Personal Computer/Host Emulation System for Handling Host Data With Personal Computer Application Programs at Personal Computers

This invention is directed to a system for the connection of a personal computer, operating as a terminal emulator, to a host system in a manner which allows data existent in the host system to be extracted from the host, manipulated by a personal computer using a conventional personal computer program, and the modified data returned to the host system for storage.

In particular, the invention pertains to a personal computer terminal emulation system which accommodates a first, emulation, operating mode in the host in conventional fashion and a second, personal computer, operating mode in which data extracted from the host system while operating in the emulation mode may be processed with conventional personal computer application programs.

Personal computers have found widespread application as terminals connected to a substantially larger host system. In this application, the personal computer operates under the control of an "emulator" program, resident in the personal computer, which causes the personal computer to function in the same fashion, i.e., emulate, a conventional terminal. When operating in the emulation mode of the prior art systems, the personal computer is incapable of performing functions other than those of the terminal which is being emulated. Thus, the diverse and powerful functions which are capable of being performed by the personal computer, operating as such, are not available in the emulation mode.

The wide variety of programs available for use on personal computers provides a potential user with an assortment of tools which accommodate almost any computer task. Some of the more common applications, such as spread sheets and word processing, have many different programs, each of which has certain advantages and disadvantages. This proliferation has led to a lack of uniformity in the way in which data is formatted, the use of different control characters, and the presence of functions or operations which are unique to each program.

In some areas, notably word processing, programs have been devised to convert documents written with one word processing program to the format of another word processing program. This allows a document prepared with a first program to be altered and printed with a second, different, program. An example of such an approach is described in U.S. Pat. No. 4,503,516, assigned to assignee of this invention. The system of that patent describes an interconnection arrangement which allows conversion of documents between DisplayWriter (DW) format and PROFS (Professional Office System) format. The DisplayWriter format is used by a stand alone device, such as the system of the same name or a personal computer, and the Professional Office System is used as a host system such as an IBM System/370.

The systems of the prior art have generally operated in a batch fashion to convert the entire document from a first format to a second format. This has the disadvantage that the entire document must be so converted even if only a minor change in the document is to be made. The inefficiency of this approach is even more obvious in the case where it is only desired to visually present the document to the operator. Even in the case where it is desired only to read the document, the prior art approach requires that the entire document must be first converted to the format of the personal computer and then reconverted back to the original format when stored in the host system.

Additionally, it would be desirable to utilize the abundance of specialized functions provided by programs available for personal computers to process data from a host system which may have been produced with a program unrelated to the program in the personal computer. The previous example involved two different word processing programs. Such programs are related to the same basic problem and the conversion between them could even be classified as straightforward. However, in the case where a numerical table exists in the word processing document, it is often desirable to apply numeric programs to this portion of the document. It would be desirable to be able to perform calculations on numeric data and insert the result of the calculation into a host document without the need to exit from the host emulation program, call up the application program, fetch the file from the host, perform the calculation, exit from the application program and reenter the host emulation program. While programs for this purpose do exist, they are specialized for particular programs, and therefore, lack the ability to accommodate data from programs not contemplated by the designer.

The prior art approaches to the problem have generally required conversion of all the data from the first to the second format prior to use of the second program; and were available, only for interchanges between a limited set of programs. The requirement for conversion prior to use of the second program imposes a substantial burden in terms of conversion processing, and may even require conversion which is unnecessary in the sense that portions of the converted data may never be used or modified. Despite the fact that processors are operating at ever increasing speeds and efficiencies, there is nevertheless a finite delay between the time the operator requests a document for conversion processing and the time that document is actually available for use or modification by the operator.

