Assume that an XRF application program, such as CICS®, runs on Systems A and B of the sample network shown in Figure 1. CICSA is the specific VTAM® APPLID of the CICS running on System A, and CICSB is the APPLID of the CICS running on System B. The terminal network is owned by the VTAM in System C (this is a communication management configuration, or CMC).

1. When CICSA is started as an active CICS application program, it issues an F NET,USERVAR,ID=CICS,VALUE=CICSA command, requesting that VTAMA create a dynamic (by default), user-managed USERVAR with a value of CICSA. Because CICSB is started as an XRF alternate, it does not request that VTAMB create a USERVAR.
2. Logon requests from a terminal are processed by VTAMC, which is the controlling VTAM for the terminal network. The first time a terminal attempts to log on to generic application name CICS, VTAMC processes the logon request as follows:
   • Because VTAMC does not recognize the name CICS yet, it treats the request like any other cross-domain logon request and sends a cross-domain session request to other VTAMs listed in an ADJSSCP table looking for CICS. At this point, VTAMC does not know whether CICS is the name of a USERVAR or a real VTAM APPLID.
   • When VTAMA receives the session request, CICS is identified as the name of one of its own user-managed USERVARs. It replies to VTAMC, indicating that CICS is really a dynamic USERVAR whose value is currently CICSA.
   • VTAMC uses the information it received from VTAMA to establish a cross-domain session with the application program by sending another session request using that specific application name, CICSA. In addition, VTAMC creates an automatic USERVAR to save the USERVAR information for future use.
3. For subsequent terminal logons to CICS, VTAMC uses the information it saved previously in the automatic USERVAR to translate the requests immediately to CICSA. VTAMC continues to translate CICS requests directly to CICSA without repeating the cross-domain search process because CICS is a dynamic USERVAR. This process continues until either an XRF takeover occurs or VTAMC discovers that it is otherwise unable to establish sessions with CICSA.
4. If CICSA fails and CICSB takes over and becomes the new active application program, CICSB issues an F NET,USERVAR,ID=CICS,VALUE=CICSB command, requesting that VTAMB create a new user-managed USERVAR with the value CICSB. This means that VTAMB is now the VTAM to identify session requests searching for CICS. VTAMB then responds, indicating CICSB is the current value of the USERVAR.
   Each VTAM that was notified that its XRF sessions were switched deletes any automatic USERVARs that were used to create those sessions. This means that the next logon for CICS does not find the USERVAR and goes through the cross-domain search process (step 2) to determine the new value of CICS. In addition, the VTAM associated with the failing application program (VTAMA) deletes its user-managed USERVAR for CICS and prevents any further logons to CICSA to ensure that logons do not get directed to the failing application program.

   Note: If a resource submits a network-qualified session request with a generic resource name, USERVAR processing occurs in the domain of the resource if one of the following is true:

   • The NETID specified on the session request is equal to the NETID of the USERVAR value.
   • The NETID specified on the session request is equal to the NETID of the host and the USERVAR value is not network-qualified.