RE: Handling decimal data errors at the field level

["Thomas Garvey" <tgarvey@xxxxxxxxxx>]

That's exactly what this program is intended to do.. Find out what's broken
so it can be researched to correct the problem.  But having a program hard
halt is not the way to do that. 


Best Regards,
 
Thomas Garvey
Unbeaten Path International
Office: 630-462-3991
web:   www.unpath.com

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Barbara Morris
Sent: Friday, June 20, 2008 12:58 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: 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.)

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.