An example of a prior art terminal emulation program is the IBM PC 3270 Emulation Program available from International Business Machines Corp., the assignee of this invention. Turbo Pascal 4.0, IBM Version for IBM PS/2 (IBM Corp..TM.), PC XT (IBM Corp..TM.) and AT (IBM Corp..TM.), a high level language selected for expression of the preferred embodiment of this invention is available from Borland International, 4585 Scotts Valley Drive, Scotts Valley, Calif. 95066. C Complier, an alternative high level language for expression of the program of this invention, is available from the International Business Machines Corp., P.O. Box 1328W, Boca Raton, Fla. 33429-1328. Macro Assembler Version 2.0, also available from the International Business Machines Corp., is also helpful in implementing the invention. Terminate and stay resident programs which are used in the implementation of this invention, are described in "The History and Technology of TSR; Terminate and Stay Resident Software", pp 39-49, an article by Steve Gibson in RAM LORD USER'S MANUAL, published by Waterworks Software, Inc., 913 Electric Avenue, Seal Beach, Calif. 90740.

It is therefore an object of this invention to provide a system in which a document or data file, resident in a host system in a first format according to a first program, can be visually displayed on a personal computer or like device and modified by the use of a second program which may have a different data format than the first program.

It is another object of this invention to provide a system in which the modification of data recorded in a format according to a first program may be accomplished with a second program, having a format differing from the first program, without the need for conversion of the entire data file.

It is a further object of this invention to provide a system which allows modification of data, stored in a host system and recorded in a format according to a first program, by a personal computing system utilizing a second program having a different format by utilizing the display buffer of the personal computer as a facility shared by the personal computer and the host system.

These and other objects of this invention are accomplished by a personal computer terminal emulation program resident in a personal computer, connected for use with a host system containing data stored according to a first format, which allows the personal computer operating in an emulation mode to directly utilize an application program, requiring data according to a second form, to modify, record and otherwise process data which is stored in the buffer associated with the display of the personal computer, which returns the processed data back to the host computer when execution of the operation is completed.

FIG. 1 is an illustration of a prior art technique for the operation of a terminal in a host environment.

FIG. 2 is an illustration of the system hardware arrangement which is used to practice the invention.

FIG. 3 is a programming flow chart showing the fashion in which the system toggles between the PC/host emulation program and the PC mode.

FIG. 3a is an illustration of the basic functional aspects of the system used to practice the invention.

FIG. 4 is a programming flow chart showing an overview of the operation of the program.

FIG. 5 is a programming flow chart including the portion of the program which converts data stored in the host computer into data which is displayed on the personal computer.

FIG. 6 is a programming flow chart including the portion of the program utilizing a personal computer program to process data which is stored in the host computer.

FIG. 7 is a memory map for a personal computer configured according to the invention.

FIG. 8 is a flowchart-hardware portrayal of a system according to the invention showing how data from the host and keystrokes at the personal computer may each be used to call PC application programs.

Appendix 1 is a program listing of the preferred embodiment written in Turbo Pascal for execution on an IBM Personal Computer connected to an IBM System/370.

The system shown in FIG. 1 is representative of the prior art approach to the problem. Where the personal computer 1 is to be used as a terminal, the conventional approach would be to have the host system 2, a large or central data processing system, provide the support for the terminal by means of an emulator 3, which is resident in the host mainframe. This required all the keystrokes at the personal computer 1 to be passed to the host system 2 for processing. The display screen 4 at the personal computer 1 was generated at the host system 2 and passed to the data buffers 5 in the personal computer 1. Such a system is limited to the emulators contained in the host system and does not utilize either the computing power of the personal computer 1 or the multitude of application programs available for such computers.

As shown in FIG. 2 the hardware arrangement used to practice the invention includes the CPU 20 within the host system 2, which is connected via a conventional communications interface 21 to the personal computer interface card 23 which resides within the personal computer 1. The interface card 23 is connected to the personal computer CPU 24 over bus 25. A conventional keyboard 26 and display 27 are connected to CPU 24 in conventional fashion. Random access memory (RAM) 28 has a portion 28a dedicated to storage of the software program which performs the functions of the invention. Additional portions 28b, 28c and 28d are devoted to the storage of PC application programs which are of the class known as terminate and stay resident (TSR) programs, the terminal emulator program, and the disk operating system, respectively. Terminate and stay resident programs are described in "The History and Technology of TSR; Terminate and Stay Resident Software", pp 39-49, Ram Lord User's Manual, published by Waterworks Software, Inc., 913 Electric Avenue, Seal Beach, Calif. 90740. Very simply, such programs are designed to run on a personal computer under DOS and are continually resident in random access memory and are called into action by a specific pointer, in this case, developed by the actuation of a "hot" key or keys. Random access memory 28 also contains a portion 28e devoted to various working register and data buffers used by the programs.

