Re: "Portable" data centers
Anne & Lynn Wheeler
lefu...@SBCGLOBAL.NET (Lloyd Fuller) writes:
> What do you mean Sun was the first?
>
> The US Army used 360/30 and 360/40s in 18-wheel trailers back in the
> early 1960s - 40 years before Sun "thought" of the idea. The Army
> even had those in Vietnam for the division data centers.
re:
http://www.garlic.com/~lynn/2009r.html#12 Small Server Mob Advantage
maybe mid-60s?? 360 announce 7apr64.
http://en.wikipedia.org/wiki/IBM_System/360
360/30 FCS jun65, 360/40 FCS apr65
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360.html
... maybe a 1401?
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP1401.html
or 1620?
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP1620.html
there was recent celebration of 50th anniv. of 1401 at computer history
museum ... there is also this article ... which includes comment from
somebody mentioning working on a 1401 located in marine truck in vietnam
(1967)
http://spectrum.ieee.org/computing/hardware/rebuilding-the-ibm-1401
I had sponsored Boyd's briefings at IBM in the 80s. Boyd's biographies
has him in 1970 doing a year stint in charge of "spook base" ... a
$2.5B(!) windfall for IBM ... although even that was probably not enuf
to offset the cost of the failed future system effort
http://www.garlic.com/~lynn/submain.html#futuresys
and/or the resulting impact that the failure had on the corporate
culture.
misc. past posts mentioning Boyd:
http://www.garlic.com/~lynn/subboyd.html#boyd1
misc. URLs from around the web mentioning Boyd:
http://www.garlic.com/~lynn/subboyd.html#boyd2
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
Anne & Lynn Wheeler
lefu...@SBCGLOBAL.NET (Lloyd Fuller) writes:
> 360/30s with < 256K. Full 2314 = 8 x 800K. I am not sure how many
> tape drives, but they were the old 7-track probably 800 BPI.
>
> One or two of them might have been 360/40s. But all of the ones that
> I saw in trailers were mod 30s. As far as I know, they all ran DOS:
> the first DOS not DOS/VS since they were 306s. I think they ran
> Power, but I am not sure.
re:
http://www.garlic.com/~lynn/2009r.html#14 "Portable" data centers
previously referenced page (announce & FCS):
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360.html
"page 2" for above:
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360B.html
available store sizes
360/30 ... 16k-64k
360/40 ... 32k-256k
2311s were single drive ... top loader, picture here:
http://en.wikipedia.org/wiki/Early_IBM_disk_storage
1316 disk pack for 2311 ... 7.25mbytes (above says same disk pack used
in earlier 1311 drives)
2314 had 9 drives ... only 8 addressable ... each pack was 29.2mbytes
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2314.html
there were address "plugs" ... possible to open drawer for 9th/spare
drive, put in new pack ... get it powered up ... and pop out the address
plug from one of the other drives and pop it into drive with newly
mounted disk. slightly reduced latency that the system saw when changing
packs.
2400 tape drives, 9trk 800bpi ... could order 7trk model (for handling
older tapes) ... 7trk could select 200bpi, 556bpi, & 800bpi.
http://en.wikipedia.org/wiki/IBM_7_track
360/30 system details with 2400 tapes and 2311 disk drives
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2030.html
i made some contributions to an "online" version of the green card
(sense bytes section) ... done in ios3270. except for the A220
information, the sense information was taken from the 360/67 "blue" card
(had information about features unique to 360/67 ... and rest filled out
with sense information).
I've done a q&d hack on the ios3270 to html
http://www.garlic.com/~lynn/gcard.html
360 channel program tape command codes
http://www.garlic.com/~lynn/gcard.html#25
above has "mode-set" for 7track.
ios3270 was standard package on vm370/cms.
for the 3090 service processor ... it started out with 4331 running a
highly customized version of vm370 release6 with the service panels all
done in (cms) ios3270. by first-customer-ship ... the "4331" service
processor had been upgraded to a pair of 4361s.
DOS/VS was for virtual storage. 370 was initially announced w/o virtual
memory (just a few new instructions, TOD-clock, a few other things).
for entry & mid-range machines, it wasn't too bad to add virtual memory
... but the hardware to add virtual memory to 370/165 became a real
problem. Eventually there was a proposal to eliminate some number of
the original 370 virtual memory features ... which would buy 370/165
schedule six months (concurrent announce and ship of virtual memory for
all models at the same time). The problem then became, for the other 370
models ... to go back and remove the 370 virtual memory features that
were being dropped for 370/165 (and any software that had already been
written to utilize the dropped features had to be rewritten).
for other drift ... "spook base" ... from Boyd biographies ... or
"NKP" discussion
http://www.airforce-magazine.com/MagazineArchive/Pages/2004/November%202004/1104igloo.aspx
the above only mentions two 360/65s ... which could hardly account for
the $2.5B mentioned in Boyd biographies. The above also mentions frogs
generating false positives ... but i've heard stories of other animals
also.
another NKP reference
http://home.att.net/~c.jeppeson/igloo_white.html
Boyd references his stint at NKP in his "Organic Design for Command and Control"
http://www.d-n-i.net/dni/john-r-boyd/
power point version
http://www.d-n-i.net/boyd/organic_design.ppt
above states it is taken from "original" 1987 version scan'ed to pdf.
I believe the original, original version was given at 1983 briefing I
sponsored at ibm ... from which I still have several hardcopies ... a
few pages I transcribed in this old posting (including NKP reference)
http://www.garlic.com/~lynn/94.html#8
i've done some quick searches for other references to use of mainframes
in that time & place ... but not a whole lot show up.
Anne & Lynn Wheeler
>>for the 3090 service processor ... it started out with 4331 running a
>>highly customized version of vm370 release6
>
> internally by the time the 3090 came out.
>
>>DOS/VS was for virtual storage. 370 was initially announced w/o virtual
>>memory (just a few new instructions, TOD-clock, a few other things).
>
> implementation of the DOS Emulator Feature only made sense if the hardware
> was designed for paging.
re:
http://www.garlic.com/~lynn/2009r.html#18 "Portable" data centers
the modifications for vm370 release 6 to be service processor started
well before 3090 came out. it was a copy of standard vm370 release 6
(predates vm/sp) and then "frozen" (with respect to the standard
product) and then various enhancements added ... like interfaces to all
the diagnostic hardware that was going to be in the 3090. i provided
some number of tools and other stuff, supporting the effort. Some of the
stuff was things I had done for the disk engineering & product test labs
... to eliminate large class of failures (they had been running
stand-alone with trivial monitor ... after having tried to use MVS and
experienced 15min MTBF with a single "testcell"):
http://www.garlic.com/~lynn/subtopic.html#disk
At the time they had started the effort ... they gathered up as much
stuff as they could ... anticipating that vm370 release 6 ... would not
be current thru the lifetime of the 3090; TROUT ... some past posts with
other old email from TROUT period:
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
i was blamed for onlined computer conferencing on the internal network
in the late 70s and early 80s. The POK engineering manager that headed
up the 3090 service processor ... had observed all the issues with the
3081 service processor ... having to write everything from scratch and
was a big proponent of using as much as possible readily available tools
(i.e. 3090 service processor screens were actually CMS IOS3270). In any
case, the guy heading up the effort also became somewhat active in some
of the computer conferencing and took some amount of hits for the
activity (although not nearly as much as I did). He also took hits on
scope-creep in the effort and growing demand for people and resources.
DOS Emulator feature had base/bound (significantly simpler than all the
segment and page table stuff; just check the address against the "bound"
... and then add in the "base") ... not for paging but for address
translation ... like some LPAR implementations ... still required a
contiguous amount of real-memory.
I was undergraduate in the 60s ... but still doing a lot of work on both
os/360 (responsible for academic and administrative system at the
univ. ... including doing highly customized os/360 system for careful
placement of datasets and PDS members to optimize arm seek & getting
approx three times thruput improvement for student jobs). I was also
allowed to do a lot of cp67 ... rewritting lots of the kernel code.
Anycase, recent posts about Boeing trying to move all of their
dataprocessing into BCS (fledging BCS started out in boeing
corporate hdqtrs administrative ... which had single 360/30
for payroll):
http://www.garlic.com/~lynn/2009r.html#43 Boeings New Dreamliner Ready For Maiden Voyage
http://www.garlic.com/~lynn/2009r.html#44 Boeings New Dreamliner Ready For Maiden Voyage
http://www.garlic.com/~lynn/2009r.html#45 Boeings New Dreamliner Ready For Maiden Voyage
and I got dragged into it. I was con'ed into giving one week class
(during spring break, '69) to the fledging BCS technical staff (and the
ibm technical support team). I was then brought in as full-time BCS
employee for the summer of '69. Part of responsibility was installing
cp67 operation in corporate hdqtrs machine room (which until then just
had a 360/30 for payroll). Part of BCS was to take over the renton
datacenter (a little corporate internal politics) ... which was the
largest operation I had seen ... summer of '69 there were always pieces
for 2-3 360/65s staged around in the hallways ... because 360/65s were
arriving faster than they could be installed.
In any case, after 370s were available ... but not yet with virtual
memory support ... one of the IBM SEs on the boeing account did a
"hacked" version of cp67 to use 370 DOS Emulator (aka address
base+bound, contiguous real storage) ... again much more like LPAR
support. He did do complete swap of a virtual machine address space
(i.e. virtual machine size had to match the base+bound contiguous area)
... so could run more virtual machines that there was total real storage
available.
As mentioned in the above ... summer of '69 ... Boeing also moved the
360/67 multiprocessor from Huntsville to Seattle (this was separate from
the 360/67 uniprocessor installed in corporate hdqtrs). Huntsville had
been using it to run a highly modified version of MVT release 13.
Problem was that MVT had significant problem with storage fragmentation
with long running jobs. Huntsville had a large collection of 2250s with
long running graphics application. Hack to MVT was to use the 360/67
address translation hardware to re-arrange real storage to appear
"contiguous" (no paging) ... this was different than the early 370 hack
to cp67 to use the base+bound (instead of full address translation) and
real contiguous storage for primitive virtual machine swapping.
Before virtual memory was announced, 370/145s weren't shipped with the
microcode-load to support virtual memory ... however, the front panel
"rollers" for the PSW ... had a "xlate" label for one of the bit/lights.
for other topic drift, recent post about science center working with
endicott on support 370 virtual memory architecture ... before hardware
was even available:
http://www.garlic.com/~lynn/2009r.html#38 While watching Biography about Bill Gates on CNBC last Night
http://www.garlic.com/~lynn/2009r.html#39 While watching Biography about Bill Gates on CNBC last Night
http://www.garlic.com/~lynn/2009r.html#40 While watching Biography about Bill Gates on CNBC last Night
science center worked with endicott to modify cp67 (running on 360/67)
to provide support for 370 virtual machines. This required having a
"370" option ... and then simulating new instructions and misc. other
stuff for "370" virtual machinesl
Then a "different" cp67 was modified to run in those "370" virtual
machines (rather than on 360/67, this "CP67I" was regularly running in
370 virtual machine a year before hardware became available). This
370'ized cp67 was used by endicott for testing ... when they had an
engineering 370/145 with first virtual memory hardware working.
other lore ... unbundling announcement was 23jun69 ... misc. past
posts
http://www.garlic.com/~lynn/submain.html#unbundle
and they started charging for application software, SE services, other
stuff ... but managed to make the case that kernel software was still
free.
one of the things I did as undergraduate at the univ. was add tty/ascii
support to cp67. Part of that was trying to make the 2702 do something
that it couldn't really do. Somewhat as a result, the univ. started
a clone controller effort ... where the channel interface was reverse
engineered and channel interface board built for an Interdata/3. The
Interdata/3 was then programmed to simulate 2702 (but with the
additional stuff I wanted to do). This got written up, blaming four
of us for clone controller business
http://www.garlic.com/~lynn/subtopic.html#360pcm
Clone controller business has been cited as major motivation for the
"future system" effort ... which was going to completely 360/370 ...
and as different from 360/370 as 360 had been from prior generations.
some past posts
http://www.garlic.com/~lynn/submain.html#futuresys
Eventually FS effort was killed ... but during the effort ... the 370
product pipeline was allowed to dry up (since it was going to be
completely replace) ... and when it was killed there was mad rush to get
stuff back into (hardware & software) 370 product pipeline. The lack of
products was also credited with allowing clone processors to gain a
foothold in the market.
I had done a lot of stuff for cp67 as undergraudate ... that was picked
up and shipped in the product. For the morph from cp67->vm370 much of
that was dropped as "simplification". Now, all during the future system
effort, I continued to do 370 stuff (and ridiculed pieces of the FS
activity ... which wasn't exactly a career enhancing thing to do, since
the senior executives were still senior executives after the dust
cleared). Misc. old email about 370 stuff:
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430
so the mad rush to get stuff back into the product pipeline, included
picking up some stuff that I had continued to do (a lot that had been
dropped in the morph from cp67->vm370). Some of it was incorporate in
standard product releases ... however a portion was selected to be
release as a separate "resource manager" component. And then, somewhat
motivated by the clone processors foothold in the market ... it was
decided to start transition to charging for kernel software ... and my
"resource manager" was selected to be the guinea pig. As a result I had
to spend some amount of time with lawyers and busines people about
kernel software charging policies.
vm370 release 6 "product" then was towards the end of this transition
... the base product was free ... but there was BSEPP (entry &
mid-range, aka endicott machines) & SEPP (high-end, pok machines)
chared-for "add-ons".
In any case, There was no vm370 release 7 ... the next release was all
"charged for" and called VM/SP release 1 (no separate kernel free and
non-free, it was all non-free). Then the next stage was the OCO-wars
... not only charged-for ... but no longer shipping full source ... and
providing full source maintenance on monthly PLC service tapes.
Another result of the unbundling announcement ... was major blow to SE
education ... basically apprentice type operation as parge of SE team at
customer account (couldn't figure out how to justify charges for this
activity ... but required to). This was original motiviation for
HONE ... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#hone
... allow SEs in the branch office to play with operating systems in
cp67 virtual machines. After initial 370 announcement ... the
non-virtual memory 370 "changes" (few new instructions, other stuff) was
incorporated into the HONE cp67 systems (allowing ipl of 370 operating
systems gen'ed to use the new instructions).
Anne & Lynn Wheeler
> I had done a lot of stuff for cp67 as undergraudate ... that was picked
> up and shipped in the product. For the morph from cp67->vm370 much of
> that was dropped as "simplification". Now, all during the future system
> effort, I continued to do 370 stuff (and ridiculed pieces of the FS
> activity ... which wasn't exactly a career enhancing thing to do, since
> the senior executives were still senior executives after the dust
> cleared). Misc. old email about 370 stuff:
> http://www.garlic.com/~lynn/2006v.html#email731212
> http://www.garlic.com/~lynn/2006w.html#email750102
> http://www.garlic.com/~lynn/2006w.html#email750430
re:
http://www.garlic.com/~lynn/2009r.html#49 "Portable" data centers
in the early 80s, I wrote a "open door" about my salary and being
underpayed. After a couple weeks, I got back a written response from HR
saying that they had studied my completely employee history and I was
being payed exactly what I was suppose to.
This was about the time I was being asked to interview new hires
... supposedly to work in a new group under my (technical)
direction. They told me what HR was offering them as starting salaries.
I then wrote I follow-up to HR's response ... pointing out that they
were offering starting salaries to these new hires that was 1/3rd more
than I was currently making.
A couple weeks later I got the first of a series of raises that would
eventually bring me up level to starting salaries that HR was offering
the new hires that I was interviewing. It was (then) fairly obvious that
HR's initial response wasn't true.
old post mentioning being told "never forgive you for being right"
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
misc. recent posts referencing "business ethics is oxymoron", Boyd's "to
be or to do", and/or the "never forgive you for being right" quote:
http://www.garlic.com/~lynn/2009.html#53 CROOKS and NANNIES: what would Boyd do?
http://www.garlic.com/~lynn/2009b.html#25 The recently revealed excesses of John Thain, the former CEO of Merrill Lynch, while the firm was receiving $25 Billion in TARP funds makes me sick
http://www.garlic.com/~lynn/2009e.html#37 How do you see ethics playing a role in your organizations current or past?
http://www.garlic.com/~lynn/2009g.html#56 Old-school programming techniques you probably don't miss
http://www.garlic.com/~lynn/2009h.html#5 mainframe replacement (Z/Journal Does it Again)
http://www.garlic.com/~lynn/2009h.html#71 My Vintage Dream PC
http://www.garlic.com/~lynn/2009h.html#74 My Vintage Dream PC
http://www.garlic.com/~lynn/2009k.html#73 And, 40 years of IBM midrange
http://www.garlic.com/~lynn/2009o.html#47 U.S. begins inquiry of IBM in mainframe market
http://www.garlic.com/~lynn/2009o.html#52 Revisiting CHARACTER and BUSINESS ETHICS
http://www.garlic.com/~lynn/2009o.html#57 U.S. begins inquiry of IBM in mainframe market
http://www.garlic.com/~lynn/2009p.html#34 big iron mainframe vs. x86 servers
http://www.garlic.com/~lynn/2009p.html#60 MasPar compiler and simulator
http://www.garlic.com/~lynn/2009q.html#37 The 50th Anniversary of the Legendary IBM 1401
http://www.garlic.com/~lynn/2009q.html#38 The 50th Anniversary of the Legendary IBM 1401
http://www.garlic.com/~lynn/2009r.html#6 Have you ever though about taking a sabbatical?
Anne & Lynn Wheeler
rfoc...@YNC.NET (Rick Fochtman) writes:
> IIRC, the DAT box was optional on the 370/145 and became standard on
> the 370/148. Ditto the 370/155 and 370/158 and 370/165 and
> 370/168. The 168 was unique in the 370 series because it used outboard
> channels; as I recall , it was the only 370 that did so.
re:
http://www.garlic.com/~lynn/2009r.html#14 "Portable" data centers
http://www.garlic.com/~lynn/2009r.html#18 "Portable" data centers
http://www.garlic.com/~lynn/2009r.html#49 "Portable" data centers
http://www.garlic.com/~lynn/2009r.html#50 "Portable" data centers
most 370/145s could have 370 virtual memory enabled with just
a different microcode load.
the real bear was all the hardware needed to upgrade a 370/165 for
virtual memory. this was so difficult that 370 virtual memory
announcement was slipping ... finally there was a case made to drop
several features from the 370 virtual memory architecture ... in order
to buy back some of the 370/165 schedule slippage. this required other
models that already had full virtual memory running ... to remove the
dropped features. also software that had already been written to utilize
the full 370 virtual memory features had to be redone.
370/148 (& 138) had additional storage for microcode and there was big
push to add operating system microcode enhancments ... to help
differentiate the 138/148 from some of the clones (especially in world
trade countries). As referenced in these recent posts ... I got
talked into doing a lot of the work for ECPS
http://www.garlic.com/~lynn/2009r.html#17 How to reduce the overall monthly cost on a System z environment?
http://www.garlic.com/~lynn/2009r.htmL#38 While watching Biography about Bill Gates on CNBC last Night
this old post has some of the kernel analysis that was used in choosing
what went into ECPS microcode:
http://www.garlic.com/~lynn/94.html#21
I also got dragged into lots of the product planning meetings for
138/148 with business meetings at various world trade locations
(positioning 138/148 against clones in foreign markets). endicott was on
its way to making 370/148 a product offering that came with vm370
pre-installed with everything running under vm370 (regardless of
whatever else the customer ran ... a little like current LPAR
environment). this was vetoed by corporate hdqtrs when POK convince
corporate that vm370 product was to be killed, the burlington mall
development group shutdown and all the people moved to POK ... as
necessary in order to make the mvx/xa ship schedule. endicott eventually
managed to save the vm370 product mission ... but essentially had to
reconstruct a development group from scratch (but too late to make vm370
come preinstalled on all 148s).
the issue in the entry & mid-range machines was that 370 instructions
were simulated in native micro-engine instructions ... tended to
avg. approx. ten native instructions for every 370 instruction. ECPS was
able to drop 370 kernel instructions into native instructions at nearly
1:1 ... resulting in ten times speedup. In some cases, when something
similar was attempt for POK "high-end" machines ... there were cases
where it actually ran slower ... the problem was that the hardware had
been optimized to the point that 370 instructions were running at nearly
full hardware speed (already). Even the later SIE had some scenarios
where it would run slower than direct kernel 370 code. Some of this
is touched on in this previously mentioned old email
http://www.garlic.com/~lynn/2006j.html#email810630
in this post
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
that discusses some of the difference between the 3081 SIE and 3090 SIE
implementation. There was even scenarios were the 3081 service processor
had to perform "microcode" paging operations (using a 3310/piccolo FBA
device).
there was 370/195 with outboard channels (basically an upgraded of
360/195 with few additional instructions ... but never got any of the
virtual memory support upgrade).
165 & 168 had outboard channels. 370/158 had integrated channels. for
303x ... the 303x (outboard channel) channel director was a 370/158
engine with the integrated channel microcode ... but w/o the 370
instruction set microcode. A 3031 ... then was two 370/158 engines ...
one with the integrated channel microcode (but w/o 370 instruction set
microcode) and a processor (with the 370 instruction set microcode but
no integrated channel microcode). A 3032 ... was a 370/168 with new
covers ... and reconfiguration to use the 303x channel director as its
outboard channels. A 3033 started out being 370/168 wiring diagram
mappped to chips that were about 20% faster (which would have resulted
in machine about 20% faster than 168-3). The chips also had about ten
times the circuits per chip ... that were going to be left
unused. Before 3033 shipped there was effort to redo critical sections
of 168 logic to better utilize the extra circuits (picking up speed by
doing more things "on-chip" ... rather than the latency of going
"off-chip). The 3033 eventually shipped about 50% faster than 168-3.
sjr/bldg.28 was still running an aging MVT 370/195 system when the
bldg.15 disk product test lab got an early engineering 3033. Carefully
pipelined ... 370/195 would peak at about twice 3033 sustained thruput
... however most codes ran about same thruput on 370/195 as 3033. The
batch turn-around on the MVT system could be a couple weeks ... even for
some things like the air-bearing simulation program that was part of
3380 disk head design. getting to play disk engineer in both bldg14 disk
engineering and bldg15 disk product test ... and providing them an
operating system ... so they could do on-demand testing of multiple
testcells simulataneously ... allowed me some latitude in running other
types of applications on those machines (even several testcell testing
load was only couple percent of processor ... since it was strictly i/o
intensive) ... aka previously disk testcell testing, running
stand-alone, was prescheduled around the clock, one testcell at a time.
In any case, was able to move the air-bearing simulation work over to
the 3033 in bldg15 ... and provide on-demand compute intensive service.
misc. past posts mentioning getting to play disk engineer
http://www.garlic.com/~lynn/subtopic.html#disk
Anne & Lynn Wheeler
> 138/148 with business meetings at various world trade locations
> (positioning 138/148 against clones in foreign markets). endicott was on
> its way to making 370/148 a product offering that came with vm370
> pre-installed with everything running under vm370 (regardless of
> whatever else the customer ran ... a little like current LPAR
> environment). this was vetoed by corporate hdqtrs when POK convince
> corporate that vm370 product was to be killed, the burlington mall
> development group shutdown and all the people moved to POK ... as
> necessary in order to make the mvx/xa ship schedule. endicott eventually
> managed to save the vm370 product mission ... but essentially had to
> reconstruct a development group from scratch (but too late to make vm370
> come preinstalled on all 148s).
re:
http://www.garlic.com/~lynn/2009r.html#51 "Portable" data centers
there was a joke about the head of POK being a major contributor to
vax/vms ... because so many people didn't move to POK (when burlington
mall location was shutdown) ... but left and went to work for DEC.
other trivia ... the cp67 group split off from the science center ... on
4th flr of 545 tech
http://www.garlic.com/~lynn/subtopic.html#545tech
and took over the (IBM) boston programming group on the 3rd flr (both
space and many of the people). As it expanded into vm370, it outgrew the
3rd flr and moved out into the vacated SBC bldg in burlington mall (had
become vacant as part of the transfer of service bureau corporation to
CDC).
IBM boston programming group only had a portion of the 3rd flr ... the
rest of it was occupied by a group listed on the bldg. directory as a
law firm. However, the phone closet for the 3rd flr was on the IBM side
of the flr ... and the phone company had written the organizations name
on the boxes ... and the other side of the 3rd flr as listed as a
3-letter fed. gov. agency.
this was back in the days of lots of demonstrations in the boston and
cambridge area. One day, one of the groups phoned the FBI office in
boston and said that there was a bomb in the boston area office bldg
that had certain "3-letter" gov agency. they then had people stationed
all over the area on the lookout for what bldg. got evacuated.
jmfbahciv
<snip ref-list>
There were a couple of people who left DEC, worked for a year and
then were rehired back for the sole purpose of getting a "raise".
/BAH
Anne & Lynn Wheeler
> 360/195 with few additional instructions ... but never got any of the
> virtual memory support upgrade).
> sjr/bldg.28 was still running an aging MVT 370/195 system when the
> bldg.15 disk product test lab got an early engineering 3033. Carefully
> pipelined ... 370/195 would peak at about twice 3033 sustained thruput
> ... however most codes ran about same thruput on 370/195 as 3033. The
re:
http://www.garlic.com/~lynn/2009r.html#51 "Portable" data centers
370/195 was pipelined and to get peak sustained thruput ... just about
had to be carefully constructed loops totally within the pipeline.
370/195 didn't have branch prediction or speculative execution ... so
(a non-carefully constructed pipeline looping branch) would drain the
pipeline. most codes had frequent branches keeping the pipeline from
being more than half-full and running at half peak thruput (or about the
same as 3033).
the 370/195 group came up with idea for hyperthreading ... basically
emulate two processor smp ... with two PSWs, two sets of registers, etc.
... but no additional pipeline or execution units. the idea was if
single execution stream only kept the pipeline half-full at half-thruput
... then two independent execution streams might be able to keep the
pipeline full and the execution units fully busy.
i got invited to participate because of other work on smp. however,
the effort never got as far as even being announced.
for other drift ... one of the nails in the "future system" coffin
http://www.garlic.com/~lynn/submain.html#futuresys
was analysis that if a FS machine was built from 195 technology
... applications running on such a machine would have thruput of 370/145
(that was one of the FS sections that had a complete enuf definition
that analysis could be perform ... lots of the other FS was so
inadequately defined that couldn't be analyzed). The actual comparison
was Eastern Airlines reservation system (System/one), optimized for
running on 370/195 ... the comparison pointed out that the best thruput
it could expect to achieve (on the highest performance FS system) was
that of running on 370/145
another site of some hardware & FS discussion from
the FS period:
http://www.jfsowa.com/computer/memo125.htm
a few misc. tidbits from above:
Whereas the Model 168 had required 40 months to evolve from development
to initial shipment, the 3033 was shipped to its first customer after
only 28 months in development." IBM achieved that feat by remapping the
Model 168 design into the circuitry intended for VANDERBILT and making a
number of tweaks in the design to improve performance. Of course, IBM
could have delivered a machine with similar or better performance in
1975 instead of 1977, if they hadn't killed all the System/370 design
projects to avoid competition with the FS fantasy.
... snip ...
later the Eastern Airline res system was the basis for Amadeus ... and
my wife severed a short stint as chief architect. Unfortunately she
sided with the selection of x.25 (over sna) ... and the SNA forces
managed to have her replaced. However, it didn't do them any good, since
Amadeus went with x.25 anyway ... a couple recent posts mentioning
Amadeus
http://www.garlic.com/~lynn/2009j.html#33 IBM touts encryption innovation
http://www.garlic.com/~lynn/2009l.html#55 IBM halves mainframe Linux engine prices
Anne & Lynn Wheeler
chris...@BELGACOM.NET (Chris Mason) writes:
> I believe it really worked only if the customer had ordered and taken delivery
> of the said machine types at or shortly after announcement. Any who had
> ordered and taken delivery just before the 370/158 and 370/168 were
> announced was still entitled to be spitting blood.
big problem was that 370/165 hardware changes to add virtual memory was
turning out to much bigger job ... and it was holding up virtual memory
announcement. eventually they had to drop several features in the
original 370 virtual memory architecture ... in order to help out the
370/165 hardware implementation and speed up the announcement. then the
other hardware groups had to eliminate the dropped features ... and some
of the software groups that had done implementations using the new
features ... had to go back and figure out other ways of doing things.
big change going from 155/165 to 158/168 was different real storage
technology that was more compact/smaller and about 4-5 times faster.
The 168 microcode engineers also point out that they reduced the
avg. machine cycle/370 instruction from (370/165) 2.1 machine cycles to
(370/168) 1.6 machine cycles.
the faster memory met than when there was a cache miss ... that
the machine waited shorter time for the data.
the low/mid range 370s had "vertical microcode" engines ... more like
familiar computers ... and implementation tended to avg. ten native
instructions per 370 instruction (some simularity to current day
software mainframe simulators running on intel platforms).
high end 370s had "horizontal microcde" engines ... where the "native"
instruction could start lots of different operations in parallel ... as
a result there was some amount of overlap in things that were going on
... and so instead of measure native instructions per 370 instruction
... it was avg. machine cycles per 370 instruction.
part of the issue was that there was an early joint project between the
science center and endicott to modify cp67 to provide full 370 (virtual
memory) virtual machines running on 360/67 (i.e. some of the new
instructures and some format differences between 360/67 virtual memory
tables and 370 virtual memory tables). This was "cp67h" system (running
on 360/67). Then there was modifications to cp67 to run on 370 virtual
memory ("cp67i"). The cp67i system was regularly running in 370 virtual
machine a year before any real 370 virtual memory hardware became
available. In fact, booting/ipling cp67i was originally used to verify
very first engineering machine with virtual memory hardware (370/145).
for a long period it was cp67i that was running on all of the increasing
nuumbers of internal 370/145s with virtual memory (and later "cp67sj"
... which as "cp67i" with support for 3330 & 2305 devices ... added by
san jose).
recent x-over post from a.f.c about this early period with cp67i
http://www.garlic.com/~lynn/2009s.html#1 PDP-10s and Unix
Anne & Lynn Wheeler
rfoc...@YNC.NET (Rick Fochtman) writes:
> In re the 165, 165 II and 168, you're quite right. I don't consider
> the 370/195 to be a true s/370, inspite of the marketting blurbs.
>
> Is it worthwhile to split the hairs so finely? As long as the general
> idea gets across? This is all ancient history, mostly of interest to
> us "old timers".
360/195 to 370/195 added the new instructions for the original 370
announcement. it also added some amount of (370) instruction retry (that
wasn't in 360 flavor ... justification was that 195 had so many discrete
components that even fairly reliable MTBF individual items ... there was
so many ... that the MTBF probability for any piece became
problematical. instruction retry significantly helped with some number
of transient errors. the 195 group feed me all this when I was con'ed in
to helping them look at doing a "SMP" (actually hyperthread) 370/195.
retrofitting virtual memory to 370/165 was extremely difficult ... in
fact, some number of features in 370 virtual memory had to be dropped to
make 370/165 easier/possible/timely.
retrofitting virtual memory to 370/195 would have been significantly
more difficult.
misc. recent posts mentioning 370/195
http://www.garlic.com/~lynn/2009m.html#34 IBM Poughkeepsie?
http://www.garlic.com/~lynn/2009m.html#75 Continous Systems Modelling Package
http://www.garlic.com/~lynn/2009o.html#11 Microprocessors with Definable MIcrocode
http://www.garlic.com/~lynn/2009p.html#82 What would be a truly relational operating system ?
http://www.garlic.com/~lynn/2009r.html#51 "Portable" data centers
http://www.garlic.com/~lynn/2009r.html#59 "Portable" data centers