Re: Data structure and data decimal error

Booth M wrote:
> Non iSeries files are being transferred to an iSeries.
> The file layouts will be "exactly the same" as needed
> in the iSeries files.  My plan would be to  eval the
> incoming data string into an externally described data
> structure, thusly populating the record format.

Excerpting code from Susan's example in the URL Rob provided:
(D) C                   MONITOR

     // Set up display values from input data
(E) C                   EVAL      Num1 = InputData.InpNum1
    C                   EVAL      Num2 = InputData.InpNum2
    C                   EVAL      Num3 = InputData.InpNum3

     // Catch decimal data errors
    C                   ON-ERROR  DecDataErr

(F)  // Place code here to react to Dec Data Errors

    C                   ON-ERROR

     // Place code here to deal with other errors

    C                   ENDMON

OK. Somebody over on the other platform keyed 123456+ into the customer
number field, InputData.InpNum2.  At (F) we know that one of the input
fields was invalid, but which one?  What to put on the audit report -
Record 852 has bad data?  Wouldn't it be better to say that the 'Customer
number field has invalid data; "123456+" should be numeric?'  You could
readily write this sort of code if you built a small code generator to read
the field descriptions for you and emit code similar to the above, only a
single eval in each MONITOR block.

Having done more than a few of these sort of things, I strongly advise that
the inport file layout consist of only character fields.  Then test them for
'numericness' or 'dateness' yourself, either via a subprocedure or TESTx
operation.  It has always seemed tidier to prevent an error rather than
trapping it, both from an aesthetic view and from run-time performance on
small machines.  Just my opinion though.
  --buck