Question about the history of EXEC 8, OS 1100, OS 2200, etc.
rste...@visi.com
Unisys History Newsletters and other things I've read, but I'm curious
about several things:
* When did EXEC 8 start being called OS 1100? At what EXEC level?
* When did OS 1100 become OS 2200? What EXEC level?
* Were there any other EXEC levels where interesting things happened?
New binary formats? The large program file format? Etc.?
There's at least one web site out there that maintains a history
timeline for non-UNIX OSes, and EXEC 8 gets a mention, but the entire
tree after that appears to be missing. It would be nice to have
correct (and current) information on his chart. Why let z/OS get all
the glory? :-)
Also, I'm just curious... Thanks!
-Rich Steiner (rste...@visi.com)
P.S. Why are there two different UTS emulator companies (KMSystems and
QuickWare) down here in Atlanta? Were Uniscopes designed and built
down here at one point or something?
l_c...@juno.com
> I know approximately when EXEC 8 arrived on the scene from the varioua
> Unisys History Newsletters and other things I've read, but I'm curious
> about several things:
>
> * When did EXEC 8 start being called OS 1100? At what EXEC level?
>
IIRC, Sperry changed the Exec so that message references
to "EXEC 8" became "OS1100" around the time the 1100/60
(AKA Vanguard) was released.
That would have been around 1979 or so.
As you're probably aware, at any instant in time, the
Company has (or used to have) several Exec levels in
development and so I don't know that it's all that
meaningful to ask what Exec level the change was made
to since it was likely made to at least a couple Exec
levels at roughly the same time.
Around the 1100/60 time frame, there were at least a
couple variants of 36R1 and 36R2 floating around with
several variants of 37R1 being split off the mainline
around then as well.
> * When did OS 1100 become OS 2200? What EXEC level?
>
IIRC, Exec message references to "OS1100" were changed
to "OS2200" around the time that the 2200/200
(AKA Swift) was released.
That was around the time Burroughs took over Sperry
which would have been around 1986.
My memory is a lot fuzzier about what Exec levels were
running around about then, but the range would have
probably been somewhere between 39 to 41.
<snip>
Stephen Fuld
<l_c...@juno.com> wrote in message
news:1139452749.6...@o13g2000cwo.googlegroups.com...
> Rich Steiner (rste...@visi.com) wrote:
>
>> I know approximately when EXEC 8 arrived on the scene from the varioua
>> Unisys History Newsletters and other things I've read, but I'm curious
>> about several things:
>>
>> * When did EXEC 8 start being called OS 1100? At what EXEC level?
>>
>
> IIRC, Sperry changed the Exec so that message references
> to "EXEC 8" became "OS1100" around the time the 1100/60
> (AKA Vanguard) was released.
> That would have been around 1979 or so.
I thought it was earlier than that; about the time the 1108,1106 and 1110
were replaced by their semiconductor memory (i.e. DRAM) equivalents, the
1100/10,1100/20 and 1100/40 which would have been a few years earlier,
perhaps 1977 (?).
--
- Stephen Fuld
e-mail address disguised to prevent spam
Steve J. Martin
the old name kicking around for maximum confusion.
When I sign on to demand on Exec 47R3, the first line Exec displays is:
*UNISYS 1100 Operating System Level ...
At some point they updated it from Sperry or Univac to UNISYS but the
1100 is still there. I like it!
Cheers,
Steve
l_c...@juno.com
You could be right.
I'm reasonably confident about when the "1100" to "2200"
name change occurred time-wise, but I'll defer to just
about anyone else with a different recollection when it
comes to the "Exec 8" to "1100" name change.
I think I recall being around (working for the Company)
when a fix was applied to Exec announcement message that
appears around "ENTER DATE" as part of the 1100/60 adapt
which is 1979.
My memory isn't what it used to be though, so maybe I'm
just hallucinating.
This stuff all sounds like questions R.Q. could answer.
So, Mr. Smith, are you lurking around out there somewhere?
If so, care to give us your recollections?
l_c...@juno.com
Sperry Univac/Sperry/Unisys 1100/2200 system, they
(used to) usually get a copy of the Exec in the form of
a master tape which contains a file containing the base
symbolics for the Exec (the base) and a file containing
symbolic corrections which when applied to the base
produce the symbolics for the latest version of the
Exec (the permanent correction file or PCF).
I gather that it's up to the customer to find another
working 1100/2200 somewhere and perform a sys gen to
produce a (hopefully working) boot tape and to then
continually apply the corrections they (the customer)
feels are appropriate.
So what's all of this basic background information
got to do with anything?
Well, if you say that you're seeing a 47 level Exec
that's still spitting out a reference to "1100
Operating System", then I guess I'll have to believe
you, but I'm also reasonably confident that 47 level
is *WAY* beyond when the Exec base symbolics were
updated by Unisys to say "2200".
When I left the Company more than 10 years ago, the
Exec level was up to around 45 level and I'm pretty
sure that Unisys had pretty much changed all of the
"1100" references to "2200" references by then.
Perhaps the customer thought that "1100" was more
"appropriate" and so either didn't apply the Unisys
change or applied a change to change it back.
Of course, if this were the case, why didn't they
change "Unisys" to "Univac"? ;-)
Bert Hyman
@z14g2000cwz.googlegroups.com:
> Well, if you say that you're seeing a 47 level Exec
> that's still spitting out a reference to "1100
> Operating System", then I guess I'll have to believe
> you, but I'm also reasonably confident that 47 level
> is *WAY* beyond when the Exec base symbolics were
> updated by Unisys to say "2200".
Looking at a system running 48R1, which is pretty recent, it still
says "UNISYS 1100 Operating System ...."
--
Bert Hyman | St. Paul, MN | be...@iphouse.com
Marc Wilson
<9OKGf.364365$qk4.1...@bgtnsc05-news.ops.worldnet.att.net>::
I started working on Sperry kit in '80, and I think it was already labelled
as OS1100 then (but Exec 8 was also mentioned). Level 36R1, IIRC.
That was on a (new) 1100/80 installation.
--
Marc Wilson
___________________________________________________________________
Cleopatra Consultants Limited - IT Consultants - ICE Partner - BIS Associate
Tel: (44/0) 845 890-3012 Fax: (44/0) 871 236-1531
Mail: in...@cleopatra.co.uk Web: http://www.cleopatra.co.uk
___________________________________________________________________
MAPPER User Group mailing list: send *SUBSCRIBE to M...@cleopatra.co.uk
Steve J. Martin
my system software (about every two years), we start with the Exec base
symbolics and PCF as released by Unisys. We apply some PCRs, all from
Unisys.
The string '*UNISYS 1100 OPERATING SYSTEM LEVEL' is at line 395 of
element RSIMSG in the Exec level 47 base symbolics. Unisys updated
this element for level 47 in July 2002.
So on my system the '1100' is not a carryover from the distant past.
Everytime Unisys changes this string they risk breaking some RSI$
programs that expect it as an indication that logon worked. IIRC I had
to change a program of mine years ago when they changed it to 'UNISYS'.
So they might now be hesitant to change this string (?).
-- Steve
Eugene Miya
<rste...@visi.com> wrote:
>I know approximately when EXEC 8 arrived on the scene from the varioua
>Unisys History Newsletters and other things I've read, but I'm curious
>about several things:
>
>* When did EXEC 8 start being called OS 1100? At what EXEC level?
It was about level 35-36.
It was about 1980 (I saw the 79 post, I think that's too early).
Or 1981. It happened about the time when JPL got 3 1100/81s.
I recall the levels because of the awful printers we had which could
never align a line.
>* When did OS 1100 become OS 2200? What EXEC level?
When did 2200s come out?
>timeline for non-UNIX OSes, and EXEC 8 gets a mention, but the entire
--
Ron Smith
Exec 8 became OS 1100 with the introduction of the 1110 computer in 1972.
There was some discussion of changing the name to Exec 10 and we even had
that in the system. In fact, I have a picture of a console that says Exec
10. It was changed in Exec level 27.
We did in fact change the Exec ID line on the console to say OS 2200, but
had to change it back. We discovered that customers, especially NUK (Japan)
had scripts that looked for the OS 1100 line.
--
Ron Smith
Unisys
Roseville, MN
(Remove nsp. from e-mail address)
<rste...@visi.com> wrote in message
news:1139432780.5...@f14g2000cwb.googlegroups.com...
Stephen Fuld
<l_c...@juno.com> wrote in message
news:1139515268.8...@z14g2000cwz.googlegroups.com...
> As you're probably aware, when a new customer buys a
> Sperry Univac/Sperry/Unisys 1100/2200 system, they
> (used to) usually get a copy of the Exec in the form of
> a master tape which contains a file containing the base
> symbolics for the Exec (the base) and a file containing
> symbolic corrections which when applied to the base
> produce the symbolics for the latest version of the
> Exec (the permanent correction file or PCF).
> I gather that it's up to the customer to find another
> working 1100/2200 somewhere and perform a sys gen to
> produce a (hopefully working) boot tape and to then
> continually apply the corrections they (the customer)
> feels are appropriate.
It's been a long time, but they also used to supply a "starter Exec", which
was bootable on an 1108 (IIRC) that could be run time configured to run on
almost any configuration and was enough of a system to allow doing a sysgen
to get your initial system up and running. And, of course, given a new
customer, Univac would be more than happy, given your configuration, to run
a sysgen on one of their machines to get you started. Now a days, the
number of new name customers, i.e. those without an existing 2200 series
system upon which to run a gen, is assymptotic to zero, so it just isn't a
problem. :-(
l_c...@juno.com
<snip>
>
> It's been a long time, but they also used to supply a "starter Exec", which
> was bootable on an 1108 (IIRC) that could be run time configured to run on
> almost any configuration and was enough of a system to allow doing a sysgen
> to get your initial system up and running. And, of course, given a new
> customer, Univac would be more than happy, given your configuration, to run
> a sysgen on one of their machines to get you started. Now a days, the
> number of new name customers, i.e. those without an existing 2200 series
> system upon which to run a gen, is assymptotic to zero, so it just isn't a
> problem. :-(
>
IMHO, slapping a boot tape up on a 2200 and booting
it without first performing a sysgen to tailor it
to a particular hardware configuration hasn't been a
significant problem for a long time, and not simply
because the number of new customers has been
declining.
I don't know what happened in the 1108 days, but the
"starter Exec" I'm familar with appeared with the
1100/60.
It wasn't a different special purpose exec like the
Sigma, Summit, or Mate, but rather was the real live
OS1100 Exec which had been adapted to include a new
"starter Exec" bootstrap segment made from an element
whose name, IIRC, was *BTSTART.
I think it was invoked at run at manual boot time via
a jump key, although I can't remember which one.
The BTSTART segment couldn't deal with just any
arbitrary hardware configuration.
Instead, it expected that certain types of
peripherals would be connected to certain channel
interfaces.
A probe I/O would identify the presence and type of
peripheral.
As a result of a probe, BTSTART could effectively
prune a theoretical superset hardware configuration
described by a canned superset Master Configuation
Table (MCT) down to something that described the
actual hardware configuation (or at least enough of
it to allow a sysgen).
I don't know how much this "starter Exec" was used,
but the idea of making the Exec self-configuring
with respect to hardware re-appeared in the 1100/50
(AKA System11/Mapper10) where it worked quite
well.
It was implemented differently, though, in that the
code and data to implement the superset probing
feature was added to the existing (non-1100/60 only)
bootstrap BTCTL segment made up of the elements
*BTCTL, *BTDATA, and *BTSUB, which was updated to
work for 2200/200 and 2200/400 systems as well.
Again, probing was invoked at manual boot time via
a jump key, and again, I can't remember which one.
A major problem with probing is that the channel
hardware and peripherals of the time weren't
designed to be self-identifying and since most
peripherals weren't being made by Sperry/Unisys,
there was essentially no chance that full
self-identification would ever be possible.
And even if it were possible, the combinatorial
explosion for really large configuations was
nothing to sneeze at.
As part of the 2200/900 adapt, the Exec was changed
to get a description of a system's hardware
configuration in the form of a full blow Partition
Data Bank (PDB) from the SCF at manual boot time.
The Exec builds an MCT from scratch from the PDB.
(On autorecovery boots, the SCF passes a
lobotomized PDB sans hardware configuation.)
So, since the 2200/900, it has not only been
unnecessary to perform a sysgen to tailor a boot
tape to a particular hardware configuration system,
it's also stopped being a meaningful thing to do,
at least in the way it used to be.
So, aside from a trip down memory lane, do I
have any other point to make that's on topic?
Well in away, yes, in that in Mr. Steiner's original
posting, he asked about " ... other EXEC levels
where interesting things happened ... ".
As I think back on the really large changes made to
the Exec in the "Good Old Days", virtually all were
hardware driven resulting in the regular hammering
of the heavily hardware dependent portions of the
Exec like Bootstrap/Initialization (INT), Hardware
Fault Control (HFC), and the I/O Complex (IOC and
IOP) getting regularly hammered.
(This really isn't much of a surprise since this
is the reason why the mysterious and unavailable
"Hardware-Software Independence" Spec, HSI-002,
referenced in an appendix of every 2200 IP PRM
since the 2200/900, was drawn up.)
In fact, the only 2 significant exceptions I can
think of are "New FI" (i.e. the re-design and
re-write of Facilities [FIN] in PLUS) and
"B1 Security" (i.e. the adapt to make a version of
the Exec that could obtain a B1 security rating).
I don't have any idea anymore when either of these
features hit the fan.
And, yes, I know some of the scaling related
changes like "EXPOOL expansion" and "Exec in a
file" addressed problems that weren't specific to
one type of hardware, but ISTM that these problems
had a way of being ignored until some new piece of
hardware pretty much forced them to be addressed
so I consider them to be hardware driven changes
as well.
Stephen Fuld
<l_c...@juno.com> wrote in message
news:1139682831....@g47g2000cwa.googlegroups.com...
snip
You make a good point about the big changes being hardware driven. I
thought about what other big changes came about that weren't hardware
driven, and I thinnk I can add two to your list. The whole conversion of
demand processsing to to RSI, (Remote Symbiont Interface) affected a lot of
stuff and done IIRC in Level 31 (along with being the first general release
Exec to support the 1110, but the two weren't related) was one. You might
consider the integration of TIP from where it was a separate PCF supplied by
Eagan to an integral part of Exec to be another. IIRC, that was in level
33?????
Note that for me, this IS just a trip down memory lane! :-)
Richard Steiner
eug...@cse.ucsc.edu (Eugene Miya) spake unto us, saying:
><rste...@visi.com> wrote:
>
>>* When did EXEC 8 start being called OS 1100? At what EXEC level?
>
>It was about level 35-36.
>It was about 1980 (I saw the 79 post, I think that's too early).
>Or 1981. It happened about the time when JPL got 3 1100/81s.
We had an 1100/82 at Mankato State when I arrived there in the fall in
1981, and I think it was already caled OS 1100 at that point.
>>* When did OS 1100 become OS 2200? What EXEC level?
>
>When did 2200s come out?
Good question; I suspect the nomenclature change was simultaneous.
The first 2200's I played on were the 2200/400's living at the Unisys
Airline Center in Eagan (MACS Building on Pilot Knob) in mid-1990.
We also had DDP access from ADSC to a few Mercury boxes (2200/900's) in
Roseville at that point, so those were around. Maybe not production
yet, though.
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Mableton, GA USA
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
WARNING: I've seen FIELDATA FORTRAN V and I know how to use it!
The Theorem Theorem: If If, Then Then.
Richard Steiner
"Ron Smith" <ronq....@nsp.unisys.com> spake unto us, saying:
>Exec 8 was the "Executive System for the UNIVAC 1108."
I knew it was first associated with the 1108, but that's an interesting
(well, to me <g>) bit of trivia. Thanks. :-)
l_c...@juno.com
FWIW, the "UNIVAC 1100/2200 Series" Wikipedia entry
( http://en.wikipedia.org/wiki/UNIVAC_1100/2200_series )
says that the 2200/200 came out in 1986, which coincides
nicely with my recollection.
But the entry also happens to give 2 contradictory
dates for the 2200/100, one which indicates that it was
released in 1985 (a year before the 2200/200) and one
which indicates that it was released in 1990 (6 years
after the 2200/200).
Now, I don't know what the 2200/100 is/was in real terms
(I assume that it was really some form of repackaged
2200/200 or 2200/400 since those were the only "real"
released 2200s before the 2200/900), but I do *KNOW*
that the 2200/200 was the first "2200" released.
(And for those of you who think I forgot the 2200/600,
no, I didn't ... the 22000/600 was "really" a 1100/90
based on a different chip technology.)
Also, FWIW, in the "External Links" section of the
Wikipedia page, there's a link to a PDF file entitled,
"A history of Univac Computers and Operating Systems"
( http://people.cs.und.edu/~rmarsh/CLASS/CS451/HANDOUTS/os-unisys.pdf
).
On page 11, this file states that the 1110 was
"announced" on November 10, 1970.
Now in a contest between some nameless Univac/Sperry
"historian" and R.Q., I'll tend to believe R.Q. every
time, but the specificity of the announcment date did
get me to wondering if maybe the 1110 was "announced"
long before it was "released", making both the
"historian" and R.Q. right.
(Note that the "External Links" section also contains
a reference to a text file entitled, "Univac Timeline",
which also indicates that the 1110 was also released in
1972.)
Anyone care to comment?
R.Q.?
Stephen Fuld
<l_c...@juno.com> wrote in message
news:1139774159.8...@g44g2000cwa.googlegroups.com...
snip
> Now, I don't know what the 2200/100 is/was in real terms
I believe it was a rebadged "System/11" AKA MAPPER 10. Never popular.
David Schroth
> Stephen Fuld wrote:
> <snip>
>
>>It's been a long time, but they also used to supply a "starter Exec", which
>>was bootable on an 1108 (IIRC) that could be run time configured to run on
>>almost any configuration and was enough of a system to allow doing a sysgen
>>to get your initial system up and running. And, of course, given a new
>>customer, Univac would be more than happy, given your configuration, to run
>>a sysgen on one of their machines to get you started. Now a days, the
>>number of new name customers, i.e. those without an existing 2200 series
>>system upon which to run a gen, is assymptotic to zero, so it just isn't a
>>problem. :-(
>>
>
While I didn't arrive on the scene until 1100/80 days, I supported an
1106 at the LA Data Center, and I don't remember any such beast as a
starter Exec for the pre-2200/900 systems. Indeed, a part of the
justification for the 1106 in the LA Data Center was its use to generate
initial software releases for new customers. The arrival of
Cosmic/Comus caused us a severe amount of pain (the initial release was
so large that the only way to successfully perform a system generation
was to reboot the machine, and run only the system generation. Allowing
anything else to run begore the system generation would invariably cause
the system generation to fail.
I won't argue with your recollection of bootstrap, but I have no
recollection of using probing to get an new account 1100/60 up and
running. And I helped install quite a number of them.
Gee, I would suggest that the switch from granule tables to DAD tables
was pretty large and significant.
RQ asserts that they considered converting the file system to a
hierarchical file system at that time, but were dissuaded when their
customers said they didn't want to deal with the conversion to a
hierarchical file system.
I know that the absolute format has changed at least once, and Univac
released a utility that would convert absolute elements from the old
format to the new format.
While I can forgive the original developers for the design of program
files, I don't think there is any good reason/justification for the ugly
hacks done since that have resulted in program files, large program
files, and large element program files.
Before my time, there was no such thing as common banks. There was
something analagous, but bank switching was done via ER rather than
instruction (REP$ ?). So the whole area of common banks, AFCBs, NCCBs,
etc was pretty big.
I'd say the switch from a segmented architecture to a segmented and
paged architecture was a pretty significant change. (and as a
consequence of that change, I'm now extremely leery of Death Marches.)
More currently the switch from interrupt-driven I/O to polled I/O is
pretty big.
> And, yes, I know some of the scaling related
> changes like "EXPOOL expansion" and "Exec in a
> file" addressed problems that weren't specific to
> one type of hardware, but ISTM that these problems
> had a way of being ignored until some new piece of
> hardware pretty much forced them to be addressed
> so I consider them to be hardware driven changes
> as well.
>
I'll concede that a number of those are hardware driven changes.
David Schroth
I'm not real happy with that Wikipedia entry. There are several things
in it that are flat-out wrong (the assertion that third-word references
are unsigned being a big one), and attempts to correct the entry are
undone. And their view of the architecture appears to date to the 1110
or the 1100/80 (given the references to J registers). They also claim
the existence of at least one model I've never heard of (it appears to
be a typo).
<snip>
Regards,
David
Marc Wilson
<daSHf.385009$qk4.3...@bgtnsc05-news.ops.worldnet.att.net>::
>
>I'm not real happy with that Wikipedia entry. There are several things
>in it that are flat-out wrong (the assertion that third-word references
>are unsigned being a big one),
Heretics! How could the following code snippet work, else?
TP,T1 $ . What mode are we in?
J THIRDWORD . Third-word mode.
gg...@gta.ga.gov
Earlier in this string someone made reference to A history of Univac
Computers and Operating Systems" which is on the web at
http://people.cs.und.edu/~rmarsh/CLASS/CS451/HANDOUTS/os-unisys.pdf
This is an unattributed steal of the article RQ and I wrote for the
IEEE Annals of the History of Computing on Sperry Rand's third
generation computers.
The 1110 was announced on November 10, 1970. Units were not shipped
until later.
l_c...@juno.com
> In comp.sys.unisys, (David Schroth) wrote in
> <daSHf.385009$qk4.3...@bgtnsc05-news.ops.worldnet.att.net>::
>
> >
> >I'm not real happy with that Wikipedia entry. There are several things
> >in it that are flat-out wrong (the assertion that third-word references
> >are unsigned being a big one),
>
> Heretics! How could the following code snippet work, else?
>
> TP,T1 $ . What mode are we in?
> J THIRDWORD . Third-word mode.
>
Thank you for proving Mr. Schroth's point since the
snippet obviously "works" based upon the setting of
the third-word/quarter word designator bit (which is
DB32 for M-Series machines like the 2200/900).
When quarter word mode rather than third word mode is
enabled, the instructions j-field code is interpreted
as a reference to Q1 rather than T1 as indicated by the
assembly mnemonic.
Q1 of a "TP" instruction is treated as an unsigned
number (i.e. it is NOT automatically sign) where as
T1 of a "TP" instruction is treated as a signed number.
Therefore, since the MSB of the "TP" opcode is set, a
positive value is loaded if a reference to the "TP" is
made in quarter word mode, while a negative value is
loaded if a third word reference is made.
And, oh, by the way, it's nice to hear from you again,
Mr. Schroth ... so how's the car working these days?
Quincy
IIRC), bootable tape/cart shipped with the base symbolics etc. I
certainly used this on 2200/400 before performing a sysgen.
Best Regards,
Steve Quinnell.
Quincy
JK14 - Not used, Was used for the Starter Executive
JK19 - Not used, Was used for Installation Boot
David W Schroth
> David Schroth wrote:
>
> GPTE - General Purpose Typical Exec, used with hardware probe JK (19
> IIRC), bootable tape/cart shipped with the base symbolics etc. I
> certainly used this on 2200/400 before performing a sysgen.
>
Which doesn't conflict with what I was saying. My remarks were directed
toward the 1100/60, which preceded the 2200/400 by several years...
By the time the 2200/400 came out, I was no longer in the field, and
hadn't been for a while.
> Best Regards,
>
> Steve Quinnell.
David W Schroth
> Marc Wilson wrote:
>
>>In comp.sys.unisys, (David Schroth) wrote in
>><daSHf.385009$qk4.3...@bgtnsc05-news.ops.worldnet.att.net>::
>>
>>
>>>I'm not real happy with that Wikipedia entry. There are several things
>>>in it that are flat-out wrong (the assertion that third-word references
>>>are unsigned being a big one),
>>
>>Heretics! How could the following code snippet work, else?
>>
>> TP,T1 $ . What mode are we in?
>> J THIRDWORD . Third-word mode.
>>
In my experience, third-word sign extension and inappropriate
third-word/quarter-word references all generated significantly more
problems within the Exec than the existence of -0.
>
> <snip>
>
> Thank you for proving Mr. Schroth's point since the
> snippet obviously "works" based upon the setting of
> the third-word/quarter word designator bit (which is
> DB32 for M-Series machines like the 2200/900).
> When quarter word mode rather than third word mode is
> enabled, the instructions j-field code is interpreted
> as a reference to Q1 rather than T1 as indicated by the
> assembly mnemonic.
> Q1 of a "TP" instruction is treated as an unsigned
> number (i.e. it is NOT automatically sign) where as
> T1 of a "TP" instruction is treated as a signed number.
> Therefore, since the MSB of the "TP" opcode is set, a
> positive value is loaded if a reference to the "TP" is
> made in quarter word mode, while a negative value is
> loaded if a third word reference is made.
>
> And, oh, by the way, it's nice to hear from you again,
> Mr. Schroth ... so how's the car working these days?
>
Hi, Lewis. I just ran into Joan Heinz in Daytons, and we spent some
productive time g/o/s/s/i/p/i/n/g/talking about you.
Which car would you be asking about? The old Toyota is long gone, the
new Toyota just got out of the body shop, and both current cars recently
incurred expensive repair bills (excluding the bodywork, which insurance
should pay for).
Who knew that hitting a chunk of ice on the ramp going from 35W to
Industrial Boulevard could put a hole in an oil pan?
Regards,
David
Marc Wilson
<1139855577.7...@g14g2000cwa.googlegroups.com>::
>Marc Wilson wrote:
>> In comp.sys.unisys, (David Schroth) wrote in
>> <daSHf.385009$qk4.3...@bgtnsc05-news.ops.worldnet.att.net>::
>>
>> >
>> >I'm not real happy with that Wikipedia entry. There are several things
>> >in it that are flat-out wrong (the assertion that third-word references
>> >are unsigned being a big one),
>>
>> Heretics! How could the following code snippet work, else?
>>
>> TP,T1 $ . What mode are we in?
>> J THIRDWORD . Third-word mode.
>>
><snip>
>
>Thank you for proving Mr. Schroth's point since the
>snippet obviously "works" based upon the setting of
>the third-word/quarter word designator bit (which is
>DB32 for M-Series machines like the 2200/900).
I *know*. I'm saying that the Wikipedia is wrong, not Mr Schoth.
>When quarter word mode rather than third word mode is
>enabled, the instructions j-field code is interpreted
>as a reference to Q1 rather than T1 as indicated by the
>assembly mnemonic.
>Q1 of a "TP" instruction is treated as an unsigned
>number (i.e. it is NOT automatically sign) where as
>T1 of a "TP" instruction is treated as a signed number.
>Therefore, since the MSB of the "TP" opcode is set, a
>positive value is loaded if a reference to the "TP" is
>made in quarter word mode, while a negative value is
>loaded if a third word reference is made.
Listen, I didn't eat alphabet soup and shit that code out, you know. I
used to do that stuff for a living.
l_c...@juno.com
> In comp.sys.unisys, (l_c...@juno.com) wrote in
> <1139855577.7...@g14g2000cwa.googlegroups.com>::
>
> >Marc Wilson wrote:
> >> In comp.sys.unisys, (David Schroth) wrote in
> >> <daSHf.385009$qk4.3...@bgtnsc05-news.ops.worldnet.att.net>::
> >>
> >> >
> >> >I'm not real happy with that Wikipedia entry. There are several things
> >> >in it that are flat-out wrong (the assertion that third-word references
> >> >are unsigned being a big one),
> >>
> >> Heretics! How could the following code snippet work, else?
> >>
> >> TP,T1 $ . What mode are we in?
> >> J THIRDWORD . Third-word mode.
> >>
> ><snip>
> >
> >Thank you for proving Mr. Schroth's point since the
> >snippet obviously "works" based upon the setting of
> >the third-word/quarter word designator bit (which is
> >DB32 for M-Series machines like the 2200/900).
>
> I *know*. I'm saying that the Wikipedia is wrong, not Mr Schoth.
I *know* you *know*.
I figured that out from the code snippet. (Duh.)
Therefore, I *know* you're saying the Wikipedia is
wrong and not Mr. Schroth.
And *I'm* saying that you provided an excellent
example that proves the point he made ... provided
the reader of your post makes the connection that
the code snippet potentially behaving differently
depending on on the setting of the quarter
word/third word designator.
I imagine that most folks reading this thread
probably have been around the block enough to make
that connection almost instantly, just like I did.
To them, I imagine that my follow-up posting was
quite superfluous.
But then, I imagine that most folks who are
reading this thread also realized the correctness
of Mr. Schroth's point about third-word references
without the need for your comment and the code
snippet.
OTOH, I thought that anyone who hadn't been around
the block enough to realize the obvious could use
the obvious being pointed out to them since you
failed to do so.
Hence, my follow-up reply.
>
> >When quarter word mode rather than third word mode is
> >enabled, the instructions j-field code is interpreted
> >as a reference to Q1 rather than T1 as indicated by the
> >assembly mnemonic.
> >
> >Q1 of a "TP" instruction is treated as an unsigned
> >number (i.e. it is NOT automatically sign) where as
> >T1 of a "TP" instruction is treated as a signed number.
> >Therefore, since the MSB of the "TP" opcode is set, a
> >positive value is loaded if a reference to the "TP" is
> >made in quarter word mode, while a negative value is
> >loaded if a third word reference is made.
>
> Listen, I didn't eat alphabet soup and shit that code out, you know. I
> used to do that stuff for a living.
>
>
> --
> Marc Wilson
<snip>
As I look back on my previous post, I noticed a
number of mistakes that I made in haste (e.g.
quoting "works" rather that "obviously" and word
"extended" missing from the explaination that
followed).
Hopefully, I would have fixed had I taken more time.
If I had, perhaps I might have even changed my first
sentence to read more like, "Thank you for
[providing an example] proving Mr. Schroth's
point ... ", which hopefully would have made it
clear that my intent was *NOT* to insult you by
implying that you didn't know what you were talking
about.
Since you obviously took my post as an insult,
I sincerely apologize for my unintended slight.
Having said that, and at the risk of blowing any
goodwill my apology might have garnered from you,
however, let me also say that when handed lemons
(e.g. smart Alec comments and/or other
"background noise") by you or anyone else, I will,
when I feel it's appropriate, try to make lemonade
(i.e. post follow-ups that are just as smart Alec
and vacuous and/or which I hope will be useful to
at least some of the potential readership).
If you have a problem with that, well that's too
bad ... get over it.
Stephen Fuld
"David Schroth" <David....@worldnet.att.net> wrote in message
news:26SHf.384988$qk4.3...@bgtnsc05-news.ops.worldnet.att.net...
> l_c...@juno.com wrote:
>> Stephen Fuld wrote:
>> <snip>
>>
>>>It's been a long time, but they also used to supply a "starter Exec",
>>>which
>>>was bootable on an 1108 (IIRC) that could be run time configured to run
>>>on
>>>almost any configuration and was enough of a system to allow doing a
>>>sysgen
>>>to get your initial system up and running. And, of course, given a new
>>>customer, Univac would be more than happy, given your configuration, to
>>>run
>>>a sysgen on one of their machines to get you started. Now a days, the
>>>number of new name customers, i.e. those without an existing 2200 series
>>>system upon which to run a gen, is assymptotic to zero, so it just isn't
>>>a
>>>problem. :-(
>>>
>>
>
> While I didn't arrive on the scene until 1100/80 days, I supported an 1106
> at the LA Data Center, and I don't remember any such beast as a starter
> Exec for the pre-2200/900 systems.
Indeed, you young whippersnapper! :-) I Believe that starter exec was
phased out after about Exec level 27. When the 1110 came out, it was so
different that it probably wasn't possible to have a single starter exec for
all configurations. Of course, this was long before the 1100/80.
Marc Wilson
Sorry- I was jumping to an unwarranted conclusion.
And I also apologise for spelling "Schroth" incorrectly.
Quincy
Univac flavor after NODE SGS's were dropped with the PDB's.
I'm no longer in the industry either :(
Hi Ron!
Q.
l_c...@juno.com
all this talk about "starter Exec" has brought something
to mind that I haven't heard anyone outside of
Univac/Sperry/Unisys ever mention.
Just out of curiosity, since the place seems to filled
with "old geezers", would anyone here happen to know what
I mean if I mentioned the word "Roanoake"?
(And if you don't know, don't ask.)
David W Schroth
Yes.
Williams, Steve
I was visiting Roseville from the UK (and looking for a job) the week after the project
was cancelled. Bad time to look for a job!
I rescued one or two manuals describing the architecture from being dumped while I was
there later, which I still have somewhere. As I remember the scheme seemed a bit grandiose
for the technology then available, but I guess those people knew better than I did.
Ron Smith
--
Ron Smith
Unisys
Roseville, MN
(Remove nsp. from e-mail address)
<l_c...@juno.com> wrote in message
news:1139953238....@g47g2000cwa.googlegroups.com...
Colin Zealley
I first met Exec 8 as an operator employed by a customer, when both it and I
were at around level 19, AFAIR, in 1968 or so at Shell Mex & BP in Hemel
Hempstead.
But didn't the console continue to use a runid of EXEC8 to mark
Exec-originated messages for quite some years after it 'officially' became
OS1100? Anyone recall that, or am I smoking stuff?
Colin
"Richard Steiner" <rste...@visi.com> wrote in message
news:jfu7DpHp...@visi.com...
Eugene Miya
So go in an fix it.
That's how Wikipedia is supposed to work.
Short of revealing secrets, real secrets, or sensitive data, it's not
supposed to be a passive thing. The old supercomputer entry had a quote
wrongly attributed to Seymour Cray. Clearly in such fields there will
be some things which will never see the light of day. They don't have
to go into Wikipedia.
--
David W Schroth
I did go in and fix it.
And someone immediately reversed my fix.
Had I the time, I'd probably try to make the change, and make it stick.
Regards,
David W. Schroth
Marc Wilson
>>> >> >I'm not real happy with that Wikipedia entry. There are several things
>>> I *know*. I'm saying that the Wikipedia is wrong, not Mr Schoth.
>
>So go in an fix it.
>That's how Wikipedia is supposed to work.
The OP said that fixed entries were being removed- that's the downside of
Wikipedia; two (or more) people who disagree about something can enlessly
chop the entries about. It's especially galling when one of them is
demonstrably wrong, and won't admit it.
Jeff Wilson
been locked down because of edit wars. They also seem to attempt to
resolve differences and in extremis they can lock out users from making
changes. Perhaps whomever you were locking horns with has moved on by now.
I've been updating the MCP related pages lately and haven't had any
problems. When you do get the OS pages sorted out, add [[Category:
Operating systems]] to the bottom so they'll get listed in the Operating
systems category page. And look around. I found quite a few pages that
I could legitemitely add a reference to the MCP or Unisys to.
Richard Steiner
"Ron Smith" <ronq....@nsp.unisys.com> spake unto us, saying:
>Yup, I worked on it.
Heh. I've gotten the impression over the years that you've either seen
or actually worked on just about everything at Sperry/Unisys. :-)
Eugene Miya
Jeff Wilson <jeff....@unisys.com> wrote:
>Did anyone complain to the admins. There are lists of pages that have
>been locked down because of edit wars. They also seem to attempt to
>resolve differences and in extremis they can lock out users from making
>changes. Perhaps whomever you were locking horns with has moved on by now.
Marc Wilson wrote:
>> The OP said that fixed entries were being removed- that's the downside of
>> Wikipedia; two (or more) people who disagree about something can enlessly
>> chop the entries about. It's especially galling when one of them is
>> demonstrably wrong, and won't admit it.
And that is how Wikis work.
You guys have to resolve differences.
Gawd, what's his name, who runs the project, my brain went blank, I met
him 2 years ago. If you can't agree on one node, split the difference.
You can't just point to authority in Wikis. There are bigger fish to
fry than history.
--
Louis Krupp
So if I insist that the Battle of Hastings happened in 1866, we're
supposed to agree on 1466, and call it good?
Louis
Stephen Fuld
Several people have responded here, and I vaguely remember something about
it (I was working at a user site then and a little leaked out). From what I
recall, the rumor was of a group that met at the Roanoke Hotel and was
trying to define a new system that combined the attributes of the 1100
series and the 9000 series (byte oriented low end IBM near look alikes). I
recall something about bit oriented addressing. But that is all I know.
Since we have people who know more, and the strictures of non-disclosures
are long gone (IIRC this was the mid 1970s), will those who know tell us
about it?
Eugene Miya
Louis Krupp <lkr...@pssw.nospam.com.invalid> wrote:
>So if I insist that the Battle of Hastings happened in 1866, we're
>supposed to agree on 1466, and call it good?
Well, I would say that you guys have been working for mainframe based
firms too long (central authority thinking).
Wikipedia has to deal with far more controversial subjects.
Split the node, fork two sets of ideas. Work and keep improving one side.
--
Mike
Servers, ClearPath OS 2200 Release 10.1 September/2005 CD results in 171
instances of 'EXEC 8' and 'EXEC-8'. Including "Exec (also known as the
Executive, Executive System, Exec-8) is a software supervisor that controls
the OS 2200 system operating environment." on page 7-5 of the "ClearPath
Enterprise Servers ClearPath OS 2200 Systems Software Product Catalog", 7850
5252-011.
The run id "EXEC 8" is still used for EXEC log entries, and is displayed in
some console messages (e.g. I/O errors). For example, see page 19-23 in the
"OS 2200 System Console Messages
Reference Manual", 7833 3275-019.
The above documents are publicly available on the Unisys Support site, if
you agree to the terms
(http://public.support.unisys.com/os1/txt/web-verity?type=list).
Cheers,
Mike
"Colin Zealley" <colin....@removethisbit.unisys.com> wrote in message
news:dt032i$1qnh$1...@si05.rsvl.unisys.com...
Ron Smith
Minneapolis where a group of Sperry people met to put together the plan.
Roanoke started in the early 1970s when all computer companies were dreaming
about 4th generation computing. IBM had their FS (Future System) project.
Honeywell, Burroughs, and Control Data all had programs as well. One common
point of all of them was a movement towards machines that were oriented
toward high-level languages. IBM FS actually had language specific hardware
(really firmware) processors. There were to be COBOL, FORTRAN, and PL1
processors plus one or more OS and virtual machine manager processors.
Sperry's Roanoake, like most of the others had lots of on-processor firmware
to create the processor personality. The native mode of the hardware was
64-bit addresses, bit addressable. The address specified the starting
high-order bit. There were to be no restrictions on alignment although some
operations would be faster if the address happened to be 64-bit word
aligned. The 1100 and 9000 series systems were to be handled by firmware
emulation. There was also a virtual machine layer built in which allowed
any number of operating system instances.
The Roanoke system was more like the Burroughs MCP system architectures than
the 1100 or 9000 series. It was a descriptor and capability architecture
with a block structured stack. What's that mean? Well, there was one ADD
instruction with two operands. The operand addresses were actually number
pairs consisting of a stack block number and index within the block. The
blocks were called lexical levels. The entries on the stack contained
descriptors which had the memory addresses (bit) and length (bits) along
with data type and security access control information. The idea was that
the architecture mimic compiler intermediate text. Type conversion was
handled automatically by the "hardware." There were special instructions
for pushing descriptiors onto the stack to get things started and special
descriptors that contained small immediate data hence acting like registers
or load immediate operations.
We were doing a brand new OS (NOS), new job control language modeled on a
CODASYL proposal, a virtual machine manager, etc.
Remember that this was before UNIX had left Bell Labs. In fact, at the
height of the Roanoke program when we were seriously hiring, I was sent to
Berkeley where I had gone to school on a recruiting mission. One of my
roommates, Ken Thompson was there on sabatical from the Labs, and had
brought the first copy of UNIX with him with special permission to leave a
copy at Berkeley. Anyway, the point is that there weren't any de facto
models to follow in creating a new OS or command language and we were
totally on our own.
At Thanksgiving 1975 Roanoke was cancelled and everyone was moved back to
other 1100 or 9000 series work. IBM had previously cancelled FS as well.
In all cases the decision was the problem of having a large installed base.
It just wasn't feasible to try to move your installed base to something
totally new. Intel tried almost exactly the same thing years later with the
i432 chip which failed for the same reason. We'll see whether they can pull
it off now with Itanium.
--
Ron Smith
Unisys
Roseville, MN
(Remove nsp. from e-mail address)
"Stephen Fuld" <s.f...@PleaseRemove.att.net> wrote in message
news:O01Lf.443171$qk4.1...@bgtnsc05-news.ops.worldnet.att.net...
Bert Hyman
news:dtkec3$1s0k$1...@si05.rsvl.unisys.com:
> At Thanksgiving 1975 Roanoke was cancelled and everyone was moved
> back to other 1100 or 9000 series work.
Maybe 1977?
--
Bert Hyman | St. Paul, MN | be...@iphouse.com
Stephen Fuld
"Ron Smith" <ronq....@nsp.unisys.com> wrote in message
news:dtkec3$1s0k$1...@si05.rsvl.unisys.com...
> The Roanoake program was indeed named for the Roanoke building in downtown
> Minneapolis where a group of Sperry people met to put together the plan.
Rest of good description snipped.
Thanks, Ron. That was interesting, and the extra nugget about your roommate
was neat as well!
Colin Zealley
before.
Colin
"Ron Smith" <ronq....@nsp.unisys.com> wrote in message
news:dtkec3$1s0k$1...@si05.rsvl.unisys.com...
[snip fascinating stuff]
>