SirSafe SIRENQ utility: Difference between revisions
m (misc cleanup) |
m (1 revision: SirSafe pages) |
(No difference)
|
Latest revision as of 21:32, 30 November 2016
The SIRENQ utility is designed to be run as a started task or batch job under all the MVS instances that can host Model 204 jobs. SIRENQ performs three functions that significantly enhance the operation of Model 204 in Sysplex and multiple LPAR installations:
- Verifies that Model 204 database file enqueues are automatically promoted from the
SYSTEM
scope to theSYSTEMS
scope on the current MVS instance. - Establishes an enqueue that can be "seen" by other members of a Global Resource Serialization (GRS) ring.
- Monitors and reports to the operator the other visible instances of SIRENQ.
For additional details about SIRENQ, see the SIRENQ section in the discussion of SirSafe enhancement of shared DASD enqueueing.
Installation
SIRENQ is distributed as a single object deck, which may be downloaded as directed by Technical Support or included on a product distribution tape.
SIRENQ must be linkage edited with AMODE(31)
. Also, RMODE(ANY)
is suggested.
SIRENQ does not require APF authorization.
The following job could be used to linkage edit SIRENQ:
//LINKENQ JOB CLASS=A,MSGCLASS=A //* //* LINK SIRENQ INTO SIRENQ.V101.LOAD, WHICH DOES //* NOT NEED TO BE APF-AUTHORIZED //* //LINK EXEC PGM=HEWLKED,REGION=0M, // PARM='LIST,LET,MAP,NCAL,SIZE=(2048K,512K),AC=0' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=VIO,SPACE=(3200,(300,150)) //SYSLMOD DD DSN=SIRENQ.V101.LOAD,DISP=SHR //SYSLIN DD * <b><insert SIRENQ object deck></b> ENTRY SIRENQ NAME SIRENQ(R) /* //
Before SIRENQ can be used, a GRSRNLxx
parmlib member must be modified and
activated to override the scope specification for the enqueue requests used by Model 204.
This is accomplished by adding 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)
Executing SIRENQ
SIRENQ can be invoked as a started task or a batch job, depending upon local preference. If the current configuration does not correctly promote the enqueues used by Model 204, SIRENQ issues an error message and terminates.
SIRENQ consumes very few system resources, although it does maintain three exclusive
enqueues that are issued with a scope of SYSTEM
and promoted to scope of SYSTEMS
:
IFAMQA MODEL204.SIRENQ.smfid IFAMQB MODEL204.SIRENQ.smfid IFAMQC MODEL204.SIRENQ.smfid
Where smfid is the SMF system ID for the current system, or the value of the SMFID parameter (described below).
The following JCL could be used to invoke SIRENQ, assuming it had previously
been linkage-edited into the data set identified by STEPLIB
:
//SIRENQ JOB ,'SIRSAFE SHARED DASD',CLASS=A,MSGCLASS=A //* //* FIRE UP SIRENQ //* //TEST EXEC PGM=SIRENQ,REGION=1024K //STEPLIB DD DSN=SIRENQ.V101.LOAD,DISP=SHR //
SIRENQ accepts the following parameters from the PARM
field of its EXEC
statement:
INTERVAL=nnn | Number of minutes to wait before re-scanning for visible systems.
The default is 5 minutes, sufficient for avoiding 522 ABENDs, while still noticing systems enteringand leaving the GRS ring.
A value of |
---|---|
SMFID=cccc | If specified, this parameter provides the SMF system ID to be used by this copy of SIRENQ. If not specified, the SMF system ID of the current system is used. This is useful in certain hot recovery environments to avoid the need for ENQCTL commands to clear obsolete shared DASD enqueues. |
Operation
SIRENQ listens for operating system STOP
or MODIFY
commands.
If a STOP
command is received, SIRENQ drops its enqueues, and it exits, causing the current OS/390 instance to become invisible.
SIRENQ processes the following MODIFY
commands:
REFRESH | Immediately rebuild the list of SIRENQ copies seen on other systems, without waiting for the completion of the current time interval, if any. |
---|---|
EOD or EXIT | Processed as a STOP command: immediately drop the enqueues and exit. |