Browse Prior Art Database

Maintenance of Customizing Models

IP.com Disclosure Number: IPCOM000082363D
Original Publication Date: 1974-Nov-01
Included in the Prior Art Database: 2005-Feb-28
Document File: 3 page(s) / 16K

Publishing Venue

IBM

Related People

Brown, TN: AUTHOR [+2]

Abstract

In a complex customizing procedure, it is possible that more than 100 models and files must be altered whenever a maintenance update or change is made. Here, the use of update files which are carried through to the package builder rather than a normal brute force approach of maintenance, is shown in such a complex environment. The specific environment relates to the maintenance of program customizing models, wherein the models include a source model, national models translated into a local language from the source, and industry application models derived through a build block from a national model.

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

Page 1 of 3

Maintenance of Customizing Models

In a complex customizing procedure, it is possible that more than 100 models and files must be altered whenever a maintenance update or change is made. Here, the use of update files which are carried through to the package builder rather than a normal brute force approach of maintenance, is shown in such a complex environment. The specific environment relates to the maintenance of program customizing models, wherein the models include a source model, national models translated into a local language from the source, and industry application models derived through a build block from a national model.

Specifically, a file maintenance control program resolves each change to the source model as an add, delete, or both and creates a record there-for in an update file. The update file is then matched with a translate file for renumbering and with an old national model to produce a national update file. Once the translate file has been renumbered, a new national model can be generated.

The national update file is then matched with each package build block and the build blocks commands renumbered and executed, to determine the update records to be made active for the submodel. The control program records the switches involved in the active update records, to give the package builder an opportunity to review the changes that affect his package and make any further changes to his build block he may feel is appropriate. Only thereafter will the models be rebuilt. A more detailed view is as follows.

The creation of the source model, of a national translate file, or of a package build block uses a standard file load procedure. Similarly, a standard file maintenance procedure is used for a change to the source model by the development group, a change to a translate file by its translator, or a change to a package build block by its package builder.

When the package builder makes a change to a package build block, the only other file that is affected is the submodel generated from the build block. The submodel must be regenerated.

When the translator makes a change to the translate file, the national model is affected and the submodels generated from the national model are affected. These files must be regenerated. The package build blocks are not affected, because the translator cannot make functional changes.

When the development group makes a change to the source model, it is possible that all other files will be affected. Even though new national models and submodels can be regenerated, translate files and package build files cannot be. These must be synchronized with the new version of the source model before they can be used again. The illustration of update files shows how this synchronization is accomplished.

When changes are made to the source model, they must be reflected in all translate files so that new national models can be generated from the source model, and they must be reflected in all package...