CZ9101521A3 - A method for assisting in the generation and removal of windows at a plurality of remote terminal display screens - Google Patents

Abstract

The method involves using a computer system having a host processor executing applications programs, and interconnected through a number of communications controllers each connected to a number of non-programmable and programmable terminals. The processing steps required for windowing may be distributed between the host processor and the controllers. The host processor generates and sends to the controllers (USC) a data stream defining the window parameters. Each controller is adapted to construct and display the window on the display screen(s) which it controls.

Description

The invention generally relates to computer workstations that are connected to exchange information to host or mainframe computer systems; in particular, the invention relates to a method and apparatus for generating and removing windows on certain computer workstations to provide uniform user interaction between different types of workstations. Further, the invention relates to a method and apparatus that greatly improves the overall response time for presenting and removing windows in systems where the host processor executes application programs and is connected to a plurality of remote terminals.

BACKGROUND OF THE INVENTION

Historically, the manipulation interface with the mainframe system has evolved from a single manipulation control console that was connected to the mainframe structure. Handling control console formed. only a keyboard that allowed the operator to generate simple input commands, and a display screen that allowed the mainframe to present simple status messages to the operator. The development and dissemination of this concept led to the development of several terminals with limited intelligence that allowed several users to communicate with the mainframe system where multiple terminals were

61830 (2761830_upr3.doc) y 3 o 3 o

0 0? 3 Ó 1)

0 3 0 O

O 0 0 3 0 3

0 0>

• 0300 O <0 o O O O O o o o o o o .7 J) O l

OO o o placed possibly remote from each other and from the mainframe, but commonly connected to the controller and the controller was connected to the mainframe computer system. However, the concept of multiple terminals was a relatively low cost solution of allowing multiple users to communicate with the mainframe computer system, but with the limited intelligence contained in each terminal, so that user communication was limited to relatively simple input / output transmissions.

The development of standalone personal computers (PCs) provided a high level of internal intelligence and allowed the addition of a huge number of user interface features to the PC, with the result that PCs became very user-friendly devices. Among the interface improvements made possible by the development of personal computers were improved cursor control devices, scrolling and windows. These improvements greatly improved the computer's communication with the user.

User-friendly personal computers soon adapted to communicate with host computer systems, initially by connecting the personal computer to the controller, and writing software that allows the personal computer to emulate a terminal with a limited intelligence normally connectable to the controller. Alternatively, a PC / mainframe interface has been developed that allows the PC to communicate more or less directly with the host processor where independent intelligence contained in the PC could be both to improve the user interface with the host system and to independently execute software independently of the host system. The class of terminals developed using this concept, known as intelligent terminals, and previously developed terminals with limited intelligence, have become known as silly terminals. Due to the widely differing internal intelligence of these two types of terminals, we have also (2761830_upr3.doc) »ΛΟ πο ο ο ο η ί ο ο α .7 Ο« Ο ·> ·>

.3 0 0 7 7 3?, 3 η ··> 3 0 7

7 7 7

7 1 ί 1 mn mo -m ο 7 greatly began to vary the capabilities and rules for using terminals.

Considerable effort has been made to attempt to develop a set of rules for the normal use of computer workstations, although the hardware designs of these workstations may vary considerably. The basis of this effort is to simplify the rules for users of these workstations and thereby reduce the amount of time required by the user to understand communication with the workstation. Another principle is to enable the common programming interface to manage presentation management functions independently of workstation device types.

Ideally Ideally, the rules for user access and interaction would be the same for all workstations, regardless of the level of complexity of the hardware design of any workstation. However, the ideal situation is difficult to achieve because of the complexity of the hardware design between the stations. The so-called intelligent workstation class includes a hardware that is capable of a full range of independent computing operations; a so-called silly workstation typically contains only enough hardware equipment to allow the operator to interact with the keyboard and display screen to communicate simple information and commands. For example, International Business Machines (IBM) classified the intelligent workstation space under the name independent workstation or programmable workstation (PWS), and the second category under the designation dependent workstation (DWS) or non-programmable terminal (NPT). The programmable workstation is capable of performing a relatively high level of independent computing operations by itself, while the dependent workstation is in principle only able to receive commands and control information from (2761830_upr3.doc)

1. i 7 ff 7 7 O

3 1 Ί 3 1 f! 7 7 fi 1

0 3 3 1 clay 3 7 .7 7 3 Ο 3 '. »Ο 3} 7 ·> 3 1 7 · | :>

3 3 3 13 π 3 Ο 7 0 0 0 7 Ο ·) ο display the host computer and transfer operator keystroke data back to the host computer via the controller. Naturally, the cost of a programmable workstation is considerably higher than a dependent workstation, although for a large number of computer applications the complexity of the dependent workstation is limited to the task needed. It is not uncommon for a computer buyer to initially use one or more dependent workstation devices connected to a host computer and then later replace those devices with programmable workstation devices. It is also not uncommon to have both dependent workstation devices and programmable workstation devices connected to the same host computer system.

