According to Scott Lurndal <slp53@pacbell.net>:
>>Wikipedia says that while S/360 and the B5500 were announced in 1964,
>>the B3500 was announced in 1966. In the discussion of MCP on the B3500
>
>Sorry, I mean to imply that the B3500 (and successors) were 100% sw
>compatible within the medium systems family.
>
>Likewise for the large systems (B5500) line. ...

Oh, OK. In view of the timing, I'd guess that the people at Burroughs,
who were certainly not dumb, looked at the S/360 material and figured
oh, that's a good idea, we can do that too.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to MitchAlsup1 <mitchalsup@aol.com>:
>> TSS was a disaster due to an extreme case of second system syndrome,
>> but Michigan's MTS and IBM skunkworks CP/67 worked great.
>
>TSS at CMU was extensively rewritten in assembly and became quite
>tolerable--hosting 30+ interactive jobs along with a background
>batch processing system. When I arrived in Sept 1975 it was quite
>unstable with up times less than 1 hour. 2 years later it would run
>for weeks at a time without going down.

For reasons I do not want to try to guess, AT&T did the software
development for the 5ESS phone switches in a Unix system that sat on
top of TSS. After IBM cancelled TSS, AT&T continued to use it as some
sort of special order thing. At IBM there were only a handful of
programmers working on it, by that time all quite experienced, and I
hear that they also got rid of a lot of cruft and made it much faster
and more reliable.

At the same time, IBM turned the skunkworks CP/67 into VM/370 with a
much larger staff, leading to predictable consequences.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 5/7/2024 12:47 PM, John Levine wrote:
> According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
>> In what sense was the S/360 architecture, designed for terminal use? I
>> already talked about the base register, BALR/Using stuff that prevented
>> an interative program from being swapped out and swapped in to a
>> different real memory location. This was a significant hinderance to
>> "terminal use".
>
> With sufficiently disciplined programming, you could swap and move data
> by updating the base registers. APL\360 did this quite successfully
> and handled a lot of interactive users on a 360/50.

Wasn't APL\360 an interpreter? If so, then moving instructions and data
around was considerably simpler.

> Reading between the lines in the IBMSJ architecture paper, I get the
> impression they believed that moving code and data with base registers
> would be a lot easier than it was, and missed the facts that a lot of
> pointers are stored in memory, and it is hard to know what registers
> are being used as base registers when.

Interesting. That would seem to imply that it wasn't that they didn't
think about the problems that base addressing would cause, they just
(vastly) underestimated the cost of fixing it. A different "design"
problem indeed.

> This paper from U of Michigan lays out the problem and proposes a
> paging design which soon became the 360/67:
>
> https://dl.acm.org/doi/pdf/10.1145/321312.321313
>
> TSS was a disaster due to an extreme case of second system syndrome,
> but Michigan's MTS and IBM skunkworks CP/67 worked great.
>
>> BTW, another problem occurs in transaction workloads where there is
>> another level of software between the user and the OS, but insteaed of
>> TSO, it was IMS or CICS, ...
>
> There's two ways to write interacticve software, which I call the time-sharing
> approach and the SAGE approach. In the time-sharing approach, the operating system
> stops and starts user processes and transparently saves and restores the process
> status. In the SAGE approach, programs are broken up into little pieces each of
> which runs straight through, explicitly saves whatever context it needs to, and
> then returns to the OS.

