Abstract: Data channels of a computer system may be remotely monitored to detect data channel degradation. A monitoring agent on a client may execute script commands on the remote computer system to monitor input/output (I/O) rates of a set of channels. The monitoring agent may compute an average data rate of the data channels and compare the I/O rate of each channel to the average. When the I/O rate of a channel falls below the average by at least a threshold amount, an alert may be generated to indicate to an administrator a possible failure with the data channel.

Abstract: Data channels of a computer system may be remotely monitored to detect data channel degradation. A monitoring agent on a client may execute script commands on the remote computer system to monitor input/output (I/O) rates of a set of channels. The monitoring agent may compute an average data rate of the data channels and compare the I/O rate of each channel to the average. When the I/O rate of a channel falls below the average by at least a threshold amount, an alert may be generated to indicate to an administrator a possible failure with the data channel.

Abstract: Data channels of a computer system may be remotely monitored to detect data channel degradation. A monitoring agent on a client may execute script commands on the remote computer system to monitor input/output (I/O) rates of a set of channels. The monitoring agent may compute an average data rate of the data channels and compare the I/O rate of each channel to the average. When the I/O rate of a channel falls below the average by at least a threshold amount, an alert may be generated to indicate to an administrator a possible failure with the data channel.

Abstract: Non-automated read-and-reply console messages may be automated. These messages may be classified into impact groups in which the messages may be removed from the database or sent to an automation analyzer for analysis. As more messages become automated, a debugging mode may be enabled to allow an operator to respond to a message with a proposed action. If the proposed action is aligned with an action predetermined in response to the automation analysis, the operator may be allowed to respond to future actions.

Abstract: A system and method for monitoring and correcting device operating states during steady-state operations may be automated. The operating states for devices operating in a steady-state environment may be monitored. Any operating device that is set to operate in an unexpected operating state may be automatically changed to its expected operating state. The operator may then be warned of any incorrect state assignment through a console message that cannot be ignored by the operator.

Abstract: Monitoring of storage systems, including virtual tape libraries (VTLs), may be performed with automated systems. Automated monitoring may be performed through an SSH connection to a storage manager for the storage system. For example, a method may include initiating, by a monitoring server, an SSH connection to a storage manager; issuing commands, by the monitoring server, through the SSH connection to monitor a storage device coupled to the storage manager; receiving, by the monitoring server, responses to the issued commands through the SSH connection; matching, by the monitoring server, the responses to automation rules; and executing, by the monitoring server, commands based on the matched automation rules.

Abstract: Non-automated read-and-reply console messages may be automated. These messages may be classified into impact groups in which the messages may be removed from the database or sent to an automation analyzer for analysis. As more messages become automated, a debugging mode may be enabled to allow an operator to respond to a message with a proposed action. If the proposed action is aligned with an action predetermined in response to the automation analysis, the operator may be allowed to respond to future actions.

Abstract: Automation scripts may be examined and compared to a set of new or changed operating system messages to identify potential issues with the automation script that occur with updates to the operating system. When the issue is identified, the reference in the automation script may be updated to refer to the changed operating system message. Further, the reference in the automation script may be modified to address other changes in the system messages, such as changes in information and/or parameters reported in the message.

Abstract: Non-automated read-and-reply console messages may be automated. These messages may be classified into impact groups in which the messages may be removed from the database or sent to an automation analyzer for analysis. As more messages become automated, a debugging mode may be enabled to allow an operator to respond to a message with a proposed action. If the proposed action is aligned with an action predetermined in response to the automation analysis, the operator may be allowed to respond to future actions.

Abstract: A system and method for monitoring and correcting device operating states during steady-state operations may be automated. The operating states for devices operating in a steady-state environment may be monitored. Any operating device that is set to operate in an unexpected operating state may be automatically changed to its expected operating state. The operator may then be warned of any incorrect state assignment through a console message that cannot be ignored by the operator.

