IBM 360/85 vs. 370/165

[Jon Elson]

Some time ago, a picture showed up here that piqued my interest
in how similar a model 85 looked to a 165/168.

There isn't any bitsavers FEMM on the /85, but there is a functional
characteristics book on the two machines. This revealed more than
I might have hoped for. The physical layout of the two machines
is similar in volume, but somewhat different in the exact layout.

The 85 was set up like this:

| | |
| | |
---------
| | |
| | |

The /165 was like this :

| |
| |
---------
| | |
| | |
|
---------

Both machines were apparently partially liquid cooled. the clock
rate was the same, 80 ns. I think that pretty much answered my question
about the basic technology, it pretty much must have been a version of
MST, rather than a souped-up version of SLT, both to get all the CPU
into the box as well as run at that speed. The model /85 had a LOT
of memory, way more than earlier 360's, something like 1 - 4 MB was
the range. Since it was CORE, it would take up a LOT of that cabinet!
The /85 document makes no mention of writeable control store.

But, the thing that totally cinched the fact that the two machines
had a LOT in common was the instruction execution time table in the
back of the two functional char. documents. They appeared on cursory
inspection to be the EXACT SAME table! That just couldn't happen unless
the machines basically shared the same low-level architecture.

So, that was sure something I NEVER KNEW! I HAD thought the model 195
was the bridge between 360 and 370 physical implementations, and never knew
the /85 was the real bridge.

Jon

[John Levine]

>So, that was sure something I NEVER KNEW! I HAD thought the model 195
>was the bridge between 360 and 370 physical implementations, and never knew
>the /85 was the real bridge.

"IBM's 360 and early 370 systems" by Emerson W. Pugh, Lyle R. Johnson,
and John H. Palmer is the classic reference. WU's library has a copy.

The 360/85 was a souped up 360/65, using much faster core memory and
the fast ASLT logic from the /91. It was microcoded like the
successful /65, not hardwired like the /75 and /91. IBM's high end
computers, STRETCH, the /91 and the /195 had been phenomenally
complicated, and the /85 seemed to be a relatively low risk addition
to plug a hole in the product line. The original plan was to use
250ns core memory, three times as fast as the /65 or /91 core, which
was a big technical challenge. Then someone came up with the idea of
a cache, which initially met with great scepticism. But extensive
simulations showed it would work, and it worked really well, so well
that the main memory was slowed to 1000ns, allowing larger memories
with longer cables, but it didn't matter since nearly all references
were satisified from the 80ns cache. For jobs that didn't do much
floating point, the cache made the /85 nearly as fast as the much more
complex /91.

The 370/165 was largely a reimplemented /85. All of the larger 370s
had caches, and it was a long time if ever before IBM reused the
complex out of order design of the /91.

[Anne & Lynn Wheeler]

John Levine <jo...@iecc.com> writes:
> "IBM's 360 and early 370 systems" by Emerson W. Pugh, Lyle R. Johnson,
> and John H. Palmer is the classic reference. WU's library has a copy.
>
> The 360/85 was a souped up 360/65, using much faster core memory and
> the fast ASLT logic from the /91. It was microcoded like the
> successful /65, not hardwired like the /75 and /91. IBM's high end
> computers, STRETCH, the /91 and the /195 had been phenomenally
> complicated, and the /85 seemed to be a relatively low risk addition
> to plug a hole in the product line. The original plan was to use
> 250ns core memory, three times as fast as the /65 or /91 core, which
> was a big technical challenge. Then someone came up with the idea of
> a cache, which initially met with great scepticism. But extensive
> simulations showed it would work, and it worked really well, so well
> that the main memory was slowed to 1000ns, allowing larger memories
> with longer cables, but it didn't matter since nearly all references
> were satisified from the 80ns cache. For jobs that didn't do much
> floating point, the cache made the /85 nearly as fast as the much more
> complex /91.
>
> The 370/165 was largely a reimplemented /85. All of the larger 370s
> had caches, and it was a long time if ever before IBM reused the
> complex out of order design of the /91.

claim is that half per processor throughput improvement from z10 to z196
was introduction of these old features of out of order execution and
additional work responsible for z196 to ec12 per processor improvement.

