If a specific context is used and the first item in the application appl_CMS_PATH logical name does not specify the latest generation of a class (i.e. it does not finish in a +), a job appl_CMS_PATH logical name is defined with a user specific class as the new first item. This user specific class is of the form appl_envr_user.

For example an environment which does support specific generations:

$ context application fin dev/common DISK_DEV5:[FIN.WRK.JONES_AB] Executing application FIN in DEV's ENTER.COM $ show logical fin_cms_path "FIN_CMS_PATH" = "FIN_DEV" (LNM_FIN_DEV) $ show logical fin_cms_variant %SHOW-S-NOTRAN, no translation for logical name FIN_CMS_VARIANT $ context specific DISK_DEV5:[FIN.WRK.JONES_AB] Executing application FIN in DEV's ENTER.COM $ show logical fin_cms_path "FIN_CMS_PATH" = "FIN_DEV_JONES_AB+" (LNM$JOB_80E05930) = "FIN_DEV" "FIN_CMS_PATH" = "FIN_DEV" (LNM_FIN_DEV)

In the above example, a DEVTOOLS CMS PROMOTE or SRCCTL PROMOTE command would be used to propte the developers specific generation into the common class.

For example an environment which does not support specific generations:

$ context environment mnt/common DISK_MNT4:[FIN.WRK.JONES_AB] Executing application FIN in MNT's ENTER.COM $ show logical fin_cms_path "FIN_CMS_PATH" = "FIN_MNT+" (LNM_FIN_MNT) $ show logical fin_cms_variant "FIN_CMS_VARIANT" = "A" (LNM_FIN_MNT) $ context specific DISK_MNT4:[FIN.WRK.JONES_AB] Executing application FIN in MNT's ENTER.COM $ show logical fin_cms_path "FIN_CMS_PATH" = "FIN_MNT+" (LNM_FIN_MNT)

3.5 Multi-variant CMS Classes

If a multi-variant development environment is in use the previously described formats for the appl_CMS_PATH logical name items become appl_envr_VARvrnt and appl_envr_VARvrnt_user as appropriate.

For example:

$ context application fin dev b/common DISK_DEV5:[FIN.VARB.WRK.JONES_AB] Executing application FIN in DEV variant B's ENTER.COM $ show logical fin_cms_path "FIN_CMS_PATH" = "FIN_DEV_VARB" (LNM_FIN_DEV_VARB) $ show logical fin_cms_variant "FIN_CMS_VARIANT" = "B" (LNM_FIN_DEV_VARB) $ context specific DISK_DEV5:[FIN.VARB.WRK.JONES_AB] Executing application FIN in DEV variant B's ENTER.COM $ show logical fin_cms_path "FIN_CMS_PATH" = "FIN_DEV_VARB_JONES_AB+" (LNM$JOB_80E05930) = "FIN_DEV_VARB" "FIN_CMS_PATH" = "FIN_DEV_VARB" (LNM_FIN_DEV_VARB)

3.6 Multi-version CMS Classes

If a multi-version maintenance environment is in use the previously described formats for the appl_CMS_PATH logical name items become appl_envr_vrsn and appl_envr_vrsn_user as appropriate.

For example:

$ context application fin mnt v2.1/common DISK_MNT5:[FIN.V021.WRK.JONES_AB] Executing application FIN in MNT version V021's ENTER.COM $ show logical fin_cms_path "FIN_CMS_PATH" = "FIN_MNT_V021" (LNM_FIN_MNT_V021) $ show logical fin_cms_variant "FIN_CMS_VARIANT" = "A" (LNM_FIN_MNT_V021) $ context specific DISK_MNT5:[FIN.V021.WRK.JONES_AB] Executing application FIN in MNT version V021's ENTER.COM $ show logical fin_cms_path "FIN_CMS_PATH" = "FIN_MNT_V021_JONES_AB+" (LNM$JOB_80E05930) = "FIN_MNT_V021" "FIN_CMS_PATH" = "FIN_MNT_V021" (LNM_FIN_MNT_V021)

3.7 Multiple CMS Libraries

