Deleting log data sets with errors

If an active log data set encounters an I/O error, use the DSNJU003 (change log inventory) utility to delete the log data sets with errors.

Procedure

To delete log data sets with errors:

  1. If you use dual active log data sets, check if the data from the bad active log data set is saved in the other active log. If it is, you can use the other active log.
  2. If you cannot use the other active log or if the active log is in the STOPPED status, fix the problem manually by taking the following steps
    1. Check whether the data set was offloaded.
      For example, check the list of archive log data sets to see whether one has the same RBA range as the active log data set. This list can be created by using the DSNJU004 (print log map) utility.
    2. If the data set was not offloaded, copy the data to a new VSAM data set. If the data set was offloaded, create a new VSAM data set that is to be used as an active log data set.
    3. Run the change log inventory utility with the DELETE and NEWLOG statements.
      Important: If misused, the change log inventory utility can compromise the viability and integrity of the Db2 subsystem. Only highly skilled people, such as the Db2 system administrator, should use this utility, and then only after careful consideration.

      The DELETE statement removes information about the bad data set from the BSDS. The NEWLOG statement identifies the new data set as the new active log. The DELETE and NEWLOG operations can be performed by the same job step. The DELETE statement precedes the NEWLOG statement in the SYSIN input data set.

      To ensure consistent results, run the change log inventory utility on the same z/OS® system on which the Db2 online subsystem runs.

      Use the print log map utility before and after you run the change log inventory utility to ensure correct execution and to document changes.

      When you use dual active logs, choose a naming convention that distinguishes primary and secondary active log data set. The naming convention should also identify the log data sets within the series of primary or secondary active log data sets. For example, the default naming convention that is established at Db2 installation time is as follows:

      prefix.LOGCOPYn.DSmm

      In this convention, n=1 for all primary log data sets, n=2 for all secondary log data sets, and mm is the data set number within each series.

      If a naming convention such as the default convention is used, pairs of data sets with equal mm values are usually used together. For example, prefix.LOGCOPY1.DS02 and prefix.LOGCOPY2.DS02 are used together.

      However, after you run the change log inventory utility with the DELETE and NEWLOG statements, the primary and secondary series can become unsynchronized. This situation can occur even if the NEWLOG data set name that you specify is the same as the old data set name. To avoid this situation, always do maintenance on both data sets of a pair in the same change log inventory execution:

      • Delete both data sets together.
      • Define both data sets together with NEWLOG statements.

      The data sets themselves do not require deletion and redefinition.

  3. Delete the bad data set by using VSAM Access Method Services.

What to do next

Before you initiate a conditional restart or cold restart, consider making backup copies of all disk volumes that contain any Db2 data sets. These backup copies enable a possible fallback. The backup data sets must be generated when Db2 is not active.