Re: Decimal data errors

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