I've just read (most of) "The Design of Design" by Fred Brooks,
especially the chapters dealing with the design of the /360,
and it's certainly worth reading. (I had finished "The Mythical
Man-Month" before). There are chapters on computer and software
architectures, but also something on a house he himself built.

An interesting detail about the /360 design was that they originally
wanted to do a stack-based machine. It would have been OK for the
mid- and high-end machines, but on low-end machines it would have
been undompetetive, so they rejected that approach.

He discusses the book on computer architecture he co-authored with
Gerrit Blaauw in it (as a project). Would be _very_ nice to read,
but the price on Amazon is somewhat steep, a bit more than 150 Euros.

One thing about Brooks - he is not shy of criticizing his own
works when his views changed. I liked his scathing comments on JCL
so much that I put them in the Wikipedia article :-)

His main criticism of his own book on computer architecture was
that it treated computer architecture as a finite field which had
been explored already.

@John S: Not sure if you've read "The Design of Design", but if you
haven't, you probably should. It might help you to refocus in your
quest to recreate a S/360 (especially the requirement to get the
architecture to work well on a very small machine like the 360/30).

Soo... good to read. Anything else?

It appears that Thomas Koenig <tkoenig@netcologne.de> said:
>An interesting detail about the /360 design was that they originally
>wanted to do a stack-based machine. It would have been OK for the
>mid- and high-end machines, but on low-end machines it would have
>been undompetetive, so they rejected that approach.

The 1964 IBM Systems Journal paper has half a page on that. They felt
it would be about as good for scientific machines, worse for commercial.
Stack machines have more compact instructions due to zero-address, but
they need more instructions to move stuff around in the stack so that
was a wash, and the performance depends on how much of the stack it
can keep in fast memory.

The 360 had way more registers than any previous IBM machine. The 7094
had accumulator, MQ, and 7 half length index registers. STRETCH had an
overcomplex architecture with 7 fast registers, mostly special
purpose. Some of the commercial machines had an odd circular store
treated as some number of variable length registers.

They had the insight to see that the 16 fixed sizs registers could be
in fast storage on high end machines, main memory on low end machines,
so the high end machines were fast and the low end no slower than a
memory-memory architecture which is what it in practice was. It was
really an amazing design, no wonder it's the only architecture of its
era that still has hardware implementations.

>He discusses the book on computer architecture he co-authored with
>Gerrit Blaauw in it (as a project). Would be _very_ nice to read,
>but the price on Amazon is somewhat steep, a bit more than 150 Euros.

I have a copy. The first half is the textbook, which is pretty good.
The second half is descriptions and evaluations of 30 architectures from
Babbage and the Mark I to the 6502 and 68000, which are great.

I see a used copy here for $105 which is what textbooks cost these days:

https://www.valore.com/textbooks/computer-architecture-concepts-and-evolution-1stth-edition/0201105578

--
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 <johnl@taugh.com> schrieb:

> They had the insight to see that the 16 fixed sizs registers could be
> in fast storage on high end machines, main memory on low end machines,
> so the high end machines were fast and the low end no slower than a
> memory-memory architecture which is what it in practice was. It was
> really an amazing design, no wonder it's the only architecture of its
> era that still has hardware implementations.

And they are making good money on it, too.

Prompted by a remark in another newsgroup, I looked at IBM's 2023
annual report, where zSystems is put under "Hybrid Infrastructure"
(lumped together with POWER). The revenue for both lumped together
is around 9,215 billion Dollars, with a pre-tax margin of more
than 50%.

At those margins, they can certainly pay for a development team
for future hardware generations.

Thomas Koenig wrote:

> John Levine <johnl@taugh.com> schrieb:
>
> > They had the insight to see that the 16 fixed sizs registers could
> > be in fast storage on high end machines, main memory on low end
> > machines, so the high end machines were fast and the low end no
> > slower than a memory-memory architecture which is what it in
> > practice was. It was really an amazing design, no wonder it's the
> > only architecture of its era that still has hardware
> > implementations.

