Limit recoverable errors during copy

When you copy to or from a database file or from a tape file, you can limit the number of recoverable errors that you accept before the copy ends. Use the ERRLVL parameter to specify this limit.

This parameter applies to the following types of errors:

CPF4826: Media error
CPF5026: Duplicate key in the access path of this member. (Note: The copy command does not count CPF5026 as an ERRLVL error when you specify MBROPT(*UPDADD) on CPYF.)
CPF5027: Record in use by another job. (Note: The copy command only counts CPF5027 as an ERRLVL error when you specify MBROPT(*UPDADD) on CPYF.)
CPF5029: Data or key conversion error
CPF502D: Referential integrity constraint violation
CPF502E: Referential integrity constraints cannot be validated
CPF5030: Partial damage on member
CPF5034: Duplicate key in the access path of another member
CPF5036: Invalid length tape block read
CPF504B: DataLink error
CPF504C: DataLink preparation error
CPF5097: *NAN (Not a Number) value not allowed in floating-point key field

The ERRLVL parameter specifies the maximum number of recoverable errors allowed for each label pair or each member copied. The value specified for ERRLVL indicates the total errors that are allowed on both the from-file and the to-file that are combined for each label pair or each member copied. Each time an error occurs, the following process runs:

The process increases the count for that label pair or that member by 1.
A message identifying the last good record that is read or written is printed on all copy lists if TOFILE(*PRINT), PRINT(*COPIED), or PRINT(*EXCLD) was specified.
The error record is printed if you specified PRINT(*ERROR).
Copying continues.
If the copy command completely copies the from-file member without exceeding the limit, the process resets the counter to 0, and the copy of the next member starts.
If the limit is exceeded during the copy of a member, copying ends and a message is sent, even if more records or members remain to be copied.

For a database from-file, including the open query file, the recoverable errors are:

those that occur when data is converted (mapped) AND
those caused by a damaged area on the disk (in auxiliary storage)

For a tape from-file, the recoverable errors are:

a block length that is not valid AND
a media-read operation from the tape volume on the device resulting in an error

For a physical to-file, the recoverable errors are:

those that occur when data is converted AND
those that occur when more than one of the same key is found

Any record that causes an error is not copied to the to-file. For a write error, the record is printed on a PRINT(*COPIED) and PRINT(*EXCLD) printout. A message then follows this printout. This message indicates that the record was not actually copied. If you specified PRINT(*ERROR), the command prints the records that caused write errors on the *ERROR listing. A message then indicates that an error occurred. For a read error, no record is available to be printed on the copy printouts (TOFILE(*PRINT), PRINT(*COPIED), PRINT(*EXCLD), or PRINT(*ERROR)). However, a message prints on all specified printouts that indicates that a record cannot be read.

When the command cannot read a portion of the file from disk, partial object damage to the contents of a database file occurs. If a file is damaged in such a way, you can bypass the records that are in error by copying the good records and manually adding the records that were not copied because of the damage.

Regardless of the value of the ERRLVL parameter, recoverable errors always appear in the job log with a reply of "C" for "Cancel."

For files that have constraint relationships, the ERRLVL parameter only affects the to-file. If you set the ERRLVL parameter to 0, the copy command does not copy into the file any record that causes the to-file to violate the constraint relationship. The copy operation ends. If ERRLVL is greater than 0, the copy command does not copy into the file any record that causes the to-file to violate the constraint relationship. However, the copy operation continues until enough violations (recoverable errors) have occurred so that the ERRLVL value has been reached. If this value is exceeded, the copy operation ends.

You can use the ERRLVL parameter to bring files with constraint relationships in check pending status back into non-check pending status. Do this by setting up the dependent to-file with constraints that are the same as the dependent from-file. Then, use a CPYF command with the ERRLVL(*NOMAX) to copy all valid records. The to-file should not contain any records. The copy command does not insert into the to-file any records that it encounters from the from-file that would cause the to-file constraints to go to check pending status. With ERRLVL set to *NOMAX, the copy command processes all records in the from-file.

Other copy commands (CPYSRCF, CPYFRMTAP, andCPYTOTAP) end immediately if the systems signals one of the recoverable errors because there is no ERRLVL parameter for them.