DATA SET TRIGGERS and SPECIAL RESOURCE ETT with GDGs

Resolving The Problem

DATASET TRIGGERING is a TWSz (MAINFRAME ONLY) TRACKER function that monitors SMF14, SMF15, and SMF64 records via the TRACKER subsystem and code in the IEFU83 SMF exit, and creates a SPECIAL RESOURCE STATUS CHANGE EVENT when there is a match on a DATASET NAME in an SMF record and an entry in that TRACKERs EQQDSLST.

SPECIAL RESOURCE EVENT TRIGGERED TRACKING is a TWSz (MAINFRAME ONLY) CONTROLLER function that monitors all SPECIAL RESOURCE STATUS CHANGE events received from ALL the connected TWSz TRACKERS and adds an occurrence of a specified APPLICATION into the CURRENT PLAN when there is a match between the SPECIAL RESOURCE name in an incoming event and a SPECIAL RESOURCE TRIGGER NAME in the ETT specifications (TWSz ISPF dialog function 1.7).

When the DATASET TRIGGERING code in the TRACKER subsystem recognizes that the DATASET NAME in an SMF record is a GDG, it strips out the LOW LEVEL QUALIFIER from that dataset name and matches ONLY on the GDG BASE name. Also, the SR STATUS CHANGE EVENT (the SYY event) is created with only the GDG BASE name.

However, if the DATASET NAME is NOT recognized as a GDG, then the fully qualified dataset name is used in the match, AND is also included in any SYY event that may be created. (The EQQLSENT macros which define the EQQDSLST can be coded to read only a portion of the dataset name)... thus allowing a basic level of "generic" matching).

To ensure that TWSz correctly recognizes all GDGs, regardless of how created or manipulated, it is **STRONGLY** recommended that all users code the GDGNONST(YES) option in their TRACKER OPCOPTS initialization statement:

>
> OPCOPTS GDGNONST(YES)
>

NOTE:

Since TWSz V8R3, "yes" is the default value of the GDGNONST() parameter. The parameter was retained so that existing users with unique implementations could migrate to TWSz V8R3 without changing those implementations. However, most TWSz users should use the default, GDGNONST(YES).

On the CONTROLLER side, SPECIAL RESOURCE ETT processing matches the SPECIAL RESOURCE name in the incoming SYY event with the TRIGGERING EVENT name in the ETT table. Again GENERIC MATCHING is allowed, but it is strongly recommended that if the triggering dataset is a GDG, that the ETT definition contain ONLY the GDG BASE name.

Generic matching on GDGs is unnecessary, and incurs significant additional CONTROLLER overhead as compared to an exact match. Also, if a generic match is not coded correctly, there will be NO match, and ETT processing will not occur.

For instance, if an GDG dataset defined as a DATASET TRIGGER is named:

>
> PP.NIMO.NONRES.BILLED
>

Then each generation of that dataset will have a fully qualified dataset name in the format:

>
> PP.NIMO.NONRES.BILLED.G0021V00
>

DATASET TRIGGERING recognizes the dataset as a GDG, and omits the "GOOVOO" LLQ from the SYY event.

Thus the ETT definition in the CONTROLLER must match on the BASE GDG name:

>
> PP.NIMO.NONRES.BILLED
>

A triggering event name of:

>
> PP.NIMO.NONRES.BILLED.**
>

Will **NOT** match because the CONTROLLER code will be looking for at least a period (dot --".") character following the BILLED qualifier, and that character will NOT be in the SYY event.

So in summary, when using GDGs as TWSz DATASET TRIGGERS:

1. Always specify ONLY the GDG BASE dataset name as the TRIGGERING EVENT NAME in the CONTROLLER ETT definition, and

2. Always set TRACKER OPCOPTS keyword GDGNONST(YES). (Or allow it to default to that value).