Mike,

Yes, I am aware of that, but its all or nothing with that option.  I’d want to 
be able to choose the larger of the two, and not reduce an allocation

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List <[email protected]> on behalf of 
Michael Watkins <[email protected]>
Date: Monday, April 7, 2025 at 3:55 PM
To: [email protected] <[email protected]>
Subject: Re: Migrating Storage pools to EAV



Column 46 in ISMF option 4 (Data Class) allows you to create a DATACLAS that 
overrides the SPACE values in the JCL. You can either change their DATACLAS or 
change the DATACLAS they are assigned, no? Is that what you need?



OVERRIDE     The OVERRIDE SPACE column 46 shows whether or not the data

SPACE        class space attributes will override the space attributes

--(46)--     from other sources like JCL.

YES



  Possible values:



      YES  Data class attributes will override others



      NO   Data class attributes can be overridden



      ???  Error obtaining data



-----Original Message-----

From: IBM Mainframe Discussion List <[email protected]> On Behalf Of 
Jousma, David

Sent: Monday, April 7, 2025 2:48 PM

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.



I think the point of my question wasn't worded clearly.    The problem is poor 
allocation coding over the years where coded primary and secondary allocations 
are NO WHERE NEAR what is really needed.   But because we have 100's of volumes 
in the pool, and a dataclass that allows 59 volume multi-volume dataset, the 
problem is masked because the dataset can get 123 extents on each of the 59 
volumes.   With a 20-1 reduction in volumes in the pool(1TB EAV's replacing 20 
mod-54's), there might not be 59 volumes in the pool, and that dataset will now 
take an x-37 abend that we will take the heat for.



That is what I am trying to avoid.  Seems like my only option is to reduce the 
size of the EAV so that there are more volumes, or make the developers fix 
their JCL allocations.    I was hoping for the pixie dust to work around the 
latter, but I don't think there is anything.   It would be nice if (here is the 
pixie dust), that on dataset extent processing, if some number of x space is 
requested, but is below some threshold percentage of the current file size, or 
less than some site customizable minimal trk/cylinder quantity that it would 
get overridden to something larger.



Dave Jousma

Vice President | Director, Technology Engineering









>



> -----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


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

Reply via email to