March 93 - Front-ending in MacApp
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.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
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.