Browse Prior Art Database

Automated cross-referencing of modified programs to ensure that all necessary parts are included in a service change to a product

IP.com Disclosure Number: IPCOM000199540D
Publication Date: 2010-Sep-08
Document File: 3 page(s) / 47K

Publishing Venue

The IP.com Prior Art Database

Abstract

Automation of the work of a change team programmer in determining which components are required in a software fixlist.

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

Page 1 of 3

Automated cross-referencing of modified programs to ensure that all necessary parts are included in a service change to a product

Software products can contain many thousands of separate programs (modules). During the lifetime of a release of the code, there is the need for a service team to provide corrective solutions to programming errors that are encountered by the users. Such changes are reported and fixed and solutions made available.

    It is quite common for a fixlist to contain more than one module in order to fix a reported problem. These modules may be tightly coupled, or may be independent of each other. The fix for an can therefore span multiple modules.

    Some modules need to be recompiled and reshipped when changes are made to other related programs. This is so they can pick up the changes made in the other modules. An example of this is when a module is written as a common collection of routines. This module is then included in one or more other modules. By way of example:

    DFHCMMN contains common routines which perform functions used by a number of other modules, and:

    DFH1111, DFH2222, DFH3333 and DFH4444 all include DFHCMMN, so that they can all make use of these common functions.

    Different library management systems have different approaches to adding parts into defect reports. Some rely upon the change team programmer to manually add in any parts that they want to change or recompile. Others have built-in cross-reference tables, so if one part is added, all the other parts which are in the same table are added in too. These tables are often produced by hand at the start of a release.

    If parts are omitted from these tables, or if they are not manually added into the defect report or fix by the programmer, then it is possible for a fix to only change a subset of the modules which should be recompiled as part of the change. In some circumstances this can lead to a serious error - the omitted parts will not have knowledge of the change, and may be incompatible at runtime as a result. To avoid this situation, library systems often implement the cross-reference tables described above. In addition, programmers have to take care when adding parts to their APARs to ensure that modules are not left out of fixlists in error. Both these approaches are not fool-proof, and omissions can still occur.

    Another problem which can be seen is if a change is made to a common routine in a module such as DFHCMMN (as above), which includes a call to another part of the product. The problem is that the common routine module often does not contain the declaratives necessary for a module to be able to compile domain calls. Instead, these declaratives are coded within the modules which use the common functions (DFH1111 through DFH4444 in the example above).

    If a new domain call is added to DFHCMMN by a fix, the associated parameter list declarations and working storage definitions need to be added to the modules which make use of the common rout...