In a message dated 7/28/2005 8:20:46 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: >Thanks for taking the time to write this response. It is most informative. >This goes straight to my useful information folder.
>So, if ASM will treat PLPA and Common as a single Common+PLPA extent than I >will stand corrected. There is benefit to be gained by having them allocated >adjacent to one another. >It would be good to know if there is any other logic applied for ASM to do >this. For example must the order of the datasets always be PLPA and then >Common? Does this operate for a PLPA larger than one Cylinder? I don't know. >I am also wondering if this continues to operate in this way for PAV. With >PAV I would think that a page-in from the PLPA dataset would use one of the >UCB assigned to PLPA, rendering the need for adjacent datasets redundant. When PAV is involved, other considerations complicate matters. Any number of I/Os can theoretically be happening simultaneously within the same data set from any number of exposures as long as all those I/Os are read only. But if only one of them wants to do a write, then serialization is necessary within the control unit. This is done at the extent level. The extent information is relayed by the user's I/O request to the controller through the Define Extent command (or Set File Mask or Prefix). If an extent is defined as between tracks X and Y and that channel program also says it might do a write (this is also conveyed in the Define Extent parameters), then the controller looks at the extent range defined for all the other channel programs that are simultaneously active on that same device. If any other active channel program has at least one track between X and Y, then the I/O involving the possibility of doing a write has to wait until all read-only operations that have extent overlap that have already been started finish, and once the I/O with a write possibility is started then any more read-only chains with X-Y extent overlap have to wait until the write I/O finishes. This is the way the EMC microcode does it according to their patent application. I didn't read IBM's patent applications, so I don't know exactly how the 2105 does it. All this is great with most data sets, but paging is not most data sets. A typical paging chain, even though it is limited to a maximum of 30 pages for a 3390, could have many reads or write commands in each burst. And the define extent parameters are not re-transferred with each Resume Subchannel. They are sent only once when the SECP began long ago with a Start Subchannel. So there exists a much greater chance within paging I/O that controller serialization will occur, especially if you allowed 8 exposures to be doing I/Os within the page data sets. I suspect this is the real reason why IBM has limited paging PAVing to at most two exposures; namely that having more than two exposures rapidly becomes counter-productive due to the increasing amounts of serialization. ASM could be changed so that it no longer uses the SECP technique and always does a SSCH on each paging I/O, paging chains could be shortened, and the range of tracks in the Define Extent parameters for each of these I/Os could be shrunk down to the minimum necessary for all the pages being transferred in that one I/O rather than cover the track range for the entire page data set. If all these changes were made in ASM, I think that more than two exposures would be worthwhile. And if SECP were abandoned, then there would be no residual reason to allocate PLPA right next to Common. >With PAV I would suggest that a dedicated PLPA and Common Dataset (i.e. no >overflow) on the same volume would provide almost the same throughput as two >dedicated volumes - whether or no they are adjacent. I think so too. ASM is an extremely critical and complicated part of z/OS, and significant changes to it are not to be hastily made. 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
