z/OS Communications Server: SNA Programming
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


UNBIND

z/OS Communications Server: SNA Programming
SC27-3674-00

UNBIND is sent by an LU, either a PLU or an SLU, to its session partner in an LU-LU session to end that session. Additionally, UNBIND can be sent on an LU-LU session on behalf of an LU by other network components; this is typically done to notify each LU in the session that a session outage has occurred (for example, because of a network or LU failure).

UNBIND received by an SLU application program is always presented through an SCIP exit routine. UNBIND received by a PLU is presented through an SCIP exit routine only if such an exit routine exists and if SONSCIP=YES is coded on the APPL definition statement for that application program; otherwise, either an NSEXIT exit routine is scheduled with CLEANUP, or a LOSTERM exit routine is scheduled with a reason code. See Session outage notification for details.

If an SCIP exit routine is scheduled, the AREA field in the read-only RPL provides the address of an UNBIND RU in read-only storage. This RU contains a 1-byte request code and a 1-byte type code. Additional data may be available for certain type codes. Many of the currently defined UNBIND SON (UNBIND type) codes follow. Additional codes are listed in SNA Formats. If an application program receives an UNBIND SON code that it does not recognize, it should act as if UNBIND SON type 1 had been received. VTAM® terminates the session and attempts to notify the application program for any UNBIND SON code.

UNBIND
  Type code meaning
1 (X'01')
Normal end of session. (For example, the PLU application program issued CLSDST OPTCD=RELEASE for this session.)
2 (X'02')
BIND forthcoming. (For example, the PLU application program issued CLSDST OPTCD=PASS for this session.) The LU receiving the UNBIND should retain resources associated with this session because a BIND arrives shortly to establish another session which can use those resources.
7 (X'07')
Virtual route inoperative. The virtual route used by this session has become inoperative, possibly because of a link or network node failure. You can try to reinitiate the session (for example, by using SIMLOGON or REQSESS) using the same class of service or a different class of service (class of service is specified indirectly through a logon mode name); this attempts to reestablish the session on a virtual route within that class of service. The virtual route used can be the same as the original virtual route (if it has recovered) or can be another virtual route within the chosen class of service.
8 (X'08')
Route extension inoperative. The route extension used by this session has become inoperative. (The route extension is the connection, including the link, between a peripheral node associated with one end of the session and the subarea node supplying boundary function for that peripheral node.) The session cannot be reestablished until the route extension has been made operative again. You can attempt to reinitiate the session by using SIMLOGON OPTCD=(Q,ASY). This fails if the SSCP has detected a permanent route extension failure. If a recovery procedure is under way to reestablish contact with the peripheral node, SIMLOGON cannot be posted complete for a long time; it is posted complete with (RTNCD,FDB2)=(X'00',X'00') if the recovery procedure succeeds; it is posted complete with an error return code if a permanent error is detected.
9 (X'09')
Hierarchical reset. The current LU-LU session is being terminated because an SSCP established an SSCP-LU (or SSCP-PU) session with the other LU in this session (or the PU associated with that LU) and that LU (or PU) could not accept the SSCP session without terminating all of its associated LU-LU sessions. An immediate attempt to reinitiate the LU-LU session (for example, by using SIMLOGON) is likely to succeed.
10 (X'0A')
SSCP gone. The current LU-LU session is being terminated because the SSCP-PU or SSCP-LU session associated with the other LU in the session has been intentionally or unintentionally terminated. For example, a VTAM operator has used the VARY command to deactivate that PU or LU, or the virtual route used by the SSCP sessions with the PU and LU has failed and the node providing boundary function support for the PU and LU has been coded to end LU-LU sessions when this occurs. An immediate attempt to reinitiate the LU-LU session is unlikely to succeed because the other LU is currently unavailable.
11 (X'0B')
Virtual route deactivated. The current LU-LU session is being terminated because the virtual route used by that session has been intentionally deactivated. You can try to reinitiate the session (for example, by using SIMLOGON or REQSESS) using the same class of service or a different class of service (class of service is specified indirectly through a logon mode name); this attempts to reestablish the session on a virtual route within that class of service. The virtual route used can be the same as the original virtual route (if it can be reactivated), or a new virtual route can be used.
12 (X'0C')
Unrecoverable LU failure. The current LU-LU session is being terminated because of a permanent failure of one of the LUs involved in the session. An attempt to reinitiate the session probably fails.
14 (X'0E')
Recoverable LU failure. The current LU-LU session is being terminated because of a temporary failure of one of the LUs involved in the session. An attempt to reinitiate the session might be successful.
15 (X'0F')
Cleanup. The current LU-LU session is being terminated because one of the LUs in the session is being cleaned up, usually because an SSCP issued a CLEANUP request to that LU. An attempt to reinitiate the session might succeed.
254 (X'FE')
Session protocol or user-supplied sense code that is not valid. One of the LUs in the session has detected a protocol violation. Four bytes of sense data following the UNBIND SON code indicate the specific violation. Depending on the violation, an attempt to reestablish the session might succeed.

Code X'FE' can also be coded in an application program to indicate that 4 bytes of user-defined sense data are supplied in the UNBIND.

Certain information can appear in control vectors appended to the UNBIND RU:
Vector
Description
X'35'
Extended-sense data control vector.
X'60'
Fully qualified PCID control vector.

For the role of the UNBIND request in various sequences, see Request and response exchanges for typical communication operations.

Table 1. SCIP exit routine: Registers upon entry
Reg Contents
0, 2-13 Unpredictable
1 Address of a parameter list that includes the following:
  • Word 1—address of ACB for application program to which the session-control request is sent
  • Word 2—CID of the session 1
  • Word 3—USERFLD data of NIB at time the session is initiated or established; be aware of the following:
    • If session has been established, word 3 contains USERFLD field contents from NIB used by OPNDST or OPNSEC
    • For receipt of BIND request resulting from the application program issuing a REQSESS, word 3 contains USERFLD contents from NIB used by REQSESS, else, word 3 is 0 for BIND
    • For receipt of UNBIND, word 3 can contain the user field data for the session if it still exists, else, word 3 will be 0. This user field data was originally obtained from the USERFLD contents in the NIB.
  • Word 4—contents depend on the type of request:
    • BIND request - contains beginning address of the session parameters (see Specifying a session parameter); the area is freed when both of the following have occurred:
      • Exit routine has returned to VTAM
      • OPNSEC, SESSIONC, or TERMSESS has been issued for session
  • Other types of requests—contains no meaningful data
  • Word 5—address of a VTAM-supplied, read-only RPL
  • Word 6—address of the PLU's symbolic name 2 (BIND RU only)
  • Word 7—address of the network identifier parameter list 3 (BIND RU only)
14 VTAM address that is branched to when SCIP exit routine completes processing
15 Address of SCIP exit routine
Notes:
  1. The application program should use the CID to identify the session for a particular logical unit.
  2. This name is the LUALIAS name, USERVAR name, or the name in the NSPLU name field of the BIND.
  3. The network identifier parameter list is mapped by the ISTNRIPL DSECT. For more information, see Table 1.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014