Browse Prior Art Database

Predecessor Mapper

IP.com Disclosure Number: IPCOM000083579D
Original Publication Date: 1975-Jun-01
Included in the Prior Art Database: 2005-Mar-01
Document File: 3 page(s) / 46K

Publishing Venue

IBM

Related People

Conroy, ED: AUTHOR

Abstract

In an evolving product a continuous stream of changes is applied to the product's parts. In managing such a project, it is mandatory that for any version of a part the changes contained in that version must be determined. This is usually done by determining the chain of predecessor versions on which the subject version is based.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Predecessor Mapper

In an evolving product a continuous stream of changes is applied to the product's parts. In managing such a project, it is mandatory that for any version of a part the changes contained in that version must be determined. This is usually done by determining the chain of predecessor versions on which the subject version is based.

Historically this type of association has usually been done with a chain of pointers which connects the predecessor versions. This requires multiple I/O references to reference the chain, since each element on the chain must be read. In addition, in a decentralized environment involving multiple data bases, processing such a chain can be slow and complex to the point of impossibility if different links are in different data bases. It is also possible to keep a list of predecessor version numbers, but this requires considerable space if the list is long.

This method involves mapping the predecessor history into a segmented logical bit string. Each bit position corresponds to a previous version of the part. A "1" indicates that the corresponding version is in the subject version's base chain. A "0" indicates that the corresponding version is not in the subject version's base chain.

Each bit string segment is stored with an associated key field, e.g., as an occurrence in an IMS-like memory. The key fields are simply serial numbers corresponding to the associated segment's position in the logical string. Only segments containing one or more 1's are stored.

The algorithms for referencing the bit string are shown in Figs. 1 and 2 below. Fig. 1 shows the logic for creating a new version's bit string. Usually the segment-level processing is a simple copy operation, since any segments missing in the immediate base's bit String will also be missing in the new version's bit string. The bit-level processing consists of adding a new 1 to the new version's bit string, in a position corresponding to the immediate base version.

Fig. 2 shows the logic for determining the predecessors in a version's base chain. The bit string is expanded into a list of specific version numbers.

In both figures, it is assumed that the key field is named KEY and the field containing the bit string segment is named DATA. The length of each bit string segment (i.e., the length of each DATA field) is N. The subject version number (i.e., the new version in Fig. 1 and the version whose hi...