Question & Answer
Question
An LU in an APPN network attempts to log on to a VTAM application, defined as a generic resource, in an adjoining APPN network. The logon attempt fails with the following message group:
IST663I IPS SRC REQUEST TO ISTAPNCP RECEIVED, SENSE=10145046
IST664I REAL OLU=luname1 REAL DLU=luname2
IST889I SID = sessionid
IST891I netid.nodename1 GENERATED FAILURE NOTIFICATION
IST893I ORIGINAL FAILING REQUEST IS GDS CDINIT
IST314I END
The APPN border node function is enabled for communication between the two networks. At the time of the session failure, the end node owning the generic resource is served by a backup network node server outside the sysplex to which the end node belongs.
Answer
DIAGNOSIS
If the ENBCAST parameter on the NETSRVR definition statement is set to YES on an end node's (EN) definition of a backup network node server, it indicates that the backup network node server is allowed to search an end node it serves for unknown resources. This operand is used to enable the generic resource function to operate with a network node server (NNS) that is not connected to the same generic resource structure as the end node.
In this case, however, the EN owning the generic resource either specified NO for ENBCAST for the backup NNS or used the default value NO. ENBCAST=NO specifies that the network node server is not allowed to search the end node for unknown resources.
When the EN established CP-CP sessions with that backup NNS, an exchange of CP capabilities GDS variables (x'12c1') took place between the EN and NNS. Because of the ENBCAST=NO setting, the EN did not include an EN CP search vector (x'33') on the CP capabilities it sent to the backup NNS.
Consequently, when the NNS received that CP capabilities GDS variable from the EN, it, did not find a CV33 in the CP capabilities and therefore concluded that the EN does not allow searches for LUs.
When the backup NNS later received a search request for the particular generic resource, the backup NNS did not send a locate-find-CDINIT search request sent to the end node owning the generic resource, since it had previously determined that the EN does not allow searches for LUs . Consequently, the NNS did not get from the EN any TG (x'46') vectors for the generic resource.
Because no TG vectors were provided to the NN, the session request was failed with sense code X'10145046' (TG vectors not present in a CD-Initiate from an end node OLU or DLU).
RESOLUTION
To avoid this problem, when specifying a backup NNS outside the sysplex in the end node's NETSRVR list, specify the parameter ENBCAST=YES.
As the SNA Resource Definition Reference points out, ENBCAST=YES "can be used to enable the generic resource function to operate with an NNS that is not connected to the same generic resource structure as the end node."
Due to the possible performance impact, this is intended as a backup mode of operation only; therefore, ENBCAST=YES should be coded only on the NETSRVR definition statement of a backup NNS. In addition, this backup mode of operation works only when all ENs connected to the same generic resource structure are using the same backup node as their NNS. For this reason, it is necessary to configure all of these end nodes such that they will switch to the backup-mode network node server only in the event of a failure of the primary NNS (rather than, for example, when a link failure occurs).
Product Synonym
ZOSCS COMMSERVER
Was this topic helpful?
Document Information
Modified date:
19 October 2015
UID
dwa1233955