After a context has been created, it must be applied before taking effect. A context is applied, as follows:

1. Select the Apply Button from the Environment Manager.
2. Use the DECset SET command:

   $ DECSET SET CONTEXT TEAM_Z - _$ /DATABASE=DISK2:[PROJECT_EG]PROJECT.DECSET_CONTEXT_DB

3. Define the DECSET$CONTEXT logical names:

   $ DEFINE DECSET$CONTEXT TEAM_Z $ DEFINE DECSET$CONTEXT_DB DISK2:[PROJECT_EG]PROJECT.DECSET_CONTEXT_DB

Once a context has been applied and a DECset tool activated, it influences the current environment.

This chapter has focused on using the Environment Manager to tailor the environments for people working on related projects and across teams. However, the Environment Manager is also useful for an individual user for tailoring and switching between contexts, especially when working with varied environment requirements.

This chapter describes the description file generator for the Compaq Module Management System for OpenVMS (MMS). The MMS description file generator currently supports the following programming languages: BASIC, BLISS, C, C++, CDD/Plus, COBOL, Fortran, Pascal, RDB, and SQL.

Description file generation may be performed from the command-line (MMS/GENERATE) or from within the DECwindows Interface. The general process is as follows:

1. You supply the generator with a list of language source files.
2. The generator scans these source files.
3. From the results of the scanning, the appropriate target for the source, the source, the dependencies, and an action line are written to the description file for each source file.

Detailed information on the description file generator may be found in the following locations:

• Section 2.8 and the Command Dictionary (/GENERATE qualifier) of the Guide to DIGITAL Module Management System for OpenVMS Systems
• Online help ($ HELP MMS /GENERATE)

Description file generation is separate and distinct from application building. They are implemented by very different parts of MMS and are subject to different qualifiers and options.

Generally, anything set using the Options pull-down menu in the main MMS window only affects program building, and anything set in the MMS Description File Generator dialog box only affects description file generation. Of course many of the specifications are captured in the description file which will then affect building; but the steps and qualifiers are independent.

This distinction carries to the command-line, where the qualifiers on the MMS build command are separate from the ones on the MMS/GENERATE command.

This section shows how a description file may be generated for a C program consisting of a main module (MAIN.C) and some external modules (MODULE*.C) with header files (MODULE*.H). The source files contain interdependencies and references to DEC C Run-Time Library functions.

Assuming that all the source files are in the default directory, the MMS/GENERATE command may be used:

$ MMS/GENERATE/OPTIONS_FILE=TOOLS$:C.OPT MAIN.C, MODULEA.C, MODULEB.C, - _$ MODULEC.C, MODULED.C MMS-S-GENBEGIN MMS description file generation started MMS-S-NORMAL MMS description file generation completed

The same description file could also be generated from the DECwindows interface. However, the rest of this section shows the DECwindows interface being used on the same files, but this time the files are stored in a CMS library.

1. From the Main MMS window, click the Create MMS File button to bring up the MMS Description File Generator dialog box.
2. Click the Sources button to bring up the MMS Sources dialog box, select the CMS library, and create the input source list.
3. Exit the MMS Sources dialog box and generate the description file by clicking the Generate button.

Both the command-line and DECwindows interface will generate the same description file (see Figure 3-1).

Figure 3-1 Automatically Generated Description File

