Re: A possible solution to the mystery of 123 extents per volume (UNCLASSIFIED)
On 26-Nov-13 15:30, Storr, Lon A CTR USARMY HRC , US wrote: 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 (
A possible solution to the mystery of 123 extents per volume (UNCLASSIFIED)
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
