However, HSM Partial Release should consolidate extents, so a properly sized (big) secondary should keep the abends at bay
> -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Paul Feller > Sent: Wednesday, February 21, 2024 12:39 PM > To: [email protected] > Subject: Re: Something keeps releasing space on a large (annual) DS > > [EXTERNAL EMAIL] > > Bob as Steve said you might want to talk to your storge management team. > What I think is happening is your dataset is getting a management class that > has Partial Release set and then HSM is doing space management and releasing > any unused space. I've seen this happen before and it has happened to me. > > Good luck. > > Paul > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Steve Thompson > Sent: Wednesday, February 21, 2024 1:59 PM > To: [email protected] > Subject: Re: Something keeps releasing space on a large (annual) DS > > Ask the storage guys about the preferred method to allocate a file that will > get > very large during production runs. And you don't want production to fail with > a storage ABEND. And let them know about the current behavior. They may > have made a change that is the cause of your problem. > > Then you can modify the REXX code to include the class info they give you. > > Also, I suggest you allocate in CYLS not TRKS in the case they are doing > compression of space on data sets allocated in tracks... > > I've seen various odd things done to recover space for files that can't be on > the > tracks after 65xxx (forgot the last track accessible by the old NOTE/POINT > that > causes products like Panvalet to break). > > And if I remember correctly, compression/decompression is done by the > access method. Double check to make sure this isn't a VSAM thing. > > I've not had to deal with these features for a few years.... So things slip > from > one's mind. > > Steve Thompson > > On 2/21/2024 2:33 PM, Bob Bridges wrote: > > Ooh, now that's interesting! The content of this file would lend > > itself well to compression - all alphanumeric with a few parens, > > colons and the like. But what happens when someone needs to view it? > > Does it compress automatically or is another step required? > > > > It's not something I can bring up now, because everyone's busy with a > > z/OS upgrade. But next month... > > > > --- > > Bob Bridges, [email protected], cell 336 382-7313 > > > > /* For Sale: Parachute. Only used once, never opened, small stain. */ > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On > > Behalf Of Michael Oujesky > > Sent: Wednesday, February 21, 2024 13:49 > > > > You might consider SMS compression to reduce the physical size of the file. > > If you do, change the BLKSIZE to 32760 as SMS compression writes full > > tracks and the BLKSIZE becomes logical (the size of the buffer used in > > passing date to/from the application). > > > > --- At 11:44 AM 2/21/2024, Bob Bridges wrote: > >> I'm not a sysprog (just a security geek), but I can at least allocate > >> datasets, and at the start of this year it fell to me to allocate a > >> new dataset in which are logged all changes made in the security system. > >> Past year's log are in the 12000-track range, so I started with a > >> smaller allocation while I took the time to talk to our sysprog about > >> space requirements. It's populated from a daily production job, by > >> the way. > >> > >> When I re-allocated it, on his advice I tried a multi-volume and > >> extended allocation (PS-E). Almost immediately the job started > >> bombing, claiming that the first four volumes it tried didn't have > >> the necessary space to add an extension. The sysprog is puzzled - > >> says it should have looked in volumes that DO have the space, not the > >> ones that don't. > >> > >> Second attempt (I don't count the temporary smaller allocation) I > >> kept PS-E but dropped the multi-volume requirement. I've never done > >> one of those anyway, and don't trust 'em. The system promptly > >> dropped the extra tracks I allocated, and a day or two later the job > >> started bombing with a B37-04. > >> > >> Third attempt: Forget PS-E (I'm unfamiliar with that too) and just > >> used SPACE=(TRK,(9000,1000)). That seemed to work for a whole week, > >> but I just noticed that something, somewhere, has released extra > >> space AGAIN; > >> 3.4 tells me it's now 1960 tracks and 83%. The job isn't bombing > >> yet; some time later in the year I'm guessing it's going to. > >> > >> Pardon my frustration: WHAT THE HECK IS GOING ON? Why does it keep > >> releasing space although I never specified RLSE? The sysprog doesn't > >> know either - but he's an external contractor who just took over the > >> system a few months ago and if it's something simple he may not be > >> aware yet of ... I dunno, something in SMS maybe? > >> > >> Some wrinkles that may or may not be relevant: > >> > >> 1) The dataset is written using a REXX exec that calculates the DSN > >> by reference to the current year. This relieves folks from having to > >> update the JCL every year, but maybe something about the way the exec > >> does the allocate is causing the problem? I'm guessing not, because > >> as far as I now this job has run correctly for years. But just in case: > >> > >> "ALLOC DDN(CHG$$OT) DSN('<dsn>') MOD CATALOG REUSE", > >> "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)" > >> > >> 2) I don't know anything about SMS, but could something there be > >> releasing space? > >> > >> 3) What IS extended PS, anyway? I'm told it allows more than 16 > >> extents, but a) how many more? And b) how else is it different? > >> > >> 4) I allocated the dataset each time using not batch JCL but 3.2 ... > >> expecting there's no difference. > > ---------------------------------------------------------------------- > > 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
