Abstract:
An update management system provides access to software updates (patches and upgrades) and to an update catalog server. The catalog server includes a chronology generator. When a request for an update family tree for a target update is received, the chronology generator accesses an index to find the database and record number for the target update. The record is retrieved, indicating updates superseded by the target update and updates superseding the target update. Records for the superseded and superseding updates are, in turn, retrieved. The process is iterated until there are no further superseding and no superseded updates indicated. The succession relations indicated in the retrieved records are arranged into a family tree for the target patch. The family tree can be used (along with dependency data) to help determine an update for a given workstation that optimizes performance and compatibility. Optionally, the family tree can be used to generate an update state list to assist in the optimization.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    The present invention relates to computers and, more particularly, to the management of updates for computer software. A major objective of the present invention is to provide for optimally selecting updates for a given hardware/software configuration.  
           [0002]    Much of modern progress is associated with the increasing prevalence of computers. Computers include one or more processors and memory. The memory stores data and instructions; a processor manipulates data by executing instructions. Instructions are organized into programs to perform meaningful work. While the first programs were quite simple, the size and complexity of the most sophisticated programs have increased exponentially.  
           [0003]    Almost inevitably, it becomes necessary or desirable to modify a program: 1) to correct a defect, 2) to address a compatibility issue with other software or hardware, 3) to improve performance, and/or 4) to add features. (If no new features are added, the update is called a “patch”; if new features are added, the update is called an “upgrade”.) Instead of replacing an entire program, the program can be updated. Updating can involve actually changing the instructions in a monolithic program. However, partly to facilitate updates, programs are often configured as a group of files so that an update can simply involve a replacing a preexisting file with an update file.  
           [0004]    Update installation can be problematic if the update renders a program incompatible with a program that was previously compatible. Typically, “uninstall” programs are available to restore the pre-update state of the computer. However, the objective of the update is then not accomplished.  
           [0005]    Often, available updates are not installed. A user may avoid changing a system that is serving its purpose well; or a user may not be aware of an update&#39;s availability. In such cases, available updates can be superseded one or more times before a user tries to update. This can present a choice of updates. Normally, the most recent update is installed. However, if the most recent update is unsuccessful, e.g., raises new compatibility issues, optimizing the selection of updates can be problematic.  
           [0006]    Update selection can be difficult for a number of reasons. In the first place, one update may be dependent on another update having been installed. In addition, update successions can be complex since one update can supersede more than one prior update. What is needed is a way to improve update selection when there is a complex succession of updates.  
         SUMMARY OF THE INVENTION  
         [0007]    The present invention provides an update management system including an update chronology generator. In response to a request via a network received at an input of the system, the update chronology generator generates a chronology regarding a given target update. The chronology is generated by accessing a database record for the target update, as well as database records for updates indicated in the target-update record as being succeeded by the target update. The update management system can access a set of one or more databases including an internal database or an external database or both. Preferably, the chronology extends back to the “base” program, and also extends forward to indicate updates that succeed the target update. 
       
    
    
       [0008]    The update chronology can be in the form of an update family tree or an update state sequence. In either case, the chronology can be used as a reference when troubleshooting a system. For example, where both an original update state and a fully updated state of a program cause compatibility problems, the update chronology presents intermediate states that may avoid these compatibility problems. When used in conjunction with update dependency information, the update chronology can help in removing unnecessary files from a computer—freeing storage capacity and improving performance. These and other features and advantages of the invention are apparent from the description below with reference to the following drawings.  
       BRIEF DESCRIPTION OF THE DRAWINGS  
       [0009]    [0009]FIG. 1 is a block diagram of an update management system in accordance with the present invention.  
         [0010]    [0010]FIG. 2 is a flow chart of a method of the invention practiced in the context of the system of FIG. 1. 
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0011]    In accordance with the present invention, an update management system AP 1  comprises an update catalog server  10  and update files  11 . Update catalog server  10  includes a chronology generator  13 , a dependency generator  15 , an update index  17 , and a local update database  19 . The chronology generator and the dependency generator share a common interface  20  for accessing local update database  19 , as well as external databases. Update management system AP 1  is connected to a network  21  at a network port  22 , on which two update databases  23  and  25  reside. A remote workstation  31  on a remote network  33  communicates with update management system AP 1  via an inter-network link  35 .  
         [0012]    The invention provides for use of one or more databases; each of which can be either local (part of update management system AP 1 ) or remote. Normally, when there are plural databases, they are mutually exclusive as to target updates represented. Alternatively, a local database can be used as a cache to improve performance.  
         [0013]    Typically, requests are made to update management system AP 1  from a remote workstation, such as remote workstation  31 , and are received by update management system AP 1  at network port  22 . The requests are made for updates to a “base” program, typically residing on the remote workstation. The base program can be an operating system, a utility program, an application program, etc. The updates can be patches—which fix problems or improve performance without adding features, or upgrades, which add features, or both.  
         [0014]    The request can be directed toward finding an appropriate update for a given computer system. To this end, the request can include information regarding the hardware configuration, operating system, and co-existing programs on the workstation. Alternatively, a request can concern a particular update. For example, a dependency request can be seek a listing of “prerequisite” files required by the target update.  
         [0015]    Of particular interest herein, are “chronology” requests for an update chronology for a target update. For example, a chronology of patches leading up to a target patch from the initial release of the base program. Alternatively, the chronology can specify updates that supersede the target update. Most useful, is a chronology that indicates an entire succession from the base program, through the target update, to its most recent successor.  
         [0016]    The response to a chronology request (command line: “$ pft PHKL — 8000”, where “PHKL — 8000” is a hypothetic target update) can be a family tree of the form:  
                                                                                                                                             PHKL_9000                PHKL_8000                PHKL_6000                |   PHKL_3000                |   |   PHKL_1000                |   PHKL_4000           |   PHKL_5000                |   PHKL_2000                PHKL_7000                      
 
         [0017]    Non-indented updates on succeeding lines are successor updates. In this case, PHKL — 8000 has been succeeded only by PHKL — 9000. If the latter had been succeeded, its successor would have been listed on the line above PHKL — 9000 and with the same indent. It is assumed herein that a target update can only be directly succeeded by one update. Hence, successor updates can be displayed linearly. If it is permitted for a single target update to have multiple direct successors, then the successor updates can be displayed in tree form, as are the predecessor updates.  
         [0018]    It is often the case that an update will in effect merge two or more of its predecessors. Hence, the chain of succession up to a target update can have a tree-type structure. Updates that have a common successor are aligned vertically in the report. For example, PHKL — 6000 and PHKL — 7000 are aligned, since they are both succeeded by PHKL — 8000. Likewise, PHKL — 6000 succeeds PHKL — 3000, PHKL — 4000 and PHKL — 5000. The report also indicates that PHKL — 3000 supersedes only PHKL — 1000, and PHKL — 5000 supersedes only PHKL — 2000. All updates for which no predecessor is indicated are patches to the base program.  
         [0019]    Several attributes can be displayed in the report. The report can include a one-line description for each update. In addition, the report can indicate: if an update has been recalled, whether it has dependencies, whether it is critical, and whether it has been reposted. The information included in the report can be determined by selections made in the request itself.  
         [0020]    A method M 1  of the invention is flow-charted in FIG. 2. An update chronology request is received by update management system AP 1  at step S 1 . Update catalog server  10  handles this request. In particular, chronology generator  13  accesses update index  17  to determine the location of an update record for the target update at step S 2 . Update index  17  lists updates alphabetically and indicates a database and a record number for each update listed therein. The database can be local database  19 , considered part of update catalog server  10 , or it can be an external database, such as databases  23  and  25  at remote nodes on network  21 .  
         [0021]    At step S 3 , chronology generator  13  accesses the database and target record identified in index  17 . For small systems with not too many updates, index lookup step S 2  is not necessary. However, the larger the number of records and databases, the more time is saved using the index in step S 2 .  
         [0022]    The target record accessed in step S 3  must identify any updates directly superseded by the target update. Preferably, any immediate successor to the target update is also identified. Updates can be identified by name, or by database (if more than one) and record number, as they are in index  17 . Preferably, both name and database locations are given. The records can contain other information, notably, any prerequisite updates that are required to be installed if the target update is to function. (Note that dependency requests are normally handled by dependency generator  15 ).  
         [0023]    At step S 4 , the records for any indicated immediate predecessors, step S 4 A, and for any indicated immediate successor, step S 4   b,  are accessed. If the target record does not indicate the database locations of these records, chronology generator  13  can look up the locations in index  17 . Preferably, however, the target record does indicate database locations for the immediate successor and predecessors so this index step can be omitted for higher performance. If, at step S 4 A, the predecessor records indicate further predecessors update, step S 4 A is repeated. When, in step S 4 A, the only predecessor is the base program, the iteration stops. Likewise, if at step S 4 B, a further successor update is indicated, step S 4 B is iterated until a successor record is found with no successor update indicated.  
         [0024]    Once all the records indicated in step S 4  are gathered, chronology generator  13  generates a family tree, as indicated in the example for PHKL — 8000 above. Optionally, a state list can be generated at step S 5  from the family tree. (Alternatively, the state list can be generated directly, without first generating a family tree.) The state list can indicate a series of workable update states. The following state list corresponds to the PHKL — 8000 family tree generated above, given that update names reflective the order in which they were introduced.  
                                             State List: PHKL_8000                Update   Co-existing Updates                       (0)   (Base program)           PHKL_1000   (Base program)           PHKL_2000   PHKL_1000           PHKL_3000   PHKL_2000           PHKL_4000   PHKL_2000 &amp; PHKL_3000           PHKL_5000   PHKL_3000 &amp; PHKL_4000           PHKL_6000           PHKL_7000   PHKL_6000           PHKL_8000           PHKL_9000                      
 
         [0025]    The family tree or the state table can be used in upgrading a system when the most recent updates cause problems. For example, assume workstation  31  had PHKL — 1000 and PHKL — 2000 installed at its last update. Also, assume a user for workstation  31  is advised to upgrade to PHKL — 8000 for higher performance. The user performs a chronology request and discovers that PHKL — 8000 has been superseded by PHKL — 9000. The user downloads and installs PHKL — 9000 from update manager system AP 1 . In addition, the user can issue a dependency request handled by dependency generator  15  to ensure all updates required by PHKL — 9000 are installed.  
         [0026]    Assume that after proper installation, PHKL — 9000 causes compatibility problems with a key application program. The user uninstalls update PHKL — 9000, returning workstation  31  to its previous state. Instead of choosing only between the most recent update and the most-recent pre-update state, the family tree and state table present a number of intermediate alternatives. The user can work forward or backward through the chronology until the optimal state is found. For each state, dependency checks can be performed for each installed update to ensure that the proper dependency updates are also installed. Thus, the update catalog manager, in particular, the chronology generator, facilitates update optimization.  
         [0027]    In addition, the chronology generator can be used to assist removal of unused updates. The dependencies of the replaced updates can be compared with the dependencies of the newly installed updates, and the dependencies that are no longer used can be subject to a reverse dependency analysis. If the reverse dependency analysis turns out negative, the former dependencies can be removed.  
         [0028]    While the invention applies generally to updates, it has been implemented in the following patch-family-tree tool (pft) for patches. The following command-line syntax with switches can be used.  
         [0029]    Usage: pft −o &lt;os&gt; [−p &lt;platform&gt;] [−s &lt;servers&gt;] [−v] [−l] [−r] [−e] [−c] [−a] [−y] [−z] [−i &lt;number_of_spaces&gt;] &lt;patch_name_or —number&gt;   
         [0030]    where,  
         [0031]    &lt;os&gt;=operating system version  
         [0032]    examples: 10.20 11.00 11.04  
         [0033]    &lt;platform&gt;={ 700 |800 } (ignored for 11.X)  
         [0034]    &lt;servers&gt;=system1:port1[,system2:port2] [, . . . ] 
         [0035]    −v=verbose (print one-line descriptions)  
         [0036]    −l=show recalled patches  
         [0037]    −r=show released patches  
         [0038]    −e=show patches with dependencies  
         [0039]    −c=show critical patches  
         [0040]    −a=show reposted patches  
         [0041]    −y=show superseded patches (“older”)  
         [0042]    −z=show superseding patches (“newer”) (default is to show both)  
         [0043]    &lt;number_of_spaces&gt;=to indent each generation (default and min=1; max=8)  
         [0044]    The OS is specified with the −o option, and the hardware is specified with the −p option. The hardware platform is not required for any HP-UX 11.X releases.  
         [0045]    The tool can be directed to a particular catalog server, or servers, using the −s option. This will override the default value, and any value(s) specified with the CATALOG_SERVERS environment variable.  
         [0046]    A patch family tree is generated for a single patch and it must be specified on the command line.  
         [0047]    The number of spaces in the indentation can be adjusted using the −i option. Increasing the number of spaces can improve readability of the output report.  
         [0048]    The report can include one-line descriptions of each patch, by specifying the −v option, for “verbose” output.  
         [0049]    By default, the report will contain patches that are both older than (superseded by) and newer than (supersede) the specified patch. Only the older patches are shown when the −y option is used. Only the newer patches are shown when the −z option is used.  
         [0050]    Various attributes of the listed patches can be displayed using several options. If the patch has the requested attribute, a flag will be included in the output listing.  
                                           Output           Option   Flag   Description                   -l   RCL   Patch has been recalled.       -r   REL   Patch has been released in a Support Plus or               Extension Software bundle.       -e   DEP,   Patch has patch dependencies and/or other           ODEP   dependencies.       -c   CRIT   Patch is flagged has containing critical defect               fixes.       -a   REP   Patch was reposted.                  
 
         [0051]    This following example shows the use of the −v (verbose) option and the −i (indentation) option, for the command line beginning with the “$”−sign below. The specified patch supersedes five patches: PHKL — 14070, PHKL — 14034, PHKL — 13676, PHKL — 13644, and PHKL — 13328. PHKL — 14070 supersedes one patch, PHKL — 13858, which supersedes PHKL — 13552, which supersedes PHKL — 13081.  
         [0052]    $ pft −v −o 11.00 −i 3 −y 14088  
         [0053]    # 
         [0054]    # Patch Family Tree  
         [0055]    # PHKL — 14088 HP-UX Performance Pack cumulative patch  
         [0056]    # OS: 11.00  
         [0057]    # 
         [0058]    # Only superseded patches are displayed.  
         [0059]    # Superseded patches are indented to the right  
         [0060]    # and go down.  
         [0061]    # Patches aligned in a vertical column are in the  
         [0062]    # same “generation”.  
         [0063]    # 
         [0064]    PHKL — 14088 HP-UX Performance Pack; cumulative patch  
         [0065]    PHKL — 14070 Tape, IOCTL, FC fixes cumulative patch  
         [0066]    | PHKL — 13858 Tape and IOCTL fixes cumulative patch  
         [0067]    | PHKL — 13552 Large record, seismic tape support  
         [0068]    | PHKL — 13081 PCI EPIC arbitration timeout panic  
         [0069]    PHKL — 14034 SHMEM_MAGIC Perf, Mem window patch  
         [0070]    | PHKL — 13810 Memory Windows; pstat; space id  
         [0071]    | | PHKL — 13278 User stack limits on 32/64 bit  
         [0072]    | | PHKL — 13193 Fix panic:hdl_alloc_spaceid  
         [0073]    | | PHKL — 13052 pstat(2) number of procs limit  
         [0074]    | PHKL — 13646 Poor perf with SHMEM_MAGIC programs  
         [0075]    PHKL — 13676 Fix C program error in badalignment( )  
         [0076]    PHKL — 13644 Fix for panic in wait1( )  
         [0077]    PHKL — 13328 Fix for panic in proc_close( )  
         [0078]    The following example shows the use of the −y (display older patches) and the −r (denote recalled patch) options. Only patches that are superseded by the specified patch, PHCO — 12922, are displayed. The patches that supersede PHCO — 12992 (PHCO — 12923,  
         [0079]    PHCO — 14842, and PHCO — 16591) are not displayed. Note the two recalled patches, PHCO — 11909 and PHCO — 11908, flagged with the “RCL” keyword.  
         [0080]    $ pft −v −o 10.20 −p 800 −y −r 12922  
         [0081]    # 
         [0082]    # Patch Family Tree  
         [0083]    # PHCO — 12922 fsck —vxfs( 1M) cumulative patch  
         [0084]    # OS: 10.20  
         [0085]    # PLATFORM: 800  
         [0086]    # 
         [0087]    # Only superseded patches are displayed.  
         [0088]    # Superseded patches are indented to the right  
         [0089]    # and go down.  
         [0090]    # Patches aligned in a vertical column are in the  
         [0091]    # same “generation”.  
         [0092]    # RCL=Recalled patch  
         [0093]    # 
         [0094]    PHCO — 12922 fsck —vxfs( 1M) cumulative patch  
         [0095]    PHCO — 11909 RCL fsck_vxfs(1M) cumulative patch  
         [0096]    PHCO — 11908 RCL fsck_vxfs(1M) cumulative patch  
         [0097]    PHCO — 11223 fsck_vxfs(1M) cumulative patch  
         [0098]    PHCO — 10965 fsck_vxfs(1M) cumulative patch  
         [0099]    PHCO — 9396 fsck − vxfs(1M) fix for file system  
         [0100]    The recall notices for the “recalled” patches can be viewed using a query tool. The query tool, indicated by the abbreviation “qpc”, is used to send a message to the catalog server. Quite often this message takes the form of a query. The query tool reads a message from its command line arguments, sends it to the specified server, waits for the answer, and displays.  
         [0101]    $ qpc 11909 Warn  
         [0102]    PHCO — 11909:  
         [0103]    Warn: 97/10/21—This patch has been recalled. —Patch PHCO — 11909 can cause OmniStorage A.02.20 filesystems to be unmountable on HP-UX 10.20. The problem is . . .  
         [0104]    The following example shows the use of the −z (display newer patches) option, and the −e (display patches with dependencies) option. Note that each of the patches that supersede PHCO — 11909 has a dependency on at least one other patch.  
         [0105]    $ pft −v −o 10.20 −p 700 −z −e 11909  
         [0106]    #  
         [0107]    # Patch Family Tree  
         [0108]    # PHCO — 11909 fsck_vxfs(1M) cumulative patch  
         [0109]    # OS: 10.20  
         [0110]    # PLATFORM: 700  
         [0111]    # 
         [0112]    # Only superseding patches are displayed.  
         [0113]    # Superseding patches are indented to the left  
         [0114]    # and go up.  
         [0115]    # Patches aligned in a vertical column are in the  
         [0116]    # same “generation”.  
         [0117]    # DEP =Patch has dependencies on other patch(es)  
         [0118]    # ODEP =Patch has other dependencies  
         [0119]    # 
         [0120]    PHCO — 16591 DEP fsck_vxfs(1M) cumulative patch  
         [0121]    PHCO — 14842 DEP fsck_vxfs(1M) cumulative patch  
         [0122]    PHCO — 12923 DEP fsck_vxfs(1M) cumulative patch  
         [0123]    PHCO — 12922 DEP fsck_vxfs(1M) cumulative patch  
         [0124]    PHCO — 11909 DEP fsck_vxfs(1M) cumulative patch  
         [0125]    The patch dependencies can be viewed using the patch dependency analysis tool “pdat”, as implemented by patch dependency generator  15 .  
         [0126]    $ pdat −v −o 10.20 −p 700 16591  
         [0127]    PHCO — 18563 LVM commands cumulative patch  
         [0128]    PHKL — 16750 SIG_IGN/SIGCLD,LVM,JFS,PCI/SCSI cum. patch  
         [0129]    PHKL — 16959 Physical dump devices configuration patch  
         [0130]    PHKL — 17857 Fix for mount/access of disc sections  
         [0131]    PHKL — 20610 Correct process hangs on ufs inodes  
         [0132]    PHKL — 21594 VxFS (JFS) mount, fsck cumulative patch  
         [0133]    PHKL — 21660 lo_realvfs panic fix, Cum. LOFS patch  
         [0134]    PHNE — 19937 cumulative ARPA Transport patch  
         [0135]    The following example shows the use of the −c (flag critical patches) option for a patch family tree command. Patches which have been released with Support Plus and/or Extension Software are flagged when the −r option is specified. PHCO — 14198 is a critical patch, and both PHCO — 14198 and PHCO — 13131 have been released in a Support Plus and/or Extension Software bundle.  
         [0136]    $ pft −v −o 11.00 −i 3 −c −r 14198  
         [0137]    # 
         [0138]    # Patch Family Tree  
         [0139]    # PHCO — 14198 crashutil(1M) cumulative patch  
         [0140]    # OS: 11.00  
         [0141]    # 
         [0142]    # Both superseded and superseding patches are  
         [0143]    # displayed.  
         [0144]    # Superseded patches are indented to the right  
         [0145]    # and go down.  
         [0146]    # Superseding patches are indented to the left  
         [0147]    # and go up.  
         [0148]    # Patches aligned in a vertical column are in the  
         [0149]    # same “generation”.  
         [0150]    # REL=Patch released with Extension Software and/or  
         [0151]    # Support Plus  
         [0152]    #  
         [0153]    # CRIT=Patch contains critical fixes  
         [0154]    PHCO — 14198 REL CRIT crashutil(1M) cumulative patch  
         [0155]    PHCO — 13131 REL crashutil(1M) cumulative patch  
         [0156]    Critical fix information for a patch, and all patches that it supersedes, can be viewed using qpctree:  
         [0157]    $ qpctree −f Crit 14198  
         [0158]    PHCO — 14198:  
         [0159]    Crit: PHCO — 14198::  
         [0160]    Yes  
         [0161]    CORRUPTION  
         [0162]    PHCO — 13131::  
         [0163]    No  
         [0164]    The following example shows the use of the −a (flag reposted patches) option. In this example, PHCO — 10576 has been reposted.  
         [0165]    $ pft −v −o 10.20 −p 800 −a 14967  
         [0166]    # 
         [0167]    # Patch Family Tree  
         [0168]    # PHCO — 14967 sar(1M) cumulative patch  
         [0169]    # OS: 10.20  
         [0170]    # PLATFORM: 800  
         [0171]    # 
         [0172]    # Both superseded and superseding patches are  
         [0173]    # displayed.  
         [0174]    # Superseded patches are indented to the right  
         [0175]    # and go down.  
         [0176]    # Superseding patches are indented to the left  
         [0177]    # and go up.  
         [0178]    # Patches aligned in a vertical column are in the  
         [0179]    # same “generation”.  
         [0180]    # REP=Patch was reposted  
         [0181]    PHCO — 14967 sar(1M) cumulative patch  
         [0182]    PHCO — 14228 sar(1) cumulative patch  
         [0183]    PHCO — 10576 REP sar(1) cumulative patch  
         [0184]    PHCO — 8820 sar(1M) patch  
         [0185]    The reposting notice can be viewed using qpc:  
         [0186]    $ qpc 10576 Repost  
         [0187]    PHCO — 10576:  
         [0188]    Repost: 98/04/20  
         [0189]    A problem was discovered with replacement patch PHCO — 14228. PHCO — 14228 breaks the Year 2000 compliance implemented in patch PHCO — 8820. PHCO — 10576 will be re-released until a replacement patch is available.  
         [0190]    As indicated earlier, the patch tools work as well for upgrades, so they are general to updates. The invention has industrial applicability to both hardware and software manufacturers, as it allows them to organize and distribute their updates both internally and to customers in a manner that optimizes updates for performance and compatibility. Other variations upon and modifications to the described embodiments are provided for by the present invention, the scope of which is defined by the following claims.