Abstract: In a disaster recovery context, device operation states can he automatically changed from their expected operating states for steady-state operation as soon as a disaster recovery event is triggered. Every operating device with a first expected operating state for steady-state operation may be automatically changed to a second expected operating state when a disaster recovery event is triggered. Every operating device with the second expected operating state for steady-state operation may be automatically changed to the first expected state when a disaster recovery event is triggered.

Abstract: Systems and methods for multi-threaded server control automation for disaster recovery are described. A method may include initiating a disaster recovery sequence on two or more processors, wherein the disaster recovery sequence comprises a plurality of subsequences. The method may also include implementing the disaster recovery sequence on the two or more processors in parallel, wherein one or more subsequences of the disaster recovery sequence are implemented on the two or more processors in parallel. Upon completion of the disaster recovery sequence, at least one server partition is repurposed from a first configuration, such as a test configuration, to a second configuration, such as a production configuration.

Abstract: Non-automated read-and-reply console messages may be automated. These messages may be classified into impact groups in which the messages may be removed from the database or sent to an automation analyzer for analysis. As more messages become automated, a debugging mode may be enabled to allow an operator to respond to a message with a proposed action. If the proposed action is aligned with an action predetermined in response to the automation analysis, the operator may be allowed to respond to future actions.

Abstract: Non-automated read-and-reply console messages may be automated. These messages may be classified into impact groups in which the messages may be removed from the database or sent to an automation analyzer for analysis. As more messages become automated, a debugging mode may be enabled to allow an operator to respond to a message with a proposed action. If the proposed action is aligned with an action predetermined in response to the automation analysis, the operator may be allowed to respond to future actions.

Abstract: Non-automated read-and-reply console messages may be automated. These messages may be classified into impact groups in which the messages may be removed from the database or sent to an automation analyzer for analysis. As more messages become automated, a debugging mode may be enabled to allow an operator to respond to a message with a proposed action. If the proposed action is aligned with an action predetermined in response to the automation analysis, the operator may be allowed to respond to future actions.

Abstract: A global cache of automation variables may be established for a computing environment. Message event reports may be received and parsed at an application manager. Based on the message event report, variables may be stored in a global cache for use by several different disparate computer systems executing different operating systems. If a system reboot or failure occurs, the variables may be retrieved from the global cache and transmitted to the required systems to restore operations.

Abstract: Read-and-reply console messages may be received and a reply automatically generated. Further, a message system may test the availability of an automation sequence for a computing environment. Test commands may be transmitted to a system to test if automation is available. If automation is available, a message system may receive a read-and-reply console message and transmit the message to a host system where an automation sequence may be performed. After the automation sequence is verified, the read-and-reply console message may be answered.

Abstract: Read-and-reply console messages may be received and a reply automatically generated. Further, a message system may test the availability of an automation sequence for a computing environment. Test commands may be transmitted to a system to test if automation is available. If automation is available, a message system may receive a read-and-reply console message and transmit the message to a host system where an automation sequence may be performed. After the automation sequence is verified, the read-and-reply console message may be answered.

Abstract: Automation scripts may be examined and compared to a set of new or changed operating system messages to identify potential issues with the automation script that occur with updates to the operating system. When the issue is identified, the reference in the automation script may be updated to refer to the changed operating system message. Further, the reference in the automation script may be modified to address other changes in the system messages, such as changes in information and/or parameters reported in the message.

Abstract: Monitoring of storage systems, including virtual tape libraries (VTLs), may be performed with automated systems. Automated monitoring may be performed through an SSH connection to a storage manager for the storage system. For example, a method may include initiating, by a monitoring server, an SSH connection to a storage manager; issuing commands, by the monitoring server, through the SSH connection to monitor a storage device coupled to the storage manager; receiving, by the monitoring server, responses to the issued commands through the SSH connection; matching, by the monitoring server, the responses to automation rules; and executing, by the monitoring server, commands based on the matched automation rules.