[email protected] (DASDBILL2) writes: > In the late 1970s, I worked at a service bureau where I had to write a > tape file conversion program to reblock a tape file with 640KB blocks > to a much smaller physical block size that could be handled by QSAM. > My program read in one block with an EXCP and 10 CCWs data chained, > each of which read in 64KB bytes, all into one buffer of 640KB bytes > long. Then I copied the buffer into 20 32KB blocks to an output tape > using QSAM. Then I read the next input tape block, etc., until the > input found the end-of-file marker. It worked. But I had to run it > under MVT running under VM, and VM kept doing funny things with the > massive real channel program built by MVT's I/O Supervisor that > caused chaining checks at random places in the chain, so I reran the > job until I had an execution with no I/O errors.
re: http://www.garlic.com/~lynn/2013o.html#6 "hexadecimal"? http://www.garlic.com/~lynn/2013o.html#10 "hexadecimal"? aka MVT thinking it ran real memory, EXCP could just tic to the passed channel program ... cp67&vm370 has to make a copy of the virtual machine channel program that accounts for virtual pages that aren't contiguous in real storage (with additional data chaining and/or idals) with move of MVT to virtual memory and OS/VS2 ... EXCP was forced to do the same as cp67&vm370 ... creating a copy of the passed application channel program that could account of virtual pages that weren't contiguous in real storage. In fact the original implementation of adding virtual memory support to MVT for OS/VS2 involved hacking CP67's routine that built the copied channel programs (CCWTRANS) into the side of EXCP processing. The latencies for the additional channel overhead/processing (for the copied channel program and non-contiguous real addresses introduced with virtual memory) could result in overruns. The 370/158 channel processing throughput/overhead tended to be especially a problem (158 microcode engine was shared between executing 370 emulation and channel emulation) even compared to 370/145. similar channel latency problems then show up in all the 303x machines (even with dedicated 370/158 microcode engine for the channel processing). as part of the mad rush to get stuff back into the 370 product pipelines (after the failure of future system effort) ... the 303x channel director was created which was a 370/158 microcode engine w/o the 370 microcode and just the channel emulation. The 3031 was a 370/158 microcode engine with the 370 microcode (and w/o the channel microcode) and a separate 370/158 microcode engine as a channel director. The 3032 was 370/168 reconfigured to work with channel director. The 3033 was 370/168 logic remapped to 20% faster chips. http://www.garlic.com/~lynn/submain.html#futuresys i mentioned getting to play disk engineer in bldgs. 14&15 and one of the things that got done was profile typical channel processing latencies of the different processor models. 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 [email protected] with the message: INFO IBM-MAIN
