Abstract:
A terminal emulation program for an IBM host is described. The program can record scripts (mini-programs) of IBM host sessions. For each action or event, as desired, the program records an appropriate script. Scripts may be created for connecting to and disconnecting from the IBM host, for sending key strokes, for sending playback-time inputs, for awaiting a certain screen, and for importing displayed IBM host data. The scripts are stored in a file on a PC and may be replayed either from the terminal emulator, from Windows, or via OLE.

Description:
NOTICE OF COPYRIGHTS 
     A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. 
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates generally to PC to host communications, and more particularly to terminal emulation on a PC for communications with an IBM mainframe or minicomputer. 
     2. Description of Related Art 
     Today&#39;s enterprise features universal personal and network computing. In most cases the same enterprise is a long-term user of and investor in International Business Machines Corp. (Armonk, N.Y.) (&#34;IBM&#34;) host computing systems and technology. In the early 1980s, the arrival of the Personal Computer (PC) in IBM host computing environments created a PC-to-IBM host connectivity market. Today this hardware/software market is approximately a $1 billion segment of the networking industry. 
     The PC-to-IBM host connectivity market has gone through several transitions over the past decade. In the early 1980s the market formed around the replacement of Control Unit Terminals (&#34;CUT mode devices&#34;) with hardware/software combinations such as the &#34;IRMA&#34; card. The first major transition in this market began in 1985 with IBM&#39;s introduction of distributed function terminal (&#34;DFT&#34;) mode in its cluster controllers (3X74), terminals, and modified PCs. PC-to-host connectivity vendors responded by developing DFT mode software for PC-DOS, an effort which required development of complete SNA protocol engines. 
     By the late 1980s many organizations were swept up in the process of connecting PCs together into Local Area Networks (LANs). This gave rise to another transition in the market, the connections of LAN-attached PCs to IBM hosts. The use of connectivity methodologies that deny PCs powerful access to local and wide area networks (such as coax/twinax to fixed function cluster controllers) is on the decline, being replaced by gateway and direct connect configurations that treat IBM hosts as one of several internetwork servers. 
     In 1990 the transition in the Intel PC install base to Windows 3.X began. Windows is a product of Microsoft Corp. (Redmond, Wash.). The effect upon the IBM host connectivity market was immediate and profound. New, high growth companies emerged that specialized in Windows-to-IBM host connectivity. For the first time, changes in the desktop computing environment begat significant changes in the use of IBM host computers. 
     In the typical PC-DOS-to-IBM host connectivity installation, terminal emulation software allows operation of the PC as a dual function device: both PC-DOS application processor and host terminal. The typical PC-DOS based 3270 or 5250 product may also include other features for host connectivity such as application programming interfaces and/or file transfer software. However, the limitations of PC-DOS itself (memory management and user interface in particular) hinder general development and deployment of more powerful PC-to-host connectivity systems. 
     The widespread adoption of Windows 3.X on Intel Desktop PCs created a market for more innovative PC-to-IBM host connectivity software. Graphical User Interface technology has been applied to the task of simplifying the look and feel of older host applications. Enhanced mode memory management allows for more reliable deployment of underlying PC-to-host communications technology such as Advanced Program to Program Communications/Logical Unit (&#34;APPC/LU&#34;) 6.2 engines. Task switching enables the concurrent use of various PC-to-host applications and services on a single desktop. All of these innovations represent incremental improvement over the DOS-to-IBM host computing environment. 
     One important aspect of IBM host connectivity is host data incorporation. Host data incorporation can generally be broken down into two approaches: screen scraping based on the High Level Language Application Programming Interface &#34;(HLLAPI&#34;) applications programming interface (&#34;API&#34;), and client/server systems based on APPC/LU 6.2. HLLAPI allows users to write high level language programs for automating repetitive tasks and console operations. It also allows for masking complex applications from the user, consolidating several tasks into one simple task, monitoring tasks without human intervention and simplifying existing host applications. 
     In coding HLLAPI applications, the corporate developer is presented with at least two alternatives. One is to write a traditional Windows application in C that reads and writes from the host display session presentation space as needed to incorporate host display session data into Windows applications. Another is to write a Visual Basic application that includes Visual Basic custom controls that perform a similar set of encapsulated host presentation space read/write functions and services. Both methods may consume anywhere from a few days to a few months worth of development effort, depending upon the complexity of the data incorporation problem and the skill of the developer. 
     Although IBM host applications can be written having a more contemporary user interface, most IBM host applications are old, and it is difficult to make significant changes to them. These older IBM host applications are commonly known as &#34;legacy applications.&#34; One defining characteristic of legacy applications is that they are navigated linearly and sequentially. Thus, where some IBM host applications may be accessed using Software Query Language (&#34;SQL&#34;), legacy applications typically cannot. Furthermore, SQL access is generally limited to relational database management systems (&#34;RDBMSs&#34;). 
     Yet, although the legacy applications are old, the data stored with them and typically accessible only through them can be quite new and relevant. Thus, despite the age of the legacy applications, there continues to be a great need to use them. 
     It is therefore a first object of the invention to provide simplified navigation of IBM host applications. It is also an object of the invention to provide simplified navigation of IBM host applications using a PC-based terminal emulator. It is a further object to simplify for users the task of incorporating data from an IBM host application into a Windows applications. It is a further object to provide a system in which a network administrator or IS professional can build software relationships that facilitate such data incorporation. Other objects of the invention are to provide these other objects in an economical fashion requiring a minimum of modification to legacy applications and IBM hosts. 
     These objects and others are provided by the screen navigation method of the present invention. 
     SUMMARY OF THE INVENTION 
     In accordance with the present invention, there is provided a screen navigation system for a terminal emulator in which the path to a desired screen of an IBM host application is recorded, and then, when desired, the recording is replayed to return to the desired screen. Path recordings are created as &#34;navigation path&#34; objects. The navigation path objects are built by an administrator using a special terminal emulator. The special terminal emulator records necessary information while the administrator navigates through IBM host applications. After the navigation path object is created, it may be displayed graphically and edited. 
     A number of additional commands are provided in the invention. These include commands for: selecting data areas of an IBM host screen for capture to the terminal emulator, opening a window on the terminal emulator for data input which is then typed into a desired position in the IBM host screen, and selecting a series of commands to be repeated. 
     To use the navigation path object, an ordinary user may start the special terminal emulator and select the navigation path object for playing. Alternatively, the navigation path object, stored in a Windows file, may be selected and run from Windows Container Applications, the Windows desktop or File Manager/Explorer. 
    
    
     DESCRIPTION OF THE DRAWINGS 
     These and other advantages of the present invention are best understood with reference to the drawings, in which, in varying detail: 
     FIG. 1 is a block diagram of a computer system in accordance with the invention. 
     FIGS. 2A and 2B are a flow chart of a process for creating a navigation path object. 
     FIGS. 3A, 3B, 3C and 3D are a flow chart of a process for playing back a navigation path object. 
     FIG. 4 is a pull-down menu in accordance with the preferred embodiment. 
     FIG. 5 is a dialog in accordance with the preferred embodiment. 
     FIG. 6 is a tool bar in accordance with the preferred embodiment. 
     FIG. 7 is a screen shot of a terminal emulator screen in accordance with the preferred embodiment. 
     FIG. 8 is a terminal emulator window with a user input field in accordance with the preferred embodiment. 
     FIG. 9 is a dialog for setting input field properties in accordance with the preferred embodiment. 
     FIG. 10 is a terminal emulator window having data areas marked in accordance with the preferred embodiment. 
     FIG. 11 is a dialog for setting data properties in accordance with the preferred embodiment. 
     These and additional embodiments of the invention may now be better understood by turning to the following detailed description wherein a preferred embodiment is described. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     Throughout this description, the preferred embodiment and examples shown should be considered as exemplars, rather than limitations on the apparatus and methods of the present invention. 
     In accordance with the invention, a special terminal emulator program is used to first record actions and events during an IBM host session, and then, as desired, to replay all or part of the recording. The recording comprises a number of scripts, where each action or event preferably will be recorded as one script. These scripts are effectively a program. 
     The form, syntax and structure of the scripts may be designated using well-known techniques. The particular form of the script language is not believed to be critical to the invention. 
     It is contemplated that in the typical embodiment of the invention, a more experienced or skilled user of the IBM host and the terminal emulator will do the recording, and ordinary users are contemplated as doing the playback. In the description herein, the more experienced or skilled user will be referred to as the &#34;administrator,&#34; and an ordinary user will be referred to as a user. This terminology is for convenience, and should not be considered in a limiting sense. 
     The Hardware Architecture of the Preferred Computer System 
     FIG. 1 shows an IBM AS/400 110, an IBM S/370 120, and two PCs 130 on a token ring network 140. The AS/400 110 is representative of a class of IBM midrange computers which includes the S/36 and S/38. The S/370 120 is representative of a class of IBM mainframe computers which includes the S/390. The IBM midrange and mainframe computers represent a class of products known as IBM hosts and will be so referred as such below. IBM hosts are characterized in that they are multi-user systems, wherein users typically access them through synchronous or bi-synchronous terminals. The terminals are typically dumb, in that they typically have little processing capability, such as the CUTs described above. 
     Terminals typically comprise a monitor for providing host display session output displays to the user, and an input device such as a keyboard for receiving user input. Thus, programs running on an IBM host which would interact with a user typically display data on the display of the user&#39;s terminal and receive input from the user through the terminal&#39;s keyboard. 
     The PCs 130 are preferably Intel-based personal computers using the Microsoft Windows 95 operating system, although other types of computers and operating systems are within the scope of the invention. The PCs 130 are representative of a class of computers which will be referred to herein as &#34;guest computers.&#34; The guest computers are characterized in that they have the ability to access the IBM hosts through a special hardware interface and software interface, the software interface for emulating a dumb terminal typically comprising terminal emulation software. To the IBM host, the guest computers appear to be CUTs. 
     An important feature of the guest computers is that they receive display sessions from the IBM host, but rather than automatically displaying them, the guest computers receive the displays in a &#34;host display session presentation space.&#34; With typical terminal emulation systems on PCs 130, the host display session presentation space is displayed directly to the monitor 132. However, because of the additional processing capabilities of the guest computer over a dumb terminal, the terminal emulation program can affect other results. 
     The PCs 130 preferably have a monitor 132 on which displays are presented to a user, and a central processing unit 134 which stores the programs and processes them. The PCs 130 include user input devices such as a keyboard (not shown) and a mouse (not shown). Other input and output devices are within the scope of the invention. 
     The Method of Creating the Navigation Path Objects 
     Referring now to FIGS. 2A and 2B, a first major aspect of the invention is described. This aspect relates to the creation of a navigation path object as a navigation file by an administrator. This aspect is preferably embodied as a program stored in the PC 130 and run as desired on the PC 130. This aspect of the invention may also be appreciated from the pseudo code for this program in Appendix A. 
     In step S205, the process begins. For example, this may be from the administrator activating a &#34;Navigator&#34; pull-down 405 for a menu 400 as shown in FIG. 4 and selecting a &#34;Record&#34; menu item 410. 
     Preferably, there is a step S210 wherein the program causes a Windows dialog 500 to be displayed on the monitor 132 as shown in FIG. 5. This is generally referred to as &#34;opening a dialog.&#34; The dialog 500 includes a prompt 510 for the user to enter a name to be used for the navigation file, and an input field 520 for the name. Other elements of the dialog 500 will be appreciated by those of skill in the art and are therefore not described further here. 
     The navigation file will store a number of scripts recorded during the administrator&#39;s interaction with the IBM host. Preferably, each action by the administrator or the IBM host generates a sequence of instructions comprising a script for that action. Each instruction preferably includes a command selected from a predefined command set, and variable data. 
     The navigation file may be stored in the PC 130 or in another location such as in a file server, as known in the art. Once the administrator has selected a name for the navigation file, the program in step S215 creates and opens the navigation file. 
     Once recording begins, the administrator is preferably presented with a standard terminal emulation window 700 on the PC&#39;s monitor 132. However, there is preferably also a tool bar 600 as shown in FIG. 6. Note also that the terminal emulation window 70 includes the &#34;Navigator&#34; pull-down 405 of FIG. 4. 
     The tool bar 600 includes a number of buttons 610, 620, 630, 640, 650, 660, 670, 680, 690. The start recording button 640 functions the same as the Record menu item 410 on the pull down menu 400 (FIG. 4). The remaining buttons will be described with respect to the relevant commands, although their function may be appreciated from the figure by those skilled in the art. 
     The center of the terminal emulation screen 700 is the terminal display area 710 (or terminal screen) which reproduces the host display session presentation space. Other elements of FIG. 7 will be familiar to or readily understood by those skilled in the art. 
     One event S230 is the administrator causing the PC 130 to be connected to the IBM host. This event essentially comprises the actions necessary for the administrator to start an IBM host session. When this is recognized, then in step S235 the program saves the sequence of commands used to connect to the IBM host into the navigation file as a &#34;connect&#34; script. The connect script preferably includes instructions for using typical terminal emulator functions to open the session. After this, processing continues at step S236. 
     Another event S240 is where the terminal emulator receives a screen update from the IBM host. This update may be a new screen or a revision of the next previously received screen. When this occurs, in step S245, the program preferably causes the screen&#39;s signature to be saved in the navigation file as a &#34;screen update&#34; script. A screen signature comprises a simple means for identifying particular screens. More preferably, the screen signature includes one or more unique and protected fields from the screen, their positions and lengths. After step S245, processing continues at step S246. 
     Another event S250 is where the administrator presses a key on the PC&#39;s keyboard. Such an event may happen, for example, as the administrator starts an application on the IBM host and navigates through the application&#39;s menus. The program preferably in step S255 stores an identification of the key in a &#34;key-press&#34; script in the navigation file. This key identifier is preferably a mnemonic of the key, as will be appreciated by those skilled in the art. After step S255, processing continues at step S256. 
     Another event S260 is where the administrator creates an input field. In other words, and with reference to FIG. 8, the administrator identifies a specific place 820 on the terminal display 710 which is an editable field and for which, during playback, the playback user will need to enter data. One of the tools 610 on the tool bar 600 is preferably designated for allowing the user to mark input fields. The administrator uses the mouse to click on the tool 610, then uses the mouse to click and drag an input box 825 on the terminal emulation window 700. 
     As shown in FIG. 8, the USERID field 825 and a PASSWORD field 835 have been marked with boxes by the administrator. When the script is run by during playback, the user will be prompted to enter his user ID and password for the IBM host. After entry by the user, the playback program will send the user ID and password to the IBM host. 
     Referring again to the recording process, after marking a field 825, the program preferably displays a dialog 900 as shown in FIG. 9 (step S265). This dialog 900 allows the user to enter a title 910 for the marked input field 820, as well as displays the type 920, length 930 and attributes 940 of the input field. In step S266, the title 910, type 920, length 930 and attributes 940, plus the position of the field in the terminal screen 710, are saved as an &#34;input field&#34; script in the navigation file. The title, type, length and attributes are used during playback to properly prompt the user for an input and insert that input into the previously identified field in the proper format. After step S266, processing continues at step S267. 
     Another event S270 is where the user selects an area 1010 of the terminal screen 710 like the one shown in FIG. 10 which, during playback will have data which will be imported to the PC 130. This is useful for importing data from the IBM host to an OLE container application. 
     Preferably, the administrator may mark one 1010 or more 1020 rectangular areas of the terminal screen 710 for data selection. One of the tools 650 on the tool bar 600 is preferably designated for allowing the user to mark data areas. The administrator uses the mouse to click on the tool 650, then uses the mouse to click and drag the boxes 1010, 1020 on the terminal screen 710. Preferably, these multiple areas 1010, 1020 are combinable by the program so that, during playback, they can form a table. This is especially desirable where a large table is needed which spans across multiple host panels. 
     After the areas are marked S270, the program displays a Data Properties dialog 1100 as shown in FIG. 11 (step S275). Using this dialog 1100, the administrator may select whether the marked areas 1010, 1020 should be transferred as text 1110 or as a table 1120. Furthermore, if a table 1120, then the administrator may select whether the data should be parsed by blank space 1121 or by a special character 1122, and whether extra blank spaces should be removed 1123. 
     After the data import areas have been marked and configured (S275), the program saves the position, length and data format of the marked areas as a script in the navigation file as a &#34;data import&#34; script (step S276). After step S276, processing continues at step S277. 
     Another event (S280) is when the administrator causes the terminal emulator to disconnect from the IBM host. In this event, the program saves the disconnect command as a &#34;disconnect&#34; script in the navigation file (step S281). After step S281, processing continues at step S282. 
     Two other events correspond to buttons on the tool bar 600--a repeat tool 660 and an until tool 670. These tools 660, 670 are used to create loops in the navigation file. The repeat tool 660 is selected (step S283) where the top of the loop is desired and creates a &#34;loop top&#34; script (step S284). The until tool 670 is selected (step S286) where the bottom of the loop is desired and creates a &#34;loop bottom&#34; script (step S287). Preferably, when the administrator clicks on the until tool 670, the program displays a dialog for the administrator to enter termination conditions for the loop. 
     The repeat and until tools 660, 670 enable smart page-down actions until the end of a document or database is reached. The loop top ad loop bottom scripts may be combined with the data import script to retrieve an unknown amount of data from a document or database. 
     The last event is the administrator stopping recording (step S290). To do so, the program preferably includes, on the pull down menu 400 (FIG. 4) a &#34;stop&#34; item 430. Preferably, this item 430 is greyed until recording starts. One of the tools 630 on the tool bar 600 is preferably designated for allowing the user to stop recording. The administrator uses the mouse to click on the tool 630. If the administrator selects the stop item 430 or the stop tool 630, then the navigation file is closed and processing ends. Otherwise, processing continues at the top of the recording loop (step S220). 
     Once the scripts are recorded, preferably there is provided a means for editing the scripts. More preferably, there is provided a means for graphically displaying the scripts, for example in sequence. 
     The Method of Using the Navigation Path Objects 
     Referring now to FIGS. 3A, 3B, 3C and 3D, another major aspect of the invention is described. This aspects relates to the playback of the navigation file by a user and is preferably embodied as a program stored in the PC 130 and run as desired on the PC 130. This aspect of the invention may also be appreciated from the pseudo code for this program in Appendix B. 
     In step S300, the process begins. For example, this may be from the user activating the pull-down menu 400 of FIG. 4 and selecting &#34;Play&#34; 420. Alternatively, the user might click on the playback tool 620 (FIG. 6). Preferably, there is a step S302 wherein the program opens a dialog similar to that shown in FIG. 5 for obtaining the name of the navigation file to be played. Then the program opens the navigation file and retrieves the navigation scripts (step S304). 
     Alternatively, the navigation file may be played by running it from the Windows 95 Explorer or from the Windows 95 desktop. As another alternative, the navigation file could be started and played via an OLE link. As a further alternative, the program could include a means for graphically displaying the screens stored in the selected navigation file, and for allowing the user to select a particular screen as a target. If the target screen is not the last, then the program would stop script processing when the target screen is reached. 
     A connector S306 is shown which is the top of the program&#39;s loop for sequential playback of scripts. This process generally involves testing the current status of playback, reading the next script, identifying the type of script, replaying the command sequences of the script, and returning to the top of the loop. 
     At the top of the loop (step S306), the program determines whether it has reached the end of the navigation scripts (steps S310). If so, then processing is complete and the program stops (step S314). Otherwise, the program processes messages from the program&#39;s windows and from other applications to avoid &#34;freezing&#34; of the program&#39;s user interface during playback (step S312). 
     Next, before processing a script, the program determines whether the user has stopped the navigation process (step S320). This may be because the user clicked on the stop tool 630 (FIG. 6) or selected &#34;Stop&#34; 430 from the pull-down menu 400 (FIG. 4). If so, then processing stops (step S314). Otherwise, the program loads the next navigation script (step S325) for processing. 
     If the navigation script is a connect script (step S330), then the program uses the command sequences of the connect script to connect to the IBM host (step S335). Then processing returns to the top of the script processing loop (step S306). 
     If the navigation script is a disconnect script (step S340), then the program uses the command sequences of the disconnect script to disconnect from the IBM host (step S345). Then processing returns to the top of the script processing loop (step S306). 
     If the navigation script is a screen update script (step S350), then the program retrieves the saved IBM host screen contents (step S355) and stores the signature as the saved signature (step S356). Then processing returns to the top of the script processing loop (step S306). 
     If the navigation script is a key-press script (step S360), then the program preferably waits until the current screen signature matches the saved signature in the script (step S365), then converts the stored key mnemonic and sends the key to the IBM host (step S666). Then processing returns to the top of the script processing loop (step S306). 
     If the navigation script is a data import script (step S370), then the program preferably waits until the current screen signature matches the saved signature in the script (step S375). Then, the program gets the position and format of the selected data from the script (step 376), and composes and saves the selected data from the IBM host screen (step S377) as specified in the script. Then processing returns to the top of the script processing loop (step S306). 
     If the navigation script is an input field script (step S380), then the program preferably waits until the current screen signature matches the saved signature in the script (step S375). Then, the program gets the input field attribute and field title from the script (step S386), opens a dialog with the input title to retrieve the user&#39;s desired input (step S387), and sends out the user input to the IBM host into the screen position defined in the script (step S388). 
     If the navigation script is a loop top script (step S290), then the program notes the location of the script and continues (step S391). Once the loop bottom script is met (step S395), the program tests whether the loop termination conditions of the loop bottom script are met (step S396). If so, then the next script is processed (step S306). Otherwise, the program returns to the corresponding loop top script (step S396). 
     If the script is not identified, then it is ignored and processing returns to the top of the script processing loop (step S306). 
     Although exemplary embodiments of the present invention have been shown and described, it will be apparent to those having ordinary skill in the art that a number of changes, modifications, or alterations to the invention as described herein may be made, none of which depart from the spirit of the present invention. All such changes, modifications and alterations should therefore be seen as within the scope of the present invention. 
     
                       APPENDIX A______________________________________Learning (Record) navigation:______________________________________if starts learning navigation,opens a dialog and asks user for navigation filename(.NSN filename).creates and opens this file.while not quit,if connects host,saves connect command into navigation file.if receives host screen update,analyzes screen content for unique signature:   (signature analysis:)   if is unformatted host screen,    if is not a blank screen,     gets the first 20 characters as signature.    else     use NULL as signature.   else    for the first, second, and the second last     protected fields, strips out leading repeat     characters.     filters out date and time digits.     saves the position and length of this protected     field as signature field.saves screen contents, position and length ofsignature fields into navigation file.if key pressed,saves key mnemonic into navigation file.if creates an input field,allows user to configure field attributes and fieldtitle through short-cut menu.saves position, length, field attributes and field title ofinput field into navigation file.if selects data,allows user to configure data format throughshort-cut menu.saves position, length and data format of selected datainto navigation file.if disconnects host,saves disconnect command into navigation file.if stops learning navigation,saves and closes navigation file.quit.}______________________________________ 
    
     
                       APPENDIX B______________________________________Following (Playback) navigation:______________________________________if starts following navigation,opens a dialog, asks for navigation filename.opens this navigation file and retrieve navigation scripts.while not end of navigation scripts,allows other windows messages flow.if user stops following process,quit.gets next navigation script.if navigation script = connect,connects session.else if navigation script = disconnect,disconnects session.else if navigation script = host screen update,retrieves screen contents, position and length of signaturefields.composes and concatenates signature fields as the savedsignature.else if navigation script = send key,waits till current screen signature is the same as the savedsignature.converts key mnemonic and sends it to the host.else if navigation script = data select,waits till current screen signature is the same as the savedsignature.gets the position and format of selected data.composes and saves the selected data from currenthost screen.else if navigation script = input field,waits till current screen signature is the same as the savedsignature.retrieves input field attribute and input title.pops up dialog with input title to retrieve user input.sends out user input into correct host screen position.}______________________________________