METHOD AND SYSTEM FOR MANAGEMENT OF ONE OR MORE REMOTE COMPUTING SYSTEMS The present invention relates generally to a method and system for managing one or more remote computing systems, and in particular to a method and system for managing actions such as an automated mainframe Logical Partition (LPAR) active system task termination, reset-normal/clear, activate/deactivate, load (Initial-Program-Load (IPL)), stop, start, pswrestart, send opsys and invoke a stand alone dump of the computing systems. The present invention is suitable for use in applications in which the management of the one or more remote computing systems is performed via an Internet-based user interface and it will be convenient to describe the invention in relation to that exemplary application. Many companies are required to manage and monitor multiple data centers at different locations. For example, each data center may require the need to perform or instruct an outage that requires a mainframe Logical Partition (LPAR) to be recycled. In some organisations, remote data center management is controlled by an automated outboard engine that manages messages received from each established TN3270 Telnet Session, and applies policies to these messages as specified by an administrator as well as initiating follow-up actions based on the policies. These actions may range from issuing session commands to notifying operators to take necessary action for a critical event. However, such automated outboard engines are difficult for an operator to manoeuvre through and understand where options to perform various actions reside. Operators of the automated outboard engine must typically be present at all times in order to monitor and control activities taking place on various data centers within the organisation. Operators are not provided with full visibility of a current or occurring IPL (Initial Program Load) process within their data center environment. Moreover, multiple automated outboard engines are required to be installed on a number of terminals if multiple operators are required to control or monitor processes occurring within the various data centers. It would be desirable to provide a method for management of one or more remote computing systems that ameliorates or addresses one or more disadvantages of known remote computing system techniques.
It would also be desirable to provide an improved method and system for management of one or more remote computing systems in which an automated outboard engine is used to monitor messages and perform automated actions, that improves operator visibility and control of events within each remote computing system. It would also be desirable to provide a method and system for managing one or more remote computing systems that was simpler, more transparent and easier to use for operators of the remote computing systems. One aspect of the invention provides a system for managing actions performed on one or more remote computing systems, the system comprising: a hardware management console (HMC) operably connected to the remote computing systems; an automation component for monitoring messages received from the remote computing systems and automating actions performed on the remote computing systems; a database for logging messages and events from the remote computing systems, and maintaining system profile, asset and configuration information for use in relation to performing actions on the remote computer system; and a remote system management application operably connected to the automation component and the database, the remote system management application acting to provide remote user control of the automation component and the hardware management console, and further providing remote user viewing of the logged messages and events and enabling access to and viewing of the system profile, asset and configuration information. Preferably the remote system management application is implemented as web application. The operations performed on the one or more remote computing systems may include, but are not limited to: automated system or logical partition (LPAR) active task termination, terminating current operations; clearing one or more interruption conditions; clearing main storage and/or registers; system task activation; stopping an operational status; de-allocating system resources; clearing
associated hardware; execution of a program read from a designated device; stopping the operational status, start processing instructions, central processor CPC restart operations, sending a command to the operating system and/or invocation of a standalone dump. Preferably the automation component takes the form of an automated outboard engine. Preferably the actions performed on one or more remote computing systems are performed on a mainframe Logical Partition (LPAR) forming part of one or more of the remote computing systems. In a preferred implementation the actions performed on one or more remote computing systems be performed from an Internet browser. In a second aspect there is provided a remote system management application for enabling the management of one or more actions performed on one or more remote computing systems, said system including, a hardware management console operably connected to the remote computing systems; an automated outboard engine for monitoring messages received from the remote computing systems and automating actions performed on the remote computing systems; a database for logging messages and events from the remote computing systems, and maintaining system profile, asset and configuration information for use in relation to performing actions on the remote computer system; wherein said a remote system management application is operably connected to the automated outboard engine and the database and is configured to provide control of the automated outboard engine and the hardware management console to a user; enable logged messages and events to be viewed by a user; and enable user access to and viewing of a system profile, asset and configuration information. In a third aspect there is provided a remote system management application for enabling the management of one or more actions performed on one or more remote computing systems said remote system management application , said system including a hardware management console operably connected to the remote computing systems and a database for logging messages and events from the remote computing systems, and maintaining system profile, asset and
configuration information for use in relation to performing actions on the remote computer system; wherein said a remote system management application includes an automation component for monitoring messages received from the remote computing systems and automating actions performed on the remote computing systems; and is operably connected to the database, said remote system management application being configured to: provide control of the hardware management console (HMC); enable logged messages and events to be viewed by a user; and enable user access to and viewing of a system profile, asset and configuration information. In these implementations it is preferable that the remote system management application is implemented as web application. In a further aspect there is provided a method of facilitating the performance of an action on a remote computing system, said method including: enabling remote interaction with an automation component and hardware management console of the system to control the performance said action; logging messages and events from the remote computing system to a database, storing system profile, asset and configuration information for use in relation to performance of actions on the remote computer system in said database; enabling remote viewing and access to said stored system profile, asset and configuration information; and enabling remote viewing of said logged messages and events. The following description refers in more detail to the various features of the present invention. To facilitate an understanding of the invention, reference is made in the description to the accompanying drawings where the system for managing of one or more remote computing systems is illustrated in a preferred embodiment. It is to be understood however that the invention is not limited to the preferred embodiment illustrated in the drawings. In the drawings: Figure 1 is a schematic diagram illustrating one embodiment of a system for managing one or more remote computing systems in accordance with the present invention;
Figure 2 is a flow chart illustrating actions performed during a mainframe
Logical Partition (LPAR) active system task termination, reset-normal/ clear, activate/ deactivate, load (Initial-Program-Load (IPL)), stop, start, pswrestart, send opsys or invoke a stand alone dump of a system, forming part of a mainframe LPAR of Figure 1 ; Figure 3 is a flow chart illustrating the flow of Multiple Virtual Systems (MVS) messages in the system of Figure 1 ; Figure 4 is a flow chart illustrating the transmission and storage of events occurring within the system of Figure 1 for viewing by a user; Figure 5 is a flow chart illustrating user selectable options for viewing data stored within the system of Figure 1 ; Figure 6 is a flow chart illustrating the storage of system profile, asset and configuration information for automated IPLs in the system of Figure 1 ; and Figure 7 is a flow chart illustrating the basic retrieval of stored data to present graphical reports and the light from previous active system task terminations and IPLs in the system of Figure 1. In the illustrative embodiments described herein, the remote system management application is implemented as a web application running on a web server, however it should be noted that the present invention should not be considered as limited to such an implementation. In this regard the present invention should be understood to extend to implementations in which the user interacts with the remote system management application via a network other than the World Wide Web and/or using a communication protocol other than HTTP. In certain implementations, the remote system management application can be run as an application on a user terminal or run remotely on an application server with a corresponding client side application running on a user terminal. Referring now to Figure 1 , there is shown generally a system 10 for managing one or more remote computing systems, here referenced 12 and 14. The computing systems 12 and 14 are in this example mainframe computer systems maintained in different physical locations. A terminal controller 16 controls operation of the mainframe 12, whilst a terminal controller 18 controls operation of the mainframe 14. The system 10 includes a Hardware Management
Console (HMC) 20 providing a central management terminal for each of the mainframes 12 and 14. An automation component, implemented in this example as an automated outboard engine 22, is operatively connected to each of the terminal controllers 16 and 18. In certain embodiments of the invention, the automated outboard engine may be implemented by Computer Associates Unicenter® Automation Point™, IBM Tivoli AF/Remote® or BMC's CONTROL- M/Links outboard automated engine. The automated outboard engine 22 monitors and manages the system messages received from established TN3270 Telnet Sessions 202 via the terminal controllers 16 and 18. The automated outboard engine 22 automates by managing messages received from the established TN3270 Telnet Sessions 202, applying policies to those messages as specified by an administrator and initiating follow-up actions based on the policy. These actions may range from issuing session commands to notifying computer operational staff to take a necessary action for a critical event. The system 10 further includes a database 24, a web server 26 and a remote system management application, implemented as a web application 28. The server 26 is operably connected to the automated outboard engine 22. An end user terminal 30 is operably connected to the web application 28 via the Internet or other suitable data network. The end user terminal 30 is also in data communication with the HMC 20. The web application 28 is a front end website that drives processes or instructions sent from the user terminal 30. The web application 28 provides user access to a series of functions to enable a user to perform a range of functions including, but not limited to, initiating an automated mainframe Logical Partition (LPAR) active system task termination, reset-normal/ clear, activate/ deactivate, load (Initial-Program-Load (IPL)), stop, start, pswrestart, send opsys or invoke a stand alone dump from the web application 28. The web application 28 also enables a user at the end user terminal 30 to manage system profile and asset information maintained in the database 24, manage Input/Output Configuration Dataset (IOCDS) information maintained in the database 24, and view HMC information. The web application can also provide, to a user of terminal 30, technical documentation areas, display historical data relating to previous IPL and active system task termination occurrences, display historical data relating to previous IPL and active system task termination
messages, retrieve automated outboard engine messages and event logs, update and view automated outboard engine global and environment variables, load and update automated outboard engine rule files and provide a dynamic console emulation facility for a mainframe Logical Partition (LPAR) active system task termination, reset-normal/ clear, activate/ deactivate, load (Initial-Program-Load (IPL)), stop, start, pswrestart, send opsys and invoke a stand alone dump. Figure 2 depicts a flowchart showing a method 50 of operation of the system 10 of Figure 1. As seen in Figure 2, the web application 28 is accessed from the end user terminal 30 at step 100. At step 102, the operator uses a series of menu options to select the particular mainframe, site or system upon which an automated action is to be performed. At step 104, the environment in which the user wishes to perform the mainframe action is selected. Exemplary categories may include production, pre- production, development, QA and test categories. At step 106, a decision is made by the web application 28 as to the type of action the operator wishes to perform on the selected mainframe system to initiate one of the following: (a) a mainframe active system task termination to a specific LPAR, (b) a mainframe LPAR reset-normal/ clear, activate/ deactivate, stop, start, pswrestart, send opsys or invoke a stand alone dump, (c) a mainframe IPL to a specific LPAR, or (d) a combined mainframe active system task termination and IPL to a specific LPAR. If a shutdown is selected at 106, a command is sent at step 108 to the automated outboard engine 22 and the HMC 20 specifying the action to be performed to the specific LPAR which is to be processed by the HMC at step 135 to invoke an automated LPAR active system task termination. The process is logged to the database 24 at step 110. The shutdown instruction 108 will use the HMC 20 via Simple Network Management Protocol (SNMP) to act and carry out the shutdown action requested at step 135. The process log maintained in the
database 24 is available for subsequent viewing at the end user terminal 30 for dynamic and historical viewing. If a reset-normal/ clear, activate/ deactivate, stop, start, pswrestart, send opsys or invoke a stand alone dump is selected 15 106, a request is forwarded at step 114 to the HMC 20 via Simple Network Management Protocol (SNMP). The process is logged to the automated outboard engine 22 and in the database 24 at step 116. The HMC then executes the command instruction at step 118. The response from the HMC 20 is then returned to the web application 28. If neither a mainframe shutdown to a specific LPAR or a mainframe reset- normal/ clear, activate/ deactivate, stop, start, pswrestart, send opsys or invoke a stand alone dump to a specific LPAR are selected, the relevant profile parameters maintained in the database 24 are selected in step 120 to perform either a mainframe IPL to a specific LPAR or a combined active system task termination and IPL to a specific LPAR. If a mainframe system IPL to a specific LPAR is selected, a specific mainframe LPAR is recycled using current or new program load parameters. At step 122, a request is sent to the HMC to perform the IPL on the selected mainframe LPAR. The request is sent, and corresponding status information is received, from the HMC 20 via Simple Network Management
Protocol (SNMP). Profile and asset information maintained in the database 24 is updated at step 124. The HMC performs the IPL on the selected mainframe
LPAR at step 126. Alternatively, if a combined shutdown and IPL is selected at 120, then a request is sent at step 128 to the HMC 134. This operation effectively combines the operations performed in relation to the associated LPAR. Accordingly, the application 28 invokes the active system task termination of the selected mainframe LPAR to step 128 and logs events occurring during the process in the database 24 at step 132 and automated outboard engine 22. The application 28 then transmits a request via the end user terminal 30 to the HMC 20 to cause the IPL of the selected mainframe LPAR to be initiated at step 134. Once again, events occurring during this process are logged to automated outboard engine 22 as well as updated profile information being maintained in the database 24. As seen in Figure 3, a user uses a web browser 200 that is installed on the user terminal 30 to access the web application 28 which in turn communicates
with the automated outboard engine 22. The automated outboard engine 22 communicates with the mainframes 12 and 14 using established TN3270 Telnet Sessions 202 via the use of software and hardware components 16,18 and 202. By way of example, the established MVS sessions may be derived from Attach Mate Extra™ or a similar software product. These sessions are configured within the automated outboard engine 22 and used to display messages from the host. Figure 4 illustrates the manner in which logs 300 are rendered back to the Internet browser 200 of the end user terminal 30 by the web application 28 from the database 24. In this example, the user establishes a connection 302 with the web application 28 via the Internet browser 200. Information received from the established TN3270 Telnet Sessions 202 are logged via the automated outboard engine 22 to the database 24 and dynamically to a web console emulation 404. The stored log information in database 24 is retrieved by the web application 28 and served to the Internet browser 200 for presentation as a series of displays 300 to the user. Figure 5 illustrates the manner in which the user of the end user terminal 30 can access data stored in the database 24. Data stored in the database 24 which is derived from actions performed by the automated outboard engine 22, is accessed by the web application 28 and rendered to the Internet browser for the end user. A first series of automated outboard engine logs 400 may be presented to a user derived from automated actions configured within the automated outboard engine 22. The web application 28 renders the display of the TN3270 Telnet Sessions 202 and command entries 402. A console emulation capturing and presenting system messages is available from the browser 200. Automation log swapping is provided by the display 404. Logs for the host and automated outboard engine message logs may be swapped from this display. The web application 28 enables log swapping from the Internet browser, removing the need to revert back to the Graphic User Interface (GUI) of the automated outboard engine 22. A display 404 allows for global and environment variable setting, updating and viewing from the Internet browser 200 set by the automated outboard engine 22. The display 406 supports the option of loading new rules files and updating rules files with new requests loaded by the automated outboard engine from the Internet browser 200. As will be appreciated, with this
embodiment, there is no need to use the Graphical User Interface (GUI) options from any automated outboard engine, thereby saving the need to load a client version to any desktop PC. As seen in Figure 6, the system 10 provides two other storage component areas, namely an Input/Output configuration data set (IOCDS) storage area to preserve I/O configuration dataset information, and IPL profile and asset information storage area to preserve IPL and mainframe configuration parameter information. Both storage component areas are maintained within the database 24. The user accesses the data stored in the database 24 using the web application 28 via the Internet browser 200 of the end user terminal 30. From here, the web application 28 presents to the user the possibility of selecting, at step 600, to either add, update or delete IPL profile information at step 602, or alternatively add, update or delete IOCDS information at step 604. The web application enables two options to be selected, a first to make a profile current, for the next automated IPL if required and secondly to store all parameter information. As seen in Figure 7, the web application 28 is adapted to produce graphical displays of data maintained in the database 24 via the Internet browser 200. The graphical displays 700 may typically include bar and line graphs that benchmark historical timelines from previous IPLs, active system task termination and/or LPAR reset-normal/ clear, activate/ deactivate, stop, start, pswrestart, send opsys and invocation of a stand alone dump. From the foregoing, it can be seen that the system 10 provides the ability for computer support or operational staff to perform an automated remote web active system task termination and perform an automated mainframe IPL from a web browser, whilst logging all relevant events occurring during these processes. The web application may sit on top of an automated engine that filters or screen scrapes messages from established TN3270 Telnet Sessions. It uses this to log dynamic events from a mainframe system. The web application then logs events and critical system messages from the system for subsequent review by computer support or operational staff. It should be understood that the web application is not limited to use with an automated outboard engine, but can be configured to perform the above mentioned functions, including, but not limited to, a mainframe IPL, an active
system task termination, reset-normal/ clear, activate/ deactivate, stop, start, pswrestart, send opsys or invoke a stand alone dump of a mainframe system without the use of an automated outboard engine. The web application provides a web enabled layer for the automated outboard engine providing web viewing of automated outboard engine logs, update and reload automated outboard engine rules files, provide web enabled console emulation and message command entry, set and update automated outboard engine global and environment variables and switch automated outboard engine logs without the use of a graphical user interface traditionally used for automated outboard engines. The web application moreover provides a storage area for mainframe software support personnel to store system LPAR profile, asset and IOCDS information for automated IPLs removing the need to store profile information on the HMC. Where benchmarking utilities that use the stored data from past automated active system task terminations (system shutdown(s)) and IPLs are also provided for auditing, as well as a graphical representation of the data to the user via a web browser. Finally, it should be appreciated that modifications and/or alterations may be made to the system for managing one or more remote computing systems described here-above without departing from the spirit or ambit of the invention.