RNQ0907: Decimal data error

What it means

RNQ0907 is an ILE RPG runtime message for program status 00907. IBM's ILE RPG Reference describes that status as a decimal data error, where a digit or sign isn't valid. Packed and zoned decimal fields have strict rules. Every digit position must hold 0 to 9, and the sign must be one of the allowed sign values. Blanks, hex zeros and letters break those rules.

The machine finds the bad value when the program uses the field and raises MCH1202. The RPG runtime reports it as status 00907. It is the IBM i version of the S0C7 data exception on z/OS. The instruction is fine. The data reaching it is wrong, so the fix is usually to find where the bad value came from.

RNQ0907 is the inquiry form, sent when nothing in the program handled the error. The job waits for an answer on the user's screen or, in batch, usually in QSYSOPR. RNX0907 is the escape form of the same condition, which MONITOR or a calling program can catch without anyone replying.

Common causes

• A record written by something other than a normal program, such as a file transfer, a CPYF with FMTOPT(*NOCHK), or a program that wrote character data over numeric fields.
• A data structure without the INZ keyword. Its subfields start out as blanks, so a packed or zoned subfield holds blanks until the program sets it.
• A data structure that overlays character data with numeric subfields, where the character data doesn't match the layout.
• A record layout that changed while an old program still reads the file with the old field positions.
• A parameter passed as character from a CL program or command line into a program that expects a packed number.

How to find the problem

1. Look for MCH1202 just above RNQ0907 in the job log (DSPJOBLOG). It confirms a decimal data error.
2. Press F1 on RNQ0907 for the procedure, program and statement number. Find that statement in the compile listing and list the numeric fields it uses.
3. Reply D to get a formatted dump. Fields with bad decimal data stand out because their values can't be shown as numbers.
4. If the field came from a file, find the record being processed and look at it in hex. DSPPFM can switch to a hex view so you can see blanks (X'40') where digits should be.

How to fix it

• Correct the bad records at the source, then rerun. Find out which job or transfer wrote them.
• Add INZ to data structures, or set numeric subfields before using them.
• Make sure every program that reads the file is compiled against its current layout.
• Check data you don't control before using it, and report records with bad numeric fields instead of failing.
• The compile option FIXNBR(*ZONED) and FIXNBR(*INPUTPACKED) can make the program treat some bad zoned or packed data as valid. They hide bad data, so use them with care.
• Reply C for the waiting job. Use D first if the developers need the dump.

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.