Computer With Terminal Emulation Interface for Multi-Environment Client/Server Applications

This invention relates to computer systems and, more specifically is concerned with integration of such systems.

The introduction of new computer systems and applications is frequently complicated by the existence of legacy systems and applications (ie those already in use by the customer), whose immediate replacement is not practical. It is desirable to provide some way of integrating such legacy systems and applications with new systems and applications, allowing both to be used side-by-side, so that the new systems can be phased in more gradually.

Several integration products are already on the market. However, their coverage is usually limited and they often require some modification to the target application or its host system.

The object of the present invention is to provide a novel means for integration, which reduces these problems.

According to the invention there is provided a computer system comprising a first processing environment, a second processing environment and a gateway interconnecting the environments to allow a client application in the first environment to send service requests to a server application in the second environment, wherein the gateway includes terminal emulation means for emulating a terminal in the second environment, and means for converting service requests from a client in the first environment into dialogues on said terminal by executing scripts in a scripting language.

It will be shown that the invention allows client applications to communicate with server applications in other environments in a way that is completely transparent to the clients. The client is not aware that it is communicating with the server through a dialogue on an emulated terminal; all knowledge of the dialogue is embodied in the scripts.

FIG. 1 is a block diagram of an integrated computer system.

FIG. 2 is a block diagram showing a gateway unit in more detail.

One embodiment of the invention will now be described by way of example with reference to the accompanying drawings.

Referring to FIG. 1, it is assumed in this example that a banking organisation has a legacy computer system consisting of at least one host computer 10 which runs a banking application 11. The banking application maintains customer account data, and can perform various operations such as opening or closing accounts, and transferring funds between accounts. The application is accessible only through dumb terminals 12, e.g. VT100 terminals, connected to the computer 10.

It is assumed that the bank wishes to introduce a new computer system to replace this existing system. The new application runs on a computer system 13 (e.g. an ICL DRS6000 computer, running under the UNIX operating system), and comprises a number of server applications 14. Each of the server applications 14 provides a particular banking service, such as open (open an account), deposit (make a deposit in an account), balance (provide a balance on an account) and transfer (transfer funds from one account to another). The servers are supported by a relational database management system (RDBMS) 15, which holds the customer and account data. The system 13 can be accessed from a number of PC (personal computer) clients 16 which run graphical user interface (GUI) software, to provide a convenient and attractive service to the users. A transaction processing (TP) monitor 18 provides a distributed processing environment in which the PC clients can interact with the server applications. The TP monitor 18 may, for example, be the TUXEDO product. (TUXEDO is a trade mark of UNIX System Laboratories Inc.)

It is further assumed that the bank wishes to migrate incrementally from the old system to the new, one branch at a time. This means that the old and new systems must coexist for some transition period, and that it is therefore necessary to connect the two systems together in some way to provide to users the appearance of a single integrated system.

The way in which the two systems are integrated to achieve this goal is as follows.

The system 13 is provided with a gateway 20, connected to the remote host computer 10 by way of a communications module 21. The TP monitor steers service requests from clients 16 according to the value of a branch identity code in the request: requests relating to accounts held at bank branches that have migrated to the new system are steered to the appropriate one of the servers 15, while requests relating to accounts held at branches that have not yet migrated are steered to the gateway 20, and hence to the remote application 11.

As far as the TP monitor 18 is concerned, the gateway 20 looks exactly like one of the servers 15. On the other hand, viewed from the old application 11, the gateway 20 emulates a VT100 terminal, and converts the service requests from the TP monitor into old-style VT100 dialogues. In other words, as far as the old application is concerned, the gateway looks exactly like one of the terminals 12 of its host system.

The new and old modes of access are indistinguishable to the end-user and the GUI client software, including the ability to transfer funds between the old and new regimes.

The gateway 20 will now be described in more detail with reference to FIG. 2.

The gateway comprises an interface module 30, a script support library (SSL) 31, and an XHLLAPI (extended high level language applications programming interface) 32. The gateway also has associated with it a set of UNIX shell scripts 33 and a set of UNIX shell functions 34.