Yes, although it isn't clear how much of its success is due to
technical superiority versus marketing superiority.

>
> And they are making good money on it, too.
>
> Prompted by a remark in another newsgroup, I looked at IBM's 2023
> annual report, where zSystems is put under "Hybrid Infrastructure"
> (lumped together with POWER). The revenue for both lumped together
> is around 9,215 billion Dollars, with a pre-tax margin of more
> than 50%.
>
> At those margins, they can certainly pay for a development team
> for future hardware generations.

Yes, but remember that includes softwre revenue, which has higher
margins than hardware revenue. I believe I saw somewhere that IBM made
more from MVS, DB2, CICS, etc. than they do on the hardware itself. So
one could argue that they have to develop mew hardware in order to
protect their software revenue!

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

According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
>Thomas Koenig wrote:
>
>> John Levine <johnl@taugh.com> schrieb:
>>
>> > They had the insight to see that the 16 fixed sizs registers could
>> > be in fast storage on high end machines, main memory on low end
>> > machines, so the high end machines were fast and the low end no
>> > slower than a memory-memory architecture which is what it in
>> > practice was. It was really an amazing design, no wonder it's the
>> > only architecture of its era that still has hardware
>> > implementations.
>
>Yes, although it isn't clear how much of its success is due to
>technical superiority versus marketing superiority.

S/360 invented eight bit byte addressed memory with larger power of 2
data sizes, which I think all by itself is enough to explain why it
survived. All the others, which were word or maybe decimal digit
addressed, died. Its addresses could handle 16MB which without too
many contortions was expanded to 2GB, a lot more than any other design
of the era. We all know that the thing that kills architectures is
running out of address space.

I thought the PDP-10 was swell, but even if DEC had been able to
design and ship the Jupiter follow-on to the KL-10, its expanded
addressing was a kludge. It only provided addressing 8M words or about
32M bytes with no way to go past that.

--
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>:
>>Thomas Koenig wrote:
>>
>>> John Levine <johnl@taugh.com> schrieb:
>>>
>>> > They had the insight to see that the 16 fixed sizs registers could
>>> > be in fast storage on high end machines, main memory on low end
>>> > machines, so the high end machines were fast and the low end no
>>> > slower than a memory-memory architecture which is what it in
>>> > practice was. It was really an amazing design, no wonder it's the
>>> > only architecture of its era that still has hardware
>>> > implementations.
>>
>>Yes, although it isn't clear how much of its success is due to
>>technical superiority versus marketing superiority.

> S/360 invented eight bit byte addressed memory with larger power of 2
> data sizes, which I think all by itself is enough to explain why it
> survived. All the others, which were word or maybe decimal digit
> addressed, died. Its addresses could handle 16MB which without too
> many contortions was expanded to 2GB, a lot more than any other design
> of the era. We all know that the thing that kills architectures is
> running out of address space.

Note to self:: when designing a 36-bit machine, do not cripple it
with 18-bit addresses with inherent indirection....

> I thought the PDP-10 was swell, but even if DEC had been able to
> design and ship the Jupiter follow-on to the KL-10, its expanded
> addressing was a kludge. It only provided addressing 8M words or about
> 32M bytes with no way to go past that.

According to MitchAlsup1 <mitchalsup@aol.com>:
>> S/360 invented eight bit byte addressed memory with larger power of 2
>> data sizes, which I think all by itself is enough to explain why it
>> survived. All the others, which were word or maybe decimal digit
>> addressed, died. Its addresses could handle 16MB which without too
>> many contortions was expanded to 2GB, a lot more than any other design
>> of the era. We all know that the thing that kills architectures is
>> running out of address space.
>
>Note to self:: when designing a 36-bit machine, do not cripple it
>with 18-bit addresses with inherent indirection....

In fairness, in 1963 when the PDP-6 was designed, 256K words seemed
like an enormous amount of memory. A 7094 could only address 32K. Even
with that limit, PDP-10 series lasted until 1983. Twenty years was a
pretty good run.

