In a message dated 7/12/2007 2:39:10 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: >... do access methods have calculations built in for allowing for the gaps? Yes. Modern physical DASD is made by Seagate, IBM, et al, they are 3.5 inches in diameter, they are controlled as RAID, they are all FBA, and the reality is nothing at all like the CKD SLEDs described in IBM's control unit reference manuals. Anciently, when a SLED was still a SLED, gaps served two purposes: (1) control data was written in them to let the control unit know what was coming next on the track (e.g.) and (2) timing, explained in detail next. The original reason for gaps was to waste time. The control unit had to ask the channel to fetch the next CCW command code byte from central storage and give it to the control unit before the next count field, key field, or data field rotated under the read/write mechanism. Given the specific rotation speed and recording density, you can calculate how many microseconds wide was this window for fetching the next CCW. At the speed of signals through copper cables, sending many signals both ways, and the width of the window allowed by the chosen gap size, IBM's answer was that the control unit must be within 400 feet of the CPU or there would be I/O errors due to the control unit's not getting the next CCW in time. The gap is there to waste enough time in rotation so the control unit has a good chance of getting the next CCW before the piece of data upon which that next CCW command needs to act arrives and then moves past the read/write mechanism. Another source of conflict for CCW signal propagation was competing for central storage. Some early S/360 processors had inboard channels, which meant that when the channel needed to access a particular byte of central storage (e.g., for fetching a CCW) it had to compete with active jobs for enough CPU cycles to do the storage access. The use of inboard channels also necessitated wasting more rotation time with gaps. Later CPU models had outboard channels, meaning channels which did their own microcode processing and did not need to steal CPU cycles from running jobs. Channels today have entire CPUs running them due to the increased complexity of channel microcode and the high data transfer rates that must be maintained. Software access methods still assume the physical DASD is CKD, they build CCWs that act as if there were gaps and CKD on the tracks, the control units decode all these legacy CCW commands, they convert them into disk actions that reflect the reality of the physical FBA disks, the entire track is probably in high-speed control unit cache so there is no need at all for gaps, and finally they convert the I/O request's ending status back into virtual CKD status information for more legacy IOS code to use in handling any possible error. There is a LOT of code still supporting the CKD structure and CKD gaps that have not existed for perhaps 15 years now. Bill Fairchild Plainfield, IL
************************************** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour ---------------------------------------------------------------------- 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
