Re: Handling decimal data errors at the field level

Thomas Garvey wrote:

Has anyone had any experience handling decimal data errors at the field
level? I know you can trap for the decimal data error that happens when a
record is read that contains a decimal data error in one of the field
values, and I know you can set the FIXNBR parameter on the RPG compile to
automatically fix numeric values that are bad. But I want to know which
specific field(s) in the record were bad. It's OK that the compiler will
fix them for me, but I want to know which field(s) in the record were fixed.

I think it's bad that the compiler will fix them for you. FIXNBR and its evil twin IGNDECERR only serve to hide problems.

There's no way to trap errors on I specs within the program; you could only get granular information if you read into a data structure.

Once you have your data structure, you can use MONITOR to locate the problem fields.

read file ds;
monitor;
chkds.price = ds.price;
on-error;
-- report the error with PRICE
endmon;
monitor;
chkds.discount = ds.discount;
on-error;
-- report the error with DISCOUNT
endmon;

Maybe I'm naive to say this, but I think it would be better to let the program crash on the I spec, find out which I spec it was on from the joblog or the formatted dump, and then figure out why the file had bad decimal data in that field. Correct the problem, and repeat, until the file isn't getting any more bad decimal data.

(I'm sure there are much more direct ways to figure out which fields are bad in a file. I think even CPYF can do it, if you force it to do a mapping from packed to zoned, or zoned to packed.)