sensuixel wrote:... I tried to add some buffer (until 500) but i did not see even a slight difference, anyway i'm still reading stuff on channel programming.
And of course i don't want to compete with sort performance but at least to reduce a little the amount of I/O.
Adding buffers should not change the EXCP count when using QSAM It may reduce elapsed time a little, but that's all. By doing a great deal of effort, you may reduce the EXCP count when using EXCP, but you are not reducing the total I/O; you are just increasing the amount of I/O you are performing for each EXCP. Like I said before, you probably won't see much, if any, reduction in elapsed time.
There is a complex trade off here; it was more extreme before the days of control units with disk caches. When you do any sort of I/O it is using three real resources behind the scene: the channel, the control unit, and the device. Often, all three resources are required. By being clever, yuu, or the operating system, can reduce the use of these resources.
In a real sense, there have been four generations of DASD connectivity starting with System/360.
In the first generation, you had a "selector" channel that supported one I/O event at a time, coupled to a control unit that supported one I/O event at a time. A complete (but simplified) channel program to read one record might be -
CCW seek,disk-address,command-chain,4
CCW search ID equal,record ID,command-chain,5
CCW transfer in channel,*-8,0,0
CCW read,buffer address,0,buffer size
You, as a programmer, do not provide the first CCW: OS/360 provides it. You, as a programmer, provide the last 3 CCWS.
The channel, control unit, and device are busy for the entire duration of this channel program.
There is room for improvement here. Once issued, the device, on its own, can move the access mechanism to the right place and select the approprisate read/write mechanism, and the channel and control unit can be released so that other channel programs can use these resources. What really happened is OS/360 would run an I/O with just the first CCW. As soon as the channel and control unit sent the seek address to the device, the channel and control were free for other users. When the device completed the seek command, it notified the control unit and channel it was complete, and the channel presented an interrupt to the CPU. OS/360 would start a second real I/O with the full channel program. In other words, in first generation DASD
every disk I/O required two real I/O events; the stand-alone seek, and the complete channel program.
The next resource killer is the search ID equal command. It requires all three resources. The control unit reads the track until the next record appears at the read/write mechanism, and then compares the record ID with the record ID in CPU storage. If they are equal, the control unit (in essence) tells the channel to skip the next CCW, otherwise the next CCW executes. In concept, this businnes requires 1/2 the revolution time of the disk.
Finally, we have the read CCW. As with the search CCW, all three resources are required. The time required depends on the actual record length, unless the record length specified in the CCW is less than the actual record length.
Thr second generation sought to improve system performance. This required a new kind of channel, the block multiplexor channel, which could manage one I/O event for each device, but only do an I/O transfer at a time, control units that could manage an I/O event for each device. and a new device capability, rotational position sensing, which divides each track into a number of fixed length sectors. On command, the device can locate a specific sector without requiring assistance from the channel and control unit. The "typical" channel program becomes -
CCW seek
CCW set sector
CCW search ID equal
CCW transfer in channel,*-8
CCW read
Once the channel has sent the seek address to the control unit and device it can disconnect from the control unit, and the device can locate the sector. One the device has positioned the access mechanism, it wakes up the channel to send the sector to the device and the channel goes back to sleep. Once the device has found thew sector, the channel wakes up and we execute the search
ID equal, with (hopefully) the next record coming up almost immediately so we never actually execute the transfer in channel.
"Ah ha!" you say, "Where does the sector number come from?" A good question. You can calculate it, or you can cheat, sort of, and get the device to tell you by extending the channel program -
CCW seek
CCW set sector
CCW search ID equal
CCW transfer in channel,*-8
CCW read
CCW read count
CCW read sector
The read count command reads the count area, which contains the record ID and the record length, for the next record, The read sector command transfers the sector containing the last record to your program.
This sector stuff doesn't do you any good at all. It frees channel and control unit resources others can use
The third generation included caching controllers, which did not alter our programming, but made this sector stuff, which didn't work all that well any way, superfluous. The fourth generation is "RAID" DASD which makes serious I/O errors a thing of the past. In 1996 I was working on a program which was supposed to include very fancy I/O error recovery when I realized I was never going to see I/O errors to recover from! So I discarded the code I had written, which was just as well, since it could not be tested.