When it was new, S/360 was considered a memory hog. When they realized
that OS/360 needed 64K to run and a lot more to run well, they quickly
came up with DOS and TOS that ran in 16K and a minimal BOS that ran in
8K. In retrospect we know that memory prices dropped quickly and the
big address space was a good idea, but it was a gamble at the time.
--
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 <johnl@taugh.com> schrieb:

> S/360 invented eight bit byte addressed memory with larger power of 2
> data sizes, which I think all by itself is enough to explain why it
> survived. All the others, which were word or maybe decimal digit
> addressed, died. Its addresses could handle 16MB which without too
> many contortions was expanded to 2GB, a lot more than any other design
> of the era. We all know that the thing that kills architectures is
> running out of address space.

Brooks wrote that the design was supposed to have been 32-bit
clean from the start, but that the people who implemented the BALR
instruction (which puts some bits of the PSW into the high-value
byte) didn't follow that guideline. He blamed himself for not making
that sufficiently clear to all the design team.

He also commented on the carefully-designed gaps in the opcode space;
extensibility was designed in from the beginning. @John S: Another
important point about S/360 you might want to follow, as Mitch
keeps telling you...

> I thought the PDP-10 was swell, but even if DEC had been able to
> design and ship the Jupiter follow-on to the KL-10, its expanded
> addressing was a kludge. It only provided addressing 8M words or about
> 32M bytes with no way to go past that.

Reading

http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp10/KC10_Jupiter/ExtendedAddressing_Jul83.pdf

I concur that it was a kludge, but at least they seem to have
allowed for further extension by reserving a 1-1- bit pattern,
as an illegal indirect word.

However, one questions. Designs like the PDP-10 or the UNIVAC
(from what I read on Wikipedia) had "registers" at certain
memory locations. On the PDP-10, it even appears to have been
possible to run code in the first memory locations/registers.

It seems that the /360 was the first machine which put many
registers into a (conceptually) separate space, leaving them open
to implementing them either in memory or as faster logic.

Is that the case, or did anybody beat them to it?

John Levine wrote:

> According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
> > Thomas Koenig wrote:
> >
> >> John Levine <johnl@taugh.com> schrieb:
> >>
> >> > They had the insight to see that the 16 fixed sizs registers
> could >> > be in fast storage on high end machines, main memory on
> low end >> > machines, so the high end machines were fast and the low
> end no >> > slower than a memory-memory architecture which is what it
> in >> > practice was. It was really an amazing design, no wonder it's
> the >> > only architecture of its era that still has hardware
> >> > implementations.
> >
> > Yes, although it isn't clear how much of its success is due to
> > technical superiority versus marketing superiority.
>
> S/360 invented eight bit byte addressed memory with larger power of 2
> data sizes, which I think all by itself is enough to explain why it
> survived.

Of cpurse, I agree about IBM inventing the 8 bit byte (although the
Burroughs large scale systems used it too), and the power of two data
sizes (although the Univac 1108 and successots sort of had that with
quarter word, half word word and doube word data sizes). While
important, I am not sure about succfient.

I do want to note that another factor in S/360's success was the
quality of the paper peripherals, expecially the 1401 printer, which
was a true marvel in its time. IBM got that advantage from their long
experience with punch card business systems.

All the others, which were word or maybe decimal digit
> addressed, died. Its addresses could handle 16MB which without too
> many contortions was expanded to 2GB, a lot more than any other design
> of the era. We all know that the thing that kills architectures is
> running out of address space.

The Univac 1110 (circa 1972), (about a devcade before XA) had banking,
which allowed an instruction to address anywhere within a 262K
(approximately 1 MB) "window" into what could be an "address space" of
about 4 GB. It was a little awkward in that, while you could have 4 of
such "windows" available at any time, changing windows required
executing an, (unprivlidged) instruction.

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

Thomas Koenig wrote:

snip
>
> However, one questions. Designs like the PDP-10 or the UNIVAC
> (from what I read on Wikipedia) had "registers" at certain
> memory locations.

