Hello,
If I understand correctly, you are deciding between using the old
fixed-format TESTN opcode vs. MONITOR/ON-ERROR when reading a 1 million
row database table, where about 70% of the rows have decimal data
errors, so approximately 700,000 errors.
The TESTN opcode will be much faster when such a high percentage of the
rows has errors.
This is because it takes a significant amount of system resources to
generate an exception (*ESCAPE message.) It takes time to trap the
error, generate the*ESCAPE message, put it into the program queue, job
log, etc, then get handled by MONITOR, and presumably you'd also write
code to remove the message from the program queue. All of these steps
takes much more time than testing it with TESTN.
Don't get me wrong, TESTN also takes time, its just less than generating
an exception. When you use MONITOR, you don't have to use TESTN, so
for each database row where the fields are valid, the MONITOR approach
will take less CPU time. For every row where there is an error, the
TESTN would take less CPU time. Your decision would be easy if all
rows had errors, TESTN would definitely be faster. If none had errors,
MONITOR would definitely be faster. In fact, even if only a relatively
small percentage (I don't know the exact number, but I'd guess at around
10%) had errors, MONITOR would be faster. But, with 70% having errors,
i'm pretty sure TESTN is faster.
One big drawback to TESTN is that it cannot be used in free-format.
Since free-format is the standard RPG coding style, and has been so for
a VERY long time now, it would not be a good idea to use TESTN. It
simply is unacceptable to code as if it is still 2002...
So instead of using TESTN, I would write a little subprocedure that uses
some IF statements checking for *blanks and calling %check to check for
valid digits. This will catch 99% of the numeric errors, and you can
wrap it in a MONITOR statement to catch the rare errors that
blanks/%check don't find. This way, you can just call the subprocedure.
Or, if you really love TESTN so much that you are unwilling to write
your own, then please at least wrap TESTN with a subprocedure so that
you only need fixed format code in one small place. Then, just call
that subprocedure to do the testing.
Good Luck
On 7/8/2021 10:49 PM, Singh, Ashwani (Lake Mary) via RPG400-L wrote:
Thanks Charles and John!
When I said fairly large the whole log which was about 9999+ pages long had this error only..... I would say out of million records may be more than 70% + of them gad the error.....
TEST(N) is good idea or bad? Open for any suggestions
MCH1202 Escape 40 07/06/21 22:56:58.951684 EF9XXXXX CXXXXXX *STMT EF9XXXXXX CXXXXXXX *STMT
From module . . . . . . . . : EF9XXXXXXX
From procedure . . . . . . : EF9XXXXXXX
Statement . . . . . . . . . : 94700
To module . . . . . . . . . : EF9XXXXXXX
To procedure . . . . . . . : EF9XXXXXXX
Statement . . . . . . . . . : 94700
Message . . . . : Decimal data error.
Cause . . . . . : The sign or the digit codes of the packed or the zoned
decimal operand is in error. Valid signs are hex A-F, valid digit range is
hex 0-9.
Data definition -
XXXXXD DS
XXXXXD NP18 1 9a Inz
XXXXXD NP18D 1 9P 0 Inz
XXXXXD DtlRefNum S 18s 0 Inz
D refNum 18a
Thanks,
Ashwani
midrange.com
