WO1998014890A1

WO1998014890A1 - System and method for remote operation of mainframe console

Info

Publication number: WO1998014890A1
Application number: PCT/US1997/017480
Authority: WO
Inventors: Hayes J. Landry, Jr.; Jeffrey P. Scheetz; John D. Cole; Kevin M. Royce
Original assignee: Mci Communications Corporation
Priority date: 1996-09-30
Filing date: 1997-09-30
Publication date: 1998-04-09
Also published as: AU4656597A

Abstract

A system and method for remotely monitoring one or more computers (320, 322, 326, 328) from remote consoles (314, 316, 318). The system augments conventional remote accessing systems by automatically generating communication configuration parameter files, providing simultaneous remote control of multiple local terminals from remote terminals, and by providing enhanced failure notification.

Description

System and Method for Remote Operation of Mainframe Console

Background of the Invention

Field of the Invention

The present invention relates generally to mainframe computers and, more particularly, to remote operation of mainframe computers.

Related Art

Mainframe computers, such as the IBM S/370, are single hardware platform computers used for storing data and application software and, often, for executing the stored application software. Many businesses have one or more mainframe computers located at a data center, with multiple data centers located throughout the country.

Mainframe computers are often divided into distinct logical partitions

(LPARs). Each LPAR operates as a distinct, individual, mainframe computer. Each of these LPARs must be monitored for the performance of its hardware and its operating system. The operating system used by the IBM S/370 is known as

Multiple Virtual Storage (MVS).

In order to monitor individual LPARs, a workstation, which may be a personal computer (PC), is provided for use as a local console. The local console may be connected to the LPAR via coaxial cables. Typically, one or more consoles are provided for each LPAR. Each console includes necessary hardware and software for communicating, operating and monitoring the associated LPAR.

Where there are multiple LPARs, one operator may be required to monitor more than one display console. Where a business employs multiple mainframe computers located at various sites throughout the country, it is advantageous to consolidate operations and monitoring functions at one or more remote locations. Software products are currently available for providing remote operation and maintenance of computer systems. Typically, remote systems operate an LPAR through its local display console.

A product offered by Computer Associates of Islandia, New York, known as Outboard Control Facility (OCF), provides software which enables a standard PC to present hardware and software views of an LPAR on both a local console and a remote console. OCF includes two software components, one for the local console and one for the remote console. An Outboard Console Platform (OBCP) allows a PC to operate as a mainframe local console. A Remote Console Platform (RMCP) allows another PC to communicate with the OBCP on the local console, thus operating as a remote console. Under control of the OCF, the remote console and local console communicate as an integrated input/output platform. That is, each image sent to the local console by the LPAR is simultaneously picked up by the remote console and each command entered by a user at the remote console is automatically and simultaneously entered as input at the local console. Using OCF, an operator may monitor the hardware and operating system of an LPAR at a remote site. In operation, the remote console accesses a local console, emulates that local console, and allows the remote operator to perform as if the remote operator were sitting at the local console. Generally, a remote console connected to a WAN can access any local console connected to that WAN.

OCF is an alternative to typical LAN/WAN environment communications where one PC communicates with another by sending messages, which are then read and interpreted by the receiving PC. While conventional remote operating systems for mainframe computers permit consolidation of resources, they have a number of limitations. For instance, each time a remote console requests access to a local console, communications configuration parameters must be provided to the remote console. Communication configuration parameters may include NetBIOS identifiers and modem dial-up telephone numbers. Where backup communication paths are to be provided between a remote and a local console, additional communication configuration parameters must be provided for each back-up method of access. Where a number of mainframe computers are being monitored, each having a number of individual LPARs, the process of providing communication configuration parameters can become a time consuming and confusing procedure.

Another limitation of conventional remote communications systems is manual initiation of communications. Essentially, after providing communications configurations parameters, the operator at a remote console must still initiate or command the remote console to attempt to connect with a local console using the provided parameters. While this is generally a simple and straightforward procedure, where multiple mainframe computers are to be monitored, each having multiple LPARs, each additional command which must be performed adds undue time and expense to a business.

Yet another limitation of conventional remote operation systems is the inability to monitor multiple local consoles from a single remote console. Thus, if a remote operations center is to monitor twelve local consoles, then twelve remote consoles must be provided. In order to adequately monitor twelve or more remote consoles, more than one remote operator is typically necessary.

A further limitation of conventional remote operations systems is the lack of adequate alarm capabilities. Where, for instance, an operator is monitoring multiple remote consoles, a fault on one of those consoles may go undetected if the operator is concentrating on other consoles. Moreover, since the operator must select only one of several available monitoring modes, which is typically a choice between a hardware view, an operating system view or a communications view, and because faults are typically displayed only if they are related to the selected view, a fault may go unnoticed unless it occurs in the portion of the system actively being viewed. Furthermore, where an operator is monitoring multiple local consoles through multiple remote consoles and there is an interruption in communications between one of those remote consoles and its associated local console, the operator may not be adequately notified of such a loss in communications if the remote operator is not closely monitoring that particular remote console. In conventional remote operations systems, therefore, there are too many opportunities for faults to go unnoticed by the remote operator.

What is needed, therefore, is a remote mainframe monitoring system which automatically generates communication configuration parameter files for connecting a remote console to a local console. A remote monitoring system should be able to take those generated parameter files and automatically establish communications between the remote console and the local console and automatically initiate communications between those devices through backup methods, when necessary. A remote monitoring system should also permit multiple local consoles to be viewed simultaneously on a single remote console. Finally, a remote monitoring system should provide adequate alarm capabilities to inform a remote operator whenever there is a hardware fault or a communications fault, regardless of which local monitor display view is active. Such an alarm system should include audible alarms and graphic alarms in order to insure that a remote operator will be notified. Summary of the Invention