Univac reserved the first 0200 locations of the user's address space as
"aliases" of the registers. This is because the instruction format
only had room for one arithmetic register and one indes (address)
register. Thus to, for example, load one register with the contents of
another, you put the source register's address in the displacement
field. But physically, the regoisters were separate.

In fact, on the 1108, since the first 0200 memory locations weren't
diretly usable by the software, they were reserved such that upon a
system power loss, the actual CPU registers were saved into those (core
- hence non-volatile) memory locations so at least in theory, you could
recover from a power loss. It didn't work very well.

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

According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
>I do want to note that another factor in S/360's success was the
>quality of the paper peripherals, expecially the 1401 printer, which
>was a true marvel in its time. IBM got that advantage from their long
>experience with punch card business systems.

I presume you mean the 1403 which was indeed a great printer. I printed a
lot of term papers on them.

> All the others, which were word or maybe decimal digit
>> addressed, died. ...

>The Univac 1110 (circa 1972), (about a devcade before XA) had banking,
>which allowed an instruction to address anywhere within a 262K
>(approximately 1 MB) "window" into what could be an "address space" of
>about 4 GB. It was a little awkward in that, while you could have 4 of
>such "windows" available at any time, changing windows required
>executing an, (unprivlidged) instruction.

There were a lot of segmented address schemes and as far as I can tell
nobody liked them except maybe the Burroughs machines where the
compilers made it largely invisible. The most famous was the 8086 and
286 but the PDP-10 extended addressing was sort of like that and even
the PDP-8 had a bit to say whether an address was to page 0 or the
current one.

--
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 Thomas Koenig <tkoenig@netcologne.de>:
>> S/360 invented eight bit byte addressed memory with larger power of 2

>Brooks wrote that the design was supposed to have been 32-bit
>clean from the start, but that the people who implemented the BALR
>instruction (which puts some bits of the PSW into the high-value
>byte) didn't follow that guideline. He blamed himself for not making
>that sufficiently clear to all the design team.

Yup. Even worse, the OS programmers were under extreme pressure
to save memory so in every data structure with address words,
they used the high byte for flags or other stuff. So when they
went to 31 bit addressing, they needed new versions of all of
the control blocks.

>> I thought the PDP-10 was swell, but even if DEC had been able to
>> design and ship the Jupiter follow-on to the KL-10, its expanded
>> addressing was a kludge. It only provided addressing 8M words or about
>> 32M bytes with no way to go past that.

I misread the manual. The extended addresses were 30 bits or about 4GB
which was plenty for that era, but the way they did it in 256K word
sections was still a kludge. In the original PDP-6/10 every
instruction could address all of memory. In extended mode you could
directly address only the current section, and everything else needed
an index register or an indirect address.

While this wasn't terribly hard, it did mean that any time you wanted
to change a program to run in extended mode you had to look at all the
code and check every instruction that did an address calculation,
which was tedious.

>Reading
>
>http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp10/KC10_Jupiter/ExtendedAddressing_Jul83.pdf
>
>I concur that it was a kludge, but at least they seem to have
>allowed for further extension by reserving a 1-1- bit pattern,
>as an illegal indirect word.

Given that it could already address 4GB I don't think that would help, since anything
larger would need multi-word addresses which would be an even worse kludge.

>However, one questions. Designs like the PDP-10 or the UNIVAC
>(from what I read on Wikipedia) had "registers" at certain
>memory locations. On the PDP-10, it even appears to have been
>possible to run code in the first memory locations/registers.

Funny you should mention that. On the PDP-6/10, the registers were the
first 16 memory locations. There were no register to register
instructions since you used the regular instruction with a memory
address between 0 and 017. You could indeed run code in the registers
which was somewhat faster. I wrote a little multi-precision factorial
routine that ran in the registers.

>It seems that the /360 was the first machine which put many
>registers into a (conceptually) separate space, leaving them open
>to implementing them either in memory or as faster logic.
>
>Is that the case, or did anybody beat them to it?