z900, 16 processors, 2.5BIPS (156MIPS/proc), Dec2000
z990, 32 processors, 9BIPS, (281MIPS/proc), 2003
z9, 54 processors, 18BIPS (333MIPS/proc), July2005
z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008
z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010
EC12, 101 processors, 75BIPS (743MIPS/proc), Aug2012

in the early 70s, i had gotten dragged into project doing hyperthreading
on 370/195 (which never shipped, part of the issue was that they were
never going to be able to retrofit virtual memory to 195) ... they told
me that biggest change from 360/195 to 370/195 were the couple
additional new 370 instructions and hardware instruction retry. 195
pipeline had out-of-order instruction execution but not branch
prediction and speculative execution ... so conditional branches drained
the pipepline. Carefully constructed codes would hit 10mips ... but
most codes typically ran 5mips. hyperthreading was to emulate two
i-streams (two processor operation) using red/blue bit implementation
described here in this article about end of acs/360 (two emulated
processors running conditional branch code at 5mips keeping 10mip
execution hardware utilized)
http://people.cs.clemson.edu/~mark/acs_end.html

Above also mentions acs/360 was shutdown because executives were afraid
that it would advance the state-of-the-art too fast and they would loose
control of the market and some of the features then show up in es/9000
20yrs later.

In the wake of failure of future system project
http://www.garlic.com/~lynn/submain.html#futuresys

there was mad rush to get products back into 370 pipeline ... including
kicking off 303x & 3081 somewhat in parallel; 3033 started out being q&d
effort remapping 168 logic to warmed over 20% faster chips from FS
(and 3081 using other warmed over FS technology)
http://www.jfsowa.com/computer/memo125.htm

at that time I was involved in 16-way smp effort ... and we had gotten
some of the 3033 processor engineers to work on it in their spare time
(lot more interesting than what they were doing with 3033). Initially
POK high-end people that it was really great ... and then somebody told
the head of POK that it might be decades before POK's favorite son
operating system had 16-way SMP support.

3033
https://www-03.ibm.com/ibm/history/exhibits/3033/3033_room.html
3081
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3081.html

when 3033 was out the door, they start on 3090 (overlapped with the
3081 work) ... finally as new effort
https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3090.html

followed by es/9000
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS9000.html

followed by ESA/390
http://en.wikipedia.org/wiki/IBM_ESA/390

and then finally get to 16-way with z900 in Dec2000

old post discussing decision to make virtual memory standard
on all 370s:
http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory

posts mentioning SMP (&/or compare-and-swap instruction)
http://www.garlic.com/~lynn/subtopic.html#smp

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

[Jon Elson]

John Levine wrote:


>
> "IBM's 360 and early 370 systems" by Emerson W. Pugh, Lyle R. Johnson,
> and John H. Palmer is the classic reference. WU's library has a copy.
>

Thanks, I'll have to look this one up!

> The 360/85 was a souped up 360/65, using much faster core memory and
> the fast ASLT logic from the /91.

Ah, so it wasn't using MST. I'm a bit surprised they could pack
the necessary circuitry into the machine with discrete transistors.
I don't think ASLT was much denser than SLT, and didn't realize
it would run quite that fast! The instruction timing on the /85
closely matches the /165, I would have thought the MST of the
/165 would have speeded things up. But, MAYBE, if you use very
similar microcode and the clock speed is the same, the instruction
timing will just be the same too, even with different logic
technology.

> It was microcoded like the
> successful /65, not hardwired like the /75 and /91.

Yes I knew that was the case.

> The original plan was to use
> 250ns core memory, three times as fast as the /65 or /91 core, which
> was a big technical challenge. Then someone came up with the idea of
> a cache, which initially met with great scepticism. But extensive
> simulations showed it would work, and it worked really well, so well
> that the main memory was slowed to 1000ns, allowing larger memories
> with longer cables, but it didn't matter since nearly all references
> were satisified from the 80ns cache. For jobs that didn't do much
> floating point, the cache made the /85 nearly as fast as the much more
> complex /91.

Yes, IBM lost money big-time on the /91 and 195, and knew they would
going in, but it was a "loss leader". At least the /85 paved
the way for the follow-on machines.

