 |
 |
||||||||
|
 |
||||||||
|
|
 |
Across the Boards - Dialog Terminal Scripting
Dialog - Scripting for Terminals
Dialog provides scripting functions to Across the Boards applications. While providing general scripting functions, Dialog focuses on terminal control and management. With the ability to run stand alone or embedded into an application, Dialog can greatly simplify an application's interactions with a host.
The need for terminal scripting
An application that interacts with a host application via a terminal must cope with a system that is typically designed for human interaction, not for the convenience of PC applications. Many of the functions required are navigational in nature and contribute little to the overall logic of an application - yet must be automated for the PC application to be successful. For example, most hosts require a logon procedure before granting access to the application of interest, and a logoff afterwards. Further, accessing an application may require responding to various prompts and menus to get to the screens of interest.
 Traditional terminal emulation with Dialog |
While an Across the Boards application can manage all navigational issues with XAPI, this involves a considerable amount of logic with little relevance to the application, not to mention hard coding the navigational code in the application. Dialog is a layer on top of XAPI that presents a high level view of the terminal to the application.
Dialog is specifically designed to navigate through host sessions and to manipulate terminals. It reduces the program code required for navigation to the specification of the navigation itself. Dialog also allows the navigational logic to be separated from the application, making it easy to maintain and change.
For example, if an application is sitting at a mainframe signon screen, a Dialog script to perform the logon might consist of two lines:
send home 'jsmith' tab 'pswd' enter waitfor 'Signon is complete' or 'Invalid password'
In reality, signons are usually much more complex, involving several user interactions, several terminal screens, and numerous choices to make based on displayed messages. For example, a mainframe application logon might start at a VTAM menu, require a "LOGON APPLID" command to be entered, and then display a TSO signon screen. After sending the user ID and password (on a couple of different screens), the host may require the user to change their password, then display a variable number of pages of system news. Only after all that is completed can the application of interest be run. The entire logon sequence can be easily scripted with Dialog.
Scripting for variable conditions
Logon screens are notoriously mutable and are frequently updated, even within a single installation. If you are deploying an application to multiple installations, code may need to written to support dozens of variations on the basic process. Dialog, by making it easy to adapt to changing conditions, can reduce or eliminate the need to update the application's logon logic when host changes its behavior. Since Dialog allows the scripts to be completely separated from the application, an application can leave the entire process customizable, and specify little more than the name of the script file Dialog should run.
Logon sequences are not the only navigational issues an application may face when dealing with host applications, but they're usually the first one. After signon, the application may have to navigate around different applications or different screens within an application. Again, Dialog can greatly simplify that process and externalize the scripting from the application.
| Next Page >> |
Home | About Us |
Products | Tech Support
| Contact Us