× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Yes that is good. I have to see how it is used in Robot.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Bob P. Roche
Sent: Thursday, January 04, 2007 10:32 AM
To: RPG programming on the AS400 / iSeries
Subject: 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_SQ
L.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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.