As mentioned above, the purpose of the gateway is to emulate a terminal for the old application, and to convert service requests from the TP monitor into dialogues between the emulated terminal and the old application. These dialogues are defined by the custom shell scripts 33, each service request having a corresponding shell script. For example, each of the open, deposit, balance and transfer services mentioned above has a corresponding custom shell script. In addition, other shell scripts are provided for functions such as remote logging on to the host 10.

The shell functions 34 provide a set of standard procedures for use by the custom shell scripts.

The interface module 30 is a C language module. As far as the TP monitor is concerned, the interface module acts in the same way as a standard server, advertising its services to the TP monitor, receiving service request messages from the TP monitor, and then issuing responses back to the TP monitor. When the interface module receives a service request from the TP monitor, it derives the name of the corresponding shell script from the request. It then decides whether the script needs to be started. (As will be described, a script may have issued a call to stay resident, and in that case it will not need restarting). The interface module also converts the parameters of the request into shell variables, so that they can be used by the shell script, and converts the results returned by the shell script back into a form usable by the TP monitor.

The script support library (SSL) 31 is a set of C language functions, embodying all the script and session control functionality of the gateway. It presents a high level function interface for use by the interface module, mapping service requests on to script invocations and lower level XHLLAPI calls. The SSL includes a function ssl.sub.-- run.sub.-- script which starts a specified shell script, by means of UNIX fork and exec system calls. It also includes a function ssl.sub.-- wait which waits for termination of a specified shell script and then returns the results of running the script to the interface module. While waiting for termination of a shell script, ssl.sub.-- wait handles any XHLLAPI requests from the shell functions 34. The shell functions 34 communicate with the script support library (SSL) 31 by way of a UNIX pipe interface. XHLLAPI requests from the shell functions are piped to the SSL, and the results from the XHLLAPI operations are piped back to the functions.

The SSL allows an emulated terminal session to be represented to the clients as a set of logical transaction services, implemented by the scripts. The terminal session is owned by the SSL process, and therefore several scripts can be run sequentially on the same session (that is, a session does not need to terminate when a script exits), provided that each script leaves the session in a well-defined state. Thus, a single terminal session can be shared between many clients on a transaction-by-transaction basis. This reduces the number of sessions required and so improves the efficiency of the system.

A separate instance of a custom shell script may be run for each transaction. However, this may be inefficient for frequently used scripts. To reduce this inefficiency, an initialisation script may choose not to exit, but to continue running in parallel to service all subsequent transactions. In this case, when a request arrives at the gateway, it is forwarded to the already running script (using an SSL function ssl.sub.-- send) rather than being used to invoke a new instance of the script. The script itself must loop around, reading new commands (using a shell function tsh.sub.-- receive) and branching to an appropriate routine to service the request.

XHLLAPI 32 is a library of C language functions which perform the terminal emulation, allowing a client program to operate an interactive session with the remote host 10. The XHLLAPI maintains an area of memory referred to as the presentation space (PS) which represents the virtual screen of the emulated terminal, along with a virtual keyboard. It also maintains current cursor and saved cursor values which point to locations on the virtual screen. XHLLAPI provides operations on these resources which simulate a human user's access to a physical terminal, such as screen reading and searching, and processing of simulated keystrokes. XHLLAPI appears to the host as an ordinary interactive terminal, and so no special host software is required.

In this example, the emulated terminal is asynchronous, i.e. it uses an asynchronous protocol to communicate with the host 10. A major consideration with an asynchronous service is how a script is to deduce when the host output has finished. (This problem does not arise for blocked mode protocols, where there is an explicit "keyboard unlocked" state). For asynchronous terminals, the script has to deduce this state from application-dependent changes made by the host to the virtual screen. However, continual reading of the virtual screen by the script over the UNIX pipe interface would clearly be inefficient. For this reason, the shell functions include a tsh.sub.-- pause function which allows a script to declare a set of simply testable events, based on screen contexts and other factors, and to pause while waiting for one of these events to be triggered. XHLLAPI keeps statistics of operations performed on the virtual screen by the remote host, including number of line feeds, characters, and screen clears. These statistics can be used by the tsh.sub.-- pause function as triggers, eg to trigger an event after a given number of new lines have been processed.

