SMS compression/de-compression is done by the access method
(presuming regular QSAM/BSAM) and is usually transparent to the
application. A long time ago, tailored compression had a bug that
lost track of where the tailored dictionary was kept and
caused abends when trying to read the file. HMIGRATE/recall of the
dataset corrected the error. I would expect y'all have zEDC
available and that operates on a block level providing better
compression than either generic or tailored compression options.
Michael
At 01:33 PM 2/21/2024, 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
