This section discusses FEPI in a CICS® extended recovery facility (XRF) environment. To understand it, you need to have read the CICS/ESA 3.3 CICS XRF Guide, and to be familiar with CICS XRF VTAM® USERVAR processing--the VTAM Programming manual contains relevant material.
The effect of an XRF takeover of a CICS back-end system with which FEPI is in communication is described. Although IMS™ XRF processing is not discussed here, the same considerations apply.
FEPI uses VTAM secondary LU support for communication and the simulated terminals defined to the back-end CICS system behave in a different way to real devices.
In an XRF environment, the simulated terminals in the back-end system cannot behave as VTAM class 1 terminals because there is no 3745/3725/3720 controller acting as the boundary network node (BNN). They behave like VTAM class 2 terminals, which is the default setting for CICS and IMS terminal definitions. Consequently, simulated terminals do not support VTAM XRF, and CICS XRF facilities are provided by tracking mechanisms that are explained in the CICS/ESA 3.3 CICS XRF Guide.
When a FEPI connection is acquired, the back-end CICS generates a TCTTE (if one is not present already) using autoinstall. At this point, in a CICS XRF environment, the active CICS informs the alternate that a terminal has been defined. If the active is then taken over, the alternate knows which terminals are defined, and can take actions to recover the links.
As part of takeover processing, a VTAM BIND is issued to reestablish the session with each simulated terminal. However, FEPI also has detected that the connection has ended, and attempts to contact the (new active) back-end system by issuing a similar bind. This results in a bind race. The outcome of this bind race depends on the circumstances of the exchange. However, the bind issued by the new active CICS will probably be rejected, and the FEPI bind accepted. This results in DFHZCxxxx messages being produced during the takeover (see Connections with a conversation--with data flow). If FEPI reestablishes the connection, these messages can be ignored. You can remove these bind races by defining the back-end CICS terminal so it behaves as a VTAM class 3 terminal (no XRF support). To define the simulated terminals as class 3, specify RECOVOPTION=NONE in CICS, or BACKUP=NO in IMS.
In an XRF environment, the applid specified on the FEPI INSTALL TARGETLIST command must be the generic applid of the back-end system. Specifying either the primary or secondary applid of the target results in processing errors. If you use the generic applid, FEPI is able to cater for the back-end system undergoing an XRF takeover.
However, you can define a pool that contains the specific applids of both the active and alternate systems. In this case, the alternate targets cannot be contacted until an XRF takeover has been performed. Similarly, the active targets cannot be contacted after takeover. If you define pools in this way (perhaps to provide backup support without XRF), you should manage the ACQUIRED-RELEASED status yourself, to minimize FEPI retry processing.
This section describes what happens when the CICS system running FEPI undergoes an XRF takeover.
Each back-end transaction is abended, due to the loss of the simulated terminal--which is usually the principal facility for the task. Consequently, the ATNI (or equivalent) abend processing is unable to send the usual message indicating a transaction abend to the principal facility.
Transactions that attempt to handle terminal control errors should already be written to cope with this circumstance, and you should not need to alter them.
FEPI is acting as the "terminal", so an XRF takeover of the FEPI system results in the loss of the "terminal" in the back-end system. CICS takes the usual actions for the loss of a (real) terminal. There are three cases to consider:
If you are using autoinstall, the TCTTEs representing these "terminals" are deleted after a delay; if the delay is long enough, the alternate front-end CICS may reestablish the sessions before the TCTTEs are deleted.
If you are using autoinstall, the TCTTEs representing these "terminals" are deleted after a delay; if the delay is long enough, the alternate front-end CICS may reestablish the sessions before the TCTTEs are deleted.
These "terminals" are usually running a transaction when the "terminal" is lost. This results in the transaction being abended with the normal CICS abend code for a terminal failure (usually ‘ATNI’). The abend is usually accompanied by a DFHZCxxxx message indicating that the "terminal" has suffered an unrecoverable failure.
You may have to modify your node error program to prevent retry loops, but normally the default action (not to retry) is taken. When node error processing ends, if autoinstall is used, the "terminal" is deleted.
The alternate FEPI CICS takes over operation of the failed CICS in the normal fashion. However, FEPI resources are not recovered automatically after an XRF takeover.
FEPI restarts at a late stage of takeover, after all RDO resources have been reinstalled. Nevertheless, when the second phase of the PLTPI list is entered, FEPI is ready to receive commands. Therefore, if you follow the recommendation to start your FEPI setup transaction from a PLTPI program, FEPI resources are reinstalled as part of the takeover. If you do not run your setup transaction in this way, then after a takeover you must arrange for it to be run manually, so that your FEPI resources are reinstalled.
However you handle resource definition in an XRF-environment, you must be prepared to cope with the possibility that FEPI resources have been manipulated in the failed CICS, so that the environment after takeover is not the same as that immediately before takeover. For example, resources may have been installed or deleted, or SERVSTATUS or ACQSTATUS values altered, after your setup transaction was run in the failed CICS.
This section describes what happens when the CICS back-end system with which FEPI is communicating undergoes an XRF takeover.
FEPI application programs are unable to distinguish between a loss of session due to an XRF takeover of the back-end system, and one due to a FEPI failure. In both cases, a typical RESP2 value of ‘215’ (‘Session lost’) is returned on the next FEPI command issued after the takeover has started. Alternatively, the application may get an indication of a state error, meaning that the command cannot be issued because the connection is not active. The application should immediately issue a FEPI FREE command to free the conversation.
If an end-session handler is active, it gets invoked, even though the conversation has ended.
If the application program believes that the back-end is undergoing an XRF takeover, it should reissue a FEPI ALLOCATE command for the back-end. When the takeover is complete, and FEPI has reestablished contact, the FEPI ALLOCATE completes successfully (together with any specified begin-session processing). If the TIMEOUT option is used, consider its setting in relation to how long you expect the alternate back-end system to take to complete takeover.
It is the responsibility of the application program to perform any processing in the new active back-end system necessitated by the XRF takeover.
In general, FEPI successfully copes with
the XRF takeover of a back-end system with which it is communicating. However,
when the new active back-end system attempts to establish its terminal sessions,
communication with FEPI may result in some strange terminal control messages.
You should ignore these until FEPI has had time to contact the back-end
system.
While FEPI is attempting to reestablish contact with the back-end system:
There are three cases to consider:
These connections reestablish contact with the new active back-end when the back-end’s ACB is opened.
These connections reestablish contact with the new active back-end when the back-end’s ACB is opened. You may get some messages in the back-end system indicating that the TCTTE was deleted and reinstalled.
These connections generate errors in the back-end system when it attempts to reestablish contact with the "terminal". You may see messages DFHZC3492E, DFHZC2411E, DFHZC3422E, DFHZC3437I, or DFHZC3462I being generated--all of which say that the standby back-end could not reestablish contact with the "terminal". However, as long as the conversation that was running on the connection has been freed, FEPI subsequently reestablishes contact and reinstalls the "terminal".
[[ Contents Previous Page | Next Page Index ]]