The following functions are provided by the script support library.

ssl.sub.-- init options

This function initializes the SSL. It also calls the XHLLAPI.sub.-- INIT function to initialize XHLLAPI, and the XHLLAPI.sub.-- PARAMS function, to pass options parameters. The ssl.sub.-- init function must be called before any other functions are used.

ssl.sub.-- deinit

This function deinitializes the SSL, by freeing memory space and tidying up the memory. It should be the final SSL function called before the system 14 is powered down.

ssl.sub.-- connect (host.sub.-- address)

This starts a terminal session to the host 10, by invoking the XHLLAPI.sub.-- ASSOC.sub.-- PS function. The function returns a session handle which can be used for subsequent identification of the session.

ssl.sub.-- disconnect

This stops a terminal session to the remote host 10 by invoking the XHLLAPI.sub.-- DISSOC.sub.-- PS function.

ssl.sub.-- select (session.sub.-- handle)

This selects a session, making it the current session on which subsequent requests operate. The session must have been previously connected by the ssl.sub.-- connect function. Only one session can be current at any given time.

ssl.sub.-- deselect

This deselects the current session, leaving no session current.

ssl.sub.-- run.sub.-- script (session.sub.-- handle,script.sub.-- name,parameters)

This starts a specified one of the custom shell scripts, to run on the currently selected session, by fork and exec system calls with the supplied parameters. These parameters consist of a sequence of items of the form name=value, which are added to the environment of the child process. They are then available to the shell script as shell variables. The function returns a script handle which can be used subsequently to reference the running script. Multiple script instances may be run concurrently, each being assigned a script handle and associated with a single session. However, only one script may be active for a given session at any one time; any other scripts associated with the same session will be in a dormant state.

ssl.sub.-- wait (script.sub.-- handle,script.sub.-- reply, len)

This waits for a specified script to terminate by making a call to the tsh.sub.-- return shell function. Script.sub.-- reply points to a buffer of length len that is to receive the results returned by the shell script. While waiting, ssl.sub.-- wait services any requests received from the shell functions by way of the pipe interface, by invoking the appropriate XHLLAPI functions. When the specified script terminates, ssl.sub.-- wait returns the results of the shell script to the interface module.

ssl.sub.-- send (script.sub.-- handle,parameters,message)

This sends a new message to a specified resident script (ie one that has previously called the tsh.sub.-- return function with result code=1). The parameters are a sequence of items of the form name=value which are added to the environment of the script.

The following shell functions are provided.

tsh.sub.-- keys string

This sends a string of emulated keystrokes to the target session, using the XHLLAPI.sub.-- DO.sub.-- KEYS function.

tsh.sub.-- read var row column size

This uses the XHLLAPI.sub.-- COPY.sub.-- FROM.sub.-- PS function to read the contents of a specified area of the virtual screen, and writes the data into the named shell variable.

tsh.sub.-- readmsg var1 var2 . . . varN

This uses the XHLLAPI.sub.-- READMSG function to read the contents of the virtual screen between the saved cursor and the current cursor, and writes the data into the named shell variables.

tsh.sub.-- search row column string

This uses the XHLLAPI.sub.-- SEARCH.sub.-- PS function to search the virtual screen for a specified string, starting at a given row/column address.

tsh.sub.-- write row column string

This writes a specified string to the virtual screen, starting at a given row/column location, using the XHLLAPI.sub.-- COPY.sub.-- TO.sub.-- PS function.

tsh.sub.-- compare row column string

This uses the XHLLAPI.sub.-- COPY.sub.-- FROM.sub.-- PS function to obtain the contents of the virtual screen (PS) at the specified row, column address, and then compares this with a specified string value. The address may be either absolute, or relative to the current cursor position.

tsh.sub.-- getcursor

