Browse Prior Art Database

Automated validation of modifications to existing data structures that adversely affect offsets of data items within the structure Disclosure Number: IPCOM000199640D
Publication Date: 2010-Sep-13
Document File: 4 page(s) / 83K

Publishing Venue

The Prior Art Database


An automated means of validating changes to control blocks to ensure that their structures remain comparable after any changes have been made to them.

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

Page 1 of 4

Automated validation of modifications to existing data structures that adversely affect offsets of data items within the structure

Large and complex systems are composed of many thousands of separate modules (programs). These make use of many tens of thousands of data structures. In the main, these are declared in programming languages or assembler, and resolve to mappings of the structure of the data areas used by the programs. Data structures can be provided in languages such as COBOL or C. Often there is the need to declare the same data structure mapping in more than one programming language, since it may be referenced at run-time by programs written in a variety of languages. A typical requirement is to declare control blocks in both a high level programming language and assembler. There is an obvious requirement for the two structures to match, and resolve to the same field names, at the same offsets, for the same lengths of each field. If the control blocks are not directly equivalent, unpredictable results may well occur at run-time, and the code will almost certainly not function correctly.

    It is often the case that data structures are shared between multiple programs, and each program relies upon its copy of the structure to map over areas of memory and so reference shared storage in a consistent manner. If the programs are written in different languages the need for the language-specific structures to match each other is clear. However, there is another consideration regarding individual structures that are included within many different programs of the same language, for example assembly copybooks.

    When developing code, it is typically the case that the development build environment will regenerate all the parts that are affected by the changes being made. Applications can be completely rebuilt on a regular basis during the development cycle, so all the parts are reassembled/recompiled regularly, and changes made to shared structures are quickly picked up across all the product. This model does not apply to the service stream however,

where for practical

reasons a change to one or more parts cannot result in the regeneration and reshipment of the entire product. This practical restriction means that changes to shared structures such as copybooks must be made in compatible ways. Typically, this means that new fields added to the structures are inserted at the end of the structures. By doing this, the existing offsets of the old fields in the structure are not affected by the change, and other modules which reference these fields in the shared structure do not need to be reassembled/recompiled and reshipped as part of the change made by the service organisation (e.g. as a fix for a problem).

    There is nothing to force a programmer to follow this good programming practice however, and it is possible for fields in a structure to be added, changed, or removed. As long as all the modules which reference the changed structure...