The limit of 16 extents per volume for a non-VSAM data set dates back to the 
mid-1960s and release 1 of OS/360.  A Format 1 DSCB has space for 3 extent 
descriptors and a pointer to a Format 3 DSCB, which has space for 13 more 
extent descriptors AND ALSO a pointer to another Format 3 DSCB.  Thus the VTOC 
was architected to allow an infinite number of extents in one data set, as long 
as the volume has enough free space for one more Format 3 DSCB.  For reasons 
unknown to me now, but probably due to  the smallness and expense of storage in 
the 1960s, IBM chose to cap a data set's VTOC usage to a maximum of two DSCBs 
for a non-ISAM data set and three for an ISAM data set.  The way VSAM data sets 
are described in terms of DSCBs is that you start with a Format 1, it points to 
a Format 3, that F3 can then point to another F3, etc. up to however many F3 
DSDBs are needed to hold all the extents that are allowed by some other 
constraint somewhere in the system software.  That is the only reason why a 
VSAM data set is limited to 123 extents.  Nine full Format 3 DSCBs can be used 
with a 10th Format 3 DSCB having only three of its possible 13 extent 
descriptor slots filled in.  Somewhere else in MVS is the limit of 123 imposed. 
 This limit came about when VSAM was invented along with making OS/360 use 
virtual storage.  The system catalog's internal structure was redesigned at the 
same time to use VSAM in which to store catalog entries.  So the limit of 123 
extents, I believe, is related to some part of a VSAM catalog's internal 
structure. 

One DEB can have 255 different extent entries in it.  They could theoretically 
all be on the same volume if there weren't the other constraint about 16 
extents per volume for one data set.  In fact they can be all on the same 
volume if multiple different data sets, all on one volume, are concatenated.  
Remember the DEB was invented in the mid-1960s also, long before VSAM came 
along with the new larger 123 extent limit.  I don't know about the limit of 59 
volumes per data set.  The TIOT's constraint looks like a reasonable 
explanation. 


Bill Fairchild 

Franklin, TN 

----- Original Message -----

From: "Lon A CTR USARMY HRC Storr (US)" <[email protected]> 
To: [email protected] 
Sent: Thursday, November 21, 2013 1:11:58 PM 
Subject: Re: Extents limit for HFS (UNCLASSIFIED) 

Classification: UNCLASSIFIED 
Caveats: NONE 

According to my personal notes 

The restriction of 127 extents per volume (device) comes from the DEB: DEBLNGTH 
is the number of double-words in the DEB (up to 255 ===> 255 * 8 = 2040; (2040 
- 71) / 16 = 123). 
The restriction of 59 volumes (devices) per DD comes from the TIOT: TIOELNGH is 
the number of bytes in the TIOT entry  (up to 255 ===> (255 - 16) / 4 = 59) 

Alan 


-----Original Message----- 
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of DASDBILL2 
Sent: Thursday, November 21, 2013 1:45 PM 
To: [email protected] 
Subject: Re: Extents limit for HFS 

I think there was some rational explanation given several years ago.  Check the 
archives, John.  Something about how many whatevers could fit within one 
such-and-such, where both are control blocks within a VSAM catalog structure. 
  
I disagree with the other post that mentioned up to five different extents to 
satisfy the  primary size.  If this were true, then we wouldn't have a limit of 
16 extents for a non-VSAM data set, but rather 12 (16 minus 4).  Each of  those 
five extents that might be necessary to fulfill the primary request count 
towards the total, whether the total is 123 or 16.  And, since the primary 
request could also be fulfilled with only one extent, then there can still be 
122 more non-primary extents in a VSAM data set. 
  
Bill Fairchild 
Franklin, TN 

----- Original Message ----- 

From: "John Gilmore" <[email protected]> 
To: [email protected] 
Sent: Thursday, November 21, 2013 11:11:46 AM 
Subject: Re: Extents limit for HFS 

Why the magic number of 123 extents per volume?  127 is more plausible.   What 
else is going on here? 

On 11/21/13, John Eells <[email protected]> wrote: 
> 
> z/OS DFSMS Using Data Sets, topic 3.9.2.1, "Creating HFS Data Sets": 
> 
> ... 
> 
> These data sets can expand to as many as 255 extents of DASD space on 
> multiple volumes (59 volumes maximum with 123 extents per volume). 
> 

John Gilmore, Ashland, MA 01721 - USA 

---------------------------------------------------------------------- 
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 

Classification: UNCLASSIFIED 
Caveats: NONE 



---------------------------------------------------------------------- 
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

Reply via email to