l...@garlic.com (Anne & Lynn Wheeler) writes: > oops, late 80s is 25yrs ago ... not 35yrs ... finger slip.
re: http://www.garlic.com/~lynn/2012m.html#2 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#3 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#4 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#5 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee but this was 35yrs ago ... they use to let me wander around bldg 14&15 (disk engineering and disk product test) and let me play disk engineer. at the time, the machine rooms had lots of mainframes and "testcells" (individual secured wire cages ... additional layer of security inside machine rooms). They were scheduling the mainframes for stand-alone, dedicated, individual testing at a time, 7x24. They had attempted to use MVS for concurrent testing but found (in that environment), MVS had 15min MTBF hang/failure requiring manual re-ipl. I offerred to rewrite i/o supervisor making it absolute bullet-proof and never fail (allowing for arbitrary, concurrent, on-demand/unscheduled testing, greatly improvement productivity) a lot of 370xa ssch justification was to compensate for the horrible performance penalty in the MVS interrupt processing pathlength ... along with lost thruput because of long delay it took to redrive a device (with queued request) after taking interrupt. Part of bullet-proof, never fail I/O supervisor, I thought I would also demonstrate the absolute minimum, optimized, pathlength for interrupt & device I/O redrive (while at the same time not sacrificing any ras &/or integrity) ... showing that the case for ssch could be significantly reduced ... except for the enormous overhead in MVS. The first time they put engineering 3880 into production use with 16 3330 drives and live load ... the superfast redrive turned up some performance issues with the 3880 implementation. They couldn't fix all the performance issues ... but attempted to at least mask some of the issues (as I previously mentioned the slow processor in 3880 significantly drove up channel busy to perform any operation). The engineers hated having to use the slow processor ... making snide remarks about some bean-counter in the executive ranks thought it might save a few pennies. recent post mentioning high 3880 channel busy required significant increase in 3090 channels http://www.garlic.com/~lynn/2012l.html#30 X86 server I then wrote up a (internal only) report on the work, describing how to make a bullet-proof, never-fail I/O supervisor ... but also happened to mention the MVS 15min MTBF. This brought down the wrath of the MVS organization on my head (they would of had me fired if they could figure out how to do it), which would linger on for the rest of my time at IBM. Note that just prior to 3880 customer ship ... field engineering had regression error test cases that would result in requiring reipl of MVS and in 2/3rds of the cases not even recording cause of the failure. old email reference: http://www.garlic.com/~lynn/2007.html#email801015 in this post http://www.garlic.com/~lynn/2007.html#2 The Elements of Programming Style misc. past posts about getting to play disk engineer in bldgs. 14&15 http://www.garlic.com/~lynn/subtopic.html#disk -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
