Browse Prior Art Database

A Method to Internally Execute a Retryable Command Line Interface (CLI) Command Disclosure Number: IPCOM000190193D
Original Publication Date: 2009-Nov-19
Included in the Prior Art Database: 2009-Nov-19
Document File: 5 page(s) / 32K

Publishing Venue



This invention proposes a method to internally retry a failed Command Line Interface (CLI) command. Therefore, with this invention there is no need for a customer to write an script that contains retry cases in case of failure, nor will a customer be required to make changes to a script in production to accommodate a new case of a Retryable CLI command.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 37% of the total text.

Page 1 of 5

A Method to Internally Execute a Retryable Command Line Interface (CLI) Command

Storage controllers like IBM DS8000 provides a Command Line Interface (CLI). With CLI a user may configure the storage controller hardware resources. Configured hardware resources such as devices may be configured to be used in Copy Service relationships.

One advantage with CLI is that a user may create an script that contains several CLI commands. The CLI processor would then execute one CLI command at a time. When one CLI command completes, the next one is read from the script. This goes on until all CLI commands in the script are executed.

When the storage controller is working without interruption, the CLI scripts work without a problem. It is when the storage controller goes into a recovery state that the scripts may not work as expected. When the storage controller is in recovery mode, it does not accept commands from CLI. Some common recovery modes in which storage controller does not accept CLI commands until the recovery is completed are: warmstart, failover, failback, single cluster IML. The CLI rejection case can also occur for lack of resources to execute the CLI command. Or resources that are needed to execute the CLI command are temporarily unavailable, such as metadata, etc.

When a CLI command is rejected, the CLI processor reports an error and the CLI script is aborted. When this happens, a customer may opt to rerun the script. Depending on the storage controller recovery state, the retry of the failed CLI may be successful or fail again.

One solution to this problem is for the customer to add retry handling techniques to the script. That is, when a CLI command is rejected, the script will retry the CLI command if the CLI is rejected with a status code that signals a retry request to the user. One exposure to this solution is when a new case in the storage controller causes the rejection of a CLI command with a different status code. Thus after extensive investigation and analysis the customer is told that he or she needs to modify the script to handle the new case of retry request.

This brings out another point. Although CLI scripts can be written to allow for automated execution of CLI commands, customers may be hesitant to rely on it due to problems that cause repeated changes in the script to handle cases of a temporary unavailable storage controller. So, a person is designated to run the scripts manually to make sure that the CLI script completes executing all its CLI commands.

The above solution forces customers to write scripts that would handle all known cases of CLI command failures that would require a simple retry of the CLI command to be successful. The changes in the script which was used in a production environment must be tested before it is introduced into the production environment.

Therefore, all the responsibility to handle CLI failures that can be retried are left to the