Bill, > > I confess to ignorance of FICON details and of the acronym OE. >
OE is short for Open Exchanges. This refers to the number of Initiator => Target relationships supported by the Host Channel and the Storage Port. If volume has 4xFICON channels and 256 Alias then technically there is no reason why there cannot be 256 IO outstanding to that volume. > > IOS uses a PAV alias UCB to find the base UCB that is associated with > that > alias device number. > This base UCB has in it a matrix of up to eight CHPIDs that can be used > for > an I/O from that LPAR to that device. > There is only room in the UCB for eight CHPIDs. I used to think that > the > maximum number of I/Os that can be started > on any one LPAR to one particular device was eight, and that was > because I > assumed the Channel > Subsystem would not accept more than eight. I forgot about the > multiplexing > of multiple I/Os down > one channel. After reading your post and rereading the PoOps section > on the > I/O Start Function, it appears that > if the Channel Subsystem finds all eight (maximum possible paths to a > device) channels busy (connected), then > that I/O is queued in the CS; i.e., it remains Start Function pending. > The > CS must store this request in a queue > somewhere in its HSA control blocks, and later the CS will start the > 9th > through the n-th I/O to the same device > down whichever channel is next to indicate that it is disconnected. > No > matter how many "quasi-simultaneous" I/Os > that the CS has started to the device, however, at any one instant no > more > than eight of them can possibly be connected > to a channel path and actively transferring data. True, but once you are in IOS you are already past the UCB. That's why it is called IOS Queue :-) With ESCON there can up to eight channels on an LCU transferring data, and an even greater number of IO Disconnected while a volume's disk is seeking, queued for sibling pend, waiting for remote copy IO, waiting for dirty cache delays, delayed for XRC sidefile full, etc. > > The disconnect-reconnect capability has been present since the early > 1970s > with Block Multiplexor > Channels. Whenever a control unit sees a command in the channel > program > that could result in a > significant amount of time before that command can finish (such as a > seek), > the control unit disconnects > that I/O operation from the channel to which is was connected. Then > that > channel is available to do I/O > to or from any device that is accessible through that channel. I used > to > think that only an I/O to a > different device would steal away the channel at this point. But with > the > advent of PAV it now seems > that a different I/O to the same device could connect to the channel. > Or > maybe that possibility has been in the > microcode since even before PAV. > And of none of the preceeding discussion (mine and yours) applies to FICON. FICON does not really have a connect and disconnect state. It is more like transferring and not transferring frames for a volume. There is no DPR - everything happens on the same channel. Think of it like a PABX that supports 64 phone calls. When 64 lines are in use you have to wait. It happens rarely for good cache IO, but for some cache unfriendly workloads (CA-IDMS and IMS Fastpath spring to mind) you can quickly use up the OE and watch IO stall waiting for cache misses to complete. > > The patent applications to which I referred in my earlier post were > those of > EMC's initial support of > 2105 PAV compatibility in late 2000. There is a limit of eight per > device > that was architected into that level of > microcode. Evidently they have increased the limit to some new, much > larger > value. Some vendors wrote their own code to talk to PAV on MVS, and some paid IBM for the API and still had limits initially. The limits on the storage were not PAV limits in MVS. Note that there are other resource restrictions that can affect FICON throughput. I suggest browsing Pat Artis' website for some quality education on FICON. > > Bill Fairchild > Plainfield, IL > > > > > ---------------------------------------------------------------------- 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
