Front-ending in MacApp

Paul Ens

For those of us who see a Macintosh Plus as little more than a paper-weight with a power supply, the days when the dumb terminal ruled the cutting edge seem as ancient as the rule of the dinosaur. However, despite the recent hardware and software advancements in microcomputing, the dumb terminal is still widely used for the day to day business of many of today's corporations. These companies continue to live with the limitations of character-based technology because the advantages of an object-oriented graphical user interface does not outweigh their existing investment in mainframe hardware and software development.

The Macintosh boasts an array of applications that emulate VT100, 3270, and 5250 terminals. These applications allow corporations to give their employees access to the latest in word processing, spreadsheet and electronic mail applications, while continuing to use mainframe-based corporate databases and in-house applications. Unfortunately, these applications tend to pale when compared to Macintosh applications. It doesn't take long for users to expect the Macintosh look-and-feel from their mainframe applications.

BLACKSMITH

The desire to take advantage of today's user-interface technology without losing investment in existing mainframe systems has spawned a new genre of personal computer software called "Front-Ends".

A "Front-End" is a microcomputer application that provides a user-interface for one or more applications on a remote host system. The front-end accesses the host through communications hardware attached to the workstation or its network. Since the front-end's interface hides the host application's screens from the user, the front-end must be capable of interacting with the host in the ways that a user normally would.

Creating a front-end application is usually quite straight-forward. Once all of the screens and functions of the host application have been identified, a Macintosh interface should be designed that will easily and intuitively allow the user access to the same information and functionality. This interface can then be created and tested using the existing MacApp class library.

Once the interface exists, the user's actions and requests need to be relayed to the host system. A product called BLACKSMITH from CEL Corporation provides a set of tools to enable developers to interact with various host systems. The core of BLACKSMITH is a driver. It is accompanied by interfaces to 4th Dimension, Hypercard, Omnis 7, Pascal, C and MacApp. Interfaces to Prograph and Serius are also in the works.

Opening a Session

The core of BLACKSMITH's MacApp interface is the TBSmithSession class. This object class represents a single connection to a host system and provides a number of methods designed specifically for developing sophisticated front-end applications.

Once a TBSmithSession object is created, the developer must select a connection method and initiate communication with the host:

TBSmithSession * mySession = new TBSmithSession;
mySession->IBSmithSession();
mySession->OpenMethod(b_Netway);
mySession->OpenSession(&port, b_PoolName, luName, key
                                b_NewSession, b_ModelAny,
                                b_TerminalSession, returnName);

BLACKSMITH supports virtually all major Macintosh 3270 and 5250 communications hardware products, including MacIrma, MacMainframe, Netway, SNA•ps, NetAxcess, TokenAxcess, TCPAxcess and VT100. Modules for Novell, TN5250, TN3270 and TNVT100 are in the works.

Also supported is a "Dummy" access method which simulates a connection to a host based on screens saved during an actual connection. This "Dummy" method can save significantly on dial-in charges when development or testing must be done remotely. It is also useful for doing demonstrations or proof-of-concept presentations in locations where physical connection to the host is unavailable.

Host Interaction

Reading and Writing Data In order for a front-end to present data from its host applications and to feed the user's action to the host, TBSmithSession maintains a "Presentation Space". This block of memory is the equivalent to the characters of the display of a dedicated terminal. All user activity is expressed through modifications to this presentation space, while all host activity is reflected in the presentation space.

TBSmithSession provides two methods for reading the text of the presentation space: ReadPS and ReadBlockPS. ReadPS reads a number of characters from the presentation space, starting from a specified position. ReadBlockPS reads the block of text from the presentation space enclosed by a set of row and column coordinates. Similarly, WritePS and WriteBlockPS insert text into the presentation space.

A typical host application is designed to accept text input ending with a control key prompting the host to accept the data and perform an action. This style of interaction is accomplished with TBSmithSession through the WriteKeys method. This method sends a string of characters to the host as literal key strokes. Control characters like PF keys, tab and enter keys are designated by a set of character combinations, such as "@T" for tab. The following example would type "User Name", then a tab, "password" and then enter:

mySession->WriteKeys("\pUser Name@Tpassword@E",&sent);

Fields

Most host applications format the presentation space by dividing it into a number of fields. These fields can be either protected, or unprotected. Protected fields cannot be changed by the user and are typically used for displaying text labels or unchangeable data. Unprotected fields are intended for user input.

