Re: Decimal data errors

["Dave Boettcher" <DBoettch@xxxxxxxxxxxxxxxx>]

Also, It seems I have read recently about a way to define the file so
that fields are not read until used.  
Thus reducing the decimal data error possibility. 
Using this in conjunction with the monitor blocks only around the
fields that have presented a problem should reduce your coding.
Trouble is, I can't remember how that was, seems like it might have
been to read the file record directly into a data structure, but I'm not
sure.
Perhaps someone else can build on my faulty memory.

hth, 

Dave B

> > > michaelrtr@xxxxxxxxx 11/28/2006 11:39:41 AM >>>
How about a MONITOR block around the statements that access the
suspect
fields?

On 11/28/06, James H H Lampert <jamesl@xxxxxxxxxxx> wrote:
> We have a customer with a couple of files with lots of
> decimal data errors in them. Fields that are nominally
> zoned decimal, that either have packed decimal values in
> them, or EBCDIC blanks.
>
> Apparently, their own applications aren't balking at the
> wonky field content, but ours are throwing DD errors,
> locking up server jobs and in some cases creating traffic
> jams by blocking other jobs from getting locks.
>
> They don't seem to be in any kind of hurry to clean up
> their database.
>
> Obviously, I could use a FIXNBR compiler option, but that
> would be kind of a "sledgehammer" approach to the problem
> (besides which, if the packed-value-in-zoned-field is
> meaningful, it would presumably discard meaningful data
> that their application understands just fine). Likewise, I
> could program-describe the affected files, but then, if
> they were changed in any way that affected the fields we
> used, or the record length, we'd have to go in and modify
> the source, and there wouldn't be any level-check errors
> to tell us when there was a mismatch.
>
> Any other ideas?
>
> --
> JHHL