Please enable JavaScript to view this site.

ESL Documentation

Navigation: ESL Documentation > ESL APPC Support > Overview

How ESL APPC Support Works

Scroll Prev Top Next More

ESL APPC support consists of the following:

ESLAPPCI.EXE

An initiating transaction program (TP).

ESLAPPCA.EXE

A transaction program that accepts an initiation request.

ESLAPPC.DLL

A DLL containing ESL APPC externalized subroutines and common routines.

Example:

The following example describes how an APPC conversation between two hypothetical ESL APPC programs (PROGRAM1 and PROGRAM2, on different machines) would be established and would proceed. Both programs are designed to be capable of sending and receiving. The example illustrates use of the automatic interface.

The ESL Runtime Facility and PROGRAM1 start. (The ESL APPC profile already exists, and PROGRAM1 uses it to determine what program to invoke at the remote machine.) To initiate the APPC conversation, PROGRAM1 calls the APPCStart subroutine. APPCStart obtains storage for a conversation control block, starts the ESLAPPCI.EXE transaction program as a separate process, and returns a conversation identifier (a handle) to PROGRAM1.

The ESLAPPCI.EXE TP operates asynchronously to the ESL Runtime Facility process. ESLAPPCI.EXE issues the APPC verbs TP_STARTED and MC_ALLOCATE to start the conversation. If a startup error occurs at this point, ESLAPPCI.EXE indicates the error by POSTing a message to ESL.

The MC_ALLOCATE verb triggers your communciations program in the remote machine to activate the ESLAPPCA.EXE TP. (Note that you may also start ESLAPPCA.EXE at the remote machine; simply wait for the initiation request.) When ESLAPPCA.EXE is started, the ESL Runtime Facility and PROGRAM2 are presumed not to be running. One or more ESL programs, unrelated to APPC communications (along with one or more copies of ESL), may in fact already be running at the remote machine. However, it is only the specific ESL program(s) configured to participate in APPC conversations­PROGRAM2 in this case ­that ESLAPPCA.EXE attempts to start.

The ESLAPPCA.EXE TP issues a RECEIVE_ALLOCATE APPC verb. If that is successful, ESLAPPCA.EXE gets a conversation block and then looks at the ESL APPC profile to get the invocation command needed to start the ESL Runtime Facility and PROGRAM2. When PROGRAM2 gets control, it must call the APPCAcceptStart subroutine to get the conversation ID. If the ESL Runtime Facility and the ESL partner program are not successfully started, ESLAPPCA.EXE issues an APPC MC_DEALLOCATE verb with the ABEND indication.

Unless an error notification is received, the conversation between the two ESL programs proceeds. Keep in mind that the APPC protocol allows only one program at a time to be in Send state, and while it is in Send state, its partner must be in Receive state.

PROGRAM1 calls the APPCSendString subroutine, and a request to send is queued to the ESLAPPCI.EXE TP running locally on its machine. The TP then checks whether the conversation is in Send state. If so, the TP issues the MC_SEND_DATA APPC verb, and the data is transmitted (immediately or eventually, depending on whether the data was forced).

If the conversation is in Receive state, the ESLAPPCI.EXE TP issues an MC_REQUEST_TO_SEND APPC verb followed by an MC_RECEIVE_AND_POST. Its partner TP (ESLAPPCA.EXE), which by implication currently has Send state, then receives the request to send notification as a response to its next MC_SEND_DATA request.

When the partner TP (ESLAPPCA.EXE) is inactive for a certain amount of time after data was last sent, an internal timer goes off. This causes ESLAPPCA.EXE to issue an MC_TEST_RTS verb to check whether a request to send is pending. When it receives the request to send from the ESLAPPCI.EXE TP, ESLAPPCA.EXE completes sending any queued data and then issues an MC_RECEIVE_AND_POST verb. When data from ESLAPPCI.EXE arrives, the ESLAPPCA.EXE TP places it in a local queue and POSTs a message to the ESL runtime, which in turn triggers the response to stimulus ... APPC_Data definition in PROGRAM2. When PROGRAM2 calls the APPCGetString subroutine, the data is placed in an ESL string variable. An additional message is POSTed for each complete data buffer received.

Note:        The length-of-inactivity timer value is specified in the ESL APPC profile. The timer is employed only in the automatic interface and its use is optional. The timer value can be set to 0 to prevent ESL APPC from switching the conversation state automatically. See the INACTIVITY_TIMEOUT argument in APPCSetInitProfile and APPCSetAcceptProfile for more information.