The present invention provides a system and method for remotely monitoring a plurality of mainframe computers and mainframe computer LPARs from a single remote console. The present invention automatically generates primary and back-up communication configuration parameters for establishing communications between a remote console and multiple local consoles. The present invention also generates audio and graphic alarms for any of a variety of system faults.

According to the present invention, conventional software designed for remotely monitoring a mainframe computer is augmented with a primary executable file, possibly an AUTOEXE.BAT executable file, for linking other executable files, each of which provides a particular function.

In a preferred embodiment, a first executable file called by the primary executable file automatically generates communication configuration parameter files based on operator selected access methods. These files are used for automatically accessing one or more mainframe computers or mainframe computer LPARs. A second executable file called by the primary executable file includes a remote console portion of the conventional remote system. This second executable file receives the communications configuration parameter file from the first executable file and automatically accesses selected mainframe computers or mainframe computer partitions. A third executable file called by the primary executable file provides audio and graphic alarms in the event that communications is lost between the remote and local consoles.

In the preferred embodiment, a screen scraping program is provided at local consoles for detecting LPAR hardware faults, regardless of the display mode selected at the associated local console. In the event that a hardware fault is detected by the screen scraping program, audio and graphic alarms are generated at the local console. These alarms are automatically reproduced at the remote console. Brief Description of the Figures

The present invention is described with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. Additionally, the left-most digit of a reference number identifies the drawing in which the reference number first appears.

FIG. 1 is a block diagram illustrating a typical hardware system architecture for monitoring mainframe computers via local consoles.

FIG. 2 is a block diagram illustrating a network architecture for remotely monitoring mainframe computers. FIG. 3 is a block diagram illustrating the use of LANs and a WAN for implementing the architecture of FIG. 2.

FIG. 4 is a block diagram illustrating the use of routers and bridges for implementing the architecture of FIG. 2.

FIG. 5 is a flowchart illustrating the process performed by a primary executable file.

FIG. 6 is a flowchart illustrating the configuration file building process performed by the PICKOBCP.EXE file in step 506 of FIG. 5.

FIG. 7 is a sample display provided to the operator in step 602 of FIG. 6.

FIG. 8 is a sample display presented to the operator in step 606 of FIG. 6. FIG. 9 is a typical communication configuration parameter file created in step 612 of FIG. 6.

FIG. 10 is a flowchart illustrating the process performed by the RMCP.EXE file in step 508 of FIG. 5.

FIG. 11 is a sample display of a remote console providing views for up to four local consoles.

FIG. 12 is a flowchart illustrating the process performed by the ATTN.EXE file in step 510 of FIG. 5.

FIG. 13 is a flowchart illustrating the screen scraping process performed at a local console. Detailed Description of the Preferred Embodiments

The present invention augments conventional remote operations systems by automatically generating communication configuration parameter files for use by a conventional remote operations system, by providing remote monitoring of multiple local consoles by a single remote console and by providing advanced monitoring and warning capabilities at remote consoles.

In operation, a remote operator at a remote console is provided with communication access options, including LAN (Token Ring and/or Ethernet), WAN and dial-up access options. In a preferred embodiment, the user is offered four token ring access options and two modem dial-up options for monitoring up to six local consoles on a single remote console. A simplified icon screen is provided to the remote operator for selection of access options. After selecting the methods of communication, the remote operator is prompted to select a local console for remote monitoring. After a remote operator selects a desired communication interface and a local console, a communication configuration parameter file is automatically generated for establishing communications between the remote console and the selected local console.

The communication configuration parameter file is provided to a conventional remote operations system which establishes communications between the remote console and the selected local console. In the event that the selected communication access option is unavailable, the remote operator may select an alternate communication route from one or more back-up access routes selections. In the preferred embodiment, the four backup routes are:

(i) virtual private network (VPN);

(ii) dial-1 with VPN access;

(iii) dial-1 with switched network access; and

(iv) dial-1 with specific interexchange carrier (IEC). At any time, the remote operator may open additional windows at the remote console for monitoring additional local consoles.

After communications is established between a remote console and one or more selected local consoles, the remote console simultaneously displays the selected local consoles. Thus, one remote operator can monitor multiple mainframes from a single remote console. In a preferred embodiment, a single remote console provides views of four local consoles, although any number of local consoles may be simultaneously displayed.

The present invention, thus, permits a remote operator to quickly establish communication with a plurality of local consoles without needing to know specific configuration parameters such as NetBIOS identifiers and network address of local consoles. This greatly increases productivity and efficiency of remote operations personnel, since a typical operator can effectively monitor up to three remote consoles, each with views of four or more local consoles. A single operator thus can effectively monitor at least 12 local consoles from just three remote consoles.

The present invention also provides a number of hardware, monitoring system and communication malfunction alarms. For example, a screen scraping program is provided to a local console for detecting hardware alarms messages from the associated LPAR. Upon detection of a fault, audio and graphic alarms are generated at the local console and, therefore, at the remote console as well. The screen scraping function detects these hardware faults regardless of the view currently monitored on the local or remote console.

The present invention also provides an alarm if communications are interrupted between a remote console and a local console. Thus, if a session terminates, regardless of the cause, a program is triggered which provides an audio alarm at the remote console. In a preferred embodiment, this function is provided by an executable program which executes upon detection of a loss in communication between a local console and a remote console. In a preferred embodiment, the alarm is both audio and graphical. Referring to FIG. 1 , a block diagram illustrates a system architecture for a mainframe computer system 110 which is monitored via local consoles. System 110 includes a mainframe computer 112 including first and second LPAR partition 114 and 116, respectively. First LPAR 114 is monitored at local console 118 while second LPAR 116 is monitored at local console 120. Local consoles

