× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.