|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.