Allocating multivolume OSAM data sets

Secondary allocation must be specified for all volumes if the data set will be extended beyond the primary allocation.

Secondary allocation must be specified for all volumes in order to write to volumes preallocated but not written to by initial load or reload processing.

Secondary allocation is not allowed for queue data sets because queue data sets are not extended beyond their initial or preallocated space quantity. However, queue data sets can have multi-volume allocation.

The secondary allocation size defined on the first volume will be used for all secondary allocations on all volumes regardless of the secondary allocation size specified on the other volumes. All volumes should be defined with the same secondary allocation size to avoid confusion.

When a multivolume data set is preallocated, you should allocate extents on all the volumes to be used. The suggested method of allocation is to have one IEFBR14 utility step for each volume on which space is desired.

Do not use IEFBR14 and specify a DD card with a multivolume data set because this allocates an extent on only the first volume.

Do not use a separate IEFBR14 utility step to allocate extents on each volume as described previously if you plan to use the Database Image Copy 2 utility (DFSUDMT0). Using a separate IEFBR14 step for each volume creates extents that have the same identifier (volume 1). The Database Image Copy 2 utility requires that you allocate your multivolume data sets by using the standard DFSMS methods.

Preallocating more volumes for OSAM data set extents than are used during initial load or reload processing might cause an abend if you attempt to extend the data set beyond the last volume written to at initial load or reload time under the following circumstances: the initial load or reload step did not result in the data being written to the last volume of the preallocated data set, and secondary allocation was not specified during data set preallocation.

When loading a database, the volumes of the data sets are loaded in the order that their volume serial numbers are listed in the CATLG statement.

Do not reuse a multivolume OSAM data set without first scratching the data set and then reallocating the space. This also applies to the output data sets for the HALDB Online Reorganization function.

Failure to scratch and reallocate the data set might cause an invalid EOF mark to be left in the DSCB of the last volume of the data set when the data set is first reused by an IMS utility (such as the Unload/Reload utility used in database reorganization). Then, the data set is opened by OSAM for normal processing.

For example, a data set might initially be allocated on three volumes with the EOF mark on the third volume. However, after the reorganization utility is run, the data set might need only the first two volumes. Therefore, the new EOF mark is placed on the second volume. After reorganization, when the data set is opened by OSAM for normal processing, OSAM checks the last volume's DSCB for an EOF mark. When OSAM finds the EOF in the third volume, it inserts new data after the old EOF mark in the third volume instead of inserting data after the EOF mark created by the reorganization utility in the second volume.

Subsequent processing by another utility, such as the Image Copy utility, uses the EOF mark set by the reorganization utility on the second volume and ignores new data inserted by OSAM on volume three.