A programmable workstation is typically a complete computer computing system and may have a built-in media device such as a floppy disk drive or disk. Thus, the programmable workstation can perform stand-alone computing applications on the workstation and can communicate independently with the host computer system via standard communication links. In contrast, the dependent workstation is connected to the host computing system via a workstation controller (WSC), and in a typical system configuration, one workstation controller is connected to a plurality of dependent workstation terminals and supports a plurality of dependent workstation terminals. The workstation controller communicates with the host processor via a local bus or remote communication links, but each dependent workstation is connected to the workstation controller via a communication cable.

The dependent workstation can only work on (2761830_upr3.doc) β »o oo and o 1

O o o o o o o o o o

5 0 0 O 0 0 0 0

O Λ

O O> 3

O '3, · y

O O O

O O β 03 003 computer, which is based on host computer computing applications and has only limited internal capability to provide improved user interface features. While a programmable workstation typically has 1-1-6 or more megabytes of internal memory, the internal memory of a dependent workstation is minimal. A programmable workstation can always store at least the data required to assemble or construct one or more images on the screen in its internal memory, while the dependent workstation can only store data to restore the currently displayed image on the screen and therefore each time the display device screen changes to dependent workstation, the change must be initiated by the host processor.

In any typical prior art system that utilizes a host processor and workstation, where workstations are used to interact with user and access and the host processor is used to execute application programs, the host processor provides some basic data. For example, the host processor may generate a data stream containing information to be displayed on the workstation screen and presentation control information and the position of the data on the screen. Generally, the data stream carries no logical intelligence, that is, information that allows the workstation to independently control and manipulate the following on-screen panels resulting from their communication with the user. Control and manipulation of each panel on the screen is typically generated by the host processor, transmitting a new data stream for each panel, where each data stream contains new presentation and location information.

In the case of a programmable workstation, the data (2761830_upr3.doc)

6t> ό ο Λ .3 π) - Ο '3 Λ. Ο 3 ') η .1 Λ ο ο ο ο ο ι> 3 ό Ο D 3 D 3} ί) »3, .Ο ο -> -) Ο ο

43 4 3 0 0 3 0 0 3 3 6) ') Ο Ο The host processor flow is sent directly to the workstation and processed internally on the workstation, which itself contains enough internal memory and program data to directly control the interaction with the display screen device and keyboard. In the case of a dependent workstation, the host processor data stream is sent to the workstation controller (WSC) and the workstation controller provides internal memory and control to directly control the display screen of the dependent workstation display device. The workstation controller may prompt the workstation to determine whether a keystroke should be recognized or whether any of a predetermined number of commands has been received. This results in a more limited set of options available to the user-dependent workstation than is available to the user-programmable workstation.

It would be an obvious benefit to the user if the dependent workstation terminals and the programmable workstation terminals were operated using the same set of user interaction rules, and manufacturers are constantly striving to do so. For example, IBM has defined a common user access (CUA) for use with the Systems Application Architecture (SAA) published in IBM Publication No. SC26-4583-0 under the name Common User Access Basic Interface Design Guide, and IBM Publication No. SC26-4582 under the name Common User Access Advanced Interface Design Guide.

These publications have identified a set of common standards for user access and attempt to achieve consistency between different types of workstation designs. However, these specifications distinguish in many important respects the rules for user access to programmable terminals (2761830_upr3.doc)

3 9 -Λ Λ 9) * 9 9 9393 9 999

3 9 '3 Ο «7 3 3

3 Π ί 3 3)? -, - »_>

9 9 Ί 9, Λ, ·>

9:> 7 9 ο 7 ο τ 9 9 Λ Γ> ο π ->

workstations versus terminal dependent workstation terminals. It would be an advantage if the number of occurrences of differences between these terminals were limited or even eliminated to allow users to perceive the same access to the system regardless of the degree of complexity of the user's workstation.

Previous publications distinguish programmable workstation terminals as programmable workstations and dependent workstation terminals as non-programmable terminals. A non-programmable terminal is defined as a terminal connected to the host processor through a workstation controller in which all or most of the user interface functions are controlled by the host.

The user's interaction with the terminal and hence with the host computer is achieved through a user-controlled keyboard and display screen. The user communicates with the display screen using a cursor that provides a pointer for user interaction with the panel. In some cases, user interaction is at least partially achieved through a mouse device that allows the user to communicate with the panels on the screen and transmit signals to the host processor to generate new and / or changed panels on the screen.

Among the improvements that have been made available to improve user interaction in recent years is the concept known as window display, which allows the display panels to be presented overlapping each other on the display device screen. This concept allows the user to keep the panel off the screen while temporarily (2761830_upr3.doc)

5 5

5 .5 5

5 5

