CPF5035: Data mapping error on member

What it means

When a program reads or writes a database record, the system often has to map field values from one form to another. A logical file can present a field with a different type or length from the physical file. A date stored in one format can be shown in another. A field that allows nulls has to be handed to a program that may not expect a null. If a value can't be mapped, the system sends CPF5035.

CPF5035 is a diagnostic message. Its help names the field, the record number and a reason code that says what went wrong. It is usually followed by the message for the failed operation, most often CPF5029, whose help points back to CPF5035 to identify the fields in error. So CPF5035 is the message that tells you which field to look at.

Press F1 on the message to see the reason code and the full list on your release. The codes people meet most are these. Code 1 is data that isn't valid in a decimal field, and 2 is a significant digit that would be lost. Codes 15 and 16 are a date later than the latest or earlier than the earliest the format allows. Codes 17 and 18 are a date, time or timestamp in the wrong format or holding data that isn't valid. Code 19 is a null value the operation didn't expect, and 20 is a null that can't go into a field that doesn't allow nulls.

Common causes

• A date field uses a two-digit-year format such as *MDY and holds a date outside the range 1940 to 2039, which that format can't show. IBM has a support note on this case under reason code 16. In the message help, 16 is a date below the minimum and 15 a date above the maximum.
• A program wrote a date field without setting it. IBM describes an OPM RPG case where a program compiled with CVTOPT(*DATETIME) left the date blank, which isn't a valid date.
• A record contains a null value and the program reading it doesn't support nulls, or a program tried to put a null into a field that doesn't allow one.
• A logical file defines a field with a type or length that the physical file's data doesn't fit, so mapping fails for some records.
• Bad data was copied into the file at the byte level, so a date, time or numeric field holds a value that isn't valid for its type.

How to find the problem

1. Run DSPJOBLOG, put the cursor on CPF5035 and press F1. Note the member, the field, the record number and the reason code.
2. Look at the message that follows, usually CPF5029, to see which operation failed and in which program.
3. Read the record by its relative record number, for example SELECT * FROM ACCTLIB.PAYMAST WHERE RRN(PAYMAST) = 1437, or use DSPPFM.
4. The help for CPF5029 says that a record number of 0 means the error came from something other than a stored record, such as a write or update through a logical file, a default value or a null. In that case check the record the program was building.
5. IBM suggests journaling the physical file and reading the journal to find which job is writing the out-of-range values.

How to fix it

• Use date formats with four-digit years, such as *ISO or *USA, in the file or in a logical file over it. IBM's example re-creates the file with DATFMT(*USA), or adds a logical file with that format so programs can find and correct the bad values.
• Make every program that writes the file set a valid date, and recompile OPM RPG programs with CVTOPT(*DATETIME) if they must handle date fields.
• Give the field a default value with the DFT keyword so records written without it still get a valid date.
• Handle nulls. Let the program read null values (in ILE RPG, the ALWNULL option) or change the field so it doesn't allow them, and correct records that hold nulls where they shouldn't.
• Correct the bad records with SQL or a one-off program, then rerun the job that failed.

What it looks like

Data mapping error on member PAYMAST.

DSPMSGD MSGID(CPF5035) MSGF(QSYS/QCPFMSG)

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your IBM i release.