SysWorks also allows development style environments to have their own CMS libraries. This is primarily to allow higher performance during the highly volatile development stage, and to reduce the number of `junk' versions in the primary CMS library. This arrangement is made on an application environment basis. For example the FIN application in development may have its own CMS library whihc would reside in:

DISK_DEV:[FIN.SRC.CMSLIB]

No reference directory is used for the same reason as with the common CMS library. If a separate CMS library is used for a development style environment, the appl_envr class and the appl_CMS_PATH logical name should still be defined.

During the various version control procedures the generations are copied across to the application common CMS library.

3.8 Commands

Three command interfaces are used to control sources. These are:

• CMS
• SRCCTL (minimum abbreviation SRC)
• DEVTOOLS CMS (minimum abbreviation DEV CMS)

The last two are used to act as a front end for CMS. See Table 3-3 for a list of CMS commands and the front ends which will accept them.

Table 3-3 CMS Command Availability

Command	CMS	DEVTOOLS	SRCCTL
ACCEPT GENERATION	X
ANNOTATE	X
CANCEL REVIEW	X
COPY ELEMENT	X
CREATE CLASS	X		X 1
CREATE GROUP	X		X 1
CREATE ELEMENT	X	X	X
CREATE LIBRARY	X		1
DELETE CLASS	X		X 1
DELETE GENERATION	X		X 1
DELETE GROUP	X		X 1
DELETE ELEMENT	X	X	X
DELETE HISTORY	X		X 1
DIFFERENCES	X
FETCH	X	X	X
INSERT ELEMENT	X
INSERT GENERATION	X	X
INSERT GROUP	X
MARK GENERATION	X
MODIFY CLASS	X
MODIFY ELEMENT	X
MODIFY GENERATION	X
MODIFY GROUP	X
MODIFY LIBRARY	X
PROMOTE		X	X
REJECT GENERATION	X	X
REMARK	X
REMOVE ELEMENT	X
REMOVE GENERATION	X	X
REMOVE GROUP	X
REPLACE	X	X	X
REPORT		X	X
RESERVE	X	X	X
RETRIEVE ARCHIVE	X
REVIEW GENERATION	X
SET ACL	X
SET LIBRARY	X	X
SHOW ACL	X		X 1
SHOW ARCHIVE	X		X 1
SHOW CLASS	X		X 1
SHOW ELEMENT	X		X
SHOW GENERATION	X		X 1
SHOW GROUP	X		X 1
SHOW HISTORY	X		X 1
SHOW LIBRARY	X		X 1
SHOW RESERVATIONS	X		X 1
SHOW REVIEWS_PENDING	X		X 1
SHOW VERSION	X		X 1
UNRESERVE	X	X	X
VERIFY	X

If the SysWorks Developer CMS front end (SRCCTL or DEVTOOLS CMS) is used, the appl_CMS_PATH and appl_CMS_VARIANT logical names provide defaults for use with the /PATH qualifier. The /PATH qualifier is not a CMS qualifier, rather it is an extension provided by SysWorks to element based CMS commands such as CREATE ELEMENT to indicate that the element is to be placed in the indicated class after being created in the CMS library.

By default, a command which supports the /PATH qualifier will, if the qualifier is not specified, default to the equivalence of the appl_CMS_PATH logical name.

By default, a command which supports the /VARIANT qualifier will, if the qualifier is not specified, default to the equivalence of the appl_CMS_VARIANT.

The SRCCTL method supplies a menu based front end which ultimately uses the DEVTOOLS CMS command to perform the actual operation. If the SRCCTL command is entered from DCL without any sub-command following or is selected from the session manager Manage => Sources pulldown menu, its displays the menu illustrated in Figure 3-1 and prompts for a sub-command. If the SRCCTL command is followed by one of the sub-commands indicated in Figure 3-1, the menu is not displayed and the sub-command dialog is entered directly.

Figure 3-1 SRCCTL menu

The DEVTOOLS CMS method is a foreign utility will a full command line interface (i.e entering DEVTOOLS without any sub-command causes a DEVTOOLS> prompt to appear). At this time not all SRCCTL commands are fully supported by DEVTOOLS CMS - some are still implemented by using CMS directly - so although DEVTOOLS CMS is faster, SRCCTL is more complete. In a future version of SysWorks Developer, the DEVTOOLS CMS command will support all CMS commands and qualifiers.

Both of these front ends extend CMS by allowing lists of elements and an indirect construction. For example, the following command:

$ devtools cms reserve fin_main_prog.c,fin_other.c "Fix"

will reserve both elements. Also, the following command:

$ devtools cms reserve @t1.txt "Fix them all"

will reserve each of the files specified in T1.TXT. Another enhancement allows full file specifications to be given in place of CMS element names. This becomes useful in the following example:

$ search [-]*.com* old_sym/window=0/out=t1.txt $ devtools cms reserve @t1 "Change OLD_SYM to NEW_SYM" $ change *.com* old_sym new_sym/verify

In this example the search command with /WINDOW=0 produces only the file specifications of the files containing the requested text. The output of this can then be fed into the DEVTOOLS CMS RESERVE command, which will reserve each of the elements which contain the text. The CHANGE command will then change the text to a new value and display each of the lines thus changed in each file. Note the use of the [-] construction in the SEARCH command. Given a developers default directory will be of the form DISK_envr:[appl.WRK.user], this construct results in searching the common work directory, which would normally contain copies of the appropriate generations (i.e. current or latest from class) of all the elements associated with the application environment's CMS class.

The following sub-sections describe the extra actions that the front end command will perform above the base CMS operation, and extra tasks provided by the SRCCTL front end. They are presented in alphabetic order.

3.8.1 BUILD

One of the items on both the SRCCTL and VSNCTL menus is BUILD. When selected, it asks a set of questions before building the application's software. See Section 5.2 for a description of how BUILD works. It is also available from DCL as a command. When used directly from DCL, the BUILD command takes qualifiers much like any normal DCL command. See the Command Dictionary or use HELP BUILD for more details on using the BUILD command from DCL.Intermediate Directories

3.8.2 CREATE

3.8.3 DELETE

Examples

$ srcctl report
Version [V2.0]: V1.0
Development environment [DEV]:
Development testing environment [DTST]:
Maintenance environment [MNT]:
Maintenance testing environment [MTST]:
Output [SYS$OUTPUT]:
Display (All/New/Unused) [All]: NEW,UNUSED
Execution (Batch/Detached/Online/Subprocess) [Batch]: ONLINE
      

This example generates a report listing elements which are not in the release class or are not in any class. The report is generated online.

3.8.11 SHOW