5 5 n <5

5555 55

O «1 5

(5) overlay another screen panel completely or. partially above the maintained panel. This allows the user to focus the attention from the first screen panel to one or more secondary screen panels for assistance and / or insight, so that the overall user interaction can be improved. The processor controlling this operation must maintain information regarding the original display screen and all subsequent overlapped windows, including the specific screen panel conventions associated with each of them, and must also control the computing operations controlled by the user during his interactive use of each window. Window work activities place considerable computational load and also require reasonably short response times to be effective.

In a computer system that has a host processor executing application programs and that contains a large number of remote terminals, CPU load due to improvements such as windows is a serious problem because all of the computing operations must be performed in the host processor and transmitted to the terminals in real time noticeable delays that may be a barrier to user efficiency. With the increasing number of terminals connected to the host processor, the problem becomes more severe and virtually puts such computational loads on the host processor that window enhancements become unusable in systems of this type. Therefore, without an adequate solution to this problem, the Common User Access (CUA), which defines a set of interaction rules designed to accommodate all terminals, cannot be implemented. In particular, it is desirable to find a solution to this problem so that common user access rules can truly be applied to all terminals. The present invention solves this problem and provides a solution that allows application (2761830_upr3.doc)

- 9 ·) "> 15 o:

030 011 common user access rules for dependent workstation terminals and programmable workstations.

also to terminals

Although a programmable workstation terminal is considerably more complex than a dependent workstation terminal when used in an environment where the host processor executes application programs and only uses the programmable workstation terminal to create an operator / user interface, the programmable workstation terminal suffers mostly from the same constraints as Dependent workstation terminal. For example, each time a panel changes from a screen to a screen of any type of terminal, the host processor creates a panel description and presentation and constructs a data stream for transmission to the terminal. A typical bitrate transfer may contain 2000 bytes of information, more or less, and may require a transfer time of at least a few seconds, in addition to the processing time required to create and develop the bitrate. In a system comprising a significant number of these terminals, the constraints of computing load and transmission time are cumulative, resulting in a significant reduction in overall system performance. The present invention provides a method of improving this performance with respect to both programmable workstation terminals and dependent workstation terminals. Here, however, for the sake of clarity, we will refer to the terminals of dependent workstations, it being understood that the uses and advantages of the present invention are equally well applicable to both types of terminals. Where reference is made herein to workstation controllers, WSCs are understood to be associated with slave workstation terminals and programmable workstation terminals not using workstation controllers. Programmable Workstation Terminals Communicate (2761830_upr3.doc)> no λ

0 3

3

Λ 3 3 3

3

3

3

3 3 3 3 3 <33 j o i? n

3 3 .3 O 3

3 3

3 3 3 3 directly with the host processor through appropriate 1/0

communication control equipment, but equipment programmable working stations have internal logic, that effectively performs the same features like done controllers work station. SUMMARY OF THE INVENTION The present invention provides method a equipment , which

allowing the host processor application software to run in a window environment in a system using multiple dependent workstation terminals, the present invention allows for common user access rules to be applied to the dependent workstation terminals. The method is performed in groups of interactive steps between a host processor and a workstation controller (WSC), wherein certain initial steps are performed in the host processor to define the content of the window, and the workstation controller performs the steps of the method to define the presentation and position of information associated with the window and the device the dependent workstation performs the steps required to display information from the window.

It is a main object of the present invention to provide a method and apparatus that allows terminal users of dependent workstations to gain the benefits of windowing when connected to a host processor executing application programs.

It is a further object of the present invention to provide a method and apparatus for using windows at terminal dependent workstations according to common user access rules defined for user interactivity.

It is another object of the present invention to distribute (2761830_upr3.doc) ·>

9 1 9

9

1 9 9

9

9

9

999 999

9 9 i -9 9> 9 □

O 9 computing load associated with window performance to maximize the efficiency of the entire computing system and user.

BRIEF DESCRIPTION OF THE DRAWINGS

DETAILED DESCRIPTION OF THE DRAWINGS FIG. 1 FIG. 2 FIG. 3 FIG. 4 FIG. 5 FIG. 6 FIG. 7 FIG. 8A FIG. 8B FIG. 9 FIG. 10A A typical block programmable workstation diagram typical block diagram of a dependent workstation typical block diagram of a workstation controller typical block diagram of a plurality of dependent workstation devices connected to a host computer through a workstation controller a simplified diagram illustrating an image data flow in a system having dependent workstation terminals block diagram working with windows according to the prior art block diagram for constructing a window block diagram according to the invention for creating a window on a dependent workstation block diagram according to the invention for creating a window on a programmable workstation block The diagram of the present invention removing the sample panel window from the screen (2761830_upr3.doc) differs

Fig. 10B The panel of the screen of Fig. 9A with an exemplary window

DETAILED DESCRIPTION OF THE INVENTION

