Thanks for this! Worth looking into. I was hoping the pixie dust wouldn’t cost extra, but I shouldn’t be surprised.
Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List <[email protected]> on behalf of rpinion865 <[email protected]> Date: Monday, April 7, 2025 at 4:18 PM To: [email protected] <[email protected]> Subject: Re: Migrating Storage pools to EAV Cost options, BMC STOP-X37, DTS Software ACC/SRS, or not as sophisticated IBM's TAM (Tivoli Allocation Manager). I know that TAM has the ability to increase secondary allocations after "x" number of extents. I think there are additional tuning knobs that can be turned for both primary and secondary allocation amounts. "Confidentially doc, I am the wabbit." Bugs Bunny Sent with Proton Mail secure email. On Monday, April 7th, 2025 at 3:48 PM, Jousma, David <[email protected]> wrote: > 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