>
> The 370/165 was largely a reimplemented /85. All of the larger 370s
> had caches, and it was a long time if ever before IBM reused the
> complex out of order design of the /91.

Doing that amount of out of order and other pipelining tricks only
makes sense on much more highly integrated machines. I'm sort of
amazed they could ever get the /91 and 195 to work in the field.


Jon

[Quadibloc]

On Friday, December 5, 2014 2:12:28 PM UTC-7, Jon Elson wrote:

> So, that was sure something I NEVER KNEW! I HAD thought the model 195
> was the bridge between 360 and 370 physical implementations, and never knew
> the /85 was the real bridge.

Well, some of the other 370 models also resembled 360 models; for example, the
370/115 resembled the 360/25. I don't think there was one bridge.

The model 195, although it was converted to a 370 version, was basically
abandoned by IBM - they didn't feel that such a high end machine fitted into
their commercial plans.

John Savard

[Anne & Lynn Wheeler]

Quadibloc <jsa...@ecn.ab.ca> writes:
> Well, some of the other 370 models also resembled 360 models; for example, the
> 370/115 resembled the 360/25. I don't think there was one bridge.
>
> The model 195, although it was converted to a 370 version, was basically
> abandoned by IBM - they didn't feel that such a high end machine fitted into
> their commercial plans.

re:
http://www.garlic.com/~lynn/2014l.html#11 360/85
http://www.garlic.com/~lynn/2014m.html#105 IBM 360/85 vs. 370/165
http://www.garlic.com/~lynn/2014m.html#106 [CM] How ENIAC was rescued from the scrap heap

Boeblingen got into lots of trouble from corporate for doing for 370
115/125; they had 9 position memory bus for microprocessors ... rather
than having integrated channels and controllers ... microcode running on
same engine as running 370 microcode ... it had separate microcode
engines running the different functions. 370/115 had all the processors
identical (processor running the 370 microcode was same as all the other
processors running various controller microcode). 370/125 was identical
to the 370/115 except the processor running 370 microcode was about 50%
faster than the other processors.

At one point I got sucked into designing software & architecture for
370/125 that had five of the memory bus positions filled with processor
engines running 370 microcode ... although it never shipped. I dropped
some amount of dispatching into microcode ... somewhat hiding low-level
multiprocessor complexity from the operating system softare (and
increasing performance) ... slightly akin to what was later done for the
i432 ... as well as other operating system functions ... more
architected than what I was asked to help with for VM/370 ECPS microcode
assist which was nearly one-for-one 370 instruction microcode
instruction (that I was being asked to work on at the same time). past
reference to ECPS microcode assist
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

past posts mentioning the 370/125 5-way SMP work
http://www.garlic.com/~lynn/submain.html#bounce

[hanc...@bbs.cpcn.com]

On Saturday, December 6, 2014 4:26:42 PM UTC-5, Quadibloc wrote:
> The model 195, although it was converted to a 370 version, was basically
> abandoned by IBM - they didn't feel that such a high end machine fitted into
> their commercial plans.

Both the S/360 history (op cit) as well as TJ Watson Jr's memoir (Father Son & Co) both touch on the issue of very high end machines.

Note the S/360 history includes an interest performance comparison charge of various high end machines doing various kinds of work, some jobs to take advantage of special features, others of a typical nature.

To paraphrase, in earlier yars, Watson thought it was important for the prestige of the company to have such machines, plus, such machines, whose purchase would be subsidized by deep pocket customers and sponsors would develop new technology that could be utilized by lower machines.

However, in later years, Watson and the company realized there was a special art to building such high end machines economically. They saw innovations by CDC using existing technology that IBM couldn't do or didn't think of.


As an aside, FWIW, an weather bureau researcher told me that 195 was a good machine, but they got significant improvements when IBM mainframes got vector processing, which apparently is important to the nature of their forecast model.

[Shmuel Metz]

In <-92dnXA7geQmgh_J...@giganews.com>, on 12/05/2014

at 03:12 PM, Jon Elson <jme...@wustl.edu> said:

>The /85 document makes no mention of writeable control store.

