Method and apparatus for software maintenance at remote nodes6110228Abstract A computer network system includes a central software service site that operates with a customer interface through which a customer at a remote location can request service and receive updated executable code back from the service site. The customer interface provides a seamless front end across the different software platforms of the network. A customer initiates servicing of a program product by composing a service request through the front end, which provides a mechanism for the collection of information regarding the nature of the customer request. The front end permits the customer to specify a range of optional operations to be performed at the service site, including service research, requesting service, applying service, and installing fixes from the service site to the remote location. A service facility at the service site performs the requested service and provides the results back to the customer, or collects the service and returns the product and service to the remote location for application of service. The source code for the program product being updated resides only at the service site. All code is returned to the remote location over the network in a form that is ready to be executed. In a distributed implementation, the service site is provided as a central node and one or more slave nodes that also perform service. Claims We claim: Description BACKGROUND OF THE INVENTION
______________________________________
Display an Enter screen providing
a menu of options;
Receive customer selection;
Verify that customer selection is valid;
Execute the customer selection menu choice;
End.
______________________________________
The processing steps involved with the execution of the menu selection will be better understood with reference to the following data flow diagrams and pseudocode. The first data flow diagram, FIG. 5, shows the overall processing involved in fulfilling a customer (end customer) service request. The first step comprises receiving customer system required changes at the front end, as described above, and producing service request details after validation and formatting. This processing step is represented in the data flow diagram by the diagram box numbered 92. Next, the service request details are provided to the service facility at the flow diagram box numbered 94, which then performs the service request. FIG. 5 shows that the service facility receives and updates system configuration information and update changes from data repositories identified by the flow diagram box numbered 96. Such data repositories can comprise, for example, direct access disk storage devices (DASDs) connected to the central node. The repositories 96 are illustrated in FIG. 5 as comprising a first group of "PTF Requisites" designated D1, which is a list of all the types of requisite service necessary to be applied prior to applying a specific piece of service, which is commonly referred to as a Program Temporary Fix ("PTF"). Another repository group is designated D2, "PE Information", and comprises a service-with-error list that includes a listing of service with errors and the subsequent service fix for the error. The next repository is labelled "PTF Repository" designated D3 and comprises a list with associated information concerning the PTFs, such as whether PEs (listed in D2) exist. A "Destination Node" repository, D4, contains a list of all valid target system nodes comprising remote locations and end customers of the network 18, what programs reside on the nodes, status information, and update information for each node. Accordingly, the next repository is that of "Node Configuration Files," D5, which is a set of files for each software product that is used to tailor the product for a particular customer. Finally, a D6 repository called "Node Service History" provides a product image service level history including the PTFs applied, the date of applying, the current service level for the software product, and similar information. FIG. 5 also shows a generalized input/output operation represented by the flow diagram box numbered 98. This diagram box represents a number of operations, including a log of service requests, the service history of the program product for which service is requested, data files for use by the operating system of the service facility, service request reports, and customer specified image files from which the service facility determines the nature of the service to be provided. These operations are described in greater detail below. FIG. 5 indicates that serviced customer-required files are provided for installation at the remote location, as represented by the flow diagram box numbered 100. FIG. 5 also shows that the service facility provides a Service Request Results Report that keeps the customer informed as to the operations that were performed at the service facility. Lastly, the remote location provides information on the installation status back to the service facility, as indicated by the arrow leading from the Install box numbered 100 back to the Perform box numbered 94. The status indicates whether the installation of the serviced files was completed satisfactorily. FIG. 6 is a data flow diagram that illustrates the Submit Service Request processing step (represented by the FIG. 5 flow diagram box numbered 92) in greater detail. The first processing step begins with the receipt of customer system required changes in the form of a service request, indicated as the FIG. 6 flow diagram box numbered 102. After the validation of the customer request, such as described above, the next process to be performed is to format the service request. This formatting is performed by the software maintenance system front end that is resident at the remote location. This processing step is represented by the flow diagram box numbered 104. It should be understood that validation and formatting are implementation specific according to a particular processing system and protocol. Thus, such details will be understood by those skilled in the art without further explanation. Next, the formatted service request is sent over the network, as represented by the flow diagram box numbered 106, thereby providing the service request details to the service facility at the central site. Part of the processing of the front end in receiving a customer service request is to permit the customer to configure a customer product image profile. Such a configuration step permits the customer to specify product information concerning the software program product that is to be updated, the identification of the customer, and options relating to the type of program updates that will be incorporated into the changed program product. For example, FIG. 7 shows a screen labelled "CFG1" to illustrate a first customer configuration screen, which illustrates the type of information gathered by the front end. FIG. 8 is labelled "CFG2" and illustrates a second screen that shows further details of the information gathered by the front end. In the second screen, "HIPERS" refers to very important program changes that are generally viewed as essential for updates. The phrase "PE" refers to a program fix having an identified error, which may or may not have been subsequently solved. The phrase "PEFIX" refers to a fix made to a PE. The phrase "Pre-Requisites" refers to certain predetermined data files necessary before an update can be performed. The phrase "Co-Requisites" refers to files that must be available simultaneously with any particular update. Finally, the phrase "Hard Reqs" refers to any requisites specified by the customer. For example, a customer may be aware of particular fixes that the customer wants to identify by name to be certain of incorporation. The processing steps followed by the system in carrying out the Configure Customer Product Image Profile function of the execution processing shown in FIG. 3 can be better understood with reference to the flow diagram of FIG. 9. In the first step of processing, represented by the flow diagram box numbered 110, the front end interactively receives information for the Configure Customer Product screen. This information includes what is known as the product identifier (called the "prodid" or "prod ID"), which is the name or title designation by which the program product is referred. The prod ID is the designation given to the program product by the product vendor and is not changed by the customer. A customer at a remote location can tailor a particular instance or copy of the program product for use at that remote location, or can include multiple copies of the same program product at the remote location. A particular customer copy of the program product is designated by a corresponding image identifier that is defined by the customer. The product identifier and image identifier together uniquely designate a particular software program product and are referred to as the customer-defined "product image". If necessary, the system waits at the processing step represented by the flow diagram box numbered 110 for the customer to provide screen input through the keyboard at the remote location, or waits for the customer to cancel the configuration request, or waits for a valid add/update/delete request from the screen input. At the next step, indicated by the flow diagram box numbered 112, the system validates any update or add request received from the customer and prepares a corresponding update request with the proper format for transmission to the service facility at the central site. At the FIG. 9 flow diagram box numbered 114, the system responds to an insufficient entry of screen input by filling in the missing information from the indicated program product image supplied by the customer. The information that the system requires can be determined, in relation to the preferred embodiment, with reference to the blank lines displayed in the FIG. 8 sample display screen. If the system cannot determine the nature of the product that the customer wishes to configure, then it indicates an error or provides a suggestion in the form of a list (as indicated by the list function F4 shown at the lower edge of FIG. 8) or displays a help menu. If a cancel or exit command is received, then the action by the system is to exit to the previous display screen or exit the program, respectively. The processing exemplified by the FIG. 9 flow diagram also is reflected in the following pseudo code:
______________________________________
If the customer selection is Configure Customer
Product Image Profile
then
Do
Display the screen with known
customer information
until
an exit request (from application) or
a cancel request (to previous screen) or
a valid add/update/delete request is
received;
If an update or add request is received
then
Do
Validate the data entered as
being valid
If the data entered is valid
then format a Customer
Profile Update Request,
send it to the central
data base update
program, and update
appropriate data bases;
Exit to previous
screen;
else display invalid field
help;
End;
If enter and the product image are
not blank and all other fields
are blank,
then search for the image indicated
and fill in blanks;
If enter and all fields are blank
then suggest F4 for a list of
existing images;
If help request
then display help depending on
cursor location
If cursor is on a field
then field help
else general help;
If cancel/previous request
then exit to previous screen;
If exit request
then exit the application;
End.
______________________________________
The processing exemplified by the pseudo code should be apparent to those skilled in the art, in view of the flow diagram and discussion above, without further explanation. Another option presented to the customer in the Entry screen (FIG. 4) is to configure a software product. The screen displayed on the video monitor of a customer is illustrated in FIG. 10 and is identified as "CFG5. " The display screen of FIG. 10 shows that the front end permits a customer to configure software product files that determine how the program product to be updated will run in a production environment. In FIG. 10, an exemplary file name of "PROFILE" is shown for purposes of illustration only. The processing of this option will be better understood with reference to the flow diagram of FIG. 11 and the discussion below. The first step of processing in the Configure Software Product processing is represented by the FIG. 11 flow diagram box numbered 120, which shows that the system interactively receives information from the customer via the input screen 24a for the software product to be configured, including the product image comprising the product identifier (the "prod ID") and the image identifier referred to above. At the next step, indicated by the box numbered 122, the system retrieves a list of configuration files or returns an error message if the product information provided by the customer does not identify a known product. At the next processing step the customer selects a configuration file for viewing or for updating, as represented by the flow diagram box numbered 124. In the preferred embodiment, the configuration files are maintained at the central site. The system then checks for any added information and, if the customer adds new information to the configuration file the system validates it and exits the routine. This processing is represented by the flow diagram box numbered 126. The next step illustrated in FIG. 11 is indicated by the box numbered 128 and shows that the system determines if insufficient data has been entered interactively from the screen 24a. If possible, the system fills in the missing information from the identified product image. If the system cannot provide the missing information, then at the box numbered 130 it indicates an error or provides a suggestion in the form of a list (as indicated by the list function F4 shown at the lower edge of FIG. 8) or displays a help menu. If a cancel or exit command is received, then the action by the system is to exit to the previous display screen or exit the program, respectively. The processing of this option will be better understood with reference to the pseudo code below:
______________________________________
If the selection is Configure Software Product
then
Do
Display the input screen until
an exit request (from application) or
a cancel request (to previous screen) or
a valid add/update/delete request is
received;
If customer has previously been at this point
then display the list of software product
configuration files from the
last session;
else
Do
Customer enters a software product
image identifier;
If this is a valid software product
image identifier
then retrieve a list of product
configuration files for the
specified software product
image with their current
and intended locations;
else give a message of "unknown
software product";
End.
Customer selects a software product
configuration file to view or update;
Customer can add a new product
configuration file;
If an update request is submitted (by
editing a file)
then
Do
If the data entered is valid
then format a Customer
Profile Update Request;
Send it to the central data
base update program; and
exit to previous screen;
else display invalid field help;
End.
If enter and the product image are
not blank and all other fields are
blank
then search for the image indicated
and fill in blanks;
If enter and all fields are blank
then suggest F4 for a list of existing
images;
If help request
then display help depending on
cursor location;
If cursor is on a field
then field help
else general help;
If cancel request
then exit to previous screen;
If exit request
then exit the application;
End.
______________________________________
The processing exemplified by the pseudo code should be apparent to those skilled in the art in view of the discussion above without further explanation. The next option provided by the Enter screen of FIG. 4 is to research and apply a software product service. If this option is selected, then the preferred embodiment displays a screen such as illustrated in FIG. 12 to the customer. It should be apparent that the information supplie d by the customer in response to the screen provides information necessary to perform service research and to apply the service to a predetermined software product. The processing of this option will be better understood with reference to the flow diagram of FIG. 13 and the discussion below. In the first processing step of FIG. 13, represented by the flow diagram box numbered 136, the front end retrieves information from the Research and Apply a Software Product Service screen. If necessary, the system waits for the customer to interactively provide screen input through the keyboard at the remote location, or waits for the customer to cancel the research request, or waits for a valid research/apply request from the screen input. At the next step, indicated by the flow diagram box numbered 138, the system validates any software product image received, comprising a product identifier (prod ID) and image identifier, and retrieves related product information to perform the research or apply the service. As is apparent from the screen display illustrated in FIG. 12, the customer can press function buttons to select between a Research (F2), Apply (F5), or History (F6) operation. A selection of Research results in the system validating the entered data, formatting a research request, and sending the research request on to the service facility or an equivalent research processor. An invalid entry will result in the display of an error message or a help prompt. This processing is represented by the flow diagram box numbered 140. It should be understood that the exact format of the research request is not critical to the function of the system. Rather, the advantage provided by the preferred embodiment of the invention is in providing the same format, as the system designer may choose it to be, so that the software maintenance function can be performed across different platforms and programs with the same format and therefore the same interface. If the Apply function (F5) is selected, then the system validates the interactively entered data, formats the research and apply request, and provides it to the service facility, as represented by the flow diagram box numbered 142. If the History function (F6) is selected, then the system again validates the entered data before formatting a service history request and providing the request to the service facility. This processing is represented by the flow diagram box numbered 144. Next, as indicated by the flow diagram box numbered 146, the system determines if insufficient data has been entered interactively from the screen. If possible, the system fills in the missing information from the identified product image. If the system cannot provide the missing information, then at the box numbered 148 it indicates an error or provides a suggestion in the form of a list (as indicated by the list function F4 shown at the lower edge of FIG. 8) or displays a help menu. If a cancel or exit command is received, then the action by the system is to exit to the previous display screen or exit the program, respectively. The processing steps carried out by the front end in gathering this information will be better understood with reference to the following pseudocode.
______________________________________
If selection is Research and Apply Software
Product Service
then
Do
Display the screen (initialized with last
session values)
until
an exit request (from application) or
a cancel request (to previous screen) or
a valid research and/or apply request
is received;
If customer has previously been at this point
then display the previous research/apply
information
else
Do
Customer enters research/apply information;
If this is a valid software product/image
identifier
then retrieve related information
for the specified software
product image
else give a message of unknown
software product;
End.
______________________________________
The box 140 Research function processing is illustrated in pseudo code as follows:
______________________________________
If F2 (Research) is pressed
then
Do
Validate the fields entered;
If the data entered is valid
then
Do
Format a research request;
Send the research request to
the service facility or
equivalent request processor;
End;
else display invalid field help;
End.
______________________________________
The box 142 Apply function processing is illustrated in pseudo code as follows:
______________________________________
If F5 (Apply) is pressed
then
Do
Validate the fields entered;
If the data entered is valid
then
Do
Format a research and apply
request;
Send the research and apply
request to the service facility
or equivalent request
processor;
End;
else display invalid field help;
End.
______________________________________
The box 144 History processing is illustrated in pseudo code as follows:
______________________________________
If F6 (History) is pressed
then
Do
Validate the fields entered;
If the data entered is valid
then
Do
Format a Service History Request;
Send the Service History Request
to Service facility or equivalent
request processor;
End;
else display invalid field help;
End.
______________________________________
The processing of flow diagram boxes 146 and 148 is illustrated in pseudo code as follows:
______________________________________
If enter and the product image are not
blank and all other fields are blank
then search for the image indicated
and fill in blanks;
If enter and all fields are blank
then suggest F4 for a list of existing images;
If help request
then display help depending on cursor location;
If cursor is on a field
then field help
else general help;
If cancel request
then exit to previous screen;
If exit request
then exit the application;
End.
______________________________________
The processing exemplified by the pseudo code should be apparent to those skilled in the art, in view of the flow diagram and discussion above, without further explanation. The fourth option provided by the Enter screen of FIG. 4 is to install serviced software product files. FIG. 14 illustrates the type of screen displayed by the front end so that appropriate information can be interactively gathered from the customer to permit the installation of serviced software product files. The processing of this option will be better understood with reference to the flow diagram of FIG. 15 and the discussion below. In the first processing step of FIG. 15, represented by the flow diagram box numbered 156, the front end interactively receives information for the Install Serviced Software Product Files screen. If necessary, the system waits for the customer to interactively provide screen input through the keyboard at the remote location, or waits for the customer to cancel the request, or waits for a valid request from the screen input. At the next step, indicated by the flow diagram box numbered 158, the system validates any product image identifier received and retrieves related product information to perform the installation. As is apparent from the screen display illustrated in FIG. 14, two of the options presented to the customer are to press function buttons to select between an Install (F7) and a History (F6) operation. A selection of Install results in the system validating the entered data, formatting an install request, and sending the install request on to the service facility or an equivalent installation processor. Those skilled in the art will appreciate that the installation process is dependent on the particular operating system implementation. Thus, details of the installation process will be known to those skilled in the art without further explanation. An invalid screen entry will result in the display of an error message or a help prompt. This processing is represented by the FIG. 15 flow diagram box numbered 160. If the History function (F6) is selected, then the system validates the entered data, formats the installation history request, and provides it to the service facility, as represented by the FIG. 15 flow diagram box numbered 162. The installation history operation provides the sequence of changes, fixes, and updates applied to the identified software program product image identifier. As with the Install operation, the processing of the installation history operation is implementation dependent and should be known to those skilled in the art without further explanation. Next, as indicated by the flow diagram box numbered 164, the system determines if insufficient data has been entered interactively from the screen. If possible, the system fills in the missing information from the identified program product image. If the system cannot provide the missing information, then at the box numbered 166 if indicates an error or provides a suggestion in the form of a list (as indicated by the list function F4 shown at the lower edge of FIG. 14) or displays a help menu. If a cancel or exit command is received, then the action by the system is to exit to the previous display screen or exit the program, respectively. The processing steps carried out by the system in performing the installation function will be better understood with reference to the following pseudocode:
______________________________________
If the selection is Install Serviced
Software Product Files
then
Do
Display the input screen
until
an exit request (from application) or
a cancel request (to previous screen) or
a valid install request is received;
If customer has previously been at this point
then display the previous installation
information
else
Do
Customer enters installation information;
If this is a valid product image identifier
then retrieve related information
for the specified software
product image
else give a message of
"unknown software product";
End.
______________________________________
The box 160 Install function processing of FIG. 15 is further illustrated in the following pseudo code, which causes the install request to be formatted and sent to the service facility:
______________________________________
If F7 (Install) is pressed
then
Do
Validate the fields entered;
If the data entered is valid
then
Do
Format an install request;
Send the install request to the
service facility or
equivalent request processor;
End;
else display invalid field help;
End.
______________________________________
The box 162 Installation History function processing is further illustrated in the following pseudo code, which causes the proper request to be formatted and sent to the service facility over the network:
______________________________________
If F6 (History) is pressed
then
Do
Validate the fields entered;
If the data entered is valid
then
Do
Format an Install History Request;
Send the Install History Request
to the service facility or
equivalent request processor;
End;
else display invalid field help;
End.
______________________________________
The processing of boxes 164 and 166 of FIG. 15 are further illustrated by the following pseudo code:
______________________________________
If enter and the product image
identifier are not blank and all
other fields are blank
then search for the image indicated
and fill in blanks;
If enter and all fields are blank
then suggest F4 for a list of existing
images;
If help request
then display help depending on
cursor location;
If cursor is on a field
then field help
else general help;
If cancel request
then exit to previous screen;
If exit request
then exit the application;
End.
______________________________________
The processing exemplified by the pseudo code should be apparent to those skilled in the art, in view of the flow diagram and discussion above, without further explanation. Finally, the last option provided by the Enter screen of FIG. 4 is to perform research, apply service, and install the resulting product. In the case of this option, the front end displays the screen illustrated in FIG. 12 and operates according to the steps illustrated in FIG. 13. Thus, the system waits for either an exit request from the application program, a request cancellation from the customer, or receipt of an installation request from the customer. All other operations are as for the research and apply service option except if the installation option is selected by the customer. In the case of the installation option being selected, then the Install Serviced Software Product screen of FIG. 14 is displayed and the processing for that option as illustrated in FIG. 15 is followed. The following pseudo code illustrates the processing for this option:
______________________________________
If the selection is Research, Apply Service, and Install
then
Do
Display the Research and Apply
Service input screen with F7 = Install
displayed
until
an exit request (from application) or
a cancel request (to previous screen) or
a valid install request is received;
If customer has previously been at this point
then display the previous installation
information
else
Do
Customer enters installation information;
If this is a valid product image identifier
then retrieve related information
for the specified software
product image
else give a message of "unknown
software product";
End.
Perform all processing the same as Research and
Apply Service
Except
If F7 (Install) is pressed
then
Do
Display the Install Service Software
Product screen;
Follow the processing for Install Service
Software;
End;
End.
______________________________________
The processing exemplified by the pseudo code should be apparent to those skilled in the art, in view of the flow diagram and discussion above, without further explanation. After the service request is validated and formatted, it is sent over the network to the service facility. When the service facility receives the service request details, it then performs the service request, as identified by the flow diagram box numbered 94 in FIG. 5. FIG. 16 is a data flow diagram comprising the diagram box numbered 94 shown at a next level of detail. The boxes containing the letter "D" followed by a number indicate a data file. Other flow diagram boxes indicate processes. In the first diagram box of FIG. 16 numbered 220, the service request details are received at the service facility, which manages the service requests. As indicated by the diagram box numbered 222, a history of the service requests received from the customer is maintained in the storage devices of the service facility. The flow diagram box numbered 224 indicates that research is performed by the research processor of the service facility to determine the list of needed fixes, also referred to as program temporary fixes (PTF) relative to the service request received from the customer. The diagram box numbered 226 indicates requisite information, and the box numbered 227 indicates information concerning PEs, PE fixes, and HIPERs, are used in performing the service research. The data flow diagram box numbered 228 indicates that node configuration file data comprising configuration details for a given product at a given customer remote location are received at the central site with the service request details. The FIG. 16 flow diagram also indicates that a configuration is updated by receiving from a second processing step numbered 230, the results of the service application. That is, in managing the service request, the processing step represented by the flow diagram box numbered 230 is to apply the service to a specified computer program product and to incorporate the applicable configuration files into the serviced product. The flow diagram box numbered 232 represents the software product base code that never changes and is identified as "VM Base" data. The unchanging code provides a baseline, or reference, to which subsequent fixes can be applied. Thus, the unchanging code is used as a base on which to build serviced product. The flow diagram box numbered 233 represents the PTF repository of program fixes. FIG. 16 indicates the VM Base files and the PTF files are provided to a service routine identified as "CSX" and represented by the flow diagram box numbered 234. In addition, the flow diagram box numbered 236 indicates that the node service history at the remote location is updated as part of the application of the service in the box numbered 230. The flow diagram box numbered 238 represents the product files being updated and represents the source code to which changes are applied. As noted above, the source code is not resident at the remote location and is kept only at the service facility at the central site. The flow diagram box numbered 240 indicates the customer-defined product image information is used in applying the service to the computer program product. In this way, the service is applied in accordance with the desires of the remote location customer. It should be apparent that such information also is needed by, and is provided to, the processing step represented by the flow diagram box numbered 242, which indicates that the installation request is prepared and sent. It also should be apparent that such information is needed by, and is provided to, the processing represented by the flow diagram box numbered 224. Destination node information is provided in the processing step numbered 244. Finally, a service report is prepared at the flow diagram box numbered 246 and is a summary of the service research and installation. The processing steps followed by the system corresponding to the data flow diagram of FIG. 16 will be better understood with reference to the following pseudocode. First, the processing of the flow diagram box numbered 220 is exemplified as follows:
______________________________________
If a request is received
then
Do
Examine the request and determine
the request type;
Coordinate execution of each request
based on the nature of the request;
______________________________________
The next portion of pseudo code further illustrates the processing of the flow diagram box numbered 220 in formatting a research request, which is provided to the processing represented by the box 224:
______________________________________
If the request is for Research
then
Do
Format a research request;
Place a list of needed PTF's
in the request;
Identify the parameters for
performing research;
Send the research request;
Wait for search results and process
other requests in the interim;
If the search results arrive in a
predetermined reasonable
amount of time
then
Do
Check for problems
including was the report
created, is it a valid
report, is there
information in the report
indicating problems;
If problems exist
then detail problems in
a request report;
else detail status information
in a request report;
If the research request report
was created
then send research request
report to requestor
else tell requestor problems
with fulfilling request;
End;
End.
______________________________________
The next section of pseudo code further illustrates the processing in changing the data structures corresponding to the boxes 226 and 227 of FIG. 16:
______________________________________
For each PTF in the list of requested PTFs:
Do
Identify all requisite service as indicated
either at the time of the request or
in the product image profile (default),
where an interactive request overrides
the profile;
End.
Repeat the above for all newly identified PTFs
until no more identified (requisites, PE Fixes,
PEs, Open PEs) exist.
Identify all HIPERs if specified either at request
time or in customer's product image profile;
If the list is "ALL" or a specific level is indicated
then perform the appropriate research for
the matching PTFs.
______________________________________
The processing exemplified by the pseudo code above should be apparent to those skilled in the art, in view of the flow diagram and discussion above, without further explanation. The processing steps followed by the service facility in performing service research should be well-known to those skilled in the art without further explanation. Moreover, it should be understood that the exact implementation of the research request is not critical to the function of the system. Rather, the advantage provided by the preferred embodiment of the invention is in providing the same research request format, as the system designer may choose it to be, so that the software maintenance function can be performed across different platforms and programs with the same format and therefore the same interface. Nevertheless, the processing steps performed in the flow diagram box numbered 220 in generating a service envelope request to the CSX box numbered 234 is exemplified by the following pseudo code:
______________________________________
If the request is for an envelope of service files
then
Do
Examine the service history
database (D7) to determine
what service already has been
applied to the specified
software product; the
unapplied PTFs will be placed
in the request;
Format a service envelope
generation request;
Place a list of unapplied PTFs
in the request;
If the envelope is for the
requestor
then list the requestor as the
target
else list the intended service
application program as the
target; this is determined by
examining a profile listing
where the service application
programs are and by
determining which ones are
not busy;
Send the service envelope generation
request;
Wait for the search results (process
other requests in the interim);
If the search results arrive in a
predetermined reasonable
amount of time
then
Do
Check for problems including
was the report created, is
it a valid report, is there
information in the report
indicating problems;
If problems exist
then detail problems in a
request report;
else detail status information
in a request report;
If the research request report
was created
then send envelope request
report to requestor;
End;
End.
______________________________________
The next section of pseudo code exemplifies the processing carried out in the box 220 for generating service request information, which is provided to the processing of box 230:
______________________________________
If the request is for service application
to a product
then
Do
Format a service application request;
include the service envelope
request information;
include the product name, image,
and the like;
Send the service application request;
Wait for search results (process
other requests in the interim);
If the search results arrive in a
predetermined reasonable
amount of time
then
Do
Check for problems
including was the service
history updated, are all
status indicators positive,
is there information in
the report indicating
problems;
If problems exist
then detail problems in
a request report;
else detail status information
in a request report;
End;
End.
______________________________________
The next section of pseudo code further illustrates the processing described above in connection with the changes to the data in box 240:
______________________________________
If the request is for Add/Update/Delete of Customer Product
Image profile
then
Do
Add/Update/Delete the image profile
as request indicates;
If the image is already there
then notify the customer;
Link/Access the resources containing
the profiles;
For an Add, create these resources;
For a Delete, erase these resources;
Wait for results (process other requests
in the interim);
If the results arrive in a predetermined
reasonable amount of time
then
Do
Check for problems including
did the Add/Update/Delete
complete, is the resulting file
in the correct format;
If problems exist
then detail problems in a
request report;
else detail status information
in a request report;
End;
End.
______________________________________
The next section of pseudo code relates to the changes in data illustrated by the flow diagram box numbered 228:
______________________________________
If the request is for Add/Update/Delete of
Product Configuration files
then
Do
Add/Update/Delete the configuration
files as request indicates;
If the file is already there
then notify the customer;
Wait for results (process other requests
in the interim);
If the results arrive in a
predetermined reasonable amount
of time
then
Do
Check for problems including
did the Add/Update/Delete
complete, is the resulting
file in the correct format;
If problems exist
then detail problems in
a request report;
else detail status information
in a request report;
End;
End.
______________________________________
The next section of pseudo code relates to the processing of boxes 222 and 246 of FIG. 16:
______________________________________
Complete (generate) the Request Report and
Update the Logs;
Update the Service Requests Database;
Update the Service Reports Database;
Send the request report to the requestor;
Wait for next request.
______________________________________
The processing exemplified by the pseudo code above should be apparent to those skilled in the art, in view of the flow diagram and discussion above, without further explanation. The processing steps followed by the service facility in applying the service to a particular program software product should be well-known to those skilled in the art without further explanation. Moreover, it should be understood that the exact implementation of the service application is not critical to the function of the system. Rather, the advantage provided by the preferred embodiment of the invention is in providing the same service request format, as the system designer may choose it to be, so that the software maintenance function can be performed across different platforms and programs with the same format and therefore the same interface. Nevertheless, the processing steps performed in the flow diagram box numbered 230 in applying the service to a program software product is exemplified by the following pseudo code:
______________________________________
Apply Service to Specified Software Product:
Compare the list of service in the envelope to
what has been applied to this image of the
product;
If all of the requested service has been applied
then stop and record this information (no
need to proceed);
Coordinate the following activities based on
the status of each activity (Note: through
the following steps no error stop processing
and report error):
Set up the product servicing environment;
Access code listed in the customer image
of the product;
Notify the requestor;
While service is available and no
errors have occurred
Do
Receive the service envelope to the
customer image of product
repository locations;
Update the Service History;
Notify the requestor;
Apply the serviced parts to the
customer image of product;
Re-apply Modifications;
Update the Service History;
Notify the requestor;
Build the serviced customer image of
product;
Re-build with modifications
included;
Update the Service History;
Notify the requestor;
End.
Examine all logs for errors and report any
warnings or errors.
______________________________________
The processing exemplified by the pseudo code should be apparent to those skilled in the art, in view of the flow diagram and discussion above, without further explanation. After the service request is performed, the next step indicated by the flow diagram box numbered 100 in FIG. 5 is to install the customer required service files. The details of this process are illustrated in the data flow diagram of FIG. 17, which shows the serviced customer required files being received at a process represented by the flow diagram box numbered 302, which indicates that the production disk is linked based on the service request. The next step, as indicated by the flow diagram box numbered 304, is to unpack the serviced customer required files, which have been received over the network. The next step is to take the unpacked customer required production files and place or install them at the customer remote location, as represented by the flow diagram box numbered 306. This results in the newly created customer environment, which is incorporated into the direct access storage devices at the customer remote location, as represented by the flow diagram box numbered 308. In an alternative construction, the processing of the flow diagram box numbered 304 can include accessing the central site data base via a network connection to perform the installation otherwise performed by the box numbered 306. Finally, FIG. 17 indicates that the customer also receives the service request result report from the service facility. The processing steps followed by the service facility in installing a software product on the remote location system should be well-known to those skilled in the art without further explanation. Moreover, it should be understood that the exact implementation of the product installation is not critical to the function of the system. Rather, the advantage provided by the preferred embodiment of the invention is in providing the same service request format, as the system designer may choose it to be, so that the software maintenance function can be performed across different platforms and programs with the same format and therefore the same interface. Nevertheless, the processing steps performed in the installation of the software product are exemplified by the following pseudo code: Install a Specified Software Product on a Customer System
______________________________________
Look for an installation request;
If an installation request is found
then look for the serviced software product
files that are the delta between what is
currently installed and what is new on
the either serviced or modified version
of the product.
If the serviced software product files (delta) are
found
then Link/Access the product resources
based on request;
Unpack the delta files;
Add/update/replace the delta files over
the existing files;
Activate if indicated
(the request should specify the mode of
installation either into production
or in test mode).
______________________________________
The system described above includes a central site of a network that first receives service requests, then references configuration files, base product files, and service files at the central site, and lastly returns requested service to requesting customers at remote locations. As noted above, however, the central site can be implemented in accordance with a distributed processing architecture in which the processing of the central site is not confined to a single processor, such as is illustrated in FIG. 1. FIG. 18 is a block diagram representation of a computer network system 400 constructed in accordance with the present invention and having a distributed processing architecture. Comparison of the FIG. 1 system with the system illustrated in FIG. 18, in which like reference numerals refer to like structures, should make apparent the similar processing. In the FIG. 18 distributed system, remote locations 12, 14 again communicate with a central processing site 16 over a network 18. The remote locations include a CPU 20, RAM 22, input/output devices 24, and a DASD 26. If desired, the remote location DASD 26 can contain product-specific configuration files, depending on the implementation selected and in accordance with the customer-defined product image. In the distributed system, the central site effectively comprises a central node processing site and one or more slave node processing sites communicating over the network and sharing the central site DASD 32, which is a data repository. FIG. 18 shows one of the slave processing sites 402 and illustrates that each slave processing site includes a processor 20, RAM 22, input/output devices 24, and a high-speed disk drive unit 26 to facilitate communication and control. FIG. 18 also shows that the slave processing site includes a service facility 34 like that shown at the central site 16. Thus, the service facility of the slave site 402 includes a rebuild processor 36, service apply processor 38, and a service research processor 40. A slave node unit 404 provides an interface to the network. In the FIG. 18 distributed system, all service requests are directed to the central node control processor and network interface unit 28 at the central node processing site 16. The central node processor determines which of the service facilities should be given the task of handling the service request, either the service facility at the central site 16 or at a slave site 402. This determination is typically made according to which facility is not currently busy, but could depend on other implementation parameters as well, such as geographic location, specialized site capabilities, or others that will occur to those skilled in the art. The processing of a service request, whether at the central site 16 or at a slave site 402, follows the processing steps described above in conjunction with the illustrations of FIGS. 2-17. For example, the processing step of the central node determining where to send a service request corresponds to the management processing represented by the FIG. 16 flow diagram box numbered 220. FIG. 18 shows that the slave node unit 404 communicates directly with the DASD 32 of the central site 16. Thus, the slave site has ready access to the configuration files, service history files, and other data described above in connection with FIGS. 2-17 as residing at the central site. This direct access permits a seamless interconnection between the central site and the slave site in which service processing as between the central site 16 and a slave site 402 is transparent to the customer. That is, a customer at a remote location 12, 14 is completely unaware as to whether a service request sent by the customer to the central site is being handled by the central site service facility or is actually being handled by a slave site service facility. More particularly, if a service request is sent from the central node 28 to a slave node 404, then the tasks of service research, service application, and product rebuilding and related tasks of service processing can be performed by the slave site service facility processors in accordance with the customer request. Any central data files needed by the slave site processors 36, 38, 40 can be directly accessed from the central site DASD 32 and temporarily copied into the slave site storage 30 for processing. In this way, the central site DASD remains the solitary repository of archival data needed for processing service requests. Alternatively, copies of some of the central site files, such as the unchanging VM base files, might be kept at the slave sites because such data will not be changed at the slave site. As described above, the distributed network architecture implementation provides a system in which the processing of remote location service requests is moved out from a single central site and is distributed across multiple service facilities under the control of a central node. In either implementation, the single central site processing of FIG. 1 or the distributed processing of FIG. 18, the software maintenance task can be performed through a common interactive customer interface through which service request are received, formatted, performed, and returned to the requesting customer in executable form. Thus, the computer network systems described above include a central service facility that operates with a front end that permits a remote location customer to request service and receive updated executable code back from the service facility. The front end provides a consistent interface across the different software platforms of the network. The customer can easily initiate servicing of a program by composing a service request through the front end. The customer can specify a range of optional operations to be performed at the central site, including service research, requesting service, applying service, and installing fixes from the central service facility to the remote location. The requested service can be performed at the central site and the results provided back to the remote location customer, or the service and base product can be returned for application at the remote location. The source code for the program product being updated advantageously resides only at the central service facility. All code is returned to the remote location over the network in an executable form. The present invention has been described above in terms of a presently preferred embodiment so that an understanding of the present invention can be conveyed. There are, however, many configurations for network software maintenance systems not specifically described herein but with which the present invention is applicable. The present invention should therefore not be seen as limited to the particular embodiment described herein, but rather, it should be understood that the present invention has wide applicability with respect to network maintenance systems generally. All modifications, variations, or equivalent arrangements that are within the scope of the attached claims should therefore be considered to be within the scope of the invention.
|
Same subclass Same class Consider this |
||||||||||