Mark: Ben Alford was lamenting the fact that Extent Consolidation only worked for VSAM. I was speculating that IBM might not have wanted to simply enable it for non-VSAM because it might break some applications. One scenario that crossed my mind is as follows: In a program that writes to disk using EXCP, the setup of IOBSEEK before each write, for example, is done based on the contents of the extent list. When the program reaches the end of the last allocated extent, it would presumably issue an EOV to request the system to allocate more space. Upon return from the EOV, I can imagine code that would (only) expect to find a new extent in the list. In other words, code whose behavior would be "undefined" if, instead, EOV simply increased the high CCHH of the extent that had just previously been exhausted. Since it's never been necessary to do so before, I suspect that most such programs will not- go back and re-examine the last extent (to see if it had been increased in size). How they each might behave as a result of not- getting the new extent they expected is anyone's guess. My "suggestion" as to how to safely implement Extent Consolidation for non-VSAM data sets opened for EXCP, would be to include a mechanism where the program could indicate to the system that it is prepared to re-examine the previously exhausted extent. Without that indicator being set, the system would best create a new extent. Art
At 11:30 AM 5/11/2006, Mark Thomen wrote: >[...snip...] > >I'm a little puzzled - why would a program issuing an EOV bother to search >for "new extents"? If it worked, they've got more space. If it didn't, >then they can take other options. VSAM code determines when it needs >another extent, and takes care of it automatically - the user doesn't even >know that it happened. > >Extent consolidation only applies to VSAM data sets (see "z/OS DFSMS Using >Data Sets"), and it is a huge impact for customers. If extents are >adjacent, then they don't run into the limit of 123 extents on a volume. >This improves performance, and reduces the likelihood of having to supply >additional devices to extend to. ================================================== Art Celestini Celestini Development Services Phone: 201-670-1674 Wyckoff, NJ ============= http://celestini.com ============= Mail sent to the "From" address used in this post will be rejected by our server. Please send off- list email to: ibmmain<at-sign>celestini<dot>com. ================================================== ---------------------------------------------------------------------- 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
