SirSafe enhanced shared DASD enqueueing
SirSafe enhances the shared DASD enqueue mechanisms of Model 204 to better exploit Sysplex and multiple LPAR environments. The SIRENQ stand-alone utility allows members of a Sysplex or GRS ring to "see" each other, providing automatic recovery from a variety of shared DASD enqueueing conflicts that arise when Model 204 jobs are scheduled across multiple systems. Extended monitoring and administration facilities within the Model 204 environment simplify administration of Sysplex environments.
Global Resource Serialization (GRS)
Global Resource Serialization (GRS) allows two or more operating system instances to share information about serialized resources. GRS can be used to support ENQ/DEQ serialization between address spaces executing under different instances of an MVS operating system. GRS is mandatory between members of a Sysplex, and it is optional between systems that are not members of the same Sysplex.
Once a GRS ring is established, ENQ/DEQ requests between all members of the ring can be serialized as if the entire ring were a single operating system image. The ENQ/DEQ services accept an argument that specifies the scope of the resource being enqueued:
| SYSTEM | The current ENQ/DEQ applies just to the current operating system instance. ENQ/DEQ requests with a scope of SYSTEM are not visible to other members of a GRS ring. |
|---|---|
| SYSTEMS | The current ENQ/DEQ applies to the GRS ring of the current system. ENQ/DEQ requests with a scope of SYSTEMS are not considered to be the same as requests with a scope of SYSTEM. |
The mutual insulation of the ENQ/DEQ scopes means that all of the Model 204 instances executing on an operating system instance must use the same specification for scope. In practice, this can be very hard to ensure, and errors can compromise file integrity.
Fortunately, a GRSRNLxx parmlib member can be used to override the scope specificationfor ENQ/DEQ requests.
This makes it possible for all of the Model 204 file control ENQ/DEQ
requests on a system to be promoted from a scope of SYSTEM to a scope of SYSTEMS.
This is accomplished by the following entries in a GRSRNLxx member:
RNLDEF RNL(INCL) TYPE(GENERIC) QNAME(IFAMQA) RNLDEF RNL(INCL) TYPE(GENERIC) QNAME(IFAMQB) RNLDEF RNL(INCL) TYPE(GENERIC) QNAME(IFAMQC)
If the entries above are active for a particular instance of MVS, then all of the ENQ/DEQ requests used by Model 204 to serialize database file access will be promoted to the SYSTEMS scope.
This guarantees that the current Model 204 logic for shared DASD will continue to work, but in and
of itself, the promotion does not extend the functionality.
For more information on creating and maintaining GRS rings and promoting enqueues, refer to the following IBM publications:
- MVS Authorized Assembler Services Guide
- MVS Planning: Global Resource Serialization
- MVS Initialization and Tuning Reference
SIRENQ
The SIRENQ utility is designed to be run as a started task or batch job under all of the MVS instances that can host Model 204 jobs. Its purpose is to let each Model 204 instance determine if it is a member of a Sysplex or GRS ring, and if so, to determine the other members of the ring that are promoting IFAMQx enqueues. Model 204 can then treat all systems so identified as a single system image, performing automatic cleanup of obsolete shared DASD enqueue list entries.
SIRENQ's unified view of Model 204 instances and shared DASD cleanup provides significant benefit to Sysplex and GRS ring members, while it still maintains the usefulness of the current shared DASD approach for other systems (for example, for a monoplex used for testing).
SIRENQ installation and operation is summarized in SirSafe SIRENQ utility.
SIRENQ establishes three special enqueues, each with a scope of SYSTEM:
IFAMQA MODEL204.SIRENQ.smfid IFAMQB MODEL204.SIRENQ.smfid IFAMQC MODEL204.SIRENQ.smfid
Where smfid is the SMF system ID for the current system.
SIRENQ then uses the GQSCAN system service to build a list of all MVS instances that have enqueues on these resources with a scope of SYSTEMS.
By examining the last portion of the resource name, SIRENQ can
determine if the IFAMQx enqueues from other systems will be "visible."
SIRENQ wakes up periodically (default sleep interval is five minutes) to recheck its view of the GRS environment and update its list of other MVS instances running SIRENQ. SIRENQ also produces informational messages to the operator's console when other MVS instances either become visible or cease to be visible.
All systems that are "SIRENQ visible" to the current system are considered
to be the same system for purposes of deleting obsolete shared DASD enqueue list entries.
For example, if a Model 204 instance is running on system V210 with a copy of SIRENQ,
and SIRENQ is also running on another GRS ring member with an SMF system ID of Z140,
the first instance automatically detects and deletes any obsolete enqueue entries for Z140.
This is possible because the Model 204 instances on V210 know that their
ENQ/DEQ calls have been promoted to the SYSTEMS scope, and they also know that the ENQ/DEQ calls on Z140 have been promoted.
Further, Model 204 instances on the two systems know that the GRS ring between the two instances is functional.
Note that if a third system is either not in the GRS ring or
does not have a copy of SIRENQ active,
then any Model 204 instance running on that system will not be able to detect
obsolete entries from V210 or Z140, and those systems in turn will not be able to detect obsolete entries from the third system.
However, no loss in file integrity will result from sharing files among the three systems.
The AUTHCTL command under SirSafe is enhanced to better support the monitoring and management of shared DASD enqueueing within Model 204.
AUTHCTL VIEW indicates whether enhanced shared DASD enqueueing is active, and if so, it lists the systems that are visible and those that have become invisible:
*** MSIR.0688: SirSafe enhanced shared DASD active on V210 (SIRIJES2) *** MSIR.0689: SirSafe Shared DASD visible system: V210 (SIRIJES2) *** MSIR.0689: SirSafe Shared DASD visible system: + Z140 (SIRIUSZO) *** MSIR.0689: SirSafe Shared DASD visible system: - TEST (SIRITEST)
The above example shows that enhanced shared DASD enqueueing is active for the
current system, that the system Z140 has become visible since the last AUTHCTL VIEW or
AUTHCTL REFRESH, and the the system TEST was visible but is currently not visible.
Note that the eight-character "system name" is shown as well as the older
four-character SMF ID for each system.
Suppose that a Model 204 Online being tested under system TEST had several files open when the testing LPAR was reset.
Rather than track down all the obsolete shared DASD enqueue list entries and delete them with an ENQCTL command, a second copy of SIRENQ can be run on the V210
system, with an smfid parameter value of TEST.
This causes any Model 204 instance on V210 to automatically clear the obsolete entries from TEST.
While this second copy of SIRENQ is active, an AUTHCTL VIEW command yields:
*** MSIR.0688: SirSafe enhanced shared DASD active on V210 (SIRIJES2) *** MSIR.0689: SirSafe Shared DASD visible system: Z140 (SIRIUSZO) *** MSIR.0689: SirSafe Shared DASD visible system: TEST (SIRIJES2)
The presence of the system name makes it easy to spot duplicate copies of
SIRENQ that were used to facilitate recovery.
Note that if the system SIRITEST was restarted and rejoined the Sysplex or
GRS ring, then when it's copy of SIRENQ was started, the operator of
SIRITEST would receive an error notification indicating that SIRIJES2 was running a spoofing copy of SIRENQ.
Each Model 204 instance maintains its view of visible systems in an efficient manner. You can use the AUTHCTL REFRESH command to cause Model 204 to manually rebuild its view of visible systems:
AUTHCTL REFRESH [CLEAR]
The CLEAR option directs Model 204 to remove from its list any systems that were once visible, but are now invisible (that is, those entries preceded by a minus sign). If a Model 204 instance is started without a copy of SIRENQ running, then an AUTHCTL REFRESH command is required to enable enhanced shared DASD enqueueing.