On the PDP-6 and KA-10 the transistor registers were an extra cost
option, so you could order your machine either way. I believe that DEC
never shipped a machine without the fast registers since the speed
difference was so great.
--
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>:
> > I do want to note that another factor in S/360's success was the
> > quality of the paper peripherals, expecially the 1401 printer, which
> > was a true marvel in its time. IBM got that advantage from their
> > long experience with punch card business systems.
>
> I presume you mean the 1403 which was indeed a great printer. I
> printed a lot of term papers on them.

Yes, 1403. Sorry.

>
> > All the others, which were word or maybe decimal digit
> >> addressed, died. ...
>
> > The Univac 1110 (circa 1972), (about a devcade before XA) had
> > banking, which allowed an instruction to address anywhere within a
> > 262K (approximately 1 MB) "window" into what could be an "address
> > space" of about 4 GB. It was a little awkward in that, while you
> > could have 4 of such "windows" available at any time, changing
> > windows required executing an, (unprivlidged) instruction.
>
> There were a lot of segmented address schemes and as far as I can tell
> nobody liked them except maybe the Burroughs machines where the
> compilers made it largely invisible. The most famous was the 8086 and
> 286 but the PDP-10 extended addressing was sort of like that and even
> the PDP-8 had a bit to say whether an address was to page 0 or the
> current one.

The 1100 series scheme, which was called multi banking, wsn't exactly a
segment scheme, but the differences are subtle. It certainly wan't a
clean as a single large adress space, but it did make certain things,
like shared libraries (common banks in 1100 terminology) very easy.
And it did eliminate the need for the BALR/Using stuff. And it didn't
have the issue of having already used the upper bits that caused such
problems with IBM's XA transition.

My point is not that the 1100 scheme was better or worse than the S/360
scheme. Each had benefits and drawbacks. But it is that the S/360 CPU
architecture wasn't the only factor in its success. Other factors,
like marketing and peripherals were a significan't, perhaps the major
factors.

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

Stephen Fuld <SFuld@alumni.cmu.edu.invalid> schrieb:
> Thomas Koenig wrote:
>
>> John Levine <johnl@taugh.com> schrieb:
>>
>> > They had the insight to see that the 16 fixed sizs registers could
>> > be in fast storage on high end machines, main memory on low end
>> > machines, so the high end machines were fast and the low end no
>> > slower than a memory-memory architecture which is what it in
>> > practice was. It was really an amazing design, no wonder it's the
>> > only architecture of its era that still has hardware
>> > implementations.
>
>
> Yes, although it isn't clear how much of its success is due to
> technical superiority versus marketing superiority.

"Put a bullet through a CPU without missing a single transation"
is also a technical achievement :-)

I recently heard (but did not find a source that IBM did RAID on some
of their caches.

>> Prompted by a remark in another newsgroup, I looked at IBM's 2023
>> annual report, where zSystems is put under "Hybrid Infrastructure"
>> (lumped together with POWER). The revenue for both lumped together
>> is around 9,215 billion Dollars, with a pre-tax margin of more
>> than 50%.
>>
>> At those margins, they can certainly pay for a development team
>> for future hardware generations.

> Yes, but remember that includes softwre revenue, which has higher
> margins than hardware revenue. I believe I saw somewhere that IBM made
> more from MVS, DB2, CICS, etc.

SAP S4/HANA is going to hurt their bottom line, then. Earlier
versions of SAP could, I understand, run on zOS and DB2, S4/HANA
requires SAP's in-house database and requires Linux.

> than they do on the hardware itself. So
> one could argue that they have to develop mew hardware in order to
> protect their software revenue!

Sounds reasonable, and the reverse of what they did in the
(far-away) past.

John Levine <johnl@taugh.com> schrieb:

[PDP-10]

> I misread the manual. The extended addresses were 30 bits or about 4GB
> which was plenty for that era, but the way they did it in 256K word
> sections was still a kludge. In the original PDP-6/10 every
> instruction could address all of memory. In extended mode you could
> directly address only the current section, and everything else needed
> an index register or an indirect address.
>
> While this wasn't terribly hard, it did mean that any time you wanted
> to change a program to run in extended mode you had to look at all the
> code and check every instruction that did an address calculation,
> which was tedious.

Hmm... would a simple recompilation have done the trick, or were there
also issues with integers being restricted to 18 bits, for example?

Thomas Koenig wrote:

> Stephen Fuld <SFuld@alumni.cmu.edu.invalid> schrieb:
> > Thomas Koenig wrote:
> >
> >> John Levine <johnl@taugh.com> schrieb:
> >>
> >> > They had the insight to see that the 16 fixed sizs registers
> could >> > be in fast storage on high end machines, main memory on
> low end >> > machines, so the high end machines were fast and the low
> end no >> > slower than a memory-memory architecture which is what it
> in >> > practice was. It was really an amazing design, no wonder it's
> the >> > only architecture of its era that still has hardware
> >> > implementations.
> >
> >
> > Yes, although it isn't clear how much of its success is due to
> > technical superiority versus marketing superiority.
>
> "Put a bullet through a CPU without missing a single transation"
> is also a technical achievement :-)

