Re: Reading the dump

[Rich Duzenbury <rduz@xxxxxxxxxxxxxxxxxxx>]

It's tough to debug without the source code!  Hopefully, the fix will be to 
just update some record.  If you happen to need to recompile the program to 
fix the problem it could be difficult, expensive, or both.

Sometimes the statement number starts with a letter followed by a 
number.  As I recall, the compiler assigns the first file letter A, the 
second one B and so on.  The first field within each file is assigned a 
number.  So, if you get an error statement like C000005, it means that when 
the system read in some data for the third file on the F specs, the fifth 
field has invalid numeric data.  You might be able to figure out which file 
is the third file by looking at the WRKJOB open files list, or perhaps not 
if the program frequently opens and closes files.

If you have a regular statement number, then it's more of a guessing 
game.  The dump shows each field used in the program, along with it's hex 
equivalent.  You can go through your dump and find all the numeric fields 
that have garbage in them.  Perhaps you will be able to tell which file has 
the bad data, or perhaps not.  Packed fields should look like 
x'12345F'.  Signed fields should look like x'F0F1F2F3F4F5'.

I first look at *ENTRY parms and data structures as likely places for 
decimal data errors.  If the program uses the cycle and is a level break 
program, I look to see if the primary file has records.  I have seen lots 
of programmers 'forget' that even if the primary input file is empty, the 
total time processing gets run.   In that case, data structures with 
numeric fields often are invalid, and cause decimal data errors.

You might also consider asking this question on the MI400 list, as there 
may be ways to look at the instruction stream and determine exactly which 
field has gone bad.

Regards,
Rich

At 08:35 PM 3/30/01 +0200, you wrote:

>Hello,
>
>I have a small question...
>
>  I have a program rpgIII (only the object not the source) that suddenly 
> crashed with a decimal data error and I took a dump. I could obtain from 
> the dump the statement no at which the error occurred...but could I also 
> determine the variable name which causes this decimal data error at this 
> statement number...If yes,  I am curious to know how can I do this.
>
>Thanks
>Heba

Regards,
Rich

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---