118 and 120 may each be a PC workstation specifically configured to operate as a mainframe computer local console. For added reliability, local console 120 acts as a backup local console for monitoring LPAR 114. Similarly, local console 118 acts as a backup local console for monitoring LPAR 116. Thus, if local console 118 or local console 120 become disabled or taken off-line for scheduled maintenance, the associated LPAR is not rendered inoperable or non-monitorable.

Mainframe LPAR 114 includes a hardware console view interface device

122 for providing a hardware console view to local console 118 via line 126.

Although not shown, I/O device 122 could provide the hardware console view to back-up local console 120, as well. The hardware console view permits an operator at local console 118 to monitor the hardware of LPAR 114.

Mainframe LPAR 114 also includes an Establishment Controller 124 for providing a Master Console View (MVS) to local console 118 over line 128 and for providing an MVS Virtual Telecommunications Access Method (MVS VTAM) console view to local console 118 over line 130. The MVS master console view permits an operator to monitor the overall performance of the LPAR 114 operating system. The MVS VTAM console view provides an operator with communications performance data of LPAR 114. Establishment controller 124 also provides the MVS console view from LPAR 114 to backup console 120 over line 132.

Local console 120 receives MVS VTAM console views, MVS master console views, and hardware console views from LPAR 116, in a manner similar to that described above. Referring to FIG. 2, a high-level block diagram illustrates a network architecture 210 for remotely monitoring multiple LPAR data centers. This may be accomplished with a product offered by Computer Associates of Islandia, New

York, known as Outboard Control Facility (OCF), although any product having the features described herein could be used.

Using OCF, an operator can monitor the hardware and operating system of an LPAR at a remote site. Under control of OCF, the remote console accesses a local console, emulates that local console, and allows the remote operator to monitor and control an associated LPAR as if the remote operator was sitting at the local console.

OCF provides the software needed for a standard PC to present hardware and MVS console views on both a local console and a remote console. OCF includes two software components, one for the local console and one for the remote console. The local console portion, called an outboard console platform (OBCP), allows a PC to operate as a mainframe local console. The remote console portion, called a remote console platform (RMCP), allows a PC to communicate with the OBCP on the local console, thus operating as a remote console. The terms "local console" and "remote console" are used throughout this disclosure to refer to workstations running OBCP and RMCP. Although OCF is the software employed in a preferred embodiment, the present invention may be employed with any similar system which permits a remote console to operate as an integrated I/O platform with a local console whereby any image sent to a local console by an LPAR is simultaneously displayed on a remote console and each command entered by a user at the remote console is automatically and simultaneously entered as input at the local console.

Referring to architecture 210, a primary remote operation center 212 is linked to a secondary remote operation center 214 via two dedicated Tl communications links. The Tl communications links include a primary link 216 and a secondary or backup link 218. Links 216 and 218 use diverse transmission routes for network reliability. Four LPAR data centers 220, 222, 224 and 226, are shown for illustrative purposes. In a preferred embodiment, however, more than four LPAR data centers may be employed.

Each LPAR data center 220-226 is connected to each remote operation center 212 and 214, preferably via a dedicated Tl communications links. Line

228, for example, represents a Tl communications link between remote operations center 212 and LPAR data center 220.

LPAR data center 220 is also connected to secondary, or backup, remote operation center 214, preferably via a dedicated Tl communications links. Line 230 represents a communications link between LPAR data center 220 and secondary remote operations center 214. In the event that communications is disrupted over line 228, remote operation center 212 may still maintain communication with LPAR 220 through line 230 and one or both of lines 216 and 218. In the event that remote operation center 212 itself fails, LPAR data center 220 may be monitored by remote operations center 214 through line 230 or through line 228 and one or both of lines 216 and 218.

Additional backup remote operation centers (not shown) and communication links (not shown) may be employed as well.

Similarly, LPAR data center 222 is coupled to remote operations center 212 via line 232 and to remote operations center 214 via line 234. LPAR data center 224 is coupled to remote operations center 212 via line 236 and to remote operations center 214 via line 238. LPAR 226 is coupled to remote operations centers 212 and 214 in a similar manner.

FIGS. 3 and 4 provide more detailed illustrations of the network architecture employed for network 210. Referring to FIG. 3, architecture is provided to illustrate the use of LANs, a WANs and a public switched telephone network (PSTN) for implementing the architecture of FIG. 2. A portion of system 210 includes LPAR data centers 220 and 222 and primary remote operation center 212. LPAR data center 220 includes a local area network (LAN) 318, which may be a token ring network, coupled to local display consoles 320 and 322.

LAN 318 may include two LPARs (not shown) of a mainframe whose operation will be controlled and monitored on local consoles 320 and 322. Local console 320 could monitor one LPAR and console 322 could monitor the other LPAR.

LPAR data center 222 is similar to LPAR data center 220 and includes a local-area network (LAN) 324 which may include one or more logical partitions of a mainframe computer. Local consoles 326 and 328 monitor the operations of LPARs (not shown) within data center 222. For example, local console 326 may monitor one LPAR while console 328 monitors a second LPAR. Alternatively, console 326 may operate as a primary console to an LPAR while console 328 operates as a back-up console to that LPAR.

Primary remote operation center 212 includes a LAN 312, which may be a token ring LAN. LAN 312 is coupled to three remote consoles 314, 316 and 318 for remotely monitoring LPARs at data centers 220 and 222.

In a preferred embodiment, remote consoles 314, 316 and 318 can each remotely operate and monitor a plurality of LPARs. Remote console 314, for example, could monitor and operate LPARs at data centers 220 and 222.

Consoles 316 and 318 could monitor other LPAR data centers (not shown) or could be employed as back-up spare consoles for console 314.