True. But that is a relativly recent achievement. Long after IBM's
mainframe dominance.

>
> I recently heard (but did not find a source that IBM did RAID on some
> of their caches.
>
> >> Prompted by a remark in another newsgroup, I looked at IBM's 2023
> >> annual report, where zSystems is put under "Hybrid Infrastructure"
> >> (lumped together with POWER). The revenue for both lumped together
> >> is around 9,215 billion Dollars, with a pre-tax margin of more
> >> than 50%.
> >>
> >> At those margins, they can certainly pay for a development team
> >> for future hardware generations.
>
> > Yes, but remember that includes softwre revenue, which has higher
> > margins than hardware revenue. I believe I saw somewhere that IBM
> > made more from MVS, DB2, CICS, etc.
>
> SAP S4/HANA is going to hurt their bottom line, then. Earlier
> versions of SAP could, I understand, run on zOS and DB2, S4/HANA
> requires SAP's in-house database and requires Linux.
>
> > than they do on the hardware itself. So
> > one could argue that they have to develop mew hardware in order to
> > protect their software revenue!
>
> Sounds reasonable, and the reverse of what they did in the
> (far-away) past.

Yup. I remember when the woftware was free! Amdahl and the other
PCM's forced that to change.

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

According to Thomas Koenig <tkoenig@netcologne.de>:
>> While this wasn't terribly hard, it did mean that any time you wanted
>> to change a program to run in extended mode you had to look at all the
>> code and check every instruction that did an address calculation,
>> which was tedious.
>
>Hmm... would a simple recompilation have done the trick, or were there
>also issues with integers being restricted to 18 bits, for example?

This was 50 years ago. The system software was mostly written in
assembler. Some was written in BLISS which was more concise but still
extremely machine specific. I suppose you could recompile your Fortran
programs, but the Fortran compiler was written in BLISS.

There were later versions of BLISS for the PDP=11, Vax and other
machines but they were not compatible with each other. The earliest
places I can think of system programming languages with different
targets were when Bell Labs ported Unix to the Interdata, and the IBM
S/38 and its successors that had (still has) a virtual machine
language that is translated to whatever hardware it's running on.

--
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 Thomas Koenig <tkoenig@netcologne.de>:
>> Yes, but remember that includes softwre revenue, which has higher
>> margins than hardware revenue. I believe I saw somewhere that IBM made
>> more from MVS, DB2, CICS, etc.
>
>SAP S4/HANA is going to hurt their bottom line, then. Earlier
>versions of SAP could, I understand, run on zOS and DB2, S4/HANA
>requires SAP's in-house database and requires Linux.

I dunno how much of a problem it'll be. IBM has put a lot of work into
getting zSeries to run Linux well.

I realize neither you nor I would buy a mainframe to run Linux, but we
wouldn't run SAP either.

--
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 Thomas Koenig <tkoenig@netcologne.de>:
>>> While this wasn't terribly hard, it did mean that any time you wanted
>>> to change a program to run in extended mode you had to look at all the
>>> code and check every instruction that did an address calculation,
>>> which was tedious.
>>
>>Hmm... would a simple recompilation have done the trick, or were there
>>also issues with integers being restricted to 18 bits, for example?

> This was 50 years ago. The system software was mostly written in
> assembler. Some was written in BLISS which was more concise but still
> extremely machine specific.

BLISS reads a LOT like the original K&R C.

> I suppose you could recompile your Fortran
> programs, but the Fortran compiler was written in BLISS.

> There were later versions of BLISS for the PDP=11, Vax and other
> machines but they were not compatible with each other.

Imagine if BLISS were machine independent ?!!

> The earliest
> places I can think of system programming languages with different
> targets were when Bell Labs ported Unix to the Interdata, and the IBM
> S/38 and its successors that had (still has) a virtual machine
> language that is translated to whatever hardware it's running on.

John Levine <johnl@taugh.com> schrieb:
> According to Thomas Koenig <tkoenig@netcologne.de>:
>>> Yes, but remember that includes softwre revenue, which has higher
>>> margins than hardware revenue. I believe I saw somewhere that IBM made
>>> more from MVS, DB2, CICS, etc.
>>
>>SAP S4/HANA is going to hurt their bottom line, then. Earlier
>>versions of SAP could, I understand, run on zOS and DB2, S4/HANA
>>requires SAP's in-house database and requires Linux.
>
> I dunno how much of a problem it'll be. IBM has put a lot of work into
> getting zSeries to run Linux well.

They won't get DB2 royalties, though. I'm also not sure what they
could charge for Linux vs. zOS.

> I realize neither you nor I would buy a mainframe to run Linux, but we
> wouldn't run SAP either.

Certainly not :-)

