OPS/MVS

  • 1.  Cumulative message count across LPARs in a PLEX

    Posted 10-20-2021 11:21 AM
    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


  • 2.  RE: Cumulative message count across LPARs in a PLEX

    Broadcom Employee
    Posted 10-21-2021 09:03 AM
    Hi Chris,

    Set the OPS/MVS parameter, GLVNOTIFYRULES, to YES to cause GLV events when Sysplex Variables are updated.  So your #1 idea should work with this in place.

    Regards,
    Tyrone​


  • 3.  RE: Cumulative message count across LPARs in a PLEX

    Posted 10-25-2021 05:20 PM
    Thanks Tyrone, I have tested the GLV rule for use with Sysplex Globals and it works fine, Not sure if the manual has been updated for v 14.


  • 4.  RE: Cumulative message count across LPARs in a PLEX

    Posted 10-22-2021 09:43 AM
    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


  • 5.  RE: Cumulative message count across LPARs in a PLEX

    Posted 10-25-2021 05:28 PM
    Dave you have great ideas, I am having to rig the processes you are advocating, please put in an RFE and I will definitely vote for it.   We are looking a cumulative of 30 msgs in 30 min, they are not redundant on each lpar, so that spares having to monitor which system the message comes from.   Fortunately in this instance the message is not redundant so tracking the system that creates the alert will not be a concern, but I can see in the future where we will probably need to perform some kind of tracking, maybe create the variable with the first system as the last node, perform a GETLIKE and increment that, then just ship the alert on the first system that captured the message.

    Thanks everyone
    Chris Allamon
    NFCU


  • 6.  RE: Cumulative message count across LPARs in a PLEX

    Posted 10-26-2021 08:18 AM
    I've voiced/submitted this MSGPLX and other possible sysplex tool enhancements (TODPLX, GLVPLX, OPSTHRSH() Plex option, etc) before, so if CABC wants some more thoughts on the ideas they know where I'm at! Your comment about possible 'future' logic to track what system the plex event occurred on - within the GLV rule, you can interrogate the GLV.SYNA environmental variable. This will have the value of the sysplex system that last updated the plex variable.