Error codes (*ERR) and diagnosis

This topic lists the error conditions that AUDIT can detect.

For certain reported conditions involving control information (see topics One and Two), the AUDIT command can determine an Audit Repair Action. If the FIX option is specified, the AUDIT function will take the specified action. Where the verbs “patch,” “create,” or “delete” appear in the table, the AUDIT function generates a FIXCDS command (or series of commands) to make the specified changes. The column below also contains additional diagnostic information for some errors.

It is recommended that you direct AUDIT output to a specific data set, and that you review that output for errors that may have occurred when AUDIT tried to repair a problem.

For those cases where AUDIT cannot repair the problem, some Troubleshooting Hints have been provided.

Note: The error messages are listed sequentially, but not every number in the sequence has been used.

Table 1. Error Codes Used in AUDIT Reports
Description	Audit Repair Action	Troubleshooting Hints
*ERR 01
Neither the catalog nor the MCDS has a record of the data set being audited. This condition can also be caused by the user catalog being offline. Note: This condition may not be an error.	For AUDIT VOLUMES (primary): AUDIT tries to catalog the data set.	If you are auditing a specific data set or level: A dsname or qualifier may have been misspelled; if so, correct the misspelling and reissue the command. The data set may be uncataloged, in which case DFSMShsm would not have a migration copy. If there is no misspelling, the catalog in which the data set is cataloged may be offline; if so, the catalog must be brought online before reissuing the command.
*ERR 02
The catalog has no record of the data set being audited, but the MCDS record indicates that the data set is on a primary volume.	For AUDIT VOLUMES (primary): If the primary volume being audited is the same as the volume serial indicated in the MCDS record, AUDIT tries to catalog the data set.
*ERR 03
The catalog has no entry for the data set that is being audited, but the MCDS record indicates that the data set is on a migration volume.		For AUDIT DSNAMES: Because there is no catalog entry for the data set with the migration copy, that copy is most likely an old one that has not yet been scratched, probably because of a previous error when the data set was being recalled or deleted. There are two methods to correct the problem: (1) issue the HSEND DELETE command for the data set, deleting the D and A records in the MCDS immediately; or (2) have the migration copy and its D record removed during the next migration cleanup by using the FIXCDS D dsname PATCH() command to reset the assigned flag (MCDFASN) bit to 0 (off) and to set the needs scratch flag (MCDFNSCR) bit to 1 (on). `FIXCDS D dsname PATCH(X'06' BITS(0.....1.))` This command resets the assigned bit and sets the needs scratch bit. Also possible: the catalog entry was inadvertently deleted, and the migrated copy is still valid. If this is the case, rebuild the catalog entry as a non-VSAM data set with a volume serial of “MIGRAT”.
*ERR 03 (continued)
The catalog has no record of the data set being audited, but the MCDS record indicates that the data set is on a migration volume.	For AUDIT VOLUMES, MCDS, BCDS, or OCDS: AUDIT catalogs the data set and (for VSAM) any VSAM intercept object names associated with the data set, with a volume serial of MIGRAT. Note: If the data set in question is a rolled-off generation data set (GDS), no error is reported, and the GDS is not recataloged.	For AUDIT VOLUMES (primary): Although there is no catalog entry for the migrated data set, there is an uncataloged data set with the same name on the primary volume being audited. If you can verify that there is no relationship between these two data sets, the persistence of the migration copy is probably caused by a previous error when the data set was being recalled or deleted. You can have the migration copy and its D record removed during the next migration cleanup by using the FIXCDS D dsname PATCH() command to reset the assigned flag (MCDFASN) and to set the needs scratch flag (MCDFNSCR). `FIXCDS D dsname PATCH(X'06' BITS(0.....1.))` This command resets the assigned bit and sets the needs scratch bit.
*ERR 04
The catalog record of the data set being audited indicates that the data set is on a level 0 volume, but this could not be verified. No MCDS record of the data set exists for this error condition. This may or may not be an error.		If you can verify that the data set in question is on the volume indicated by the catalog entry, there is no problem. Otherwise, you should either delete the catalog entry or alter it to indicate the correct volume serial numbers.
*ERR 05
The data set is cataloged on a volume other than the volume being audited. No MCDS record exists for the data set.		The volume being audited apparently has an uncataloged data set with the same name as a data set (on another volume) that is cataloged. You may want to rename the uncataloged data set, then catalog it also under its new name.
*ERR 06
The catalog and the MCDS records for the data set being audited indicate that the data set is on a primary volume. The data set, however, is not on the volume recorded in the catalog, and the volume where the data set does reside cannot be determined.		The volume in question may not be mounted. If you can verify which volume contains the data set in question, alter the catalog entry to indicate the correct volume. Otherwise, if you can verify that the data set is no longer needed, delete the catalog entry. The existence of the MCDS record indicates that migration cleanup has not yet removed that record of a previously recalled data set.
*ERR 07
The serial number of the volume containing the data set being audited as recorded in the catalog does not agree with the serial number of the primary volume containing the data set as recorded in the MCDS. The two conflicting volume serial numbers are on the lists under the CATALOGED TO VOLUME and MIGRATED TO VOLUME headings, respectively.		This condition can occur when a migrated data set is recalled, moved to another primary volume, and the audit is done before migration cleanup has removed the MCDS record. After migration cleanup has removed the record, the AUDIT function no longer reports the condition.
*ERR 08
The catalog indicates that a data set of the same name resides on a volume other than the one being audited. The MCDS record indicates a primary volume.		The volume being audited apparently has an uncataloged data set with the same name as a data set (on another volume) that is cataloged. You may want to rename the uncataloged data set, then catalog it also under its new name.
*ERR 09
The catalog record of the data set being audited indicates that the data set is on a volume not managed by DFSMShsm, but the MCDS indicates that the data set is on a migration volume.		The catalog may have been offline to DFSMShsm when the catalog entry for the data set in question was replaced with one for a nonmigrated (or recalled) data set. The condition could have also been caused by a DELETE NOSCRATCH operation. The MCDS record for the data set will have the serial number of the volume from which the data set was migrated. If you can determine that the current catalog entry has the correct status for the data set, use the FIXCDS D dsname PATCH() command to reset the assigned flag (MCDFASN) and to set the needs scratch flag (MCDFNSCR) in the MCDS record; this causes the next migration cleanup to remove the migration copy. `FIXCDS D dsname PATCH(X'06' BITS(0.....1.))` This command resets the assigned bit and sets the needs scratch bit. If, however, you determine that the correct status for the data set is a migrated copy, then alter the data set now referred to by the catalog entry to refer to volume MIGRAT.
*ERR 10
The catalog record of the data set being audited indicates that the data set is on a migration volume, but the MCDS has no record of the data set.		To indicate a migrated data set, DFSMShsm uses the volume serial MIGRAT in the catalog entry for that data set. If someone in your organization catalogs data sets on a primary volume called MIGRAT, change that volume serial number and alter all related catalog entries to avoid confusion with DFSMShsm’s indicator. If no such primary volume MIGRAT exists, then you need to verify whether the data set in question is supposed to be migrated: If it is and you need to recall the data set, you need to locate the migration copy. (If no previous LIST output or activity log identifies the migration volume, do a LIST VTOC [for each DASD migration volume] or LIST TTOC [for each tape migration volume].) Then reconstruct the MCDS record, using the following command: `FIXCDS D dsname ADDMIG(volser)` Another way to rebuild the data set record is to run AUDIT MEDIACONTROLS, once you have determined the volume serial number. This may be required for successful recall of the data set. If the data set is not supposed to be migrated, either delete the catalog entry, or alter it to refer to a different (primary) volume.
*ERR 11
The catalog record of the data set being audited indicates that the data set is on a migration volume, but the MCDS record indicates that the data set is on a primary volume.		To indicate a migrated data set, DFSMShsm uses the volume serial MIGRAT in the catalog entry for that data set. If someone in your organization catalogs data sets on a primary volume called MIGRAT, change that volume serial number and alter all related catalog entries to avoid confusion with DFSMShsm’s indicator. If no such primary volume MIGRAT exists, then an error has apparently occurred during an attempted recall of the data set in question. You need to verify whether the data set is supposed to be migrated: If it is and you need to be able to recall the data set, use the FIXCDS D dsname DISPLAY command to determine from the MCDS record what migration volume has held the migration copy, verify (with the LIST or AUDIT command) that the migration copy is still on that migration volume, and set the assigned flag (MCDFASN) in the MCDS record by using a FIXCDS D dsname PATCH() command. This command sets the assigned bit. `FIXCDS D dsname PATCH(X'06' BITS(1.......))`
*ERR 12
The catalog and MCDS records of the data set being audited indicate that the data set is on a migration volume, but the mounted volume table entry indicates that the volume is not a migration volume. (The data set is apparently a very old migration copy, made before HSM Release 3.)		Most likely an uncataloged data set on the volume has the same name as a (very old) cataloged migrated data set. This is not an error, but you should catalog all your data sets. Otherwise, if you can determine (from lists of migration volumes, and so forth) that DFSMShsm should have considered the volume as a migration volume, then use the FIXCDS V volser PATCH() command to set the flag in the volume record that identifies the volume as a migration volume rather than a level-0 volume.
*ERR 14
The BCDS backup version record of the data set being audited specifies a serial number that does not match the serial number of the backup volume being audited. If the data set resides on a tape volume, this error is detected only if the volume is also not spanned by the data set being audited.	For a tape backup volume, AUDIT sets the invalid flag in the TTOC entry, and in the TTOC for any spanned volume.
*ERR 15
Either the catalog entry for this data set indicates that the type of data set is not supported by DFSMShsm migration, or the entry did not indicate a volume for the data set.		For AUDIT DSNAMES: Most likely this error is a typing error in specifying a particular data set to be audited; the object cataloged by that name is not one that is supported by DFSMShsm. Correct the spelling of the dsname and reissue the AUDIT command. For AUDIT VOLUMES: Since the catalog indicates the data set is something not supported by migration (for instance, a VSAM page space), this may not be an error. Even so, it is probably best to move the data set to another volume.
*ERR 16
The TTOC records do not coincide with the catalog and the MCDS data set record. One of the following conditions may have occurred: The catalog and the MCDS data set record say the data set is migrated. The volume serial number of the TTOC, however, does not match the volume serial number in the MCDS data set record, or (according to that record) of any volumes the data set might span. The catalog and the MCDS data set record indicate that the data set is on a specific primary volume. The TTOC, however, contains a valid data set entry for the data set, which means the data set has been migrated (and may have been recalled). If the DATA SET ON VOLUME field contains “INVALID”, the TTOC indicates that the data set copy is invalid. If the DATA SET ON VOLUME field contains “NO ENT”, one of the following conditions is true: If the tape being audited is in single-file format, the data set cannot be found in the TTOC extension identified by the MCD record. If the tape being audited is a multifile tape, the file block identifiers (FBID) in the TTOC do not coincide with the FBID in the MCD record. This situation may be resolved by recalling and again migrating the data set in error.		The TTOC entry may identify a previous migration copy. A system failure most likely occurred before DFSMShsm was able to invalidate it. You can use the FIXCDS T command to invalidate the entry for the data set in question: `FIXCDS T key ENTRY(dsname) PATCH(X'34' BITS(.0......))` Verify that the migration volume referred to in the data set record actually contains a migration copy of the data set. (If the volume is a tape volume, you can issue a LIST TTOC command.)
*ERR 17
Here are the possible error conditions AUDIT reports and their meanings: OFFLNE The catalog cannot be opened, and is probably offline. NO TTC The TTOC record of the migration volume or backup volume as indicated in the data set record does not exist. The missing TTOC record can be either the base TTOC record or an extension TTOC record. -SEQ1- The first data set file sequence number in the base TTOC record is greater than the data set file sequence number indicated in the MCDS data set record. -SEQ1- The last data set file sequence number in the base TTOC record is less than the data set file sequence number indicated in the MCDS data set record for a non-VSAM data set. -SEQ1- The last data set file sequence number in the base TTOC record plus one is less than the data set file sequence number indicated in the MCDS record for a VSAM data set. -SEQ2- The TTOC record shows a data set name based on the data set file sequence number found in the MCDS data set record. This data set name in the TTOC does not match the data set name in the MCDS data set record.		Check that the catalog is online to DFSMShsm while the AUDIT command is running; an offline catalog can cause this error indication. If the catalog is not offline, then diagnosis depends on the tape format involved: If the tape is in single-file format, run the AUDIT MEDCTL command against the tape volume to determine, by checking the tape volume, whether the MCDS data set record or the TTOC record set is in error. (The FIX option will regenerate a TTOC set.) If the tape is in multifile format, the TTOC entry most likely represents an out of date copy and can be invalidated by using the FIXCDS T command: `FIXCDS T key ENTRY(dsname) PATCH(X'34' BITS(.0......))`
*ERR 18
The catalog record of the data set being audited indicates that the data set is on a primary volume, but the MCDS indicates that the data set is on a migration volume.		The catalog may have been offline to DFSMShsm when the catalog entry for the data set in question was replaced with one for a nonmigrated (or recalled) data set. The MCDS record for the data set will have the serial number of the volume from which the data set was migrated. If you can determine that the current catalog entry has the correct status for the data set, then use the FIXCDS D dsname PATCH() command to reset the assigned flag (MCDFASN) and to set the needs scratch flag (MCDFNSCR) in the MCDS record; this causes the next migration cleanup to remove the migration copy. `FIXCDS D dsname PATCH(X'06' BITS(0.....1.))` This command resets the assigned bit and sets the needs scratch bit. If, however, you determine that the correct status for the data set is a migrated copy, then rename and recatalog the data set now referred to by the catalog and alter the original catalog entry to refer to volume MIGRAT.
*ERR 19 userdsn HAS NO D RECORD
Data set userdsn is not migrated. No data set (D) record can be found.		The data set name may be spelled incorrectly.
*ERR 20 userdsn ON migvol, BUT NO V RECORD
The catalog indicates that data set userdsn has been migrated and the MCDS indicates that the migration copy is on a specific migration volume (migvol); but there is no migration volume (V) record for that volume.	If the D record is flagged to indicate the copy is in an SDSP data set, and If an SDSP data set can be found on the volume, an ADDVOL command is generated for the L1 volume. If no SDSP data set can be found on the volume, but the migration copy can be found there, the D record is patched to reset the SDSP flag, and an ADDVOL command is generated for the L1 volume. If the D record is not flagged for a copy in an SDSP data set, and the migration copy can be found on the volume, an ADDVOL command is generated for the L1 volume.
*ERR 21 userdsn INDICATES DEVICE TYPE X'...', V RECORD INDICATES X'...'
For user data set userdsn, a data set (D) record exists, indicating that the migration copy is on a migration volume of device type X'...', but the volume (V) record for that volume indicates a different device type X'...'.	If the volume record indicates tape, and a TTOC record exists, the data set (D) record is patched to replace the device type. If the volume record indicates DASD and the migration copy can be found on the volume, the data set (D) record is patched to replace the device type.
*ERR 22 userdsn HAS NO ALIAS RECORD
The data set (D) record for user data set userdsn indicates that the migration copy is not in an SDSP data set. Therefore, there should be a MCDS alias record identifying the migration copy; but the MCDS alias record does not exist.	If the migration copy can be found on the volume, an alias (A) record is created.
*ERR 23 userdsn—VSAM ASSOCIATIONS RECORD MISSING
The MCDS data set (D) record for user data set userdsn indicates the existence of a MCDS VSAM association (O) record, but no such record exists.		If the VSAM data set has already been recalled, then the D record is extraneous; you can use the FIXCDS command to delete it.
*ERR 24 userdsn—MISSING VSAM INTERCEPT OBJECT
The MCDS VSAM associations (O) record for the migration copy of data set userdsn indicates the existence of an intercept object representing one of the components of the VSAM data set. The catalog entry for this object is not a non-VSAM entry indicating MIGRAT as its only volume serial.	The VSAM Association (O) record is patched, to correspond to the actual components found.
*ERR 25 userdsn—component MIGRATED, BUT NO ALIAS RECORD
The VSAM associations (O) record for the migration copy of data set userdsn indicates the existence of an intercept object representing a component of the VSAM data set. This component has a non-ICF catalog entry with a volume serial of MIGRAT, but the MCDS alias (A) record does not exist.	The alias (A) record for the component is created.
*ERR 26 userdsn—L RECORD MISSING
The MCDS data set record for data set userdsn indicates that a BCDS backup migrated data set (L) record has been created, but no such L record exists.	If a BCDS data set (B) record is found that indicates a backup was made after the migration date, the MCDS data set (D) record is patched to reset the L-record flag. If no such B record is found and the D record indicates the migration copy is on L1, a BACKDS command is generated for the data set.
*ERR 27 userdsn—EXTRANEOUS VSAM ASSOCIATIONS RECORD
A VSAM-associations (O) record refers to an MCDS data set (D) record for data set userdsn. Either the data set record does not exist, or (if present) does not indicate the existence of a VSAM-associations record.	The VSAM Association (O) record is deleted.
*ERR 28 userdsn—EXTRANEOUS ALIAS RECORD
An extraneous MCDS alias (A) record is referring to an MCDS data set (D) record for data set userdsn, but the MCDS data set (D) record does not exist.	If there is no data set (D) record, The alias (A) record is deleted; If the A record indicates a VSAM component, and the catalog entry for that component indicates that it is migrated, the catalog entry is deleted.
*ERR 29 userdsn—NO TTOC RECORD
An MCDS data set (D) record for a migration copy of data set userdsn indicates the migration copy is on a migration tape volume. Either no TTOC record exists for the migration volume, or no TTOC extension contains a valid entry for the migration copy.		You can run AUDIT MEDCTL against the migration tape in the D record, and (if FIX is specified) AUDIT will rebuild the TTOC. This error may occur if AUDIT DATASETCONTROLS is executed while migration is currently updating a given TTOC record. If this occurs, run AUDIT DATASETCONTROLS while migration is inactive.
*ERR 30 INVALID CDS RECORD TYPE.
An invalid record type has been detected in the control data set (MCDS or BCDS) being audited.	The unknown record is deleted (internally).
*ERR 35 MCB VERSION FIELD FOR `dsn` NEEDS VERSION NUMBER `vernum`
All MCC (backup version) records that are associated with the specified MCB (data set backup) record have been audited. During the audit of these records, the most current version found based on the MCC record timestamp has been tracked. The MCBGEN field should contain the version number of the most current MCC record, but it does not. If the suggested version number is 1, then in most cases this indicates that the actual version number could not be determined, so versioning is restarted. This situation occurs only if an existing version number cannot be established.	A FIXCDS PATCH is issued to update the MCBGEN field to the highest version number.	None.
*ERR 36 BACKUP VERSION ENTRY `backupdsn` CONTAINS (`mcbver`), SHOULD CONTAIN (`mccgen`)
The MCC record and associated MCB record have a discrepancy between the MCBVER and MCCGEN fields for the specified version entry. The MCBVER field needs to be modified to be the same as the MCCGEN field for the version entry.	A FIXCDS PATCH is issued to update the MCBVER field to the proper value, which is the value contained in the MCCGEN field of the associated MCC record.	None.
*ERR 37 <MCBR key> BAD SEQUENCE NUMBER
The sequence number in the MCBR (Z) record and MCC (C) record should be identical, but they are not. Either the data set backup retained copy (Z) record or the data set backup version (C) record are in error.		You can display the MCBR (Z) record using the following command: `FIXCDS Z <MCBR key> INDEX(n) DISPLAY` The default for INDEX(n) is INDEX(1), which will display the most current MCBR record for that data set. See z/OS DFSMShsm Diagnosis for more information on using the FIXCDS command. You can display the MCC (C) records using the following command: `FIXCDS C <MCC key> DISPLAY` You can find the MCBR key in the ERR37 message text. You can find the MCC keys in the output of the FIXCDS Z DISPLAY command. All MCC records listed in the MCBR version array should contain the same sequence number. Each MCC record needs to be FIXCDS displayed to find its sequence number. You need to consider all of the sequence number information when determing which record contains the incorrect sequence number. You can use the FIXCDS PATCH command to correct the record with the correct sequence number.
*ERR 38 <MCC OR MCB key> HAS INVALID SEQUENCE NUMBER
The dataset backup record contains an indication of the number of dataset backup retained copy records that exist. The number is incorrect.
*ERR 39 userdsn IS MISSING version
The BCDS data set (B) record for userdsn refers to a backup version of that data set. However, the corresponding backup version (C) record no longer exists or exists but does not refer back to this (B) record.		The time and date stamp incorporated in the version name may indicate a version old enough that it is no longer useful, and the copy referred to by that version name may no longer exist. If a LIST BCDS LEVEL(userdsn) indicates there are other available versions of userdsn, you may not need the missing version. If there is no other available version, you need to determine (for example, from a previous LIST output) what backup volume contains the version, so that you can use the "FIXCDS C version ..." command to regenerate the C record. You should discover what caused the deletion of the C record and correct that problem to avoid future occurrences.
*ERR 40 userdsn - backup version name MISSING B RECORD
The backup version (C) record refers to a BCDS data set record that does not exist, or the (B) record exists but does not refer to the backup version (C) record. In the message, userdsn is the original data set name in the (B) record and version is the generated backup name in the (C) record. Note: Each FIXCDS command generated with this error is dependent on previous FIXCDS commands. If NOFIX is used, the offsets in the output data set are invalid.	If the backup version (C) record indicates the version is invalid, then a BDELETE command is issued to delete the backup version (C) record. If the backup version (C) record indicates the backup version is for an uncataloged data set or a data set with the RACF® erase on scratch option, then no action is taken – regardless of whether there is a valid data set (B) record or not. If the backup version (C) record references a data set (B) record that does not exist, then a new (B) record is created and the version added. If the data set (B) record referenced by the backup version (C) record exists but does not correspond to the specified backup version, then one of the following actions will be performed: If the maximum number of backup versions has been reached and the specified backup version is older than any of those described in the data set record, the backup version is deleted. If the maximum number of backup versions has not been reached, then the data set (B) record is extended. If the version is older then any of those described in the (B) record, then it is added at the end. If the version is not the oldest, then it is inserted in date order.	The number of versions specified by SETSYS VERSIONS or in the management class is ignored and new versions might be added until the system maximum has been reached. Subsequent BACKUP, EXPIREBV, or BDELETE commands can be used to cleanup unwanted backup versions. The RECYCLE command must be issued to delete the versions from the backup volumes. GENERATION and VERSION numbers are not updated in the data set (B) record as backup versions are added. Different backup versions can have duplicate numbers. Backup versions are added to the (B) record in date order. If multiple backup versions exist for the same date, they are not specifically ordered by time. Cataloged backup versions take precedence over uncataloged backup versions with newer dates.
*ERR 41 version INDICATED ON backvol, BUT NO X RECORD
The backup version (C) record for version indicates the version is on backup volume backvol, but no BCDS backup volume (X) record exists for backvol.	If the volume is found to be an L1 volume, the data set (B) record is patched to indicate L1 residence of this version. If the volume is the second or later of a multivolume version, an ADDVOL command is generated for volume serial backvol.
*ERR 42 version INDICATED ON migvol, BUT NO V RECORD
A backup version (C) record indicates version is on migration volume migvol (that is, it has been created by the (H)BACKDS command), but no MCDS volume record (V) exists for migvol.	If the volume is found to be a backup volume, the data set (B) record is patched to indicate the version is not on L1. Otherwise, an ADDVOL command is generated for the L1 volume.
*ERR 43 version RESIDES ON migvol, BUT NO M RECORD
*ERR 43 migvol - CONTAINS version, BUT NO M RECORD
Backup version version exists on migration volume migvol, but no BCDS move backup version (M) record exists for moving the version to a backup volume.	If a backup version (C) record exists for the version, and If a BCDS data set (B) record referring to the version exists, an M record is created. If no such B record exists, the C record is patched for subsequent deletion and scratching of the backup version.
*ERR 44 version INDICATES DEVICE TYPE X'...', X RECORD INDICATES X'...'
The BCDS backup version (C) record for version indicates the version is on a backup volume of device type X'...', but the volume (X) record for that volume indicates a different device type X'...'.	If the volume record indicates tape, and a TTOC record exists, the backup version record is patched to replace the device type. If the volume record indicates DASD, and the backup version can be found on the volume, the backup version record is patched to replace the device type.
*ERR 45 version - NO TTOC ENTRY
A BCDS backup version (C) record for version indicates the version is on a backup tape volume. Either no TTOC record exists for the backup volume, or no TTOC extension contains a valid entry for the backup version.
*ERR 46 userdsn - BAD L RECORD
A backup migrated data set (L) record refers to a migration copy of data set userdsn, but no MCDS data set (D) record exists.	The L record is deleted.
*ERR 47 version INDICATED ON migvol, BUT CANNOT BE FOUND
The BCDS data set (B) record indicates that version is on migration volume migvol and a backup version (C) record exists, but either migvol is not mounted or it does not contain the backup version.		If the version is no longer needed, no action need be taken. If the migration volume is mounted, but you know the version is on a different volume, you can use the FIXCDS command to update volume serial numbers in the C record for the version. If the migration volume is not mounted, it should be mounted to provide access to the version.
*ERR 48 userdsn HAS NO B RECORD
Data set userdsn, specified as a parameter for auditing backup controls, is not backed up (does not have a BCDS data set (B) record).		The data set name may be spelled incorrectly.
During AUDIT MEDIACONTROLS VOLUMES processing, a data set backup version for `userdsn` was found on the tape volume specified. There is no BCDS data set (B) record for `userdsn`.		If a backup version is required for data set `userdsn`, use the BACKDS command to create a current backup version.
*ERR 50 volser NOT A MIGRATION VOLUME [(DUMP\|BACKUP\|LEVEL-0)]
Specified volume volser is not a migration volume as there is no MCDS migration volume record. If volume volser is a BCDS dump volume record, it will be reported as (DUMP). If volume volser is a BCDS backup volume record, it will be reported as (BACKUP). If volume volser is a level-0 volume, it will be reported as (LEVEL-0).		The volume serial specified in the command may be spelled incorrectly. If not, and the volume is identified as a different type of DFSMShsm-owned or DFSMShsm-managed volume, you cannot use this AUDIT option on the volume. If the volume serial is not misspelled and you have evidence that the volume was once managed by DFSMShsm, you need to check DFSMShsm logs to determine why the volume was deleted.
*ERR 51 volser - V RECORD INDICATES TAPE, NO TTOC EXISTS
A migration (V) record for volume volser exists, but no TTOC base record is found.	If the volume record indicates A tape other than one in single-file format, and An empty volume an ADDVOL command is generated for volser. If the volume record indicates a tape in single-file format, the base TTOC is created, and individual data set TTOC entries are created as the tape is read.
*ERR 52 volser - V RECORD INDICATES NO RACF, TTOC INDICATES RACF
*ERR 52 volser - X RECORD INDICATES NO RACF, TTOC INDICATES RACF
*ERR 52 volser - X RECORD INDICATES RACF, TTOC INDICATES NO RACF
For volume volser, there is a conflict between either the MCDS volume (V) record or the BCDS backup volume (X) record and the TTOC. The V record or the X record for volser indicates a RACF protected tape, but the TTOC record does not, or vice versa.	If RACF indicates that the volume is RACF protected, either the TTOC or the volume record is patched to indicate that protection.
*ERR 53 volser - RACF-INDICATED, BUT NOT IN DFSMShsm’S TAPEVOL
*ERR 53 volser - IN DFSMShsm’S TAPEVOL, BUT NOT RACF INDICATED
For volume volser, there is a conflict between either the MCDS volume (V) record or the BCDS backup volume (X) record and DFSMShsm’s TAPEVOL volume set. The V record or the X record for volser indicate a RACF protected tape, but DFSMShsm’s TAPEVOL volume set does not, or vice versa.	If RACF indicates that the volume is not in DFSMShsm’s tape volume set, RACF is invoked to add the volume to the set; otherwise, the volume record is patched to indicate RACF protection.
*ERR 54 volser IN L2CR RECORD, NO V RECORD
Volume volser, which is in the L2CR record, does not have a MCDS volume (V) record.		If the volume is not intended to be (or is no longer) a DASD level-2 migration volume, you can use the FIXCDS command to remove the entry for the volume from the L2CR record or use the DEFINE ML2 to redefine the list of volumes to be associated with the key range involved. Otherwise, issue an ADDVOL command for the volume, to reidentify it to DFSMShsm as a DASD level-2 migration volume.
*ERR 55 volser IN L2CR RECORD NOT DASD L2 VOLUME
Volume volser in the L2CR record has a corresponding MCDS volume (V) record that indicates a volume type other than DASD (L2).		If the V record for the volume correctly indicates that the volume is not a DASD level-2 migration volume, you can use the FIXCDS command to remove the entry for the volume from the L2CR record or use the DEFINE ML2 to redefine the list of volumes to be associated with the key range involved. Otherwise, use the FIXCDS command to correct the V record so that the volume is identified as a DASD level-2 migration volume.
*ERR 56 MC1 EXTENSION nnnn MISSING
The last MC1 migration level-1 free space (1) record incorrectly indicates that there is another extension record nnnn.	The last MC1 extension is patched to indicate no continuation.
*ERR 57 MC1 EXTENSION nnnn EXTRANEOUS
There is an extraneous extension record nnnn in the MCDS migration level-1 free space record.	The extraneous MC1 extension is deleted.
*ERR 58 orig volser ALTERNATE TAPE VOLSERS MISMATCHED: TTOC ttoc volser {MCT mct volser \| MCV mcv volser}
The alternate volume serials for duplex volumes do not match between the TTOC ttoc volser and either the MCT mct volser or the MCV mcv volser.
*ERR 70 volser NOT A BACKUP VOLUME [(DUMP\|MIGRATION\|LEVEL-0)]
Volume volser is not a backup volume as there is no BCDS backup volume record. If volume volser is a BCDS dump volume, it is reported as (DUMP). If volume volser is a MCDS migration volume, it is reported as (MIGRATION). If volume volser is a level-0 volume, it is reported as (LEVEL-0).		The volume serial specified in the command may be spelled incorrectly. If not, and the volume is identified as a different type of DFSMShsm-owned or DFSMShsm-managed volume, you cannot use this AUDIT option on the volume. If the volume serial is not misspelled and you have evidence that the volume was once known to DFSMShsm, you need to check DFSMShsm logs to determine why the volume was deleted.
*ERR 71 volser - TTOC EXISTS, NO X RECORD
The TTOC base record was found for volume volser, but the backup volume (X) record is missing.
*ERR 71 volser - X RECORD INDICATES TAPE, NO TTOC EXISTS
A backup volume (X) record for volume volser exists, but no TTOC base record has been found.	For VOLUMECONTROLS(BACKUP) If the X record indicates an empty volume, an internal ADDVOL command is generated for volser. For MEDIACONTROLS:The base TTOC is created, and individual data set TTOC entries are created as the tape is read.
*ERR 72 volser - X RECORD - {SP\|UN\|DAY nn}, BVR - {UN\|DAY nn\|SP}
A BVR is a BCDS backup cycle volume record subdivided into spill and day of backup cycle (daily). A BVR lists a backup volume volser, but there is a mismatch between the BCDS backup volume (X) record type {SP\|UN\|DAY nn} and the BVR type {UN\|DAY nn\|SP}.	The BVR entry is deleted.
*ERR 73 volser - X RECORD - {SP\|UN\|DAY nn}, TTOC - {UN\|DAY nn\|SP}
The usage for volume volser in the BCDS backup volume (X) record is inconsistent with the {SP\|UN\|DAY nn} usage in the TTOC record key.		Depending on your intended backup usage for the volume, use the FIXCDS command to correct either the TTOC record set (the base and any extensions), or the X record.
*ERR 74 volser - X RECORD INDICATES TAPE, BVR ENTRY INDICATES DASD
*ERR 74 volser - X RECORD INDICATES DASD, BVR ENTRY INDICATES TAPE
A BVR is a BCDS backup cycle volume record subdivided into spill and day of backup cycle (daily). The BVR record entry does not agree with the BCDS backup volume (X) record as to whether volume volser is a DASD or tape volume.	The BVR entry is patched to agree with the volume record.
*ERR 75 volser - X RECORD INDICATES FULL, BVR ENTRY INDICATES NOT FULL
*ERR 75 volser - X RECORD INDICATES NOT FULL, BVR ENTRY INDICATES FULL
A BVR is a BCDS backup cycle volume record subdivided into spill and day of backup cycle (daily). There is a conflict between a BVR entry and a BCDS backup volume (X) record, where the X record indicates full but the BVR record indicates not full, or vice versa.	The BVR entry is patched to agree with the volume record.
*ERR 76 volser - X RECORD INDICATES SINGLE-FILE TAPE, BVR IS MULTI-FILE
*ERR 76 volser - X RECORD INDICATES MULTI-FILE TAPE, BVR IS SINGLE-FILE
A BVR is a BCDS backup cycle volume record subdivided into spill and day of backup cycle (daily). There is a conflict between a BVR entry and a BCDS backup volume (X) record, for volume volser: The X record indicates a multifile format whereas the BVR entry indicates a single-file format, or vice versa.	The BVR entry is patched to agree with the volume record.
*ERR 77 volser - X RECORD, NO BVR ENTRY
A BVR is a BCDS backup cycle volume record subdivided into spill and day of backup cycle (daily). A BVR entry exists for volume volser, but there is no BCDS backup volume (X) record for the volume, or vice versa.	If the BVR entry is missing, an ADDVOL command is generated for the volume, to create the missing entry. If the volume record is missing, the BVR entry is deleted.
*ERR 78 BVRxx EXTENSION nnnn MISSING
A BVR is a BCDS backup cycle volume record subdivided into spill and day of backup cycle (daily). In the BVR record set, the last entry indicates that there is another extension (nnnn), but the extension does not exist.	The missing BVR extension is created.
*ERR 79 BVRxx EXTENSION nnnn EXTRANEOUS
A BVR is a BCDS backup cycle volume record subdivided into spill and day of backup cycle (daily). There is an extraneous extension nnnn in the BVR record set BVRxx.	The previous BVR extension is patched to indicate the continuation.
*ERR 90 volser - NO V OR X RECORD
An eligible volume (P) record indicates that volume volser has been backed up or dumped and is a DFSMShsm volume, but neither a BCDS backup volume (X) record nor a MCDS migration volume (V) record exists for volume volser.		If the P record represents a DFSMShsm-owned volume that was backed up at some point and then deleted, the P record can be left as it is, in case you need to recover the volume. If the volume is not a DFSMShsm-owned volume, you can use the FIXCDS command to reset the DFSMShsm-owned flag in the P record.
*ERR 91 volser - vtoccopy INDICATED ON migvol, BUT NO V RECORD
The BCDS eligible volume (P) record for volume volser indicates that VTOC copy data set vtoccopy is on migration volume migvol, but no corresponding MCDS volume (V) record exists for migvol.	If the VTOC copy can be found on the volume, an ADDVOL command is generated for an L1 volume.
*ERR 92 volser - vtoccopy INDICATED ON backvol, BUT NO X RECORD
The BCDS eligible volume (P) record for volume volser indicates that VTOC copy data set vtoccopy is on backup volume backvol, but no corresponding BCDS backup volume (X) record exists for backvol.		If you can confirm that the VTOC copy data set still resides on the volume, then you can add the volume as a backup volume, using the ADDVOL command.
*ERR 93 volser - vtoccopy INDICATED SPANNING TO backvol, BUT NO X RECORD
The BCDS eligible volume (P) record for volume volser indicates that VTOC copy data set vtoccopy spans to a second volume (backvol). No BCDS backup volume (X) record exists, however, for backvol.		The data set is probably an obsolete VTOC copy data set. If the volume indicated by qualifier “.Vvolser” has not been backed up (or dumped) since the date indicated in qualifier “.Dyyddd”, issue the BACKVOL command for the volume.
*ERR 94 volser - NO DGN RECORD FOR generation
The BCDS eligible volume record for volume volser refers to dump generation generation, but no corresponding dump generation (G) record exists.		If ERR 103 occurs for the volume in ERR 94, use the FIXCDS command to correct either the G record or the generation entry in the P record. If you also see an ERR 104 message referring to this generation, it will identify the dump volume that contained the missing generation.
*ERR 95 volser - NO DVL RECORD FOR dumpvol IN COPY n OF generation
The BCDS eligible volume record for volume volser indicates one or more dump generation record keys. Dump generation copy n of dump generation generation describes a dump volume (dumpvol). No BCDS dump volume record exists for dumpvol.		You should use the ADDVOL command to identify the volume as a dump volume. If the generation contains other dump copies or if you have no need to restore data from that generation (for example, there is a later generation), no further action is needed. Otherwise, use the FIXCDS command to update the Y record for the volume, using the dump class and volume sequence data from the dump copy information in the G record.
*ERR 96 volser - INVALID DVL RECORD FOR dumpvol IN COPY n OF generation
For volume volser, there is an invalid BCDS dump volume record for dump volume dumpvol in copy n. This is described in the dump generation (G) record for generation.		If you know (for example, from DFSMShsm LIST output) that the volume does contain part of a dump copy for generation, use the FIXCDS command to turn on the valid flag in the Y record for the volume.
*ERR 97 volser - BAD CHAIN FROM generation TO dumpvol
1) The dump generation (G) record for generation refers to dump volume dumpvol as holding part of a dump copy, but the dump volume (Y) record for dumpvol contains part of a different generation. 2) The position of dump volser dumpvol in the array of volumes for its dump copy in the (G) record is inconsistent with the position of the entry in the (Y) record which refers to that generation.		If you know (for example, from DFSMShsm LIST output) that the volume does contain part of a dump copy for generation, use the FIXCDS command to update the Y record for the volume to refer to that generation. You may also see an *ERR 98 message for the dump volume.
*ERR 98 volser - BAD CHAIN FROM dumpvol TO generation
The dump volume (Y) record for dumpvol indicates that the volume contains part of a dump copy in generation generation, but the dump generation (G) record for generation does not refer to volume dumpvol.		If you also see an ERR 97 message referring to the volume, use the FIXCDS command to update the Y record for the volume to refer to the generation* mentioned in the *ERR 97 message.
*ERR 99 volser - CLASS class1 OF dumpvol, CLASS class2 IN generation
For dump generation generation of eligible volume volser, dump volume dumpvol is supposed to contain part of a dump copy. However, the CLASS (class1) listed in the BCDS dump volume record and the CLASS (class2) listed in the BCDS dump generation record are not the same.		Based on your knowledge from previous DFSMShsm output of the intended dump class for the dump volume, use the FIXCDS command to correct the dump class name in either the Y record for the volume or the G record for generation.
*ERR 100 volser - BAD VOL SEQ FOR dumpvol IN COPY n OF generation
For eligible volume volser, the volume sequence number for dump volume dumpvol in the dump volume record does not agree with the sequence number for that volume in copy n in the dump generation (G) record for generation.		Based on your knowledge from previous DFSMShsm output of the sequence of dump volumes in the dump copy, use the FIXCDS command to correct the volume sequence field in the Y record for the volume, or the position of the volume in the dump copy’s array of volumes in the G record for the generation.
*ERR 101 volser - dumpvtoccopy INDICATED ON migvol, BUT NO V RECORD
A BCDS eligible record for volume volser exists, indicating that dump VTOC copy data set dumpvtoccopy should exist on migration volume migvol. No MCDS migration volume (V) record exists for migvol.	If the DUMPVTOC copy can be found on the volume, an ADDVOL command is generated for an L1 volume.
*ERR 102 volser - NO P RECORD FOR generation
For volume volser, there is a dump generation record (generation) that does not have a corresponding BCDS eligible volume (P) record.		If you need to restore the dumped volume from this generation, use the FIXCDS command to recreate the P record, such that it refers to the generation.
*ERR 103 volser - NO INDICATION OF generation
For volume volser there is a BCDS eligible volume (P) record, but that record has no indication of generation generation, even though a dump generation (G) record exists for that generation.		If ERR 94 occurs for the volume mentioned in ERR 103, you should use the FIXCDS command to correct either the DGN record or the generation entry in the P record.
*ERR 104 dumpvol - NO DGN RECORD FOR generation
The dump volume record for dumpvol indicates that the volume is part of a copy in dump generation generation, but no dump generation (G) record exists for the generation.		If you also see an ERR 97 message referring to the volume, you should use the FIXCDS command to update the Y record for the volume to refer to the generation mentioned in the ERR 97 message. If you also see an *ERR 94 message referring to this generation, it will contain the volume serial number, which make up the first 6 bytes of the DGN record key.
*ERR 105 volser - NO P RECORD
For volume volser, there is no BCDS eligible volume (P) record.		The volume serial specified in the command may be spelled incorrectly.
*ERR 106 `cpname` - NO F (FRB) RECORD FOUND
There is no copy pool F FRB record for `cpname`.		If `cpname` is "NONE", there are no FRB records. This indicates that a fast replication backup was not created or failed. (That is, the FRBACKUP command has not been issued for the indicated copy pool or has failed.)
*ERR 110 volser - NO V OR X RECORD [DUMP]
For volume volser, there is no MCDS volume (V) record or BCDS backup volume (X) record. DUMP indicates that a dump volume (Y) record exists for volser.		The volume serial specified in the command may be spelled incorrectly. If not, and the volume is identified as a different type of DFSMShsm-owned or DFSMShsm-managed volume, you cannot use this AUDIT option on the volume. If the volume serial is not misspelled and you have evidence that the volume was once known to DFSMShsm, you need to check DFSMShsm logs to determine why the volume was deleted.
*ERR 111 volser - MISSING TTOC EXTENSION nnnn
Volume volser is missing one or more TTOC extensions (nnnn). (Gaps exist in the sequence of extension numbers.)	The missing TTOC extension is created.
*ERR 112 volser - EXTRANEOUS TTOC EXTENSION nnnn
For volume volser, TTOC extension nnnn is extraneous.	The extraneous TTOC extension is deleted.
*ERR 113 volser TTOC EXT. nnnn - NO {A\|D} RECORD FOR ttocdsn
In TTOC extension nnnn for volume volser, the data set entry for ttocdsn is flagged to indicate a valid copy, but one of the following conditions exists: No MCDS data set (D) record or MCDS alias entry (A) record exists for ttocdsn. An MCDS alias entry (A) record exists for ttocdsn but the MCDS data set (D) record referred to does not.	An MCDS data set (D) record is created for the TTOC entry. Note: If a (D) record was not created for data set ttocdsn, this tape begins with a partial data set. To have a (D) record properly created and built for this data set, you need to run AUDIT MEDIACONTROLS against the tape volume volser.
*ERR 114 volser - TTOC EXT. nnnn - ttocdsn HAS ‘A’ REC
In TTOC extension nnnn for volume volser, the data set entry for ttocdsn does not indicate a valid copy, but an MCDS alias entry (A) record exists for ttocdsn.	If there is no corresponding D record, the alias (A) record for the TTOC entry is deleted. If the corresponding D record is no longer valid and the catalog does not indicate the data set is migrated, the alias (A) record for the TTOC entry is deleted. If the corresponding D record is valid and indicates a migration copy at the current location, the TTOC entry is flagged valid.
*ERR 115 volser - TTOC EXT. nnnn - ttocdsn IS MIGRATION COPY
Volume volser with TTOC extension nnnn indicates that ttocdsn is a valid migration copy. The catalog indicates that the data set is migrated. The corresponding MCDS data set (D) record indicates a different migration volume from volume volser, but that volume (according to its TTOC, for a tape volume, or its VTOC, for a DASD volume) does not contain the migration copy.	The MCDS data set (D) record is updated to refer to this TTOC entry.
*ERR 116 volser - TTOC EXT. nnnn - ttocdsn HAS INVALID C RECORD
In TTOC extension nnnn for volume volser, the data set entry for ttocdsn does not indicate a valid copy, but a BCDS backup version (C) record exists for ttocdsn.
*ERR 116 volser - TTOC EXT. nnnn - ttocdsn HAS INVALID C RECORD (continued)
In TTOC extension nnnn for volume volser, the data set entry for ttocdsn is flagged as a valid copy, and a BCDS backup version (C) record exists for ttocdsn, but a corresponding BCDS data set record does not exist, or does not refer to that version.	All associated backup version records are deleted from DFSMShsm’s control dataset, and the TTOC entry is patched invalid.
*ERR 117 volser - TTOC EXT. nnnn - NO P RECORD FOR vtoccopy
*ERR 117 volser - TTOC EXT. nnnn - NO P RECORD FOR vcatcopy
For volume volser with TTOC extension nnnn, no BCDS eligible volume (P) record exists for VTOC copy data set vtoccopy or vcatcopy.		The data set is probably an obsolete VTOC (or VCAT) copy data set created when the volume indicated in the qualifier “.Vvolser” was backed up. Because no P record now exists for that volume, or if you need the backup, you should issue the BACKVOL command for the volume to create a backup and to regenerate the P record.
*ERR 118 volser - TTOC EXT. nnnn - vtoccopy NOT IN P RECORD FOR srcvol
*ERR 118 volser - TTOC EXT. nnnn - vcatcopy NOT IN P RECORD FOR srcvol
For volume volser, TTOC extension nnnn indicates a VTOC copy (vtoccopy) or a VCAT copy (vcatcopy), but vtoccopy or vcatcopy is not referred to in the corresponding BCDS eligible volume (P) record for srcvol.	The current TTOC entry is patched invalid.
*ERR 119 volser - NO PREDECESSOR TTOC FOR prevol
The TTOC for volume volser indicates that the first data set (migration copy or backup version) on the tape volume is continued (spans) from volume prevol. However, no corresponding (migration or backup) TTOC base record exists for tape volume prevol.
*ERR 120 volser - NOT A SUCCESSOR FROM TTOC FOR prevol
The TTOC for volume volser indicates that the first data set (migration copy or backup version) on the tape volume is continued (spans) from volume prevol. The TTOC, however, for prevol does not indicate volume volser as a successor.
*ERR 121 volser - ttocdsn NOT SPANNED FROM TTOC FOR prevol
The TTOC for volume volser indicates that the first data set (ttocdsn) on the tape volume is continued (spans) from the volume prevol, and the TTOC for prevol indicates volser as a successor volume; but the last TTOC entry for volume prevol has a different data set name from the first TTOC entry for the current volume volser.
*ERR 122 volser - NO SUCCESSOR TTOC FOR sucvol
The TTOC for volume volser indicates that the last data set on the tape volume continues on (spans to) volume sucvol. There is, however, no corresponding (migration or backup) TTOC base record for tape volume sucvol.
*ERR 123 volser - NOT A PREDECESSOR TO TTOC FOR sucvol
The TTOC for volume volser indicates that the last data set (migration copy or backup version) on the tape volume continues on (spans to) volume sucvol. The TTOC, however, for sucvol does not indicate volume volser as a predecessor.
*ERR 124 volser - ttocdsn NOT SPANNED TO TTOC FOR sucvol
The TTOC for volume volser indicates that the last data set (ttocdsn) on the tape volume continues on (spans to) volume sucvol. A TTOC record set exists for volume sucvol, and it indicates volser as a predecessor volume; but the first TTOC entry for volume sucvol has a different data set name from the last TTOC entry for the current volume volser.
*ERR 125 volser1 SPANS {TO \| FROM} volser2, BUT ttcdsn THAT SPANNED IS NO LONGER VALID
volser1 is the volume being audited. If TO is the insert, volser2 is the successor volume and the last data set (ttcdsn) on volser1 continues on (spans to) volser2. If FROM is the insert, volser2 is the predecessor volume and the first data set on volser1 spans from volser2. The TTOC for volser1 indicates that volser2 is also needed for ttcdsn, but this is incorrect since ttcdsn is no longer valid.	If a TTOC exists for volser2 and it indicates a data set spans to or from volser1 and the spanning data set names are the same on both TTOCs, the TTOC for volser2 is corrected by patching the appropriate field, TTCSUCVL or TTCPREVL, to blanks. The TTOC for volser1 is corrected by patching the appropriate field, TTCSUCVL or TTCPREVL, to blanks.
*ERR 130 volser - NOT SINGLE-FILE-FORMAT 3480 TAPE VOLUME
For volume volser, either a MCDS volume record or a BCDS backup volume record exists, but does not indicate a cartridge type tape written in single-file format.		The MEDIACONTROLS option cannot be used with this volume, because the volume is not written in single-file format.
*ERR 131 volser - CANNOT BE MOUNTED.
For volume volser, either a MCDS volume record or a BCDS backup volume record exists, but the volume cannot be allocated or mounted.		The volume cannot be mounted, or the operator has chosen not to mount the tape volume. Determine that the volume is accessible to your operator before reissuing this AUDIT command for this volume.
*ERR 132 volser - userdsn NO LONGER MIGRATED
A migration copy of userdsn exists on migration volume volser, but no catalog entry exists for userdsn, or the catalog indicates that userdsn is on a level-0 volume.	If there is no MCDS data set (D) record and the current TTOC entry is flagged valid, the TTOC entry is patched invalid, and an existing alias (A) record is deleted; If a data set (D) record refers to the current copy on this tape, the TTOC entry is patched valid until the problem can be resolved; If the D record refers to another copy and the current TTOC entry is flagged valid, the TTOC entry is patched invalid.
*ERR 133 volser - userdsn (MIGRATED) NEEDS VALID D RECORD
For volume volser, the catalog indicates that user data set name userdsn is migrated (volser is MIGRAT), but the MCDS data set (D) record either does not exist or is not flagged as valid.	The current TTOC entry is patched valid. A valid MCDS data set (D) record and (if needed) an alias (A) record are created.	If the data set in question is a VSAM component, see ERR 169 for additional diagnostic data and handling. If Audit rebuilt the MCD record for a VSAM data set and used the data component name for the key, further action is required to change the key to the cluster name. See ERR 169 for details and instructions.
*ERR 134 volser - CANNOT IDENTIFY ANY DFSMShsm DATA SET
The MCDS volume (V) record indicates that volume volser is a migration volume, but there is no common data set descriptor (CDD) record found on the tape, thus no DFSMShsm migration copy or backup version can be identified.	The first data set TTOC entry is patched invalid.
*ERR 135 volser - TTOC ENTRY FOR ttocdsn - BLOCK COUNT SHOULD BE nnnn
In volume volser, the block count indicated for TTOC entry ttocdsn does not agree with the actual block count. The TTOC block count should be nnnn.	The TTOC entry is patched with the correct block count.
*ERR 136 volser - TTOC ENTRY FOR ttocdsn - SHOULD BE VALID
For volume volser, both the MCDS data set (D) record and the catalog indicate that the TTOC entry for ttocdsn should be flagged as valid, but it is flagged as invalid.	The TTOC entry is patched valid, and (if needed) an alias (A) record is created.
*ERR 137 volser - TTOC BASE NEEDS VALID-BLOCK COUNT nnnn
For volume volser, a block count discrepancy exists between the number of blocks of valid data and the count of valid blocks in the TTOC base record. The TTOC base record needs to be updated with the valid block count of nnnn.	The base TTOC is patched with the valid block count.
*ERR 138 volser - TTOC BASE NEEDS TOTAL-BLOCK COUNT nnnn
For volume volser, a block count discrepancy exists between the number of blocks of data and the count of blocks in the TTOC base record. The TTOC base record needs to be updated with the block count of nnnn.	The base TTOC is patched with the total block count.
*ERR 140 migvol - userdsn HAS NO ALIAS RECORD
*ERR 140 migvol - cdddsn HAS NO ALIAS RECORD
For migration volume migvol, no MCDS alias entry (A) record exists for one of the following conditions: Data set name userdsn in the VTOC has the form of a DFSMShsm-generated migration copy name. Data set name cdddsn, in what appears to be a common data set descriptor (CDD) record, indicates a migration copy. (The catalog entry for cdddsn indicates volume serial MIGRAT; an MCDS data set (D) record for cdddsn refers to an alias (A) record for the migration copy.)	An alias (A) record is created, referring to this migration copy.
*ERR 141 migvol - SCRATCHED EMPTY DATA SET {migdsn\|version}
For migration volume migvol, migration copy migdsn or backup version version is empty.	The empty data set is scratched and uncataloged.
*ERR 142 migvol - version HAS NO C RECORD
For migration volume migvol, one of the following conditions exists for the data set named version in the VTOC: The name has the form of a DFSMShsm-generated backup version name, but no corresponding BCDS backup version (C) record exists. The first record of data set version appears to be a common data set descriptor (CDD) record, but the index of versions in the B record does not refer to version.	The data set is scratched.
*ERR 143 migvol - NO P RECORD FOR srcvol OF vtoccopy
*ERR 143 migvol - NO P RECORD FOR srcvol OF vcatcopy
Migration volume migvol contains either the VTOC copy vtoccopy or the VCAT copy vcatcopy made during a backup of volume srcvol. However, no BCDS eligible volume (P) record exists for source volume srcvol.	The copy data set is scratched and uncataloged.
*ERR 144 migvol - vtoccopy NOT IN P RECORD FOR srcvol
*ERR 144 migvol - vcatcopy NOT IN P RECORD FOR srcvol
Migration volume migvol contains either the VTOC copy vtoccopy or the VCAT copy vcatcopy made during a backup of volume srcvol. The BCDS eligible volume (P) record does not refer to either vtoccopy or vcatcopy.	The copy data set is scratched and uncataloged.
*ERR 145 migvol - NO P RECORD FOR srcvol OF dumpvtoccopy
Migration volume migvol contains the dump VTOC copy dumpvtoccopy made during a volume dump of srcvol. However, no BCDS eligible volume (P) record exists for source volume srcvol.	The copy data set is scratched and uncataloged.
*ERR 146 migvol - dumpvtoccopy NOT IN ANY DGN RECORD FOR srcvol
Migration volume migvol contains the dump VTOC copy dumpvtoccopy made during a volume dump of srcvol. However, no dump generation record (DGN) exists that refers to dumpvtoccopy.	The copy data set is scratched and uncataloged.
*ERR 147 migvol - userdsn NEEDS D RECORD
User data set userdsn is on migration volume migvol. The catalog indicates that this data set is migrated. The MCDS data set (D) record for userdsn is either missing or indicates some other migration volume, but the VTOC or TTOC for that other migration volume does not refer to userdsn. The userdsn is not recognized as a DFSMShsm-generated name.	The D record is created, or patched, to refer to the copy on the migration volume being audited.
*ERR 148 migvol - userdsn MAY BE OLD MIGRATION COPY
An MCD record was found for the migrated data set on the volume, or in the SDSP data set being processed. The catalog indicates that this data set is migrated. A discrepancy was found between the MCD record and the volume being audited.		For AUDIT MEDIACONTROLS(SDSP) VOLUME(volser): If the MCD record indicates this data set is on tape, the AUDIT output will recommend AUDIT MEDIACONTROLS VOLUME(tapevolser). If the data set is determined to be properly migrated to tape and you want the SDSP entry removed to prevent further ERR148s, then Recall the migrated copy from the tape volume. Create an MCD record for the data set in the SDSP as follows: `FIXCDS D userdsn ADDMIG(sdspvol)` Note: If the MCD create fails due to an already existing MCD record, delete the existing MCD record and create a new MCD record for the SDSP data set as suggested. The command to delete the MCD record is: `FIXCDS D userdsn DELETE` Delete the MCD entry from the MCDS and remove the entry from the SDSP by issuing the following command: `HSEND DELETE userdsn` The MCD record indicates it is not in an SDSP data set, and the issuance of an OBTAIN for the data set on the volume indicated in the MCD record resulted in “volume not mounted”. The MCD record indicates an SDSP data set, but the volume indicated in the MCD record does not match the volume being audited. The volume indicated in the MCD record cannot be checked because we could not allocate the SDSP data set on that volume, or the volume was not mounted.
*ERR 148 migvol - userdsn MAY BE OLD MIGRATION COPY (continued)
An MCD record was found for the migrated data set on the volume, or in the SDSP data set being processed. The catalog indicates that this data set is migrated. A discrepancy was found between the MCD record and the volume being audited.		For AUDIT DIRECTORYCONTROLS VOLUMES(dasdvol), the MCD record indicates the migration copy was created before HSM Release 3, and The MCD record indicates the data set is in an SDSP data set. However, AUDIT found the migrated data set on the DASD volume being audited. AUDIT will recommend running AUDIT MEDIACONTROLS(SDSP) VOLUMES(sdspvol) to assist in diagnosing the error. The MCD record says it is on a DASD volume other than the one currently being audited. AUDIT tried to OBTAIN the data set from that other volume, but the volume was not mounted. AUDIT will recommend AUDIT MEDIACONTROLS VOLUMES(volser) of the volume indicated in the MCD record.
*ERR 149 migvol - migdsn IS OLD MIGRATION COPY
User data set migdsn is on migration volume migvol. The catalog indicates that migdsn is migrated. The MCDS data set (D) record for migdsn refers to a migration copy on a different volume. The VTOC or TTOC for that other migration volume indicates that a migration copy of migdsn does exist on that volume. The migdsn is not recognized as a DFSMShsm-generated name.	The data set is scratched. If an alias (A) record exists, it is deleted.
*ERR 150 migvol - version HAS NO CDD RECORD
On migration volume migvol, the first record in (what appears to be, by its name) migration copy migdsn or in (what appears to be, by its name) backup version version, cannot be identified as a common data set descriptor (CDD) record.		The data set, if named like a DFSMShsm backup version, may nevertheless not be a DFSMShsm data set. If it is not, and because the data set is on a migration volume, not a backup volume, there should be no problem. If the data set is a backup version, it is not possible to recover it without a CDD as the first record, and there is no point in having DFSMShsm move the version to a backup volume. If no C record exists, the version can be scratched from the volume. If a C record exists for the version, issue the BDELETE command to delete the version.
*ERR 151 migvol - cdddsn NOT CATALOGED, HAS COPY migdsn
On migration volume migvol, the first record in (what appears to be, by its name) migration copy migdsn appears to be a common data set descriptor (CDD) record created from data set cdddsn. There is, however, no catalog entry for cdddsn.	The MCDS data set (D) record is patched as invalid, and patched to indicate that the migration copy is to be scratched. The record will automatically be cleaned up the next time DFSMShsm migration runs (secondary space management processing).
*ERR 152 migvol - cdddsn NOT MIGRATED, HAS COPY migdsn
On migration volume migvol, the first record in (what appears to be, by its name) migration copy migdsn appears to be a Common Data set Descriptor (CDD) record created from data set cdddsn. The catalog entry, however, for cdddsn indicates that the data set is not migrated.	The MCDS data set (D) record is patched as invalid, and patched to indicate that the migration copy is to be scratched. The record will automatically be cleaned up the next time DFSMShsm migration runs (secondary space management processing).
*ERR 160 migvol - DOES NOT HAVE SDSP DATA SET
For migration volume migvol, no SDSP data set listed in the VTOC exists. The name of such a data set must be uid.SMALLDS.Vmigvol, where uid is the authorized userid for the current startup of DFSMShsm.		The volume serial specified in the command may be spelled incorrectly. If not, your installation may have changed the UID value in the DFSMShsm startup procedure since the SDSP data set on the volume was created. You may need to rename the data set, changing the first qualifier to the current UID value.
*ERR 161 migvol - userdsn NOT CATALOGED, HAS {VALID \| INVALID} COPY IN SDSP
The small data set packing (SDSP) data set on migration volume migvol contains a migration copy of userdsn, but that data set is not cataloged. The message text indicates whether the data set appears to be valid or invalid.	If there is no data set (D) record, and no catalog entry, the migration copy is deleted (internally) from the SDSP. If there is a D record, but no catalog entry, and the copy has gaps in its records, the migration copy is deleted (internally) from the SDSP, and the D record is patched invalid. If the D record identifies the migration copy as valid (that is, recalled) and the data set is not cataloged, and the D record does not indicate that the migration copy needs to be scratched, a FIXCDS PATCH command is generated by AUDIT to turn on the “needs scratch” indicator.	If there is a D record, but no catalog entry, and the D record appears to represent a valid migration copy, you should determine one of the following: If the data set is invalid and you want it deleted, you should issue an HSEND DELETE command, to have associated records deleted and have the data set removed from the SDSP. Following is an example of the HSEND DELETE command: `HSEND DELETE userdsn` If the data set is valid, you should catalog it to a volume serial of ‘MIGRAT’.
*ERR 162 migvol - userdsn NOT MIGRATED, HAS COPY IN SDSP
The small data set packing (SDSP) data set on migration volume migvol contains a migration copy of userdsn, but the catalog entry for that data set indicates that the data set is not migrated.	If there is no data set (D) record, the migration copy is deleted (internally) from the SDSP. If there is a D record, but the catalog does not indicate MIGRAT, and the copy has gaps in its records, the migration copy is deleted (internally) from the SDSP, and the D record is patched invalid. If there is a D record, but the catalog does not indicate MIGRAT, and there are no record gaps in the copy, and the D record is flagged other than “invalid, needs scratch,” the D record is patched as invalid, and patched to indicate that the migration copy be scratched.
*ERR 163 migvol - userdsn MISSING ONE OR MORE RECORDS IN SDSP
The small data set packing (SDSP) data set on migration volume migvol contains a migration copy of userdsn, but the migration copy is missing one or more records.		If the data set is no longer needed, you can issue a DELETE command for the data set. If you can recall the data set successfully, then the record gap is not significant. If the data set cannot be recalled successfully, but a backup copy exists, then delete the data set (to remove the catalog entry and D record), and issue the RECOVER command for the data set.
*ERR 164 TTOC FOR VOLUME volser INDICATES IN-STORAGE RECORDS EXIST
The TTOC for the tape volume indicates that in storage records existed that may not have been written to the OCDS on DASD. After this AUDIT has completed, all data sets on the tape will have entries in the existing TTOC record for this volume.	The TTCFAIST bit in the base TTOC is patched off.
*ERR 165 NO DATA FILES ARE INDICATED FOR ABR RECORD KEY = abrrecordkey
The ABR record with key abrrecordkey indicates that neither a DFSMSdss data file nor an internal data file is included with the aggregate backup.		The ABR record specified is invalid and should be deleted.
*ERR 166 ABARSCONTROLS SPECIFIED USING AGGREGATE GROUP = aggroupname. A MATCHING AGGREGATE GROUP NAME COULD NOT BE FOUND IN THE BCDS.
The aggregate group name specified with the AUDIT command has no ABR records (has not been backed up).		Aggregate group name agname was probably spelled incorrectly.
*ERR 167 ABARSCONTROLS SPECIFIED, BUT NO ABR RECORDS WERE FOUND IN THE BCDS.
The BCDS has no record of aggregate backup activity.		No ABR records exist, therefore no aggregate backups have successfully completed.
*ERR 168 [CONTROL \| DFSMSdss DATA \| INTERNAL DATA \| INSTRUCTION/ACTIVITY LOG] FILE NAME = filename, INDICATED IN THE ABR RECORD, BUT IS NOT CATALOGED. ABR RECORD KEY = abrrecordkey
The aggregate group backup refers to a particular file, but the file cannot be found in the catalog.		You should catalog the file indicated by filename.
*ERR 169 MCD RECORD CREATED FOR VSAM DATA SET dsname NEEDS NEW KEY
In diagnosing error 133 for a migrated VSAM data set, AUDIT cannot determine its base cluster name and has used data component name dsname to recreate the MCDS data set record.		You need to determine the base cluster name of the VSAM data set, and issue a FIXCDS command to change the key of the MCD record: `FIXCDS D dsname NEWKEY(base cluster_name)` Then, if AUDIT re-created an alias (A) record, you can either recall and remigrate the VSAM data set; or issue a FIXCDS command to patch the alias record: where generated_name can be found in the AUDIT output that created the alias record, or at offset X'9C' (field MCDMCANM) in the MCD record. `FIXCDS A generated_name PATCH(X'4'base cluster_name)`
ERR 170 SPECIFIED COPY POOL cpname* DOES NOT EXIST
*ERR 171 F RECORD INDICATES x {DUMP \| TOTAL \| DASD \| SMS SPECIFIED} VERSIONS, ONLY y VERSIONS WERE FOUND
Number of (FRD) Dump Version records found is not equal to the number of dumped versions indicated in the (FRB) copy pool record.		If DUMP, the number of (FRD) Dump Version records found is not equal to the number of dumped versions indicated in the (FRB) copy pool record. If TOTAL, the number of versions found is not equal to the number of versions indicated in the FRB record. If DASD, the number of all DASD versions found is not equal to the number indicated in the FRB record. If SMS SPECIFIED, the number of non-rolloff versions found is not equal to the number indicated in the FRB record.
*ERR 172 H RECORD INDICATES x DASD VERSIONS, ONLY y VERSIONS WERE FOUND
ERR 173 COPY POOL cpname* F RECORD INDICATES x H RECORDS FOR VERSION z, ONLY y RECORDS WERE FOUND
(FRB) Copy pool record field and the number of (FRVP) volume pair records found do not match.		This error may be resolved by other audit discoveries. Some audit actions delete FRVP records which may result in these counts be correct.
ERR 174 COPY POOL cpname* F RECORD WAS NOT FOUND, ORPHANED H RECORDS EXIST
A volume pair record has been found, but the copy pool record to which it belongs does not exist.	The volume pair record is deleted. Note: Repair actions are only performed when FIX is specified on the audit command.	Error only found when no cpname was specified on the AUDIT COPYPOOLCONTROLS command.
*ERR 175 H (FRVP) RECORD INDICATES IT IS A 'PREPARE' RECORD, THE CORRESPONDING F (FRB) RECORD DOES NOT
		You need to determine which indicator is correct. Use the FIXCDS PATCH command to correct the problem. You can use the LIST COPYPOOL command to help you determine which indicator is correct. Either the 'Prepare' flag should be on in the F (FRB) record or the FRVP records are orphan entries and should be deleted using the FIXCDS DELETE command.
