Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Rejecting a conversation pending deallocation for persistent sessions z/OS Communications Server: SNA Programmer's LU 6.2 Guide SC27-3669-00 |
|
After the failure of a VTAM® application program that has enabled persistence, VTAM attempts to deactivate any active conversations. If deallocation of a conversation does not complete, for whatever reason, the conversation remains in a state of pending deallocation for persistent LU-LU sessions until it is brought down for another reason or until the session is deactivated. If the application program tries to use the conversation, VTAM sets a return code that indicates that the conversation identifier is not valid. If session information is requested on the APPCCMD CONTROL=OPRCNTL, QUALIFY=RESTORE macroinstruction (LIST=ALL), the RESTORE structure indicates whether the session is pending deactivation for persistent LU-LU session support (SRESPNDA) or whether the conversation is pending deallocation for persistent LU-LU session support (SREPCONV). However, only the session identifier (SESSID) is passed back in the RESTORE structure. (See Retrieving information for a mode and sessions to be restored for more information.) After the mode is restored, the application program can issue APPCCMD CONTROL=REJECT, QUALIFY=SESSION for such a session to bring down the session and any existing conversation. |
Copyright IBM Corporation 1990, 2014
|