On a standard terminal, attempting to type into a protected field causes the terminal to go into an "input inhibited" mode. In this mode, further keystrokes cannot be processed until the terminal is reset. It is important for a front-end to be fully aware of the current field layout of the presentation space to avoid such terminal locking.

TBSmithSession provides a number of methods to search for fields and provide information about them. For example:

TBSmithSession::FindField( short findType, short *pos, short *len,
                                    short *wLen, short *attr);

The findType determines if the search is to move forward or backward from the specified position, and if the search is to include protected fields, unprotected fields, or both. FindField returns the position and length of the found field. It also returns an attribute byte which tells you if the field is protected or not, as well as its color and other display characteristics.

Other methods for finding the location of screen elements include FindString, FindFieldList (providing a list of all screen fields) and FindFieldIndex.

Status Line

Dedicated terminals have a status line (called the Operator Information Area, or OIA) containing a string of symbolic characters which provide information about the status of the user's session. The OIA reports when the session is waiting, when it is locked (input inhibited) and other session conditions.

It is important for a Front-End to monitor the state of the session in order to recover from errors, or to provide feed-back to the user. The status line can be read using the ReadOIA method:

TBSmithSession::ReadOIA (Str255 oia);

Screen Traversal

While the read, write and find methods of TBSmithSession are useful for dealing with individual host screens, another important element of a robust front-end application is screen traversal. Screen traversal involves identifying the current screen, and navigating the host from there to another screen, as well as dealing with exception handling and complex timing issues.

Pattern Matching

Before a front-end can navigate somewhere, it must know where it is. Even if the front-end is the only user of a session, it can be dangerous to make assumptions about its "location". Most host systems include features like time-outs and information broadcasts which can change your session's location without warning. In order to positively identify the current screen, a front-end needs to check the presentation space for the presence or absence of certain elements.

TBSmithSession provides a powerful pattern matching system to facilitate screen identification. The base of this system is the PatternMatch method:

TBSmithSession::PatternMatch (Str255 pattern,  short* matched);

A pattern is a group of strings which are searched for at specific locations of the presentation space. If the PatternMatch is successful, matched will be returned with a value of zero. If the session is busy when PatternMatch is called, it will return -1. Otherwise, an index to the first element of the pattern to fail will be returned.

A pattern string contains a number of components delimited by ¶ (option 7) or • (option 8). The first component is the pattern type. Currently, only a pattern of type 1 has been defined. Additional components describe an area of the screen followed by a string (or strings) to check for within that area. A pattern's second component must contain a list of indexes to the screen area descriptions. The search area can be specified to be a particular row, a block of text, a cursor-relative area or the entire screen.

For example, if one of your host screens contains the string "Enter Command:" somewhere on the screen, you could detect it with the following pattern: "1•3•0•Enter Command:". The "3" in the second component tells TBSmithSession that the third component is the only screen area description. The zero in the third component means that the string should be searched for anywhere on the entire screen. The fourth component is the string to search for.

While this pattern structure can be quite confusing at first, the complexity is outweighed by its flexibility and power. This flexibility is especially apparent for more complex screens. Consider the following pattern:

"1•3,6•1•Main Menu•File Menu•5,10,1,20,15•Save Changes"

As indicated by the "3,6" in the second component of the pattern, PatternMatch will be checking in two regions. One check will take place in the region described in component three, the other in the r1egion described in component six. The "1" in component three means to search for strings on row 1. So, if either the string "Main Menu" or "File Menu" appear in row 1, the pattern can succeed. Component six describes the block of characters enclosed by row 10, column 1, row 20 and column 15. If this area contains the text "Save Changes", then the pattern can match.

Another TBSmithSession method, DoReady, accepts a list of patterns and returns an index to the first matching pattern. With this command, a front-end can rapidly check the current screen against a large database of possible patterns.

Traversing

Once the current screen has been identified, a front end can execute the appropriate key-strokes to navigate to its desired screen. This is generally done using WriteKeys to send a sequence of text and control keys to the session.

Once the data has been sent, the session will be busy for a period of time processing the request. If the front-end needs to continue traversing once the session has completed the request, it must monitor the session's status until it is free. Once it is free, the front-end should again check the current location to ensure no errors took place, and then take appropriate action based on the new location.

