 |
 |
||||||||
|
 |
||||||||
|
 |
Across the Boards - XAPI - Terminal Access and Control
Terminal Access and Control with XAPI
The XAPI solutionXAPI is used when a true peer-to-peer solution (using cfSOFTWARE's APPX, for example) is not feasible. This occurs when an author of a PC application does not have access to the mainframe application or when the amount of effort required to alter the host application is too large.
The basic idea behind using XAPI to front end a mainframe application is very simple: XAPI provides the PC application with an interface to the "front side" of a terminal. In the case of a mainframe application, this would likely be a 3270 terminal. That is, XAPI allows the application to do things like: look at the 3270 screen, extract data from it, and "press" keys on the 3270 keyboard.
While a developer may use a single API or hardware interface provided by a 3270 emulator, gateway, or protocol converter to accomplish this, the application would lose functionality when presented with a different communications facility. It also leaves the application dependent on an installed emulator. XAPI's advantage is that it unifies all of these interfaces and presents a single API to the PC application, which in turn gains portability. XAPI also provides embedded terminal emulators, which eliminate the need for additional terminal emulation software to be deployed on the end user's workstations. XAPI also provides other conveniences to the PC front end. It allows the front-end application to access multiple connections to one or more mainframes even if the connections are made with different hardware. For example, a PC could have one coax connection to a mainframe via an IBM 3270 coax card, be connected to another mainframe via a dial-up protocol converter, and have a third connection to a host via a TN3270 connection.
XAPI supports many simultaneous host connections, and is thread safe. XAPI can be used in a server environment to handle multiple simultaneous requests for host data (for example, a web server might use XAPI to retrieve host data).
The Dialog solution
Dialog provides a higher level of control than XAPI. Dialog executes scripts that can be used to navigate around a mainframe application, and otherwise interact with the terminal. In addition to its scripting facility, Dialog provides a full screen terminal emulator which can be activated at any time during the execution of a script.
The following Dialog script fragment executes the common CICS application "CEMT" to reload a program and then exits back to CICS.
SEND 'CEMT SET PRO(CFX011) NEW' ENTER WAITFOR 'STATUS:' SEND PF3 WAITFOR RESPONSE SEND CLEARScripts can be defined in the source code of the application or can be defined in external files. Scripts are easy to write and can easily be modified if the host application changes. A script can even be generated dynamically.
While an application using Dialog can do nothing that a pure XAPI application cannot do (Dialog is, in fact, an XAPI application), using Dialog and XAPI together can simplify a PC front-end application tremendously. Easy to code and maintain Dialog scripts can be used to navigate around the host application, while XAPI is used to access data.
Online and offline front ends
Across the Boards allows an application to front end a mainframe application with a PC application in two simple ways. These can be described as "Online" and "Offline."
An online front end interacts with the user while accessing the mainframe application. From the user's point of view, the front end is accessing the mainframe on the user's behalf, possibly extracting selected data from screens or accessing different screens to consolidate data. The front end provides a friendlier interface that reacts according to the user's needs.
An offline front end interacts solely with the user, and then, at intervals, sends all of its activity to the mainframe.
The distinction between offline and online is not clear-cut. For example, a "pure" offline order entry system might allow all orders to be entered on the PC, then transfer them to the mainframe at the end of the day. A "pure" online order entry system might allow the PC front end to communicate with the mainframe for each line item on the order. In the middle we might find a PC based order entry system that handles the entry of an entire order at the PC and sends it to the mainframe when the user finishes entering the order. A front end might also be composed of several subsystems, some of which are online and others are offline. For example, the order entry system might be fully offline, but might access the mainframe "credit approval" system in an online fashion if an order being entered exceeds a certain dollar limit.
Two major types of activities
A PC application that uses XAPI or the combination of XAPI and DIALOG to front end a mainframe application will engage in two major types of activity. It must find its way to the correct mainframe screen and then extract data from, or enter data into, that screen. Most often the cycle is repeated many times. The navigation function can be coded with XAPI, or it may use be done with Dialog scripts (written for, or generated by the application), while XAPI extracts and modifies data on the screens.
| << Previous Page | Next Page >> |
