Multi-volume data sets have always been troublesome. The best thing is to avoid them at all costs. However, this is not an option because we have data sets larger than a 3390-3. So, we may have to live with that. This article attempts to give some advice for managing multi-volume OSAM data sets.

Method of Creation

The effect of secondary allocation is quite different on how the data sets are allocated. There are basically two methods:

• The data set is allocated in the initial load step.
• The data set is pre-allocated in a previous step.

The data set is allocated in the initial load step

In this case, the JCL (or SMS constructs) contains multiple volume serials. However, there is only one SPACE parameter. The first volume will get the primary allocation and up to 15 secondary allocations. The switch to the next volume in the list occurs when the first volume cannot obtain additional secondary allocations anymore. Keep in mind that this may be less than 15.

The subsequent volume will now get the secondary allocation. This makes the amount of the secondary allocation somewhat important, but also difficult to specify, since you want to get the most out of each volume. My suggestion is to keep the primary and secondary allocation the same. This is not ideal, but at least you know what you get.

Once the load step has ended, there could be an "empty" volume, which does not have any records yet.

Example:

//DBDFILE DD DISP=(,CATLG),VOL=SER=(VOL1,VOL2,VOL3)

The data set is pre-allocated in a previous step

This is basically done by allocating the data set on each volume. Keep in mind that you must use DISP=(,KEEP), and you need to use IDCAMS to catalog the data sets [DEFINE NVSAM (NAME (..) VOLUMES(v1 v2 ..) DEVT(3390)) ] prior to the load process. The difference now is that you specify a DD statement for each volume. This way the SPACE parameter is used for each volume. The odd thing is that the load process ignores the secondary allocation whenever it finds a pre-allocated additional volume, regardless of available space. Once the load of the database is done, additional extents are taken, beginning on the ending volume of the load process.

Example:

//  EXEC  PGM=IEFBR14
//VOL1    DD  DISP=(,KEEP),SPACE=(CYL,(5,1)),
//         VOL=SER=VOL1,UNIT=3390,
//         DSN= …
//VOL2    DD  DISP=(,KEEP),SPACE=(CYL,(5,1)),
//         VOL=SER=VOL2,UNIT=3390,
//         DSN= …
//VOL3    DD  DISP=(,KEEP),SPACE=(CYL,(5,1)),
//         VOL=SER=VOL3,UNIT=3390,
//         DSN= …
//  EXEC  PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DEF NVSAM (NAME(dsn..) VOLUMES(VOL1 VOL2 VOL3) -
       DEVT(3390))

If no secondary allocation is specified, only the method described above using pre-allocated data sets can be used. At the end of each volume, the load process switches to the next volume. This one may have a different primary allocation. The difference starts when the load process has ended. Let's assume that 3 volumes were specified, but only 2 have been loaded. If the second volume becomes full, the third volume will not be used. This is somewhat surprising, so you have to specify at least a secondary allocation on the second volume. If you have difficulties defining how much data you will load, use secondary allocation on all allocations.

Which method should you use? I prefer the method with pre-allocated data sets. This way I can predict the load process and its allocation on the different volumes. However, this is a very "hands on" method. If you are less experienced, allocate in the load step.

Fragmentation on Volumes

Even a primary allocation can use several extents, unless you specify CONTIG in the SPACE parameter. This is something you should avoid. It can be done by "reorganizing" the volumes every now and then. However, the question arises why we still pay attention to those things in light of RAID devices. The answer is very simple. Unfortunately, all our disks are still 3380 or 3390. All data management is still working on the assumption of real disks. For performance reasons, we can neglect the volume placements now, but we are still limited by the geometry of those "virtual" devices. That's why we need to maintain volumes and data sets. Plus, keep in mind that there is a limitation on the number of extents you can have in total. For OSAM this is 64. If you thought about specifying a small amount of primary and secondary allocation and large amount of volumes, this is the defeating factor. Will this ever change? Unless a new device geometry is defined, the answer is "no." And creating a new device geometry is a considerable task. MVS still queues I/O requests on a "logical" volume. So, heavily used data sets may have to be split on different volumes.

Additional Parameter with IEFBR14 Allocation

I have seen additional parameters in the JCL, especially DCB parameter. Those can be deleted. Since IEFBR14 does not open any data sets, those parameter will not be placed in the VTOC. This is done only by OPEN/CLOSE/EOV processing. The second reason has to do with OSAM. The file attributes (LRECL, BLKSIZE) are specified in the DBD. The load process will use those parameters. This also means that you have to change the DBD if you want different file attributes. For those already using HALDB, the data set attributes are defined with the definition of the partitions.

In both cases, the database or the partition needs to be reloaded. You should have done an unload prior to the change. The unload process needs the correct file attributes in the descriptions (DBD, Partition definition)

Volume Sequence Number

OSAM does not maintain a volume sequence number. This is not a problem since BDAM is not used (OSAM uses EXCP, thus has written its own access method). However, if you use IMS databases in a different environment (which nobody in his right mind would do), you may have to pay attention to the volume sequence number. BMC Software has a tool which could help you there.

What I Would Do If I Could Rule

Since a new device type with a different device geometry is highly unlikely, I would start bugging (or begging) the disk vendors. Since everything is now RAID and the devices can be defined for that box, it should be possible to increase the number of cylinders. This would avoid a lot of problems and should be worth a try.