It is a characteristic of software members that they can be easily modified, and experience shows that they frequently are modified. Stable and relevant states of a development object are therefore maintained in the form of members.
Several versions per member type and member name
In libraries, a member is uniquely defined by its type, name and version designation. Furthermore it is possible to store several versions under one member type and member name.
If the user does not specify the version to be processed, LMS takes the following actions as a standard procedure:
In read mode
that member is sought whose specified name is accompanied by the highest version designation. The date is ignored.In write mode
the actions depend on the statement:ADD-ELEMENT and MODIFY-LOGGING-PARAMETERS TEXT-OUTPUT=The member is generated or overwritten with the highest version X’FF’. LMS identifies this version by @.
Other statements
The output member is given the version designation of the input member.
If an identically named member is overwritten, the internal variant number is incremented by 1. This serves as a write counter.
Different states of a development object are stored in different members. Initially, only the user is aware of the relationships between individual members; they are not established in the library. Each member is an independent unit in the context of a library.
Delta storage
Members that have been created through modification from a predecessor member generally differ only minimally from the predecessor. It is therefore sensible to store this set of members in a more compact form, namely by physically storing only the differences from the relevant predecessor. This compact storage of the differences produces the delta tree.
All members of a delta tree which have no successor are referred to as “leaves”. Only leaves can be overwritten.
Delta trees
Only through the use of delta trees can a relationship between the members also be recorded in the library. The following applies to such members
on the member designation level
Since the new member was created through modification from another member, it still belongs to the same class and reflects the same logical content. Both aspects are recorded in the type and name of the member, i.e. all members of a delta tree have the same type and name.
The version component of a member designation should reflect the state.on the physical level
The relationship between the two members is also to be recorded on the physical level. Which members are to be interlinked is not determined on the basis of the version string, however, but is to be derived from user specifications. For this purpose the user must declare one member as the “predecessor” and one member as the “successor”.