While perusing the site that Lewis gave a link to en an earlier post
(Thanks Lewis), I came across this video about the Univac C series systems.

https://digital.hagley.org/VID_1985261_B109_ID01?solr_nav%5Bid%5D=6456d02f49ec42a30406&solr_nav%5Bpage%5D=0&solr_nav%5Boffset%5D=23

which I found very interesting.

Two questions.

1. Can someone give a "cheat sheet" that gives the official product
names for the each of the internal code names shown in the talk?

2. One of the projects mentioned was a "Relational Database
Accelerator", which, I gather, never made it to market. Can someone
provide more details about this, e.g. What specifically it was supposed
to do, and why it never made it to a product?

BTW, for those interested in more "ancient trivia", a list of the links
to all the talks from that symposium that are on the site is at

https://digital.hagley.org/islandora/search/19th%20Annual%20Sperry%20Univac%20Spring%20Technical%20Symposium?type=edismax&f%5B0%5D=-RELS_EXT_isMemberOfCollection_uri_ms%3A%28%22info%3Afedora/islandora%3Aead%22%29

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Wednesday, November 15, 2023 at 1:03:53 PM UTC-8, Stephen Fuld wrote:
> While perusing the site that Lewis gave a link to en an earlier post
> (Thanks Lewis), I came across this video about the Univac C series systems.
>
> https://digital.hagley.org/VID_1985261_B109_ID01?solr_nav%5Bid%5D=6456d02f49ec42a30406&solr_nav%5Bpage%5D=0&solr_nav%5Boffset%5D=23
>
> which I found very interesting.
>
> Two questions.
>
> 1. Can someone give a "cheat sheet" that gives the official product
> names for the each of the internal code names shown in the talk?
>
> 2. One of the projects mentioned was a "Relational Database
> Accelerator", which, I gather, never made it to market. Can someone
> provide more details about this, e.g. What specifically it was supposed
> to do, and why it never made it to a product?
>
> BTW, for those interested in more "ancient trivia", a list of the links
> to all the talks from that symposium that are on the site is at
>
> https://digital.hagley.org/islandora/search/19th%20Annual%20Sperry%20Univac%20Spring%20Technical%20Symposium?type=edismax&f%5B0%5D=-RELS_EXT_isMemberOfCollection_uri_ms%3A%28%22info%3Afedora/islandora%3Aead%22%29
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

You're welcome, Mr. Fuld.

C-Series code names:

"Chaparral" = 1100/50 AKA System 11 AKA Mapper 10, the low-end of the Extended Mode (EM) Series of 1100.
"Cirrus" = 1100/90 which with a hardware refresh from Hitachi became the 2200/600, the high-end EM Series of 1100.

"Centurian" = A midrange EM 1100 between the Chaparral and Cirrus that died a quiet death last (I remember seeing some PDs on parts of it).

About the other C-Series members ("Condor" and "Capricorn"), they apparently all died before I even heard about C-Series.

As you are no doubt aware, the Company had a habit of coming up with interesting ideas that were later either dropped or seriously scaled back in order to meet various deadline constraints.
In particular, it appeared to be the way that the Company went about breaking the hardware boys and girls ... by starting a project and then cancelling it ... until they eventually went to other parts of the Company or outside it entirely.

On Wed, 15 Nov 2023 13:03:51 -0800, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

>While perusing the site that Lewis gave a link to en an earlier post
>(Thanks Lewis), I came across this video about the Univac C series systems.
>
>https://digital.hagley.org/VID_1985261_B109_ID01?solr_nav%5Bid%5D=6456d02f49ec42a30406&solr_nav%5Bpage%5D=0&solr_nav%5Boffset%5D=23
>
>which I found very interesting.
>
>Two questions.
>
>1. Can someone give a "cheat sheet" that gives the official product
>names for the each of the internal code names shown in the talk?
>
>2. One of the projects mentioned was a "Relational Database
>Accelerator", which, I gather, never made it to market. Can someone
>provide more details about this, e.g. What specifically it was supposed
>to do, and why it never made it to a product?
>
>BTW, for those interested in more "ancient trivia", a list of the links
>to all the talks from that symposium that are on the site is at
>
>https://digital.hagley.org/islandora/search/19th%20Annual%20Sperry%20Univac%20Spring%20Technical%20Symposium?type=edismax&f%5B0%5D=-RELS_EXT_isMemberOfCollection_uri_ms%3A%28%22info%3Afedora/islandora%3Aead%22%29