IBM System/360 Model 85 Functional Characteristics, A22-6916-1, p. 14:

<QUOTE>

Control Storage

The control storage in the Model 85 consists of a combination of
read-only storage (ROS) and writable control storage (WCS) plus
associated logic. Internal transfers are parity-checked; a parity
error causes a machine check. The cycle time for both types of control
storage is 80 nanoseconds.

Control storage stores control information that is used to define the
state of the CPU at any given time. The execution unit is controlled
by microprograms in both read-only storage and writable control
storage. The microprogranls are presently arranged in a 108-bit
control word format. More than 2,500 control word addresses are
provided in the basic CPU: 2,000 in read-only storage and 500 in
writable control storage.

One control word is accessed, decoded, and used
during each machine cycle. Control is exercised over
machine functions such as movement of the contents
of a register to the input of an adder. Control words
are used instead of conventional logic to control the
operation of the CPU.

The writable control storage is included to provide microdiagnostic
capability. It is also used to contain the compatibility feature
control words. When the compatibility feature is installed (factory
installation only), 500 additional control word addresses in wcs arc
included in the CPU.

</QUOTE>

>But, the thing that totally cinched the fact that the two machines
>had a LOT in common was the instruction execution time table in
>the back of the two functional char. documents.

That can be explained as coincidence. The fact that both had the same
(108 bits without compatibility feature) microinstruction size and
console is hardfer to explain away.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[John Levine]

>However, in later years, Watson and the company realized there was a special art to building such high end machines
>economically. They saw innovations by CDC using existing technology that IBM couldn't do or didn't think of.

IBM's high end machines, the STRETCH, /91 and /195 were hugely complex
designs, and IBM prided themselves on their ability to manage the
complexity. Then Cray came out with much simpler computers that ran
like a bat out of hell, which I gather was rather a shock to IBM.

In the /91, some of the complexity was required to implement the 360
architecture, e.g. the prefetch logic had to checks for store into the
instruction stream. But a lot of it was complex whizzo speedups,
notably the Tomasulo out of order floating point stuff.

>As an aside, FWIW, an weather bureau researcher told me that 195 was a good machine, but they got significant
>improvements when IBM mainframes got vector processing, which apparently is important to the nature of their forecast
>model.

I used the /91 at Princeton, which worked great when it worked, but it
was unreliable enough that you were expected to do checkpointing of
anything that was expected to take clock time of more than an hour or
so.

Weather forecasting involves dividing the surface of the world into a
grid, and doing various calculations on each cell of the grid, so it's
an ideal application for vector and parallel designs. IBM's vector
architecture was pretty good, but it eventually became apparent that
the people who cared about FP performance didn't care about 360
compatibility, so the high end computers went in a different direction.

[Jon Elson]

Shmuel Metz wrote:

> In <-92dnXA7geQmgh_J...@giganews.com>, on 12/05/2014
> at 03:12 PM, Jon Elson <jme...@wustl.edu> said:
>
>>The /85 document makes no mention of writeable control store.
>
> IBM System/360 Model 85 Functional Characteristics, A22-6916-1, p. 14:
>
> <QUOTE>
>
> Control Storage
>
> The control storage in the Model 85 consists of a combination of
> read-only storage (ROS) and writable control storage (WCS) plus
> associated logic.

OK, THANKS! I looked, but missed that!

Jon

[Peter Flass]

Quadibloc <jsa...@ecn.ab.ca> wrote:
> On Friday, December 5, 2014 2:12:28 PM UTC-7, Jon Elson wrote:
>
>> So, that was sure something I NEVER KNEW! I HAD thought the model 195
>> was the bridge between 360 and 370 physical implementations, and never knew
>> the /85 was the real bridge.
>
> Well, some of the other 370 models also resembled 360 models; for example, the
> 370/115 resembled the 360/25. I don't think there was one bridge.

The /25 was introduced very late in System/360's lifetime, do that makes
sense. IBM may already have been looking forward to the 370 at the time.

--
Pete

[Charles Richmond]

"John Levine" <jo...@iecc.com> wrote in message
news:m60er2$ja8$1...@miucha.iecc.com...