Where LANs 312, 318 and 324 are located in the same building, the LANs could be interconnected with network routing devices. Where LANs 312, 318 and 324 are not located in the immediate vicinity of one another, however, the LANs should be coupled through a wide area network. In FIG. 3, such a wide area network 330 is provided for coupling primary communications links 228 and

232 to remote operation center 212 through communication link 334.

For added reliability, remote operation center 212 and LPAR data centers

220 and 222 may also communicate through a public switched telephone network

(PSTN) 332. Typically, connections between PSTN 332 and the remote operation center 212, and between PSTN 332 and LPAR data centers 220 and 222 are provided through modem connections. If any of the LANs 312, 318 or 324, or any of the communications links therebetween fail, the modem links between the local consoles and the remote consoles, through the PSTN, provide an adequate substitute communications link. As will be explained with reference to FIGS. 6 and 7, a number of particular remote access methods via the PSTN are available.

Each remote console 314, 316 and 318 may access one or more of local consoles 320, 322, 326 and 328. Moreover, each remote console 314, 316 and 318, may access multiple local consoles and, preferably using IBM's OS/2 as the operating system on the remote console, simultaneously display the images appearing on those local consoles. This allows a single operator at remote operation center 212 to perform mainframe LPAR operations on any LPAR in the network, as well as on multiple LPARs in the network. Thus, the productivity of individual operators is greatly increased. Referring to FIG. 4, a detailed network architecture is provided to illustrate the use of routers and bridges in system 210.

LPAR data center 220 includes four individual LANs, shown here as token ring LANs 412, 414, 416 and 418. These token ring LANs communicate through bridges 420, 422 and 424. A bridge is a device for connecting two similar networks at a data link layer of the LAN's architecture.

Token ring LAN 412, 416 and 418 may include one or more individual LPARs, each LPAR having at least one local console.

LPAR data center 220 includes primary and secondary routers 426 and 428, respectively, for transmitting and receiving information over primary and secondary Tl communications links 228 and 230, respectively. Recall that LPAR data center 220 is connected to primary remote operation center 212 through a primary Tl connection 228 and to backup remote operation center 214 by a Tl communications link 230. Remote operation center 212 includes a local area network, shown here as a token ring local area network 430 which includes one or more remote consoles (not shown).

Remote operation center 212 also includes routers 432 and 434 for communicating to the various LPAR sites. Remote operation center 212 may employ any number of routers, depending upon the number of LPAR data centers and the number of transmit and receive ports on each router.

In order for remote operation center 212 and 214 to connect with any of LPAR data centers 220, 222 or 224, the remote operations centers must have access to various communication configuration parameters for each desired

LPAR data center. In the case of a LAN system, communication configuration parameters include NetBIOS identifiers.

Briefly, each local console and remote console has an individual NetBIOS identifier. In order for a remote site to access a local console, the remote site must have the NetBIOS identifier of the local console. Each bridge and router includes a table of authorized NetBIOS identifiers. When a NetBIOS identifier is received by a bridge or router, this table is queried. If the NetBIOS identifier is authorized, communications is permitted. These bridges and routers thus server as an additional level of security to the system. By preventing unauthorized users from accessing the system, these bridges and routers also serve to reduce unnecessary traffic through the system. This increases accessibility to authorized users and, therefore, reduces the need for authorized users to access the system through indirect routes. In other words, by limiting access to authorized users only, excessive hops (i.e., hopping from route to route in an attempt to access the system) by authorized users are reduced.

Conventional remote operations systems require an operator at a remote operation center to supply communication configuration parameters for each

LPAR to be accessed. For example, suppose each token ring LAN 412, 414, 416 and 418 at LPAR center 220 each include an LPAR, each LPAR having an associated local console. If an operator at remote operation center 212 desires to monitor the local consoles associated with the LPARs, the operator must supply communication configuration parameters for each of the local consoles. In the event that a selected communications path or a selected local console is unavailable, the remote operator must also supply backup communication configuration parameters. As a result, remote operators spend considerable of time just preparing to establish communications with the various local consoles. Recall from FIG. 1 that a local console may view any one of three separate console views. These views included a hardware console view, an MVS master console view, and an MVS VTAM console view. In conventional systems, however, if a local console is displaying an MVS master console view, for instance, and if the associated LPAR suffers a hardware fault, the local console would not display that fault because it was not displaying the hardware console view. In addition, because a remote console displays precisely what is displayed at local console, the remote console will also not disclose the existence of a hardware fault on the LPAR.

The present invention provides a system and process which eliminate the drawbacks of conventional systems. Essentially, the present invention provides a primary executable file at a remote center for linking an automatic communication configuration parameter file generating program and an alarm generating program to a conventional remote console platform program resident on a remote operation center PC. The present invention also provides for monitoring multiple local consoles from a single remote console and provides integrated alarm capabilities.

Briefly, a primary executable file initiates a communications configuration parameter-building program which generates communication parameters for establishing communications links between a remote console and one or more local consoles. In the event that a selected access method is unavailable, upon prompting by the user, the communications configuration parameter generating file may also generate backup communications parameters. Upon generation of the necessary parameters, the communications configuration parameter-building program terminates and control is passed back to the primary executable file. The primary executable file then initiates execution of a conventional remote console platform program resident on the remote PC. The resident remote console platform receives the communication configuration parameters generated above and establishes communications with selected local consoles in accordance with those parameters.

In the event that communications is lost between the remote console and one or more local consoles, the remote console platform program terminates and control is returned to the primary executable file. The primary executable file then initiates execution of an alarm-generating program for automatically generating audio and graphic alarms at the remote console.

