Allowing parallel updates

You can use the information in the previous section to set up a project in which you can make modifications to what you have in production (development) while being able to make quick fixes to production modules (maintenance). The simple hierarchy is illustrated in the following example. An actual hierarchy can contain many groups and layers.

The top item of the hieararchy is PROD, which is FIXED. The second level of the hierarchy has DEV (which is BETTER) and FIX (which is FIXED).

Define the groups as follows:

PROD     FLMGROUP   KEY=Y,AC=(FIXED)
DEV      FLMGROUP   KEY=Y,AC=(BETTER),PROMOTE=PROD
FIX      FLMGROUP   KEY=Y,AC=(FIXED),PROMOTE=PROD

There are three groups: PROD is the production library, DEV is the development library, and FIX is the maintenance library. In practice, there would be a much larger subhierarchy under both DEV and FIX in order to allow for both multiple developers and for testing of applications before moving them to production.

DEV, FIX, and PROD each have a single authorization code, BETTER, FIXED, and FIXED respectively, and could have more. More importantly, no authorization code is assigned to both DEV and PROD. It is this aspect of the project definition that prevents the promotion of any modules from group DEV into group PROD. When the development code is ready to move into production, the authorization code BETTER must be added to the valid authorization codes for the PROD group.

A programmer planning to make changes to a module for the next release of an application draws the module down from PROD into DEV, specifying an authorization code of BETTER on the SCLM EDIT-ENTRY PANEL. Changes are made and tested in DEV.

Suppose that while the module is being changed and tested in the DEV group, a user encounters a problem with the application and another programmer determines that the fix requires a change to the module that has been drawn down to DEV.

The programmer can draw down the module into FIX even though that same module has been drawn down into DEV. This is possible because the promotion paths of the two modules do not intersect; the module in DEV cannot be promoted into PROD because of authorization codes. Therefore, changes made to one module do not overwrite changes made to the other copy.

When the fix has been made to the module in FIX and the application has been rebuilt at that group, the user can run the application from group FIX until the fix has been verified and then promoted to PROD.

Before the fix is promoted, the changes must be incorporated into the copy of the modules in DEV. This is a manual change made by the current owner of the modules in DEV with the assistance of the person who made the changes in FIX.

Keep in mind that although authorization codes can be used to restrict promotion paths, they do not provide security against modifications to SCLM-controlled data made outside of the SCLM environment. You should use RACF® (or the functional equivalent) for that purpose.