This returns the current cursor position, using the XHLLAPI.sub.-- CURSOR function.

tsh.sub.-- savecursor

This saves the current cursor position, by means of the XHLLAPI.sub.-- SAVE function. The saved cursor can then be used as an alternative base for addressing the virtual screen PS.

tsh.sub.-- restore

This restores the current cursor to its saved value, by means of the XHLLAPI.sub.-- RESTORE function.

tsh.sub.-- getsaved

This returns the saved cursor position, using the XHLLAPI.sub.-- GETSAVED function.

tsh.sub.-- setcursor row column

This sets the current cursor position to the specified row and column, by means of the XHLLAPI.sub.-- SETCURSOR function.

tsh.sub.-- setsaved row column

This explicitly sets the saved cursor position to the specified row and column, by means of the XHLLAPI.sub.-- SETSAVED function.

tsh.sub.-- wait

This function waits until it detects a "keyboard unlocked" state, using the XHLLAPI.sub.-- WAIT function. It can be used to detect completion of host output in the case where the terminal used a blocked mode protocol.

tsh.sub.-- pause options

This function pauses until triggered by any of the events specified by a list of options. The events that may be specified include:

a pause in the host output,

the output of a specified number of new lines from the host,

the presence of a particular string at a specified location of the virtual screen,

the output of a particular string from the host,

the presence of the cursor within a specified range of positions.

The tsh.sub.-- pause function makes use of the XHLLAPI.sub.-- PAUSE function to detect the occurrence of events, the XHLLAPI.sub.-- QUERY.sub.-- HOST function to obtain information about a detected event, and the XHLLAPI.sub.-- COPY.sub.-- FROM.sub.-- PS function to read the virtual screen so as to check whether the detected event is one of the specified events for which tsh.sub.-- pause is waiting.

tsh.sub.-- return result.sub.-- code string

This function returns a numeric result code to the SSL, along with a result string. The following result codes are available:

0 success: the shell script has finished.

1 terminate but stay resident: the script is now ready to accept new requests by way of the tsh.sub.-- receive shell function.

2 immediate return: this is used to pass back a partial result rather than terminating.

3 acceptable failure: the shell script has detected an error and needs to be terminated.

-1 catastrophic failure: the shell script is in a state from which it cannot recover, and so the session needs to be terminated, and the gateway restarted.

tsh.sub.-- receive message

This is used by scripts that have opted to terminate but stay resident, to accept new requests. When a request arrives, tsh.sub.-- receive returns the message in a shell variable whose name was supplied by the caller.

tsh.sub.-- env "name1=value1 name2=value2 . . . nameN=valueN"

This function passes a string of space-separated name=value pairs to the SSL to be exported as environment variables, thus allowing existing or successive scripts to have access to these variables.

tsh.sub.-- options "opt1 opt2 . . . optN"

This uses the XHLLAPI.sub.-- PARAMS function to set one or more XHLLAPI option parameters.

All XHLLAPI operations are initiated by means of a single function call interface XHLLAPI() which has four parameters as follows:

func: a function code

buff: a buffer, for holding a string of virtual screen or keyboard data.

size: the length of the data in the buffer.

pos: a virtual screen position; also used to return a result code.

The function code defines the following functions.

XHLLAPI.sub.-- INIT

This initialises the XHLLAPI interface. It must be the first XHLLAPI operation performed by a process. It must also be called after an XHLLAPI.sub.-- DEINIT if it is required to use XHLLAPI again. XHLLAPI.sub.-- DEINIT

This clears down the XHLLAPI interface after use, by dissociating all current sessions and releasing resources.

XHLLAPI.sub.-- RESET

This resets the XHLLAPI interface by dissociating all sessions, releasing all resources, and breaking all host connections, leaving XHLLAPI initialised and ready for use.

XHLLAPI.sub.-- PARAMS

This sets various option parameters to control aspects of the operation of subsequent commands, such as time-outs and addressing bases.

XHLLAPI.sub.-- ASSOC.sub.-- PS