FIG. 3 illustrates how the system toggles back and forth between the host terminal emulation mode and the PC mode. The user may cause the system to switch from one mode to the other by depressing the selected key or a selected combination of keys which then develops the appropriate pointer. The PC/host emulation program monitors the keyboard to detect the actuation of the selected key or combination of keys representing PC application program functions as shown in block 30. When the PC mode is selected by actuation of a key representing a PC application program function, the program branches to block 31, causing the selection of the appropriate PC application program and the desired function. The system remains in the PC application mode until the appropriate key (or keys) is depressed, which actuates block 30 to cause the system to switch back to the host emulation mode.

In the terminal emulation mode, as will later be described in more detail, the screen is constructed from data obtained from the host in accordance with block 33. The keystrokes in this mode are detected by block 34 and sent to the host via the emulator program as shown in block 35. The host operates to interpret the keystrokes in conventional fashion in accordance with the host program as shown in block 36. Data resident in the host may be sent to the emulator program as shown.

FIG. 3a provides an overview of the various functional aspects of the invention. When operating under control of the PC/host terminal emulation program, two fundamental functions are performed on a recurring basis. The first function is to monitor host data to sense a host data update. The data supplied to the personal computer at the outset of the operation may be independently updated by the host system during a PC session. That is, the data previously supplied to the personal computer by the host system may become obsolete during the course of the PC session. For this reason, the PC/host emulation program continuously monitors the host data to determine if any changes have been made since the last update.

The second function is to monitor the personal computer keyboard for activity. Depression of a key on the keyboard can signal the entry of new data on the screen, or it can be a command such as would require host activity or the calling of a terminate and stay resident application program resident in the personal computer.

At the outset, the host data, which will most commonly represent a screen on the host display, is translated into PC format by data translation portion 31a emulation program. The host display data, now in PC format, is loaded into a data buffer 32a in the PC. Since the PC display commonly responds to codes which differ from the display codes of the host, a further translation into PC display codes by the display translation portion 33a of the emulation program is performed. The resulting data, in the PC display format, is loaded into the PC display buffer 34a and presented on the PC keyboard/display 35a.

Keystrokes on the keyboard/display 35a are examined by the keystroke interpretation portion 36a of the emulation program to determine whether a PC or a host function is required. Program block 36a is responsive to the selected mode. In the PC mode, the keystrokes are handled by block 37a as normal keyboard commands or data. In the emulation mode, the keystrokes representing the host keys are passed to the host processor via the host emulator 31a.

The data flow chart of FIG. 4 represents an overview of the operation of the PC/host terminal emulation program. Beginning with block 40, the program reads the host display buffer in search of new information. The content of the host display buffer is first translated into PC format and further translated into the appropriate PC display codes for storage in the PC display buffer at block 41 to display the host screen contents on the PC display screen.

The PC/host terminal emulation program then checks to see if there has been a PC application program key depressed as shown in block 42. A PC application program key is one which has been specifically designated as a "hot" key which operates to call in a particular PC terminate and stay resident application program. In contrast to prior art terminal emulation programs which disabled the "hot" keys, the program of this invention allows use of the hot keys while in the terminal emulation mode. That is, the operator is permitted to call PC application programs and their functions by the depression of the appropriate hot key. If a hot key has not been depressed, the program loops back to block 40 in search of new host display information. If there has been a PC key depressed, the program branches to the test for a PC function in block 43. If the depressed key is not a PC function, it is necessarily a host key function, and block 44 causes the program to branch back to block 40, passing the host key information to the host for display and/or command action. If the depressed key represents a PC function, block 43 passes the program to block 45, which calls the appropriate PC application program. The specified PC application program then operates on the data in the PC display buffer as shown in block 46 and branches back to block 42 to check for actuation of a PC key.

