In a message dated 5/5/2006 9:08:28 A.M. Central Daylight Time, [EMAIL PROTECTED] writes:
>If I recall, there is "end of extents" checking that happens whenever you >cross an extent boundary; Limits were always and still are placed on how far a multi-track search key command could search while looking for the directory block that should contain the member info if that member is within that given PDS (in case of concatenating more than one PDS). The end of extent checking is done in the control unit. The only real software performance hit inside the LPAR would occur if the extent containing the directory were not allocated on a cylinder boundary and CKD channel programs were used (they were in the old days). The exact nature of the hit was that on average 1/2 track revolution was necessary before the search could begin; then the whole track had to be searched; end of track was sensed before the directory block was found; an I/O error was signalled; I/O error recovery issued a Sense command and found the condition was an expected one rather than a hard error; the seek address was updated to the next track X+1 in the directory extent; the I/O was restarted; maybe you would be lucky and get that next I/O started before the track had rotated very far, but if not then on average 1/2 of a revolution would occur before the next full track search could be started; etc. So each track in the directory resulted in 1.5 track revolutions if you were lucky, as the directory was searched one track at a time. If on cylinder boundaries, the same series of events occurred at the end of each cylinder in a multi-cylinder directory, but the performance-impacting events occurred much less often. If there were Y tracks in a cylinder, the time to search a whole cylinder was roughly equal to (Y+1/2)*(track revolution time) + minimum seek time to the next cylinder (lots and lots of milliseconds in those old days). Nowadays an ECKD channel program is built that will never stop searching until it comes to the end of the directory, although seek time from one cylinder to the next is involved, with a subsequent necessary extra revolution of the first track of each cylinder (since the minimum seek time is greater than the track revolution time from index point to the beginning of the first directory block). That all assumes SLED. RAID is known only to the DASD vendors. >plus in the "old days" extents would cause seek >time as you moved to the location of the new extent. If the PDS was on a >very active pack and poorly allocated, you could have the first extent at >the beginning of the pack, the second near the end, then the third back >near the beginning, etcetera, resulting in what was called "thrashing the >heads". You can still have seek time performance degradation, although now such impact is impossible to predict with the RAIDing of all DASD. It was also possible in the old days to allocate a huge first extent, a small secondary extent could end up just before the first extent containing the directory, and the seek time to move the arm from the directory block containing the member's beginning TTR could be very low if the member were in the second extent as opposed to very high if that member were at the end of the first extent. The number of extents was irrelevant to this component of total I/O time. The only thing that mattered was the absolute number of cylinders to move the arm from the member's directory entry to where that member began. Another part of the total member read time that was impacted by multiple extents is when the member to be read is not wholly contained within one extent. A seek is necessary (assuming cylinder alignment of the extent) to move to the next extent containing part two of the member. A PDS member can be spread across all extents of the PDS, but the directory must be wholly contained within the first extent. Bill Fairchild ---------------------------------------------------------------------- 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
