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: - The application program should use the CID to identify
the session for a particular logical unit.
- This name is the LUALIAS name, USERVAR name, or the
name in the NSPLU name field of the BIND.
- The network identifier parameter list is mapped by
the ISTNRIPL DSECT. For more information, see Table 1.
|