Much of this monitoring can be accomplished by using the TBSmithSession method DoWaitTillReady. DoWaitTillReady accepts a list of patterns, along with a tolerance and settle time, and waits for one of the patterns to match. If one of the patterns successfully matches for at least as long as the specified settle time, the index to that pattern is returned. If none of the patterns match within the specified tolerance time, an error is returned.

Example: Logging In

Most host systems begin a session with some sort of title screen and log-in sequence. Logging in to a host is a typical front-ending task. A front-end application would provide a friendly method for a user to identify themself and enter their password. It would then use this data to automatically navigate through the host's log-on sequence.

After creating an instance of TBSmithSession and opening a connection to the host, a front-end would create a list of patterns representing the screens involved in logging on to the host:

splashScreen = "1•3•0•Welcome to the Mainframe";
passwordScreen = "1•3,5•15•Enter your id:•17•Password:";
mainMenu = "1•3•1•Main Menu•File Menu";

TBSmithPatternList * logonList = new TBSmithPatternList;
logonList->IBSmithPatternList();
logonList->Insert(mainMenu);
logonList->Insert(passwordScreen);
logonList->Insert(splashScreen);

Next, it must find out what screen the mainframe is currently on:

short whatPat;
whatPat = mySession->DoWaitTillReady(logonList,120,20);

Once the screen has been identified, the appropriate actions can be taken to arrive at the main menu:

if (whatPat == 3)  {   /* if matched splashScreen */
    err = mySession->WriteKeys("\p@E");    /* Hit Enter */
    logonList->Delete(3);    /* Remove splashScreen from list */
    whatPat = mySession->DoWaitTillReady(logonList,120,20);
            /* do another DoWaitTillReady to see where
                 the session is now. */
};

if (whatPat == 2)   {   /* if matched splashScreen */
    err = mySession->WriteKeys(userName);
    err = mySession->WriteKeys("@T");      /* Hit Tab */
    err = mySession->WriteKeys(password);
    err = mySession->WriteKeys("\p@E");    /* Hit Enter */
    logonList->Delete(2);
    whatPat = mySession->DoWaitTillReady(logonList,120,20);
};

if (whatPat == 1)   /* if matched on main menu */
    success = TRUE;

other features

Terminal Emulation

Developing and testing a front-end application requires regular monitoring of host sessions. Users of front-ends will often need access to the host session in order to use portions of the host applications that are not front-ended. To facilitate these needs, BLACKSMITH provides a fully-functional terminal emulation window encapsulated in the TBSmithTerminal class, a subclass of TWindow.

A TBSmithTerminal can be customized in a number of ways. It provides methods to change the display colors, font and font size. The mapping of the Macintosh keyboard to standard terminal keys is also completely customizable. Individual keys can even be assigned complex macros.

A powerful recording facility is built-in to TBSmithTerminal. This facility allows a developer to record the keystrokes of an experienced user moving through the various screens of a host application. This recording can be played back later for reference during the front-end's development process.

File Transfer

TBSmithSession also provides a number of methods that enable a front-end to transfer files to and from the host. Currently, only IND$FILE transfers on CICS, TMO or CMS host systems is supported.

conclusions

Front-ending is an extremely valuable tool for corporations who rely on mainframe applications. A front-end will decrease the cost of computing by moving host processing to the Macintosh which is much more efficient at user-driven, non-data intensive tasks. While it can sometimes take months to modify a host application, a front-end can be modified very quickly, at any time. It is also possible for different areas of the same organization to customize their front-end to meet the needs of their division without having to alter the original host application.

BLACKSMITH provides first-rate tools for creating powerful front-end applications, including support for most major communications hardware, advanced screen manipulation, pattern matching, full terminal emulation, screen recording and file transfers. These tools, combined with the power of MacApp can allow in-house developers or consultants to give new life to old programs.

A Windows version of BLACKSMITH is expected to ship in February 1993 and support for Bedrock is being planned.

CEL Corporation, the author of BLACKSMITH, can be contacted at (403) 463-9090, P.O. Box 8339, Station F; Edmonton, Alberta; Canada; T6H 4W6, AppleLink: CEL.MKTG. You can also get information about BLACKSMITH from CEL's folder in the Third Party folder on AppleLink.