Cross system rule updates when DASD not shared on MSF Connected Systems

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

We have been ‘tolerating’ an issue regarding viewing/updating rules from OPSVIEW 4.5.1. We are not in a shared DASD environment. Each sysplex has its own version of rules sets in the form of OPSA.OPS.*.RULES.  All systems are MSF connected. Thus, OPSA.OPS.MSG.RULES(ABC123) on system A (sysplex A), and OPSA.OPS.MSG.RULES(ABC123) on system B (sysplex B) are two ‘different/unique’ rules.

The issue is if we are on SYSTEM A in sysplex A, and access OPSVIEW 4.5.1 setting system to SYSTEM B, the View and Edit options manipulate the rule on the local system. Meaning, if on SYSTEM A looking at or updating rule ABC123 on SYSTEM B actually manipulates ABC123 on SYSTEM A. OPSVIEW 4.5.1 should generate an error for both View and Edit options in this case, indicating that the rule is ‘Not accessible’ or whatever. For the ‘View’ option the error message could actually  be ‘Use option 4.5.3 to view in-storage copy on remote systems’

This is not an impacting issue, but should be corrected as we don’t want to ‘assume’ some cross system update happened, when in fact it was done on the local system.

Environment

Release : 14.0

Component : OPS/MVS

Resolution

Unfortunately this is a function of ISPF, and not OPS/MVS. 

According to our product architect there is no way that OPS/MVS can detect when someone is attempting to update a different LPAR's dataset via the 4.5.1 panel when the same dataset name exists on both LPARs. 

The only recommendation that we can offer is to change the dataset name on the other LPAR so that the two ruleset names are unique.