FIX and NOFIX: Specifying whether auditing repairs errors

Explanation

FIX and NOFIX are mutually exclusive, optional parameters specifying whether auditing repairs any error it can when an error is found.

FIX: Auditing repairs any error it can.
NOFIX: Auditing reports errors, but does not fix them. For COMMONQUEUE, the number of errors only is reported.

Tip: The output data set contains executable FIXCDS commands to create or correct CDS records, but those CDS changes are only a subset of the corrective actions taken by audit processing. In addition, the CDS records can be read multiple times during the course of an audit. If the NOFIX option is specified, the changes to a record generated on its initial read are not reflected in that record when it is read a subsequent time, this might result in incorrect action being taken. For these reasons, you should not later submit output from an AUDIT NOFIX command as a substitute for an AUDIT FIX command.

Defaults

The default is NOFIX.

Usage notes:

The number of errors reported by AUDIT COMMONQUEUE FIX may be lower than the number of errors reported by a previous AUDIT COMMONQUEUE NOFIX. This is acceptable since the errors in the common queues are interrelated. Hence, fixing one error may actually fix several other errors.
If you specify the FIX parameter and the parameter applies, DFSMShsm issues a message indicating whether the fix was successful or unsuccessful.
The FIX parameter can degrade performance. When you specify it with the MASTERCATALOG or USERCATALOG parameter, DFSMShsm does not fix the audited information. If you specified the FIX parameter with the MASTERCATALOG or USERCATALOG parameter, DFSMShsm allows the operator to cancel an audit by replying N to the following message:
```
   ARC0803A  WARNING:  AUDIT OF CATALOG MAY DEGRADE PERFORMANCE,
             REPLY ‘Y’ TO START AUDIT OR ‘N’ TO CANCEL
             AUDIT COMMAND
```
You must use the FIXCDS command to correct any discrepancies between the catalog and the MCDS.
If you specify the FIX parameter when you audit a primary or migration volume, DFSMShsm scratches and uncatalogs all utility data sets on the volume even if the utility data sets have expiration dates.
If you use the CDSR=YES startup parameter, DFSMShsm issues the RESERVE macro to keep the other z/OS® images from accessing the three volumes containing the MCDS, BCDS, and OCDS under the following conditions:
- You are in a multiple-image environment.
- You have specified the FIX command.
- You have specified SERIALIZATION(CONTINUOUS).
- When the primary audit category is one of the following:
  - ALL | BACKUPCONTROLDATASET | MIGRATIONCONTROLDATASET | OFFLINECONTROLDATASET(DAILY(day) | ML2 | SPILL | ALL)
  - MASTERCATALOG | USERCATALOG(catname)
  - BACKUPTYPE(DAILY(day) | SPILL | ALL) | BACKUPVOLUMES | BACKUPVOLUMES(volser...) | VOLUMES | VOLUMES(volser...)
  - DATASETNAMES(dsname...) | LEVELS(qualifier...)
The reserve applies to the three volumes that contain the control data sets; therefore, no other data sets on those volumes can be accessed from another z/OS image.
If you specify the FIX parameter when you audit a volume, DFSMShsm catalogs the uncataloged data sets (excluding rolled-off GDG data sets) on the volume. Consequently, AUDIT should not be run concurrently with other jobs that are creating uncataloged data sets.