Re: Invalid decimal data

At 08:17 08/27/2001, Donald Fisher wrote:
>We have a series of files, possible all of them, containing invalid decimal
>data in some fields.  The only two ways I can think of to identify them are
>to create an RPG program that will interrogate each field by executing a
>Z-ADD operation and checking the error indicator or to execute an SQL
>statement using each numeric field in the selection criteria.  The statement
>should fail upon encountering invalid decimal data.  The trouble with the
>latter method is it won't allow me to fix the data.  At least I don't think
>so.

If you only need to initialize invalid fields to default values, you can
use CPYF to do that. The procedure is to make a temporary version of the
file with an additional dummy field at the end of the record, so that the
real and temporary files do not have identical records. Then use cpyf with
fmtopt(*map *drop) and errors(*nomax) (I think the keyword is errors - it's
the last parameter when you prompt cpyf) to copy the data from the database
file to the temporary file. The joblog will tell you if changes were made,
but I don't think it gives you record numbers or anything. It is possible
to use two dsppfm or dbu or shwfc windows to blink back and forth between
the two files to identify changes if you have identical records displayed
from both files. Any differences will catch your eye, sort of the way
astronomers used to compare glass plates looking for comets etc. Obviously
that doesn't work well for large files. Anyway, once you're satisfied that
the data in the temporary file is OK, you just copy it back, replacing the
data in the real file. You can use fmtopt(*nochk) for that step, since the
records are identical up to the last byte of the real file. The extra field
at the end of the temporary file will be ignored. Fmtopt(*nochk) runs a lot
faster than fmtopt(*map *drop). Oh, and make sure you have a good backup
before you start<g>.

hth
Pete

Pete Hall
pbhall@execpc.com
http://www.execpc.com/~pbhall/