Referring first to Fig. 1, a typical block diagram of a programmable workstation is shown; the circuitry in the intermittent boundary 10 is generally located on one or more printed circuit boards in a programmable workstation design. The microprocessor 111 is typically Intel type 80286 or 80386 or equivalent microprocessors from other manufacturers. The microprocessor 111 has an external bus that can communicate with a plurality of adapters that are themselves connectable to various internal and external devices. A typical Programmable Workstation will have a keyboard 112 and optionally a mouse 114 connected via adapters 113, 115 to the internal bus 118, a monitor connected to the internal bus adapter, one or more disk or diskette adapters

121,

122 connected to one or more disks or diskette drives 119, 120 and connected to the internal bus 118, and a communication adapter 123 that is connectable to other systems by external cables 124. RAM 125 is typically a direct access memory having a capacity of 1-16 megabytes large enough to accommodate the entire operating system, additional programmatic workspace, monitor screen cache area, and application program execution area. Permanent ROM 126 is a read-only memory that typically includes code for initializing the machine after performing diagnostic operations and controlling the basic 1/0 system; The ROM typically has a capacity of 64-128 kilobytes. The programmable workstation 10 (PWS) is therefore operable as a stand-alone computer system (2761830_upr3.doc) ό 4 4 Λ 4 4 »

Ρ 4 4 9 4 3 ο m ο .-, 4

Λ 4

4 »« 3 0

9 4 4 4 ί »4 ·> ο y

4 4 4 4

4 4 4 4 4 4 0 440 or as an 'independent workstation' that can be connected to the host computer via external cables. Programmable Workstation 10 features allow it to provide a wide range of user enhancements, including full-scale cursor control, instant image flip, and monitor screen adjustment. All of these improvements are contained in the programmable workstation 40 itself and controlled by the programmable workstation 10 itself, although when the programmable workstation 10 is connected to the host computer processor and is operated as a workstation, it receives its commands and control from the host processor. For example, the host processor may transmit the data stream embodying the monitor screen content to the programmable workstation 10, and may identify formats to display and control data, but once the programmable workstation 10 receives general instructions from the host processor, the programmable workstation 10 itself generates internal control signals for controlling the actual display of data on the display device screen. In a preferred embodiment, the programmable workstation 10 shown in Figure 1 is IBM Personnel System / 2 or equivalent, although another IBM personal computer or equivalent can be used.

Dependent workstation

Giant. 2 shows a typical block diagram of a dependent workstation 20 (DWS) where the circuitry. The microprocessor 211 is typically Intel based on an 8088 or 8086 processor or equivalent, and the microprocessor 211 has an external bus that can be connected to multiple adapters to allow communication with a limited number of external (2761830_upr3.doc)

equipment. 73 -1Δ- j α ϋ » ~ 3 3 3 3 3 3 3 3 3 0330 33 O 3 3 ' 3 3 3 3 3 »33 - •> 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 For example adapter 212 keyboard 213 allows communication between microprocessor 211 a keyboard 213,

the display adapter 214 allows information to be transmitted to the monitor screen 215, and the communication adapter 218 allows communication between the slave workstation and the host controller. Direct access memory 216 typically has a storage capacity of 3-5 kilobytes, for storing the screen cache and for providing a limited amount of internal memory processing area. Permanent ROM 217 typically has a capacity of about 8 kilobytes, for storing power-on code, diagnostic code and pattern generation patterns, and processing communication protocols to communicate with other systems. The slave workstation 20 is not capable of any significant internal processing other than that required to interface with the keyboard and monitor and to communicate through the communication adapter. Therefore, all information displayed on the monitor screen 215 must be passed through the communication adapter 218 to the RAM, and the microprocessor 211 generates sufficient internal control to display the information on the monitor screen 215. Similarly, all keystrokes from the keyboard 213 are temporarily received in RAM 216, causing the communication adapter 218 to transmit keystroke information via cable 219 to the workstation controller 30. In the preferred embodiment of the dependent workstation shown in FIG. 2, the display device is an IBM 5250 family, although other equivalent types of dependent workstation 20 may be used.

Workstation controller (2761830_upr3.doc)

3 3 0 9 9 3 About

7 3 3 9 3? > 5 O O)

O 3 3 3 5 O>

Λ O 9- ·) 9 9> »9 9 o 3 3 3 9 9 -»

7 9 9 9 9 9 9 0 3 3 9 0 2

In typical systems, the function of the workstation controller 30 is to provide information transfer and control of a number of remote terminals from one host processor. This function is usually performed by a hardware and software package that is uniquely identified and separate from the hardware and software packages of the host processor. The workstation controller hardware is typically included on the circuit board assembly (s) that is pluggable into the host processor accessory slot, and the workstation controller software is typically run by hardware independently of the software that is run by the host processor. However, in some systems, the workstation controller function is entirely a function of the software package, with the software running on the host processor hardware. Although a preferred embodiment of the present invention is disclosed with respect to the concept of a workstation controller that is physically separate from the host processor in both hardware and software details, the invention is applicable to a second type of workstation controller where functions are performed entirely by a software package on the host processor ..

