This section gives some general guidance on how to handle various error conditions, for example:
FEPI does not recover any user data when an error condition is raised--data recovery, if needed, must be performed by the application program. In addition, the output option values on a command are not set if the command fails; your program should not be using these values in such cases.
The recommended way is that errors raised by FEPI commands should be handled by your application rather than letting CICS terminate the transaction abnormally. Errors and exceptions can be detected by using the RESP and RESP2 command options, or trapped using HANDLE CONDITION.
You should use time-outs with FEPI commands. If there is a problem with the connection to the back-end application, a program without time-outs may wait for ever, you may stop other applications running, and operator intervention may be needed.
Time-outs can be used with FEPI ALLOCATE, RECEIVE, START, and CONVERSE commands. In all cases, the timing applies only to the period that FEPI waits for a reply from the back-end system. As soon as anything is received from the back-end, FEPI stops the timer, and then waits for as long as is necessary to receive all the data that is required to complete the command. You cannot specify a time-out for FEPI SEND, because the command always completes immediately, without waiting for any data to be transmitted. Any delay or other problem is handled by the following FEPI RECEIVE command. The action to take on a time-out depends on the command that was used:
For a temporary conversation, it is as if the command were preceded by a FEPI ALLOCATE and followed by a FEPI FREE, so in this case the time-out is applied to both the ‘allocate’ and ‘receive’ parts of the command. In this situation, if a time-out occurs, there is no indication as to which part caused it.
If a FEPI application loses the session with the back-end application, it should free the conversation. Having done that, the application can take whatever action is required. A typical action would be to recover any data and restore the initial state before retrying the conversation or sending a message to the user.
The loss of a session can also occur because of CLSDST(PASS) processing (as discussed in Handling CLSDST(PASS)). If this is the case, you can find out when the session has been reestablished using the FEPI EXTRACT CONV command. You can then continue processing as required.
This occurs on a FEPI RECEIVE and is indicated by RESP2=216. It may be an external communication error, or it may be that the back-end system has responded negatively (as IMS™ does, for example, if you try to run an unknown transaction). Use the FEPI EXTRACT CONV command to get the sense data describing the failure. If this indicates a negative response, you should reissue the FEPI RECEIVE to get the data. If it was not a negative response, it is equivalent to a lost session and the session cannot be recovered.
It is simplest to treat communication and network errors as a lost session, which avoids the need for detailed SNA error protocol handling. However, sophisticated applications may want to handle certain recoverable conditions, for example, SNA CLEAR received (RESP2=230).
A command can be rejected by the FEPI global user exits (RESP2=10). Typically this would be because it violates the rules imposed by your system programmer. Check the rules with your system programmer.
Besides specifying the ID incorrectly, this is probably caused by the task that issued the command not owning the conversation, because:
If the error occurs on a FEPI ALLOCATE command with PASSCONVID, the conversation was probably not "unowned". Where the CONVID was obtained from FEPI start data, it is possible that between FEPI scheduling the task and it actually starting, a resource used by the conversation has been discarded, or CICS has started shutdown.
An operator/system error occurs when the operator tries to cancel a FEPI transaction. If, as is likely, it is waiting for a FEPI command to be processed, it is the ‘wait’ for FEPI processing that is canceled, not the transaction.
When a FEPI command fails with an ‘operator action’ error (RESP2=18), first end all the active conversations and then end the transaction as soon as possible.
A normal CICS shutdown waits for currently active tasks to end, but does not allow new tasks to start. FEPI allows existing conversations to continue within a task but does not allow them to be passed to another task (because that task would never be started), nor does it allow new conversations to be started. Conversations that are "unowned" are ended immediately, because the tasks that would subsequently handle them would never be started. Therefore, FEPI START or FREE PASS commands issued during shutdown fail (RESP2=214); in this case the error-handling routine, after doing whatever housekeeping is required, should issue FEPI FREE to end the conversation. FEPI ALLOCATE commands issued during shutdown fail with RESP2=12.
You might need to take special action on the back-end system, for example, signing off, when the front-end application is going to shut down. For this reason, when conversations end during shutdown, the end-session handler is invoked with SHUTDOWN indicated in the EVENTVALUE field of the start data, so that the back-end system can be restored to a known state before FEPI ends; the FEPI FREE issued by the handler is treated as if RELEASE is specified. If you require this function, make sure the end-session handler is defined in the transaction list table (XLT), so that it can be started, and so that it does not adversely affect the performance of CICS shutdown. (The XLT is described in the CICS Resource Definition Guide.) Using an end-session handler is the only way to perform special processing on shutdown, because no notification of shutdown is given to normal active transactions and conversations.
An immediate CICS shutdown ends all conversations immediately, and commands in progress fail. No further FEPI commands can be issued, and no end-session handlers are started.
[[ Contents Previous Page | Next Page Index ]]