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
