🚀 go-pugleaf

Andreas Kohlbach <a...@spamfence.net> writes:
> Thanks for the update. Suppose if you'd still use them today (are they
> still used today?) they could also be exploited?

while 360/195 & 370/195 had out-of-order ... it didn't have speculative
execution and stalled on conditional branches ... as a result, most
ordinary codes only ran at half speed. I got con'ed into participating
in hyperthreading project for 370/195 (that was never released)
... basically simulating two processor SMP (two i-streams some chance of
keeping processor 100% busy) ... ref to hyperthread
https://people.cs.clemson.edu/~mark/acs_end.html

Sidebar: Multithreading

In summer 1968, Ed Sussenguth investigated making the ACS/360 into a
multithreaded design by adding a second instruction counter and a second
set of registers to the simulator. Instructions were tagged with an
additional "red/blue" bit to designate the instruction stream and
register set; and, as was expected, the utilization of the functional
units increased since more independent instructions were available.

IBM patents and disclosures on multithreading include:

US Patent 3,728,692, J.W. Fennel, Jr., "Instruction selection in a
two-program counter instruction unit," filed August 1971, and issued
April 1973.

US Patent 3,771,138, J.O. Celtruda, et al., "Apparatus and method for
serializing instructions from two independent instruction streams,"
filed August 1971, and issued November 1973. [Note that John Earle is
one of the inventors listed on the '138.]

"Multiple instruction stream uniprocessor," IBM Technical Disclosure
Bulletin, January 1976, 2pp. [for S/370]

... snip ...

the other issue, was that company was going to move everything to
virtual memory ... post about decision to go virtual memory for
everyting
http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory

... and a virtual memory 370/195 would have been a completely new
machine. Don't see IBM mainframe doing out-of-order really again
until z196 (Jul2010, 50yrs later).

I've mentioned before San Jose Research had 370/195 running increasingly
aging MVT system (almost 1980 before replaced with 168-3 & MVS). Job
queue sometimes was 3month backlog.

Palo Alto Science Center had a program that ran 1hr on SJR 370/195
... but only got turn around every three months. They had 370/145
running VM/370 and did some checkpointing for the application and
started running offshift ... it took around month to complete a run
... but that was still better than the 3month turn around on SJR's
machine.

Disk Division was doing air bearing simulation for design of thin film
disk r/w heads (3370 fba) ... and even with expediated processing, it
was only getting something like two week turn arounds.
http://www.computerhistory.org/storageengine/thin-film-heads-introduced-for-large-disks/
https://en.wikipedia.org/wiki/Disk_read-and-write_head

Across the street in bldgs 14&15 ... they had dedicated mainframes for
DASD engineering testcell testings ... stand alone time scheduled around
the clock 7x24. I offered to rewrite input/output supervisor to make it
bullet proof and never fail ... so they could operate on-demand,
concurrent testing greatly improving productivity.  bldg 15 would get
early processor machine for testing ... and in late 70s got both early
engineering 3033 & 4341 (something like third or fourth operational
engineering machine).  Turns out even with multiple concurrent testcell
testing ... that only used one or two percent CPU. Setup so that air
bearing simulation could run on bldg. 15 3033 ... and although had
slightly less than half the throughput of 370/195 ... could still get a
few turn arounds a day ... rather than turn around every couple weeks
from the 370/195 (because the bldg 15 3033 otherwise had nearly unloaded
CPU compared to weeks & months workload backlog for 370/195).

posts getting to play disk engineer in bldgs 14&15
http://www.garlic.com/~lynn/subtopic.html#disk

over the weekend did series of google satellite maps of san jose plant
site 1998-2017 (for retired IBM online group) ... shows whole lot of
bldgs being plowed under between June 2007 and end of July ... but bldgs
13, 14, 15 continued to stand. Then bldgs 13 & 15 plowed under early
2014 ... but bldg 14 still stands.

Next round was 1st half 80s ... demand for computing greeatly
outstripping traditional raised floor datacenters ... and saw loads of
4341s (& 3370 FBA disks) being placed out in departmental areas ...
sort of the leading edge of the coming distributed computing tsunami
(saw huge spike in vm370 installations ... in part because POK favorite
son mainframe operating system never supported FBA (still doesn't, even
though CKD disks haven't been made for decades, they still have
requirement for CKD simulation ... on industry standard fixed-block
disks).

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