What to do if recovery does not occur or complete

The D NET,ID command can be used to display the sessions associated with an MNPS application. As described earlier, the session that is eligible for MNPS recovery is denoted with a /M status modifier; however, the presence of the /M status modifier does not guarantee that the session will recover if the application were to move or to fail. Factors, such as whether the application is enabled for persistence and whether the session partner is a DLUR-related dependent LU, for example, can affect the actual recovery of the session.

If the display information indicates that a session is not recoverable, and if a message is displayed indicating that a session is not recoverable, and you expected it to be recoverable, do the following steps:

Verify that PERSIST=MULTI is specified on the APPL definition statement. If model application definition statements are being used to define your application program, verify that the application program is active and PERSIST=MULTI is coded on the application model.
Verify that PARMS=(PERSIST=YES) is specified on the OPEN ACB for the application program.
Verify that the coupling facility structure name matches the STRMNPS start option for all VTAMs.
Verify that HPR=RTP start option is coded and not overridden by the definitions for the PU or TG.
For end nodes, verify that at least one adjacent node has HPR=RTP start option specified.
For network nodes, verify that the path chosen for the session is one that traverses an adjacent node with HPR=RTP coded (or the configuration option that applies to the adjacent node if not a VTAM®).
Verify that the adjacent CDRM (for migration data host node) does not favor subarea routing over APPN (SSCPDYN start option or SSCPORD and SORDER).
Note: SSCPORD and SORDER can be specified as start options or specified separately for each ADJSSCP table.

If you have a multinode persistent session-capable application program, and the sessions are not being recovered when you expect them to be recovered, do the following steps:

Verify that the recovering application program is using the same name as the failed application program.
Verify that an MVS™ system symbol is used as part of the value for LUAPFX. If model application definition statements are being used to define your MNPS application program and LUAPFX is specified, use an MVS system symbol as part of the value for LUAPFX to reduce collision of LUALIAS values.
Verify that the sessions do not involve LUs active where the recovery is taking place or LUs active at the node where the MNPS application was previously active.
Verify that the PSTIMER has not expired or that it is not too short. Recall that when the PSTIMER expires, the session information is cleaned up. If the timer value is too short, there might not be sufficient time to recover the sessions.
Verify that the partner node still has sessions showing active. It could be that the MNPS node shows the sessions as PRECOVRY, but the HPR connection has timed out and sessions are cleaned up at the partner node.
Verify that the sessions are not in PRECOVRY state. If they are, the recovery might be occurring but is slow to complete.
Verify that the application program being recovered has PERSIST=MULTI specified on its APPL definition statement and PARMS=(PERSIST=YES) on its ACB statement.
Verify that the new VTAM (where the application is being recovered) has HPR connectivity and (if VTAM is an end node) has CP-CP sessions to an NNS (which might be needed to calculate the new route to the partner endpoint). Use the DISPLAY NET,STATS,TYPE=CFS command to verify that the new structure has connectivity to the multinode persistent session coupling facility structure.
Verify that if the attempt is a forced takeover, that the takeover and the current owning VTAM are at the correct level, which is at a minimum z/OS® Communications Server V1R6. Verify that the ACB macroinstruction of the application issuing the forced takeover request correctly specified PARMS=(FORCETKO=YES). Verify that the application being taken over has correctly indicated the ability to accept forced takeover requests by specifying PARMS=(FORCETKO=ALL) or PARMS=(FORCETKO=MULTI) on SETLOGON OPTCD=PERSIST (and that no subsequent SETLOGON OPTCD=PERSIST specified PARMS=(FORCETKO=NONE) or PARMS=(FORCETKO=SINGLE)). Finally, if the application being taken over was once owned by a pre-z/OS Communications Server V1R6 node, then ensure that SETLOGON OPTCD=PERSIST with PARMS=(FORCETKO=ALL) or PARMS=(FORCETKO=MULTI) was performed after the application moved to a z/OS Communication Server V1R6 node.
Verify that a CDRSC representation of the MNPS application could be created, or reused, at the VTAM DLUS node when moving the MNPS application to another VTAM node in the sysplex.