[email protected] (Tony Thigpen) writes: > The 4300 did not come out of Endicott. It was developed in Germany, in > the same lab that developes DOS/VSE.
As an undergraduate I do lots of work on cp67 (including to run in 256kbyte machine). The morph of cp67 to vm370, did a lot of simplification of cp67 at the same time bloating the kernel size so performance was seriously impacting running in 256kbytes. Boeblingon does 115&125 ... and at one point I get dragged into optimizing vm370 to run on 256kbyte 125 customer machines. boeblingon does 135 and 138. Then Boeblingon does 4331. Endicott had con'ed me into doing lots of work on 148, vm/370 ecps. At the same time I was helping Endicott with 148 vm370 ECPS, the 125 group also asked me to do the design and specification for a 5-way 125 SMP machine (which never shipped, it turns out the Endicott 148 people felt threaten that 5-way 125 multiprocessor would impact their market ... which put me in odd position since I was doing both). Later was dragged into doing a lot of work with regard to 4341. Across the street, the disk engineering group in bldg. 14 and the disk product test group in bldg. 15 dragged me into playing disk engineer ... some past posts http://www.garlic.com/~lynn/subtopic.html#disk the product test group in bldg 15 would typically get the 3rd or 4th engineering model for doing disk i/o testing. they got the 3rd enginneering model of 3033 and very early E4 (4341) engineering machine for testing. Because I was doing so much stuff for them, I would get lots of time on bldg. 15 system for other stuff I might want to do. The performance test marketing group in Endicott con'ed me into doing customer benchmarking on the bldg. 15 enginneering E4/4341 ... since I had bettter access to the machine ... than they had to early engineering machines in Endicott. some old email http://www.garlic.com/~lynn/lhwemail.html#43xx email includes references that when the E4/4341 originally arrived in bldg. 15 ... it had the proceessor cycle slowed down (allowed machine to work as they refined the engineering) so that the benchmarks were not as good as they could be. Later as they refined the machine, they were able to crank down the processor cycle. One of the benchmarks was for LLNL that was looking at getting 70 4341s for a compute farm (sort of the precursor to modern cluster, GRID and supercomputing). It showed 4341 was faster than 158&3031 and 4341 cluster was faster, cheaper, much less floor space and environmentals than 3033. The cluster 4341 threat to 3033 was so big that at one point, the head of POK got corporate to cut the allocation of critical 4341 manufacturing component in half. other trivia: circa 1980, there was plan to move the large variety of internal microprocessors to 801/RISC, including low&mid-range (vertical microcode) 370s, what was to be as/400, lots of controllers, etc. For various reasons that effort floundered and they continued with various CISC microprocessors. I helped somebody in endicott with white paper showing that VLSI was moving to the point, that large part of 370 could be implemented in silicon ... as opposed to having to be emulated ... which would be much faster & price/performance than pure emulation in 801/RISC (other side effect was that some number of 801/RISC engineers leave and go to work on RISC projects at other vendors). Boeblingon does 4361 (4331 follow-on) and Endicott does 4381 (4341 follow-on) in CISC. IBM was expecting that 4361/4381 would continue the enormous 4331/4341 sales explosion, but by that time the mid-range market was starting to move to workstations and large PCs. Previous posts mentions in the wake of the FS failure, there was mad rush to get stuff back into 370 product pipeline, this included 3033 (168 logic remap to faster chips) and 3081/xa kicked off at the same time http://www.jfsowa.com/computer/memo125.htm Turns out during the 3033 engineering period, I was also involved in a 16-way 370 SMP effort and we con'ed some of the 3033 processor engineers to work on it in their spare time. At first everybody thot it was really great effort, and then somebody tells the head of POK that it could be decades before MVS had effective 16-way support ... and he then invites some of us to never visit POK again ... and tells the 3033 processor engineers to stop being distracted by other activities. With the 3033 out the door, the 3033 processor engineers start work on trout1.5 (aka 3090, in parallel with ongoing 3081/xa) circa 1980. Part of the 3090 effort was to use 4331 as service processor running a highly modified version of vm370 release 6 ... and I periodically get dragged into that effort. The 3090 service processor eventually gets upgraded to pair of 4361s running highly modified version of vm370 release 6 ... a couple (later) old email references http://www.garlic.com/~lynn/2010e.html#email861031 http://www.garlic.com/~lynn/2010e.html#email861223 Early days of REXX (well before ships to customers), I wanted to demonstrate it wasn't just another pretty scripting language ... and chose to rewrite IPCS all in REXX as demonstration. At the time, IPCS was a enormous amount of assembler code. I set to rewrite IPCS all in REXX, with ten times the function and ten times the performance, working half time over three months. I finished early and so started doing library of automated analysis that would look for typical failure mode signatures. I had expected that when REXX shipped to customers, my rewritten IPCS would also ship to customers (it was by then in use by early all internal datacanters and customer support PSRs). I did get permission to make presentations on my rewrite of IPCS at customer user group meetings (and within couple weeks, similar implementations started to appear at customer shops). In any case, the above 3092 (aka 4361) email references was about picking up my IPCS rewrite and shipping as part of standard 3092. Some past posts mentioning IPCS rewrite http://www.garlic.com/~lynn/submain.html#dumprx -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
