Rejecting a conversation pending deallocation for persistent sessions

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.