SirSafe SIRENQ utility

From m204wiki
Jump to navigation Jump to search

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 the SYSTEMS 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 0 eliminates the timer, and SIRENQ just waits for a MODIFY or STOP command from the operator.

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.

See also