Its been a while since I played with sysplex variable tools, so not sure if any of my thoughts on how they used to work are still valid here. Perhaps improvements or changes that I'm not aware of on this topic. Using a )GLV rule to fire on all the updates occurring in the sysplex is good in that you will be able to use the OPSTHRSH() to incorporate the 30 times in 30 mins, but some code/plumbing here to ensure only 'one' GLV fires. One option is to enable only on one sysplex system. Issue here is you'll need some code to ensure it is 'always' active on one system in the plex. Meaning if you enable only on SYSA,need to handle if SYSA goes away. Another option is to enable on all sysplexes, and then have some logic to check some value of 'all done' or whatever to tell the logic not to fire after performed. Also, keep in mind that you cannot use the OPSVASRV() in )MSG rules. While there is an end-around that I wont share because you could cause other issues (hangs in asids firing the rules), your )MSG DB2msg rule will have to call an OPS/REXX pgm to update/increment the sysplex variable. Since you have to create a pgm to update, I would probably just have the pgm do 'all the work', eliminating the )GLV rule. Thus keeping the 'logic/plumbing' in one place. The pgm would utilize the OPSENQ() function on a SYSTEMS enqueue where needed to ensure that the 'action' (such as doing the work when condition is met) is only done on one system in the plex. The threshold logic (x times in y mins), can be done by either manipulating the date/time info when the plex var was created (obtainable via OPTIONS(STATS) on the OPSVASRV GET command), or logic that utilizes the DATE2SEC function to create threshold logic via a date/timestamp value and that can be stored in the variable too (set var value to 'cnt timestamp'). The OPS4402O sample rule demonstrates using DATE2SEC if needed and you go this route.
Lastly, this area (firing on syplex activity/events) is in the need of more effective out-of-the-box/internal drop in tools from the product. This of course not only to optimize the automation, but eliminate the need of having to code alot of end-user logic to ensure all the i's are dotted, and t's are crossed. Ideally some parms or other magical way of telling OPS to 'flow abcdef sysplex events' through something like a )MSGPLX rule processed by some new asynchronous task. Have the task communicate to all the tasks in the plex to 'do whatever is necessary' such as ensure only enabled on one syplex. Enhance the OPSTHRSH() to process a plex var counter in a )MSGPLX rule or even some internal msgplx.vars to do the needed threshold logic, etc... bottom line 'internal' improvements would be a big help!
Would greatly welcome....
)MSGPLX DB2msg
)Proc
plxcnt = OPSTHRSH('P','1800') /* P for plex threshold using plex variable*/
if plxcnt = '30' then
do
/* action here */
end
Original Message:
Sent: 10-20-2021 11:20 AM
From: Chris Allamon
Subject: Cumulative message count across LPARs in a PLEX
Need some ideas, We have shared workload DB2's on 3 LPARs in a plex. I have been asked to monitor for a specific message and when it is created 30 times within 30 minutes across all 3 LPARs, alert the support staff. We are on version 13.5 of OPS.
1st thought was use )GLV and monitor a sysplex variable, but from the manual, it does not appear that the )GLV rule will monitor sysplex variables. If it does, problem solved.
2nd thought, create a rule on each LPAR to update a standard global variable on one system and have a )GLV rule monitor that, I will just need to designate a hierarchy of systems so that if one is not available it cascades to the next. I don't want to update one global on all 3 LPARs so that there is less of a possibility of creating multiple alerts.
Any other ideas or thoughts on the best way to accomplish this? Unless plex variables can be monitored, #2 seems the most likely, just looking to see if anyone has a better/easier way to perform this task?
Thank you
Chris Allamon
NFCU