Can OPS/MVS be set to detect events but not execute commands

[Kevin Kinney]

I need to test a new release of OPS/MVS.  I want to verify the rules are detecting triggering events, but I do not want to execute the commands in response to those events.
This should allow the new release to run in parallel with the old.

Is there a function like that?

[Marcel van Ek]

If you still want to go that path and are only talking about z/OS commands, you may want to create an OPSCMD security rule in your test ops that refuses  any command coming from that OPS instance (SSID)
I honestly have no idea what will happen if that result clashes with another possible sec rule on your prod innstance (OPSS)....

------------------------------
Automated Operations
Atos
Netherlands
------------------------------

[Marcel van Ek]

Well, before that I commented why running two active OPS/MVS instances sharing the same rules is never a good idea: apart from commands, you'll also mess up any variables that will be processed twice, AE bits that may be set unexpectedly, EPI sessions that will get stuck and so on.

What we do is bring up s second instance (OPST), running from different install libs and NO rules active, to be able to test the ISPF environment and maybe run a rexx in OPST that tests needed OPS functions. You'll have to deal with the 2 different load libraries though, which may be cumbersome (esp if run from linklist)

------------------------------
Automated Operations
Atos
Netherlands
------------------------------

[Dave Gorisek]

For any Host environment 'action', you can use Address Message, and the action/command will just be echoed and not issued. So if you are just testing a limited number of rules that are issuing commands (Address OPER) pgms (Address OSF) SQL updates (Address SQL),etc you can replace with Address Message and the command will just be echoed into the OPSLOG and not issued. This is an effective approach during any type of initial rule/pgm testing, but I agree with Marcel that it is not a real effective way to perform the testing of a new release of the product. While some side by side testing can be done (OPSS with running libraries and OPST with new libraries), the true test comes with just running with the new maintenance. Ideally, if you utilize the SSM component, when you IPL and start OPS for the first time using the maintenance, the function of SSM itself is a good initial test to determine if you can proceed with the new release or need immediately back off the maintenance. If there is some issue with rules triggering, commands not being issued, variables not set, SYSCHK1 access, pgms triggered, etc which are some actions of SSM rules/pgms/internal functions, then you'll now sooner than later that you need to back off.

[Marcel van Ek]

Another good idea would be to use the MAINPRM option, so you can start your OPS environment depending on the parm you define, like:
S OPSMAIN,MAINPRM='TEST'
and in your AOFINITREXX rexx (assuming you use that) you could verify the MAINPRM value and if it contains TEST, decide not to enable any rules , use another ruleset prefix, or anything you can come up with.

------------------------------
Automated Operations
Atos
Netherlands
------------------------------

[Marcel van Ek]

Hi Kevin, I don't think there's anything simple like that. Plus you may want to prevent any rexx execs running on servers and having 2 instances of OPS/MVS running with all rules active will definitely mess up any variable handling in your automation.  (and likely some more)
You CAN startup a second instance (OPST or something) with NO rules active, just to test the basics , like ISPF interface and test opsfunctions from a test rexx towards subsys OPST. You'll have to deal with the 2 different load libs if running from linklist... you may find incompatibility issues.

------------------------------
Automated Operations
Atos
Netherlands
------------------------------

[Kevin Kinney]

Thank you for your suggestions. You've confirmed what I found (or didn't find) in the documentation.

I have set up a second instance and have tested some of the supplied sample rules. I was hoping for a more complete test of our current rules before putting it into production.

Thank you again.

Next out of office - 8/26/22
Kevin C. Kinney | Technical Analyst
400 Broadway | Cincinnati, Ohio 45202
513.629.7488 direct
513.629.1787 fax
WesternSouthern.com<https: www.westernsouthern.com/="">

[http://wsintranet.ws.wsfgrp.net/intranet/cms/images1/sig-wsfgrp-logo.jpg]
[http://wsintranet.ws.wsfgrp.net/intranet/cms/images1/sig-facebook.jpg]<https: www.westernsouthern.com/signaturelink1=""> [http://wsintranet.ws.wsfgrp.net/intranet/cms/images1/sig-twitter.jpg] <https: www.westernsouthern.com/signaturelink2=""> [http://wsintranet.ws.wsfgrp.net/intranet/cms/images1/sig-linkedin.jpg] <https: www.westernsouthern.com/signaturelink4=""> [http://wsintranet.ws.wsfgrp.net/intranet/cms/images1/sig-pinterest.jpg] <https: www.westernsouthern.com/signaturelink5=""> [http://wsintranet.ws.wsfgrp.net/intranet/cms/images1/sig-instagram.jpg] <https: www.instagram.com/westernandsouthern/=""> [http://wsintranet.ws.wsfgrp.net/intranet/cms/images1/sig-youtube.jpg] <https: www.westernsouthern.com/signaturelink6="">
This email and any attachments to it are confidential and intended solely for the individual or entity to whom it is addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you have received this email in error, please contact the sender by reply email and destroy all copies of the original message.