I've worked with SAP's user interface a bit, for entering hours
for accounting. The user intrface, well, let's just say it took
longer to get used to than I used it (quite a few years).

According to MitchAlsup1 <mitchalsup@aol.com>:
>> This was 50 years ago. The system software was mostly written in
>> assembler. Some was written in BLISS which was more concise but still
>> extremely machine specific.
>
>BLISS reads a LOT like the original K&R C.

Not really, a little more like BCPL, maybe. It didn't have types or
structures. It did have a rather extensive way to define pointer
deferencing which meant it was easy to describe an upper diagonal
array, but clumsy to describe a thing with two ints and a string.

>> There were later versions of BLISS for the PDP=11, Vax and other
>> machines but they were not compatible with each other.
>
>Imagine if BLISS were machine independent ?!!

Much later DEC came up with versions of BLISS that were similar enough
that you could write fairly portable code, with moderate amounts of
per-machine conditional compilation. This article is a good summary
of the language and its evolution.

https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf

By that time, though, Unix had been ported to lots of machines. BLISS
suffered by its origin on the word-addressed PDP-10, while after its
earliest years people only cared about C on 8-bit byte addressed
machines.

--
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

Thomas Koenig <tkoenig@netcologne.de> writes:

> Stephen Fuld <SFuld@alumni.cmu.edu.invalid> schrieb:
[...]

>> [...] remember that includes softwre revenue, which has higher
>> margins than hardware revenue. I believe I saw somewhere that IBM
>> made more from MVS, DB2, CICS, etc.
>
> SAP S4/HANA is going to hurt their bottom line, then. Earlier
> versions of SAP could, I understand, run on zOS and DB2, S4/HANA
> requires SAP's in-house database and requires Linux.
>
>> than they do on the hardware itself. So
>> one could argue that they have to develop mew hardware in order to
>> protect their software revenue!
>
> Sounds reasonable, and the reverse of what they did in the
> (far-away) past.

IBM was forced to change what it did in the past as a
consequence of an antitrust action filed by the US
government. And in fact there was more than one of
those.

Thomas Koenig <tkoenig@netcologne.de> writes:

> I've just read (most of) "The Design of Design" by Fred Brooks,
> especially the chapters dealing with the design of the /360,
> and it's certainly worth reading. (I had finished "The Mythical
> Man-Month" before). There are chapters on computer and software
> architectures, but also something on a house he himself built.

