After a context has been created, it must be applied before taking effect. You can apply a context in any of the following ways:

• Click the Apply button on the Environment Manager main window.
• Enter the DECset SET CONTEXT command:

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

• 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 development 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 in environments with varied development requirements.

This chapter describes the description file generator for the 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.

You can generate a description file from the MMS command-line (MMS/GENERATE) or from within the DECwindows Motif interface. The general process is as follows:

1. You supply the generator with a list of language source files.
2. The MMS description file generator scans these source files.
3. Once the scan is complete, it then writes the following information about each source file to a separate description file:
   • Target for the source
   • Source
   • Related dependencies
   • An optional action line

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

• Guide to DIGITAL Module Management System for OpenVMS Systems (/GENERATE qualifier)
• 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 application builds, and anything set in the MMS Description File Generator dialog box only affects description file generation.

Although, many of the specifications captured in the description file affect an application build, the steps and qualifiers used in each process are independent. This distinction carries to the command line, where the qualifiers on the MMS build command line are separate from the ones used on the MMS generate command line.

3.2 Basic Description File Generation

This section shows how a description file can 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 HP C Run-Time Library functions.

Assuming that all the source files are in the default directory, the MMS/GENERATE command can 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 description file can also be generated from the DECwindows Motif interface. The remainder of this section shows the DECwindows Motif interface being used on the same set of files; however, this time the files are stored in a CMS library.

Figure 3-1 MMS Main Window

1. From the MMS main 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 (see Figure 3-2).

   Figure 3-2 MMS Sources Dialog Box

   ---

   
3. Exit the MMS Sources dialog box and generate the description file by clicking the Generate button. Figure 3-1 shows the MMS main window following the successful generation of a description file.

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

Figure 3-3 Automatically Generated Description File

! Define symbols according to macro values (1) !== .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 (2) !== ! !C used ! !Executables used !++ ! Missing sources catch-all !== .DEFAULT (3) ! No source found for $(MMS$TARGET_NAME) ! - Attempting to continue !++ ! Complete application - default build item (4) !== COMPLETE_APPLICATION depends_on - MAIN.EXE CONTINUE !++ ! C (5) !== 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 (6) !== 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 (7) ! files will generate errors. !== !++ !++ ! Objects not found. The following symbols may be undefined. (8) !== !++ ! 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 description files that are generated automatically have the same general format, as described below:

1. Macro symbols for DEBUG, DIAGNOSTICS, LIST, and PCA.
2. A list of the tools and images used (normally language compilers).
3. A rule to handle missing source files.
4. A rule for the complete application, with a dependency on the main image.
5. 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.
6. Rules for linking the main image followed by a list of dependencies on the object in the object library and linker rules.
7. A list of any dependency files not found by the description file generator.
8. A list of any symbols that appear to be referenced but are not defined.
9. A first directive creating the object library, if it does not already exist.
10. A last directive.

Each generated description file may contain a list of files that could not be found and a list of symbols for which no definition can be found. If both missing files and symbols definitionst are listed, check why the generator has been unable to find them. It may be due to a missing logical name or an incorrect definition.

If only missing symbols definitions are listed, the symbols may be defined in object libraries that were not constructed as part of current the build. If this is the case, performing a full build will determine whether the symbol definitions are really missing.

3.3 More Complex Description File Generation

This section illustrates description file generation using 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 to generate a description file using the DECwindows Motif interface:

1. Set default to a search list of directories that 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 environment file sources should not be selected, as the description file generator will find them when it scans for dependencies (see Figure 3-4).

   Figure 3-4 MMS Sources Dialog Box: Pascal Example

   ---

   
6. After entering the Input Source List and Main Module values, 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 MMS 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).

Logical name definitions (which could be defined in an Environment Manager context) are required for each of the directories.

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 Motif interface.

1. Click the Create MMS File... button to bring up the MMS Description File Generator dialog box.
2. Enter 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 (see Figure 3-5).
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 (see Figure 3-6).

