I would agree this should work. Many times it is an issue of the substitution not being what you would have expected. IMFOJOB is not being set to BBISA123.
A useful debugging tool is provided in hlq.BBPROC. It is a piece of REXX code that will display many of the variables available to a rule. The member name is QAOLISTV. I code my rule to capture the event but only execute this piece of REXX code. I then look in the BBIJRNL to verify the variables I would like to use are indeed being set as I would expect. Or you can write you own REXX code to display your variables.
It would help to know the event type you are trapping on and a bit more about the RULE that you are coding.
Thanks Fred, I am going to try QAOLISTV out…
As for the event type it is a MSG event..
I am still pretty new to Mainview so I am still learning what all you can do with it…
But what I am trying to do is capture a msgid and then issue a command related to it, but if it happens again within a 10 minute period don’t issue the command but notify support. So I need to set a Global variable to know if it’s has happened once already so as to not issue the command again and then clear the global variable after 10 minutes… Since there are several of these MQ’s I was hoping to match the jobname via global variable to the actual jobname so I wouldn’t have to code several rules (if I run out of room) which are basically the same.
So in SV (Variable Dependencies) I would code:
&!IMFOJOB eq &IMFOJOB
Instead of having to do:
TQV3MSTR eq &IMFOJOB or
TQV4MSTR eq &IMFOJOB or
Etc… etc.. etc..
Thanks again Fred!
1 of 1 people found this helpful
You can handle this requirement using 3 rules:
1- trap message when a global variable is different than yes, issue command and a delayed journal message and set a global variable.
2- trap message when global variable is yes, issue notification. Not sure if you need only one notification, if you do use criteria matching to suspend the rule for 10 minutes.
3- trap journal message (delayed for 10 minutes) to reset the global variable to NO.
For the global variable use a stem name. I suggest you use for the 1st part the message id (in case you need to do this for several messages) and the second part is the IMFOJOB of the issuing address space.
Be aware there is a parameter that affect what goes into IMFOJOB in your AAOPRMxx (MSGJOBNM)
As Fred indicated, QAOLISTV will help you determine what to use to represent the correct QMGR.
Check out these to insure you get the correct Address space name IMFOJOB, IMFXOJOB, IMFSYSID and IMFCIJOB.
Assuming IMFOJOB is correct, this should help create 3 rules:
Rule 1 in SV: !CSQE035I.IMFOJOB (the ! indicate 2 step substitution for a stem name) NE YES
Rule 1 in A1: issue the command you want
Rule 1 in A1 *Issue Msg( JRN ) ==> DLY(600):JCSQE035I RESET VARIABLE CSQE035I.&IMFOJOB
Rule 1 in AV: CSQE035I.&IMFOJOB YES
Rule 2 in SV: !CSQE035I.IMFOJOB EQ YES
Rule 2 in A1: issue your notification
Rule 3 trap JRNL, in S1: JCSQE035I
Rule 3 in SV: &WORD4 NO (word4 will match on the delayed JRN from above on the last word)
Please feel free to contact your BMC MainView SC if you would like more detail on this.
Hope this help, Gilles
I want to expand on what Gilles provided above.
Rule-id Stat Text-id Type
________ _ ________________ ____
RULE1 ENA IEF125I MSG
RULE2 ENA IEF125I MSG
RULE3 ENA JIEF125I JRNL
So rule one is a message event type
rule 2 is another message event type on the same message as rule1
Rule 3 is a journal message capturing the journal message put out by rule 1 with the delay.
My final addition to what Gilles wrote is rule 3 will have an action to reset the variable to NO
AV: CSQE035I.&IMFOJOB NO
Thanks to Gilles for his solution.
Good luck with this,
Giles/Fred, You Guys are awesome! Thanks for all your help! I’ll let you know how this works out.