In a message dated 10/6/2005 11:39:54 A.M. Central Daylight Time, [EMAIL PROTECTED] writes:
>Unless I have my head on backwards today (it happens), search with key or similar >operations which cannot be converted to ECKD, cause large CONNECT time, not >disconnect, since they are essentially a CCW loop (SEARCH, TIC) which remains >connected to the channel. Your head is right on. On SLED controllers, any search operation requires that data be sent from central storage to the controller (the search operand, whether ID or key field) which then compares that data from central storage to data that is read off the track. Sending data to or from central storage always requires being connected. The TIC in a search loop does not cause disconnect, so the channel will stay connected until the search is satisfied or broken because (1) index point is detected twice for the same track (meaning the control unit knows it has unsuccessfully searched the same whole track at least once), (2) end of cylinder is reached, (3) end of extent is reached (if ECKD), or (4) end of volume is reached. When the search is satisfied the channel is still connected, but the next CCW after the search loop may cause disconnect. >On a cached control unit (which is all of them today), disconnect time is mostly time >spent fetching a track into cache. But not all I/Os use caching. Some access methods disable caching for certain I/Os which could account for a high percentage of cache misses. It would help if a GTF trace were available. 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