Giant. 3 shows a typical block diagram of a workstation controller 30 (WSC) type that typically communicates with a plurality of dependent workstation device 20. The workstation controller 30 has a plurality of circuits included in the package indicated by a dashed boundary, and a microprocessor typically based on Intel 80826. or equivalent. The workstation controller microprocessor 30 is typically connected to a system bus adapter that can communicate with the host computer processor itself. The workstation controller 30 also has an internal data bus 303 and a RAM 304, (2761830_upr3.doc).

3 0 Λ 10

ΟΛΟ Λ Λ '

Ο Ο - »1 Λ Λ

Λ Ο Λ Λ

Ο Ο Ο 7 ί> 7 7 3 Λ 3 3 7

3

0 0 0

Λ Λ 9

Λ Λ Λ

Ο Λ

· Ο Ο 3 · ύ that has a capacity of 0.5-2.0 megabytes and ROM 305 that has a capacity of about 16 kilobytes, containing the code for initializing the workstation controller and for diagnostics regarding the workstation controller. The internal data bus 303 of the workstation controller 30 is connected to a communication adapter 306 that is externally connected to the multiplexer branches to allow a plurality of dependent workstation devices to communicate with one workstation controller 30. In a typical application, branching circuits are connectable to up to 40 dependent workstation devices and display screen information for each of these dependent workstation devices is stored in RAM 304 of the workstation controller 30. Similarly, keystroke signals from all device dependent workstation devices are received by the workstation controller 30 and stored in RAM 304, for subsequent communication to the host processor or for internal processing by the workstation controller 30.

In the preferred embodiment, the workstation controller 30 of FIG. 3 is an expansion card for the AS / 400 computer system, wherein the microprocessor is suitably programmed as shown in FIG. 7.

Giant. 4 shows a typical system interconnection block diagram where the host processor communicates with the workstation controller 30 via an I / O bus (1/0 = input / output) and the workstation controller 30 communicates with up to 40 dependent workstation devices 20 via communication cables. Other devices and controllers may be connected to the I / O bus 401 to communicate with the host processor 400. In the preferred embodiment, the host processor 400 is part of an AS / 400 computer system.

(2761830_upr3.doc) <> »9 Ι> 3 Ο

0 9 Λ 9 9 3 3 0 0 3 8

009 Ο ‘9 9 9

009 Ο 9 9 Ο 9 9 0 .9 *> Ο 3 9 0 9> 900 99 Ο Ο Ο Ο 9 Ο 3 3 Ο Ο 6

Under typical prior art operating conditions, the host processor 400 constructs a display device screen for each of the terminals to which it is connected, the host processor 400 then transmits data representative of each display device screen to a workstation controller 30 where they are maintained in RAM 304 The workstation controller 30 then transfers data from the monitor screen to each of the dependent workstation devices 20, and each dependent workstation device 20 has sufficient internal space to hold the monitor screen data for image presentation purposes. monitor to the user. Window position information may include window position information, although the workstation controller 30 has no specific knowledge of the window and only treats it as part of the monitor image. The workstation controller 30 transmits this information to the dependent workstation 20 containing the appearance and position of the window on the screen. When the user of the slave workstation 20 performs a keystroke, the slave workstation indicates that the slave workstation has keystroke data available for transmission to the host processor 400. The workstation controller 30 transmits this keystroke data when polling the slave workstation 20. The workstation controller 30 maintains in its internal memory and manages information regarding all of the monitor screen images it handles and information regarding all of the window position information for the various devices of the dependent workstation with which it communicates. It transfers this information to the host processor 400 and receives this information from the host processor 400 upon command.

Giant. 5 shows a simplified diagram that illustrates 0 remote processing of the monitor data flow in a system having terminals of the dependent workstation 20. The host processor 400 executes the application programs 5 as part of its normal operation function. These application programs 5 communicate from time to time with terminals connected in the system, either by keyboard data sent from the terminals or by generating monitor information to be transmitted to the terminals for display. When an application program needs to communicate with a remote terminal, it invokes an E5 application program interface routine, one of its forms being identified as the monitor data manager 6 If the information is to be displayed on the remote terminal, the monitor data manager 6 constructs a data stream according to a particular format and transfers this data flow to the workstation controller 30. The workstation controller 30 selectively communicates with all the devices of the dependent workstation 20, selectively activating the respective ones. device and then forwards the information to be displayed to the selected device of the dependent workstation.