This associates a new session with a client, and connects it to the target host. The client provides a single-character short name by which to refer to the session subsequently, and an address by which to reach the target host.

XHLLAPI.sub.-- DISSOC.sub.-- PS

This dissociates a session (referenced by a specified short name) from the client, disconnects it from the target host, and releases any resources associated with the session. The short name is deallocated.

XHLLAPI.sub.-- CONNECT.sub.-- PS

This selects a session (referenced by a specified short name) as the current session.

XHLLAPI.sub.-- DISCONNECT.sub.-- PS

This deselects the current session, leaving no session currently selected.

XHLLAPI.sub.-- WAIT

This causes XHLLAPI to wait for any output currently outstanding or in progress on the current host session to complete. It is used to wait for a host reply to a simulated keyboard input, or to poll for unsolicited host output.

XHLLAPI.sub.-- PAUSE

This causes XHLLAPI to wait for an event (i.e. an update to the virtual screen PS) on any of a specified list of sessions, subject to a timeout. The list is set up by calls to XHLLAPI.sub.-- START.sub.-- NOTIFY. On completion, details of the event may be obtained through XHLLAPI.sub.-- QUERY.sub.-- HOST.

XHLLAPI.sub.-- START NOTIFY

This adds the short name of a specified session to a poll list, for use by the XHLLAPI.sub.-- PAUSE function.

XHLLAPI.sub.-- STOP NOTIFY

This removes the short name of a specified session from the poll list.

XHLLAPI.sub.-- QUERY.sub.-- HOST

This returns information about an event detected by XHLLAPI.sub.-- PAUSE. The information includes a result code indicating whether an update has occurred to the virtual screen. Optionally, the function also returns any statistics that have been gathered relating to output from the host to the virtual screen. Optionally, the statistics are cleared after reading.

XHLLAPI.sub.-- CURSOR

This returns the current cursor position.

XHLLAPI.sub.-- SETCURSOR

This sets the current cursor position.

XHLLAPI.sub.-- SAVE

This saves the current cursor position in internal XHLLAPI storage. Unlike the current cursor, the saved cursor is considered to be attached to the data on the virtual screen so that it scrolls up with the data, with screen-wrap. This function is mainly intended to support scroll-mode host applications where different instances of a particular dialogue may appear at different positions on the screen.

XHLLAPI.sub.-- RESTORE

This restores the cursor to a previously saved position.

XHLLAPI.sub.-- GETSAVED

This returns the saved position of the cursor.

XHLLAPI.sub.-- SETSAVED

This explicitly sets the screen position of the saved cursor.

XHLLAPI.sub.-- COPY.sub.-- TO.sub.-- PS

This copies a string from the buffer to a specified position of the virtual screen PS.

XHLLAPI.sub.-- COPY.sub.-- FROM.sub.-- PS

This copies a string of specified length from a specified position of the virtual screen into the buffer.

XHLLAPI.sub.-- SEARCH.sub.-- PS

This searches the virtual screen for a specified string. The string must be null-terminated, or else its length must be supplied explicitly. According to which option is selected, either the whole screen is searched from the start, or the screen is searched from a specified position.

XHLLAPI.sub.-- READMSG

This reads the contents of the virtual screen, starting at the saved cursor and ending at the position before the current cursor. This function is intended mainly to support scroll-mode host applications, especially where the quantity of host output data cannot be predicted. In this case, the cursor can be saved, a host interaction performed, and then the response retrieved without needing to supply the screen address.

XHLLAPI.sub.-- DO.sub.-- KEYS

This processes one or more simulated keystrokes, passed to XHLLAPI in the buffer.

An example of a custom shell script will now be given. This script is run when the gateway receives a "transfer" request from a client (by way of the TP monitor) requesting transfer of funds from a specified source account to a specified target account. The script converts this request into a dialogue with the remote application 11, so as to perform the desired transfer and to send a response back to the client.

It is assumed that on entry to the shell script the following shell variables have been set up from fields in the buffer supplied by the client:

The script contains a subroutine failed() which is called upon detection of a pause failure. The subroutine returns a failure code (3) along with a suitable error message, and then quits the script.