> >However, in later years, Watson and the company realized there was a
> >special art to building such high end machines
>>economically. They saw innovations by CDC using existing technology that
>>IBM couldn't do or didn't think of.
>
> IBM's high end machines, the STRETCH, /91 and /195 were hugely complex
> designs, and IBM prided themselves on their ability to manage the
> complexity. Then Cray came out with much simpler computers that ran
> like a bat out of hell, which I gather was rather a shock to IBM.
>

Thus we have Thomas J. Watson, Jr.'s "including the janitor" memo...

--

numerist at aquaporin4 dot com

[hanc...@bbs.cpcn.com]

On Sunday, December 7, 2014 12:01:21 PM UTC-5, Charles Richmond wrote:

> Thus we have Thomas J. Watson, Jr.'s "including the janitor" memo...

But coupled to that was the private settlement--at a big loss--of the CDC lawsuit against IBM. TJ Jr touches on that in his memoir as one of the recognition points of the challenges of high-end machines that are different than workaday machines, even powerful ones. In essence, IBM was good at making big Oldsmobile Vista Cruisers with 400 cu in engines and all the options, with a very smooth ride and large capacity. IBM wasn't so good at specialty sports cars, like a Ferrari.

In my own opinion, I see the infamous janitor memo as the start of an era, and the CDC settlement as the end of an era.

Indeed, again IMHO, I both Watsons saw a virtual monopoly of the DP field as a matter of birthright or entitlement for IBM, thus IBM's aggressive attack on CDC. The settlement of the lawsuit was when Watson Jr accepted the fact that IBM simply could not have the market dominance he thought was his due. Note that at the time IBM also changed some revered long standing business practices, such as bundling.

I recommend "Father, So & Co". Watson Jr is surprisingly candid about his successes and failures.

[Shmuel Metz]

In <m5tv5i$2etb$1...@miucha.iecc.com>, on 12/06/2014

at 04:02 AM, John Levine <jo...@iecc.com> said:

>The 360/85 was a souped up 360/65,

With a completely new microinstruction format, it doesn't look much
like a 2065. The console doesn't look much like the 2065 console, with
its 2250, either.

[Anne & Lynn Wheeler]

hanc...@bbs.cpcn.com writes:
> But coupled to that was the private settlement--at a big loss--of the
> CDC lawsuit against IBM. TJ Jr touches on that in his memoir as one
> of the recognition points of the challenges of high-end machines that
> are different than workaday machines, even powerful ones. In essence,
> IBM was good at making big Oldsmobile Vista Cruisers with 400 cu in
> engines and all the options, with a very smooth ride and large
> capacity. IBM wasn't so good at specialty sports cars, like a
> Ferrari.

re:
http://www.garlic.com/~lynn/2014l.html#11 360/85
http://www.garlic.com/~lynn/2014m.html#105 IBM 360/85 vs. 370/165
http://www.garlic.com/~lynn/2014m.html#106 [CM] How ENIAC was rescued from the scrap heap

http://www.garlic.com/~lynn/2014m.html#107 IBM 360/85 vs. 370/165

except this account of ACS/360 ... where Amdahl was going to do high-end
machine, a 1/3rd machine and a 1/9th machine ... for IBM's different
market segments and meeting ibm profit and volume objectives
http://people.cs.clemson.edu/~mark/acs_end.html

executives cancel ACS/360 because they were afraid that it would advance

the state-of-the-art too fast and they would loose control of the