**ERR 176 H RECORD FOR VERSION x EXISTS, BUT VERSION CANNOT BE FOUND IN CORRESPONDING F RECORD FOR COPY POOL cpname***
The copy pool record for this volume pair record does not contain a corresponding version entry.	The volume pair record is deleted. Note: Repair actions are only performed when FIX is specified on the audit command.	This volume pair record is not needed. This error is only detected when no cpname is specified on the AUDIT COPYPOOLCONTROLS command.
ERR 177 I (FRTV) RECORD WAS EXPECTED FOR VOLUME volser* AND WAS NOT FOUND
A F (FRB) record indicates this is a valid version. The volume represented by this FRTV record needs to be made available and an FRTV record should be created to represent it or the fast replication backup of this copy pool will fail.		The FIXCDS CREATE command can be used to recreate the FRTV record.
ERR 178 I (FRTV) RECORD FOR TARGET VOLUME targetvolser, EXPECTS FRSV (J) RECORD FOR SOURCE VOLUME sourcevolser*, WHICH WAS NOT FOUND
		AUDIT has detected that the FRSV (J) record for source volume sourcevolser does not exist. This record should exist unless this version is a PREPARED version. Note: The ERR178 may be incorrectly issued when the copy pool name is not specified on the AUDIT command. Use the LIST COPYPOOL(cpname) ALLVOLS(ALLVERS) command to identify which copy pool these target volumes belong to. Then reissue the AUDIT COPYPOOLCONTROLS(cpname) command, specifying the copy pool name the sourcevolser and targetvolser belong to. If the ERR178 message is persistent, record errors exist.