That he designed (with the help of a professional architect). It
may be that Brooks and his family helped with some of the interior
work, but professional contractors did the building.

> An interesting detail about the /360 design was that they originally
> wanted to do a stack-based machine. It would have been OK for the
> mid- and high-end machines, but on low-end machines it would have
> been undompetetive, so they rejected that approach.

And it was a serious consideration, the team spending six months
before rejecting it due to those performance limitations.

> He discusses the book on computer architecture he co-authored with
> Gerrit Blaauw in it (as a project). Would be _very_ nice to read,
> but the price on Amazon is somewhat steep, a bit more than 150 Euros.

Yow. I think I'll try a local library.

> One thing about Brooks - he is not shy of criticizing his own
> works when his views changed. I liked his scathing comments on JCL
> so much that I put them in the Wikipedia article :-)

Personally I think his assessment of JCL is harsher than it
deserves. Don't get me wrong, JCL is not my idea of a great
control language, but it was usable enough in the environment
that customers were used to. The biggest fault of JCL is that it
is trying to solve the wrong problem. It isn't clear that trying
to do something more ambitious would have fared any better in the
early 1960s (see also The Second System Effect in MMM).

No comment about JCL still being used today.

> His main criticism of his own book on computer architecture was
> that it treated computer architecture as a finite field which had
> been explored already.
>
> @John S: Not sure if you've read "The Design of Design", but if you
> haven't, you probably should. It might help you to refocus in your
> quest to recreate a S/360 (especially the requirement to get the
> architecture to work well on a very small machine like the 360/30).
>
> Soo... good to read. Anything else?

I read TDOD somewhat quickly completely through. After a time I
went back and started re-reading, going more slowly the second
time. That has turned out to be rather useful, and I would at
least suggest that people try a second, and slower, reading.

According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
>> Sounds reasonable, and the reverse of what they did in the
>> (far-away) past.
>
>IBM was forced to change what it did in the past as a
>consequence of an antitrust action filed by the US
>government. And in fact there was more than one of
>those.

That's true but they didn't have that much practical effect.

The 1956 agreement required that they sell equipment, rather than only
leasing it, let customers buy their cards from vendors other than IBM,
and some other related stuff. A big deal then, irrelevant now.

In 1969 they preemptively unbundled software and services, expecting
that an antitrust suit could force them to do so. There were many of
antitrust suits through 1982, all of which IBM won or were dismissed.

Telex (a company unrelated to the Western Union telex) won a narrow
case about peripheral interfaces, but lost on appeal. Around the same
time there was an EU case that IBM settled and agreed to publish
device interfaces, which was basically what Telex wanted.

I don't think that any of these had a significant long term effect on
the computer industry. When minicomputers appeared IBM never competed
very successfully (nobody would have bought a slow expensive IBM 1130
if IBM didn't make it), and when micros came along they had a short
term success with the IBM PC but soon lost control of that market.

--
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

"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:

> Thomas Koenig wrote:
>
>> John Levine <johnl@taugh.com> schrieb:
>>
>>> They had the insight to see that the 16 fixed sizs registers could
>>> be in fast storage on high end machines, main memory on low end
>>> machines, so the high end machines were fast and the low end no
>>> slower than a memory-memory architecture which is what it in
>>> practice was. It was really an amazing design, no wonder it's the
>>> only architecture of its era that still has hardware
>>> implementations.
>
> Yes, although it isn't clear how much of its success is due to
> technical superiority versus marketing superiority.

To me it seems clear that the success of System/360 was largely or
mostly due to good technical decisions having been made. IBM
salesmen were very effective in getting customers for the new
line, but a lot of the reason for that is that they had a good
product to sell. I don't mean just the number of registers or
the size of the address space, but a commitment to a forward
looking architecture that handles all the needs of every
customer, both big and small, and would continue to do so in
the future. In those days the vast majority of computer buyers
were businesses, at least as measured by dollars, and in the
business world that sort of pitch has enormous appeal.