DFHZC2405 E date time applid termid tranid Node netname not activated. sense ((instance) Module name: {DFHZSIM | DFHZSIM | DFHZSIM | DFHZSIM | DFHZSIM | DFHZSYX | DFHZSYX | DFHZSYX | DFHZSIX | DFHZSYX | DFHZSYX})

Explanation

The node was not activated, or was deactivated by the network operator, or a generic resource affinity already exists with another system in the same generic resource.

Instance 6 - If the partner is a member of a generic resource (TOR2) and this system (AOR) is not and an affinity already exists between the AOR and another member of the same generic resource (TOR1) because TOR1 crashed, then VTAM has indicated that you cannot acquire this connection. This imbed is inserted in DFHZC xxxx messages with sense inserts. For the meaning of sense , see message DFHZC2400.

System action

All outstanding SEND and RECEIVE requests are purged. If a task is attached, it is abnormally terminated with a transaction dump. A VTAM CLSDST macro is issued to halt communication with the node, and internal LOGONs are prevented.

If this message is issued during takeover, the acquire is retried at intervals of 1, 2, 4 and 8 minutes after the first attempt. This allows time for sessions which require manual intervention before the acquire can succeed.

User response

Use the VTAM VARY command to activate the node before using it in the network. Alternatively, for ISC with IMS, enable IMS for LOGONs.

It is possible that the node in question has previously been used as a generic APPLID (or in VTAM terms - a USERVAR). Use the VTAM operator command DISPLAY USERVAR to see if this is the case. If it is, you can use MODIFY USERVAR,OPTION=DELETE,ID=node to delete the USERVAR.

Instance 6 - Determine if TOR2 was started intentionally with a different APPLID and the same GR name and if not, correct the problem. If it was and you need a connection between these two systems then you need to end the affinity between the AOR and TOR1. The affinity can be ended by:

  1. Bring up TOR1, acquire the connection and release it cleanly or

  2. Bring up TOR1 and use ENDAFFIN via CEMT or EXEC CICS or

  3. Use a batch program described in 'Writing a batch program to end affinities' in the Getting started with intercommunication.

However, if the AOR is within the same sysplex as the TOR you should be using MRO connections rather than APPC - you then get no problems with affinities.

If the AOR is outside the sysplex and the connection is acquired from the TOR then you need to use a HUB as described in 'Using a HUB' in the Getting started with intercommunication to prevent two TORs from attempting to connect to one AOR using the generic resource name.

Alternatively you can change the AOR connection to address TOR2 by its real name as opposed to its generic resource name and always acquire the connection from the AOR. This implies that you must not use AUTOCONNECT in the TOR2 connection.

Module

DFHZSYX, DFHZSIX, DFHZSIM

XMEOUT parameters/Message inserts

  1. date
  2. time
  3. applid
  4. termid
  5. tranid
  6. netname
  7. sense
  8. instance
  9. Value chosen from the following options:

Destination

CSNE