market. recent refs:
http://www.garlic.com/~lynn/2014.html#62 Imprecise Interrupts and the 360/195
http://www.garlic.com/~lynn/2014c.html#64 Optimization, CPU time, and related issues
http://www.garlic.com/~lynn/2014c.html#94 Optimization, CPU time, and related issues
http://www.garlic.com/~lynn/2014d.html#21 Write Inhibit
http://www.garlic.com/~lynn/2014d.html#28 Write Inhibit
http://www.garlic.com/~lynn/2014e.html#15 Last Gasp for Hard Disk Drives
http://www.garlic.com/~lynn/2014e.html#26 23Jun1969 Unbundling Announcement
http://www.garlic.com/~lynn/2014e.html#29 The mainframe turns 50, or, why the IBM System/360 launch was the dawn of enterprise IT
http://www.garlic.com/~lynn/2014e.html#51 The mainframe turns 50, or, why the IBM System/360 launch was the dawn of enterprise IT
http://www.garlic.com/~lynn/2014f.html#21 Complete 360 and 370 systems found
http://www.garlic.com/~lynn/2014f.html#54 IBM Sales Fall Again, Pressuring Rometty's Profit Goal
http://www.garlic.com/~lynn/2014f.html#67 Is end of mainframe near ?
http://www.garlic.com/~lynn/2014f.html#73 Is end of mainframe near ?
http://www.garlic.com/~lynn/2014f.html#78 Over in the Mainframe Experts Network LinkedIn group
http://www.garlic.com/~lynn/2014g.html#11 DEC Technical Journal on Bitsavers
http://www.garlic.com/~lynn/2014g.html#14 Is end of mainframe near ?
http://www.garlic.com/~lynn/2014h.html#4 Demonstrating Moore's law
http://www.garlic.com/~lynn/2014h.html#6 Demonstrating Moore's law
http://www.garlic.com/~lynn/2014h.html#65 Are you tired of the negative comments about IBM in this community?
http://www.garlic.com/~lynn/2014h.html#68 Over in the Mainframe Experts Network LinkedIn group
http://www.garlic.com/~lynn/2014i.html#69 IBM Programmer Aptitude Test
http://www.garlic.com/~lynn/2014i.html#87 IBM Programmer Aptitude Test
http://www.garlic.com/~lynn/2014i.html#97 The SDS 92, its place in history?
http://www.garlic.com/~lynn/2014j.html#19 DG Nova 1200 as console
http://www.garlic.com/~lynn/2014j.html#32 Univac 90 series info posted on bitsavers
http://www.garlic.com/~lynn/2014j.html#51 Is coding the new literacy?
http://www.garlic.com/~lynn/2014j.html#100 No Internet. No Microsoft Windows. No iPods. This Is What Tech Was Like In 1984
http://www.garlic.com/~lynn/2014m.html#65 Decimation of the valuation of IBM
http://www.garlic.com/~lynn/2014m.html#98 Why has human progress ground to a halt?

[Dan Espen]

hanc...@bbs.cpcn.com writes:

> On Sunday, December 7, 2014 12:01:21 PM UTC-5, Charles Richmond wrote:
>
>> Thus we have Thomas J. Watson, Jr.'s "including the janitor" memo...
>
> But coupled to that was the private settlement--at a big loss--of the
> CDC lawsuit against IBM. TJ Jr touches on that in his memoir as one
> of the recognition points of the challenges of high-end machines that
> are different than workaday machines, even powerful ones. In essence,
> IBM was good at making big Oldsmobile Vista Cruisers with 400 cu in
> engines and all the options, with a very smooth ride and large
> capacity. IBM wasn't so good at specialty sports cars, like a
> Ferrari.

Lessons to be learned:

1. Small smart team can outdo a big corporate hierarchy easily.
2. See lesson 1.

As for IBM's dominance, the computer industry trends naturally
to one leader. It's just not practical to have a large bunch
of incompatible machines. Things like the IBM 1403 and
a sharp sales force earned IBM that dominance. Also a little
trickery leading to that lawsuit.

--
Dan Espen

[John Levine]

>>The 360/85 was a souped up 360/65,
>
>With a completely new microinstruction format, it doesn't look much
>like a 2065. The console doesn't look much like the 2065 console, with
>its 2250, either.

Pugh et al. say that the successful /65 engineering team was told to
develop something faster, which was known as the 65X until it got the
final name of 85. Since they were there at at the time, I'm inclined
to believe them.

There are certainly a lot of differences between the 65 and the 85,
but the microprogrammed 85 was a lot more like the microprogrammed 65
than it was like the hard wired 75 or the hyper-complex 91.

[Anne & Lynn Wheeler]

Anne & Lynn Wheeler <ly...@garlic.com> writes:
> at that time I was involved in 16-way smp effort ... and we had gotten
> some of the 3033 processor engineers to work on it in their spare time
> (lot more interesting than what they were doing with 3033). Initially
> POK high-end people that it was really great ... and then somebody told
> the head of POK that it might be decades before POK's favorite son
> operating system had 16-way SMP support.