!++ ! Header information (1) !-- !++ ! Define symbols according to macro values (2) !-- .IFDEF DEBUG DBG = /DEBUG DBGOPT = /NOOPTIMIZE/DEBUG .ELSE DBG = /NODEBUG DBGOPT = /OPTIMIZE/NODEBUG .ENDIF .IFDEF LIST : .IFDEF DIAG : .IFDEF PCA : !++ ! List of tools used and required symbols (3) !-- ! !C used ! !Executables used !++ ! Missing sources catch-all !-- .DEFAULT (4) ! No source found for $(MMS$TARGET_NAME) ! - Attempting to continue !++ ! Complete application - default build item (5) !-- COMPLETE_APPLICATION depends_on - MAIN.EXE CONTINUE !++ ! C (6) !-- MMS$OLB.OLB(MAIN=MAIN.OBJ) depends_on - MAIN.C - ,MODULEA.H - ,MODULEB.H - ,MODULEC.H - ,MODULED.H - ! $(CC) $(CFLAGS) $(LST) $(DBGOPT) $(DIA) /OBJ=MAIN MAIN.C LIBRARY/REPLACE MMS$OLB.OLB MAIN.OBJ DELETE MAIN.OBJ;* MMS$OLB.OLB(MODULEA=MODULEA.OBJ) depends_on - MODULEA.C - ! $(CC) $(CFLAGS) $(LST) $(DBGOPT) $(DIA) /OBJ=MODULEA MODULEA.C LIBRARY/REPLACE MMS$OLB.OLB MODULEA.OBJ DELETE MODULEA.OBJ;* MMS$OLB.OLB(MODULEB=MODULEB.OBJ) depends_on - : MMS$OLB.OLB(MODULED=MODULED.OBJ) depends_on - : !++ ! Links (7) !-- MAIN.EXE depends_on - MMS$OLB.OLB(MAIN=MAIN.OBJ) - ,MMS$OLB.OLB(MODULEA=MODULEA.OBJ) - ,MMS$OLB.OLB(MODULEB=MODULEB.OBJ) - ,MMS$OLB.OLB(MODULEC=MODULEC.OBJ) - ,MMS$OLB.OLB(MODULED=MODULED.OBJ) - ! LINK $(DBG) $(PCAOPT) /EXE=MAIN.EXE MMS$OLB.OLB/LIBRARY/INCLUDE=(MAIN) - ,DISK2:[PROJECT_EG.TEAMS.TEAM_Z.BUILD.TOOLS]C.OPT/OPT- !Link options file ! End of Link !++ ! Files not found. MMS references to these (8) ! files will generate errors. !-- !++ ! Create object library if it doesn't already exist (9) !-- .FIRST IF F$SEARCH( "MMS$OLB.OLB" ) .EQS. "" - THEN $(LIBR)/CREATE MMS$OLB.OLB !++ ! End of build cleanup work (10) !-- .LAST CONTINUE

All automatically generated description files have the same general format, as described below:

1. A header box ready for additional comments.
2. Macro symbols for DEBUG, DIAGNOSTICS, LIST, and PCA.
3. A list of the tools and images used (normally language compilers).
4. A rule to handle missing source files.
5. A rule for the complete application, with a dependency on the main image.
6. Rules for the individual source files. These rules will usually lead to the creation of an object in an object library, followed by a list of dependent files and compilation action lines.
7. Rules for linking the main image followed by a list of dependencies on the object in the object library and linker rules.
8. A list of any dependency files not found by the description file generator.
9. A first directive creating the object library if it does not already exist.
10. A last directive.

This section illustrates description file generation in more complex examples. Section 3.3.1 shows a Pascal example where the main source files are in one directory and the environment files in another. Section 3.3.2 shows a COBOL example with the source files in CMS and a requirement to place all the output files into type related directories.

3.3.1 Generating a Description File for Pascal

In this example, the main Pascal source files (TEST22.PAS and SUBTEST*.PAS) reside in DISK2:[PROJECT_EG.TEAMS.TEAM_Z.SOURCE.PASCAL] while the environment files (TEST_FUNC*.PAS) are in DISK2:[PROJECT_EG.TEAMS.TEAM_Z.SOURCE.ENV].

The following steps show how a description file may be generated from the DECwindows interface:

1. Set default to a search list of directories, which allows the description file generator to see all the source files:

   $ DEFINE SOURCE$DIR DISK2:[PROJECT_EG.TEAMS.TEAM_Z.BUILD], - _$ DISK2:[PROJECT_EG.TEAMS.TEAM_Z.SOURCE.PASCAL], - _$ DISK2:[PROJECT_EG.TEAMS.TEAM_Z.SOURCE.ENV] $ SET DEFAULT SOURCE$DIR

2. Before building the image, ensure that any logical names used within the source files are defined:

   $ TYPE TEST_FUNC1.PAS [ ENVIRONMENT ('ENVDIR:TEST_FUNC1') ] MODULE TEST_FUNC1; : END. $ DEFINE ENVDIR DISK$:[DECUS.PASCAL.ENV]

3. From the MMS main window, click the Create MMS File button to bring up the MMS Description File Generator dialog box.
4. Click the Sources button to bring up the MMS Sources dialog box.
5. Select the .PAS files for the Input Source List. Note that the source files for the environment files should not be selected, as the description file generator will find them as it scans for dependencies.
6. After setting up the Input Source List and Main Module, click the OK button to return to the MMS Generate Description File dialog box.
7. Click the Generate button to create the description file and return to the main window.

The description file is now ready for use.

3.3.2 Generating a Description File for COBOL

This example is based around the following:

• The COBOL source files are fetched into one directory (COB).
• The library files are fetched into another directory (LIB).
• The image file is built in an images directory (EXE).
• The object library is built in an object library directory (OLB).
• The description file(s) are built and kept in another directory (BUILD).