In addition, local consoles are provided with code for periodically screen- scraping the local console, preferably at least once every 60 seconds, to determine whether a hardware fault exists in the LPAR. If a fault is detected, audio and graphic alarms are generated at the local console. These alarms are generated regardless of the view currently displayed at the local console. Because the remote console emulates the local console, any hardware fault thus displayed at the local console as a result of the screen-scraping is automatically displayed at the remote console. This ensures that no matter which view is currently being monitored, the remote operator will be immediately notified in the event that a fault is detected at an LPAR.

Referring to FIG.5, a primary executable program 504 is provided for controlling execution of a communications configuration parameter-building program, a conventional remote console platform program and an alarm- generating program. In operation, the process is initiated in step 502, where a remote operator initiates execution of a primary executable program 504 on a remote console, such as remote console 314. In a preferred embodiment, primary executable program 504 is an AUTOEXE.BAT program but could be any other type of software program having instructions executed by a computer.

In step 506, a program is executed which prompts a remote operator to select a primary communications link and a local console. For instance, in FIGS. 2-4, the remote operator at remote console 314 may be prompted to first select a LAN/WAN communication link or a PSTN communication link. The remote operator is then prompted to select a local console, which may include local consoles 320, 322, 326 and 328.

The program then retrieves communication configuration parameters from one or more databases. These parameters are used to generate communication configuration parameter files, after which, the program terminates and control is passed back to primary executable program 504.

Step 506 preferably includes a PICKOBCP.EXE file which prompts the remote operator to select communications options and local consoles for accessing. The preferred PICKOBCP.EXE also queries one or more databases for communication configuration parameters and generates communication configuration parameter files for those selections.

In step 508, primary executable program 504 triggers execution of a conventional remote operations program. Such a conventional remote operations programs should permit a remote console to emulate a local console so that the remote console display is identical to the local console display and so that any input to the remote console is automatically input to the local console. Although the conventional remote operations program is shown here as an RMCP.EXE file provided by the OCF product of Computer Associates, any other suitable remote operation system could be employed. In step 508, the conventional remote operations program receives the communication configuration parameter files generated by the PICKOBCP.EXE file in step 506 for a selected communication access option and a selected local console. The conventional remote operations program then initiates communications between the remote console and the selected local console through the selected communication access option.

Remote operations systems are typically configured to display only a single local console on any given remote console. Thus, in order to display several local consoles at a remote site, a separate remote console having its own remote operations system is required for monitoring each local console.

In the present invention, multiple copies of a remote operations program are resident at a single remote console, such as remote console 314. A typical remote console includes a PC and a display. The remote console operates under the control of a multi-tasking operating system such as IBM's OS/2 which permits the remote console to operate the multiple copies of the conventional remote monitoring systems simultaneously. Under control of a multi-tasking operating system, therefore, a single remote console can display and emulate a plurality of local consoles simultaneously.

A remote operator may select additional communications paths and local console for remote operation as indicated by the branch 512. When a remote operator wishes to select an additional local console to access, a primary executable program is executed. For each execution of a primary executable program, new communication configuration parameter files are generated and a new RMCP.EXE file is executed. Thus, although unnoticeable by the remote operator, each local console is remotely accessed by a separate copy of a remote operations program.

The PICKOBCP.EXE file of step 506 can also be employed with remote operations software developed for remotely accessing multiple local consoles from a single remote console. The primary point of step 506 is the automatic generation of communication configuration parameter files. Under normal operating conditions, the RMCP.EXE file of step 508 runs continuously in order to permit an operator to monitor a local console. A

RMCP.EXE file terminates only if the operator intentionally discontinues remote operations to the associated local console or if a problem occurs at the local console, at the remote console or in the communications path therebetween.

If such a problem develops which interrupts communications between a remote console and a local console, it is imperative that the remote operator be notified immediately. Where the remote operator is monitoring only a single local console, a loss of communications between the remote console and the local console should be, although not necessary is, immediately obvious. Where, however, the remote operator is monitoring more than one local console, a loss of communications between the remote console and any local console may not be immediately obvious to the remote operator.

In step 510, a module is included for immediately notifying a remote operator in the event that communications is lost between the remote console and a local console. Here, the module is shown as ATTN.EXE program. Briefly, upon termination of a RMCP.EXE file, control is passed back to the primary executable file 504. Primary executable file 504 then executes the ATTN.EXE program which automatically generates an audio alarm and a possibly a graphic alarm at the remote terminal. This ensures that even if a remote operator is monitoring several remote consoles at a time, and even if each console displays views of multiple local consoles, the operator will, nevertheless, be notified whenever communications is lost between the remote console and any local console. In addition to the executable files described above, another aspect of the present invention is a screen scraping program running in the background of a local console for providing hardware alarm message detection. Recall from the discussion of FIG. 1 that a local console may display any one of three different LPAR-related displays. Typically, where the local console is displaying one of the three possible screens, a failure which normally would be displayed on one of the two undisplayed screens would not be displayed on the local console. Because the remote console typically emulates the local console, a fault occurring in the associated LPAR which is not be displayed on the local console will also not be displayed at the remote console. The new program screen-scrapes the local console periodically, which in the preferred embodiment is approximately every

60 seconds, to detect undisplayed LPAR hardware alarm messages.

In a preferred embodiment, a conventional outboard console platform program resident in the local console is modified to provide the screen-scraping function. Typically, LPAR hardware faults are continuously provided to a local console over line 126, which carries the hardware console view. The screen scraping function queries the port which receives line 126 or an internal I/O device which receives the data from line 126. If the screen-scraping function detects an LPAR hardware fault, an audio and graphic alarm is immediately generated at the local console. Since the remote console emulates the local console, the audio and graphic alarm at the local console will automatically be picked up and presented at the remote console.

