Advanced Program to Program Communication or APPC for short, is also known as LU 6.2. It is a network protocol defined within IBM's Systems Network Architecture (SNA) strategy.

APPC enables two programs, on different CPU's, to communicate with each other. A CPU can be a programmable workstation (PWS), such as a Personal Computer, or a mainframe-style CPU, such as an AS/400 or System/370.

APPC is a set of routines which define how two different operating systems will communicate over different types of networks. APPC routines must be present on both CPUs in order for an APPC conversation to be established. The conversation structure consists of an initiator program and an acceptor program that are used only to set up the conversation.  Once the conversation is started each program has a send and a receive state, whereby they can exhange information.

The greatest benefit of using APPC is the speed of data transfer.  APPC allows two programs on different CPUs to have direct access to each other without the need for screen manipulation. This is especially beneficial when accessing host information.

A typical application using the APPC protocol might involve a user viewing and updating data on a mainframe database by way of a PC application. Query statements can be generated within the PC application and sent directly to the host, via the APPC protocol, where they can be processed and the results sent back to the PC. In addition, data can be collected inside the PC application and sent to the host for posting into the database.

The ESL implementation of APPC makes it easy to set up a conversation with another CPU. ESL provides a high level interface to the APPC Application Program Interface (API) by means of a Dynamic Link Library (DLL) called "ESLAPPC.DLL."

An ESL application could query data from a user, format it properly, and then send it to the host via a subroutine called APPCSendString. On the receiving end, the host must have a program which accepts the incoming string, processes it, and then sends back any results if necessary.

In an ESL program, APPC subroutines can be used to perform the following functions:

·        Start a conversation

·        Send data

·        Receive data

·        Get conversation information

·        End a conversation

ESL supplied Software ESLAPPC.DLL and ESLAPPC.INC

These files contain the C and ESL subroutines and constants used to communicate with ESLAPPCI.EXE (INITIATOR) or ESLAPPCA.EXE (ACCEPTOR).

ESLAPPCI.EXE and/or ESLAPPCA.EXE

These files are the Transaction Programs (TPs) that communicate with third party package that provides access to APPC

ESLAPPCI.INI and/or ESLAPPCA.INI

Holds profile names and their parameters

Communications Software

As there is no built-in support of APPC on the Windows Platform, access to this feature must be provided by a third-party package.

The 3 recommended 3270 and 5250 Emulator products (Personal Communications, Extra! and Rumba) all include access to the APPC method of communication.

Network Hardware

Coaxial cable, twisted pair cable, token ring cable, wireless network or Internet access via modem, digital subscriber line or Broadband.

The following table summarizes the APPC subroutines. Following the summary, each subroutine is discussed in detail.  In this table, the subroutines are grouped by the functions that they perform.  Each subroutine is listed alphabetically within the section.

Profile Access

Conversation Control

Send/Receive String Data

Send/Receive NON-String Data

Confirmation Processing

Changing Conversation States - Controlled Interface

Utility Subroutines

The following lists available stimulus events for ESL APPC.

To start an ESL APPC trace Add the following entry to your environment variables:

Variable    = ESLAPPC

Value        = <drive>:\<path>

Trace information will automatically be written to the file "ESLAPPC.TRC" in the path specified as soon as program execution begins. If the file already exists, then trace records are appended to the data already in the file.

The trace information will look like this.

12:47:50:94 154 AllocShrBuffer: Address= , SubAllocCount=, Size= A637034C 00000004 14

12:47:50:97 154 ESLAPPCI:  Entering TP -prty rc , class, level 00000000 00000200 29

12:47:51:07 154 Call DosSemClear 00000000 00000000 29

12:47:51:38 154 NONE// 00000000 00000000 29

12:47:51:82 154 TPCnv - After allocate: APPC ConvType, SyncLevel, rc  00000001 00000000 0

12:47:52:00 154 ESLAPPCI:  Call CommonProc - Auto 00000000 00000000 1

12:48:06:60 155 AllocShrBuffer: Address= , SubAllocCount=, Size= A637035C 00000005 14

12:48:06:63 155 ESLAPPCA:  Entering Accept TP -prty rc , class, level 00000000 00000000 2

This information can be sent to the ESL Help Desk for further analysis.

The issue of when to use a short conversation (i.e. one transaction per conversation) and when to use a long conversation (i.e. many transactions that reuse the same conversation) can often be a complicated one.  There are many variables that come into play when trying to determine how to best manage resources.

If allocating a new conversation for every transaction would incur more overhead than your performance requirements can tolerate, use a long conversation.  If, however, you keep your conversation up for extremely long periods of time, you may be consuming vital resources that are needed by other applications.  