re:
http://www.garlic.com/~lynn/2014l.html#11 360/85
http://www.garlic.com/~lynn/2014l.html#69 Could this be the wrongest prediction of all time?
http://www.garlic.com/~lynn/2014l.html#81 Could this be the wrongest prediction of all time?

http://www.garlic.com/~lynn/2014m.html#105 IBM 360/85 vs. 370/165
http://www.garlic.com/~lynn/2014m.html#106 [CM] How ENIAC was rescued from the scrap heap
http://www.garlic.com/~lynn/2014m.html#107 IBM 360/85 vs. 370/165

http://www.garlic.com/~lynn/2014m.html#109 high end, was IBM 360/85 vs. 370/165

I usually also mentioned that then the head of POK invited several
of us to never visit the location again ... the processor engineers
were then told to totally focus solely on the 3033 and don't get
side-tracked again.

I've mentioned before that the processor engineers had said in the
transition from 165 to 168 ... the memory got about four times faster
and the (horizontal) microcode had been improved so that it reduced the
avg. machine cycle per 370 instruction from 2.1 to 1.6.

when the 3033 got out the door, they then started on the 3090 (trout
1.5). One of the things they complained about was marketing adding
vector processor feature to the 3090. They claimed that big
justification for vector processing was that normally floating point is
so slow that memory bus can keep a large number of floating point
execution units fed concurrently. They claimed that they spent an
enormous amount of effort on making scalar floating point run as fast as
the memory bus could feed it ... largely negating the need for vector
(we kept in touch after the 16-way fiasco and I would even sometimes
sneak into POK).

misc. past posts mentioning trout:
http://www.garlic.com/~lynn/2000d.html#21 S/360 development burnout?
http://www.garlic.com/~lynn/2000d.html#35 S/360 development burnout?
http://www.garlic.com/~lynn/2003j.html#42 Flash 10208
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
http://www.garlic.com/~lynn/2011h.html#68 IBM Mainframe (1980's) on You tube
http://www.garlic.com/~lynn/2012n.html#33 390 vector instruction set reuse, was 8-bit bytes
http://www.garlic.com/~lynn/2014.html#63 Imprecise Interrupts and the 360/195
http://www.garlic.com/~lynn/2014d.html#17 Write Inhibit

http://www.garlic.com/~lynn/2014f.html#21 Complete 360 and 370 systems found

it wasn't my only dustup with POK. I've mentioned before in 1980 getting
con'ed into doing channel extender support for STL lab (moving 300
people from the IMS DBMS group to offsite building) so they could have
local channel attached controllers back to the STL datacenter
http://www.garlic.com/~lynn/submisc.html#channel.extender

then the vendor tried getting the support released, which was blocked by
a group in POK that had been playing with some serial fiber stuff. Later
in 1988, I get asked to help LLNL standardize some serial stuff they
have which quickly morphs into the fiber channel stuff. Finally the POK
group gets there stuff announced as ESCON with ES/9000 in 1990 (ten
years later by this time it is obsolete).

Eventually some of them become involved with fibre channel stuff and
define a heavy-weight protocol on top of FCS that drastically cuts the
native throughput ... which is eventually released as FICON
http://www.garlic.com/~lynn/submisc.html#ficon

[Shmuel Metz]

In <m62ft1$p89$1...@miucha.iecc.com>, on 12/07/2014

at 09:13 PM, John Levine <jo...@iecc.com> said:

>Pugh et al. say that the successful /65 engineering team was told
>to develop something faster, which was known as the 65X until it
>got the final name of 85. Since they were there at at the time,
>I'm inclined to believe them.

The people wh wrote the CE manuals were also there at the time. Nor
does the code name say much about the implementation.

>There are certainly a lot of differences between the 65 and the 85,
>but the microprogrammed 85 was a lot more like the microprogrammed
>65 than it was like the hard wired 75 or the hyper-complex 91.

By the same argument I could call it an upgrade of a 2040. Look at the
details of what they actually built, not the history of deciding to
build it.