I know that Cirrus was the 1100/90.
I have some reason to believe that Chaparral was the System-11.
I don't know that Condor, Capricorn, and Centurion were ever released
products. Of course, for all I know, they were released as products.

Regards,

David W. Schroth

On Wednesday, November 15, 2023 at 1:03:53 PM UTC-8, Stephen Fuld wrote:
> < snip >
> 1. Can someone give a "cheat sheet" that gives the official product
> names for the each of the internal code names shown in the talk?
>
> < snip >
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

Not that it matters, but on the subject of 1100 system code names, I should like to point out that Mr. Schroth at one time posited that the 1100 Series was renamed the 2200 Series for marketing reason.
I suspect that was/is right about that, but somewhat related (as I think others have pointed out ... perhaps even you) the Company was running out of numbers for new machines.

I don't know what code names (if any) were for the 1100/40 and 1100/80 and 1100/80A, but the code name for the 1100/60 was Vanguard.
Then the Company decided that they needed to assign yet another number to the 1100/60 for some reason and so it became the 1100/70.
That only left 1100/30, 1100/50, and 1100/90 to be assigned to new machines..

So after the 1100/90 and 1100/50, the Company went to 2200/xxx for system numbers with the following C-Series systems, the 2200/600, 2200/200, and 2200/400.
I don't recall which was which, but one of the latter two was code named Liberty.
The EM 1100/2200 on a desktop that was never released, but which was apparently instrumental in the CMOS chips used in the 2200/200 and 2200/400 was code named Orion.

Then came the M-Series.
The project manager had a bad taste left in his mouth from the 1100/80 development and so he refused to assign the first M-Series machine, the number 2200/800.
The result was that the first M-Series 2200 was numbered 2200/900 and was code named Mercury.
The second M-Series system was supposed to be a lower end machine and so it was numbered the 2200/500 and was code named Quicksilver.

After that, I don't know what system numbers and code names when with which system.
The last code name I heard about was one of the systems after the 2200/500 which was code named Odyssey.

Lewis Cole wrote:
> On Wednesday, November 15, 2023 at 1:03:53 PM UTC-8, Stephen Fuld wrote:
>> < snip >
>> 1. Can someone give a "cheat sheet" that gives the official product
>> names for the each of the internal code names shown in the talk?
>>
>> < snip >
>> - Stephen Fuld
>> (e-mail address disguised to prevent spam)
>
> Not that it matters, but on the subject of 1100 system code names, I should like to point out that Mr. Schroth at one time posited that the 1100 Series was renamed the 2200 Series for marketing reason.
> I suspect that was/is right about that, but somewhat related (as I think others have pointed out ... perhaps even you) the Company was running out of numbers for new machines.
>
> I don't know what code names (if any) were for the 1100/40 and 1100/80 and 1100/80A, but the code name for the 1100/60 was Vanguard.
> Then the Company decided that they needed to assign yet another number to the 1100/60 for some reason and so it became the 1100/70.

The 1100/60 could be ordered with or without EIS, the 1100/70 was a more
powerful /60 *with* EIS (Extended Instruction Set).

> That only left 1100/30, 1100/50, and 1100/90 to be assigned to new machines.
>

The 1100/90 came with the EIS, along with some new instructions - it may
also have been the first machine with the Extended Mode instruction set.
All of the 2200 machines had EM instructions.
Which were the first ones with Paging? I remember Alan K looking at the
code for that and announcing that the code was buggy and would lead to
an Exec stop if condition X happened (X may have been if it was used at
all). A fix was released shortly afterwards.

