Given two MVS™ systems, A and B, which do not share
DASD, fault entries that are created on system A can be copied automatically to system B for viewing
or reanalysis by using the Fault Analyzer ISPF
interface.
The entries are copied by using a Notification user exit on system A, which submits a TSO batch
job to transmit fault entries as PDS members to a dedicated user ID on system B. On system B, a
continually running batch TSO job receives fault entries into a staging data set. It then calls the
IDIUTIL batch utility to import the fault entry into
a local history file.
NFYEXIT is available in softcopy format as member IDISXNFY in data set IDI.SIDISAM1.
Notes:
❶
'nodeid' specifies the target system to which the fault entry is sent.
❷
'userid' specifies the user ID for which fault entries are received on the target system. Use this user ID solely to
receive fault entries.
❸
Ensure that the job card adheres to local standards.
❹
You can add checks here to see whether a fault is eligible to be sent to another system. The example shows how the
user ID or history file name can be used, but any fields in the ENV or NFY data areas can be checked.
This item is the name of the target history file in which the received fault entries are placed.
To select the history file that is based on where the fault originally occurred, see
❾.
❻
This item is a staging data set that is used for the TSO receive command and from
which fault entries are imported into the target history file.
Important: Do not use a
preallocated data set. Let the exec allocate and delete this staging data set for each fault
received, as shown in the sample provided.
For the IDIROBOT exec and IDIUTIL IMPORT processing to work, the staging data set
must never be used as a regular history file and must never contain more than a single member. If it
is used as a regular history file (for example, if it is displayed using the Fault Entry List
display, or used as the target of an IDIUTIL FILES
or LISTHF control statement), then a $$INDEX member will likely be created, which will cause the
processing not to work. Also, it is possible that the data set becomes IDIS subsystem managed, which will
subsequently result in serialization issues.
By ensuring that the staging data set only exists
for the duration of the receive and IMPORT processing, the possibility that these issues will occur
is eliminated.
❼
The IDIROBOT exec enters a WAIT state to
preserve resources between checking for fault entries to be received. The time interval in number of
seconds between receiving fault entries can be specified here. All fault entries on the JES output
queue for the chosen user ID are received, then the IDIROBOT exec enters the WAIT.
❽
If you set the RFRDSN, XDUMPDSN, and SDUMPDSN options to valid data set name patterns in the IDIOPTLM configuration-options load
module, there is no need to use the IDIROBEX user exit. (See Customize Fault Analyzer by using an IDIOPTLM configuration-options module.) In this case, set "use_exit" to 'N'.
If you use the IDIROBEX user exit,
any dump data set names provided by the exit override the equivalent option setting in IDIOPTLM.
❾
The sample exec uses only a single target history file for all received fault entries. It is
possible to assign a target history file that is based on one of these items:
The original history file name (in variable 'dsn').
The sending user ID (in variable 'fromid').
The node ID from where it was sent (in variable 'node'),
Important: Ensure that the user ID under which the IDIROBOT exec is running (in this example, the submitter
of the IDISTSOB job) has update access
to both the staging data set and all history files used as targets for imports.
Because the
IDIROBOT exec never exits, the IDISTSOB job executes indefinitely. However, the exec causes
the job to enter a WAIT state between attempts to receive incoming data to prevent using unnecessary
resources. To end the job, use the MVS™ CANCEL command during a
period of inactivity. Alternatively, the exec could be made to recognize a special file that if sent
to the selected user ID could trigger the exit to terminate.
A started task could be defined
instead to execute this JCL in order to prevent tying up a JES initiator.