Abstract:
A system and method for logical console verification and fallback. Conformity of physical equipment configurations with the logical console control and fallback plan is verified by sending messages through the backup paths and testing message response. The method of resource server or logical console fallback to a backup resource server or logical console includes the steps of verifying operational status of each physical component defined by the logical configuration description to assure availability. Tests can be manually or automatically generated. If all tests are completed successfully, resource server or console fallback is initiated.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of application Ser. No. 08/246,380, filed May 20, 1994 now abandoned, which is a continuation of application Ser. No. 07/922,907, filed Jul. 31, 1992, now abandoned. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to information processing systems and particularly to the management of distributed computer systems. In particular, the present invention relates to the management of failure recovery in distributed systems which provide remote operation facilities for computer hardware resources. 
     2. Background and Prior Art 
     The increasing power and complexity of large computer systems, frequently termed &#34;mainframe computer systems&#34;, has resuited in an increase in the complexity of computer system operations. The drive for increased workforce productivity, however, has tended to reduce the number of personnel assigned to the operations task. The proliferation of large computer system complexes, such as those used by airline reservations systems, banking centers, and similar computer intensive businesses, has also contributed to the need for more effective facilities for the control of hardware systems resources. 
     Large computer systems have traditionally been operated from an attached console accessible to the computer operators in a computer room. Each computer system has a dedicated console. Thus, in a large compIex of, for example, six computers, six operator consoles require monitoring. Each of these computer consoles displays messages in the order generated by the computer system. Many of the messages are informationaI, indicating the status of certain operations on the computer systems. Other messages provide warnings of current or impending problems. Finally, a third class of message requires operator response to a request for action, such as mounting a tape, or to correct an error detected in the system. It becomes increasingly difficult for an operator to monitor several consoles with several different types of messages and be able to effectively respond to each one. 
     One solution to the increasing flow of messages is to develop an automated operations facility that is able to interpret and classify messages. These types of facilities can be constructed to segregate messages by message type and to present the operator with those requiring attention. Automated operations facilities of this type are typically constructed using a workstation computer that can be connected directly to the large computer system. The workstation computer contains the necessary programs for receiving, analyzing, and responding to certain messages. 
     Productivity gains are frequently achieved by centralizing operator resources in a single operations area. This area may be on a different floor or in a different building than the large computers themselves. Centralization requires that remote access and control of the hardware resource be provided. However, remote access creates a series of problems. 
     The first problem is the need to develop a system which will allow access to the hardware resource independent of the location of that resource. Next, the system must be designed in a way that allows recovery from the failure of any component in the control system. In other words, control system component failure must not cause the failure of control of the larger system. 
     The problem of remote operations and management has been addressed in several ways. In U.S. patent application No. 07/577,967, filed Sep. 4, 1990, commonly assigned, an automated operations system is described which involves a controller coupled to the processor with remote workstation access for controlling that processor. This configuration provides control but limits remote access and fails to address the problem of control system redundancy and reconfiguration. 
     U.S. Pat. No. 5,005,122 suggests the use of a client server model for network management tasks. This system provides for management of a local area network (LAN) through the designation of a single network management node which directs other nodes to perform backup, software distribution, or other network management tasks. While this system provides a means for managing a network, there is no recognition or teaching of the management of a large mainframe hardware resource. In particular, there is no recognition of the requirement to establish fault tolerant connection facilities between a console client and the hardware resource. 
     The problem of creating a system for remotely controlling a resource such as a large computer system in a manner that allows remote access, failure recovery, and configuration flexibility is addressed in commonly assigned patent application Ser. No. 07/771,064 entitled &#34;Centralized Control for Distributed Applications.&#34; The system of that application provides a means for establishing the location of the resource to be controlled and for creating a link between a logical console, a resource server and that resource. At least one resource server is attached to each resource to be controlled. Redundant resource servers provide gateway fallback options. The system is able to recognize and recover from the failure of any control system component. 
     There remains a technical problem of ensuring that the physical computer system structure meets the requirements of the logically defined structure. In particular, fallback to a second resource server or logical console will itself fail if the physical network configuration has been modified or if a device failure has occurred. The technical problem is to provide an information processing system and method for verifying the conformity of logical to physical configurations and for assuring failure fallback integrity. 
     SUMMARY OF THE INVENTION 
     The present invention is therefore directed to a system and method for logical console verification and fallback. The present invention verifies conformity of physical equipment configurations with the logical console control and fallback plan. The method of resource server or logical console fallback to a backup resource server or logical console includes the steps of verifying each physical component defined by the logical configuration description to assure conformity and testing for successful connection. Only after conformance verification does resource server or console fallback occur. 
     It is therefore an object of the present invention to provide a remote operations system with logical fallback console verification. 
     It is yet another object of the invention to establish a fallback methodology that tests the physical fallback link for conformity with logical link definitions prior to initiating fallback and terminates fallback upon test failure. 
     It is yet another object of the invention to establish a process for logical console fallback that assures consistent fallback to an operational console. 
     These and other objects of the invention will become clear through discussion of the preferred embodiment of the present invention which will be made with reference to the following drawings. 
    
    
     BRIEF DESCRIPTION OF THE DRAWING 
     FIG. 1 is a block diagram illustrating a system created according to the present invention. 
     FIG. 2 is a flowchart illustrating the process steps of the logical fallback verification of the present invention. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     The preferred embodiment of the present invention is implemented to control hardware resources, and in particular, to control the operation of a mainframe computer system such as the IBM 3090 computer system (IBM and 3090 are registered trademarks of the IBM Corporation). It will be recognized, however, that the system of the present invention can be used to control other resources which require operator interaction including resources such as a production assembly line, chemical processing facility, or building environmental system. 
     The structure of a system according to the present invention is shown generally in FIG. 1. Resources to be controlled are identified generally at 102, 104, and 106. It will be recognized that this system is applicable to any number of resources and the example of three is shown for illustrative purposes only. 
     Each resource is connected to at least one resource server workstation. Server workstations are shown at 108, 110, and 112. These workstations are an intelligent device such as an IBM Personal System/2 computer system (PS/2) (Personal System/2 and PS/2 are registered trademarks of the IBM Corporation). The servers are connected to hardware resources by communication lines 114, 116, 118, 120 and 122. In the preferred embodiment, a resource typically is connected to more than one server to provide a fallback control path. For example, resource 102 is connected via communication path 114 to server 108 and by communication path 116 to server 110. 
     A client workstation 130 (such as an IBM PS/2 computer system) is provided as a console for operator use. The client workstation manages the operator interaction including the presentation of messages to the operator and the generation or acceptance of commands for controlling the hardware resource. The separation of client and server functions allows a balancing of workload between the devices. It also allows a single client console to manage a number of hardware resources. In the example shown in FIG. 1, client console 130 can manage resources 102, 104, and 106. 
     The client console communicates with the servers by means of a local area network (LAN) shown generally at 150. This network can be any one of several known networks, such as the IBM Token Ring LAN, an Ethernet LAN, or others. In the preferred embodiment, the control scheme is implemented using dual token ring LANS which provide for redundancy in case of the failure by either individual LAN. 
     A central control facility containing control and administrative applications (CAA) is provided to control the operation of the control system. This control server 160 is a workstation which has been configured to support and control the overall operation of the resource control system. The control server provides centralized control to ensure that console access exists for each resource to be controlled and that the client workstations know how to access each resource and how to recover from component failure. Control server 160 manages the network based upon configuration data stored in a database 162. This data can be stored in a variety of known forms such as files on the server or data under the control of the database management system. 
     The configuration data consists of two major types of data. First, static configuration data contain a description of each hardware resource location to be controlled. It also contains the parameters necessary for accessing and controlling that resource and identifies primary and fallback access paths to that resource. The second type of data is dynamic configuration data describing the current configuration for controlling each resource. This data is maintained to assure that each resource is under the control of a console and for use by fallback processing routines to re-establish communications in the case of a failure. 
     The basic process of the present invention is described with reference to FIG. 2. The process of the present invention can operate in response to an explicit validate and fallback request issued by an operator, e.g. when a console or server is to be disconnected for service, or can operate in response to an unplanned component failure. 
     The operator or recovery process issues a VALIDATE request 202 to a controlled resource, e.g. resource 102. Resource 102 contains processing logic that recognizes the validate request and issues a system identifier message 204 directed to the defined alternate resource server, e.g. server 110 in FIG. 2. The address of the alternate resource server can be explicitly specified in the validate command or the resource can use a previously defined fallback server address contained in local storage. 
     Central control facility 160 accesses 206 the configuration files 162 to determine the fallback resource server and the fallback logical console workstation for the requesting system. The collected configuration information is parsed 207 and sent as the resource server identifier and workstation identifier. 
     Alternate resource server 110 attempts to establish communication 208 with a defined alternate logical console for the requesting resource 102. Resource server 110 determines the alternate logical console by querying the configuration database contained in control server 160. Once identified, server 110 establishes a session with the logical console, e.g. console 130. The alternate logical console may be the same workstation as the primary logical console depending upon the network configuration. 
     The network is tested to determine whether linking has been successful 210. A logical console linkage failure is indicated by the generation of linkage error message, or by the failure of alternate logical console to receive the messages sent by the VALIDATE request. If operating in manual validate mode, the operator will recognize link failure and terminate fallback processing. In automated mode, a message is transmitted back to the recovery process indicating alternate path failure thereby terminating fallback processing with the appropriate message 214. If linking has been successful, controller fallback is initiated 212 by the entry of a manual fallback command or automatically by the resource 102. All console messages and activities will then be directed from resource 102 through server 110 to the fallback logical console, e.g. 130. 
     It will be understood from the foregoing description that various modifications and changes may be made in the preferred embodiment of the present invention without departing from its true spirit. This description is intended for the purpose of illustration only and should not be construed in a limiting sense. The scope of this invention should be limited only by the language of the following claims.