The reading of the host display buffer and subsequent display on the PC screen is set forth in detail in the data flow chart of FIG. 5. The entry into initial block 50 is made from appropriate branches such as shown broadly in FIG. 3 and in more detail in FIG. 4. The portion of the PC/host terminal emulation program represented in block 50 operates to obtain the row and column information representing the position of the cursor on the host display screen. This information is obtained by using the host interrupt and passed to the PC. Utilizing the PC interrupt facility, the PC/host terminal emulation program moves the PC cursor to the corresponding spot on the PC screen as shown in block 51. The PC/host terminal emulation program then causes the host text data buffer to be read and the information passed to the PC. In similar fashion, the PC/host terminal emulation program causes the host display (field) attributes and extended attributes to be read and passed to the PC.

Having obtained all the information on the host display and passed this information to buffers in the PC, as shown in block 52, the host codes for the text data, field attributes and extended attributes are converted to PC compatible codes, as shown at block 52. Despite the fact that the translation of block 53 puts the data into PC format, it is necessary to perform the operation of block 54 which converts the data into PC display codes corresponding to the display codes used by the host processor. The PC display codes are stored in the PC display buffer, shown in block 55, from which they drive the display, duplicating the display of the host.

Where the PC is operating under the direct control of a TSR program, the CRT display is generated by data from the TSR program as shown in block 55a.

At block 56, the PC/host terminal emulation program tests to see if a command exists in the data displayed on the PC screen. Since all the display data is tested, the text data, field attributes and extended attributes may all be used as the basis for commands. The commands are tested at block 57 and may be used by the PC/host terminal emulation program to cause actions within either or both the PC or host environments. For example, a command can cause a PC application program to be executed by "shelling"/returning to the PC DOS environment to execute a program. At the normal exit from the PC application program the return, via the shell, may return the user to the host environment in a fashion which remains completely transparent to the user. As previously described, certain keys may be used to call Terminate and Stay Resident (TSR) programs within the PC. These keys will override all other keys and can be used to call PC application programs such as spell checking and synonym selection. The PC/host terminal emulation program develops the appropriate command parameters which are then passed to a batch file in the PC DOS environment. The PC application is executed with normal PC functions until the user, or application program itself, exits from the application in the normal fashion.

When the refresh of the PC display is complete and in the event that the PC screen data does not contain command information, the test performed at block 56 branches to the test for keyboard activity at block 58. If there has been keyboard activity, the key strokes are examined. PC keystrokes are processed in normal PC fashion by block 59, and non-PC keystrokes are immediately passed to the host.

It is possible to automatically select a PC application program in response to the data downloaded to the PC from the host computer. This phase of the invention is shown in FIG. 6. In the example, the host data file is an XEDIT file created and used by the host program called XEDIT. While the XEDIT program is an acceptable approach to the editing problem, the PC application program PE2 (Personal Editor 2) would likely be more familiar to the PC user and presents advantages over XEDIT for this reason.

The PC/host terminal emulation program allows the user to specify certain parameters when the program is used. For example, it is possible to specify any personal computer application program in response to designators in the host file to be operated on. In the selected example, the host file is an XEDIT file. That is, the host data file to be operated on at the PC was created on the host with the use of the host program called XEDIT. There is a field in the data file, which may be a portion of the file name, which designates it as an XEDIT file. The PC/host terminal emulation program allows a user to designate which PC application program is to be called for each of the host application programs. In the example selected, the user has designated the PE2 application program to be called when a host data file of the XEDIT type is to be used.

Beginning with the reading of the host screen at block 60, the screen data is translated as previously described and stored in the PC screen buffer by the portion of the PC/host terminal emulation program represented by block 61. At this point the PC/host terminal emulation program tests the screen data for the existence of a data tag as shown in block 62. In the example selected, the data file on the host screen was generated using XEDIT, an editing program in common use on large systems. The user profile generated on the PC specified that when an XEDIT data file was retrieved from the host and loaded into the PC for further processing, the file was to be processed with the PE2 application program instead of XEDIT. When the test at block 62 detects that the displayed portion of the file is a data file, generated with XEDIT file, it causes the download of the entire data file as shown in block 63 and automatically calls the PC application program PE2 in block 64.

