The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[email protected] (Mike Myers) writes: > Yes, I had forgotten about SIO/HIO/TIO and was reminded of those by > your first post. I can't recall if I ever personally wrote a SIO > instruction. Most of the channel programming I ever did was at the > EXCP level, so i don't recall writing a SSCH instruction either. 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 http://www.garlic.com/~lynn/2009r.html#51 "Portable" data centers 370 introduced options for SIO/HIO ... SIO fast, Halt device, and Halt channel. when i was building an extremely robust operating systems for the disk engineering and product test labs ... one of the things was getting a controller or the 303x channel director to reset/re-impl ... as part of "severe" recovery process (never take down the system ... and require minimum of manual operations). it turns out that most controllers would reset/re-impl if you very quickly hit all of the controller's subchannel addresses with HDV (basically couple instruction loop). A 303x channel director would also reset/re-impl ... if you hit all six channel addresses with halt channel. misc. past posts mentioning getting to play disk engineer in bldgs. 14 & 15 http://www.garlic.com/~lynn/subtopic.html#disk in the move from 360/370 "real storage" to 370 virtual memory ... all the channel programs required to be hit. most access methods built channel programs with "real" storage addresses and then would execute EXCP. The 360 & 370 channels executed channel programs assuming all the addresses were "real". moving to 370 virtual memory ... all the channel programs built in application space would be referring to virtual addresses ... not real addresses. When this was passed to kernel with EXCP ... EXCP had to build shadow/duplicate channel program that substituted real addresses for the virtual addresses (as well as some housekeeping to pin the virtual pages at the real address). In cp67, this had been going on for some time ... taking the channel program from the virtual machine SIO ... and building a shadow/duplicate channel program with real addresses ... rather than virtual addresses. The routine in cp67 that performed this function was CCWTRANS. The initial work on os360 to move to 370 virtual memory ... borrowed a copy of CCWTRANS (out of cp67) to do the shadow/duplicate channel program. Part of the justification for SSCH was help with the enormous pathlength in MVS for I/O redrive ... after taking an interrupt (leaving device idle during the period). One of the other things I did for operating system for bldg. 14&15 ... was highly optimized the I/O redrive pathlength. This ran into problem with early (internal) work with 3880 disk controller. There was some early performance product acceptance test of the 3880 that met with no problem. However, when they swapped a 3830 disk controller with an early 3880 on 3033 in bldg15 (had a string of 16 3330 drives) ... things completely fell apart. I was getting yelled at that it was my fault. Turns out that 3830 had fast horizontal microcode engine ... and the 3880 had a much slower vertical microcode engine. There was some additional hardware paths in the 3880 (to handle 3mbyte data transfer) but commands and control operations were much slower. As part of making the 3880 appear as fast as the 3830 ... the 3880 started presented operation complete early ... before it was completely finished. 3880 assumed that it could finish in the delay that it took the processor to handle the interrupt ... do the other operating system gorp ... before getting back to redrive the 3880 with new operation. My optimized pathlength was hitting the controller with redrive in much shorter period ... before it had finished its cleanup. This resulted in having to present CC=1 to the SIO with SM+BUSY (controller busy). The processing then had to requeue the operation that it attempt to start (and go off and do something else). Later the 3880 had to present an additional CUE interrupt (to indicate it was no longer busy ... because of having presenting the earlier controller busy). This added all sorts of additional overhead and delay ... compared to the identical workload & 3330s using 3830 controller (instead of 3880 controller). recent post mentioning the SM+BUSY scenario and redrive latency (dedicated processor being able to handle queued i/o and much lower latency redrive operation). http://www.garlic.com/~lynn/2009q.html#74 Now is time for banks to replace core system according to Accenture -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