*ERR 179 `cpname` VERSION `versionnumber`, H RECORD HAS WRONG TARGET VOLUME `targetvolser`, OR I RECORD HAS WRONG SOURCE VOLUME `sourcevolser`
		Determine which record is incorrect and correct the record using the FIXCDS PATCH command. Then use the FRDELETE command to delete the copy pool version (`cpname`) identified in the message. Example: `FRDELETE COPYPOOL(cpname) ALL BOTH`
**ERR 180 J RECORD NOT FOUND FOR VOLUME volser, IT BELONGS TO COPY POOL cpname, VER= vernum***
A volume pairs record was found indicating source volume volser, but the source volume record does not exist.		This error will be issued if the source volume has been removed from the copy pool, and a successful FRBACKUP has taken place since its removal.
**ERR 181 F (FRB) RECORD FOR cpname* NOT FOUND, POSSIBLY ORPHANED J (FRSV) RECORD FOR VOLUME volser**
		Remove cpname from the FRSV cpname array. If there are no cpnames left in the array, delete the FRSV record for VOLUME volser.
ERR 182 NO P (MCP) RECORD FOUND FOR VOLUME volser*, IS THIS AN ERROR?
ERR 183 VOLUME volser* FROM THE J (FRSV) RECORD L0 FIELD COULD NOT BE FOUND IN A CORRESPONDING H (FRVP) RECORD
		H (FRVP) record was not found or volser was not found in the corresponding H (FRVP) records.
