GDG Limit 255 Reason

srini24 · New User Joined: 14 Feb 2017 Posts: 12 Location: India

Anybody know what is the exact reason for keeping 255 as a maximum limit for generation of GDG's....I hit online but i didn't get better answer..

enrico-sorichetti · Posted: Mon Sep 03, 2018 3:23 pm

the reasons why something is done in a certain way, or certain limits are what they are
are usually hidden in the design documents

if they are not available the only thing that we can do is guess

the most reasonable guess is that - for space reasons -
the counter was ONE byte - and still is one BYTE - for BASIC GDGs

steve-myers · Posted: Mon Sep 03, 2018 6:10 pm

Mr. Sorichetti is correct. In the original OS/360 CVOL catalog structure, the counter fields were one byte. For all I know, the counter fields in the BCS catalog currently used may be larger, but are still limited to 255 for historical reasons.

As a side note, in OS/360 CVOL. the counter field in GnnnnV00 was stored in the catalog in binary as a negative number. When this field was sorted, G0050V00 was first, and G0001V00 was last, which is why xx(0) got the first entry in G0050V00, and G0001V00 came up as (-49). Catalog listers had to convert the binary number to decimal, and catalog listers printed the GDG data sets in reverse order.

Nic Clouston · Posted: Mon Sep 03, 2018 6:10 pm

This topic has nothing to do with COBOL. Moved to a more sensible area.

jasorn · Active User Joined: 12 Jul 2006 Posts: 191 Location: USA

I assume most reading this already knows but for those who don't(I work with people who don't), you can now create gdgs with a limit of 999.

Here's one page but searching for something like ' how to create gdg limit 999' should be enough in case this page disappears.

www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.idak100/cat22.htm

steve-myers · Posted: Tue Sep 04, 2018 8:03 pm

I knew (prior to reading this thread) the limit had been increased, but I didn't recall the z/OS release. I reviewed the link jasorn provided and came away annoyed at IBM.

Requirement for the EXTENDED option when creating the GDG. This is telling me two things.
- The data fields for the counters are one byte in the old catalog.
- The GDG data for an "extended" GDG is a different record type in the catalog with larger fields.
Why limit it to 999? The limit seems strange since even a 2 byte binary data area in the catalog implies a much larger (32767) limit, which should be enough to keep people happy for a very long time. Is the real reason for 999 to keep the LISTCAT report essentially the same: no 4 or 5 byte decimal numerics. That will keep people analyzing the printed reports happy! Or is the real reason (the cynic in me says) IBM was too lazy to update the report program?

don.leahy · Posted: Wed Sep 05, 2018 12:11 am

steve-myers · Posted: Wed Sep 05, 2018 7:44 am

The JCL issue is worse than Mr. Leahy's quote seems to imply. Yes, you have the problem of more than 3 digit relative generations. But think about

//GDGDD DD DISP=SHR,DSN=GDGBASE

when the GDG base has more than 255 generations. Each generation creates the equivalent of a DD statement, so you run into limits on maximum DD statements in a step. This is much worse than altering the JCL scanner!