The graphic alarm is automatically displayed in the RMCP at the remote console. Thus, regardless of the LPAR view being displayed at the local and remote consoles, hardware faults will not go undetected by the remote operator. Referring to FIG. 6, a flowchart is provided for illustrating the process performed in step 506. Again, in a preferred embodiment, the process of step 506 is performed by a computer program at the remote console, shown here as executable file PICKOBCP.EXE.

In step 602, a remote operator is presented with a menu of access options for accessing local consoles. These access options are typically presented as individual icons. These icons represent modes or methods of accessing local sites and may include local area network access such as token ring and Ethernet LANs, wide area network access, and modem dial-up access. Although the specific type and number of LAN, WAN and dial-up access may vary with embodiment, a preferred embodiment includes four token ring LAN access methods and two modem dial-up access methods. This provides the remote operator with access to up to four LPAR local consoles via token-ring connection and up to two LPAR local consoles via dial-up modem connection. This permits remote operation of up to six LPARs from a single remote console. Typically the remote console displays all active local consoles simultaneously using a multi-tasking operating system such as IBM's OS/2. Although many more sessions could be established and controlled from a single local console, access to only six LPARs is provided to ensure that a remote operator has a sufficient view of each local console displayed at the remote console. Referring to FIG. 7, a sample display 710 is provided for illustrating the access option display of step 602. Icons 712-722 represent the six access options provided in a preferred embodiment. Icons 712-718, represent four possible LAN access sessions while icons 720 and 722 represent two possible modem dial-up access methods. Referring back to FIG. 6, in step 604, a remote operator selects one of the available access options presented in step 602.

In step 606, the remote operator is presented with a menu or a list of LPARs which may be accessed. Each LPAR has at least one associated local console. Referring to FIG. 8, a preferred embodiment of the display of step 606 is provided. Three columns 812, 814 and 816 provide a list of available LPARs. Each available LPAR is identified by a local console identifier and an LPAR identifier. For example, in the second row of column 812, an LPAR is identified by its local console RACOB51 and by its LPAR identifier SAC1. Thus, if in step 604 a remote operator at remote console 314 selected LAN icon 712, the remote operator would be presented with a list of local consoles available through a LAN. In FIG. 3 this would include local consoles 320 and 322 available through LAN 318, WAN 330 and LAN 312. This would also include local consoles 326 and 328 available through LAN 324, WAN 330 and LAN 312. Referring back to FIG. 6, in step 608, the remote operator selects an LPAR from the display provided in step 606.

In step 610, one or more communications configuration databases are accessed by the PICKOBCP.EXE file. The configuration databases contain communication configuration parameters for the RMCP.EXE file to access the selected local console associated with the selected LPAR. The configuration database may include NetBIOS identifiers (for LAN access) and phone numbers (for modem dial-up access). The configuration database may also contain communication configuration parameters for backup communication access for accessing the selected remote console in the event that a selected primary access route is unavailable.

In step 612, PICKOBCP.EXE builds a communication configuration parameter file using the data retrieved in step 610. A typical file is provided in

FIG. 9. PICKOBCP.EXE may also generate communication configuration parameter files for back-up communication access to selected local consoles in the event that a selected access option is unavailable.

After a communication parameter file is created, PICKOBCP.EXE terminates, passing control back to the primary executable file 504.

In the event that a selected access method is unavailable, the RMCP.EXE file terminates. The remote operator may then go back to step 502 and initiate generation of a new communication configuration parameter file using a back-up access method.

In a preferred embodiment, up to four back-up modem dial-up access methods are provided. Generally, the four dial-up access methods employ the PSTN network 332 shown in FIG. 3. The differences between the various dial-up methods is in their billing methods. Generally, the least expensive PSTN access method is the first choice for backup while the most expensive PSTN access method is the choice of last resort. The four PSTN access methods are listed in the preferred sequence of accessing. A virtual private network (VPN) access method uses a company's internal virtual private network to provide remote connectivity all the way to the local console. Although a VPN will still use the PSTN, a VPN access method is the most efficient method of dial-up access because VPN plans typically include reduced access rates to the PSTN.

A dial-1 with VPN access method uses a company's virtual private network to access a PSTN using standard dial-1 calls. In operation, from a company's premises, such as the remote operations center shown in FIGS. 2-4, a dial-1 call is placed using a VPN prefix so as to utilize whatever VPN access facilities are available. Access facilities may be dedicated or switched trunks to the PSTN. On the PSTN, the interexchange carrier to which the company's premises are "pic'd" provides the long distance transport. The term "pic" refers to the process in telecommunications of a local exchange carrier assigning an interexchange carrier to an ANI. The third alternate method of modem dial-up access is a dial-1 with switched network access. This method also uses the PSTN shared network to access the local console. Here, however, the PSTN is accessed immediately from the company's premises. A dial-1 call is placed using a line-out prefix. The local exchange carrier accesses an interexchange carrier. This is essentially a conventional or typical dial-1 call.

The fourth modem dial-up method is a "lOxxx" access method. This access method consists of a dial-1 call which accesses a specific interexchange carrier (IEC), other than the interexchange carrier to which the company is "pic'd". Because primary IECs are usually chosen for their cost effectiveness, non-primary IECs are generally more expensive than the primary IEC.

Regardless of the backup communications methods employed, step 612 generates the necessary communications configuration parameters for accessing a local console from a remote console. In a preferred embodiment, remote consoles run under multi-tasking operating systems, preferably OS/2 workstations, so that a separate window is provided for each monitoring session. A session is defined as a communication link between a remote console and a local console. Each new window opened in step 602 indicates a separate session.

