Specifying space for REORG work files, to avoid a B37, D37, E37 abend
Article ID: 20976
Updated On:
Products
Issue/Introduction
The REORG utility can dynamically allocate and create work files. If the models on which they are based do not specify adequate space, a B37, E37, or D37 abend could result.
Environment
All supported releases
Resolution
The REORG utility uses work files which can be allocated and created dynamically or manually. If dynamic allocation and creation are used, then the attributes of the work files must be specified using one or more CREATE DSMODEL statements. For the REORG utility to dynamically allocate a work file, its matching model must minimally specify a DSN attribute so that the name of the data set can be determined. For the REORG utility to create a work file, the DSMODEL must also include information to identify where to create the file, the space to allocate, and a block size to use.
The IDMS Utilities REORG section, indicates the following additional techniques in terms of allocating work files:
- Specify a relatively modest primary allocation and a large secondary allocation. This allows the file to extend to handle large amounts of information without wasting unneeded space.
- Use IBM's Storage Management Subsystem (SMS) to determine where files are to be allocated rather than trying to manually place files on specific volumes. SMS can automatically spread the files across volumes wherever there is available space. Use the DATACLAS and STORCLAS options to allow files to extend across multiple volumes.
- If SMS is not available, allow the files to be allocated across multiple volumes by specifying multiple volume serial numbers. There must be enough space across all listed volumes to satisfy the space needs of all of the work files. The order of the entries in the list is not important.
- Consider using extended format data sets for large work files. Although this adds 32 bytes of overhead to each block, extended format data sets can have more extents across more volumes than a basic format data set."
Sites that do not use SMS, and instead use some other device management product, will fall into the situation described in the third point listed above, and will need to find a way to indicate that multiple volumes can/should be used. CA IDMS supports the VOLSER (xxx,yyy,....) parameter, which can be used for this purpose. If you want to allocate across multiple devices you should use this parameter as long as it is supported by your device management product.
Having said that, whether or not multiple volumes are specified, the DSMODEL statement should be coded in order to ensure that sufficient space is specified for the data set's needs. If the specified space is not adequate for the data, at execution time a B37, E37, or D37 error is likely to result. A B37 typically means that the job step used up the entire amount of disk space specified on the SPACE parameter, and it was not enough. A D37 or an E37 is likely to result if the job step was not able to allocate additional extents on multiple devices.
If any of these errors occur, specify a larger SPACE parameter, and possibly also the VOLSER parm to spread the allocation across multiple devices, as long as the device management product your site uses will recognize this VOLSER parm.
Additional Information
Feedback
