The programs comprising a FEPI application are:
The main purpose of an access program is to:
It must also be able to handle exception cases such as edit errors, transactions that are not valid, or security violations, and it may need to manage signon/signoff sequences. It may also need to handle begin-session and end-session requirements, if special handlers are not provided. The SESSNSTATUS option of FEPI ALLOCATE tells you if a new session has been started, or if you are reusing an existing session.
For many FEPI applications, particularly where formatted data is used, the access program is not complex. However, you do need to be fully conversant with everything that the back-end application might do. Your application must behave just like the real terminal and operator, and you must send and receive data in the correct sequence. Within a conversation, any data received is passed to the application that owns the conversation; FEPI cannot determine whether it is the data or screen image that was expected or, for example, a message reporting an abnormal end. Although the FEPI application needs to handle these cases, the access program need not test for all possibilities. The suggested method is to test only for the expected data or screen image and use a special error-handling program if the test fails.
Other applications may require more sophisticated programming. In some cases, you not only have to understand all the displays and protocols of the back-end application, but must also be conversant with the detailed data stream protocols. Applications may have to be custom-written for each device and type of target that is to be supported.
Syncpoints are not needed and not applicable in FEPI because communication environments do not provide any recoverable units of work. It is up to you to provide the syncpoints and any recovery of data that you need. For particularly critical operations with the back-end applications, you may find that using "definite responses" is helpful; see DRx responses.
The begin-session handler transaction is started by FEPI when a connection is acquired. This transaction handles any functions that are required to initialize the session. Typical tasks are:
Device queries are sent by the back-end system (particularly CICS®) if the terminal definitions so demand. You would normally reply ‘null’ (as illustrated by the begin-session sample program), or with some particular terminal properties that you want. Note, if you want to match the terminal properties to those of the real front-end terminal that an application is using, you cannot use a begin-session handler; each application will have to do its own begin-session handling.
When a back-end system sends a message after a successful bind, the connection should be in a pool where the INITIALDATA property is set to INBOUND. For SLU2, IMS™ always sends such a message; CICS may or may not do so depending on the way your system is defined. This extends the process of acquiring a connection to include receiving the data. Note that, if INBOUND is specified, the begin-session handler (or each application program, if there is no begin session handler) must issue a FEPI RECEIVE command to get the data and then send a suitable reply to the back-end system.
Remember that handling this initial data is just like handling any other back-end data: you must cope with whatever the back-end system may send, and handle and reply to it accordingly.
Security requirements in the back-end system might make it more appropriate for sign-on to be part of the access program. (Information about implementing signon security is in Signon security.)
There is a sample begin-session handler program; see Begin session.
The unsolicited-data handler transaction is started by FEPI if inbound data arrives on a connection for which there is no current conversation.
Unsolicited data can occur when:
The unsolicited data should all be received by the handler, even if it is only to be discarded. Otherwise, although FEPI eventually discards the data, it also ends and restarts the session, which is inefficient.
There is a sample unsolicited-data handler program; see Monitor and unsolicited data-handler.
The end-session handler transaction is started by FEPI when a conversation ends or a session is to be unbound. This could be used as follows:
There is a sample end-session handler program; see End-session handler.