× 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.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.