On entry, the script assumes that the terminal session is currently at its top level; waiting for a command identifier to be entered. The script therefore calls the tsh.sub.-- keys function to type "t" and a carriage return (@N) on the virtual keyboard, requesting the transfer.

The script then calls the tsh.sub.-- pause function, to wait for the host application to ask for the source account number. The arguments to the tsh.sub.-- pause function have the following effect: wait until at least 4 newlines have been received (-n4), and then compare (-C) the string "number?" with the screen contents starting at position (-P) 0 rows and 7 columns before the current cursor (-0:-7) until it matches, with a timeout of 5 half-second units (-t5). Note that a row or column address prefixed by a sign (+ or -) indicates a value relative to current cursor.

".vertline..vertline." is a standard shell operator, which here will cause a call to the function "failed" if the tsh.sub.-- pause failed on a timeout or other error.

The script then calls the tsh.sub.-- keys function to type in the source account number and a carriage return on the virtual keyboard. The number is prefixed with two zeros since the host expects a seven digit account number.

The script then calls the tsh.sub.-- pause function, to wait to be asked for target account number. This is similar to the previous pause, but in this case the script waits for only one newline (-n1).

The script then calls the tsh.sub.-- keys function to type in the target account number and a carriage return on the virtual keyboard. Again the number is prefixed with two zeros.

The script again calls the tsh.sub.-- pause function to wait to be asked for the amount to transfer. This is similar to the previous pause, but in this case the function looks for the string "transfer?" occurring nine columns before cursor (-0:-9).

The script then calls the tsh.sub.-- keys function to type in the amount and a carriage return on the virtual keyboard.

The script then calls the tsh.sub.-- pause function to wait for the host to perform the operation and to prompt for the next command. This will be signalled by the string "Command?" appearing on the virtual screen at the first column of the cursor row (-P-0:1), after at least 4 new lines (-n4).

Next, the script calls the tsh.sub.-- compare function to see if an error message has been displayed on the virtual screen before the command prompt; that is, whether the word "Error" appears on the screen two rows above the cursor, at absolute column 9.

If an error message has been received, the script calls the tsh.sub.-- read function to read the full message (71 characters) into a new shell variable "statlin", calls the tsh.sub.-- return function to return this variable to the gateway process with the failure code (3), and then quits with exit status 1, indicating failure.

If, on the other hand, no error message is displayed, the script then calls the tsh.sub.-- read function twice, to extract the new account balances from the virtual screen, into shell variables sbalance.sub.-- 0 and sbalance.sub.-- 1. Each of these account balances is eight characters long and starts at column 25. The first balance appears seven rows above the cursor, and the second appears four rows above the cursor.

Finally, the tsh.sub.-- return function is called to return the success result code (0) to the SSL, together with a result string constructed from the shell variables indicating the new balances. The script then quits with exit status 0, indicating success.

It will be appreciated that many modifications may be made to the system described above without departing from the spirit and scope of the present invention.

For example, the host system 10 may use a different type of terminal, such as a block mode terminal. This may require a different version of the XHLLAPI, tailored to the new terminal type, and also some modification of the custom shell scripts to cope with the different terminal protocols. However, the interface between the XHLLAPI and the SSL remains constant, and so no modification is required to the SSL.

In other embodiments of the invention, the legacy application 11 may reside in the same computer 13 as the gateway 20, in which case the gateway can communicate directly with the legacy application, without the need for the communications module 21.

The system may be based on transaction processing environments other than the TUXEDO environment described above. In that case, the gateway interface module 30 would have to be modified to interface with the different environment. However, it should be noted that the SSL is not dependent on TUXEDO and therefore the rest of the gateway would be unaffected.

The shell scripts and shell functions may be replaced by equivalent C routines, to improve efficiency.

The SSL may be considered as providing an interface between shell scripts and the XHLLAPI functions. It can therefore be used to provide a service to standard shell scripts (i.e. those not working on behalf of some client program) to enable them to perform terminal emulations.