Re: Something keeps releasing space on a large (annual) DS
I need to correct myself. The limit is 16 extents per volume for standard datasets and for extended it is 123 extents per volume. I guess I was typing faster than my brain was thinking. >From the DFSMSdfp Storage Administration manual (z/OS 2.5) The maximum number of extents per volume and the maximum number of volumes per data set vary depending on data set type as follows: • A basic-format or large-format sequential data set and a direct data set can have up to 16 extents per volume and up to 59 volumes. • An extended-format sequential data set can have up to 123 extents per volume and up to 59 volumes. Either all or none of these volumes can be arranged into stripes for parallel processing. • A non-system-managed VSAM data set can have up to 255 extents per component and up to 59 volumes. • A system-managed VSAM data set can have up to 255 extents per stripe and up to 59 volumes. This extent limit can be removed if the associated data class has extent constraint removal specified. Up to 16 volumes at a time can be read or written in parallel due to striping. • A PDS can have up to 16 extents and only one volume. • A PDSE can have up to 123 extents and only one volume. • An HFS data set can have up to 123 extents per volume and up to 59 volumes. Paul -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Watkins Sent: Wednesday, February 21, 2024 4:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Something keeps releasing space on a large (annual) DS DSNTYPE=LARGE allows the 65,535 track (4,369 cylinder) limit to be exceeded. This should be restricted to SPOOL datasets and the like. DSNTYPE=EXTENDED does NOT allow this size limit to be exceeded. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Feller Sent: Wednesday, February 21, 2024 4:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Something keeps releasing space on a large (annual) DS 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. Bob, sorry we should have answered some of your questions at the end of your email Let me start by saying your storage management team should be able to answer all your questions. That said I'll answer some of your questions based on what I know. These are general answers. The SMS environment you are running under could have overrides that may affect what happens. You asked "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?" Basically, an extended format dataset is allowed to be bigger than a standard (or none extended) in several ways. Extended format allows for 123 volumes where non-extended is 16 volumes. Extended format allows for far larger allocation of a dataset on one volume then a non-extended. If I recall a non-extended max size is 65,535 tracks. As far as I know using 3.2 to allocate the data should not be an issue. It should (as far as I know) drive the same SMS ACS routines that are used in batch. Paul -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Bridges Sent: Wednesday, February 21, 2024 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Something keeps releasing space on a large (annual) DS 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?
Re: Something keeps releasing space on a large (annual) DS
Our site submitted defrag jobs. Not part of release processing. On Wed, Feb 21, 2024 at 3:33 PM Ed Jaffe <05acc3c79bf7-dmarc-requ...@listserv.ua.edu> wrote: > > On 2/21/2024 12:52 PM, Gibney, Dave wrote: > > However, HSM Partial Release should consolidate extents... > > Not in my experience. It removes "extraneous" extents (if any), but > doesn't actually do any sort of consolidation of occupied extents. > > That said, I believe if you migrate and then later recall a data set, a > consolidation does occur. > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > > > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Something keeps releasing space on a large (annual) DS
DSNTYPE=LARGE allows the 65,535 track (4,369 cylinder) limit to be exceeded.
This should be restricted to SPOOL datasets and the like.
DSNTYPE=EXTENDED does NOT allow this size limit to be exceeded.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Feller
Sent: Wednesday, February 21, 2024 4:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS
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.
Bob, sorry we should have answered some of your questions at the end of your
email
Let me start by saying your storage management team should be able to answer
all your questions. That said I'll answer some of your questions based on what
I know. These are general answers. The SMS environment you are running under
could have overrides that may affect what happens.
You asked "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?"
Basically, an extended format dataset is allowed to be bigger than a standard
(or none extended) in several ways.
Extended format allows for 123 volumes where non-extended is 16 volumes.
Extended format allows for far larger allocation of a dataset on one volume
then a non-extended. If I recall a non-extended max size is 65,535 tracks.
As far as I know using 3.2 to allocate the data should not be an issue. It
should (as far as I know) drive the same SMS ACS routines that are used in
batch.
Paul
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Bob
Bridges
Sent: Wednesday, February 21, 2024 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Something keeps releasing space on a large (annual) DS
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('') 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.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Law #6 of combat operations: If it's stupid but it works, it isn't stupid.
*/
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO
Re: Something keeps releasing space on a large (annual) DS
Bob, sorry we should have answered some of your questions at the end of your
email
Let me start by saying your storage management team should be able to answer
all your questions. That said I'll answer some of your questions based on what
I know. These are general answers. The SMS environment you are running under
could have overrides that may affect what happens.
You asked "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?"
Basically, an extended format dataset is allowed to be bigger than a standard
(or none extended) in several ways.
Extended format allows for 123 volumes where non-extended is 16 volumes.
Extended format allows for far larger allocation of a dataset on one volume
then a non-extended. If I recall a non-extended max size is 65,535 tracks.
As far as I know using 3.2 to allocate the data should not be an issue. It
should (as far as I know) drive the same SMS ACS routines that are used in
batch.
Paul
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Bob
Bridges
Sent: Wednesday, February 21, 2024 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Something keeps releasing space on a large (annual) DS
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('') 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.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Law #6 of combat operations: If it's stupid but it works, it isn't stupid.
*/
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Something keeps releasing space on a large (annual) DS
Also, forgot to add: list the dataset and note the management class (MGMTCLAS).
This will tell you how DFSMShsm is managing the dataset and whether space is
routinely being released.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Michael Watkins
Sent: Wednesday, February 21, 2024 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS
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.
"ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE", "SPACE(300,30) CYLINDERS
RECFM(V,B) LRECL(304) BLKSIZE(27998)"
Yes, always allocate anything other than a very small dataset in cylinders.
Also, keep in mind that an extended PS appends a 32-byte suffix onto every
block of data (an 8-byte prefix onto blocks of datasets allocated as
DSNTYPE=LARGE). Specifying BLKSIZE=27998 may mean that you only have 1 block on
each virtual 3390 track on your RAID storage frame. Perhaps code BLKSIZE=0 and
let the system determine the BLKSIZE.
One advantage extended format datasets enjoy is that up to 123 extents can be
allocated on each volume, although the 65,535 tracks (4,369 CYLs) per volume
z/OS limit is still adhered to.
Unless there are limits imposed by your application, do not hesitate to span up
to the z/OS limit of 59 volumes or take advantage of zEDC compression.
Also: Not all applications, particularly those that have a special internal
format (like SAS) or that write their own I/O (like Adabase) can use extended
format datasets.
Inquire with your storage manager whether there is an existing DATACLAS that
meets your needs. Or explain your issues and perhaps the storage manager will
design a DATACLAS for you.
Good luck!
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Mike Schwab
Sent: Wednesday, February 21, 2024 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS
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.
Its probably doing a release.
Do a cylinder allocation to at average 7 tracks after release.
Defragment to consolidate extents weekly / twice a week / MWF / daily.
On Wed, Feb 21, 2024 at 11:45 AM Bob Bridges
<0587168ababf-dmarc-requ...@listserv.ua.edu> 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('') MOD CATALOG REUSE", "SPACE(300,30) CYLINDERS
RECFM(V,B) LRECL(304) BLKSIZE(2
Re: Something keeps releasing space on a large (annual) DS
"ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE", "SPACE(300,30) CYLINDERS
RECFM(V,B) LRECL(304) BLKSIZE(27998)"
Yes, always allocate anything other than a very small dataset in cylinders.
Also, keep in mind that an extended PS appends a 32-byte suffix onto every
block of data (an 8-byte prefix onto blocks of datasets allocated as
DSNTYPE=LARGE). Specifying BLKSIZE=27998 may mean that you only have 1 block on
each virtual 3390 track on your RAID storage frame. Perhaps code BLKSIZE=0 and
let the system determine the BLKSIZE.
One advantage extended format datasets enjoy is that up to 123 extents can be
allocated on each volume, although the 65,535 tracks (4,369 CYLs) per volume
z/OS limit is still adhered to.
Unless there are limits imposed by your application, do not hesitate to span up
to the z/OS limit of 59 volumes or take advantage of zEDC compression.
Also: Not all applications, particularly those that have a special internal
format (like SAS) or that write their own I/O (like Adabase) can use extended
format datasets.
Inquire with your storage manager whether there is an existing DATACLAS that
meets your needs. Or explain your issues and perhaps the storage manager will
design a DATACLAS for you.
Good luck!
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Mike Schwab
Sent: Wednesday, February 21, 2024 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS
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.
Its probably doing a release.
Do a cylinder allocation to at average 7 tracks after release.
Defragment to consolidate extents weekly / twice a week / MWF / daily.
On Wed, Feb 21, 2024 at 11:45 AM Bob Bridges
<0587168ababf-dmarc-requ...@listserv.ua.edu> 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('') 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.
---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
/* Law #6 of combat operations: If it's stupid but it works, it isn't stupid.
*/
> --
> For IBM-MAIN subscribe / signoff /
Re: Something keeps releasing space on a large (annual) DS
At some point in the past, and maybe for greater than n? extents, HSM accomplished partial release by a migrate/recall under the covers. The may also be an additional SETSYS needed to enable extent reduction > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Ed Jaffe > Sent: Wednesday, February 21, 2024 1:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Something keeps releasing space on a large (annual) DS > > [EXTERNAL EMAIL] > > On 2/21/2024 12:52 PM, Gibney, Dave wrote: > > However, HSM Partial Release should consolidate extents... > > Not in my experience. It removes "extraneous" extents (if any), but doesn't > actually do any sort of consolidation of occupied extents. > > That said, I believe if you migrate and then later recall a data set, a > consolidation does occur. > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.com%2Fv3%2F__https%3A%2F%2Fwww.phoenixsoftware.com%2F__ > %3B!!JmPEgBY0HMszNaDT!v19RPyz3qPLVbvxhsix3B5bt02NriXaW69j3ZFop > m3wyEcoykkW9OjkXgCYvsKFGT1LZCYk7Yzlh1Pjwm0kgfYr- > M8m5TqZg%24&data=05%7C02%7CGIBNEY%40WSU.EDU%7C64fa6b8b02a > f404c10a908dc3324b77f%7Cb52be471f7f147b4a8790c799bb53db5%7C0 > %7C0%7C638441479982068087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0 > %7C%7C%7C&sdata=eun2fYIkexK6nTob2BBNvsRaMZQ3SWbAxumeMiUENB > g%3D&reserved=0 > > > > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). > If you are not an intended recipient or have otherwise received this email > message in error, any use, dissemination, distribution, review, storage or > copying of this e-mail message and the information contained therein is > strictly > prohibited. If you are not an intended recipient, please contact the sender by > reply e-mail and destroy all copies of this email message and do not otherwise > utilize or retain this email message or any or all of the information > contained > therein. Although this email message and any attachments or appended > messages are believed to be free of any virus or other defect that might > affect > any computer system into which it is received and opened, it is the > responsibility of the recipient to ensure that it is virus free and no > responsibility is accepted by the sender for any loss or damage arising in any > way from its opening or use. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Something keeps releasing space on a large (annual) DS
On 2/21/2024 12:52 PM, Gibney, Dave wrote: However, HSM Partial Release should consolidate extents... Not in my experience. It removes "extraneous" extents (if any), but doesn't actually do any sort of consolidation of occupied extents. That said, I believe if you migrate and then later recall a data set, a consolidation does occur. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Something keeps releasing space on a large (annual) DS
Its probably doing a release.
Do a cylinder allocation to at average 7 tracks after release.
Defragment to consolidate extents weekly / twice a week / MWF / daily.
On Wed, Feb 21, 2024 at 11:45 AM Bob Bridges
<0587168ababf-dmarc-requ...@listserv.ua.edu> 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('') 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.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Law #6 of combat operations: If it's stupid but it works, it isn't
> stupid. */
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Something keeps releasing space on a large (annual) DS
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 On > Behalf Of Paul Feller > Sent: Wednesday, February 21, 2024 12:39 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 On > Behalf Of Steve Thompson > Sent: Wednesday, February 21, 2024 1:59 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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, robhbrid...@gmail.com, cell 336 382-7313 > > > > /* For Sale: Parachute. Only used once, never opened, small stain. */ > > > > -Original Message- > > From: IBM Mainframe Discussion List 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
Re: Something keeps releasing space on a large (annual) DS
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 On Behalf Of Steve Thompson Sent: Wednesday, February 21, 2024 1:59 PM To: IBM-MAIN@LISTSERV.UA.EDU 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, robhbrid...@gmail.com, cell 336 382-7313 > > /* For Sale: Parachute. Only used once, never opened, small stain. */ > > -Original Message- > From: IBM Mainframe Discussion List 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.
Re: Something keeps releasing space on a large (annual) DS
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, robhbrid...@gmail.com, cell 336 382-7313
/* For Sale: Parachute. Only used once, never opened, small stain. */
-Original Message-
From: IBM Mainframe Discussion List 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('') 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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, robhbrid...@gmail.com, cell 336 382-7313
/* For Sale: Parachute. Only used once, never opened, small stain. */
-Original Message-
From: IBM Mainframe Discussion List 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('') 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Something keeps releasing space on a large (annual) DS
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, robhbrid...@gmail.com, cell 336 382-7313
/* For Sale: Parachute. Only used once, never opened, small stain. */
-Original Message-
From: IBM Mainframe Discussion List 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('') 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Something keeps releasing space on a large (annual) DS
Classification: Confidential
The most likely reason is the DATACLAS(? Possibly MGMTCLAS) ACS Routine. This
is where partial space release is specified.
It is possible, but un likely that dfHSM is doing the partial space release.
HSM would be honoring the "dictates" of the DATACLAS.
HTH,
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Bob
Bridges
Sent: Wednesday, February 21, 2024 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Something keeps releasing space on a large (annual) DS
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
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('') 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.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Law #6 of combat operations: If it's stupid but it works, it isn't stupid.
*/
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only. E-mail transmission is not guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or may contain viruses in transmission.
The e mail and its contents (with or without referred errors) shall therefore
not attach any liability on the originator or HCL or its affiliates. Views or
opinions, if any, presented in this email are solely those of the author and
may not necessarily reflect the views or opinions of HCL or its affiliates. Any
form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of HCL is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any email and/or attachments, please check them for
viruses and other defects.
Re: Something keeps releasing space on a large (annual) DS
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).
Michael
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('') 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.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Law #6 of combat operations: If it's stupid but it works, it
isn't stupid. */
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Something keeps releasing space on a large (annual) DS
PS-E (extended format) allows for 123 extents on a single volume. If the
allocated dataset is SMS managed its assigned management class is likely the
reason why free space is being released.
Mark Jacobs
Sent from ProtonMail, Swiss-based encrypted email.
GPG Public Key -
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
On Wednesday, February 21st, 2024 at 12:44 PM, Bob Bridges
<0587168ababf-dmarc-requ...@listserv.ua.edu> 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('') 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.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Law #6 of combat operations: If it's stupid but it works, it isn't stupid.
> */
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Something keeps releasing space on a large (annual) DS
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('') 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.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Law #6 of combat operations: If it's stupid but it works, it isn't stupid.
*/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