Since the OS/2 operating system permits multiple windows to be opened by step 602, execution of multiple copies of RMCP.EXE may be triggered by one or more primary executable programs 504. In a preferred embodiment, at least two access sessions may be executed simultaneously. Referring to FIG. 10, a flowchart is provided illustrating the process performed in step 508. Preferably, step 508 is performed by Computer Associate's RMCP.EXE program operating on a remote console such as remote console 314.

In step 1002, communication is established between a remote console and a selected local console. Step 1002 thus includes receiving communication configuration parameter files created in step 612, including parameters such as a NetBIOS identifiers for local consoles for LAN connections to those local consoles or telephone numbers for dial-up modem access. Recall that in conventional systems, the remote operator is prompted to manually supply these parameters. Here, however, the file generated in step 612 replaces the need for remote operator involvement. Step 1002 also includes automatic initiation of communications using the parameters contained in the communication configuration parameter files.

If the selected access method is through a LAN, as shown in FIGS. 3 and 4, the NetBIOS identifier of a local console is used to access that local console.

The bridges and routers that connect the data center LANs with the remote operations center LANs are configured to pass through only authorized NetBIOS identifiers. If, for any reason, the selected access method is unavailable, step 1002 may access the selected local console through a back-up communication means. For example, suppose that a remote operator at remote console 314 selected to access local console 322 through LAN 318, WAN 330 and LAN 312. If for some reason this access route was unavailable, the remote operator may attempt to establish communication between remote console 314 and local console 322 through PSTN 332. Recall that in a preferred embodiment four different PSTN access methods are sequentially attempted.

In step 1004, the accessed local console provides a sign-on procedure to the remote console. Typically, this includes solicitation of a password.

In step 1006, the remote operator provides identification to the local console, including a password.

In step 1008, if the local console accepts the identification information provided by the remote operator, the remote console is logged onto the LPAR associated with the local console. The remote console thereafter emulates the local console.

At this point, the remote operator is able to monitor the selected LPAR as if the remote operator were present at the local console of that LPAR. Thus, as described in reference to FIG. 1, the remote operator may select to view a hardware console view, an MVS master console view or an MVS VTAM console view of the selected LPAR. Moreover, at any time, the remote operator may choose to monitor additional LPARs with an appropriate request.

Referring to FIG. 11 , a remote console display 1110 includes windows

1112 and 1114 for monitoring two separate local consoles. Windows 1112 and 11 14 provide views of actual sessions with LPAR local consoles. Bottom windows 1116 and 1118 are generated by an IBM mainframe terminal emulation program for monitoring two additional sessions of any type. In the event that one or more of the RMCP programs of step 508 terminate, whether due to a deliberate operator disconnect or due to a communications or some other failure, AUTOEXEC.BAT file 504 executes the ATTN.EXE file of step 510. Referring to FIG. 12, a flow chart is provided to illustrate the steps performed in step 510. Preferably, step 510 is performed by a computer program, shown here as ATTN.EXE, resident at the local console. Recall that, in the event that the RMCP.EXE program of step 508 terminates, control is returned to primary executable file 504 which then initiates step 510. In step 1202, the ATTN.EXE file generates audio and graphic alarms.

The graphic alarm may include a full-screen display indicating a fault, or may be displayed in just a portion of the display screen so that the remaining local consoles may continue to be displayed.

In step 1204, the remote operator is prompted to "press any key to terminate the alarm."

In step 1206, a decision is made as to whether a key on the remote console keyboard has been pressed. Until a key is pressed on a console keyboard, the alarms continue and the console continues to prompt for an operator to "press any key to terminate the alarm." This ensures that the alarms continue until an operator acknowledges their existence. If it is determined that a key has been pressed, the alarms are terminated in step 1208.

In step 1210, ATTN.EXE is exited and the console display returns to its prior state, displaying any remaining active RMCP.EXE files. The console display may also provide details of the RMCP.EXE file which was terminated and the associated local console. The remote console display may also display some level of detail regarding the failure encountered.

Referring to FIG. 13, a flow chart illustrates the screen scraping function performed at a local console, such as local consoles 320, 322, 326 and 328. A computer program, such as Computer Associate's OBPC program, runs on a PC to enable the PC to function as a local console. In a preferred embodiment, steps 1302-1308, represent a modification to the OBPC program, although steps 1302-1308 could also be performed by an entirely separate computer program.

In step 1302, the LPAR associated with the local console is interrogated for hardware faults. This interrogation may simply be a query to a port of the local console which receives line 126 from LPAR 114.

In step 1304, a decision is made regarding whether any faults were detected by the interrogation of step 1302. If no faults are detected in step 1304, the screen scraping operation terminates in step 1308 and control passes back to the OBPC program. At some later point in time, preferably about 60 seconds, step 1302 is repeated.

In step 1306, upon detection of a hardware fault in step 1304, audio and graphic alarms are generated at the local console. The alarms are generated regardless of the console view currently displayed at the local console. Because the remote console emulates the local console, the audio and graphic alarms provided to the local console in step 1306 are automatically displayed at the remote console. Any hardware faults detected in step 1304 and displayed at the local console in step 1306 are, therefore, automatically provided to a remote operator through the remote console.

Control is then passed back to step 1302 so that the screen scraping interrogation function is performed repeatedly until step 1304 determines that the detected fault has been cleared. Through the screen-scraping process of FIG. 13, therefore, a remote operator is notified of any hardware faults existing on a monitored LPAR, regardless of which LPAR view is currently displayed at the remote or local consoles. While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

What Is Claimed Is:

1. A system for remotely monitoring at least one local console from a remote console, comprising: means for prompting a user at the remote console to select one or more local consoles for remote monitoring; and means for generating communication configuration parameter files for use by at least one remote monitoring module to establish communications between the remote console and the selected local consoles.

