Re: Default for Data Exception for trouble shooting.

Using the dump can be helpful, it won't give you the record, but will show 
you the value of all variables in your program. using these, and the line 
number in the program to see what variable gave the error, you should be 
able to determine the record in the file.
What I think you are actually looking for is not a critique of using the 
dump, but this. If QSYSOPR is set to *DFT like it is here. you will get 
cancel for most messages, if your company is still using system operators 
to answer messages, just correct them on what to do. There is a parameter 
on the SBMJOB command called. INQMSGRPY. This is where you specify when a 
message comes up needing a reply where to look for it. You can change this 
to *SYSRPYL,. This tells your program to use the System reply list to look 
up how to answer the message. The command WRKRPYLE Work with reply list 
entries, lets you add or change the default answer to give based on the 
error code received. 
 



Jerry Adams <jerry@xxxxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
01/04/2007 09:11 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: Default for Data Exception for trouble shooting.






Speaking from way experience (ouch), the dump will tell you the line 
number (compiler, not source) on which the error occurred and the 
contents of the fields *after* the field was changed.  For example, 
trying to move blanks into a numeric field, will show a field value of 
x'404040 (etc)'.  That is when the field is being propagated.


Usually one would not receive a decimal data error on a read because the 
creation of the record blew off before it could be created; thus, no 
record.  However, if one is dealing with the 36 environment and old RPG 
II programs, bad data elements can be created.  When an RPG IV program 
comes behind it and tries to read the invalid numeric data, it will 
issue a decimal data error.  Again, sadly, from experience.


                 * Jerry C. Adams
*IBM System i5/iSeries Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
                 615.995.7024
fax
                 615.995.1201
email
                 jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



rob@xxxxxxxxx wrote:

Ideally you'd define your data files with SQL's DDL instead of DDS and 
avoid the possibility of getting decimal data errors in your file in the 

first place.

http://www-03.ibm.com/servers/eserver/iseries/db2/pdf/Performance_DDS_SQL.pdf

Failing that, you could change your input processing and do some 

extensive 

MONITORing around each field to verify it's validity.

I am forgetting, does the error occur upon the READ, or, upon the usage 

of 

the field in error?  The question being, will a dump tell you the record 

or hasn't the data even been partially propagated yet?  If it's at first 

use then the dump should be fine.

Rob Berendt