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