Giant. 6 shows the software communication to construct a window block diagram that illustrates the hardware necessary for a remote technology monitor. The application on the terminal screen, according to the prior state of the host processor software, invokes the monitor data manager program to accomplish this task. The monitor data manager software in the host processor first invokes the SAVE command to the selected remote terminal. This command is transferred to the workstation controller, thereby causing the workstation controller to retrieve the information that is currently displayed on the selected terminal screen and to transmit this information, formatting table information, and status information about a particular station associated with the selected terminal to the host processor. Obtaining and sending this information involves around (2761830_upr3.doc)

000 bytes and completion typically takes about 2.5 seconds with a typical 9600 baud communication link, in addition to the 12 seconds required to run the SAVE command itself. After receiving this returned information, the host processor starts the software routine (FIG. 7) to construct a window for the selected terminal. The window position and content information is then transferred to the workstation controller, which takes an additional 1-2 seconds, and selects the appropriate terminal and transmits a new monitor screen to the device. The terminal receives this new information and presents a new image containing the window as an overlay on its previous image.

The window removal process from the monitor screen essentially follows the same procedure as shown in Fig. 6, although in this case the host processor invokes the RESTORE command to restore the monitor image, format table and station status table information associated with the previous panel displayed on the selected terminal screen. This command is sent to the workstation controller for processing, which results in the workstation controller sending a new image panel for display on the terminal screen.

Giant. 7 is a flowchart showing steps for constructing a window. In the prior art, the software required to perform the steps shown in the flowchart is included in the host processor. The software constructs margins consisting of selective margin characters that surround the window edge and also generates blank characters to clear the image inside the window. For each row, an edge segment is constructed using a border character bound on both sides with a display attribute. Because the window is intended to overlay the previously displayed panel, part of the lower panel must be examined to determine whether (2761830_upr3.doc)

3 O 3 O Λ

Ί 0 3 »3 1 3 8

9 9 and 3

O O 3 9 3 3 3

9 9 9 .3 3 0-0 β 9 7 30 330

0 3

·) O 9 and λ λ

7 Λ

7 0 ··.> 3 3) any pre-existing highlight was shown and whether pre-existing highlight was shown outside the window area, the rightmost edge margins must be adjusted to maintain the highlight. The flowchart of the software shown in Fig. 7 is triggered for each row of the window, where the upper and lower rows of the window are filled with horizontal border characters accordingly.

Giant. 8A shows a flowchart according to a feature of the present invention for creating a window, illustrating the hardware and software replacement required to construct and display windows on selected device dependent workstations. The monitor data manager software in the host processor sends a CREATE WINDOW command and transfers the contents of the desired window panel to the workstation controller. The CREATE WINDOW command contains the position of the window, such as the top left corner, and the window area, such as the number of rows and columns. The position and area of the window together define the parameters of the window. This transmission takes the form of a 5250 bitrate containing the CREATE WINDOW command. This data stream is received by the workstation controller and is processed by software running on the workstation controller. The workstation controller software identifies a particular dependent workstation device to be affected by the data flow command, and the remaining steps shown in Fig. 8A are specifically directed to the selected dependent workstation device. The workstation controller software controls and monitors the status of all dependent workstation devices to which it is connected so that it can quickly perform device-specific processing steps. For example, the workstation controller maintains a record of the current cursor addresses for each of the dependent workstation devices it controls. For the selected device, the workstation controller obtains and stores this current cursor address so it can be (2761830_upr3.doc)

9 Λ Ο Ο Π 7 7

0 0 3 0 9 0 0 0> 3 4

909 Λ 979

I) Ο I Ο 9 0 0 9 6 0

-7 ο 7 Ο 3 .7 7

0 0 0 0 0 7 9 Ο 0 0 0 Ο> ο Μ restored after window removal. The workstation controller interprets the data stream received from the host processor and computes the screen area on the selected dependent workstation to be replaced by the window. The workstation controller retrieves and saves the panel contents that lie within the computed window area and also saves the format table contents for subsequent replacement in the panel after the window is removed. The workstation controller then constructs the window according to the steps shown in Fig. 7, assuming that the microprocessor shown in the workstation controller in Fig. 3 is suitably programmed to perform the steps of Fig. 7. The workstation controller then creates a window formatting table , which stores dependent workstations in a storage area associated with a selected device. The workstation controller then selects the dependent workstation device and transmits a new image containing the newly constructed window overlaid over the contents of the lower and previous panels. The dependent workstation device displays this new screen, and the workstation controller limits the cursor to the inside of the window.

Giant. 8B shows a flowchart of a feature of the present invention for creating a window on a selected programmable workstation device. In this case, the monitor data manager software in the host processor sends a CREATE WINDOW command and sends the contents of the desired window panel to the programmable workstation. This transmission is in all respects identical to the data flow 5250 described above for the workstation controller device. In other words, the host processor constructs the 5250 bitrate regardless of the type and identity of the receiving device. This is an important feature of the invention since the host processor software can be written without knowledge or whatever types of devices will eventually be connected to the host processor, whether (2761830_upr3.doc)

