An application on a session with FM profile 3 or 4 can request termination of the PLU session. It should only do so if it has previously ensured that it is in a state where the PLU session can be terminated, that is, between-chain and between-bracket. Terminating the PLU session does not affect the state of the SSCP session.
Note that an application can issue a character coded or field formatted LOGOFF command on the SSCP session or send a Close(PLU) Request to get the local node to send TERM-SELF on the application's behalf. All of these will elicit an UNBIND, either immediately or after session tidy-up in the host.
The application requests termination of the PLU session by sending a Status-Control(RSHUTD) Request to the local node, which generates an SNA RSHUTD request to the host.
After sending the Status-Control(RSHUTD) Request, the application must remain capable of accepting and responding to all outbound data it receives. The application can now expect one of two messages, depending on whether the state of the PLU session allows it to be terminated and whether the host wishes to terminate the PLU session:
The following two figures illustrate the application-initiated termination protocol between the local node and the application and how this protocol relates to the underlying SNA protocols.
In the first illustration, the application requests termination of the PLU session, and the host sends UNBIND. The local node closes the PLU connection.
In the following illustration, the application requests termination of the PLU session, but the session is not in an appropriate state. The host sends a negative response to the RSHUTD request, which the local node presents as Status-Control(RSHUTD) Negative-Acknowledge-1. Communication continues on the PLU session.