Thanks to Don and other responders. It turns out that our performance guru Tom Buie has already spoken with Don, so some basics are covered. As to other questions:
- The unused ESCONs are indeed offline. - They have little black thingies on them. Which are not 'terminators' in the bus-and-tag sense, I'm told, just dust covers. - The 'retry' data comes from Type 78 records. - We're on z/OS 1.7 with current maintenance. The current plan is to remove the ESCON cards and POR to get a redistribution of channels across the SAPs. Someone suggested Ebay for disposition of the cards, but I voted to donate them to Dick Cheney for target practice. Give his buds a break. ;-)) . . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] IBM Mainframe Discussion List <[email protected]> wrote on 03/01/2006 02:28:59 PM: > <snip> > We're getting reports from RMF of excessively high I/O retries on some > systems. In one case, we've seen the number of retries go higher than the > actual number of I/Os! > ></snip> > > It certainly is possible that the number of retries could be larger than > the number of Start I/O commands. I have some data in one of the PDBs sent > to me by a CPExpert user that show this particular site had between 5 and > 12 retries for the average start I/O instruction. > > > > ><snip> > >- Reports do not detail the I/Os being retried by channel or device; just > >a total number > </snip> > > What release are you on? With z/OS V1R4, Type 78(3) records describe > causes of retries. See: > R783ICPB Number of times an I/O was retried due to channelpath busy. > R783IDPB Number of times an I/O was retried due to director port > busy. > R783ICUB Number of times an I/O was retried due to controlunit busy. > R783IDVB Number of times an I/O was retried due to device busy. > > In most data that I've looked at, the retries have been due to path busy, > but YMMV. > > > > >- No channel looks excessively busy according to RMF > >- We see this on more than one CEC (all z900) > >- SAP/IOP processors are 'unbalanced' > > > >This last point might be an issue. We have a fairly large number of now > >unused ESCON channels whose function has moved over to FICON. It appears > >that the three SAPs divide up all channels among themselves, but one of > >them--which happens to have the most idle channels--is less than half as > >busy as the other two. Maybe we need to physically remove the unused > >channels in order to redistribute the SAPs more evenly across the active > >channels. > > > When the distribution of I/O activity to the SAPs and to the channels is > very imbalanced, it is increasingly likely that path busy can cause a very > large number of retries. > > Have you read IBM zSeries 900 Technical Guide (SG24-5975-01)? Section > 2.6.6 ("Channels to SAP assignment") describes the assignment process with > z900. Note that this assignment is done at activation time and is simply > based on spreading the channels across SAPs (and, of course, the assignment > has no intelligence about the prospective activity among the channels). > > I have SMF data from some of my users that show 70-85% of I/O activity to a > single SAP (with 3 SAPs available). > > Don ---------------------------------------------------------------------- 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
