The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
rfocht...@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 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