Unconventional terminology, but clear and I agree with your point. It
is perhaps ironic that TSO (Time Sharing Option)/360 did not use the
"time sharing" approach. :-(

> The bad news about the SAGE approach is that the programming is
> tedious and as you note bugs can be catastrophic. The good news is
> that it can get fantastic performance for lots of users.

I think the key word here is "can". TSO/360 was a performance dog. :-(

> It was
> invented for the SAGE missile defense system on tube computers in the
> 1950s, adapted for the SABRE airline reservation system on 7094s in
> the 1960s and has been used over and over, with the current trendy
> version being node.js. We now have better ways to describe
> continuations which make the programming a little easier, but it's
> still a tradeoff. IMS and CICS used the SAGE approach to provide good
> performance on specific applications.

Agreed. But the tradeoff with CICS (I don't know about IMS) was the
extra overhead of two levels of scheduling. I believe this is why it
was not useful for the highest performance systems that instead used ACP.

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

John Levine <johnl@taugh.com> schrieb:
> According to Thomas Koenig <tkoenig@netcologne.de>:
>>> I was not around, but my impression is that by time of creation of UNIX
>>> it was a common understanding. For example, DEC supplied RSX-11 with
>>> DCL at about the same time [as UNIX got Thompson shell) and I never
>>> heard that anybody considered it novel.
>>
>>The Thompson shell was still restricted to GOTO (as was the RSX-11
>>shell).
>
> You're probably thinking of the Mashey shell.

Disclaimer: I never worked on those old systems, my first UNIX
experience was with HP-UX in the late 1980s (where I accidentally
landed in vi and could not get out, but that's another story).

>One of the first usenix
> tapes has patches I wrote in about 1976 to add simple variables with
> single character names to that shell. It was an improvement, but the
> Bourne shell was way better.

https://grosskurth.ca/bib/1976/mashey-command.pdf (written by Mashey)
credits the original shell to Thompson, so I believe we are talking
about the same shell, just with different names.

> Re when this stuff was invented, I did some work on CP/67 when I was
> in high school in about 1970 and I recall that even then people
> routinely ran files of CMS commands. Don't remember whether there were
> variables and control flow or that came later with REXX.

Hmmm... I looked at

https://bitsavers.org/pdf/ibm/370/VM/370/Release_1/GX20-1926-1_VM_370_Quick_Guide_For_Users__Rel_1_Apr73.pdf

and found a reference to $LOOP and a reference to "tokens" (which I
suppose are variables), so that definitely predated the UNIX shells.

Michael S <already5chosen@yahoo.com> writes:

> On Mon, 06 May 2024 18:22:59 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> I don't buy it. An architecture is just a description of system
>> behavior, and surely there were descriptions of system behavior
>> before System/360. Even in the 1950s companies must have changed
>> implementations of a given model while still conforming to its
>> earlier description.
>
> Were they?
> My impression is that until S/360 there was no such thing as different
> by 100% SW compatible models.

I think a counterexample is the LGP-30 (1956) and its successor
the LGP-21 (1963). (For reference System/360 and OS/360 were
announced in April 1964.) I expect there are other examples
but it's hard to get the historical data needed to answer the
question. Another example may be the IBM 709 and IBM 7090, both
done in the 1950s.

Stephen Fuld <SFuld@alumni.cmu.edu.invalid> schrieb:
> Thomas Koenig wrote:

>> Only the team that made JCL, it seems.
>
>
> Just as an aside, though this thread may be somewhat OT, I consider it
> fun and interesting.
>
> I am not sure exactly what he is saying here. By JCL, does he mean
> just the syntax of the language,

His main criticism is that the design team failed to notice that
JCL was, in fact, a programming language, that the design team
thought of it as "just a few cards for job control". This led to
attributes such as DISP doing what he called "verbish things",
i.e. commands, dependence on card formats, a syntax similar to,
but incompatible with, the S/360 assembler, insufficient control
structures etc.

He did not criticize the OS itself too much, with its complicated
allocation stategies etc, mostly some remarks on the file structure
which he says could have been simplified.

Michael S <already5chosen@yahoo.com> schrieb:

> My impression is that until S/360 there was no such thing as different
> by 100% SW compatible models.

I think the important thing was that S/360 was designed and built,
right from the start, as a _series_ of compatible computers, which
were upward- and downward-compatible. They had the challenge
of designing an architecture where the instructions for the
high-end supercomputers still needed to work (although slowly)
on the low-end bread and butter machines, and what was efficient
on the low-end bread and butter machines should not constrain the
high-end supercomputers.

Most other computer series were built one at a time, with successors
usually extending the previous ones (which IBM also did with the /370,
series). The VAX may have been another such line - DEC did not release
several models all at once, but they did release the cheaper and slower
11/750 after they had released the 11/780.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> John Levine <johnl@taugh.com> writes:
>>
>>> Well, yes, but another 360 innovation was the whole idea of computer
>>> architecture, as well as the term. It was the first time that the
>>> programmer's view of the computer was described independently of any
>>> implementation.
>>
>> I don't buy it. An architecture is just a description of system
>> behavior, and surely there were descriptions of system behavior
>> before System/360. Even in the 1950s companies must have changed
>> implementations of a given model while still conforming to its
>> earlier description.
>
> Sure, the 7094 was a compatible successor of the 704,

I think a more accurate description is to say that the IBM 709 was
an upgraded version of the IBM 704, the IBM 7090 was a compatible
replacement for the 709, and the IBM 7094 was an upgraded version
of the 7090. In both cases the upgrades included changes. The
7094, for example, still had a three-bit field to select an index
register, but there were 7 index registers, not 3, only one of
which could be selected rather than OR-ing together all the index
registers whose bits were on. To be fair I should add that the
7094 could be run in a compatible mode where only 3 index registers
were used, with OR-ing like in the earlier models, but there were
other changes (or maybe only additions) as well. The 7094 may have
been upward compatible relative to the 7090, but it wasn't plug
compatible, and TTBOMU wasn't even upward compatible relative to
the 704.

> but the idea of
> implementation independence turns out to be much more profound than
> most people (probably including its inventors at the time) realized.

The point I was trying to make upthread (and whose significance seems
to have been missed by some people) is that the important lessons had
already been learned and understood -- by some key people at IBM,
although certainly not all -- before the System/360 effort started.
It isn't an accident that IBM decided to make an upward- and downward-
compatible family of computer models. That the System/360 effort
ended up producing a system description that is independent of any
particular model, and the benefits that accrue as a result, is simply
a consequence of that earlier and deeper understanding.

On Wed, 8 May 2024 10:03:51 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> Michael S <already5chosen@yahoo.com> schrieb:
>
> > My impression is that until S/360 there was no such thing as
> > different by 100% SW compatible models.
>
> I think the important thing was that S/360 was designed and built,
> right from the start, as a _series_ of compatible computers, which
> were upward- and downward-compatible. They had the challenge
> of designing an architecture where the instructions for the
> high-end supercomputers still needed to work (although slowly)
> on the low-end bread and butter machines, and what was efficient
> on the low-end bread and butter machines should not constrain the
> high-end supercomputers.
>

Of course, there is a theory and there is a practice.
In practice, downward compatibility lasted ~half a year, until Model 20.
Upward compatibility did not fare much better and was broken
approximately one year after initial release, in Model 67.
That is, if I didn't get upward and downward backward.

According to my understanding, since ~1970, IBM completely gave up on
all sorts of compatibility except backward compatibility. In more
recent decades it was further reduced to application-level backward
compatibility.

> Most other computer series were built one at a time, with successors
> usually extending the previous ones (which IBM also did with the /370,
> series). The VAX may have been another such line - DEC did not
> release several models all at once, but they did release the cheaper
> and slower 11/750 after they had released the 11/780.

I'd think that by 1977 (VAX) backward compatibility was widespread in
the industry.

John Levine <johnl@taugh.com> writes:
>According to Scott Lurndal <slp53@pacbell.net>:
>>>Wikipedia says that while S/360 and the B5500 were announced in 1964,
>>>the B3500 was announced in 1966. In the discussion of MCP on the B3500
>>
>>Sorry, I mean to imply that the B3500 (and successors) were 100% sw
>>compatible within the medium systems family.
>>
>>Likewise for the large systems (B5500) line. ...
>
>Oh, OK. In view of the timing, I'd guess that the people at Burroughs,
>who were certainly not dumb, looked at the S/360 material and figured
>oh, that's a good idea, we can do that too.

Note that it takes several years to design and build the
machine before first delivery. I'd say that Burroughs
didn't look at the S/360 material before developing
either family, rather the B3500 was a logical extension
of the B300 family and the B5500 was a logical extension
of the B5000.

Thomas Koenig <tkoenig@netcologne.de> writes:
>John Levine <johnl@taugh.com> schrieb:
>> According to Thomas Koenig <tkoenig@netcologne.de>:
>>>> I was not around, but my impression is that by time of creation of UNIX
>>>> it was a common understanding. For example, DEC supplied RSX-11 with
>>>> DCL at about the same time [as UNIX got Thompson shell) and I never
>>>> heard that anybody considered it novel.
>>>
>>>The Thompson shell was still restricted to GOTO (as was the RSX-11
>>>shell).
>>
>> You're probably thinking of the Mashey shell.
>
>Disclaimer: I never worked on those old systems, my first UNIX
>experience was with HP-UX in the late 1980s (where I accidentally
>landed in vi and could not get out, but that's another story).
>
>>One of the first usenix
>> tapes has patches I wrote in about 1976 to add simple variables with
>> single character names to that shell. It was an improvement, but the
>> Bourne shell was way better.
>
>https://grosskurth.ca/bib/1976/mashey-command.pdf (written by Mashey)
>credits the original shell to Thompson, so I believe we are talking
>about the same shell, just with different names.
>
>> Re when this stuff was invented, I did some work on CP/67 when I was
>> in high school in about 1970 and I recall that even then people
>> routinely ran files of CMS commands. Don't remember whether there were
>> variables and control flow or that came later with REXX.
>
>Hmmm... I looked at
>
>https://bitsavers.org/pdf/ibm/370/VM/370/Release_1/GX20-1926-1_VM_370_Quick_Guide_For_Users__Rel_1_Apr73.pdf
>
>and found a reference to $LOOP and a reference to "tokens" (which I
>suppose are variables), so that definitely predated the UNIX shells.

Burroughs had something called WFL (WorkFlow Language) that was
effectively a compiler for a shell-like language.

Thomas Koenig wrote:

> Stephen Fuld <SFuld@alumni.cmu.edu.invalid> schrieb:
> > Thomas Koenig wrote:
>
> >> Only the team that made JCL, it seems.
> >
> >
> > Just as an aside, though this thread may be somewhat OT, I consider
> > it fun and interesting.
> >
> > I am not sure exactly what he is saying here. By JCL, does he mean
> > just the syntax of the language,
>
> His main criticism is that the design team failed to notice that
> JCL was, in fact, a programming language, that the design team
> thought of it as "just a few cards for job control". This led to
> attributes such as DISP doing what he called "verbish things",
> i.e. commands, dependence on card formats, a syntax similar to,
> but incompatible with, the S/360 assembler, insufficient control
> structures etc.
>
> He did not criticize the OS itself too much, with its complicated
> allocation stategies etc, mostly some remarks on the file structure
> which he says could have been simplified.

Thank you Thomas. That clarifies it. As must be clear by now, I agree
with him about the syntax, etc., my criticisms go much deeper.

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

John Levine <johnl@taugh.com> writes:
> According to MitchAlsup1 <mitchalsup@aol.com>:
>>> TSS was a disaster due to an extreme case of second system syndrome,
>>> but Michigan's MTS and IBM skunkworks CP/67 worked great.
>>
>>TSS at CMU was extensively rewritten in assembly and became quite
>>tolerable--hosting 30+ interactive jobs along with a background
>>batch processing system. When I arrived in Sept 1975 it was quite
>>unstable with up times less than 1 hour. 2 years later it would run
>>for weeks at a time without going down.
>
> For reasons I do not want to try to guess, AT&T did the software
> development for the 5ESS phone switches in a Unix system that sat on
> top of TSS. After IBM cancelled TSS, AT&T continued to use it as some
> sort of special order thing. At IBM there were only a handful of
> programmers working on it, by that time all quite experienced, and I
> hear that they also got rid of a lot of cruft and made it much faster
> and more reliable.
>
> At the same time, IBM turned the skunkworks CP/67 into VM/370 with a
> much larger staff, leading to predictable consequences.

TSS/360 was decommitted and group reduced from 1100 to 20. Morph of
TSS/360 to TSS/370 was much better (with only 20 people).

Both Amdahl and IBM hardware field support claimed they wouldn't support
370 machines w/o industrial strength EREP. The effort to add industrial
strength EREP to UNIX was many times the effort to do 370 port. They did
a stripped down TSS/370 with just hardware layer and EREP (called SSUP)
with UNIX built on top. IBM AIX/370 and Amdahl UTS were run in VM/370
virtual machines ... leveraging VM/370 industrial EREP.

CP/40 was done on 360/40 with virtual memory hardware mods; it morphs
into CP/67 when 360/67 standard with virtual memory became available.
Group had 11 people (1/100th TSS/360).

When I graduate and join IBM, one of my hobbies was enhanced production
operating systems for internal datacenters. With the decision to
add virtual memory to all 370s, it was decided to do VM/370 and some
of the science center people move to the 3rd flr taking over the
IBM Boston Programming Center for VM/370 group. The group was
expanding to 200+ and outgrew the 3rd flr, moving to the vacant IBM SBS
bldg out in Burlington Mall (of rt128).

Note the morph of CP67->VM370 dropped and/or simplified a bunch of
features (including multiprocessor support). In 1974, I started
migrating a bunch of CP67 stuff to VM370 R2. I had also done automated
benchmarking system and was the the 1st thing I migrated ... however,
VM370 couldn't complete a full set of benchmarks w/o crashing ... so the
next thing I had to migrate was the CP67 kernel synchronization &
serialization function ... it order for VM370 to complete benchmark
series. Then I started migrating a bunch of my enhancements.

For some reason AT&T longlines got an early version of my production
VM370 CSC/VM (before the multiprocessor support) ... and over the years
moved it to latest IBM 370s and propogated around to other
locations. Then comes the early 80s when next new IBM was 3081 ... which
was originally a multiprocessor only machine. The IBM corporate
marketing rep for AT&T tracks me down to ask for help with retrofitting
multiprocessor support to old CSC/VM ... concern was that all those AT&T
machines would migrate to the latest Amdahl single processor (which had
about the same processing as aggregate of the 3081 two processor).

--
virtualization experience starting Jan1968, online at home since Mar1970

According to Michael S <already5chosen@yahoo.com>:
>Of course, there is a theory and there is a practice.
>In practice, downward compatibility lasted ~half a year, until Model 20.
>Upward compatibility did not fare much better and was broken
>approximately one year after initial release, in Model 67.
>That is, if I didn't get upward and downward backward.

The 360/22, /25, /30, /40, /50, /65, /75, and /85 were all compatible
implementations of S/360. You could write a program that ran on any of
them, and it would also run on larger and smaller models.

The /20, /44, and /67 were each for special markets. The /20 was
basically for people who still wanted a 1401 (admittedly a pretty big
market), the /44 for realtime, and the /67 for a handful of
time-sharing customers. The /67 was close enough to a /65 that you
could use it as one, often /67 timesharing during the day, and /65
batch overnight. The /91 and /95 were also compatible except that the
/91 left out decimal arithmetic, which OS/360 would trap and slowly
emulate if need be.

>According to my understanding, since ~1970, IBM completely gave up on
>all sorts of compatibility except backward compatibility.

No. When hey updated the architecture and then shipped multiple
implementations of each one. So when they went to S/370, there was the
370/115, /125, /135, /138, /145, /148, /158, and /168 which were
upward and downward compatible as were the 303x and 434x series. The
/155 and /165 were originally missing the paging hardware but later
could be field upgraded.

The point here is that you could write a program for any model, and
you could expect it to work unmodified on both larger and smaller
models. Later one there was S/390 and zSeries, again each with models
that were both upward and downward compatible.

>I'd think that by 1977 (VAX) backward compatibility was widespread in
>the industry.

More like 1957. The IBM 705 was mostly backward compatible with the
702, and the 709 with the 704. But only in one direction -- if you
wanted your 709 program to work on a 704, you had to be careful not to
use any of the new 709 stuff, and since the I/O was completely
different, you needed suitable operating systems or at least I/O
libraries.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Lynn Wheeler wrote:
>
> For some reason AT&T longlines got an early version of my production
> VM370 CSC/VM (before the multiprocessor support) ... and over the years
> moved it to latest IBM 370s and propogated around to other
> locations. Then comes the early 80s when next new IBM was 3081 ... which
> was originally a multiprocessor only machine. The IBM corporate
> marketing rep for AT&T tracks me down to ask for help with retrofitting
> multiprocessor support to old CSC/VM ... concern was that all those AT&T
> machines would migrate to the latest Amdahl single processor (which had
> about the same processing as aggregate of the 3081 two processor).

Regarding retrofitting multiprocessor support to old CSC/VM,
by which I take it you mean adding SMP support to a uni-processor OS,
do you remember what changes that entailed? Presumably a lot more than
acquiring one big spinlock every time the OS was entered.
That seems like a lot of work for one person.

According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>> With sufficiently disciplined programming, you could swap and move data
>> by updating the base registers. APL\360 did this quite successfully
>> and handled a lot of interactive users on a 360/50.
>
>Wasn't APL\360 an interpreter? If so, then moving instructions and data
>around was considerably simpler.

That's right. It could switch between users at well defined points that
made it practical to update the base registers pointing to the user's workspace.

>> Reading between the lines in the IBMSJ architecture paper, I get the
>> impression they believed that moving code and data with base registers
>> would be a lot easier than it was, and missed the facts that a lot of
>> pointers are stored in memory, and it is hard to know what registers
>> are being used as base registers when.
>
>Interesting. That would seem to imply that it wasn't that they didn't
>think about the problems that base addressing would cause, they just
>(vastly) underestimated the cost of fixing it. A different "design"
>problem indeed.

In Design of Design, Brooks said they knew about virtual memory but thought
it was too expensive, which he also says was a mistake, soon fixed in S/370.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

EricP <ThatWouldBeTelling@thevillage.com> writes:
> Lynn Wheeler wrote:
>> For some reason AT&T longlines got an early version of my production
>> VM370 CSC/VM (before the multiprocessor support) ... and over the years
>> moved it to latest IBM 370s and propogated around to other
>> locations. Then comes the early 80s when next new IBM was 3081 ... which
>> was originally a multiprocessor only machine. The IBM corporate
>> marketing rep for AT&T tracks me down to ask for help with retrofitting
>> multiprocessor support to old CSC/VM ... concern was that all those AT&T
>> machines would migrate to the latest Amdahl single processor (which had
>> about the same processing as aggregate of the 3081 two processor).
>
> Regarding retrofitting multiprocessor support to old CSC/VM,
> by which I take it you mean adding SMP support to a uni-processor OS,
> do you remember what changes that entailed? Presumably a lot more than
> acquiring one big spinlock every time the OS was entered.
> That seems like a lot of work for one person.

Charlie had invented compare&swap (for his initials CAS) when he was
doing fine-grain CP/67 multiprocessor locking at the science center
.... when presented to the 370 architecture owners for adding to 370
.... they said that the POK favorite son operating system (OS/360
MVT/MVS) owners that 360/67 test&set was sufficient (i.e. they had a big
kernel spin-lock) ... this also accounted for MVS documentation saying
that two-processor support only had 1.2-1.5 times the throughput of
single processor.

I had initially done the multiprocessor kernel re-org for VM/370 for
VM/370 Release2 based CSC/VM ... but not the actual multiprocessor
support. The internal world-wide sales&marketing support HONE systems
were long time customer for my enhanced CSC/VMs and then the US HONE
datacenters were consolidated in silicon valley (trivia: when facebook
1st moves moves into silicon valley, it was into a new bldg built next
door to the former US HONE consolidated datacenter). They had added
"loosely-coupled" shared DASD support to complex of eight large systems
with load-balancing and fall-over. I then added SMP, tightly-coupled,
multiprocessor to VM/370 Release3 based CSC/VM so they could add a 2nd
processor to each system (for 16 processors total). Their two processor
systems were getting twice the throughput of single processor ... a
combination of very low overhead SMP, tightly-coupled, multiprocessor
locking support and a hack for cache affinity that improved the cache
hit ratio (with faster processing offsetting the multiprocessor
overhead).

The VM/370 SMP, tightly-coupled, multiprocessor locking was rather
modest amount of work ... compared to all the other stuff I was doing.

trivia: The future system stuff (to replace all 370) was going on during
much of this period. When FS implodes there was mad rush to stuff back
into the 370 product pipelines, including kicking off quick&dirty 3033
and 3081 in parallel
http://www.jfsowa.com/computer/memo125.htm

about the same time, I'm roped into helping with a 16-processor
tightly-coupled 370 effort and we con the 3033 processor engineers to
work on it in their spare time (a lot more interesting than remapping
168 logic to 20% faster chips) ... everybody thot it was great until
somebody tells the head of POK that it could be decades before the POK
favorite son operating system had (effective) 16-processor support (aka
their spin-lock, POK doesn't ship 16-processor SMP until after the turn
of century). Then the head of POK invites some of us to never visit POK
again. The head of POK also manages to convince corporate to kill the
VM370 product, shutdown the development group and transfer all the
people to POK for MVS/XA (supposedly otherwise they wouldn't be able to
ship MVS/XA on time) ... Endicott eventually manages to save the VM370
product mission for the low&midrange ... but have to recreate a VM370
development group from scratch.

I then transfer out to west coast and get to wander around (both IBM &
non-IBM) datacenters in silicon valley, including disk engineering
(bldg14) and disk product test (bldg15) across the street. At the time
they are running prescheduled, 7x24, stand-alone testing ... and had
recently tried MVS but it had 15min mean-time-between failure (in that
environment, lots of faulty hardware). I offer to rewrite the I/O
supervisor to make it bullet-proof and never fail so they can have any
amount of on-demand testing, greatly improving productivity (downside
any time they have problems, they imply its my software and I have to
spend increasing time playing disk engineering diagnosing their hardware
problems). I do a (internal only) San Jose Reseach report on the I/O
Integrity work and happen to mention the MVS 15min MTBF, bringing down
the wrath of the MVS organization on my head.

--
virtualization experience starting Jan1968, online at home since Mar1970

John Levine <johnl@taugh.com> writes:
> implementations of each one. So when they went to S/370, there was the
> 370/115, /125, /135, /138, /145, /148, /158, and /168 which were
> upward and downward compatible as were the 303x and 434x series. The
> /155 and /165 were originally missing the paging hardware but later
> could be field upgraded.

shortly after joining IBM I get con'ed into helping 370/195 to add
multi-threading; 195 pipeline didn't have branch prediction, speculative
execution, etc ... so conditional branches drained the pipeline ... and
most codes only ran at half rate. Multi-thread would simulate two
processor operation ... and two i-streams running at half rate might
keep aggregate 195 throughput much higher (modulo the OS360 MVT
multiprocessor support only having 1.2-1.5 throughput of single
processor).

little over decade ago I was asked to track down decision to add virtual
memory to all 370s and found staff to executive making the
decision. Basically OS/360 MVT storage management was so bad, the
execution regions had to be specified four times larger than used, as a
result a 1mbyte 370/165 normally would only run four regions
concurrently, insufficient to keep system busy and justified. Mapping
MVT to a 16mbye virtual address space (aka VS2/SVS) would allow
increasing number of concurrently running regions by factor of four
times (with little or no paging), keeping 165 systems busy
.... overlapping execution with disk I/O.

I had gotten into something of a dustup with VS2/SVS, claiming their
page replacement algorithm was making poor choices ... they eventually
fell back to since they were expecting nearly negligible paging rates,
it wouldn't make any difference.

Along the way, 370/165 engineers said that if they had to retrofit the
full 370 virtual memory architecture ... it would slip the announcement
date by six months ... so decision was made to drop features ... and all
the other systems had to retrench to the 165 subset ... and any software
dependent on the dropped features had to be reworked. For VM/370, they
were planning on using R/O shared segment protection (one of the
features dropped for 370/165) for sharing CMS pages ... and so had to
substitute a real kludge. Also the 370/195 multi-threading was canceled
.... since it was deamed to difficult to upgrade 195 for virtual memory.

Amdahl had won the battle to make ACS, 360 compatible ... folklore is
that executives then killed ACS/360 because it would advance the
state-of-the-art too fast and IBM could loose control of the market
(Amdahl leaves IBM shortly later)
https://people.computing.clemson.edu/~mark/acs_end.html
.... above also has multi-threading reference.

--
virtualization experience starting Jan1968, online at home since Mar1970

According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
>> My impression is that until S/360 there was no such thing as different
>> by 100% SW compatible models.
>
>I think a counterexample is the LGP-30 (1956) and its successor
>the LGP-21 (1963).

They were pretty close but it says on the intertubes that the -30 put
memory words 9 apart on the drum and the -21 put them 18 apart, which
I presume means that you would need to arrange your data differently
to get good performance.

>Another example may be the IBM 709 and IBM 7090, both done in the 1950s.

They were pretty similar but the 7090 had a more complex channel and
new instructions to manage it. There was a trap mode that caught the
old I/O instructions they used to run 704 or 709 coe on a 7090 but of
course not vice versa.

Compare that to S/360 where every model had the same channel
interface, the same I/O instructions, and the same I/O interrupts.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine wrote:

> According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
> >> With sufficiently disciplined programming, you could swap and move
> data >> by updating the base registers. APL\360 did this quite
> successfully >> and handled a lot of interactive users on a 360/50.
> >
> > Wasn't APL\360 an interpreter? If so, then moving instructions and
> > data around was considerably simpler.
>
> That's right. It could switch between users at well defined points
> that made it practical to update the base registers pointing to the
> user's workspace.
>
> >> Reading between the lines in the IBMSJ architecture paper, I get
> the >> impression they believed that moving code and data with base
> registers >> would be a lot easier than it was, and missed the facts
> that a lot of >> pointers are stored in memory, and it is hard to
> know what registers >> are being used as base registers when.
> >
> > Interesting. That would seem to imply that it wasn't that they
> > didn't think about the problems that base addressing would cause,
> > they just (vastly) underestimated the cost of fixing it. A
> > different "design" problem indeed.
>
> In Design of Design, Brooks said they knew about virtual memory but
> thought it was too expensive, which he also says was a mistake, soon
> fixed in S/370.

While I agree that virtual memory was probably too expensive in the mid
1960s, I disagree that it was required, or even the optimal solution
back then. A better solution would have been to have a small number of
"base registers" that were not part of the user set, but could be
reloaded by the OS whenever a program needed to be swapped in to a
different address than it was swapped out to.

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

On Wed, 8 May 2024 20:30:17 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

> According to Michael S <already5chosen@yahoo.com>:
> >Of course, there is a theory and there is a practice.
> >In practice, downward compatibility lasted ~half a year, until Model
> >20. Upward compatibility did not fare much better and was broken
> >approximately one year after initial release, in Model 67.
> >That is, if I didn't get upward and downward backward.
>
> The 360/22, /25, /30, /40, /50, /65, /75, and /85 were all compatible
> implementations of S/360. You could write a program that ran on any of
> them, and it would also run on larger and smaller models.
>
> The /20, /44, and /67 were each for special markets. The /20 was
> basically for people who still wanted a 1401 (admittedly a pretty big
> market), the /44 for realtime, and the /67 for a handful of
> time-sharing customers. The /67 was close enough to a /65 that you
> could use it as one, often /67 timesharing during the day, and /65
> batch overnight.

But programs (or OSes) that utilize the features of /67 would not run
on anything else, right?

> The /91 and /95 were also compatible except that the
> /91 left out decimal arithmetic, which OS/360 would trap and slowly
> emulate if need be.
>

How about programs that depend on precise floating-point exceptions?

> >According to my understanding, since ~1970, IBM completely gave up on
> >all sorts of compatibility except backward compatibility.
>
> No. When hey updated the architecture and then shipped multiple
> implementations of each one. So when they went to S/370, there was the
> 370/115, /125, /135, /138, /145, /148, /158, and /168 which were
> upward and downward compatible as were the 303x and 434x series. The
> /155 and /165 were originally missing the paging hardware but later
> could be field upgraded.
>

What about various vector facilities that they were adding and removing
seemingly at random during 1970s and 1980s ?
My impression was that absence vector facilities were not emulated. Is
it wrong?

> The point here is that you could write a program for any model, and
> you could expect it to work unmodified on both larger and smaller
> models. Later one there was S/390 and zSeries, again each with models
> that were both upward and downward compatible.
>
> >I'd think that by 1977 (VAX) backward compatibility was widespread in
> >the industry.
>
> More like 1957. The IBM 705 was mostly backward compatible with the
> 702, and the 709 with the 704. But only in one direction

"One direction" is synonymous with "backward compatible", is it not?
But the word "mostly" is suspect.

>> -- if you
> wanted your 709 program to work on a 704, you had to be careful not to
> use any of the new 709 stuff, and since the I/O was completely
> different, you needed suitable operating systems or at least I/O
> libraries.

Can you, please, define the meaning of upward and downward
compatibility? I had never seen this terms before this thread, so it is
possible that I don't understand the meaning.

Michael S <already5chosen@yahoo.com> schrieb:

> Can you, please, define the meaning of upward and downward
> compatibility? I had never seen this terms before this thread, so it is
> possible that I don't understand the meaning.

The term comes from Brooks. Specifically, he applied it to the
S/360 line of computers which had a very wide performance and
price range, and programs (including operating systems) were
binary compatible from the lowest to the highest performance and
price machine.

On Thu, 9 May 2024 08:19:39 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> Michael S <already5chosen@yahoo.com> schrieb:
>
> > Can you, please, define the meaning of upward and downward
> > compatibility? I had never seen this terms before this thread, so
> > it is possible that I don't understand the meaning.
>
> The term comes from Brooks. Specifically, he applied it to the
> S/360 line of computers which had a very wide performance and
> price range, and programs (including operating systems) were
> binary compatible from the lowest to the highest performance and
> price machine.

I suppose, it means that my old home PC (Core-i5 3550) is downward
compatible with my old work PC (Core-i7 3770). And my old work PC is
upward compatible with my old home PC.

But I still don't know if it would be correct to say that my old work
PC is downward compatible with with my just a little newer small FOGA
development server (E3 1271 v3). My guess that it would be incorrect,
but it's just guess.

If Brook was still alive, we could have tried to ask him. But since he
is not, and since I have no plans to read his books by myself, my only
chance of knowing is for you or for John Levine to find the definition
it in his writings and then tell me.

Michael S <already5chosen@yahoo.com> writes:
>On Thu, 9 May 2024 08:19:39 -0000 (UTC)
>> The term comes from Brooks. Specifically, he applied it to the
>> S/360 line of computers which had a very wide performance and
>> price range, and programs (including operating systems) were
>> binary compatible from the lowest to the highest performance and
>> price machine.
>
>
>I suppose, it means that my old home PC (Core-i5 3550) is downward
>compatible with my old work PC (Core-i7 3770). And my old work PC is
>upward compatible with my old home PC.

Given that both use Ivy Bridge CPUs, there is no compatibility issue
as far as the CPU is concerned. For other parts of the PCs, one would
have to discuss everything separately.

When it comes to upwards/downwards, you would have to compare with
Saltwell or Silvermont. Ivy Bridge supports AVX, while Saltwell and
Silvermont don't.

AMD is somewhat better at these things: They added AVX support to
their small cores in 2013 (Jaguar) and their big cores in 2011
(Bulldozer), while Intel added AVX to their small cores in 2021
(Gracemont) and to their big cores in 2011 (Sandy Bridge).

For AVX2, AMD added it to their big cores in 2015 (Excavator), but by
that time they had given up on the two-pronged approach and were on
the way to the one-size-fits-all Zen line.

>But I still don't know if it would be correct to say that my old work
>PC is downward compatible with with my just a little newer small FOGA
>development server (E3 1271 v3).

Haswell is a successor to Ivy Bridge and supports AVX2 (unlike Ivy
Bridge). So it's an unidirectional compatibility.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Michael S wrote:

> On Thu, 9 May 2024 08:19:39 -0000 (UTC)
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>
> > Michael S <already5chosen@yahoo.com> schrieb:
> >
> > > Can you, please, define the meaning of upward and downward
> > > compatibility? I had never seen this terms before this thread, so
> > > it is possible that I don't understand the meaning.
> >
> > The term comes from Brooks. Specifically, he applied it to the
> > S/360 line of computers which had a very wide performance and
> > price range, and programs (including operating systems) were
> > binary compatible from the lowest to the highest performance and
> > price machine.
>
>
> I suppose, it means that my old home PC (Core-i5 3550) is downward
> compatible with my old work PC (Core-i7 3770). And my old work PC is
> upward compatible with my old home PC.
>
> But I still don't know if it would be correct to say that my old work
> PC is downward compatible with with my just a little newer small FOGA
> development server (E3 1271 v3). My guess that it would be incorrect,
> but it's just guess.
>
> If Brook was still alive, we could have tried to ask him. But since he
> is not, and since I have no plans to read his books by myself, my only
> chance of knowing is for you or for John Levine to find the
> definition it in his writings and then tell me.

Perhaps this interpretation will help clear things up. Think of
compatibility as a two dimensional graph. On the Y axis is some
measure of compute power. The X axis is time. So upward/downward
compatibility is among models announced at the same time and delivered
within a small time of each other. Backward compatibility is along the
X axis, that is, between models announced/delivered at a different
points in time. So under this scheme, the S/360 model 30 was upward
compatible with the model /65 ( different Y values, but the same x
values) , but the S370s (not counting the /155 and /165) were backward
compatible with the S/260 models (different x values)

The key innovation that IBM made with the S/360 was to announce systems
with a wide range of performance *at the same time*, i.e. different Y
values and the same X value.

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