Data Set Space and Disk Storage Extents
Part Two - Challenge #10


It is fundamental to understand the way z/OS manages disk storage of newly allocated data sets. z/OS operations, developers, and systems staff members all use this knowledge in their daily tasks.

When z/OS data sets are stored onto a disk, the initial amount of space required is called a "primary extent". A primary extent is a contiguous area of space on a disk and the size can range from just a few bytes to filling the entire disk.

This is a different approach from how storage space is managed on your PC. Generally file allocation and storage is unlimited within the constrains of the OS and normally there are no other limits to the size of a single file. With z/OS data sets, size limitations are set on both the file and the disk device. This can be very beneficial to the stability of the system. For example, imagine a run-away z/OS task that was writing to a disk. This is a controlled situation as the task would eventually terminate when the specified data set size limit is reached. On your PC, this sort of behaviour might very well consume all available space on your hard drive!

When a z/OS data set is allocated, the total amount of disk space allowed to be used is the size of the primary extent plus the size of optional "secondary extents". One or more secondary extents can be allowed and these secondary extents are automatically allocated when the primary extent is full or a previous secondary extent is full.

When secondary extents are defined, the number of secondary extents is dependent upon the type of data set. In other words, all data sets have only one primary extent plus zero or more secondary extents. How many secondary extents depends on the type of data set.

Here's a list of each type of data set and the max number of extents for each type:

Data Set Type Max Extents
Sequential 16 total = 1 primary + 15 secondary
Sequential Extended 123 total = 1 primary + 122 secondary
PDS 16 total = 1 primary + 15 secondary
PDS/E 123 total = 1 primary + 122 secondary
VSAM 255 total = 1 primary + 254 secondary
VSAM (extent contstraint removed) n+1 total = 1 primary + n secondary

So, how does one know where an individual data set extent begins and ends?

The answer is that each disk device has a Volume Table of Contents (VTOC). The VTOC is a single extent written to the disk device when first initialized and formatted. Without any further changes to the VTOC, the disk has one large free extent that covers the entire device. As data sets are allocated to the disk, the VTOC is amended to indicate where each extent starts and stops. Conceptually, the VTOC is similar to the File Allocation Table (FAT) in some PC disks.

Your challenge:

Amend JCL that allocates a sequential data set with no secondary extents and copies data into this newly allocated sequential data set.

You will change the JCL to allocate secondary extents, enabling the target data set to expand enough to hold all the records from the source data set.

Run the following ISPF primary command:


Observe that an SD37 abnormal end (abend) occurred. Go ahead and take a moment to perform an internet search on the term "SD37 abend". Don't worry about reading up on it, we simply want you to see that SD37 abends are commonly encountered.

Edit CC#####.JCL(COPYJCL) and look closely at line 6. See the JCL DD SPACE= operand?

The first argument "TRK" indicates that the primary and any seconday extent space will be specified in units of track. Depending on the model of the disk being used, a track will contain a number of bytes. For our system, 3390-n disk devices allow for 56,664 bytes per track.

The first number after TRK is the primary extent size. The second number is the number of secondary extents allowed. Since the JCL is specifying a single track for the primary extent and zero secondary extents, the new data set will only be allowed to consume 56,664 bytes.

As indicated by the SD37 abend, this is clearly not enough space for the source data, so you must change the secondary extents allowed from zero to one. Do this now, and rerun the job.

Note: You may receive a MAXCC of 4. This is okay and can safely be ignored. Also, the target data set is deleted in the 3rd step of the JCL. This is to conserve space, so don't be too alarmed if you cannot locate it. If you want to take a look at the source data set, feel free to browse it in =3.4.

If the job run was successful, then P2.OUTPUT(#10) will contain disk storage information. You are not expected to understand this data now. A Part 3 challenge will explain the information in P2.OUTPUT(#10) in more detail. Feel free to move on to the next challenge now.

Next: Challenge #11