Admin: 1 revision: SirSafe pages

2016-11-30T21:32:41Z

1 revision: SirSafe pages

← Older revision	Revision as of 21:32, 30 November 2016
(No difference)

JAL: link repair

2016-11-30T21:09:14Z

link repair

New page

<var class="product">SirSafe</var> enhances the shared DASD enqueue mechanisms of <var class="product">Model 204</var> to better exploit
Sysplex and multiple LPAR environments.
The <var class="product">SIRENQ</var> 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 <var class="product">Model 204</var> jobs are scheduled across multiple systems.
Extended monitoring and administration facilities within the <var class="product">Model 204</var> 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:
<table class="thJustBold">
<tr><th>SYSTEM</th>
<td>The current ENQ/DEQ applies just to the current operating system instance. ENQ/DEQ requests with a scope of <code>SYSTEM</code> are not visible to other members of a GRS ring.</td></tr>

<tr><th>SYSTEMS</th>
<td>The current ENQ/DEQ applies to the GRS ring of the current system. ENQ/DEQ requests with a scope of <code>SYSTEMS</code> are not considered to be the same as requests with a scope of <code>SYSTEM</code>.</td></tr>
</table>
The mutual insulation of the ENQ/DEQ scopes means that all of the <var class="product">Model 204</var> 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 <code>GRSRNLxx parmlib</code> member can be used to override the scope specificationfor ENQ/DEQ requests.
This makes it possible for all of the <var class="product">Model 204</var> file control ENQ/DEQ
requests on a system to be promoted from a scope of <code>SYSTEM</code> to a scope of <code>SYSTEMS</code>.
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 <var class="product">Model 204</var> to serialize database file access will be promoted to the <code>SYSTEMS</code> scope.
This guarantees that the current <var class="product">Model 204</var> 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:
<ul>
<li>MVS Authorized Assembler Services Guide </li>

<li>MVS Planning: Global Resource Serialization </li>

<li>MVS Initialization and Tuning Reference </li>
</ul>

==SIRENQ==
The <var class="product">SIRENQ</var> utility is designed to be run as a started task or batch job under all of the
MVS instances that can host <var class="product">Model 204</var> jobs.
Its purpose is to let each <var class="product">Model 204</var> 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.
<var class="product">Model 204</var> can then treat all systems so identified as a single system image,
performing automatic cleanup of obsolete shared DASD enqueue list entries.

<var class="product">SIRENQ</var>'s unified view of <var class="product">Model 204</var> 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).

<var class="product">SIRENQ</var> installation and operation is summarized in [[SirSafe SIRENQ utility]].

<var class="product">SIRENQ</var> establishes three special enqueues, each with a scope of <code>SYSTEM</code>:
IFAMQA MODEL204.SIRENQ.smfid
IFAMQB MODEL204.SIRENQ.smfid
IFAMQC MODEL204.SIRENQ.smfid

Where <var class="term">smfid</var> is the SMF system ID for the current system.
<var class="product">SIRENQ</var> then uses the GQSCAN system service to build a list of all MVS instances that have enqueues on these resources with a scope of <code>SYSTEMS</code>.
By examining the last portion of the resource name, <var class="product">SIRENQ</var> can
determine if the IFAMQx enqueues from other systems will be "visible."

<var class="product">SIRENQ</var> 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 <var class="product">SIRENQ</var>.
<var class="product">SIRENQ</var> also produces informational messages to the operator's
console when other MVS instances either become visible or cease to be visible.

==Modified shared DASD list maintenance==
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 <var class=product>Model 204</var> instance is running on system <code>V210</code> with a copy of <var class="product">SIRENQ</var>,
and <var class="product">SIRENQ</var> is also running on another GRS ring member with an SMF system ID of <code>Z140</code>,
the first instance automatically detects and deletes any obsolete enqueue entries for <code>Z140</code>.

This is possible because the <var class="product">Model 204</var> instances on <code>V210</code> know that their
ENQ/DEQ calls have been promoted to the <code>SYSTEMS</code> scope, and they also know that the ENQ/DEQ calls on <code>Z140</code> have been promoted.
Further, <var class="product">Model 204</var> 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 <var class="product">SIRENQ</var> active,
then any <var class="product">Model 204</var> instance running on that system will not be able to detect
obsolete entries from <code>V210</code> or <code>Z140</code>, 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.

==Controlling shared DASD enqueueing==
The [[SirSafe command and function reference#AUTHCTL|AUTHCTL command under SirSafe]] is enhanced to better support the
monitoring and management of shared DASD enqueueing within <var class="product">Model 204</var>.

<var>AUTHCTL VIEW</var> indicates whether enhanced shared DASD enqueueing is active, and if so, it lists the systems that are visible and those that have become invisible:
<nowiki>*** 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)
</nowiki>
The above example shows that enhanced shared DASD enqueueing is active for the
current system, that the system <code>Z140</code> has become visible since the last <var>AUTHCTL VIEW</var> or
<var>AUTHCTL REFRESH</var>, and the the system <code>TEST</code> 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 <var class="product">Model 204</var> Online being tested under system <code>TEST</code> 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 <var>ENQCTL</var> command, a second copy of <var class="product">SIRENQ</var> can be run on the <code>V210</code>
system, with an <var class="term">smfid</var> parameter value of <code>TEST</code>.
This causes any <var class="product">Model 204</var> instance on <code>V210</code> to automatically clear the obsolete entries from <code>TEST</code>.
While this second copy of <var class="product">SIRENQ</var> is active, an <var>AUTHCTL VIEW</var> command yields:
<nowiki>*** 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)
</nowiki>
The presence of the system name makes it easy to spot duplicate copies of
<var class="product">SIRENQ</var> that were used to facilitate recovery.
Note that if the system <code>SIRITEST</code> was restarted and rejoined the Sysplex or
GRS ring, then when it's copy of <var class="product">SIRENQ</var> was started, the operator of
<code>SIRITEST</code> would receive an error notification indicating that <code>SIRIJES2</code> was running a spoofing copy of <var class="product">SIRENQ</var>.

Each <var class="product">Model 204</var> instance maintains its view of visible systems in an efficient manner.
You can use the <var>[[SirSafe command and function reference#AUTHCTL REFRESH|AUTHCTL REFRESH]]</var> command to cause <var class="product">Model 204</var> to manually
rebuild its view of visible systems:
AUTHCTL REFRESH [CLEAR]

The <var>CLEAR</var> option directs <var class="product">Model 204</var> 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 <var class="product">Model 204</var> instance is started without a copy of <var class="product">SIRENQ</var> running, then an <var>AUTHCTL REFRESH</var>
command is required to enable enhanced shared DASD enqueueing.

==See also==
{{Template:SirSafe topic list}}

[[Category:SirSafe]]

SirSafe enhanced shared DASD enqueueing - Revision history

Admin: 1 revision: SirSafe pages

JAL: link repair