RE: Fixing bad data in a numeric field

Only that you may have compatibility problems with, say, RPG V and that you
have not corrected the bug that created the invalid decimal data in the
first place.

The primary obstacle to our using more RPG IV code here is that the system
we are stuck with has all programs compiled to ignore decimal data errors
(FIXNBR(*INPUTPACKED) is not an option at V4R1 as far as I know) to avoid
the substantial number of fields in the system with this problem.  In my
opinion, using such an option to compile your programs simply ignores the
problem.  I would much rather have a program crash with a decimal data error
so I can correct the problem rather than continue in blissful ignorance.
Then again, I write code that initializes record formats with CLEAR rather
than setting every individual field to 0 and blanks and I never use
LVLCHK(*NO), but I digress.

Another problem with not knowing you have a problem is that tools like Query
and SQL do not like invalid decimal data at all.  Attempting to select
records from a file using a field with bad data results in the query
stopping with an error.

Just my opinion, of course.

Donald R. Fisher, III
Project Manager
The Roomstore Furniture Company
(804) 784-7600 extension 2124
DFisher@roomstoreeast.com

<clip>
Is there any downside to using this H-spec just as "preventative" medicine
in our set of standard H-specs?
<clip>
> FIXNBR(*INPUTPACKED)
<clip>