> So after the 1100/90 and 1100/50, the Company went to 2200/xxx for system numbers with the following C-Series systems, the 2200/600, 2200/200, and 2200/400.
> I don't recall which was which, but one of the latter two was code named Liberty.
> The EM 1100/2200 on a desktop that was never released, but which was apparently instrumental in the CMOS chips used in the 2200/200 and 2200/400 was code named Orion.
>
> Then came the M-Series.
> The project manager had a bad taste left in his mouth from the 1100/80 development and so he refused to assign the first M-Series machine, the number 2200/800.
> The result was that the first M-Series 2200 was numbered 2200/900 and was code named Mercury.
> The second M-Series system was supposed to be a lower end machine and so it was numbered the 2200/500 and was code named Quicksilver.
>
> After that, I don't know what system numbers and code names when with which system.
> The last code name I heard about was one of the systems after the 2200/500 which was code named Odyssey.
>

Lewis Cole <l_cole@juno.com> writes:
>On Wednesday, November 15, 2023 at 1:03:53=E2=80=AFPM UTC-8, Stephen Fuld w=
>rote:
>> < snip >
>> 1. Can someone give a "cheat sheet" that gives the official product=20
>> names for the each of the internal code names shown in the talk?=20
>>=20
>> < snip >
>> - Stephen Fuld=20
>> (e-mail address disguised to prevent spam)
>
>Not that it matters, but on the subject of 1100 system code names, I should=
> like to point out that Mr. Schroth at one time posited that the 1100 Serie=
>s was renamed the 2200 Series for marketing reason.

The 2200 was twice as good as the 1100?

IIRC, the SLC plant was on 2200 blvd.

On Wednesday, November 15, 2023 at 11:46:22 PM UTC-8, Andrew wrote:
> Lewis Cole wrote:
> > On Wednesday, November 15, 2023 at 1:03:53 PM UTC-8, Stephen Fuld wrote:
> >> < snip >
> >> 1. Can someone give a "cheat sheet" that gives the official product
> >> names for the each of the internal code names shown in the talk?
> >>
> >> < snip >
> >> - Stephen Fuld
> >> (e-mail address disguised to prevent spam)
> >
> > Not that it matters, but on the subject of 1100 system code names, I should like to point out that Mr. Schroth at one time posited that the 1100 Series was renamed the 2200 Series for marketing reason.
> > I suspect that was/is right about that, but somewhat related (as I think others have pointed out ... perhaps even you) the Company was running out of numbers for new machines.
> >
> > I don't know what code names (if any) were for the 1100/40 and 1100/80 and 1100/80A, but the code name for the 1100/60 was Vanguard.
> > Then the Company decided that they needed to assign yet another number to the 1100/60 for some reason and so it became the 1100/70.
> The 1100/60 could be ordered with or without EIS, the 1100/70 was a more
> powerful /60 *with* EIS (Extended Instruction Set).

After the 1100/60 was release, the boys and girls responsible for its CPU microcode went back and re-did some of it which resulted in greater performance.
I *THINK* that these microcode changes were sold separately without changing the numeric designation.
Whether or not these microcode changes included the addition of the EIS instruction set, the change in performance was not terribly great, say 10 to 20% IIRC.

The big performance change was that the customer could be a non-partitionable processor cache (which was called a "buffer" rather than an "SIU"), which with more memory could boost performance by a factor of at least two.
I don't remember when this option was made available, but again, no numeric designation change occurred.

So in real terms, the 1100/70 was just an 1100/60 whose designation was changed presumably for some marketing reason.
The basic underlying hardware was the same.

> > That only left 1100/30, 1100/50, and 1100/90 to be assigned to new machines.
> >
> The 1100/90 came with the EIS, along with some new instructions - it may
> also have been the first machine with the Extended Mode instruction set.

The 1100/90 was the first Extended Mode (EM) machine.