Control of the PC then rests with PE2, allowing the user to edit the data file with this application program. The PC/host terminal emulation program simply waits until the user exits from PE2 in the normal fashion. This exit is detected at block 65. In the absence of the exit command, the PC/host terminal emulation program continues the loop between block 64 and block 65, holding the PC in the PE2 application program.

On detection of the normal exit command from the PC application program PE2 by the portion of the program represented by block 65, the PC/host terminal emulation program branches to block 66. This causes the altered data file to be uploaded back to the host. When this operation is completed, the program proceeds to block 67, which tests to see if a key has been depressed. If there has been no key depression, the program reenters the main loop beginning at block 60, to see if new data is available at the host screen.

In the case where a key has been depressed, the branch from block 67 proceeds to block 68 which evaluates the key depressed to see if it calls a PC function, that is, to determine if the depressed key specifies an operation which requires the use of a PC application program. If the depressed key is not one which requires a PC application program, the keystroke is one which is to be passed to the host for action. The PC/host terminal emulation program branches to block 69, which passes the keystroke to the host and reenters the program at block 60.

In the case where the depressed key requires the intervention of a PC application program, say, for example, a spelling check, the portion of the program represented by block 70 operates to call the specified PC program, which then may be used in conventional fashion to operate on the display data as shown in block 71. When the PC application program is exited, the program branches back to block 67, to check for further key depressions.

It will be appreciated that the loop which includes blocks 67, 68, 70 and 71 is operative to call such popular PC application programs as "Lightning", a spelling checker program marketed by Borland International. The user would specify that the "Lightning" program is to be active when in the PC mode of operation; that is, when in the loop defined by blocks 67, 68, 70 and 71. In this mode, the "Lightning" program checks the spelling of each word as it is typed and emits a beep when the word is spelled incorrectly. By depressing a "hot" key, that is, one which operates to call a specific PC application program, the user may invoke the portion of "Lightning" which allows the user to look up the most probable correct spelling of the misspelled word. Return to the normal mode of operation is made by depressing the appropriate "hot" key or by the application program which may operate to terminate itself when the requested function has been completed.

FIG. 7 shows how the PC memory is partitioned. The DOS operating system is located in the low address portion of random access memory and the terminal emulator program, for example, the IBM PC 3270 Emulation Program is located at the next higher address. The next higher addresses contain the terminate and stay resident application programs for the personal computer. The program of this invention lies in location, just above the TSR programs and the remaining memory is available for general use by the system.

FIG. 8 further illustrates the fashion in which the emulation program of this invention utilizes host data to call a PC application program and the fashion in which the hot keys are used to call application programs. Beginning with the case where the host data processing system 80 supplies data to the PC for display on the PC CRT, blocks 81 and 81a of the emulation program pass the data along alternate paths dependent on whether the system is operating in the host mode or the PC mode. In the event that the system is in the host mode, the data for display is processed by block 82 of the emulator program to construct the PC screen as if it were the host screen. The screen information is then passed to the PC CRT display 83. In the alternative, PC mode, the functions contained in portion 84, are performed. Blocks 84a and 84b of the emulator program of this invention examine the host data sent to the PC for display to determine if the data contains control information. If it does, the program branches to block 84c to execute the PC application program called for by the control information. In the normal situation, the PC application program then assumes control of the CRT display 83 for the display of information associated with the application program. If the display information from the host is simply display data and does not contain control information, the program branches to block 84d, which is effective to construct the display for the CRT 83.

In the case where data is entered by means of keystrokes at keyboard 85, blocks 82 and 82a of the emulation program detect and route keystrokes in a fashion similar to blocks 81 and 81a previously discussed. If the keystrokes are made when the system is in the host mode, they are passed directly to the host as shown. However, when the system is operating in the PC mode, the function illustrated generally in portion 86 is operative and keystrokes are routed to block 86a, which examines each keystroke and sequence of keystrokes to see if a terminate and stay resident program function is specified. In the case where a terminate and stay resident program function is specified, the program branches to block 86b which is effective to actuate the portion of the program associated with the desired function. Where the keystrokes are not those which specify a terminate and stay resident program function, they are passed to the host via portion 87 of the terminal emulator program. ##SPC1##