Two methods are available for storing multiple versions of one member name in libraries:
the non-delta storage method
the delta storage method
The non-delta storage method is used to store exactly one member, i.e. all records of a member, in its own container (a unit of storage in the library). If another version is added under this name, all records of this member will also be kept in an individual container. Any relationship that may exist between these members is unknown to LMS.
Such members are henceforth referred to as non-delta members.
During processing, e.g. reading a non-delta member, LMS can directly access all records of the member specified and perform the action. This method applies to all member types and, because of its fast access features, it is particularly suitable for members that are still being developed or subject to change.
For the text-oriented member types S, M, J, P, D and X or types derived from them, the delta storage method can be used to store multiple versions of one member. With this storage-saving method only the temporarily first member is stored in its entirety in its own container. When other versions of the same member are added, then only the records that are different from those of the previous member are identified and inserted (comparison of members). In addition, the link between new version and previous version reveals the logical relationship between the individual members.
Such members are henceforth referred to as delta members.
During processing, e.g. reading a delta member, the relevant records of the referenced member are filtered out. This may slow down the entire action if a great number of related delta members are present. The delta storage method is therefore specially suited for the efficient and transparent filing of member versions.