First, some facts about authorization codes:

• An authorization code is a character string up to 8 characters and cannot contain commas.
• When you create the project definition, you assign zero or more authorization codes to each group.
• Each member of every group within an SCLM-controlled project is assigned one authorization code.
• In order to put a member into a group, the authorization code of that member must match one of the authorization codes that have been assigned to the group.
• When all the authorization codes are removed from a group, no members can be promoted into or out of that group.
• When you promote a member from one group to the next, the member retains its authorization code. Thus, the group being promoted into and the group being promoted from must have a matching authorization code. If, as a result of a promote, an older version of the module was replaced, the authorization code assigned to that older version is not kept.

Code this information in the project definition as follows:

RELEASE  FLMGROUP   KEY=Y,AC=(DEV)
TEST     FLMGROUP   KEY=Y,AC=(DEV,TESTONLY),PROMOTE=RELEASE
DEV1     FLMGROUP   KEY=Y,AC=(DEV,TESTONLY,PROTO),PROMOTE=TEST
DEV2     FLMGROUP   KEY=Y,AC=(DEV,L0),PROMOTE=TEST

In Figure 1, the following relationships exist:

• A member in DEV1 with an authorization code of PROTO cannot be promoted because group TEST does not have PROTO as an authorization code.
• For the same reason, a member in DEV1 with an authorization code of TESTONLY can be promoted to TEST, but cannot be promoted to RELEASE.
• Similarly, a member in DEV1 or DEV2 with an authorization code of DEV can be promoted all the way up to group RELEASE.
• A member in DEV2 cannot have an authorization code of TESTONLY or PROTO; it must be either DEV or L0.
• A member in DEV2 with an authorization code of L0 cannot be promoted because group TEST does not have L0 as an authorization code.

When you edit a member in a development group, SCLM looks at the authorization code you specified on the edit panel and tells you the following information:

• If that authorization code is not valid for that development group, you must enter an authorization code that is assigned to that group. If you enter an invalid authorization code and then press the help key, SCLM shows authorization codes for that group.
• If use of that authorization code prevents promotion of that member at some point in the group hierarchy, SCLM gives you the name of the group into which promotion is not allowed.
• If use of that authorization code leads to a potential promotion conflict with another member of the same name, SCLM does not allow the edit. An example of this problem follows.

  SCLM allows you to have two members of the same name and type residing in two different development groups (such as DEV1 and DEV2 in Figure 1) under certain conditions. Each of those members has an authorization code assigned to it. Those codes, along with the authorization codes assigned to the higher groups in the hierarchy, determine how far up the hierarchy each of those members can be promoted. If the two promotion paths do not intersect, SCLM lets you edit those members in those groups. However, if there is at least one group through which both members can be promoted, changes made to one member would be lost when the other member is promoted. In that case, SCLM does not let you edit the members in those groups.

  If a member exists in group DEV1, SCLM uses authorization codes to determine whether you can edit a member with the same name and type in group DEV2: