Re: CPF2958/CPF2959

[CRPence <CRPbottle@xxxxxxxxx>]

  CPYF error recovery was designed to be iterative using the ERRLVL(0) 
and FROMRCD(1) on the first invocation, and FROMRCD(error-record+1) [or 
FROMRCD(error-record) after data correction] on each successive 
invocation.  Does the ERRLVL() not work, or perhaps the use of the 
parameter specification ERRLVL(*NOMAX) forced overriding that design intent?

  FWiW I recall there was a specific limit for the number of conditions 
diagnosed [though I did not recall the number ten as noted in the 
CPF2958] as a means to prevent filling a job message queue and thus 
effecting either job termination or wrapping; i.e. if there were some 
number of like-errors, they were likely to be repeated many times over, 
a pervasive issue such as the TOFILE was likely created poorly and for 
that the CPYF would need to be performed again anyhow.

Regards, Chuck

On 2/10/11 8:14 AM, sjl wrote:
> We are using CPYF with FMTOPT(*MAP) to convert data from a given
> CCSID to Unicode by copying the data from the file with a given
> CCSID to a new file with corresponding fields that are defined as
> CCSID(1208).
>
> CPYF issues CPF2958 (Conversion error occurred copying from-file
> field value) when it encounters a data error - not terminal error,
> it just puts a default value (blanks) into the to-file field.
>
> In the particular example that I am looking at, the from-file is
> CCSID(939) {double-byte Japanese} and the data in field which causes
> the error has one shift-out X'0E' but there is an extra shift-in
> character X'0F' at the end of the field - probably a record that was
> converted from the old system but has never been touched by the
> interactive file maintenance program.
>
> However, only the first 10 records with conversion errors cause
> CPF2958 to be issued - CPF2959 is also issued, which indicates that
> field conversion errors occurred, but that only the first 10 records
> with errors are listed. In this case there were over 250 records with
> conversion errors.
>
> In any case, it appears that we need to write a program to
> analyse/cleanse the data in the from-file to fix the fields
> containing double-byte characters, but it would be /nice/ if IBM
> would issue CPF2958 error for every record that had conversion
> errors, since CPF2958 also indicates the RRN of the records with
> errors.