DISK2:[PROJECT_EG.TEAMS.TEAM_Z] | +------------------------------+ | : [BUILD] DEFAULT$DIR CMS$LIB + | Reference directory +----------+-----+-----+----------+ | | | | [COB] [EXE] [LIB] [OLB] COB$DIR EXE$DIR LIB$DIR OLB$DIR == ALL$DIR

Logical name definitions (which could be defined in an Environment Manager context) are required for each of the directories, and one is also needed for the search list of source directories:

$ DEFINE/TABLE=LNM$JOB ALL$DIR EXE$DIR, COB$DIR, DEFAULT$DIR, LIB$DIR

A new set of language rules are required to fetch the source files into the language specific directories. To achieve this, a new rules file (RULES.MMS) is required:

.SUFFIXES .SUFFIXES : .LIB .LIB~ .COB .COB~ .lib~.lib : if "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB - $(MMS$CMS_LIBRARY) $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=LIB$DIR:$(MMS$TARGET_NAME).LIB - $(CMSFLAGS) $(CMSCOMMENT) .COB~.COB : if "$(MMS$CMS_LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB - $(MMS$CMS_LIBRARY) $(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=COB$DIR:$(MMS$TARGET_NAME).COB - $(CMSFLAGS) $(CMSCOMMENT)

The .LIB rules are especially important when using earlier versions of the Compaq DECset for OpenVMS software. Prior to DECset, Version 12.2, MMS has no default rules for the COBOL library files.

3.3.2.1 Creating the Description File from the CMS Library

The steps below show how the description file may be generated from the DECwindows interface.

1. Click the Create MMS File button to bring up the MMS Description File Generator dialog box.
2. Set the Object Library (OLB$DIR:TEST.OLB), the description file name (COBOL.MMS), and then click the Sources button to bring up the MMS Sources dialog box.
3. Enter the CMS library, filter the COBOL files, place all the source files into the Input Source List, and specify the main module .
4. Click the OK button to return to the Generate Description File dialog box.
5. Click the Generate button to return to the MMS main window and generate the description file.

The description file may also be generated from the command-line using the CMS reference directory:

$ SET DEFAULT $1$DIA3:[PROJECT_EG.TEAMS.TEAM_Z.SOURCE.SRC_REF] $ ! $ MMS/GENERATE/DESCRIPTION=DEFAULT$DIR:COBOL.MMS/OBJECT=OLB$DIR:TEST.OLB - _$ MAIN.COB, MODULEA.COB, MODULEB.COB, MODULEC.COB %MMS-S-GENBEGIN MMS description file generation started %MMS-S-NORMAL MMS description file generation completed

3.3.2.3 Building the Program

Irrespective of how the description file was generated, to ensure the source and output files are copied into the correct directories, the default directory must be set to the search list (ALL$DIR) before building. Otherwise, MMS will not be able to check the directories for source files (which may lead to unnecessary fetches from the CMS library).

Like the generation of the description file, the program may be built using either the command-line or the DECwindows interface, as follows:

$ MMS/DESCRIPTION=DEFAULT$DIR:COBOL.MMS/RULES=TOOLS$:RULES.MMS/CMS

As the Environment Manager does not support a search list for the default directory in a context, the DECwindows interface must be accessed via the MMS/INTERFACE=DECWINDOWS command. The rules file may be set in the context, so all that is needed is to specify the correct description file and set the CMS flag:

1. The description file is set by selecting Open Description File from the File pull-down menu.
2. The CMS flag is set from the MMS Build Definition/Directive Options dialog box, which is selected from the Options pull-down menu .
3. Once the description and build options have been set, click the Start Build button in the main window.

Individually, each DECset tool is a useful product that can enhance programmer productivity. Used together with the Environment Manager, these tools combine with the program design facilities of LSE and SCA and the OpenVMS language compilers, system services, and utilities to make an integrated environment with the following characteristics:

• Support for the multiple phases of the software life cycle.
• Support for applications written in multiple languages.
• Compilers and tools that pass substantial information among themselves to automate tasks previously performed manually.

Integration in DECset exists with the OpenVMS environment and language compilers and amongst the tools themselves. Integration with OpenVMS and the compilers is discussed extensively in the following documentation:

• DECset Guide to Detailed Program Design for OpenVMS Systems
• Section 1.2 of the Using DECset for OpenVMS Systems

As a result, integration with OpenVMS is covered only very briefly in this chapter. However, integration among the tools themselves is covered through the use of a number of examples (see Section 4.2).

4.1 Integration With the OpenVMS Environment and Language Compilers

The OpenVMS compilers generate a substantial amount of information for the DECset tools, such as symbol table information for PCA, diagnostic information for LSE and cross-reference and calling-sequence information for SCA.

4.2 Integration Among the DECset Tools

An Environment Manager context was used to tailor all the DECset tools used for the examples (this explains the "Context name" in the DECwindows title bars).

4.2.1 CMS

CMS elements may be placed into LSE buffers directly from the CMS DECwindows interface using the following steps:

1. Select the element (MB1 DISPLAY_TABLES.ADA).
2. Activate the fetch command from the File pull-down menu.
3. Click the OK Button, and the element is fetched into an LSE Buffer .

This process also works for reserving elements. If an LSE DECwindows session is not activated (either expanded or iconified), the element is fetched into the default directory. Once the elements are in the buffer they can be manipulated via LSE commands.

Because CMS can store any file as an element, it is particularly useful as a central repository, not only for source files of code and documentation, but also for a variety of files generated by other DECset tools. CMS can store description files for MMS and test files (prologue, template, epilogue) for the Test Manager as well as benchmark files. MMS (see Chapter 3) can also access elements in CMS libraries automatically.

4.2.2 LSE

LSE provides a highly interactive environment for source code development. Within LSE, you can create and edit code, compile and review that code, and correct compile-time errors. You can also invoke LSE from the OpenVMS Debugger to correct source errors.

LSE is integrated with CMS to provide source code management. You can invoke LSE from the Analyzer portion of PCA and from OpenVMS Mail. LSE is also integrated with SCA as described in the following section.

4.2.3 LSE/SCA

Using LSE and SCA together creates an integrated editing environment. You can browse through all of your code to look for specific declarations of symbols or other information without regard to file location.

A CMS element has been fetched into an LSE buffer. Now we have a source file, and assuming that analysis data for the source files have been placed into the current SCA library, SCA FIND commands can be used to access other parts of the program:

1. After finding a reference to a record called TABLE, the Goto Declaration command from the Source pull-down menu is used to find the declaration of TABLE.
2. This finds a declaration based on COMPONENT_COUNT_RECORD within the same file. The process is repeated for COMPONENT_COUNT_RECORD and this time the declaration is in another source program stored in the CMS library.
3. LSE then asks if this file should be fetched into a buffer .
4. LSE fetches the file into a buffer.

If SCA and LSE are running simultaneously in separate windows, LSE can display the source code associated with symbols displayed by SCA. This is illustrated by the example below:

1. Select the Name Browser from the SCA DECwindows interface.
2. Specify a filter (PROCESS*) and then select an object (PROCESS_RECORD) from the list displayed.
3. With the object highlighted, select Type Of from the Query pull-down menu, displaying a diagram of the object (procedure PROCESS_RECORD) in a SCA: Data Structures Results screen.
4. Double-click on the procedure in the Data Structures screen, and the file is loaded into an LSE buffer

The combination of LSE and SCA also provides the report generation capability of the program design facility. LSE generates and formats the report based on design information provided by SCA.

4.2.4 MMS

MMS can access elements in CMS libraries during builds (see Section 3.3.2.3), and all the files used for the build, documentation, and the MMS description file can be kept in a CMS library. An MMS description file can also build from CMS classes. Additionally, MMS can access records stored in the Oracle Common Data Dictionary (CDD/Plus) or forms stored in libraries for the Compaq Forms Management System for OpenVMS (FMS).

MMS provides support for SCA in that analysis data can be automatically generated as part of the MMS build procedure for storage in an SCA library.

The MMS DECwindows interface is also integrated with LSE, as the example below shows:

1. If an LSE window is open, MMS will place the description file into an LSE buffer rather than the Description File Area.
2. Providing you compile with the diagnostics option, if a build fails due to a compilation failure, MMS (via the Review pull-down menu) allows you to scan the diagnostic files and place the failing source file into an LSE buffer .
3. Once in the buffer you can use LSE to resolve the problem .

You can use the storage and update capabilities of CMS for the DTM template, benchmark, test data, prologue, and epilogue files (this is how the libraries were set up in Chapter 2). This feature can be useful in testing multiple versions of a software system in situations where the expected results change from version to version. For example, you can run previous versions of tests and compare their results against the results that were valid for the corresponding maintenance version of a system.

By using Test Manager with PCA you can measure the performance or coverage of tests run under the Test Manager control. Using an MMS description file to build the application, you can also execute your tests automatically.

4.2.6 PCA

When used with the Test Manager, PCA can evaluate code coverage of your test system. Additionally, you can use the regression tests as performance tests for PCA.

You can also use PCA to analyze programs that are composed of modules written in different languages. Additionally, from PCA you can invoke LSE and have access to all of its features, such as the links to SCA and CMS.