> All of the 2200 machines had EM instructions.
> Which were the first ones with Paging? [...]

The 2200/900 was the first three addressing level machine (i.e. [bank] relative, absolute, and real).
The people who were responsible for Exec memory management were adament that paging be there from Day One, not something that could be turned off ala paging on the Intel 80386.
Nevertheless, it was suggested near the end of the project by some bozo that paging be dropped initially, which thankfully didn't happen.

> [...] I remember Alan K looking at the
> code for that and announcing that the code was buggy and would lead to
> an Exec stop if condition X happened (X may have been if it was used at
> all). A fix was released shortly afterwards.

I am familiar with the people who were responsible for paging and I trust their abilities to write good code over that of someone who just comes along and looks at it.
I don't recall when we in Roseville cut over to using the 2200/900, but by comparison to earlier machines, it was relatively painless.

> > So after the 1100/90 and 1100/50, the Company went to 2200/xxx for system numbers with the following C-Series systems, the 2200/600, 2200/200, and 2200/400.
> > I don't recall which was which, but one of the latter two was code named Liberty.
> > The EM 1100/2200 on a desktop that was never released, but which was apparently instrumental in the CMOS chips used in the 2200/200 and 2200/400 was code named Orion.
> >
> > Then came the M-Series.
> > The project manager had a bad taste left in his mouth from the 1100/80 development and so he refused to assign the first M-Series machine, the number 2200/800.
> > The result was that the first M-Series 2200 was numbered 2200/900 and was code named Mercury.
> > The second M-Series system was supposed to be a lower end machine and so it was numbered the 2200/500 and was code named Quicksilver.
> >
> > After that, I don't know what system numbers and code names when with which system.
> > The last code name I heard about was one of the systems after the 2200/500 which was code named Odyssey.
> >

Lewis Cole wrote:
> On Wednesday, November 15, 2023 at 11:46:22 PM UTC-8, Andrew wrote:
>> Lewis Cole wrote:
>>> On Wednesday, November 15, 2023 at 1:03:53 PM UTC-8, Stephen Fuld wrote:

snip

>
>> [...] I remember Alan K looking at the
>> code for that and announcing that the code was buggy and would lead to
>> an Exec stop if condition X happened (X may have been if it was used at
>> all). A fix was released shortly afterwards.
>
> I am familiar with the people who were responsible for paging and I trust their abilities to write good code over that of someone who just comes along and looks at it.

Alan K worked for Unisys, holding courses in Arcania for years. In the
meantime he'd look at the Exec and look for problems. We had one
absolute showstopper one night - an Exec stop whenever our main
Application Group was set Up - and he came round to look at it. He
immediately asked the local support people if PCR nnn had been applied.
"No". "Do so, now".
PCR nnn was the result of one of his UCFs, he'd seen the problem in the
coding. Once that Exec Gen was through, we recovered the system and all
was fine.
The way I remember it, a Stepcontrol statement had been changed months
earlier in order to make it possible to run WEBTS - this may have had to
do with Tip Session Control. We had basic security (no SECOPT1 or
higher), setting the AG UP with INIT killed the system.

If you look at the OS2200 Express documentation you will see his name
mentioned as someone they relied on heavily they created the "product".
He'd retired by then but was still an authority in exec internals.

