The #DGFE audit verifies the configuration data that is defined for replication in your configuration. This audit invokes the Check Data Group File Entries (CHKDGFE) command for the audit’s comparison phase. The CHKDGFE command collects data on the source system and generates a report in a spooled file or an outfile.
The report is available on the system where the #DGFE audit or CHKDGFE command ran. In the report, the values in the Result column indicate detected problems and the result of any automated audit recoveries.
The following table shows the possible Result values and corresponding recovery actions. If the Automatic audit recovery policy is enabled at the time the audit runs, the audit will attempt to perform the recovery action indicated and the status will become either *RECOVERED or *RCYFAILED. If the recovery action could not be performed or if the Automatic audit recovery policy is disabled, user action is needed to manually perform the actions needed to correct the reported problem.
Result |
Description and Recovery Actions |
---|---|
*NODGFE |
No file entry exists. The object is identified by an object entry which specifies COOPDB(*YES) but the file entry necessary for cooperative processing is missing. Create the DGFE or change the DGOBJE to COOPDB(*NO) Note: Changing the object entry affects all objects using the object
entry. If you do not want all objects changed to this value, copy
the existing DGOBJE to a new, specific DGOBJE with the appropriate
COOPDB value.
|
*EXTRADGFE |
An extra file entry exists. The object is identified by a file entry and an object entry which specifies COOPDB(*NO). The file entry is extra when cooperative processing is not used. Delete the DGFE or change the DGOBJE to COOPDB(*YES) Note: Changing the object entry affects all objects using the object
entry. If you do not want all objects changed to this value, copy
the existing DGOBJE to a new, specific DGOBJE with the appropriate
COOPDB value.
|
*NOFILE |
No file exists for the existing file entry. Delete the DGFE, re-create the missing file, or restore the missing file. |
*NOMBR |
No file member exists for the existing file entry. Delete the DGFE for the member or add the member to the file. |
*RCYFAILED |
Automatic audit recovery actions were attempted but failed to correct the detected error. Run the audit again. |
*RCYSBM |
The automatic audit recovery action was submitted to be processed by the replication manager. |
*RECOVERED |
Recovered by automatic recovery actions. No action is needed. |
*UA |
File entries are in transition and cannot be compared. Run the audit again. |
The Option column of the report provides supplemental information about the comparison. Possible values are:
- *NONE - No options were specified on the comparison request.
- *NOFILECHK - The comparison request included an option that prevented an error from being reported when a file specified in a data group file entry does not exist.
- *DGFESYNC - The data group file entry was not synchronized between the source and target systems. This may have been resolved by automatic recovery actions for the audit.
One possible reason why actual configuration data in your environment may not match what is defined to your configuration is that a file was deleted but the associated data group file entries were left intact. Another reason is that a data group file entry was specified with a member name, but a member is no longer defined to that file. If you use #DGFE audit with automatic scheduling and automatic audit recovery enabled, these configuration problems can be automatically detected and recovered for you. The following table provides examples of when various configuration errors might occur.
Result |
File exists |
Member exists |
DGFE exists |
DGOBJE exists |
---|---|---|---|---|
*NODGFE |
Yes |
Yes |
No |
COOPDB(*YES) |
*EXTRADGFE |
Yes |
Yes |
Yes |
COOPDB(*NO) |
*NOFILE |
No |
No |
Yes |
Exclude |
*NOMBR |
Yes |
No |
Yes |
No entry |