The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
dpurd...@aol.com (David Purdy) writes: > Yup, Speed Matching Buffer is correct. 168 had timing issues with > state-of-the-art 3380's (STK 8380's if I remember). Worst thing was > the 168 shared DASD with a 3033 - the 168 always came in second. actually the 168 had "faster" channels than 3033. after the demise of future system effort, there was a mad rush to get stuff into the 370 software&product pipeline. ... 303x was stop-gap while they got 3081 & 370-xa moving. the 158 had integrated channels (same engine doing both 370 microcode and channel microcode). they took 158 engine with only integrated channel microcode and made it the 303x "channel director". A 3031 was then a 158 engine with only 370 microcode and a 2nd 158 engine (channel director) running only channel microcode. A 3032 as 168 reconfigured to use "channel director" as enternal channels. 3033 started out being 168 logic using 20% chips (the chips also had something like 10 times the number of circuits ... before product ship ... some amount of the logic was redone to use the larger circuits per chip and got 3033 up to 1.5 times 168 ... instead of only 1.2 times). In disk enginneering lab, I was doing channel processing overhead timings ... latency to do a "head-switch" on 3330 disk drive (read/write CCW, seak head, read/write CCW). 3330s could be formated with "dummy records" that increased inter-record gap ... allowing timing latency to insert a head-switch seek between the end of one record on a track and the start of a next record on a different track (but same cylinder). The size of the "dummy" record ... was adjusted to take into account channel processing latency. The "fastest" channel (lowest latency in terms of size of dummy record to allow for channel latency) was 168, 148, 4341, etc. The slowest was 158 (needed larger dummy record ... to account for higher latency and slower processing of 158 integrated channel). All of the 303x processing (3031, 3032, 3033) with (158 engine) channel director had identical operational characteristics to 158. Now sjr (bldg. 28 across street from bldg. 14 & 15) for a time had a 168 MVS system and a 158 VM system. All of the 3330 strings were interconnected ... but there was a "rule" that NO MVS packs would be mounted on VM-designated strings ... because the enormous performance penalty (drive, controller, channel) associated with common MVS multi-track search operations. One day, an operator, accidentially mount a MVS pack on a drive in a VM-designated string. Within 10 minutes ... the datacenter was getting irate calls from users regarding severe degraded performance. Operations initially refused to switch the pack (to MVS-designated string) until off-shift. The VM group had a VS1 sysetm that had been highly optimized ... especially for running under VM. They took the VS1 pack and placed it on a MVS-designated string ... and started up standard sequence of (OS360) multi-track searches (VTOC, PDS, etc) ... and nearly brought the MVS system to its knews (i.e. the VS1 system on a VM/158 system nearly resulting in stoping a MVS/168 system ... by being able to do better job of multitrack searches). The nearly halting of the MVS/168 system ... so slowed down the multi-track searchs on the mis-mounted MVS pack ... that the VM/158 user throughput then nearly returned to normal (even with the load of virtual VS1 keeping the MVS/168 system in check). At that point, operations decided to immediately move the mis-mounted MVS pack ... if the VM group would shutdown their virtual VS1 system. -- 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
