Application organization

This section discusses application styles, started tasks, and conversations.

The three application styles can be mixed as desired. If there are enough connections available, you can have as many conversations as you like at a time with various targets: they can be consecutive or, much more usefully, interleaved. For example, if you need data from four different applications, you could overlap the processing by sending all four requests for data before you start waiting for a response.

Application style

One-out one-in conversational

One transaction performs the complete conversation with the back-end application in a single send and receive operation. This is the simplest style, if the required data can be obtained from the back-end application in this way. The transaction can be reduced to a single FEPI CONVERSE command using a temporary conversation.

By freeing the connection between transmissions, the capacity of the connection is increased. However, this style only works where no setup is needed to run the back-end transaction and it does not depend on any prior communication. This is because, unless you have a very strict pool regime, you cannot generally guarantee which simulated terminal FEPI will use-it may not be the same one as in a previous conversation-or that you were the last user of the terminal. Further, if you receive unexpected results from the back-end transaction, you may not be able to recover. Therefore, you should only use this style where it does not matter if the back-end transaction runs or not, for example, for a simple inquiry. A one-out one-in conversational program is unlikely to be suitable for accessing CICS® transactions or IMS™ conversational transactions.

See the sample program SLU P one-out one-in.

Conversational

One transaction performs the complete conversation with the back-end application using multiple send and receive operations and waiting for the inbound data to arrive. This style is used for a back-end application that requires several transmissions or complex setup. This style is simple, and if the network performance is good, the time spent waiting for inbound data may not be a problem.

See the sample program Key stroke CONVERSE.

Pseudoconversational

One transaction sends data to the back-end application, identifies another transaction that is to be started when the inbound data arrives, and ends. When inbound data arrives, FEPI starts the specified transaction which then receives the data. A typical technique is to have a transaction that, when started to receive inbound data, receives the data, sends the next piece of outbound data, issues FEPI START to start itself, and then ends.

The pseudoconversational style (use of FEPI START commands) results in significant CPU overheads in the front-end region. Further, since the use of FEPI START generates additional flows to and from the real terminal, response times are also significantly increased. As a consequence, FEPI START should be used sparingly when, for example. the receipt of the data from the back-end application takes a long time.

See the sample programs Screen image SEND and START and Screen image RECEIVE and EXTRACT FIELD.

Started tasks

In the pseudoconversational case, the ‘receive’ program is started by FEPI as a CICS started task, with a start code of 'SZ' (for FEPI) which can be checked using EXEC CICS ASSIGN STARTCODE.

FEPI supplies start data that identifies the reason for starting the task and gives information about the FEPI resources, such as the node-target connection, the data mode and format, and the conversation ID involved. The program that processes the transaction issues EXEC CICS RETRIEVE to get this data (the CICS rules relating to transactions and start data apply; in particular, you must retrieve all of the start data to prevent multiple initiations). Copy books DFHSZAPA, DFHSZAPO, DFHSZAPC, and DFHSZAPP contain declarations of the start data structure. You can provide your own data to be included in the start data, so that your programs can communicate with each other about their processing state and so on.

The first thing such a program must do is get ownership of the conversation using the conversation ID from the start data; it should then use FEPI RECEIVE to get the actual data from the back-end. Then it can do whatever it likes: end the conversation, send more data to the back-end system (and start itself or a new task to receive the reply), and so on.

In addition to inbound data arriving, anything else that would cause a FEPI RECEIVE command to complete causes the ‘receive program’ to be started. This includes a ‘previous SEND failed’ error, and a response from the back-end system without any data. The FEPI RECEIVE that you issue shows these cases, as if FEPI START had not been used.

The program is also started if the time limit set by the FEPI START command expires, or if the session is lost. These cases are indicated by the value of EVENTTYPE, in the start data, being TIMEOUT or SESSIONLOST rather than DATA. They should be handled as if a FEPI RECEIVE command had caused the error.

If your ‘send’ program is associated with a front-end terminal, your FEPI START command would normally specify that the ‘receive’ program uses the same terminal. You should be aware that it is not possible for FEPI to guarantee that another transaction will not use the terminal while the inbound data is awaited. In the majority of cases, this does not happen or does not matter. If it does happen and it is critical (perhaps for security reasons), you can prevent user input at the terminal by issuing an EXEC CICS SET TERMINAL command specifying NEXTTRANSID(itran) before issuing FEPI START; remember to reset NEXTTRANSID to blank in the started task. itran is the name of a transaction that you provide which simply rejects any user input, and sets NEXTTRANSID(itran) again. If this is unacceptable, you must avoid using pseudoconversational applications.

The handlers mentioned on pages Begin-session handler, Unsolicited-data handler and End-session handler --begin-session, unsolicited data, end-session--are also CICS started tasks. Again, the start data (obtained with EXEC CICS RETRIEVE) tells you why the task was started and the identity of the conversation. The started task must get ownership of the conversation so that it can continue the conversation and so that FEPI knows that the event is being handled.

Conversations

Your entire communication with a particular back-end transaction should be contained in a single FEPI conversation. This means that you remain in control of the communication; no other program can break in and you keep using the same simulated terminal. Only the task that started the conversation with FEPI ALLOCATE can use the conversation. It "owns" it and no other task can issue any command for it, not even FEPI EXTRACT CONV.

Conversational applications