On Thursday, November 16, 2023 at 2:33:45 PM UTC-6, Andrew wrote:
> Lewis Cole wrote:
> > On Wednesday, November 15, 2023 at 11:46:22 PM UTC-8, Andrew wrote:
> >> Lewis Cole wrote:
> >>> On Wednesday, November 15, 2023 at 1:03:53 PM UTC-8, Stephen Fuld wrote:
>
> snip
>
> >
> >> [...] I remember Alan K looking at the
> >> code for that and announcing that the code was buggy and would lead to
> >> an Exec stop if condition X happened (X may have been if it was used at
> >> all). A fix was released shortly afterwards.
> >
> > I am familiar with the people who were responsible for paging and I trust their abilities to write good code over that of someone who just comes along and looks at it.
> Alan K worked for Unisys, holding courses in Arcania for years. In the
> meantime he'd look at the Exec and look for problems. We had one
> absolute showstopper one night - an Exec stop whenever our main
> Application Group was set Up - and he came round to look at it. He
> immediately asked the local support people if PCR nnn had been applied.
> "No". "Do so, now".
> PCR nnn was the result of one of his UCFs, he'd seen the problem in the
> coding. Once that Exec Gen was through, we recovered the system and all
> was fine.
> The way I remember it, a Stepcontrol statement had been changed months
> earlier in order to make it possible to run WEBTS - this may have had to
> do with Tip Session Control. We had basic security (no SECOPT1 or
> higher), setting the AG UP with INIT killed the system.
>
> If you look at the OS2200 Express documentation you will see his name
> mentioned as someone they relied on heavily they created the "product".
> He'd retired by then but was still an authority in exec internals.

I believe the code name for the 2200/200 was Swift.

On Thu, 16 Nov 2023 21:33:40 +0100, Andrew <Doug@hyperspace.vogon.gov>
wrote:

>Lewis Cole wrote:
>> On Wednesday, November 15, 2023 at 11:46:22?PM UTC-8, Andrew wrote:
>>> Lewis Cole wrote:
>>>> On Wednesday, November 15, 2023 at 1:03:53?PM UTC-8, Stephen Fuld wrote:
>
>snip
>
>>
>>> [...] I remember Alan K looking at the
>>> code for that and announcing that the code was buggy and would lead to
>>> an Exec stop if condition X happened (X may have been if it was used at
>>> all). A fix was released shortly afterwards.
>>
>> I am familiar with the people who were responsible for paging and I trust their abilities to write good code over that of someone who just comes along and looks at it.
>
>Alan K worked for Unisys, holding courses in Arcania for years. In the
>meantime he'd look at the Exec and look for problems. We had one
>absolute showstopper one night - an Exec stop whenever our main
>Application Group was set Up - and he came round to look at it. He
>immediately asked the local support people if PCR nnn had been applied.
>"No". "Do so, now".
>PCR nnn was the result of one of his UCFs, he'd seen the problem in the
>coding. Once that Exec Gen was through, we recovered the system and all
>was fine.
>The way I remember it, a Stepcontrol statement had been changed months
>earlier in order to make it possible to run WEBTS - this may have had to
>do with Tip Session Control. We had basic security (no SECOPT1 or
>higher), setting the AG UP with INIT killed the system.
>
>If you look at the OS2200 Express documentation you will see his name
>mentioned as someone they relied on heavily they created the "product".
>He'd retired by then but was still an authority in exec internals.

The (unfortunately) late Alan K was very good at finding problems in
code. I often disagreed with his suggested fixes, but I always took
his UCFs seriously.

I rather suspect that no one who was not involved in the paging adapt
has absolutely no idea how much work/code was involved. Given the
sheer volume of code, bugs were inevitable. Given that, I'm sure that
the Exec after paging was several orders of magnitude more stable than
previous Execs, a fact I personally attribute to the architecture not
allowing IPs to directly access physical addresses - all memory
references went through the hardware protection mechanisms.

David W Schroth wrote:
>
> The (unfortunately) late Alan K was very good at finding problems in
> code. I often disagreed with his suggested fixes, but I always took
> his UCFs seriously.
>

Oh, really bad news, I had not known.

On Fri, 17 Nov 2023 21:53:49 +0100, Andrew <Doug@hyperspace.vogon.gov>
wrote:

>David W Schroth wrote:
>>
>> The (unfortunately) late Alan K was very good at finding problems in
>> code. I often disagreed with his suggested fixes, but I always took
>> his UCFs seriously.
>>
>
>Oh, really bad news, I had not known.

Irecently received that bad news in a forwarded copy of an email. I
don't feel comfortable posting the email I saw without permission from
the author of the email, who worked closely with Alan K in recent
years.