Changing the amount of space allocated

Change the amount of space allocated for your database in two situations.

The first is when you are running out of primary space. Do not use your secondary space allocation because this can greatly decrease performance. Also change the amount of space allocated for your database when the number of I/O operations required to process a DL/I call is large enough to make performance unacceptable. Performance can be unacceptable if data in the database is spread across too much DASD space.

One way to routinely monitor use of space is by watching the IWAITS/CALL field in the DL/I Call Summary report. If the IWAITS/CALL field has a relatively high number in it, the high number can be caused by space problems. If you suspect space is the problem, you can verify such problems in two specific ways:

  • For VSAM data sets, you can get a report from the VSAM catalog using the LISTCAT command. In the report, check CI/CA splits, EXCPs, and EXTENTS.
  • For non-VSAM data sets, you can get a report on the VTOC using the LISTVTOC command. In the report, check the NOEXT field.

If you decide to change the amount of space allocated for your database, do it with JCL or with z/OS® utilities. The reorganization utilities must be run to put the database in its new space. The procedure for putting the database in its new space is as follows:

Procedure

  1. Unload your database, using the existing DBD and the appropriate unload utility.
  2. Recalculate database space.
  3. Delete the old database space for non-VSAM data sets and define new database space. For VSAM data sets, delete the space allocated for the old clusters and define space for the new clusters.
  4. If you are changing the space in the root addressable area of an HDAM database, you might need to adjust other HDAM parameters. In this case, you must code a new DBD before reloading (a new DBD is not needed when a PHDAM partition is changed). To change the space in the root addressable area of a PHDAM partition, you must use the HALDB Partition Definition utility.
  5. Reload your database, using either the existing DBD (if no changes were made to the DBD) or the new DBD. Use the appropriate reload utility.
  6. If your non-HALDB database uses logical relationships or secondary indexes, you must run reorganization utilities before and after reloading the database to resolve prefix information.