Browse Prior Art Database

Display Service Effect

IP.com Disclosure Number: IPCOM000235617D
Publication Date: 2014-Mar-13
Document File: 3 page(s) / 103K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to provide information about the status of server resources in the form of a table in response to a Display Service Effect request.

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

Page 01 of 3

Display Service Effect

When a user selects one or more resources (i.e., Customer Replaceable Units, Field Replaceable Units) as part of a service action (e.g., repair, remove, or install), resources may not be available to the customer. Due to redundancy and the dynamic state of the machine, the resources to be lost to the customer depend on the selection of resources and on the state of the existing resources. Determining the resources lost to the customer and displaying that information is called "Display Service Effect".

Solutions to this problem in the past have been one monolithic code that understands all types of resources and the associated requirements. This code gathered the information as needed. This required client side knowledge of all resource types and the associated requirements to service. When the requirements on the server side change, the client needs to know and implement the new requirements, which makes it difficult to maintain.

The novel contribution is a method in which the client requests the data from the server that understands the components it possesses. As part of a Display Service Effect request, the client calls the server and passes in the requested resource(s) owned by that server. The server responds with a table containing the needed information that can be interpreted by the client to be able to display the "Service Effect".

Determining the Service Effect

With this method, the client code calls the server code. The input parameters are the selected resource(s) owned by the server. The server code needs to evaluate the "effect" of taking away the selected resource(s). This is done by the server code doing the following for each input resource:


1. The server code determines whether the resource is redundant


2. If the resource is redundant, then the server code does the following:

A. The server code determines if the associated resources that make it redundant are in a working state such that if this resource were to be unavailable the redundancy would remain. If the redundancy does not remain, then the server code saves the input resource and the associated resource(s) in the non-working state.

B. If the resource is redundant, then the server code determines if the associated resources that make it redundant are also in the input list and would therefore be unavailable. If this causes the loss of redundancy, then the server code saves the input resource and the associated resource(s) in an input list that causes the loss of redundancy.


3. If the resource is not redundant, then it is listed as causing the loss of redundancy

Once the above steps are completed for each resource, the server code determines if the net effect is Concurrent, Nonconcurrent, or Not Allowed. Concurrent means there is no loss of resources for the customer. Nonconcurrent means some resources will be lost during the service, but the service can continue. Not Allowed means the loss of resources is such that this repair as s...