2. The system of claim 1, wherein one of the local consoles is coupled to a mainframe computer for monitoring the mainframe computer and wherein the local console can display a plurality of views associated with the mainframe computer, the system further comprising: means for detecting hardware faults in the mainframe computer regardless of the view that is displayed at the local console; and an alarm at the remote console that alarms upon detection of a hardware fault in the mainframe computer regardless of the view that is displayed at the local console.

3. The system of claim 1, further comprising: means for simultaneously monitoring a plurality of local consoles at the remote console; means for detecting a loss of communication between the remote console and a local console; and an alarm that alarms upon detection of a loss of communication between the remote console and a local console.

4. The system of claim 1 , wherein said means for generating communication configuration parameter files includes means for generating communication configuration parameter files for at least one of the following communications devices: (1) local area networks;

(2) wide area networks; and

(3) public service telecommunications networks.

5. The system of claim 1, further comprising: a database of communication configuration parameters for generating the communication configuration parameter files.

6. The system of claim 2, wherein said means for detecting hardware faults in the mainframe computer regardless of the view that is displayed at the local console comprises: a screen scraper that polls one or more output ports of the mainframe computer for hardware faults and that reports detected faults to the local console regardless of the view that is displayed at the local console.

7. The system of claim 3, wherein a plurality of remote monitoring modules are resident on the remote console for remotely monitoring a plurality of local consoles and wherein: said means for generating communications parameter files includes means for generating communications parameter files for a plurality of LAN connections and a plurality of modem dial-up connections; and said means for simultaneously monitoring a plurality of local consoles at the remote console includes means for simultaneously monitoring a plurality of local consoles through the plurality of LAN connections and the plurality of modem dial-up connections.

8. The system of claim 1 , wherein said means for generating communication configuration parameter files comprises: means for generating back-up communication configuration parameter files that permit the at least one remote monitoring module to establish communications between the remote console and a local console through a back-up communication path.

9. The system of claim 8, further comprising: means for sequentially attempting to establish communications through a plurality of back-up communication paths, including at least one of the following paths:

(1) a virtual private network (VPN);

(2) a dial-1 with VPN; (3) a dial-1 with switched network; and

(4) a dial-1 with specific interexchange carrier.

10. The system of claim 6, wherein said alarm generates an audible alarm and a graphic alarm when the screen scraper reports a fault to a local console.

11. An method for remotely monitoring at least one local console from a remote console , comprising the steps of:

(1) generating communication configuration parameter files for establishing communications between the remote console and the selected local consoles;

(2) establishing communication links between the remote console and the selected local consoles using the communication configuration parameter files; and (3) remotely emulating and monitoring the selected local consoles simultaneously at the remote console.

12. The method of claim 11, wherein one of the local consoles is coupled to a mainframe computer for monitoring the mainframe computer and wherein the local console can display a plurality of views associated with the mainframe computer, further comprising the steps of:

(4) detecting hardware faults in the mainframe computer regardless of the view that is displayed at the local console; and

(5) generating an alarm when a hardware fault is detected.

13. The method of claim 11 , wherein step ( 1 ) includes the steps of:

(a) providing a selection of communication access methods at the remote console;

(b) providing a selection of local consoles at the remote console;

(c) accessing a database and retrieving communication configuration parameters for communication access methods selected by a user.

14. The method of claim 13, wherein step (2) includes the steps of:

(a) attempting to establish communications between the remote console and the selected local consoles through the selected communication access methods; and

(b) sequentially attempting to establish communications through one or more back-up communication access methods if a selected access method is unavailable.

15. The method of claim 11 , wherein step ( 1 ) comprises the steps of: (a) opening a window on the remote console;

(b) presenting communication access options in the window; (c) presenting a selection of available local consoles in the window;

(d) retrieving communication configuration parameters for a selected communication access option and a selected local console from a communication configuration parameter database; (e) generating a communication configuration parameter file from said communication configuration parameters;

(f) triggering execution of a remote monitoring module;

(g) providing the communication configuration parameter file to the remote monitoring module; (h) establishing communications between the remote console and the selected local console through the selected communication access option; and (i) monitoring the selected console in said window.

16. The method of claim 15, wherein step (1) further comprises the steps of: (i) repeating steps (a) - (h) for simultaneously monitoring additional selected local consoles in additional windows of the remote console.

17. The method of claim 16, further comprising the steps of:

(5) generating an alarm in the event that a communications link is lost between the remote console and a selected local console.

18. A computer program product for permitting a computer system to remotely monitor at least one local console at a remote console, said computer program product comprising: a computer usable media having computer readable program code means embodied in said medium for causing a computer program to execute on the computer system, said computer readable program code means comprising: a computer readable first program code means for enabling the computer system to generate communication configuration parameter files for establishing communications between the remote console and the at least one local console; a computer readable second program code means for enabling the computer system to establish communication links between the remote console and the at least one local console using the communication configuration parameter files; and a computer readable third program code means for enabling the computer system to display and emulate a plurality of local consoles simultaneously at the remote console.

19. The computer program product of claim 18, wherein said computer readable program code means further comprises: a computer readable fourth program code means for enabling the computer system to generate an alarm when one or more of the communication links is disrupted.

20. A computer program product for permitting a computer system to remotely monitor at least one local console at a remote console, said computer program product comprising: a computer usable media having computer readable program code means embodied in said medium for causing a computer program to execute on the computer system, said computer readable program code means comprising: a computer readable first program code means for enabling the computer system to screen scrape a local console to detect hardware faults in a mainframe computer that is being monitored by the local console; and a computer readable second program code means for enabling the computer system to generate one or more alarms at the local console when a hardware fault is detected in the mainframe computer, regardless of a currently selected display mode on the local console.