**ERR 184 ORPHANED J RECORD DETECTED FOR VOLUME srcvol***
No cpname copy pool record (FRB) was found for any copypool this source volume belongs to. A source volume can belong to many copy pools.	The FRSV source volume record is deleted. Note: Repair actions are only performed when FIX is specified on the audit command.	Previously issued ERR181 message(s) may be help to identify the copy pool name this record was known to have belonged to. This error is only detected when no cpname is specified on the AUDIT COPYPOOLCONTROLS command.
**ERR 185 COPY POOL cpname* COULD NOT BE FOUND IN THE J (FRSV) RECORD COPY POOL ARRAY FOR VOLUME volser**
		You need to use the FIXCDS PATCH command to patch the FRSV record with the cpname, or if the FRSV record contains no other copy pool names, deleted it with the FIXCDS DELETE command.
ERR 186 ORPHANED K RECORD FOUND, COPY POOL cpname* NO LONGER EXISTS
The copy pool record for this copy pool dump record does not exist. This record is no longer needed.	The FRD copy pool dump record is deleted. Note: Repair actions are only performed when FIX is specified on the audit command.	This error is only detected when no cpname is specified on the AUDIT COPYPOOLCONTROLS command.
ERR 187 K RECORD EXISTS, COPY POOL cpname* F RECORD INDICATES NO DUMP COPY
The FRB copy pool record indicates there is no dump copy for this copy pool version. An FRD copy pool dump version record exists for this version.	The corresponding version entry in the FRB copy pool record is patched to indicate the dump version exists. Note: Repair actions are only performed when FIX is specified on the audit command.	This error is only detected when no cpname is specified on the AUDIT COPYPOOLCONTROLS command.
ERR 188 K (FRD) RECORD NOT FOUND, F (FRB) RECORD FOR COPY POOL cpname* INDICATES THAT IT DOES EXIST
The FRB record indicates a dump for this copy pool exists, but te record representing the dump cannot be found.
**ERR 189 H (FRVP) RECORD NOT FOUND COPY POOL cpname***
During the AUDIT VOLUMECONTROLS (RECOVERABLE), an error was detected.		You should consider running AUDIT COPYPOOLCONTROLS (cpname) to learn more regarding this discrepancy.
**ERR 190 VOLUME volser* COULD NOT BE FOUND IN ANY ASSOCIATED H (FRVP) RECORD FOR COPY POOL cpname**
		You should consider running AUDIT COPYPOOLCONTROLS (cpname) to learn more regarding this discrepancy.