Ί 7 Ί 8

Ο Ο 3 Ο

7 3

3 7 3

7

7330 30

Ο 3 3 3 3

* 3> 73

3 .7 7

3 Ο 3 Ο 3

3 3 7 3

3 0 330 Ο · ') 7 3 7 as local or remote terminals. The data stream is received by the programmable workstation and is processed in much the same way as described above. The current cursor address is retrieved and stored for subsequent restoration after the window has been removed. The area of the screen to be covered by the window is calculated and the contents of the panel that is below the calculated area of the screen and the contents of the format table are saved for the next replacement. The window is constructed by the programmable workstation software, assuming that the microprocessor shown in Figure 1 has been appropriately programmed to perform the steps of Figure 7. The programmable workstation creates a window format table and presents a new monitor panel to the programmable workstation screen. The panel is displayed on the screen to complete the process steps.

Giant. 9 shows a flowchart of a window removal feature of the present invention showing the replacement of hardware and software required for the process. The host processor sends a REMOVE WINDOW command to the workstation controller. The workstation controller then receives the portion of the previous screen image that was covered by the window from its own internal memory. The workstation controller constructs a new monitor screen image, containing the screen image in front of the window, and restores the cursor position to the forefoot location, and restores the pre-window format table belonging to the previous screen image. The workstation controller then sends a new image to the dependent workstation, the dependent workstation receives the image and presents it to the user on the monitor screen. The REMOVE WINDOW command is processed in the programmable workstation in much the same way as shown in Figure 9 in terms of workstation controller / dependent workstation processing (2761830_upr3.doc)

? Ο ο · ·?

station. In both cases, the host processor generates a 5250 bitrate containing the REMOVE WINDOW command, and the bitrate is received by any type of device that is connected. In the case of a programmable workstation, all processing is performed in the programmable workstation itself because the programmable workstation communicates with its own monitor screen.

Giant. 10A shows by way of example a typical screen panel of the type that can be constructed and used by an application program. The panel contains three input fields, the first field (report type) and the last field (Giro accounts) are select fields. The middle field (accounting period) is an input field and a pop-up window is associated with this field. The pop-up window will list valid options that can be selected as input to the field. The user can bring up the pop-up window associated with this field by pressing F4; as soon as the user presses this key, a notification signal is sent to the workstation controller and then to the host processor to initiate the above computing transactions. Giant. 1OB shows the monitor panels after a pop-up window was presented on the screen. The user can select the desired option displayed in the pop-up window, according to CUA rules, and once ENTER is pressed, the option is selected. The pop-up window is then removed according to the processes described here.

The present invention provides a significant performance improvement by generating and removing windows by processor operations performed on a workstation controller. For example, lower panel data does not need to be transferred from the dependent workstation to the host processor when generating the window; this data is stored in the working controller local storage area (2761830_upr3.doc)

Ort • rt O rt 0 0 o o o rt rt o o o o o rt O o

rt 3 rt o it o o. ·> n. o rt o o rt rt rt rt rt rt rt rt rt rt station, which greatly reduces communication time to support remote stations. Further, window placement, edge generation, and panel formatting are processed in the workstation controller, thereby relieving the load on the host processor. Finally, the bottom panel data need not be transferred from the host processor to the dependent workstation once the window is removed, which also greatly reduces the communication time required to support remote workstations. If the workstation controller overloads to a point where computing power is lower than required, one or more additional workstation controllers can be added to the system.

Additional benefits are provided by distributing these processing steps to the workstation controller, as the host processor no longer needs to know device-specific features. For example, the host processor does not need to have any special knowledge of the features of any particular dependent workstation device because the workstation controller can present panel enhancements, such as working with windows, using the best features available on each device. Since the invention eliminates certain dependencies between the host processor and the dependent workstation devices, it is easier to develop new software and features because there is no need to take into account as much dependency as in the past. Support programs for dependent workstation devices can be developed with the workstation controller in mind, and it is no longer necessary to take into account the unique interrelationships between dependent workstation devices and the host processor.

The present invention may be embodied in other specific forms without departing from its spirit or essential attributes and therefore it is required that this embodiment be considered in (2761830_upr3.doc) π · '>

O O -J 9 9 9 9

O o o fi 9

99 9 9 9> 9 O

9 9 9

O 9

9

9

9 .9 9 9 9

9 9

9 9 9

9 9

9 9

9 9

In all respects, it is illustrative and not limiting, and reference is made to the appended claims rather than to the foregoing description as to the scope of the invention.

Represented by:

JOINT LAW OFFICE ALL GREEN CVO ° OKO CALCULATORS AND PARTNERS

120 00 Praha 2, Hálkova 2 Czech Republic (2761830_upr3.doc)

JUDr. Petr Kalensky attorney

120 00 Prague 2, Halkova 2

