Since the JCL overrides the DATACLAS, if the JCL has ',UNIT=(SYSDA,59)' coded, that must be changed.
But VOLUME COUNT=1 and DYNVOL COUNT=58 relieves the programmer from having to specify numbers; they just code UNIT-SYSDA. No matter whether the target storage pool is comprosed of EAVs or MOD-54s. it will work. -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of rpinion865 Sent: Friday, April 4, 2025 9:58 AM To: [email protected] Subject: Re: Migrating Storage pools to EAV CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. Yep been there done that with setting DVC to 59 causing a banking application, PEP+, to exhaust the TIOT. The TIOT was set to the maximum value. "Confidentially doc, I am the wabbit." Bugs Bunny Sent with Proton Mail secure email. On Friday, April 4th, 2025 at 10:51 AM, Michael Watkins <[email protected]> wrote: > One idea might be to change the DATACLAS as follows: set column 14 'VOLUME > COUNT' to '1' and then set column 16 'DYNVOL COUNT' to '58'. > > This prevents the catalog record from containing unused fields for DASD > volumes never allocated since only the volumes actually used will be > contained in the catalog. > > However, this does use extra space in the TIOT. (Suggestion: Set TIOT size to > 64 in the ALLOCxx PARMLIB member.) Even with TIOT size 64, JOBSTEPs with over > 125 or so DD cards all specifying this DATACLAS will blow out the TIOT and > the job will fail. > > -----Original Message----- > From: IBM Mainframe Discussion List [email protected] On Behalf > Of Jousma, David > > Sent: Friday, April 4, 2025 9:21 AM > To: [email protected] > Subject: Migrating Storage pools to EAV > > CAUTION: This email originated from outside of the Texas Comptroller's email > system. > DO NOT click links or open attachments unless you expect them from the sender > and know the content is safe. > > So, we are finally biting the bullet and making 1TB EAV volumes our standard > for UCB relief, etc. One "habit" my Storage team over the years had done to > mask poor dataset allocations was to make the mainly used DATACLAS > multi-volume, with a max of 59 volumes. It was before my time, but I'm 99% > sure that was done to avoid x37 abends for max extents. Now that we are going > to EAV's, we'll be clearing off the mod-54's and DISNEW them. And with a 20-1 > reduction in physical volumes, there will likely be pools that had say 100 > volumes, that could end up with just 5 EAV's. > > I'm not a storage guy by craft, so am wondering if there is any magic dust to > help with this other than making the owners of the poorly allocated files > make adjustments to their allocations? > > Dave Jousma > Vice President | Director, Technology Engineering > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