ERR 191 P RECORD FOUND FOR VOLUME volser*, IS NOT INDICATED AS A COPY POOL VOLUME
ERR 192 F RECORD FOUND FOR COPYPOOL cpname, WHICH VOLUME volser* BELONGS TO
If detected during AUDIT VOLCTL(RECOVERABLE), this is detected and flagged so that you can confirm that the source volume described is recoverable.	If detected during AUDIT VOLCTL(RECOVERABLE) FIX, the fix is to build the proper AUDIT COPYPOOLCONTROLS command and execute to confirm that the volume referenced is in a recoverable state. AUDIT does not issue any patch commands to correct any records. Its intent is to allow you the opportunity to confirm that this volume is a valid recoverable volume.	Audit the specified copy pool to determine the recoverability of this volume.
**ERR 193 J RECORD NOT FOUND FOR VOLUME volser***
		The MCP or DGN record for volume volser indicates that an FRSV record should exist for this volume. Expect this error to be issued for each dumped version of this volume. The MCPF_COPYPOOL bit should be patched off if it is determined that this is no longer a copypool volume, as is indicated by the missing FRSV record. FIXCDS P volser PATCH(X'9' BITS(.......0))
ERR 194 CATALOG INFORMATION DATA SET dsname* FOR COPY POOL cpname, VERSION version WAS NOT FOUND
The copy pool record indicates that the catalog information was captured but a data set containing this information was not found by AUDIT.		Remove the indication of catalog information from the FRB and reset the number sequence field to zero.
ERR 195 COPY POOL cpname, VERSION version, INDICATES CATALOG INFORMATION DATA SET dsname* BUT THE DATA SET CORRESPONDS TO A DIFFERENT COPY POOL VERSION
The copy pool record indicates that the catalog information was captured but the corresponding catalog information data set indicates that it contains catalog information for a different copy pool backup version.		Run AUDIT DIRECTORYCONTROLS against the ML1 volume where the catalog information data set resides. If necessary, remove the indication of catalog information from the FRB and reset the number sequence field.
ERR 196 CATALOG INFORMATION DATA SET dsname*, IS NOT CATALOGED
The catalog information data set was found on an ML1 volume but the data set is not cataloged.		Catalog the data set.
ERR 197 CATALOG INFORMATION DATA SET dsn* INDICATES COPY POOL cpname BUT A CORRESPONDING BACKUP WAS NOT FOUND
There is no corresponding Fast Replication backup version for the catalog information data set.		Determine if the catalog information data set corresponds to a valid fast replication backup version. If it does, patch the FRB record for the fast replication backup version to indicate that the catalog information data set exists. If it does not, delete the catalog information data set.
ERR 198 CATALOG INFORMATION DATA SET dsname, CORRESPONDS TO COPY POOL cpname* , VERSION version BUT THE COPY POOL BACKUP VERSION DOES NOT INDICATE CATALOG INFORMATION WAS CAPTURED
The copy pool backup version specified by the catalog information data set indicates that the catalog information was not captured. This catalog information data set does not correspond to a valid existing copy pool backup version.		Delete the catalog information data set.
ERR 199 CATALOG INFORMATION DATA SET dsname, CORRESPONDS TO COPY POOL cpname* , VERSION version BUT THE COPY POOL BACKUP VERSION INDICATES A DIFFERENT CATALOG INFORMATION DATA SET
The copy pool version that the catalog information data set indicates that it is associated to is not the catalog information data set that the copy pool version record indicates.		Update the entry within the FRB record which corresponds to this copy pool backup version to indicate that the catalog information is available and to reflect the correct number sequence of the data set.
**ERR 200 ERROR ENCOUNTERED WHEN PROCESSING CATALOG INFORMATION DATA SET dsn* , FOR COPY POOL cpname VERSION vers**
There was an unexpected error while trying to process the catalog information data set. This message should be preceded by an ARC1812I message.		Refer to the ARC1812I message.
ERR 201 CATALOG INFORMATION DATA SET dsn*, IS CATALOGED TO A DIFFERENT VOLUME
The catalog locate for the catalog information data set indicates that this data set is cataloged on a different volume.		Determine if the catalog is inaccurate or if this is a duplicate uncataloged version of the catalog information data set. Scratch the uncataloged copy if appropriate. If the uncataloged copy is valid, determine if the cataloged copy should be deleted and the uncataloged copy should be cataloged.
*ERR 202 ORPHAN I (FRTV) RECORD FOUND FOR TARGET VOLUME `tgtvol`, SOURCE VOLUME `srcvol`
The source volume record was not found for this target volume record and the target volume record was not validated by the volume pair record validation process. This record is no longer needed.	The target volume record is deleted. Note: Repair actions are only performed when FIX is specified on the audit command.	This error is only detected when no cpname is specified on the AUDIT COPYPOOLCONTROLS command.
**ERR 203 VALID MCD FOR DATA SET `dsn` HAS INCORRECT VOLSER, SHOULD BE VOL= volser***
During AUDIT MEDIACONTROLS, both a valid CDD record and corresponding valid MCD record have been identified. The MCD record does not indicate that it is for the tape volume being audited. Since the file block id and the timestamp in these two records are identical, this MCD record must belong to this migrated data set.	The migrated data set record (D) is patched with the volser of the tape that is being audited.
*ERR 204 I (FRTV) RECORD FOR VOLUME `targetvolser` HAS MULTIPLE H (FRVP) RECORD ENTRY REFERENCES
Multiple FRVP record entry references were found for the target volume `tgtvolser`. A target volume can have a single valid FRVP record entry reference only. The target volume is "overused."		*ERR 179 messages are issue to assist determining the copy pools and versions that are using the target volume. The existing copy pool backups identified during auditing are not reliable backups and should be deleted using the FRDELETE command. You should then issue the FRBACKUP command to create a valid backup of each copy pool.
ERR 205 K RECORD EXISTS, COPY POOL cpname* F RECORD DOES NOT HAVE THIS VERSION
A dump version record was found that has no version entry in the associated FRB record for the copy pool.	The copy pool dump version record is deleted. Note: Repair actions are only performed when FIX is specified on the audit command.	This error is only detected when no cpname is specified on the AUDIT COPYPOOLCONTROLS command.