Re: VSAM Extent Consolidation
In [EMAIL PROTECTED], on 05/11/2006 at 07:13 PM, Art Celestini [EMAIL PROTECTED] said: 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. True, but most programs either look explicitly at the DEB each time that they set it up or rely on the TTR conversion routine; I've never seen a program that assumes that an extent has been added after an EOV instead of just looking at the extent count. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: VSAM Extent Consolidation
On Thu, 11 May 2006 19:13:58 -0400 Art Celestini [EMAIL PROTECTED] wrote: :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. Again, I fail to see why combining the extents on DASD would require combining the extents in the DEB. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: VSAM Extent Consolidation
I suppose letting the new space be described by a new entry in the extent list would resolve the situation I described, but might not other issues surface when the number of entries exceeds 15 (a different condition that could cause the program to choke)? Probably less likely to really create a problem but still a possibility. At 04:33 AM 5/12/2006, Binyamin Dissen wrote: [...snip...] Again, I fail to see why combining the extents on DASD would require combining the extents in the DEB. == Art Celestini Celestini Development Services Phone: 201-670-1674Wyckoff, 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: ibmmainat-signcelestinidotcom. == -- 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
Re: VSAM Extent Consolidation
I just want to thank everyone for this discussion, especially Mark Thomen. I have noticed some strange allocations with DB2 datasets, and now understand what is happening. It is a little unnerving to look at an IDCAMS LISTCAT and see mutliple extents, with each one a different size. Especially when the sizes do not agree with what was stated when the dataset was defined. When I read the information about the extent consolidation, I thought I do that with HSM and DFDSS now, by copying the dataset. I had no idea that this result is what Thomen and his gang had in mind. Interesting concept. Instead of creating additional VTOC entries, we now modify the existing ones. And the corresponding VVDS entries also just to keep things in sync. Apart from the programming concerns, this could easily apply to all datasets on DASD -- 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
Re: VSAM Extent Consolidation
Art Celestini [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... 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: Let me say it again: There is NO EXTENT CONSOLIDATION for non-VSAM data sets. Therefore, there is no reason to worry about them. It is very unlikely we will implement that feature for non-VSAM. Thanks, Mark Thomen Catalog/IDCAMS/VSAM Development -- 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
Re: VSAM Extent Consolidation
Yes Mark, the whole discussion was based on a lot of wishful thinking on our part. But, since you say it's unlikely you'll do it for non-VSAM, it might not be a bad idea for an ISV product ... ;-) At 11:48 AM 5/12/2006, Mark Thomen wrote: [...snip...] Let me say it again: There is NO EXTENT CONSOLIDATION for non-VSAM data sets. Therefore, there is no reason to worry about them. It is very unlikely we will implement that feature for non-VSAM. == Art Celestini Celestini Development Services Phone: 201-670-1674Wyckoff, 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: ibmmainat-signcelestinidotcom. == -- 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
Re: VSAM Extent Consolidation
But, since you say it's unlikely you'll do it for non-VSAM, it might not be a bad idea for an ISV product ... Since you asked, COMPAKTOR (FDRCPK ala FASTCPK) has been combining extents for 20 years for non-VSAM and a little less for VSAM. To the best of my knowledge, DFSMSdss DEFRAG may make extents contiguous but will not combine them. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.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
Re: VSAM Extent Consolidation
On May 12, 2006, at 10:48 AM, Mark Thomen wrote: Art Celestini [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... 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: Let me say it again: There is NO EXTENT CONSOLIDATION for non-VSAM data sets. Therefore, there is no reason to worry about them. It is very unlikely we will implement that feature for non-VSAM. Mark, IIRC FDR does it extremely efficiently. Help support OEM vendors:) Ed -- 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
Re: VSAM Extent Consolidation
Ed Gould wrote: On May 12, 2006, at 10:48 AM, Mark Thomen wrote: Let me say it again: There is NO EXTENT CONSOLIDATION for non-VSAM data sets. Therefore, there is no reason to worry about them. It is very unlikely we will implement that feature for non-VSAM. Mark, IIRC FDR does it extremely efficiently. Help support OEM vendors:) Ed You haven't been paying attention, have you Eg? What's being discussed here is not some sort of daily or hourly mass reorg. Rather, the discussion centers around real-time extent consolidation, performed by the access method itself, when a new, contiguous extent is added. FDR does not do that! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.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
Re: VSAM Extent Consolidation
On Wed, 10 May 2006 19:06:47 -0400 Art Celestini [EMAIL PROTECTED] wrote: :I think it's actually non-VSAM, and it's because a lot of applications :using EXCP or lower would break. :Such programs normally issue an EOV to cause allocation of a new extent :for an output data set. I suspect most apps would then expect to find :a new extent in the extent list (not more space allocated within the last :existing extent). I think what IBM could do is to add an option to :either OPEN or EOV so the application could say I can handle Extent :Consolidation. Then it could be done without the risk of breaking a :program that currently works. Does there have to be a direct relationship between the F1 DSCB's and the DEB extent list? Why would a program fail if the DEB shows three extents (the two original + the added) while the F1 has only two, the first and the combination of the second and the third? -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: VSAM Extent Consolidation
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-1674Wyckoff, 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: ibmmainat-signcelestinidotcom. == -- 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
Re: VSAM Extent Consolidation
I think it's actually non-VSAM, and it's because a lot of applications using EXCP or lower would break. Such programs normally issue an EOV to cause allocation of a new extent for an output data set. I suspect most apps would then expect to find a new extent in the extent list (not more space allocated within the last existing extent). I think what IBM could do is to add an option to either OPEN or EOV so the application could say I can handle Extent Consolidation. Then it could be done without the risk of breaking a program that currently works. At 12:10 PM 5/10/2006, Ben Alford wrote: [...] Unfortunately, the manual says the Extent Consolidation isn't supported for non-SMS datasets. Bummer. Ben Alford Enterprise Systems Programming University of Tennessee [...] == Art Celestini Celestini Development Services Phone: 201-670-1674Wyckoff, 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: ibmmainat-signcelestinidotcom. == -- 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
