Application programs supporting persistent LU-LU sessions can reestablish
LU-LU sessions at the level before the failure without the session
establishment flow. There are two levels of support for persistent
LU-LU sessions.
- Single node persistent sessions (SNPS)
If an application program
fails or is brought down, VTAM® can retain active sessions, allowing
the same or another application program to reconnect to the sessions,
avoiding the need to reestablish the sessions. If an application program
fails, it can reconnect to the retained sessions when it recovers.
Also, another application program can take over the sessions. SNPS
takeover processing allows an application program to take over the
sessions of an active application, although the active application
is able to indicate, through SETLOGON PERSIST, that such requests
are rejected by VTAM.
- Multinode persistent sessions (MNPS)
Multinode persistent LU-LU
sessions (MNPS) extends the single node persistent session support
to application, VTAM, operating
system, and hardware failures. Applications can be restarted on an
alternate VTAM and their sessions
restored after a VTAM failure.
Applications can also restart on the same VTAM after VTAM has been restarted.
MNPS planned takeover processing
differs from SNPS takeover processing in that the application is required
to fail, or issue CLOSE ACB, while enabled for persistence in order
to be eligible to move to another VTAM.
An alternative to MNPS planned takeover, called
MNPS forced takeover, works closer to SNPS takeover processing, in
that the target application does not have to fail or issue a persistent
CLOSE ACB before the MNPS takeover attempt being made. However, unlike
SNPS takeover, MNPS forced takeover requires that the taking over
application indicate on the ACB macroinstruction that any OPEN ACB
attempted using this ACB is an MNPS forced takeover attempt; likewise,
the target application must indicate on SETLOGON OPTCD=PERSIST that
it will accept MNPS forced takeovers. SNPS takeover processing does
not require any special communication from the application, but the
capability does exist for the application to indicate that SNPS takeover
is not permitted.
When an application program is persistent enabled, VTAM saves data sent and received by the application
program and other status information. VTAM uses this information to reestablish the session after
a failure has occurred, or as part of planned or forced takeover processing.
For an application to be capable of persistence, code PERSIST=YES
on the ACB macroinstruction. To enable persistence, the application
program must specify OPTCD=PERSIST on the SETLOGON macroinstruction.
The application program can also disable persistence by issuing SETLOGON
OPTCD=NPERSIST at any time. An application that wants to use multinode
persistent session support must have PERSIST=MULTI coded on its application
definition statement.
For an OPEN ACB to be considered for MNPS forced takeover processing,
include FORCETKO=YES on the ACB macroinstruction (along with PERSIST=YES).
The application is permitted to specify the following types of
forced takeover requests it will accept from other application images
of the same name:
- To indicate that the application will accept MNPS forced takeover
requests from other instances of the application, code PARMS=(FORCETKO=ALL)
or PARMS=(FORCETKO=MULTI) on the SETLOGON OPTCD=PERSIST macroinstruction.
- To indicate that the application will accept SNPS forced takeover
requests from other instances of the application, code PARMS=(FORCETKO=ALL)
or PARMS=(FORCETKO=SINGLE) on the SETLOGON OPTCD=PERSIST macroinstructions.
- To prevent any forced takeover from being processed for the application,
code PARMS=(FORCETKO=NONE) on the SETLOGON OPTCD=PERSIST macroinstruction.
Rule: Issuing SETLOGON OPTCD=NPERSIST
does not affect the setting of the FORCETKO capability of the application.