Decimal Data Error is something which comes up very often while I do testing and debugging of RPG programs. Sometimes, the field in error is very obvious and clear like when you debug a program and the error is thrown at an EVAL operation. But in some other cases, this is not clear and an option to take a Dump appears. After you take a dump, how do you understand the field in error and where the issue occurred? So basically, the question is how to read a Spool file and understand what went wrong. How to understand the action required to correct the issue. Mainly how to understand which field is being assigned a bad value that resulted in Decimal data error? What are the important points to look out for in the spool? Below is a sample spool file for reference which I am trying to understand.
3 Answers
Statement in Error . . . . . . . . . . : 00100100
That will either be the source statement number, if your program was compiled with option(*SRCSTMT) or as appears to be the case here...the compile listing line number.
Also, the following are usually helpful since a decimal data eror usually occurs when reading data from a file.
Status that caused RNX9001 . . . . . . :
Last File Used . . . . . . . . . . . . :
Last File Status . . . . . . . . . . . :
Last File Operation . . . . . . . . . :
Last File Routine . . . . . . . . . . :
Last File Statement . . . . . . . . . :
Last File Record Name . . . . . . . . :
- 21,637
- 1
- 20
- 44
-
If you have a compile listing handy (or can regenerate it to match what's already running), then search the compile listing for that statement number. It'll likely have the numeric field with the problem. – Tracy Probst Jan 24 '17 at 18:49
-
And if the error is thrown on an input statement, it's almost certainly a native DDS file rather than a SQL table. Field values for native files are validated when read, but SQL columns are validated when written (which makes it difficult to get invalid data into a table in the first place). – user2338816 Jan 29 '17 at 08:49
RNX9001 Decimal data error. In the wild 99% a numeric field hasn't been initialized.
Consider using the reset opcode. This will set all the fields in a record format to their default values. Then populate the data.
RESET ORDERSF
- 5,581
- 1
- 26
- 35
The default value for a numeric local variable is zero (0000 in hex). The default value for a numeric field in a local data structure is blank spaces (4040 in hex). Attempting to perform math on an uninitialized field that contains only blanks will cause an a decimal data error.
The solution suggested below of a RESET operation will restore the value to what it was at end of the *INIT operation of the program. This is useful for local variables, but not for numeric fields within data structures.
A better solution is to add an INZ keyword to the definitions of your data structure fields. This is not necessary for local variables (although it may be a good habit), but it will prevent decimal data errors in your data structures by initializing them to zero rather than to blanks.
D SQL_Header DS
D Order# 6S 0 INZ
D OrderSufx 2S 0 INZ
D CustOrder 20A INZ
From the documentation:
When the INZ parameter is not specified:
Static standalone fields and subfields of initialized data structures are initialized to their RPG default initial values (for example, blanks for character, 0 for numeric).
Subfields of uninitialized data structures (INZ not specified on the definition specification for the data structure) are initialized to blanks (regardless of their data type).
The default behavior is probably for performance purposes (especially when creating an array of data structures), but it can be surprising to those not accustomed to the behavior. Getting into the habit of using INZ makes the behavior more similar to other programming languages and will prevent decimal data errors.
- 1,274
- 10
- 24