Best Practices to Initialize DASD — Two Things I Finally Learned

🖥 🖥 🖥 🖥

Having been a systems programmer for nearly four decades now, and a tester in DFSMS Device Services for the past 16 of those, I have initialized tens of thousands of DASD devices. Being part of Device Services I have participated in a great many conversations with others in DFSMS and customer support about extending the VTOC when the number of free DSCBs starts approaching single digits. Often the roadblock to extending the VTOC is the VSAM Volume Data Set (VVDS) which contains information about the VSAM, and SMS-managed non-VSAM data sets residing on the volume with the VVDS. The issue is that once the VVDS is allocated it cannot be moved. For years now, system administrators around the globe have created processes and standards to circumvent this restriction.

Yet one fall morning in October 2021, as everyone was beginning to hope the Covid-19 pandemic would be winding down the answer to the problem turned out to be we have been over engineering the solution. The story goes like this…. Mike Koester, the ICKDSF developer since the time the Nintendo Entertainment System (NES) was released in North America, was driving to the office in Silicon Valley Lab (SVL) for the second time in the past 18 months. Even at 5:30 in the morning, SVL area traffic was holding true to form and he was moving along at less than 10 miles an hour. Because I live on the East coast, not too far from Jacksonville Florida, Mike knew I would be working so he gave me a call, on his Bluetooth connected cell phone of course, to discuss the latest customer VTOC question we received from our customer support team. During the course of the conversation Mike said, “He should start the VTOC at cylinder two track zero and let ICKDSF create the IXVTOC”, and that, ladies and gentlemen, started the quest which lead to this best practice. Seems too simple, and yet I will explain why by using this ICKDSF INIT statement as my example.

INIT UNIT(EB62) NVFY VTOC(2,0,4800) VOLID(1P8902) PURGE SG

• The VTOC will start a cylinder 2 track zero ending at cylinder 321 track 14, which is on a cylinder boundary.
• The PURGE parameter ensures any unexpired, VSAM, password or RACF protected data sets will be overwritten.
• The SG keyword indicates this is a System Managed Storage (SMS) volume. Because SG is being used, the NOINDEX|NIX keyword is not allowed and the volume will be initialized with an indexed VTOC.
• Because the INDEX parameter has not been specified, ICKDSF will calculate the size of the IXVTOC and place it adjacent to the end of the VTOC.

The net result of this is

• A 29-track free space extent followed by,
• The VTOC starting at cylinder two track 0 and ending at cylinder 321 track 14. This is 4800 tracks.
• The IXVTOC starting at cylinder 322 track 0 for 222 or 241 tracks, depending on the size of the device.

Having the IXVTOC adjacent to the end of the VTOC eliminates the need to create the VVDS as the location of this data set is now irrelevant.
Not creating the VVDS increases the chance of being able to extend the VTOC a second time because the first non-system data set allocation may be satisfied adjacent to the end of the IXVTOC data set. Having a non-system data set adjacent at the end of the IXVTOC increases the likelihood that it can be moved, freeing up space for a second extend of the VTOC if needed.
The first data set¹ created on a SMS volume will place the first VVDS extent in the 29 track free space extent before the VTOC. If this were a non-SMS volume the VVDS would be created when the first VSAM data set is created.

(1)-The VVDS is only created on the first volume of any multi-volume data set or any single-volume data set.

The IXVTOC data set extent is the space that can be used to extend the VTOC. The IXVTOC data set must be a single extent allocated within the first 65,520 cylinders on a volume and cannot exceed 65,534 tracks in size.

One thing to note, the VTOC could have started at cylinder 0 track 1, or anywhere else you want to place it, as long as there is space for the IXVTOC adjacent to the end of the VTOC.

At this point I can create as many data sets of any type as I want and then extend the VTOC by extending the IXVTOC at the same time. To do this I would use an ICKDSF command like this:

//EXTIXVTC EXEC PGM=ICKDSF
//SYSPRINT DD SYSOUT=*
//VOLUME1 DD UNIT=3390,DISP=OLD,VOL=SER=1P8902
//SYSIN DD *
REFORMAT DDNAME(VOLUME1) VERIFY(1P8902) — 
EXTVTOC(5022) EXTINDEX(275)

Note — The EXTVTOC size is the original size of the VTOC plus the original size of the IXVTOC. The EXTINDEX size is the original IXVTOC size plus 10% of the VTOC size. The 10% is over-allocated but is an easily remembered rule of thumb.

These are a subset of the messages that ICKDSF will issue when the VTOC and IXVTOC are extended,

ICK01520I THE VTOC-INDEX WAS DELETED
ICK01314I VTOC IS LOCATED AT CCHH=X’0002 0000' AND IS 5022 TRACKS.
ICK01502I BUILDIX FUNCTION STARTED
ICK01503I EB62 REQUEST RECEIVED TO CONVERT VTOC TO IXFORMAT
ICK01504I EB62 VTOC FORMAT IS CURRENTLY OSFORMAT, REQUEST ACCEPTED
ICK01508A EB62 SHOULD CONVERSION PROCEED? REPLY U TO CONTINUE, ELSE T
ICK01513I EB62 BUILDIX PROCESSING COMPLETED: VTOC IS NOW IN IXFORMAT

In this example I was able to add 11,100 DSCBs, 222 tracks, to the VTOC by letting ICKDSF handle the IXVTOC and the system handle the VVDS. Simplifying the complexity of initializing volumes by doing less, how many times does that happen?

In case you were wondering. Mike did make it into the office that day, got his flu shot, had lunch with some coworkers and made it safely back home in time for supper. How’s that for a happily ever after?