MCH1202: Decimal data error

What it means

Packed and zoned decimal fields have strict rules. Every digit position must hold 0 to 9 and the sign must be a valid sign value. Before the machine adds, compares or moves such a field as a number, it checks those rules. When they fail, it raises MCH1202 and the instruction stops. It is the IBM i counterpart of the S0C7 data exception on z/OS.

So the statement in the program isn't wrong in itself. The data reaching it is. The real work is finding which field held the bad value and where that value came from.

MCH1202 is an escape message sent to the program that ran the failing instruction. An ILE RPG program reports it as status 00907 and, if nothing handles it, shows inquiry RNQ0907. COBOL and CL programs get their own inquiry or function check. MCH1202 also shows up in server jobs such as QZDASOINIT when a stored procedure receives bad decimal input.

Common causes

• A numeric field was used before anything valid was stored in it. In RPG, subfields of a data structure start as blanks unless the structure is initialized, so a packed subfield holds blanks.
• A record arrived from another system or from a program-described file with blanks or letters in a numeric field. Files from other platforms and from System/36 programs are common sources.
• The program's record layout doesn't match the file, so it reads the wrong bytes as a number. This happens when a program-described layout or a copybook falls behind a file change.
• A character field was moved into a numeric field byte for byte, for example through a data structure overlay, without converting it.
• A caller passed a parameter of the wrong type or length, such as a character value to a packed parameter.
• For SQL procedures, IBM documents a case where the catalog entries for the procedure's parameters (QSYS2.SYSPARMS and SYSROUTINE) were missing or wrong, which led to MCH1202 in the server job.

How to find the problem

1. Run DSPJOBLOG, put the cursor on MCH1202 and press F1, then F9. The program, module, procedure and statement number tell you where the bad value was used.
2. Look at the numeric fields used in that statement. One of them holds the bad value. In debug (STRDBG), display the field in hex, for example EVAL WSAMOUNT:X in the ILE debugger, and look for X'40' (blanks) or X'00'.
3. If the field came from a file, find the record the program was processing and look at it with DSPPFM and F10 for hex, or with an SQL query using HEX() on the column.
4. IBM notes that bad data written to a subfile record may only be caught later, when the subfile control record is written. If the statement is an EXFMT or WRITE of a control format, check the subfile fields too.

How to fix it

• Correct the data at its source, then rerun. If a file from another system is the cause, fix the job that builds it.
• Initialize numeric fields and data structures before use, for example with INZ on RPG data structures, or CLEAR and RESET.
• Validate input before using it. Test that a character field is numeric before converting it, and reject or log bad records.
• Recompile every program that uses a changed file or copybook so the layouts match.
• As a stopgap, ILE RPG's FIXNBR compile option can repair zoned and packed input data, and IBM describes a one-off cleanup that reads and rewrites a file with an OPM RPG program compiled with IGNDECERR(*YES). Use either only after you know what the repaired values will be.

What it looks like

Decimal data error.

DSPMSGD MSGID(MCH1202) 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.