Being More Selective with NOOPSLOG option

[Anon Anon]

So I have a bunch of DB2 Capture and Apply tasks which put out TONS of messages with ID ASN*. There are two rules currently coded which use NOOPSLOG to suppress ASN1* and ASN0* message ID's, essentially ALL of the ASN messages. Currently, I am using two messages (ASN0109I & ASN1045I) to key off for setting the state UP in SSM. The problem is, with the ASN messages not showing up in the OPSLOG it forces me to use the SYSLOG to trace them if there is an issue. I find the OPSLOG much easier to use for something like this. So what I would like to do is to let the two specific message ID's I am interested in, go to the OPSLOG but suppress everything else. Currently, I do not see how to accomplish this. If I just remove NOOPSLOG from the rules then the OPSLOG will get hundreds to thousands of messages but there is no RETURN value which will suppress from the OPSLOG either. Has anyone else encountered this situation and if so, what did you, would you do, to solve it?

[Cesar_Molina]

Travis

For the two messages ASN0109I & ASN1045I consider writing two MSG rules to fire upon those two message events and then use the logic in sample provided CCLXRULS(DSNL027I) to reissue the message back via the address WTO control statement. Let us know if this sounds like a practical solution for your request as you are allowed to fire multiple rules upon a single event.

Regards, Cesar

[Anon Anon]

I looked at the rule and I believe the key logic here is the MSG.TOKEN variable. I then took a look at the manuals and saw that the TOKEN works in conjunction with DOM. My concern would be something accidentally DOM'ing the message either through a rule or errant code. Also, as I was looking at the logic and thinking about how AOF processes messages I remembered the MSG.USER variable. I think this may work better for my purposes. Here is what I am thinking of doing:

 

AOF processes messages for the same message event from Most Specific to Least Specific so...

)MSG ASN0109I & )MSG ASN1045I will fire first and can set MSG.USER to some value that indicates this message needs reissued.

)MSG AND0* & )MSG ASN1* will fire next and look at the value of MSG.USER. If it indicates that the message should appear in the OPSLOG then it will reissue the message and leave the rule otherwise it will just do its current logic.

 

Does this make sense?

 

EDIT: So I set up some testing on our development LPAR and found that this logic does not seem to work. It appears that the NOOPSLOG option on the message ID spec is overriding whatever I do in the rule. I was thinking about using the RETURN statements for the message rule but none of them remove the messages from the OPSLOG, only the SYSLOG which I do not want to do. I would like to see the two specific message ID's but no other ASN* message ID's in the OPSLOG because there are just too many ASN* messages and it floods the OPSLOG.

[gorda05]

You cannot be 'selective' via some if/then/else  logic within the )PROC section of a rule that determines if a message is to be removed from the NOOPSLOG. Within a NOOPSLOG rule, if you need to have a certain message or messages displayed, you can reissue with Address WTO and OPTION(C). Option(C) will cause the reissued message to not be processed by MSG rules. So for your specific case:

)MSG ASN* NOOPSLOG                               

)Proc                                            

if msg.id = 'ASN0109I' | msg.id = 'ASN1045I' then

do                                              

  parse var msg.text msgid msgtxt                

  address WTO                                    

  "Msgid("msgid") Text('"msgtxt"') Option(C)"    

end                                             

 

Note: Option(C) only works with single line WTOs . Meaning, if you attempted to reissue a MLWTO (using TEXTVAR keyword of Address WTO), OPTION(C) is not honored. So in your case if ASN0109I and ASN1045I are true MLWTO's, your rule above will only log the primary line of the message. If you wanted to reissue the complete MLWTO, you have to at least create a new MSGID so the rule would not refire. Also, in your particular case, it seems you just want some type of audit for the event that triggered the SSM CS=UP rule. Keep in mind that you can also use the OPS7914T SSM audit message (SSMAUDIT parm = YES) to determine when a resource was updated. Sure, no triggering event in the log if NOOPSLOGing, but at least an indication of what rule and when the event occurred via OPS7914T.