In the simplest case, an access program starts a conversation with a FEPI ALLOCATE command specifying the pool of connections that is to be used. The command returns an identifier, the conversation ID, that is used to refer to the conversation subsequently. The program then issues a series of FEPI SEND, RECEIVE (and possibly other) commands for the conversation, each specifying the identifier, so that FEPI knows which conversation--and therefore which connection and target --the command is for. Finally, it ends the conversation with a FEPI FREE command. If it does not, the conversation is ended by FEPI when the task ends.

The FEPI FREE command should normally specify the HOLD option, so that the connection remains ready for use by another conversation. If the RELEASE option is used, or you leave the conversation to be freed by FEPI at the end of task, the session is ended, and a new one must be started for the next conversation; this is inefficient and, therefore, not recommended.

Started tasks

If the access program is pseudoconversational, after sending data it issues a FEPI START command to name the transaction that FEPI is to start when inbound data arrives. At this point the conversation becomes "unowned" and the first task can no longer use it. However, the conversation does not end; when data arrives, the conversation ID is passed to the started task and that task issues FEPI ALLOCATE with the PASSCONVID option to get ownership of the conversation. Only then can the started task use the conversation to receive the inbound data.

While the conversation is unowned, it can be acquired by any task that knows the conversation ID. Acquiring the connection cancels the pending start request, and the task that acquired ownership has to continue the conversation as if no FEPI START had been issued. This technique is useful in a pass-through application to a front-end terminal to handle contention between inbound data and terminal input. The application issues a FEPI START command, specifying the front-end terminal, and then returns to CICS specifying a ‘next’ transaction. Inbound data arriving first causes FEPI to start the transaction on the front-end terminal, which causes CICS to cancel its wait for terminal input; if terminal input arrives first, the application, after using EXEC CICS ASSIGN STARTCODE to determine why it was started, issues FEPI ALLOCATE with PASSCONVID which cancels the FEPI START request.

Getting ownership also applies to the tasks started by the various handlers. The conversation may have been started by some access program (end-session), or by FEPI itself (begin-session, unsolicited-data). Either way, you must still issue a FEPI ALLOCATE command with PASSCONVID, quoting the conversation ID, to get ownership and continue the conversation.

When a handler has finished processing, it must tell FEPI by issuing a FEPI FREE command for the conversation. For the begin-session handler, this should specify the HOLD option to indicate that the session is ready to be used; if RELEASE is used, the session is ended. The end-session and unsolicited-data handlers can use any of the options according to requirements.

Passing conversations

Besides using FEPI START to have a task for receiving data, any program or handler can explicitly give up ownership of its conversations so that another task can use them. You do this with the FEPI FREE command and the PASS option. Any task can then get ownership by using FEPI ALLOCATE with PASSCONVID and, if it maintains the command sequence, continue the conversation (for example, if the first task has issued a FEPI SEND with INVITE, the second task would have to issue a FEPI RECEIVE or, perhaps, a FEPI START). It is up to the two tasks to communicate between themselves, using the standard CICS methods (TS queue, COMMAREA, and so on), about the state of the conversation and its ID. FEPI does not offer any application programming facilities for this except that the new task can use FEPI EXTRACT CONV to determine details such as the data format.

If you do not employ a method of passing and saving the conversation across invocations of a pseudoconversational front-end transaction, and instead issue the default FREE command, you lose your connection to the back-end transaction, making it possible for another program to start a conversation and effectively "break into" the active transaction. This can cause the back-end application to abnormally end.

The only other method that can be used to ensure a unique relationship between front-end and back-end transactions, is to have FEPI pools containing a single FEPI node for each user. This ensures that you always get connected to the back-end transaction on the same terminal (FEPI node) to continue your conversation. However, this method can cause administrative problems where there are a large number of end users.

Temporary conversations

In a one-out one-in conversational application you can use a single FEPI CONVERSE command that combines an ALLOCATE-SEND-RECEIVE-FREE command sequence. This combination is selected by using the POOL option of FEPI CONVERSE rather than the CONVID option. In this case, the conversation is a temporary conversation that lasts only for the duration of the FEPI CONVERSE command. No conversation ID is returned by FEPI and no other commands can be issued for the conversation; you cannot even use FEPI EXTRACT FIELD to process the returned data.

As with all one-out one-in conversational applications, temporary conversations should be used with care. If more data is received than can be returned on the FEPI CONVERSE command (because, for example, the data is not what you expect), the excess is discarded and cannot be retrieved by the application. Data may be lost if the command fails and, because you cannot receive any more data or guarantee that your next conversation will use the same simulated terminal, it may be difficult to determine the state of the back-end system.

Notes:
  1. Every conversation started with FEPI ALLOCATE has a unique conversation ID, as does every conversation started for a handler, except in the case of end-session when started after a FEPI FREE. In this case, the ID is the same as in the task issuing the FEPI FREE.

    A task started when inbound data arrives gets the same conversation ID as the task that issued the FEPI START command.

  2. The state of a conversation (whether, for example, it is owned by an access program, in a begin-session handler, waiting for inbound data, or being passed) is shown by the STATE option of the CEMT INQUIRE FECONNECTION command (see State) or the FEPI INQUIRE CONNECTION command ( page FEPI INQUIRE CONNECTION). This may be useful when you are debugging applications.
  3. If your programs are written in C, do not handle conversation identifiers as strings; they may contain null characters.
[[ Contents Previous Page | Next Page Index ]]