Limitation of 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. (

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. (

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:

  1. The process increases the count for that label pair or that member by 1.

  2. 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.

  3. The error record is printed if you specified PRINT(*ERROR).

  4. Copying continues.

  5. 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.

  6. 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:

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

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

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.

 

Parent topic:

Preventing errors when copying files