z/OS ISPF Software Configuration and Library Manager Guide and Reference
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


SCLM hierarchies

z/OS ISPF Software Configuration and Library Manager Guide and Reference
SC19-3625-00

The groups within a project are organized in a hierarchical order with each group being subordinate to the group above it. A sample hierarchy is shown in Figure 1.

Figure 1. Sample Project Hierarchy
The top level group is RELEASE. The second level group is TEST. There are two third-level groups, DEV1 and DEV2.

The topmost group is not subordinate to any group and is known as the top group, root group, or the root of the hierarchy. There is only one top group in each hierarchy. The bottom groups in a hierarchy are called development groups. The names for the development groups in Figure 1 are DEV1 and DEV2. All modifications and additions to user-created data must occur in the development groups of the hierarchy. Groups of equivalent rank within the hierarchy are considered to be within the same layer of the hierarchy. Most hierarchies have multiple layers.

Changes can be promoted to the next group, TEST, in the example hierarchy. Promote means to copy or move a member or a set of members from one group to the next group in the hierarchy. Each group can only promote members to the group to which it is subordinate. This link between groups is known as the promote path. or example in Figure 1 the three promote paths are DEV1 to TEST, DEV2 to TEST, and TEST to RELEASE. Any number of groups can promote into the same group.

Hierarchies are always searched from bottom to top along a path called the hierarchical view. The hierarchical view can begin at any group in the hierarchy and follows the promote paths to the topmost group in the hierarchy. Therefore in Figure 1, two examples of hierarchical views are DEV1 to TEST to RELEASE and TEST to RELEASE. Thus, when referencing data in the hierarchy, members at lower groups take precedence over members at higher groups. All data existing in groups TEST and RELEASE is accessible from development libraries in groups DEV1 or DEV2. When a change is made to a member in the DEV1 group, this change is not available to the DEV2 group until the changed member has been promoted to the TEST group.

Therefore, within a hierarchy, the user data located at the lower layers of the hierarchy is in a more volatile state than the data at the upper layers. The upper layers of the hierarchy usually contain versions of products ready or nearly ready for release to customers, while the lower layers contain versions of products currently under development.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014