Consider the following:

·        The resources that the network allocates to service your conversations.  There is a session, a route, band width, data buffers, control blocks, and so on, reserved for your conversation.  While your conversation is active, no other application  can use these resources.

·        The resources that are consumed by your partner application while the conversation is active. Again, data buffers, control blocks, program memory, dispatching overhead and so on, are allocated to your partner program and unavailable to other applications.

So the trade-off boils down to this:  resource allocation time versus resource utilization.

If your application does hundreds of transactions per second, chances are the resources are fully utilized and a long conversation is justified.  The overhead of allocating a conversation for each transaction would be intolerable.  On the other hand, if your application does one transaction per minute, then chances are the resources are mostly idle. During this idle time, other programs could make good use of the resources, but they cannot do so because the resources are allocated to your conversation.  In this case, short conversations are justified.  Your application may run a little slower, but the overall system performance, considering all the other applications, will be much better.

As network and system capacities increase, this trade-off may become less important and long conversations may be acceptable in most situations.  However, as the number of simultaneous workstation applications increase, this trade-off becomes an issue once again.  Long conversations may require inordinately large resource allocations in order to support all the simultaneous applications.

There are several design considerations that must be taken into account when designing applications that will use APPC to communicate with one another.  The perspective that is often taken, is one of a "local" application, resident on a particular workstation, doing APPC to some "remote" application that resides on another PC.  However, the  terms "local" and "remote" are really not applicable in program-to-program data communication.  The perspective changes so freely you can never quite be sure which program is local and which program is remote. Instead of local and remote, we recommend using the terms "client" and "server".

Clients and servers are designed in pairs.  The data they exchange and the rules they follow must be understood by both programs.  They work as partners to complete the transaction.  When designing clients and servers, the most common design flaw is an incomplete specification of the rules they will follow.  The temptation is to choose some generic over simplification such as "if the program has data to send it will start a conversation" and then let all the other rules remain unspoken.  The best, most robust designs, are those which document even the most trivial of rules.  As a minimal test of completeness, make sure your rules can answer these questions:

When and how will the server program be started?

When and how will the client program be started?

When will a conversation be allocated?

When will a conversation be de-allocated?

When will a program request permission to send and what criteria will be used by its partner to decide if the request should be honoured or ignored?

When will a partner program be given permission to send?

When will confirmation be requested?

When is it safe to grant confirmation?

When is data sent and how is the data formatted?

When is data received and what data checking must be performed before the data is used?

When should a program force its data to be sent to its partner?  (Note, APPC packs data into internal buffers to optimise network overhead. Sometimes processing overhead can be improved by forcing the data to be sent immediately, with a FLUSH verb, for example).

When will an error be reported, how will the error be identified, and what error recovery will be performed?

Consider the following scenario:

An APPC application on the PC wants to send database inquiries to a CICS Host and receive replies.

However, some CICS mainframes must deallocate APPC conversations after each reply. Can a Host program that:

·        runs continuously,

·        reads requests from one APPC conversation and

·        sends replies on another conversation

be setup on a CICS Host?

CICS supports two 3270 application models:  conversational and pseudo-conversational.  A conversational application is a single application that displays every screen, monitors every interrupt key (Enter or PF1 for example), and processes all the data entered by the terminal operator.  A pseudo-conversational application is a collection of programs where each program sends one reply (one screen or menu for example), prepares a list of programs to be invoked next, and then terminates.  When the operator presses an interrupt key, the list provided by the last program is searched and the program that was associated with that particular interrupt key is invoked.  That program repeats the process and the processing flow skips from one program to the next, depending on the keys pressed by the terminal operator.

Pseudo-conversational applications have a huge performance benefit, both in average response time and average transaction throughput. While a 3270 operator is thinking, the conversational program remains in memory and consumes CICS resources (memory, buffers, control blocks, dispatch processing).  However, during that same delay, a pseudo-conversational program releases its resources allowing CICS to use those resources while servicing other terminals. With less CICS resource contention, every user's performance improves.

There are several possibilities, all of which are supported by APPC:

·        Make inquiry requests into small inquiry transactions where your PC application could allocate a conversation, send a request, receive a reply and deallocate the conversation for each inquiry. This is the same as a CICS pseudo-conversational application.

·        Allocate a single, long running conversation, on the PC and use it repeatedly for any number of inquiry requests and replies.  This is the same as a CICS conversational application).

·        Use a full duplex conversation where requests are received on one conversation and replies are sent on another.