Best Practice for making rules LPAR specific.

[adavidson]

Hi Community Members,

 

We run OPS/MVS on 3 LPARS. I would like to hear what are other community member’s thoughts on isolating OPS/MVS rules to one LPAR, even if those rules have the same function? This meaning that there would be 3 total rules for the same function but they are each limited to the LPAR they are defined to.

 

We are entertaining this idea in order to reduce risk of impacting production in the event a rule needs changed.

 

Also, to go along with this idea and further isolate dev & non-prod & production from each other, what is everyone’s thought on possibly having different prefix names for OPS/MVS rules for the different LPARS?

 

Thanks everyone in advance for your input. I greatly appreciate it.

[SAL COSTANZO]

We keep production lpars and test lpars with differrent Hilevel qualifiers, but once tested, it is copied from test to prod, so the rules are identical. (so 2 sets of rules datasets for all the LPARS)

 

We use the )INIT section if we want to restrict the rule from starting/stopping on different LPARS (obviously you need to put in the correct check/syntax)

 

IF TESTLPAR() THEN RETURN REJECT

IF WORDPOS(lpar,'A B C') = 0 THEN RETURN REJECT   - just run on lpars A B and C

 

With the above, we make sure AUTOENABLE is turned on everywhere, but the rule doesn't enable on the lpars you dont want it to run on.

 

You can then further refine if you want different behavior for the same rule on each lpar - one way would be do use a SELECT statement - WHEN LPAR = A THEN DO...

I would stick with one rule to handle all the LPARS  - much easier to maintain, but I guess if the automation is critical enough you can separate into one rule per lpar with same function (but I think that would be rare.)

 

Hope that helps!

[Anon Anon]

Here is the code we use in our INIT section. For tracking purposes, which is probably overkill, each rule issues a WTO when enabled or disabled. While the WTO may be overkill, I will say it has come in very handy when coding and debugging a rule as you can easily see when the rule was disabled and enabled in the log so you know where to look for any responses or other diagnostic information. I also have a rule which will highlight any message with "ABLE00" on the end.

curr_system = OPSINFO('SYSNAME')            /* The Current System     */

exec_system = "XXXX"                        /* The Desired System     */

curr_rule = OPSINFO('PROGRAM')              /* The Current Rule       */

 

 

IF curr_system = exec_system THEN DO

   z = OPSVALUE('GLOBAL1.ENABLE.RULE.'curr_rule,'U','TRUE')

   wto_txt.1 = "Rule" OPSINFO('PROGRAM') "is enabled."

   msg_id = "ENABLE00"

   ADDRESS WTO "TEXTVAR("wto_txt.") MSGID("msg_id")"

   RETURN 'ACCEPT'

END

ELSE DO

   z = OPSVALUE('GLOBAL1.ENABLE.RULE.'curr_rule,'U','FALSE')

   wto_txt.1 = "Rule" OPSINFO('PROGRAM') "will not be enabled."

   msg_id = "DEABLE00"

   ADDRESS WTO "TEXTVAR("wto_txt.") MSGID("msg_id")"

   RETURN 'REJECT'

END

[Robert Bullock]

We also use the selective ENABLE method.  One more coding example.

 

)INIT                                                                  

/* ONLY FIRE THE RULE ON CERTAIN SYSTEMS*/                     

sys = OPSINFO('SYSCLONE')                                              

recsys = "7A 7B 7D"                                                    

IF WORDPOS(sys,recsys) > 0 THEN RETURN 'ACCEPT'                        

ELSE RETURN 'REJECT'

 

With over 80 LPARs this is used a lot...