When a value read into a packed-, zoned-, or integer-decimal field is not valid
numeric data - for example non-numeric text mapped into a numeric field - using
that field raises a decimal-data error, %STATUS 00907. The value is treated as a data error, not as zero: the compiler does
not silently substitute 0. Trap it with MONITOR/ON-ERROR (or the (E)
extender on the reading operation) when a file may contain such data; left
unmonitored it halts the program.
This covers a database column whose stored bytes are not valid decimal data - a packed or zoned field carrying a bad digit or sign nibble, as happens after
a CPYF ... FMTOPT(*NOCHK) from a mismatched layout. Such a column reaches the
program as the same 00907 decimal-data error, naming the file and column, rather
than as a fabricated zero.
For a packed or zoned database field the error belongs to the statement that
uses the field, not to the input operation that read the record. The read moves
the record image into the input fields without inspecting it, so a record whose
corrupt column the program never references is processed normally. Scope a
MONITOR around the statement that uses the field:
READ INVMASTR; // succeeds even if a packed column is corrupt
MONITOR;
Total = Total + AMOUNT; // 00907 is raised here, if AMOUNT is corrupt
ON-ERROR 907;
BadRows += 1;
ENDMON;
Integer (I) and unsigned (U) fields are the exception: they hold no state
that can represent "not valid decimal data", so a refused integer column is
raised at the read. In practice this does not arise - those fields are binary,
and every bit pattern in them is a valid integer.