Figure 3-5 MMS Sources Dialog Box: COBOL Example

Figure 3-6 MMS Main Window: COBOL Example

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 Application

Regardless of how the description file is generated, you must set the default directory to the sources directory (COB$DIR) before building the application.

Like the generation of the description file, you can build the application using either the DECwindows Motif interface or the command line.

The steps below show how to build the application using the description file generated by following operations in the previous sections:

1. Select Open Description file... from the File pull-down menu and set the description file, COBOL.MMS, in the Select MMS description file dialog box.
2. Select Definition/Directive... from the Options pull-down menu and make sure that the Use CMS flag is set in the MMS Build Definitions/Directives Options dialog box. (see Figure 3-7).
3. Once the description and build options have been set, click the Start Build button in the main window (see Figure 3-1).

Figure 3-7 MMS Build Definitions/Directives Options Dialog Box

To build an application from the command line, entering the follow command:

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

Individually, each DECset tool can significantly increase productivity in specific areas of the OpenVMS application development cycle. However, when used in concert with each other, the DECset tools form an powerful, integrated application development environment with the following characteristics:

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

This chapter describes the integration that exists between DECset and the OpenVMS application development environment. It provides an overview of the data flow between the OpenVMS language compilers and the DECset tools as well as examples of interaction between the tools themselves.

For additional, detailed information about how the DECset tools work with OpenVMS system services and its language compilers to improve application design and maintenance, see the following manuals:

• DECset Guide to Detailed Program Design for OpenVMS Systems
• Using DECset for OpenVMS Systems

The OpenVMS language 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.

Figure 4-1 shows the many connections and information flow among the tools that give the OpenVMS programming environment its high level of integration. The boxes represent tools, and the arrows represent information flow, either by means of files or through direct calls between the tools.

Figure 4-1 DECset Tools Integration

The following sections provide examples of how the various DECset tools interact in an application development environment. Note that an Environment Manager context (TEST1) was used to tailor all the DECset tools used in the examples.

4.2.1 CMS

CMS elements may be placed into LSE buffers directly from the DECwindows Motif interface, as follows:

1. Select the element (MB1 DISPLAY_TABLES.ADA).
2. Select Fetch from the File pull-down menu (see Figure 4-2).
3. Click the OK Button on the Fetch dialog box. The element is fetched into an LSE Buffer (see Figure 4-3).

Figure 4-2 CMS: Fetching an Element

Figure 4-3 CMS & LSE: Element Fetched into an LSE Buffer

This process also works for reserving elements. If an LSE DECwindows session is not active (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, test files (prologue, template, epilogue) for the Digital Test Manager, and 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 and 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. This integration is illustrated below in an example which continues on from Figure 4-3.

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 (see Figure 4-4).
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 (see Figure 4-5).
4. LSE fetches the file into a buffer (see Figure 4-6).

Figure 4-4 LSE & SCA: Goto Declaration in Same File

Figure 4-5 LSE & CMS: Goto Declaration in a CMS Element

Figure 4-6 LSE & CMS: Element Fetched into an LSE 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 (see Figure 4-7).

Figure 4-7 SCA & LSE: From Data Structures Results to 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). All the files used for the build, product 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 Forms Management System for OpenVMS (FMS).

MMS provides support for SCA. Analysis data can be generated automatically as part of the MMS build procedure and then stored in an SCA library.

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

1. If an LSE window is open, MMS places the description file into an LSE buffer rather than the Description File Area (see Figure 4-8).
2. When 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 (see Figure 4-9).
3. Once in the buffer, you can use LSE to resolve the problem (see Figure 4-10).

Figure 4-8 MMS & LSE: MMS Description File in LSE

Figure 4-9 MMS & LSE: Compilation Errors During an MMS Build

Figure 4-10 MMS & LSE: Correcting Compilation Errors

You can use the storage and update capabilities of CMS to manage 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 DTM with PCA, you can measure the performance or coverage of tests run under DTM. Using an MMS description file to build the application, you can also run those tests automatically.