Configuring DASD connected trackers to avoid tracking problems

Resolving The Problem

Rules for DASD connected trackers (TRROPTS parameter HOSTCON(DASD) )


1. Every CONTROLLER and every TRACKER requires its very own, unique
EVENT DATASET, which it references via the EQQEVDS DD statement.

In other words, you should *NEVER* have any two EQQEVDS DD cards
with the same DSN. The CONTROLLER EQQEVDS is used only for a
function called SUBMIT CHECKPOINTING, so it can be very small...
whatever you minimum allocation is.

2. Your CONTROLLER should have an EQQEVDnn DD statement for each
DASD-connected TRACKER, and the DSNs in those statements should
match the DSNS in the TRACKER EQQEVDS statements.

The TRACKERs WRITE to their EQQEVDS datasets, and the CONTROLLER
READS from the matching EQQEVDnn DDname. This provides a data
path FROM each TRACKER TO the CONTROLLER.

3. The CONTROLLER must have OPCOPTS ERDRTASK() set to the number of
DASD CONNECTED TRACKERS (and the number of EQQEVDnn DD statements).

A separate EVENT READER subtask is started for each TRACKER, and
is associated with a specific EQQEVDnn dataset via the ERDROPTS
ERSEQNO().

4. You NEVER need an EQQEVDnn DD statement in a TRACKER proc, and you
NEVER need set ERDRTASK() to non-zero value in the TRACKER parms.

5. If a DASD-connected TRACKER is in a different JES-PLEX than the
CONTROLLER, or if you want to define an STC or WTO workstation on a
specific system within your JESPLEX (other than the system on which
the CONTROLLER runs), you must set up a data path from the CONTROLLER
to the TRACKER. To do this:

A: Add an EQQSUDS DD statement to the TRACKER proc, pointing at a
SUBMIT-RELEASE DATASET. Like EVENT DATASETS, S/R DATASETS must
be unique for each TRACKER.

B. In the TRACKER init parms, set EWTROPTS SUREL(YES) to tell the
TRACKER it must READ that dataset.

C. Add a DD statement to the CONTROLLER proc with the DSN of the
S/R dataset. The DDNAME is user-selected, but general convention
is xxxxSURE -- Where "xxxx" is something to allow you to associate
that dataset with the TRACKER in question.

D. Code the DASD() keyword in the CONTROLLER ROUTOPTS statement to
contain the DESTINATIONS (S/R DDNAMES) of each DASD-connected
TRACKER

E. If you want to be able to tell OPC to send scheduled work directly
to a given tracker to be submitted, define a CPU workstation and
set its DESTINATION to the DDNAME of the S/R DATASET for that
TRACKER in the CONTROLLER proc and the ROUTOPTS.


Some JCL examples to clarify the above statements:

TRACKER1 on same LPAR as controller, no submit/release dataset:

//EQQEVDS DD DSN=TWS.EV.TRACKER1,DISP=SHR

TRACKER2 on remote LPAR, using submit/release dataset:

//EQQEVDS DD DSN=TWS.EV.TRACKER2,DISP=SHR
//EQQSUDS DD DSN=TWS.SU.TRACKER2,DISP=SHR

CONTROLLER with TRACKER1 and TRACKER2:

//EQQEVDS DD DSN=TWS.EV.CONTROLR,DISP=SHR
//EQQEVD01 DD DSN=TWS.EV.TRACKER1,DISP=SHR
//EQQEVD02 DD DSN=TWS.EV.TRACKER2,DISP=SHR
//CPU2SURE DD DSN=TWS.SU.TRACKER2.DISP=SHR