Re: Data structure and data decimal error

Actually Susan mentioned, in the article, that it may be up to your 
preference as to do one field within each monitor block.

And you're right, in the old days, it was better to check each field prior 
to letting the error occur.  However, with the advent of the monitor code, 
you will get MUCH better performance if you let the trapped error occur, 
assuming that the error is the exception and not the rule.  Meaning if the 
error only happens once a fiscal quarter, then you won't have the 
performance concerns of doing string manipulation, TESTN or TESTD on each 
and every field successful or otherwise.

And there is nothing stopping you from fancying up your error message from 
reading the infds to determine which record number it was, and if you do 
single field monitor blocks, from telling the field name.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 





"Buck" <buck.calabro@xxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
07/23/2003 03:28 PM
Please respond to RPG programming on the AS400 / iSeries
 
        To:     rpg400-l@xxxxxxxxxxxx
        cc: 
        Fax to: 
        Subject:        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



_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.