Browse Prior Art Database

Filtered Error Handling During Error Recovery Disclosure Number: IPCOM000035360D
Original Publication Date: 2005-Jan-20
Included in the Prior Art Database: 2005-Jan-20
Document File: 3 page(s) / 54K

Publishing Venue



Extend the capability of ERP’s (Error Recovery Procedures) by enabling a user to specify how the ERP is to process the error condition. The extension permits the user to define the classification to use for logging the error or enable the user to specify additional tasks to be performed by the ERP.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3


TUC820040447 John C Kennel/Tucson/IBM Craig Klein, John Ain, Eric McGar, James Henry, Pete Pederson, Nathaniel L Billups, Eric A Vega

Filtered Error Handling During Error Recovery

Disclosed is a method that describes how an ERP can be modified to enable a user to specify error conditions in which the ERP is to perform additional tasks such as to snapshot the state of the SUT (system under test) at the time the failure occurred or remotely execute a shell script that could contain a set of host system operating system commands (e.g. rexec, telnet, ssh, etc.).

When a sequence of events such as a CCW (Channel Command Word) chain in a mainframe environment or CDB (Command Descriptor Block) in an open system environment are sent to a SUT, status is returned to the host indicating if the sequence of events was successful or if an error occurred. In the case of a failure, such as: invalid command parameter data, invalid command sequencing, reserved bits not set correctly, device reserved to another host, etc., the host would respond to the error status by interrogating the SUT to determine what was wrong. This process is typically performed by the ERP which would process the failure, validate the error data, log all pertinent data and programmatically recovering from the error if possible.

After the host has defined the ERP entry point, ERP is invoked which validates any data (typically sense data) returned by the SUT. If the data is ok, the ERP would get the user defined filtering actions which could be used to change the error data output classifications or execute additional host system commands. If the user defined filter action altered the error classification, then the ERP would log the data using the updated classifications. However, if the user defined filter action specified a shell script, the ERP would then execute the shell script which could contain any valid system/shell commands. Figure 1 depicts a state machine that shows the sequence of events.


Page 2 of 3

The user defined filter interface can be implemented using something as simple as an ASCII text file to define the error(s) and the information stored in one or more structures. For example the error(s) within...