Claims (5)

A method for assisting in generating and removing windows on multiple remote screens (116, 215) of a remote terminal monitor, wherein each monitor screen (116, 215) has pre-existing monitor screen contents (116, 215) connected via a controller (30) a workstation to the host processor, comprising the steps of first creating a data stream comprising the position, region, and window content, and comprising the identity of one of a plurality of remote terminal monitor screens (116, 215) for receiving said window in the host processor (400) second, transmitting the data stream from the host processor (400) to the workstation controller (30), and third identifying said one of a plurality of screens (116, 215) of the remote terminal monitor (10, 20) to receive a window and store pre-existing content a monitor screen (116, 215) of the monitor shown in one of the plurality of monitor screens (116, 215) at a remote terminal (10, 20) for receiving said window in the workstation controller (30), fourthly, constructing the window and its edges as an overlay on the pre-existing screen content (116, 215) of the monitor in the workstation controller (30); sending a constructed window overlay from the workstation controller (30) to one of the plurality of screens (116, 215) of the remote terminal monitor to receive said window and sixth displaying the overlay and pre-existing monitor screen content (116, 215) on said one of the plurality of screens (116, 215) of the remote monitor 27 61830 (2761830_upr2.doc) η *> 0 · Ί Ο 3 0 Ο Ο 0 0 9 9 0 ο 0 ο 0 ο 3.0 ο ο ο ο ο 0 3 9 Ο ~) 3. 90 0 Ο 9 0 η 9 0 0 ο ο ο ο ο ο 3 0 0 ο ο ο ο ο ο terminal to receive said window The method of claim 1, further comprising the steps of: generating a window removal command at a designated remote terminal (10, 20) destination in the host processor (400) sending a command from the host processor (400) to the workstation controller (30) to obtain pre-existing monitor screen content (116, 215) previously covered by the window , at the workstation controller (30), transmitting the acquired pre-existing screen content (116, 215) of the monitor from the workstation controller (30) to the designated remote terminal (10, 20) and displaying the acquired and transmitted pre-existing screen content (116, 215) a monitor at a designated remote terminal (10, 20). A method according to claim 1 or 2, characterized in that in. step three, the sub-step of storing the pre-existing monitor screen content (116, 215) of one of the plurality of monitor screens (116, 215) of the remote terminal monitor (10, 20) comprises storing the current cursor address for one of the plurality of monitor screens (116, 215) a remote terminal (10, 20); and calculating a screen area (116, 215) to be replaced by said window. The method of claim 3, wherein the fifth step further comprises the sub-step of limiting the range of allowable cursor addresses to the cursor addresses located in said window. (2761830_upr3.doc) β 9 ° -) «0 Λ Ο β Ο 0 5 0 5 5 Ο 5 ο σ ο ο ί> ο Ο - · Λ ο ο ο ο ο 5 5 Ο oo Ο Ο 5 5 5 Ο 4 0-5 0 Ο Ο 5 5 5 A device for assisting in generating and removing windows on a plurality of monitor screens (116, 215) of a remote terminal monitor (10, 20), each monitor screen (116, 215) having pre-existing window screen contents (116, 215) connected via a controller (30) for the host processor (400), comprising in the host processor (400) a monitor data manager (6) for generating a data stream including position, region, and window content and containing the identity of one of the plurality of screens (116, 215) a remote terminal monitor (10, 20) for receiving said window, a bus (401) for sending a data stream from the host processor to a controller (30) in the controller (30) software to identify one of a plurality of screens (116, 215) of the remote monitor a terminal (10, 20) for receiving said window and storing the pre-existing screen content (116, 215) of the monitor of one of the plurality of screens (116) A monitor of a remote terminal (10, 20) for receiving said window, in a controller (30) of software for constructing the window and its edges as an overlay on pre-existing monitor screen content (116, 215), data connection for transmitting the constructed window overlay from a controller (30) for one of the plurality of screens (116, 215) of the remote terminal monitor (10, 20) for receiving said window, and one of the plurality of screens (116, 215) of the remote terminal monitor (10, 20) for receiving said window, software for displaying overlay and pre-existing monitor screen content (116, 215). (2761830_upr3.doc) - 29 - O 0 0 3 O 3 r> 3 0 O 0 3 Od 3 0 0 O f> 3 O O 3 O 0 3 3 0 0 3333 33 333 333 03 / 3 O 3 0 0 3 O · 7 3 3 6. Equipment according to Claim 5 you signifying s e by the controller (30) further contains communication adapter (306) to connect with one or more dependent work stations (20). 7. Equipment according to Claim 5 characterized s e by the controller (30) further contains programmable working station (10). 8. Equipment according to Claim 5 confessing s e wherein the controller (30) further comprises a programmable workstation (10), and the at least one workstation controller (30) has a communication adapter (306) for connection to a plurality of non-programmable terminals.