Scott,
Thanks for the explanation and that's why I ask here before making any decision.
Wrote this under procedure TESTNUM!
P TestNum B
D TestNum PI N
D TstNStr 30 VALUE
D SLen 3 0 VALUE
D Digits C '0123456789'
// If string length passed is valid, check for any non-numeric
// characters in passed string and find position in string
NonNumPos = 999;
If SLen > 0
and SLen <= 30;
NonNumPos = %CheckR(Digits:TstNStr);
EndIf;
//Set indicator Numeric based upon no numerics in character string
NumericInd = (NonNumPos = 0);
RETURN NumericInd;
Thanks,
Ashwani
-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Scott Klement
Sent: Friday, July 9, 2021 2:10 AM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Monitor block performance question
⚠ EXTERNAL MESSAGE – Think Before You Click
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
--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://urldefense.com/v3/__https://lists.midrange.com/mailman/listinfo/rpg400-l__;!!P9vvK-4S!0hTAjYhG-Kf9NTevsStrdkPhVKO92XThJ-9cCZ34216ypJ-pac636BO9Ge8boLSk24A$
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://urldefense.com/v3/__https://archive.midrange.com/rpg400-l__;!!P9vvK-4S!0hTAjYhG-Kf9NTevsStrdkPhVKO92XThJ-9cCZ34216ypJ-pac636BO9Ge8bqhGtXLw$ .
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://urldefense.com/v3/__https://amazon.midrange.com__;!!P9vvK-4S!0hTAjYhG-Kf9NTevsStrdkPhVKO92XThJ-9cCZ34216ypJ-pac636BO9Ge8bMTvUqYw$
midrange.com
