cfSOFTWARE Contact Us Technical Support About Us cfSOFTWARE

corner
Across the Boards
Introduction
System Specs
APPX Peer-to-Peer Communications
APPX Router
Dialog - Terminal Scripting
XAPI - Terminal Access and Control
New Features and Updates
Request a Trial
corner
   Across the Boards - APPX Peer-to-Peer Communications

Across the Boards - APPX Peer-to-Peer Communications

pages


APPX Operation in Detail

There are three main issues to understanding the character of the APPX co-processing solution: the idea of an APPX session, send and receive modes, and the asynchronous nature of processing by two peers in an APPX session.

The session
The APPX session is established once two peers successfully execute APPX Connects. During an APPX Connect, PC and mainframe applications exchange information required to establish a link, such as the maximum block size each peer can receive, character translation information according to the physical link, the actual CICS translation to invoke, etc. Once the session is established it remains active until it is terminated by an APPX Disconnect or by a fatal communication error. In a session, one peer (usually the PC) originates the session while the other acknowledges the request. The originating peer is the first sender after the session is established.

Send and receive modes
At any given point during a session, one peer is the sender and the other peer is the receiver. Peers frequently swap rolls as the session progresses. For example, if the PC is the sender it requests data from the mainframe. It then relinquishes control and becomes the receiver of information. After the PC has received the data from the mainframe it will again be the sender, ready to send additional requests to the mainframe.

Under normal conditions the state of the session is controlled by the sender. The sender remains the sender until it explicitly becomes the receiver by issuing an APPX Receive. The other peer automatically becomes the sender in when this happens (this is known as turnaround). The receiving peer may anticipate this turn of control or it may wait until it is told explicitly by APPX that a turnaround has occurred. The receiving peer anticipates the turn if it knows exactly how many records will be sent. Without anticipation, many records may be sent in response to a simple query, and the turnaround might be indicated by a simple "end of file" condition. Both approaches are used in the sample application.

Asynchronous processing
In order to maximize performance, both in terms of communications traffic and in providing opportunities for parallel processing by the two peer applications, APPX avoids strict synchronization between the two peers in the APPX session, except at certain points.

Asynchronous processing occurs because the two peers run in parallel on different machines. In addition, issuing an APPX Send does not necessarily physically send anything to the peer. Sends are buffered and blocked for transmission efficiency just as writes to a tape drive are. A group of records is sent only when the buffer is full or when synchronization is needed, or is explicitly requested by the application. For instance, when the sender becomes the receiver, any records left in the buffer are physically sent so that the other peer can receive them and then become the sender in turn.

While APPX provides primitives for forcing synchronization, the vast majority of applications require only the implicit synchronization performed automatically by APPX. In most applications, a sender will immediately become a receiver after completing its task, and APPX automatically takes care of synchronization.

Other APPX Features
The APPX Advanced Compression Option adds highly efficient data compression to APPX sessions. ACO increases throughput by 100-150% for typical data streams. See the Across the Boards and pcMAINFRAME Advanced Compression Option Performance Analysis White Paper (PDF file 60kb) for additional information .

APPX support many different types of communications devices. In addition to terminal oriented devices such as 3270 emulators and coax cards, APPX supports LU6.2 and TCP/IP native communications. These provide the highest performance links available. The use of these different communications links is largely transparent to the APPX application, and an APPX application can be deployed using a variety of host connects, as appropriate for each installation.

Providing high performance, wide support and ease of use is the embedded TN3270 emulator available in Across the Boards. APPX can use the TN3270 support in structured field mode, providing excellent throughput, from anywhere that a TN3270 connection can be established to the host. The TN3270 session exists independently of any other 3270 emulation on the client PC, and so does not interfere with other users.

The APPX Router provides a high-speed gateway between the mainframe and the client PCs. Using LU6.2 to connect to the mainframe and TCP/IP to connect to the PCs, it provides the best communication option for both systems. In addition, the APPX Router offloads work from the mainframe, and adds additional security and access control for users coming in via TCP/IP connections. As always, use of the APPX Router is largely transparent to the APPX applications.

In conjunction with the APPX Router, APPX provides for link level encryption and authentication on APPX sessions, providing solid security for deploying APPX applications over the Internet.

APPX supports both sessions initiated from the PC and from the mainframe. From the mainframe an APPX application can initiate a session to a PC connected via a terminal (e.g. 3270) device, LU6.2 or TCP/IP. The host can also start a session to the PC via the APPX Router. Sessions can also be started from host to host.

Like all other portions of Across the Boards, APPX is thread safe can support hundreds of simultaneous sessions for server applications as easily as a single session for a client application. APPX can be used in web (and other) servers to access mainframe data.


<< Previous Page Next Page >>