Classification: UNCLASSIFIED
Caveats: NONE
List,
I've done some research and may have discovered the reason behind the current
limit of 123 extents per volume.
We all know that the original MVS DEB (a very messy control block because it's
so old and so much has evolved) was not designed for VSAM, DF/SMS, etc. It was
designed to mesh with the limitations built into other control blocks at that
time:
* Single-byte extent counts (i.e. one dataset across multiple volumes or
multiple datasets concatentated) in the DCB, DSCB, IOB (i.e. MBBCCHHR) and
elsewhere.
* Limitation of one F1-DSCB and one F3-DSCB (i.e. 16 total extents) per
dataset, per volume.
In its original design, the DEB probably comprised four fundamental "pieces": a
16-byte prefix, a basic section composed of a 32-byte header followed by a
variable number of 16-byte device-dependent entries and an
access-method-dependent suffix (16 bytes or more, depending on access method).
The total length of the DEB was saved in a byte at -4 in the prefix called
DEBLNGTH. It contained the total length of the aforementioned setions, measured
in doublewords. X'FF' * 8 = a maximum DEB size of 2040 bytes. Minus 64 bytes
for the prefix, header and suffix = 1976 bytes. 1976 / 16 = 123 potential
device-dependent entries. At the time, each device-dependent entry defined
exactly one extent.
Hence, in practice, a single DD statement (concatenated or not) was limited to
123 extents. I believe that this DEB limitation prevented datasets from
exceeding 123 total extents, even though other control blocks would support up
to 255 extents. I can't prove this because I can find no manuals old enough. I
have a vague recollection that this jives with a LNKLST restriction from the
Dark Ages but my memory is suspect. In any case, an ABEND S013-E4 results when
the limitation is exceeded and the text associated with this code has changed
over time.
The fundamental impetus for the change may have been OS/390, which repackaged
what had previously been individually selectable components into one monolithic
"glob" of standardly-delivered elements and features. The LNKLST concatenation
was probably one of the longest in the system and (what I believe was) the
current limitation of 123 extents in LNKLST just didn't cut it anymore because
the standard OS/390 LNKLST included a lot more "stuff". OS/390 V1R2 introduced
the LNKLST statement in PROGxx and I suspect that this is when the DEB started
changing. Perusal of the old documentation suggests that the change ONLY
applied to a LNKLST specified via a PROGxx member until OS/390 V1R5 when the
change became more generally available; I can't be sure of the exact timing but
it makes little difference.
DEBLNGTH was effectively retired (I think) and replaced by two single-byte
fields: DEBAMLNG and DEBNMEXT (i.e. the length of the access-method-dependent
section, in bytes, and the number of device-dependent entries). The number of
extents that could be defined by a single DEB was now in alignment with other
control blocks (i.e. 255). The limitation regarding the total number of extents
in a dataset and/or concatenation was increased from 123 to 255. Even this
limitation has changed over time because the newer DSNTYPEs utilize only a
single DEB entry, regardless of the number of extents the dataset occupies
(e.g. PDS-E, HFS and Extended-Format).
So, where does the limitation of 123 extents per volume come from? Since it is
a PER VOLUME limitation, I looked at things related to the volume:
1) The VTOC: Nope. All of the fields that I found related to extents are a
single byte (i.e. maximum value of 255). F3-DSCBs may be chained, so that's not
the issue either.
2) The VVDS: I don't think so. I could find no detailed mapping of the VVDS so
I dumped one after creating two datasets: one was non-SMS-managed and comprised
123 extents; the other was SMS-managed, comprised 123 extents and had
associated accounting information, exit name and log-stream name. In an NVR or
VVR, extents on a volume are apparently described by entries that are about
20-bytes long and contain a single-byte extent number. Even with the maximum
amount of information possible, there's plenty of room for more than 123 extent
entries in under 4K (i.e. the CISIZE of the VVDS and possibly the maximum size
of an NVR or VVR).
3) The BCS (albeit a long shot): Not as far as I can see.
I believe that the answer lies in DADSM, an ancient component that traces its
roots back to the same days as the DEB. When DASD was designed, a DEB could
describe 123 extents; storage was a premium resource at the time, so DADSM
restrictions mirrored DEB restrictions. The DEB has evolved but DADSM
apparently has not.
There are two macros in MODGEN: IECPRLWA (the partial release work area) and
IECSCRWA (scratch work area). Both refer to a DADSM area called the Extent
Descriptor Table (EDT), that is identified by eyecatcher ICVEDT02. IECPRLWA has
comments which specify that a full EDT contains 123 entries. IECSCRWA maps the
EDT at label SCRVRFDA; note that RTA = Relative Track Address (each a 32-bit
field).
The aforementioned is my attempt to piece together a plausible solution to the
mystery of 123 extents per volume. I wouldn't be surprised to discover that
there are other factors and/or that my findings are faulty in some way. C'est
la vie.
Regards,
Alan
Classification: UNCLASSIFIED
Caveats: NONE
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
