UNIT=SYSDA is so non-SMS style...
This is real "mainframe modernization" - to start using SMS ACS routines
and EAV. ;-)
--
Radoslaw Skorupka
Lodz, Poland
W dniu 04.04.2025 o 17:03, Michael Watkins pisze:
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 [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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
