Re: igndecerr(*yes)

My memory is far from perfect, but my memory is that file-described files were the only game in town at one time, and any collection of columns could be whatever a programmer chose them to be. Part of the consequences of that was that we could add a record to a file and not define all of the fields. The computers of that era weren't capable of lots of complex operations in one program; often times we had to run through a series of simpler programs to fill a long record.

Anyway, for that reason blanks and zeroes were pretty much interchangeable. The migration away from that paradigm was neither pretty nor ideal but over time it was fairly effective and graceful.






On 9/17/2012 12:14 PM, Barbara Morris wrote:

On 2012/9/17 9:36 AM, Dave wrote:

...
I eventually found that the reason being was that a custom compile
command compiled the RPGIII with igndecerr(*yes).

My question is, why would anyone want to compile this way?

Why? Stupidity is the only answer I can think of. Or at least, the only
kind answer. Irresponsible laziness is another possibility, if whoever
added IGNDECERR really understood what they were doing.

Turning off decimal data error reporting because of one known source of
"ok" decimal data errors is similar to _permanently_ turning off all the
smoke alarms in the house because the toaster sometimes triggers the one
in the kitchen.

I wish IGNDECERR had never been added to RPG III, and I wish FIXNBR
hadn't been added to RPG IV. FIXNBR is a tiny bit less horrible since it
produces a predictable result, but I still think it was wrongheaded to
provide an option to ignore data errors. (For the record, I am the one
responsible for adding FIXNBR(*INPUTPACKED). We can't always get what we
want ...)