You can think of FEPI as a "pipe" through which users access back-end transactions; any peculiarities that exist in the back-end system have to be allowed for in the FEPI application. IMS™ has special considerations and these are explained in the following text.
This section concludes with some notes about performance.
It is essential that you are familiar with using IMS and writing IMS applications.
When designing access programs that have IMS as a target back-end system, careful consideration must be given to the differences between CICS® and IMS under certain circumstances:
You are strongly recommended to run all your back-end IMS transactions in response mode where messages to IMS from the (simulated) terminal are handled synchronously; that is, each message from the terminal is processed by IMS and the reply is queued before a further message from the terminal is allowed. This lets your front-end application be much simpler because data received will be the reply to the data just sent, and because the data stream flows from IMS are more straightforward; further, a separate FEPI conversation can be used for each IMS transaction and this allows much better use of the network (of course, you must use the same FEPI conversation throughout an IMS conversational transaction).
If you use non-response mode, the data stream flows may be more complex. If you send multiple messages to IMS, the application has to handle asynchronous messages from IMS and, to keep the same simulated terminal, has to use the same FEPI conversation all the time.
Check with your system programmer that the transactions to be used by FEPI are defined to run in response mode. This requires the terminals for FEPI to be defined either to force response mode or to use the setting for the transaction (which in turn should be defined as response mode).
For SLU2, there is always initial data. You should:
Application programs must be designed such that when a session is ended:
Physically paged messages are removed from the queue automatically when the last page has been sent and, if they are recoverable, acknowledged. Operator logically-paged messages are not removed and require a PA2 (for SLU2 mode) or a NEXTMSG/NEXTMSGP control function (for SLU P mode) to be sent to IMS to remove the message from the queue if no input message is due.
After a system failure, IMS recovers following a restart from the last checkpoint it took. This means that, if the failure occurs when IMS has committed a message to the input queue then, on restart, IMS requeues that message and schedules a transaction to process it. Similarly, IMS will requeue all output messages that it has committed to its output queues and not successfully sent.
When IMS fails, all sessions between FEPI and IMS are ended. This is reported to the FEPI application as a command error (‘session lost’). A FEPI application should check this so that it can tidy up before ending and take the appropriate action (such as informing the operator).
FEPI attempts to regain lost connections and, therefore, when IMS restarts, any previously acquired connections are reestablished. If IMS has committed an input or output message, eventually there is going to be an output message to send. With the connection reacquired, IMS attempts to recover its position and ultimately to send any queued output messages to the FEPI node that carried the original FEPI conversation. The process of recovery in this situation is different for each of the two modes:
This situation becomes more complex if the back-end transaction is IMS conversational, because the front-end transaction has no way of knowing this, and the IMS conversation will still be active in the back-end system awaiting input.
The potential therefore exists for a front-end FEPI application to allocate a FEPI conversation on a node where an IMS conversation still exists on the back-end system. Any data flowing on this FEPI conversation is viewed by the front-end application as an exchange with a new back-end transaction, but it is viewed by IMS as the next input message to the existing conversation. To prevent this situation occurring, you can use the begin-session handler to issue the IMS /EXIT command, which has the effect of ending an active IMS conversation.
Where the possibility exists of a number of nodes with active IMS conversations following a restart, it is possible to use FEPI to obtain a connection to IMS and control the cleanup operation, from a single point. You do this by issuing, again from the appropriate handler:
In the event of a failure that unbinds all the FEPI connections to IMS, the recovery procedure is identical to that described here.
Use the following techniques to get the best performance from your FEPI applications; the main principles are to minimize the number of commands issued and the amount of data transmitted. Remember, however, that some of these techniques have drawbacks (as have been explained elsewhere), and some conflict with each other; you must choose the best balance to meet your needs.