Digital PDFs

AA-P119E-TE

December 1990

210 pages

Original

6.6MB

Document:	Guide to VAX DEC/Module Management System
Order Number:	AA-P119E-TE
Revision:
Pages:	210
Original Filename:	http://bitsavers.org/pdf/dec/vax/vms/layered_product/AA-P119E-TE_Guide_to_VAX_DEC_Module_Management_System_199007.pdf

OCR Text

Guide to VAX DEC/Module Management
System
Order Number: AA-P119E-TE

July 1990
This manual describes how to use the VAX DEC/Module Management System for
building software systems.

Revision/Update Information:

This revised manual supersedes the Guide to VAX
DEC/Module Management System
(Order Number AA-P119D-TE).

Operating System and Version: VMS Version 5.2 or higher
Software Version:

digital equipment corporation
maynard, massachusetts

VAX DEC/MMS Version 2.6

First printing, March 1983
Revised, June 1984
Revised, April 1987
Revised, May 1989
Revised, July 1990

The information in this document is subject to change without notice and should not
be construed as a commitment by Digital Equipment Corporation. Digital Equipment
Corporation assumes no responsibility for any errors that may appear in this document.
The software described in this document is furnished under a license and may be used
or copied only in accordance with the terms of such license.
No responsibility is assumed for the use or reliability of software on equipment that is
not supplied by Digital Equipment Corporation or its affiliated companies.
Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to
restrictions as set forth in subparagraph (c)(1 )(ii) of the Rights in Technical Data and
Computer Software clause at DFARS 252.227-7013.
©Digital Equipment Corporation 1983, 1984, 1987, 1989, 1990.
All Rights Reserved.
Printed in U.S.A.
The postpaid Reader's Comments forms at the end of this document request your
critical evaluation to assist in preparing future documentation.
The following are trademarks of Digital Equipment Corporation:
CDA
DDIF
DEC
DECnet
DECUS
DECwindows
DIGITAL
LN03

MASS BUS
PrintServer 40
Q-bus
ReGIS
ULTRIX
UNIBUS
VAX
VAXcluster

VAX RMS
VAXstation
VMS
VT
XUI

mnmnomn™
ZK5449

Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 1

Introduction to MMS

1.1

Overview ........................................... .

1-1

1.2

Invoking MMS ....................................... .

1-2

1.3

Getting Help ........................................ .

1-3

1.4

MMS Concepts ....................................... .
1.4.1
Description Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.3
Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.4
Action Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Built-in Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.6

1-3
1-3
1-4
1-4
1-4
1-5
1-5

1.5

Building Software Systems .............................. .
1.5.1
Single Source System . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2
Multiple Source System . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3
Multiple Programming Language System .............. .
1.5.4
System with Included Files . . . . . . . . . . . . . . . . . . . . . . . .
1.5.5
System with Multiple Targets . . . . . . . . . . . . . . . . . . . . . . .
1.5.6
System with an Object Library . . . . . . . . . . . . . . . . . . . . . .

1-6

1.6

Rebuilding Software Systems ............................ .
1.6.1
Single Source System . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.2
Multiple Source System . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.3
Multiple Programming Language System .............. .
1.6.4
System with Included Files . . . . . . . . . . . . . . . . . . . . . . . .

1-7
1-8

1-9
1-11
1-13

1-16
1-18
1-20
1-21

1-21
1-21
iii

1.6.5
1.6.6

Chapter 2

1-22
1-22

MMS Description Files
2-1
2-2

Creating the Description File ............................. .
2.1.1
Writing Dependency Rules . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2
Specifying the Target on the Command Line . . . . . . . . . . . .
2.1.3
Using Mnemonic Names for Targets and Sources ........ .
2.1.3.1
Specifying Target and Source Files . . . . . . . . . . .
2.1.3.2
Specifying Multiple Targets and Sources ...... .
2.1.3.3
Hierarchy of Dependency Rule Application ..... .

2-6
2-7

Using Built-In Rules ................................... .
2.2.1
Suffixes Precedence List . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2
Default Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-10
2-12

2.3

Defining Your Own Macros .............................. .
2.3.1
Formatting Macro Definitions . . . . . . . . . . . . . . . . . . . . . . .
2.3.2
Order of Processing Macros . . . . . . . . . . . . . . . . . . . . . . .
2.3.3
Invoking Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4
Defining Macros on the Command Line . . . . . . . . . . . . . . . .

2-12
2-13
2-14
2-15
2-16

2.4

Using Special Macros .................................. .

2-18

2.5

Defining Your Own Rules ............................... .
2.5.1
Creating a User-Defined Rule . . . . . . . . . . . . . . . . . . . . . .
2.5.2
Using User-Defined Rules . . . . . . . . . . . . . . . . . . . . . . . . .

2-20

2.6

Using Action Lines .................................... .
2.6.1
Multiple Action Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.2
$STATUS and $SEVERITY . . . . . . . . . . . . . . . . . . . . . . . .
2.6.3
MMS$STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.4
Action Line Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.5
Ignore Prefix ( - ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.6
Silent Prefix (@) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.7
Action Line Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-22
2-23
2-25
2-25
2-25
2-26
2-27
2-27

2.7

Using Directives ...................................... .
2.7.1
.IGNORE Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7.2
.SILENT Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7.3
.DEFAULT Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7.4
.SUFFIXES Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-28
2-29

2.1

2.2

System with Multiple Targets . . . . . . . . . . . . . . . . . . . . . . .
System with an Object Library . . . . . . . . . . . . . . . . . . . . . .

2-4
2-4
2-6

2-8

2-20
2-21

2-31
2-32
2-33

2.7.5
2.7.6
2.7.7
2.7.8
2.7.9
2.7.10
2.7.11
2.7.12

Chapter 3

Adding a New File Extension to the Suffixes List ......... .
Using the .SUFFIXES Directive in a Description File ...... .
Building a System with a New File Extension ........... .
Using the .SUFFIXES Directive with CMS Files ......... .
.INCLUDE Directive ............................ .
.FIRST Directive .............................. .
.LAST Directive ............................... .
.IFDEF, .ELSE, and .ENDIF Directives ................ .

2-34
2-34
2-36
2-36
2-37
2-38
2-39
2-40

Advanced Description File Techniques

3.1

Using Double Colon Dependencies ........................ .

3-1

3.2

Maintaining a Library of Object Files ....................... .

3-2

3.3

Invoking MMS from a Description File ...................... .
3.3.1
Using the $(MMS) Reserved Macro ................. .
3.3.2
Process Quotas for MMS Subprocesses .............. .
3.3.3
Process Quotas for Using MMS .................... .
3.3.4
MMS Reserved Macros .......................... .

3-3
3-4
3-4
3-5
3-5

3.4

Invoking MMS from a Command Procedure .................. .

3-6

3.5

Invoking a Command Procedure from a Description File ......... .

3-9

3.6

Changing System Build Options .......................... .

3-10

3.7

Gathering Statistics ................................... .
3.7.1
Finding Missing Sources ......................... .
3.7.2
Creating a Checkpoint File ....................... .

3-12
3-12
3-12

3.8

Creating and Using Time Stamps ......................... .
3.8.1
Using DCL Symbols ............................ .
3.8.2
Using Included Files ............................ .

3-14

Deleting Files Selectively ............................... .
3.9.1
Using a Command Procedure ..................... .
3.9.2
Using a Macro Definition ......................... .

3-17

3.10

Using Parallel Processing ............................... .

3-19

3.11

Using MMS in Complex Examples ......................... .
3.11.1
MMS and Object Libraries ........................ .

3-20
3-20

3.9

3-13
3-15
3-17
3-18

3.11.2

Producing Multiple Outputs with MMS . . . . . . . . . . . . . . . . .
Independent Outputs . . . . . . . . . . . . . . . . . . . .
Dependent Outputs . . . . . . . . . . . . . . . . . . . . .
Multiple Outputs Work-Around . . . . . . . . . . . . . . . . . . . . . .

3.11.2.1
3.11.2.2
3.11.3

Chapter 4

Accessing Libraries with MMS
Creating and Accessing Files in VMS Libraries ................ .
4.1.1
Formatting Library Module Specifications . . . . . . . . . . . . . . .
4.1.2
Using Logical Names in a Library Module Specification .... .
4.1.3
Specifying Multiple Modules . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4
Accessing Library Modules with Non-VMS File

4-1
4-2
4-2
4-2

Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Special Macros with Library Specifications . . . . . . . . . .
Using Libraries as a Source . . . . . . . . . . . . . . . . . . . . . . . .

4-3
4-3
4-4

Using MMS with CMS .................................. .
4.2.1
Using CMS Commands in a Description File ........... .
4.2.2
Automatic Access of CMS Elements from Dependency

4-4
4-6

Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Explicit References to CMS Elements in Dependency Rules ..
Using CMS Elements to Build the System ............. .
Using CMS Libraries to Rebuild the System ............ .
Building a System from a Specified CMS Class ......... .
Building a System from a Previous Class . . . . . . . . . . . . . . .
Using the .INCLUDE Directive to Include CMS Files ...... .
Using a User-Defined Rule to Access a Single CMS
Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accessing a CMS Element Not in the Default CMS Library .. .
Accessing Description Files in CMS Libraries ........... .

4-6
4-7
4-8
4-10
4-13
4-15
4-18

4.3

Checking for Replacement of CMS Elements ................. .

4-19

4.4

Accessing Forms in an FMS Library ....................... .

4-20

4.5

Accessing Definitions in COD/Plus ........................ .

4-21

4.6

Using MMS with SCA .................................. .

4-22

4.1

4.1.5
4.1.6

4.2

4.2.3
4.2.4
4.2.5
4.2.6
4.2.7
4.2.8
4.2.9
4.2.10
4.2.11

3-26
3-27
3-27
3-28

4-18
4-18
4-19

Command Dictionary
MMS...............................................

Appendix A

CD-3

Error Messages

A.1

Message Display ..................................... .

A-1

A.2

Severity Levels

A-1

A.3

MMS Messages

A-2

Appendix B

MMS and UNIX make Comparisons

Appendix C

MMS Built-In Features

C.1

Default Macros ....................................... .

C-2

C.2

Default Macro Changes with the /SCA_LIBRARY Qualifiers ....... .

C-4

C.3

Special Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C-4

C.4

Suffixes Precedence List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C-6

C.5

Directives .......................................... .

C-6

C.6

Built-In Rules ........................................ .

C-7

C.7

Built-In Rules for Library Files ............................ .

C-9

C.8

Built-In Rules for the /SCA_LIBRARY Qualifier ................ .

C-10

C.9

Built-In Rules for CMS Access ........................... .

C-14

vii

Glossary

Index

Examples

viii

1-1
1-2
1-3

Description File Using Multiple Language Compilers .............. .

1-4

Description File Using Included Files . . . . . . . . . . . . . . . . . . . . . . . . . .

1-5
1-6

Description File Using Multiple Targets

2-5
2-6
2-7
3-1
3-2
3-3

Invoking a Command Procedure from a Description File ............ .

1-7
1-8
1-10
1-12
1-14
1-16
2-9
2-12
2-15
2-21
2-23
2-24
2-35
3-8
3-9

Command Procedure to Change Build Options . . . . . . . . . . . . . . . . . . .

3-10

3-4

Description File Using Object Libraries . . . . . . . . . . . . . . . . . . . . . . . .

4-1
4-2
4-3

Description File Using CMS Libraries . . . . . . . . . . . . . . . . . . . . . . . . .

3-20
4-8
4-9
4-11
4-14
4-15
4-23

Description File Using a Single Object . . . . . . . . . . . . . . . . . . . . . . . . .
Description File Using Multiple Objects . . . . . . . . . . . . . . . . . . . . . . . .

Description File Using Object Libraries . . . . . . . . . . . . . . . . . . . . . . . .

2-1

Built-In Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-2
2-3

Description File Using Built-In Rules . . . . . . . . . . . . . . . . . . . . . . . . . .
Macro Definitions in a Description File . . . . . . . . . . . . . . . . . . . . . . . . .

2-4

Description File Using a User-Defined Rule . . . . . . . . . . . . . . . . . . . . .
Description File Using Action Lines . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description File Using Multiple Action Lines . . . . . . . . . . . . . . . . . . . . .
Description File Using the .SUFFIXES Directive . . . . . . . . . . . . . . . . . .
Invoking MMS from a Command Procedure . . . . . . . . . . . . . . . . . . . . .

Building a System from CMS Library Elements . . . . . . . . . . . . . . . . . . .
Rebuilding Using CMS Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-4

Description File for Building from a CMS Class . . . . . . . . . . . . . . . . . . .

4-5
4-6

Building a System from a Previous CMS Class . . . . . . . . . . . . . . . . . . .
Using MMS with the /SCA_LIBRARY Qualifier . . . . . . . . . . . . . . . . . . .

Figures
1-1

Dependencies in a Single Source System . . . . . . . . . . . . . . . . . . . . . .

1-2

Multiple Source System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-9

1-3

Multiple Programming Language System . . . . . . . . . . . . . . . . . . . . . . .

1-11

1-4

Included Files in a System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-13

1-5

System with More than One Executable Image . . . . . . . . . . . . . . . . . . .

1-15

1-6

Object Library in a System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-18

1-7

How MMS Rebuilds a System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-19

1-6

2-1

Relationship Between Suffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-10

2-2

CMS Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-37

4-1

A Software System Using CMS Libraries . . . . . . . . . . . . . . . . . . . . . . .

4-5

Tables
2-1

MMS Action Line Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-26

2-2

MMS Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-29

3-1

MMS Process Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-5

C-1

MMS Default Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C-2

The /SCA_LIBRARY Qualifiers Default Macros . . . . . . . . . . . . . . . . . . .

C-4

C-3

MMS Special Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C-5

C-4

Suffixes Precedence List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C-5

MMS Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C-6
C-6

C-6

MMS Built-In Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C-7

Preface
This manual explains how to use VAX DEC/Module Management System
(MMS). The guide provides both tutorial and reference material to illustrate
basic and advanced techniques.

Intended Audience
This guide is primarily intended for software engineers but it can be used by
managers, technical writers, and other users who build systems.
MMS is patterned after the UNIX® make utility.

Document Structure
This guide is divided into four chapters, a command dictionary, three appendixes, and a glossary.
•
•
•
•

Chapter 1, Introduction to MMS, describes the basic concepts of MMS
and how MMS automates the software development cycle.
Chapter 2, MMS Description Files, discusses how to create and use
description files.
Chapter 3, Advanced Description File Techniques, discusses advanced
techniques for using MMS as efficiently as possible.
Chapter 4, Accessing Libraries with MMS, explains how MMS can process files stored in VMS, CMS, and VAX FMS libraries, and definitions
stored in CDD/Plus.

® UNIX is a registered trademark of American Telephone and Telegraph Company.

•
•
•
•
•

The Command Dictionary describes the MMS command line format and
contains detailed descriptions of all MMS qualifiers.
Appendix A, Error Messages, lists and explains all MMS messages.
Appendix B, MMS and UNIX make Comparisons, describes the differences between MMS and UNIX make features.
Appendix C, MMS Built-In Features, contains tables of MMS defaults
and includes explanatory information.
The Glossary defines important terms.

Associated Documents
•
•

The VAX DEC I Module Management System Installation Guide supplies
the instructions for installing MMS on a VMS system.
Using VAXset describes how to use VAX Software Engineering Tools
(VAXset) with other VMS facilities to create an effective software development environment.

Conventions
The following conventions are used in this guide:
Convention

Meaning

Ctrl/x

A sequence such as CTRUx indicates that you must hold
down the key labeled Ctrl while you press another key or
a pointing device button.

KPn

A sequence such as KPl indicates that you must first
press and release the key labeled KPl, then press and
release another key or a pointing device button.
In examples, a horizontal ellipsis indicates one of the
following:
•
•
•

xii

Additional optional arguments in a statement have
been omitted.
The preceding item or items can be repeated one or
more times.
Additional parameters, values, or other information
can be entered.

Convention

Meaning
A vertical ellipsis indicates the omission of items from
a code example or command format; the items are omitted because they are not important to the topic being
discussed.

()

In format descriptions, parentheses indicate that if
you choose more than one option, you must enclose the
choices in parentheses.

[]

In format ~escriptions, brackets indicate that whatever
is enclosed is optional; you can select none, one, or all of
the choices.

{}

In format descriptions, braces surround a required choice
of options; you must choose one of the options listed.

user input

The hardcopy version of this manual has interactive
examples that show user input in red letters and system
responses or prompts in black letters. The online version differentiates user input from system responses or
prompts by using a different font.

bold text

Boldface text represents the introduction of new terms.

UPPERCASE TEXT

Uppercase letters indicate the name of a command or
routine. Lowercase words and letters used in examples
indicate that you should substitute a word or value of
your choice.
The OR symbol separates alternatives within braces or
brackets. For example, filespec I "macro" means that you
must type either a file specification or a macro enclosed
in quotation marks.

'string'

A term enclosed in apostrophes is information that can
vary. (This convention is used frequently in Appendix A.)

xiii

Chapter 1

Introduction to MMS
This chapter describes the VAX DEC/Module Management System (MMS)
and provides information on the following topics:

1.1

•

An overview of MMS

•
•

Invoking MMS
Getting help

•
•
•

MMS concepts
Building the software system
Rebuilding the software system

Overview
A software system can have many program files, object libraries, included
files, compilers, and compilation and linking options. The more complex the
system, the more difficult it is to reproduce the same program image for
each build.
MMS automates and simplifies the building of software systems. It can
build simple programs consisting of one or more source files, or complex
programs consisting of many source files, message files, and documentation
files.
With MMS, you can specify exactly how a software system is to be built
and rebuilt. You do this by using a description file in which you describe
the components of the system and the file dependencies used to build and
rebuild the system. A file dependency occurs when one or more files are
needed to build another file. For example, the existence of an executable file
depends on an object file.

Introduction to MMS

1-1

Each time you run MMS, it follows the description file you have created,
reads the components and dependencies, and builds the same system.
MMS can also rebuild systems quickly when parts of the system change.
MMS keeps track of source and included files. If any of the files in a
software system change or are missing, MMS can determine which files are
affected by the changed or missing files, then rebuild the affected portions of
the system by using the sources for the changed or missing files. MMS does
not rebuild portions of the system that have not changed, thus saving both
processing time and storage space.
With MMS, you can also build and test modules locally before building or
testing the modules in the source directory or library.
MMS is patterned after the UNIX make utility (see Appendix B).

1.2 Invoking MMS
You invoke MMS from the DCL command line as follows:
$

MMS

MMS then attempts to process the default description file DESCRIP.MMS in
your current directory. If DESCRIP.MMS does not exist, MMS attempts to
process a description file called MAKEFILE. If MAKEFILE. does not exist,
MMS attempts to process a file called target-name.MMS. If all of these files
exist, MMS uses only DESCRIP.MMS. If none of these files exist, MMS uses
built-in rules to build the target (see Section 1.4.5).
You can also invoke MMS with a specified description file, called
SYSTEMl.MMS in this example:
$

MMS/DESCRIPTION=SYSTEMl

MMS uses the .MMS file type when none is specified.
For information on creating a description file, see Section 2.1. For more
information on invoking description files, see Sections 2.1.2 and 2.1.3. For
information on MMS syntax and qualifiers, see the Command Dictionary.

1-2

Introduction to MMS

1.3 Getting Help
You can get information about MMS at either the DCL ( $) or MMS level. At
the DCL level, the DCL command HELP MMS provides online help on MMS
qualifiers and other topics. For example:
$

HELP MMS

To get help on a specific topic, such as the /MACRO qualifier, type the
qualifier after the HELP MMS command. For example:
$

HELP MMS/MACRO

At the MMS level, the MMS qualifier /HELP gives general information
about MMS and a list of topics, then returns you to the DCL level. For
example:
$

MMS/HELP

To get help at the MMS level on a specific MMS topic, follow the /HELP
qualifier with an equal sign and the topic name enclosed in quotation marks
(" "). For example:
$

MMS/HELP="/MACRO"

1.4 MMS Concepts
This section explains basic MMS concepts.

1.4.1

Description Files
The description file contains definitions that describe to MMS all the
components of a system build: the source files that make up the system, the
compilers that will be used, the order in which to link the software modules,
and the libraries to use when the modules are linked.
The description file also contains the components that are the definitions
for the logical dependencies in the software system. For example, it can
contain definitions for the included files used in source files, the source files
that make up each object, the objects that make up each image, and the
libraries used in a link. See Section 1.4.6 for more information on how MMS
uses dependencies.

Introduction to MMS

1-3

Each time you run MMS, it follows the description file and builds the same
system (you can use older description files to re-create previous versions of
the system). After a system is built once, MMS uses the dependencies to
rebuild the system.
For information on creating a description file, see Chapter 2.

1.4.2 Targets
A target is any file that must be built to complete the software system (a
target can also be a mnemonic name; see Section 2.1.3 for more information).
You can think of a target as the goal of building the system. Targets are
usually executable image files, but they can also be object files. For example,
executable files are targets for object files, and object files are targets for
source files.

1.4.3

Sources
Sources are used to create targets. For example, a file with programming
code is a source for an object file, and an object file is a source for an
executable file.

1.4.4 Action Lines
An action line is a DCL or DEC/Shell command that MMS uses to update
the target. The commands in the action lines tell MMS how to build the
target. Built-in rules (see Section 1.4.5) allow MMS to build only one target;
action lines override this rule.

For example, the PASCAL command is the action line that uses X.PAS to
update X.OBJ, and the LINK command is the action line that uses X.OBJ to
update X.EXE.
Action lines follow target or source'lines and specify how to use the source
file to create the target. You must indent the action line and leave a blank
line before the next dependency rule. For example:
MAIN.EXE DEPENDS_ON MAIN.OBJ
LINK MAIN.OBJ
MAIN.OBJ DEPENDS_ON MAIN.PAS

In this example, the action line is LINK MAIN.OBJ.

1-4

Introduction to MMS

1.4.5

Built-in Rules
MMS uses built-in rules to create targets with specific file types. Built-in
rules are based on file extensions. A built-in rule is an action that builds a
target based on the file extension from the target's source file. For example,
executable targets are created by default with the .EXE file type; object file
targets are created with the .OBJ file type.
MMS also uses built-in rules to determine which compiler to use. For
example, MMS uses the Pascal compiler for files with the .PAS file type and
the FORTRAN compiler for files with the .FOR file type.
A software system must follow built-in file-naming conventions for built-in
rules to work.

1.4.6

Dependencies
As you describe a system to MMS, you also state logical dependencies
in that system. For example, by using the DEPENDS_ON keyword, a
simple description file called SYSTEMLMMS could contain the following
dependencies:
MAIN.EXE DEPENDS ON MAIN.OBJ
MAIN.OBJ DEPENDS_ON MAIN.PAS

SYSTEMl.MMS is a description file that describes a single source software
system. The executable image, MAIN .EXE, is the target of building the
system. The executable image comes from one object file, MAIN.OBJ. The
object file is generated from one file of source code, MAIN.PAS.
Figure 1-1 shows the relationship between the files.

Introduction to MMS

1-5

Figure 1-1:

Dependencies in a Single Source System

MAIN.EXE

l
MAIN.OBJ

J
MAIN.PAS
ZK-5883-GE

MMS builds its own internal dependency tree. In general, MMS creates
targets from the bottom up; that is, it searches for the source for the first
target and then the source of the first target's source. It first builds the
targets at the bottom of the dependency tree, then builds the targets that
use those sources, then builds the targets that use those sources, and so on,
until the primary target is built. MMS uses built-in rules (unless action
lines are specified) to build the software system.
For example, MMS first creates an object file from a source code file, then it
creates the executable file from the object file.

1.5 Building Software Systems
MMS can build simple systems or complex systems with many files of source
code, multiple language compilers, and executable images. MMS builds the
systems by using its built-in features and information obtained from the
description file.
This section contains system-building information on the following topics:
•
•

Single object systems
Multiple object systems

1-6 Introduction to MMS

1.5.1

•

Multiple language systems

•
•
•

Multiple included files systems
Multiple executable image systems
Multiple object libraries systems

Single Source System
Example 1-1 shows a sample description file, called SYSTEMl.MMS, with a
single object defined in it. The example uses comment lines, denoted by the
exclamation point ( ! ), and blank lines for readability.
Example 1-1:

Description File Using a Single Object

Description file SYSTEMl.MMS
MAIN.EXE DEPENDS ON MAIN.OBJ
MAIN.OBJ DEPENDS_ON MAIN.PAS

In this example, the target MAIN.EXE has one source file, MAIN.OBJ.
Both the source file MAIN.PAS and the description file SYSTEMl.MMS
must be located in your current directory. After you create the description
file (see Chapter 2), you invoke MMS with the following command:
$

MMS/DESCRIPTION=SYSTEMl

MMS builds the system by using the description file SYSTEMl.MMS as
follows:
1. Locates the first target (MAIN.EXE) in the description file.

Creates a dependency tree to determine which files need to be built.

3. Uses built-in rules to determine that MAIN.PAS is a Pascal program,
and then creates the target object file MAIN.OBJ from the source file
MAIN.PAS and places it in your current directory. The built-in rule for
building .OBJ files from .PAS files is as follows:
PASCAL/NOLIST/OBJECT=MAIN MAIN.PAS

Introduction to MMS 1-7

4. Uses built-in rules to determine that MAIN.OBJ is an object file, and
then creates the target executable file MAIN.EXE from the source file
MAIN.OBJ and places it in your current directory. The built-in rule for
building .EXE files from .OBJ files is as follows:
LINK/TRACE/NOMAP/EXEC=MAIN MAIN.OBJ

Do not delete object files after using MMS, as MMS would then automatically recompile all the source code files the next time it is invoked. If none
of your targets or source files is missing or changed since your last system
build, MMS displays the following message:
$ MMS/DESCRIPTION=SYSTEM2
%MMS-I-GWKCURRNT, Target MAIN.EXE is already up-to-date.

1.5.2

Multiple Source System
Targets can have more than one source file. This section describes how to
create and execute description files with multiple objects.
Example 1-2 shows a sample description file, called SYSTEM2.MMS, with
more than one object defined in it.
Example 1-2:

Description File Using Multiple Objects

SYSTEM2.MMS
MAIN.EXE DEPENDS_ON MAIN.OBJ, SUBl.OBJ
LINK MAIN.OBJ, SUBl.OBJ
MAIN.OBJ DEPENDS ON MAIN.PAS
SUBl.OBJ DEPENDS ON SUBl.PAS

In this example, the target MAIN.EXE has two sources, MAIN.OBJ and
SUBl.OBJ. The second line of the description file is the action line, which
tells MMS how to build the target.
After you invoke MMS with the SYSTEM2.MMS description file, MMS
builds the system as follows:
1. Locates the first target (MAIN.EXE) in the description file.

2. Creates a dependency tree to determine which files need to be built.
3. Uses built-in rules to create MAIN.OBJ from MAIN.PAS.
4. Uses built-in rules to create SUBl.OBJ from SUBl.PAS.
1-8

Introduction to MMS

5. Uses the action line (which overrides the built-in rule that allows MMS
to link only one object file) to create MAIN.EXE from the newly created
MAIN.OBJ and SUBl.OBJ.
Figure 1-2 shows the relationship between the files.
Figure 1-2:

Multiple Source System

MAIN.EXE

f--

MAIN.OBJ

SUB 1.0BJ

MAIN.PAS

SUB 1.PAS
ZK-5886-GE

1.5.3

Multiple Programming Language System
Using the built-in rules for file extensions, MMS can create object and
executable files from program files that are created using different programming languages. MMS uses the different file types to choose the correct
compiler during the system build.
Example 1-3 shows the sample description file MULTI_LANG.MMS.

Introduction to MMS

1-9

Example 1-3:

Description File Using Multiple Language Compilers

MULTI LANG.MMS
!Main executable target, its objects and action line
!
MAIN.EXE DEPENDS_ON MAIN.OBJ, SUBl.OBJ, SUB2.0BJ, SUB3.0BJ
LINK MAIN, SUBl, SUB2, SUB3
!Source code dependencies
!
MAIN.OBJ DEPENDS ON MAIN.PAS
SUBl.OBJ DEPENDS ON SUBl.PAS
SUB2.0BJ DEPENDS ON SUB2.FOR
SUB3.0BJ DEPENDS-ON SUB3.FOR

After you invoke MMS with the MULTI_LANG.MMS description file, MMS
builds the system as follows:
1. Locates the first target (MAIN.EXE) in the description file.

2. Creates a dependency tree to determine which files need to be built.
S. Uses built-in rules to create MAIN.OBJ from MAIN.PAS by using the
Pascal compiler.
4. Uses built-in rules to create SUBl.OBJ from SUBl.PAS by using the
Pascal compiler.
5. Uses built-in rules to create SUB2.0BJ from SUB2.FOR by using the
FORTRAN compiler.
6. Uses built-in rules to create SUBS.OBJ from SUBS.FOR by using the
FORTRAN compiler.
7. Uses the action line to create MAIN.EXE from the newly created
MAIN.OBJ, SUBl.OBJ, SUB2.0BJ, and SUBS.OBJ.
Figure 1-S shows the relationship between the files.

1-10

Introduction to MMS

Figure 1-3:

Multiple Programming Language System

MAIN.EXE

MAIN.OBJ

SUB 1.0BJ

SUB 2.0BJ

SUB3.0BJ

MAIN.PAS

SUB 1.PAS

SUB2.FOR

SUB3.FOR
ZK-2021 A-GE

1.5.4

System with Included Files
Included files are frequently used in software development projects.
Included files can contain code, such as a set of variables, or constant
declarations. The included files are shared between developers. Individual
programmers do not have to maintain their own separate copies of these
included files; they just include the common file once.
If an included file changes, all developers using the included file automatically receive the new code the next time they use the common file. In this
case, all source files that use the common file must be recompiled; however,
MMS detects this change and automatically recompiles the next time you
perform a build.

The ability of MMS to handle included files ensures accurate system building. In a large system, you might not remember which compilation depends
on which included file and you might forget to perform the compilations
when an included file changes. When writing your MMS description file,
inspect all your source code files for statements that include other files. You
can use the DCL command SEARCH to search for these statements.

Introduction to MMS

1-11

The description file must specify any included files on the same line as the
program code that uses them, as in Example 1-4. You can list the included
files in any order.
Example 1-4: Description File Using Included Files

INCLUDE.MMS
Main executable target, its objects, and action line
MAIN.EXE DEPENDS_ON MAIN.OBJ, SUBl.OBJ, SUB2.0BJ
LINK MAIN, SUBl, SUB2
Source code files with included files COPY- 1.PAS and COPY- 2.PAS
MAIN.OBJ DEPENDS_ON MAIN.PAS, COPY_l.PAS, COPY 2.PAS
SUBl.OBJ DEPENDS_ON SUBl.PAS, COPY_l.PAS
SUB2.0BJ DEPENDS ON SUB2.PAS

When MMS processes the description file INCLUDE.MMS in Example 1-4,
it also processes the included files COPY_l.PAS and COPY_2.PAS when
it processes MAIN.PAS. The included file COPY_l.PAS is processed again
when MMS processes SUBl.PAS.
Figure 1-4 shows the relationship between the files.

1-12

Introduction to MMS

Figure 1-4: Included Files in a System

MAIN.EXE

l
l

MAIN.OBJ

SUB 1.0BJ

SUB 2.0BJ

SUB 1.PAS

SUB2.PAS

MAIN.PAS

I-

1
COPY_2.PAS

COPY_1.PAS
ZK-5884-GE

If you specify files to be included that do not exist, MMS displays an error
message and stops.

1.5.5 System with Multiple Targets
If an executable image is especially complicated, place it in its own description file. Also place executable images that are not related in some
significant way in separate description files. However, if a system has
a number of executable images that use common object files, it is more
efficient to build them using one description file.

This type of description file is layered with the overall target first, followed
by the executable images, the object files, and the source code files. You can
choose to build the entire system or selected executable files.

Introduction to MMS

1-13

Example 1-5 shows the sample description file MULTI_EXES.MMS.
Example 1-5: Description File Using Multiple Targets

MULTI EXES.MMS
Overall system target--this is a dummy target name
SYSTEMX DEPENDS ON MAIN.EXE, PROGl.EXE, PROG2.EXE
! no special action intended for overall system target
! What follows is the executable images and their object files
!

MAIN.EXE DEPENDS_ON MAIN.OBJ, SUBl.OBJ
LINK MAIN.OBJ, SUBl.OBJ
PROGl.EXE DEPENDS ON PROGl.OBJ
LINK PROGl.OBJ
PROG2.EXE DEPENDS ON PROG2.0BJ
LINK PROG2.0BJ
The object files and their sources
MAIN.OBJ DEPENDS ON MAIN.PAS
SUBl.OBJ DEPENDS ON SUBl.PAS
PROGl.OBJ DEPENDS ON PROGl.PAS
PROG2.0BJ DEPENDS ON PROG2.PAS

In this example, the description file MULTI_EXES.MMS contains the target
SYSTEMX, which is the overall target of building the system. There are no
built-in rules for targets that do not have file types, and since no action line
is specified, SYSTEMX has a null action and simply builds the executable
files. The three executable images come from their object files. All the
object files and source files have the same dependencies as in the previous
examples.
After you invoke MMS with the MULTI_EXES.MMS description file, MMS
builds the system as follows:
1.

Locates the first target (SYSTEMX) in the description file.

2. Creates a dependency tree to determine which files need to be built.
3. Uses built-in rules to create MAIN.OBJ from MAIN.PAS by using the
Pascal compiler.
4. Uses built-in rules to create SUBLOBJ from SUBLPAS by using the
Pascal compiler.
1-14

Introduction to MMS

5. Uses the action line to create MAIN.EXE from MAIN.OBJ and
SUBl.OBJ.
6. Locates the second target (PROGl.EXE) in the description file, and
so on.
Figure 1-5 shows the relationship between the files.
Figure 1-5: System with More than One Executable Image

SYSTEM

l
l

MAIN.EXE

PROG1.EXE

PROG2.EXE

MAIN. OBJ

SUB1.0BJ

PROG1.0BJ

PROG2.0BJ

MAIN.PAS

SUB1.PAS

PROG1.PAS

PROG2.PAS

ZK-5885-GE

Building a Specific Target

In a multiple target system, to build a specific target or executable image
you must include a target name on the command line. For example:
$

MMS/DESCRIPTION=MULTI_EXES PROG1.EXE,PROG2.EXE

When you specify the target name on the command line, MMS overrules its
default of building the first target in the description file; only the targets you
specify are built.

Introduction to MMS 1-15

1.5.6 System with an Object Library
This section assumes that you have some knowledge of VMS libraries.
Object libraries are useful for quick compiling and linking during debugging
sessions. MMS creates libraries, inserts modules, and updates libraries
during software system builds.
An object library is a single file that contains multiple object files,
otherwise known as object modul~s. The object library is usually named
with a file type of .OLB. The object file name is a VMS file name, usually
named with a file type of .OBJ. The object module name is governed by the
TITLE, MODULE, PROGRAM, or SUBROUTINE name in the source file.
The object file name and the object module name are frequently the same.
To include an object library in an MMS description file, you must include the
library name, the object module name, and the object file name. The object
library name follows the target's main source. The object module name and
the object file name follow the library name, enclosed in parentheses and
separated with an equal sign. No spaces are allowed.
Example 1-6 shows the sample description file OBJECT_LIB.MMS.
Example 1-6: Description File Using Object Libraries

OBJECT_LIB.MMS
Main executable target, its objects, and action line
MAIN.EXE DEPENDS_ON

MAIN.OBJ, MAIN_LIB.OLB(OPTIM=OPTIM.OBJ), MAIN_LIB.OLB(GET_RECORD=GETREC.OBJ), MAIN LIB.OLB(PUT RECORD=PUTREC.OBJ)
LINK MAIN.OBJ, MAIN_LIB/LIB
-

Program source code files
MAIN.OBJ DEPENDS ON MAIN.FOR
OPTIM.OBJ DEPENDS ON OPTIM.FOR
GETREC.OBJ DEPENDS ON GETREC.FOR
PUTREC.OBJ DEPENDS_ON PUTREC.FOR

1-16 Introduction to MMS

In this example, the executable image MAIN.EXE depends on one object
library (MAIN_LIB.OLB). The object module OPTIM comes from the object
file OPTIM.OBJ. The object modules GET_RECORD and PUT_RECORD
come from the object files GETREC.OBJ and PUTREC.OBJ, respectively.
Note that the first object module and object file name have the same name,
and the following two object modules and file names have different names.
MMS builds the object library in Example 1-6 as follows:
1. Compiles the source file for each object file.

2. Checks for the existence of the library and creates it if it does not exist.
3. Inserts each object file into the library (or replaces it, if it already exists).
Figure 1-6 shows the relationship between the files.

Introduction to MMS

1-17

Figure 1-6: Object Library in a System

MAIN.EXE

MAIN_LIB.OLB
OPTIM
GET_RECORD
PUT_RECORD

MAIN.OBJ

OPTIM.OBJ

GETREC.OBJ

PUTREC.OBJ

MAIN.FOR

OPTIM.FOR

GETREC.FOR

PUTREC.FOR
ZK-2022A-GE

1.6 Rebuilding Software Systems
During the development cycle, MMS can determine which components in a
system are missing or changed, and what other components are affected by
these changes. For example, if you change several source files, MMS can
determine which corresponding object modules need to be updated and can
then update them. The entire system is not rebuilt, only those components
whose sources have been modified. MMS checks the modification dates of
executable files against their source files. If the source files are newer than
the executable files, MMS rebuilds the executable files; if the source files are
older than the executable files, MMS determines that the executable files

1-18

Introduction to MMS

are up-to-date and does not rebuild them. MMS builds only targets whose
sources are newer than their targets, saving you time and disk space.
To rebuild a system, invoke MMS as you would for an initial build.
Figure 1-7 depicts a small software system and describes the basic steps
MMS follows when it builds the system. In this system, Component A is the
target, Component Bis a source file for Component A, and Components C
and Dare source files for Component B. The commands that update B (by
using C and D) and A (by using the updated B) are the actions.
Figure 1-7:

How MMS Rebuilds a System

•

'..

I
I

\
\

' ' ....

-- -

I
I
/
/

- -- ....

;

ZK-1090-GE

0 MMS checks the revision time of the target (Component A).
8 MMS checks the revision time of the first source file (Component B).
8 MMS checks the revision time of Components C and D against that of B.

Introduction to MMS

1-19

8 If the times of Components C or D are more recent than that of

Component B, MMS updates B. according to the action lines that you
specify in the description file. If B is more recent than C and D, MMS
does not do anything because Bis already up-to-date.
Once Component Bis updated, it is more recent than the target
Component A; therefore, MMS updates Component A.

If the target has been modified since the source files were last changed,
MMS does not update the target. Instead, it displays a message informing
you that the target is already up-to-date.
If any file listed in the description file is missing, MMS attempts to create
it from the missing file's source. For example, if MAIN.OBJ is deleted from
the directory, when MMS builds the system, it creates MAIN.OBJ from the
MAIN.PAS program file.
If you delete an object file but still have the executable file, MMS recompiles the source file and also relinks the executable file, even though your
executable file is still compatible with your source file. MMS works from the
bottom up and propagates any change up the dependency tree. However,
if you delete your source file, MMS returns a fatal error because it cannot
re-create source code from object or executable files.
If you rebuild a complete system without regard to which components need
updating, you waste disk space. Use the /SKIP_INTERMEDIATE qualifier
to avoid unnecessary building of intermediate files. For example, if you have
a source file (PROG.C) and an executable file (PROG.EXE), but no intermediate file (PROG.OBJ), when you use the /SKIP_INTERMEDIATE qualifier,
MMS does not re-create the intermediate file as long as the executable file is
newer than the source file.

1.6.1

Single Source System
When rebuilding single source systems, MMS checks the system from the
bottom up to see if it is complete and up-to-date. If any part of the system is
missing or any target is older than its sources, the system is re-created.
For example, if you edit the source file MAIN.PAS, it would be newer than
its object file, MAIN.OBJ. When you invoke MMS, it does the following:
1. Finds the first target in the description file (MAIN.EXE).

2. Finds the source for MAIN.EXE (MAIN.OBJ) and its source
(MAIN.PAS).
3. Compiles the source code file MAIN.PAS because MAIN.PAS is newer
than its target MAIN.OBJ.
1-20

Introduction to MMS

4. Relinks the object file MAIN.OBJ because MAIN.OBJ is now newer than
its target, MAIN.EXE.

1.6.2

Multiple Source System
If you edit one of the source files in a multiple source system (for example,
the source file SUBl.PAS), it will be newer than its object file, SUBl.OBJ.
When you invoke MMS, it does the following:
1. Finds the first target in the description file (MAIN.EXE).

2. Finds the sources for MAIN.EXE (MAIN.OBJ and SUBl.OBJ) and their
sources (MAIN.PAS and SUBl.PAS).
3. Compiles the source code file SUBl.PAS because SUBl.PAS is newer
than its target SUBl .OBJ.
4. Uses the action line to create MAIN.EXE from MAIN.OBJ and
SUBl.OBJ.
5. Because MAIN.OBJ is newer than MAIN.PAS, MMS does not compile
MAIN.PAS. However, MAIN.EXE is now older than one of its source files
(SUBl.OBJ), so MMS relinks the object file MAIN.OBJ, using the action
line.

1.6.3

Multiple Programming Language System
If you edit two source files in a multiple programming language system (for
example, MAIN.PAS and SUBS.FOR), they will be newer than their object
files, MAIN.OBJ and SUB3.0BJ. MMS compiles only the source code that
has been updated, and uses the correct language compiler in each case. It
then links all the objects to re-create the executable image.

1.6.4 System with Included Files
If you edit the included file COPY_l.PAS in a multiple programming
language system, it is newer than any other source file used to build
MAIN.EXE. When you invoke MMS, both MAIN.PAS and SUBl.PAS (which
both include COPY_l.PAS) are recompiled, and all necessary objects are
relinked.
If you also edit COPY_2.PAS and then rebuild the system, only MAIN.PAS
is recompiled, and all necessary objects are relinked.

Introduction to MMS

1-21

1.6.5

System with Multiple Targets
If you delete one of the executable files in your current directory (for
example, PROG2.EXE), when you invoke MMS, it must link PROG2.0BJ
to produce PROG2.EXE. MMS performs only the link necessary to complete
the system.

1.6.6

System with an Object Library
If you edit the source file GETREC.FOR, when you invoke MMS, it does the
following:

Locates the first target (MAIN.EXE) in the description file.
2. Creates a dependency tree to determine which files need to be rebuilt.
3. Uses built-in rules to recompile GETREC.FOR, thereby producing
GETREC.OBJ.
4. Uses built-in rules to replace module GET_RECORD in the object library
MAIN_LIB.OLB with the new GETREC.OBJ.

5. Uses the action line to create a new version of MAIN.EXE.

1-22 Introduction to MMS

Chapter 2

MMS Description Files
The first step in using MMS is to write a description file for the system
you want to build. The description file is a text file that describes how to
build a software system, and explains the relationships among the various
components of your system. The description file can contain some or all of
the following elements:
•

Targets (usually executable images)

•
•

Intermediate files (usually object files)
Source files (usually program code)

•

Action lines

•
•

Comment Lines
Built-in rules

•
•

User-defined rules
Directives

This chapter describes how to create a description file, and how the elements
of the description file work together to build a system.

2.1

Creating the Description File
You create and modify the description file with any text editor. For example:
$

LSEDIT DESCRIP.MMS

When you invoke MMS, it first attempts to process the default description
file DESCRIP.MMS in your current directory. If DESCRIP.MMS does not
exist, MMS attempts to process a description file called MAKEFILE. If
MAKEFILE does not exist, MMS attempts to process a description file called

MMS Description Files

2-1

target-name.MMS. If all of these files exist, MMS uses only DESCRIP.MMS.
If none of these files exist, MMS uses built-in rules to build the target.
You can also invoke MMS with a specified description file, called
SYSTEMl.MMS in this example:
$

MMS/DESCRIPTION=SYSTEMl

MMS uses the .MMS file type when none is specified.
Once MMS locates the description file, it processes it by building the first
target in the description file. However, if the description file is targetname.MMS, MMS attempts to build the actual target on the command line,
not the first target in the description file (see Section 2.1.2).
To direct MMS to override a description file, use the /NODESCRIPTION
qualifier and the target name on the MMS command line as follows:
$

MMS/NODESCRIPTION filename

When you specify /NODESCRIPTION, MMS does not look for a description
file but instead relies entirely on its built-in rules to update the target. See
the Command Dictionary for more information on the /[NO]DESCRIPTION
qualifier.

2.1.1

Writing Dependency Rules
A description file contains dependency rules. Dependency rules indicate
how files depend on, or are affected by, other files and specify the actions
MMS takes to build or update your system.
A dependency rule consists of targets, optional sources, an optional action
line, and an optional comment for each target and source line. The syntax of
a dependency rule is as follows:
target... : [source ...] [!comment] [action line ... ] [!comment]

target
Specifies a VMS file specification or a mnemonic name (Section 2.1.3
describes mnemonic names). The file specification can be complete, including
node information. MMS locates the target file in your current default
directory unless you specify another directory in your file specification.
source
Specifies a VMS file specification or a mnemonic name (Section 2.1.3
describes mnemonic names). The file specification can be complete, including
node information. MMS locates source files in your current default directory
unless you specify other directories in your file specification.
2-2

MMS Description Files

comment

Specifies a string of text, introduced by an exclamation point ( ! ). The comment provides detailed information in the description file. You can continue
a comment line onto the next line with the hyphen or backslash. MMS
considers any text on the next line following the continuation character as
part of the comment line.
action line

Specifies a command-language command that MMS uses to update the
target. You can specify any number of action lines for a target. An action
line is positioned below the corresponding target or source line and must be
indented by at least one space or tab. MMS interprets all indented lines as
action lines and associates them with the most recently specified target or
source line.
If you omit the action line, MMS uses built-in rules to update the target if a
built-in rule exists. (See Section 2.2 for an explanation of built-in rules.)

You begin a target or source line in column 1 of the line and use the keyword
DEPENDS_ON or the colon (:)to separate the target from the source. If
you use a colon to separate the target from the source, insert at least one
space or tab on either side of the colon, or MMS will interpret the colon as
part of a VMS file specification.
To improve the readability of description files, separate dependency rules
from each other with one or more blank lines. Do not use blank lines
between the action lines of a single dependency rule, because a blank line
signals the end of the dependency rule.
Any line in a description file can be continued onto the next line with a
hyphen (- ). This practice makes the description file easier to read when a
dependency rule is too long to fit on one line. For example:
. . TESTS.OBJ DEPENDS ON ~
TESTl.BAS, --! Source modules for TESTS.OBJ- @)
TEST2.BAS, TEST3.BAS, TEST4.BAS, TESTS.BAS
BASIC/OBJECT=TESTS TESTl+TEST2+TEST3+TEST4+TEST5

0 The hyphen means that the next line is treated as part of the current
line.

8 The second through fifth lines are continuations of the target or source
line.

MMS Description Files

2-3

6) A comment can appear after a continuation character without affecting
the processing of the description file.
NOTE

When a hyphen appears as the last character on a line, MMS
interprets the hyphen as a continuation character, even if the
hyphen is part of a comment.

2.1.2

Specifying the Target on the Command Line
By default, MMS updates the first target specified in the description file.
You can force MMS to update a target other than the first one by explicitly
including the target name on the MMS command line. Consider the
following description file:
TEST.OBJ DEPENDS ON A.OBJ B.OBJ
LINK/EXE=TEST A,B
A.OBJ DEPENDS ON A.FOR
B.OBJ DEPENDS ON B.FOR
PRINT DEPENDS ON
PRINT A.FOR, B.FOR

If you specify MMS PRINT on the command line, MMS searches the
description file for the dependency rule associated with PRINT, the specified
target. MMS tries to update the target PRINT rather than TEST.OBJ, the
default. If PRINT is up-to-date, no action takes place. See the description
of the /NODESCRIPTION qualifier in the Command Dictionary for more
information.

MMS updates all sources and their dependencies before updating the main
target. MMS checks all sources before it updates a target, because sources
may themselves be targets with sources in other dependency rules.

2.1.3

Using Mnemonic Names for Targets and Sources
You can use a mnemonic name for a source or a target but you must supply
the action lines that update the target. A mnemonic name is a name that
identifies the purpose of a sequence of related actions. MMS relies on the
source and target file types to apply built-in rules. Section 2.2 describes how
MMS uses built-in rules.

2-4

MMS Description Files

You can use a mnemonic name to represent a source only if it is also a target
in a dependency rule in your description file. If MMS encounters a name
for which it cannot find a matching file in the specified directory, it assumes
that the name is a mnemonic name.
Mnemonic names are useful in several cases. For example:
•
•
•

To update more than one file
To group a variety of related actions under a name that identifies the
purpose of the whole sequence
To give a name to a common action or sequence of actions in building a
system

By default, MMS builds only one target. To update several targets, you
make them sources in a dependency rule by using a mnemonic name for the
target as follows:
NEW_SYSTEM DEPENDS_ON A.EXE, B.EXE
! no action needed
A.EXE DEPENDS_ON A.OBJ
LINK A.OBJ
B.EXE DEPENDS_ON B.OBJ
LINK B.OBJ

MMS considers the target NEW_SYSTEM as updated when it executes the
action line or lines that follow it. Both A.EXE and B.EXE are updated, if
necessary.
The following example shows the use of mnemonic names as both targets
and sources. MMS updates the target, ALL, by updating the two sources,
PROG.EXE and PRINT, which are themselves targets in subsequent
dependency rules.
ALL DEPENDS_ON FROG.EXE, PRINT
! system completely built and the sources printed
FROG.EXE DEPENDS ON MODl.OBJ, MOD2.0BJ, MOD3.0BJ
LINK/EXEC=PROG MODl.OBJ, MOD2.0BJ, MOD3.0BJ
PRINT DEPENDS_ON MODl.C, MOD2.C, MOD3.C, DEFSl.H, DEFS2.H
! Print the source files
PRINT MODl.C, MOD2.C, MOD3.C, DEFSl.H, DEFS2.H

MMS Description Files

2-5

2.1.3.1

Specifying Target and Source Files

If you specify an action line but omit the source from a dependency rule,
MMS executes the action line only if the target does not exist in the specified
directory. For example, consider the following dependency rule:
[SYSTEMl]TESTS.OBJ :
PASCAL/DEBUG [SYSTEMl]TESTS.PAS

In this example, MMS executes the PASCAL command only if TESTS.OBJ
does not exist in the directory [SYSTEMl].
As MMS checks the revision dates and times of targets and sources, it builds
a list of times, which it uses in deciding when a target needs to be updated.
If there is no file associated with a target or source (for example, if the
target does not exist), MMS records a revision time for it that is older than
the times of all other existing targets and sources: 17-NOV-1858 00:00:00.0.
(This is the oldest time used by VMS.) All targets and sources that are not
existing files are assigned this revision time.
2.1.3.2

Specifying Multiple Targets and Sources

A description file can contain many dependency rules; however, MMS builds
only one target. You can specify several targets on the MMS command
line, but each target is executed as a separate invocation of MMS with the
specified set of qualifiers.
To specify multiple targets and sources, you must separate them with
commas, spaces, or a combination of both. MMS expands the specification
of multiple targets into separate dependencies before it executes the action
lines. For example, consider the following dependency rule in a description
file:
KERNEL.OBJ, DRIVER.OBJ DEPENDS_ON COMMON.DEF

Because there is no action line, MMS uses built-in rules to determine what
action is needed to update KERNEL.OBJ and DRIVER.OBJ and expands
the previous rule as follows:
KERNEL.OBJ DEPENDS_ON KERNEL.C, COMMON.DEF
CC KERNEL.C
DRIVER.OBJ DEPENDS_ON DRIVER.C, COMMON.DEF
CC DRIVER.C

MMS determines from the built-in rules that KERNEL.C and DRIVER.C
are the sources for KERNEL.OBJ and DRIVER.OBJ, respectively. When
both targets need updating, the original dependency rule expands to two
dependency rules, resulting in two separate compilations.
2-6

MMS Description Files

Sometimes, if an action line is executed twice, the results may not be what
you intended, as in the following example:
A.EXE : A.OBJ, A.LIS
LINK A.OBJ
A.OBJ, A.LIS : A.BAS
BASIC/LIST A.BAS

MMS expands the second rule to the following two dependency rules:
A.OBJ : A.BAS
BASIC/LIST A.BAS
A.LIS : A.BAS
BASIC/LIST A.BAS

Because the second dependency in the description file expands to two
dependency rules, each with a separate action, MMS executes the command
BASIC/LIST A.BAS twice and produces two .OBJ files and two .LIS files.
See Section 3.11.2 for a detailed discussion on avoiding this problem in your
description file.
Occasionally, MMS executes an action even though you do not expect the
source to be newer than the target. This situation can result from one of the
following conditions:
•

•

2.1.3.3

If sources are being stored in a library to which more than one person
has access, someone else may replace that source in the library after you
have invoked MMS but before MMS has checked the source's revision
time. Therefore, when MMS checks the time, a source newer than the
corresponding target may exist in the library. MMS would then execute
the action to update the target.
If the sources and targets in your description file do not reside on the
same node of a network, the clocks on the nodes may not be synchronized
and a source may have a revision time that is later than the target.
Also, in a VAXcluster environment, clocks on different nodes of the
cluster may not be synchronized.

Hierarchy of Dependency Rule Application

MMS has a hierarchy of rule application:

•

If an action line exists in a description file, the action line takes precedence over all built-in rules and user-defined rules.

•

If a user-defined rule exists in a description file, the user-defined rule
takes precedence over a built-in rule.

MMS Description Files 2-7

•
•

A built-in rule is executed only if no action line or user-defined rule
exists in the description file.
If there is no action line, built-in rule, or user-defined rule for updating
a target, then MMS issues a fatal-error message.

2.2 Using Built-In Rules
When writing a description file, you can explicitly state dependencies and
actions, or you can abbreviate them by taking advantage of built-in rules,
which MMS uses to update targets. A built-in rule is the default method
MMS uses for updating a target with a particular file type from a source
with a particular file type.
Built-in rules are made up of default macros, special macros, and string
variables. A complete list of the MMS built-in rules is in Table C-6. A file
copy of the built-in rules resides in the following:
SYS$COMMON: [SYSHLP.EXAMPLES.MMS]MMS$DEFAULT_RULES.MMS.

MMS uses its built-in rules when you omit the action line from a dependency
rule. If the dependency rule has an action line but no source, then MMS
uses the action line.
MMS knows how to build a software system by looking at file types and
relating them to its built-in rules. Built-in rules are fixed and go into effect
when you invoke MMS. They cannot be changed, but you can override them
with user-defined rules. Built-in rules also explain why you must follow
standard file-naming practices. For example, a Pascal program must have
a .PAS extension. If your Pascal program does not have the .PAS extension,
MMS does not know it is a Pascal program.
Built-in rules consist of the file extension of the source, the file extension of
the target, and the action to update the target using the source. The actions
in built-in rules use macros extensively, as shown in Example 2-1.

2-8

MMS Description Files

Example 2-1:

Built-In Rule

.PAS.OBJ
@)
$(PASCAL) $(PFLAGS) $(MMS$SOURCE)

0 .PAS is the source file type.
8 .OBJ is the target file type.
8 $(PASCAL) $(PFLAGS) $(MMS$SOURCE) is the action line to update
the target.
MMS attempts to use its built-in rules only when you omit the action
line from a dependency rule. For example, MMS has a built-in rule that
instructs it to use .FOR files when updating .OBJ files and to produce the
.OBJ files by invoking the FORTRAN compiler. In writing the description
file, you can state this relationship as follows:
MOD3.0BJ DEPENDS_ON MOD3.FOR
FORTRAN MOD3.FOR

You can rely on MMS built-in rules by omitting the action line as follows:
MOD3.0BJ DEPENDS ON MOD3.FOR

MMS uses its built-in rule to invoke the FORTRAN compiler and build
MOD3.0BJ from MOD3.FOR.
If you omit the source, MMS can still use built-in rules to locate it because
MMS knows about implied dependencies among files with the same name
but different file types. MMS uses its suffixes precedence list to determine
which file type (source) would result in the target file type. In the previous
example, because the target's file name is MOD3, MMS assumes that the
source's file name is also MOD3.

MMS also knows that .OBJ files depend on .FOR files with the same file
name so you can abbreviate the previous dependency rule even further as
follows:
MOD3.0BJ :

MMS automatically looks for MOD3.FOR and uses it to build MOD3.0BJ
because MMS knows that .OBJ files depend on .FOR files with the same file
name.
However, consider the following line:
MOD3.0BJ DEPENDS ON MOD2.0BJ

MMS Description Files 2-9

If you omit the action line, MMS does not know how to build the target, and
you receive an error message.

2.2.1

Suffixes Precedence List
MMS checks its suffixes precedence list to determine the file type of the
source and then uses the built-in rules to determine how the various types of
files can be generated from the known rules. Consider the following suffixes
precedence list:
.EXE .OBJ .BLI .C .FOR .BAS

According to this list, .EXE files have precedence over .OBJ files, which have
precedence over .BLI files, which have precedence over .C files, and so on.
Figure 2-1 shows the relationship between the suffixes list and the known
rules.
Figure 2-1:

Relationship Between Suffixes

I .FOR I

.BAS

I
ZK-1664-GE

The arrows in this figure indicate built-in rules. In this figure, a known
rule specifies how an .EXE file is made from an .OBJ file. Similarly, the
built-in rules direct MMS how to make an .OBJ file from a .BLI file, a .C
file, a .FOR file, and a .BAS file. Because .BLI precedes .C in the suffixes
list, .BLI files have priority over .C files as a way to build .OBJ files. (The
suffixes precedence list is contained in Table C-4; you can alter the order of
the suffixes precedence list, as described in Section 2.7.4.)
The figure also shows that .OBJ files can be built from .BLI, .C, .FOR, and
.BAS files. If MMS is trying to build MOD3.0BJ, it looks first for a source
named MOD3.BLI. If such a source exists in the specified directory, MMS
applies the known rule and creates MOD3.0BJ; if it finds no match for the
file name and type, it continues looking in the specified directory for the
same file name and the next file type from the suffixes list that can update
2-10

MMS Description Files

the target. If MOD3.BLI does not exist, MMS next looks for MOD3.C. If
MOD3.C does not exist, the next possible source is MOD3.FOR, and so on.
If MMS finally matches MOD3.0BJ with MOD3.FOR and locates
MOD3.FOR in your directory, it updates the target MODS.OBJ from the
source MODS.FOR by using its built-in rule. This procedure explains why a
dependency rule as brief as the following is complete:
MOD3.0BJ :

This rule equates to the full dependency rule as follows:
MOD3.0BJ DEPENDS ON MOD3.FOR
FORTRAN/OBJ~MOD3 MOD3.FOR

If, however, MMS fails to find a source from which to build the new target,
it repeats the entire process by determining whether it can build one of the
nonexistent sources.
If MMS exhausts all the possible file types without finding a way to build
any of the sources, it issues an error message and aborts processing.
Once MMS locates the correct source for updating a target, it checks whether
the source itself needs updating before using it to update the original target.
To do this, MMS repeats the process of finding a file in the specified directory
that matches the file name of the source and each file type in the suffixes
list that can update the target type. MMS repeats this process every time
it finds a source that could update the target so that all the sources are
guaranteed to be up-to-date.
The following example shows a description file where dependencies are
explicitly stated:
PROG.EXE DEPENDS ON MODl.OBJ, MOD2.0BJ, MOD3.0BJ
LINK/EXEC=PROG MODl.OBJ, MOD2.0BJ, MOD3.0BJ
MODl.OBJ DEPENDS ON MODl.C
CC MODl.C
MOD2.0BJ DEPENDS ON MOD2.C, DEFDIR:DEFSl.H, DEFDIR:DEFS2.H
CC MOD2.C MOD3.0BJ DEPENDS_ON MOD3.C, DEFDIR:DEFS2.H
CC MOD3.C

Example 2-2 shows a description file of the same system that takes advantage of MMS built-in rules.

MMS Description Files

2-11

Example 2-2:

Description File Using Built-In Rules

0 FROG.EXE DEPENDS ON MODl.OBJ, MOD2.0BJ, MOD3.0BJ
LINK/EXEC=PROG MODl.OBJ, MOD2.0BJ, MOD3.0BJ

0 MOD2.0BJ, MOD3.0BJ DEPENDS_ON DEFDIR:DEFS2.H

e MOD2.0BJ DEPENDS_ON DEFDIR:DEFSl.H
0 The first dependency rule lists the object files and states that PROG.EXE
8
0

2.2.2

is constructed by executing the DCL command LINK.
The rule for building MODI.OBJ need not be specified because a built-in
rule directs MMS to build it from MODl.C.
The second dependency rule says that MOD2.0BJ and MODS.OBJ depend on DEFS2.H, which is located in the directory defined by DEFDIR.
Neither the .C file dependencies nor the actions taken to build the
objects are stated.
The third dependency rule says that MOD2.0BJ also depends on
DEFDIR:DEFSl.H.

Default Macros
A macro is a name that represents a character string. MMS default
macros can help you use MMS more efficiently because they define commonly used operations. MMS built-in rules are expressed in terms of default
macros.

2.3 Defining Your Own Macros
In addition to providing built-in rules, MMS allows you to define your own
rules. Defining your own rules may involve deleting, adding to, or replacing
the built-in rules. Section 2.5 describes when and how to define new rules.
MMS allows you to use three kinds of macros: default macros (VMS utilities
or qualifiers), special macros (target or source file names), and user-defined
macros. These macros can use other macros in their definition. The full
list of default macros is in Table C-1 and the list of special macros is in
Table C-3.

2-12

MMS Description Files

In MMS, macros contain the following information:
•

The names of compilers, the linker and library utilities

•

The default qualifiers for compiling, linking, and using the library
utilities
The file name of the target
The list of sources for each target

•
•

The following table lists some default and special macros available with
MMS.
Macro

Description

Value

PASCAL

PASCAL compiler

PASCAL

PFLAGS

Default PASCAL
qualifiers

/NOLIST/OBJECT=$(MMS$TARGET_NAME)

MMS$TARGET_NAME

Target file name

Depends on target or source line

MMS$SOURCE

First file name
in source list

Depends on target or source line

MMS$SOURCE_LIST

All file names
in source list

Depends on target or source line

The default macros, PASCAL and PFLAGS, contain a fixed value and
are stored in an internal MMS list. They are created when MMS is
invoked. The special macros, MMS$TARGET_NAME, MMS$SOURCE, and
MMS$SOURCE_LIST, are also maintained by MMS but their value changes
according to the source or target line MMS is evaluating.
If your description file reuses the same file name or if you have several
action lines that invoke a compiler with the same set of qualifiers, you can
define a macro to represent the file name or the list of qualifiers. You then
can use the macro name throughout your description file. If you need to
change the file name or qualifiers, you edit only the macro definition.

2.3.1

Formatting Macro Definitions
A macro definition has the following format:
name

= string

The name of the macro can consist of any characters except a space, a tab,
a carriage return, an equal sign, the sequence $( ), quotation marks, and
control characters. A macro name can be any length. The macro string

MMS Description Files

2-13

is the text that replaces the macro name when the macro is expanded. A
macro string can consist of any character sequence. You can use a hyphen
( - ) as a continuation character to continue a macro string onto the next line
of the description file.
You must begin a macro definition in column 1 of the line. You can place
macro definitions anywhere in the description file, but placing all macro
definitions at the beginning of the description file makes it easier to find and
modify them.
After you have defined a macro, you can invoke it anywhere in the description file. To invoke a macro, simply specify a macro's name in the following
format:
$(name)

The dollar sign and parentheses surrounding the macro name are required
punctuation. MMS replaces the name (and the punctuation) with the
equivalent text string when it processes your description file.
Note that you must define a macro before you can use it; otherwise, the
macro's expanded value is the null string. To determine whether a macro
has been defined, keep in mind the order in which MMS processes macro
definitions (see Section 2.3.2).

2.3.2

Order of Processing Macros
When processing macros, MMS applies definitions in the following order:
1.

Command line

Description file
3. Built-in
4. CLI symbol
Once MMS finds a definition for a macro, it does not search those locations
farther down the list for more definitions.
You can define a macro only once in a description file. If MMS finds two or
more definitions of the same macro, it issues an error message and uses the
first definition in the file. To change a macro definition, you can redefine the
macro with the /MACRO qualifier on the command line or you can replace
the definition with the /OVERRIDE qualifier. (See the Command Dictionary
for descriptions of these qualifiers.)

2-14 MMS Description Files

2.3.3

Invoking Macros
A macro string can also contain macro invocations that are expanded when
the macro is defined. The macro invocations must denote macros that
you have already defined in the description file. For example, suppose the
following macro definitions appear in your description file:
BUILDl = /DEBUG
BUILD2 =/LIST $(BUILD1)

The macro invocation $(BUILD!) is expanded to /DEBUG because BUILD!
has already been defined. If the positions of the macro definitions were
reversed, BUILD! would be expanded to the null string because it has not
been previously defined and therefore cannot be expanded. In this case,
MMS does not issue an error message.
MMS macros are not recursive. MMS expands a macro invocation only
once. If during the expansion of a macro MMS encounters another macro
invocation, the second invocation is not expanded.
Example 2-3 shows a description file, CPROG.MMS, that defines two
macros: FNAME, which expands to the string TESTS; and CCQUALS,
which expands to the string /NOLIST.
Example 2-3:

Macro Definitions in a Description File

FNAME = TESTS
CCQUALS = /NOLIST
$(FNAME) .EXE: $(FNAME).OBJ, SYS$LIBRARY:STARLET.OLB
LINK $(FNAME),SYS$LIBRARY:STARLET.OLB/LIB
$(FNAME) .OBJ : $(FNAME) .C
CC $(CCQUALS) $(FNAME) .C

When MMS starts building the target (in this case, the .EXE file), it replaces
every occurrence of FNAME with TESTS and the occurrence of CCQUALS
with the string /NOLIST. As a result, MMS interprets the description file as
the following:
TESTS.EXE : TESTS.OBJ, SYS$LIBRARY:STARLET.OLB
LINK TESTS,SYS$LIBRARY:STARLET.OLB/LIB
TESTS.OBJ : TESTS.C
CC /NOLIST TESTS.C

MMS Description Files

2-15

2.3.4

Defining Macros on the Command Line
You can define macros on the MMS command line by using the /MACRO
qualifier. /MACRO allows you to define new macros or to redefine macros
you defined in the description file. When you redefine an existing macro
with /MACRO, the new definition overrides the one in the description file.
The format of the /MACRO qualifier is as follows:
/MACRO = { filespec I "macro"... }

The filespec is a VMS file specification or a logical name for a file that
contains only macro definitions. The default file type is .MMS. The "macro"
is a macro definition enclosed in quotation marks. Use the same format that
you would use to define a macro in a description file: name = string. If you
specify more than one macro, separate the macros with commas and enclose
the list in parentheses. The /MACRO qualifier is described in detail in the
Command Dictionary.
To build a new program called TESTl .EXE, you can use the same description
file with which you built TESTS.EXE (as shown in the Example 2-3). You
can redefine FNAME and override the macro definition in the description
file as follows:
$ MMS/DESCRIPTION=CPROG/MACRO="FNAME=TESTl II

MMS then interprets the description file as follows:
TESTl.EXE : TESTl.OBJ, SYS$LIBRARY:STARLET.OLB
LINK TEST1,SYS$LIBRARY:STARLET.OLB/LIB
TESTl.OBJ : TESTl.C
CC/NOLIST TESTl.C

The definition of the macro CCQUALS remains the same.
As indicated by the format for /MACRO, you can store macro definitions in
a file from which MMS extracts them. Suppose that you want to redefine
the macro FNAME in your description file and change the qualifiers to
the CC command. First, you create a file to hold the macro definitions. For
example, a macro definitions file might be called MACROS.MMS and contain
the following:
FNAME = TESTl
CCQUALS = /LIST/DEBUG

Then you invoke MMS with the /MACRO qualifier and the name of the
macro definitions file:
$ MMS/DESCRIPTION=CPROG/MACRO=MACROS

2-16 MMS Description Files

MMS interprets the previous description file as follows:
TESTl.EXE : TESTl.OBJ, SYS$LIBRARY:STARLET.OLB
LINK TESTl, SYS$LIBRARY:STARLET.OLB/LIB
TESTl.OBJ : TESTl.C
CC/LIST/DEBUG TESTl.C

You invoke a default macro in a dependency rule just as you would invoke
a macro you have defined yourself. For example, if you want to compile a C
program using the /NOLIST and /OBJECT qualifiers, you can instead invoke
the default macro CFLAGS:
PROG.OBJ : PROG.C
CC $(CFLAGS) PROG.C

MMS expands CFLAGS to its equivalent, /NOLIST/OBJECT, and assumes
that the object file and the specified target have the same name. Since MMS
has a built-in rule for generating .OBJ files from .C files, and since this rule
invokes the default macro CFLAGS, you can get the same results with the
following simple dependency rule:
PROG.OBJ :

You can redefine a default macro so that you can use different qualifiers.
The following example redefines CFLAGS:
CFLAGS = /LIST
PROG.EXE DEPENDS ON MODl.OBJ, MOD2.0BJ, MOD3.0BJ
LINK/EXEC=PROG MODl.OBJ, MOD2.0BJ, MOD3.0BJ
MODl.OBJ DEPENDS_ON
MOD2.0BJ DEPENDS_ON DEFDIR:DEFSl.H
MOD2.0BJ, MOD3.0BJ DEPENDS_ON DEFDIR:DEFS2.H

MMS interprets the description file as follows:
PROG.EXE DEPENDS ON MODl.OBJ, MOD2.0BJ, MOD3.0BJ
LINK/EXEC=PROG MODl.OBJ, MOD2.0BJ, MOD3.0BJ
MODl.OBJ DEPENDS ON MODl.C
CC/LIST MODl.C
MOD2.0BJ DEPENDS ON MOD2.C, DEFDIR:DEFSl.H, DEFDIR:DEFS2.H
CC/LIST MOD°2.C
MOD3.0BJ DEPENDS ON MOD3.C, DEFDIR:DEFS2.H
CC/LIST MOD3°.C

If you later decide that you want the C source files to be compiled with the
/DEBUG qualifier, you can redefine CFLAGS on the command line by typing
the following:
$

MMS/MACRO="CFLAGS=/DEBUG/NOLIST"

MMS Description Files

2-17

MMS then interprets the description file as follows:
FROG.EXE DEPENDS ON MODl.OBJ, MOD2.0BJ, MOD3.0BJ
LINK/EXEC=PROG MODl.OBJ, MOD2.0BJ, MOD3.0BJ
MODl.OBJ DEPENDS ON MODl.C
CC/DEBUG/NOLIST MODl.C
MOD2.0BJ DEPENDS ON MOD2.C, DEFDIR:DEFSl.H, DEFDIR:DEFS2.H
CC/DEBUG/NOLIST MOD2.C
MOD3.0BJ DEPENDS ON MOD3.C, DEFDIR:DEFS2.H
CC/DEBUG/NOLIST MOD3.C

2.4 Using Special Macros
MMS special macros expand to source or target names in the dependency
currently being processed. You use them instead of target and source file
specifications when you are writing general user-defined rules.
MMS provides nine special macros, which you can use in the following
places in a description file:
•
•
•
•

In user-defined rules
In macro definitions
In action lines
In comments

You cannot redefine a special macro or use a special macro on a target or
source line in a description file.
Table C-3 lists the MMS special macros and describes their functions. The
table also lists a symbol that you can use as an abbreviation for each macro.
More information on the special macros that relate to the VAX DEC/Code
Management System (CMS) can be found in Section 4.2.
NOTE

The strings $*, $%, and $? always denote special macros. If an
action line contains these character combinations, the asterisk
(* ), percent sign ( % ), and question mark (? ) are not interpreted
as wildcard characters.
The following example shows how MMS defines a built-in rule using the
MMS$SOURCE special macro:
.C.OBJ
$(CC) $(CFLAGS) $(MMS$SOURCE)

2-18 MMS Description Files

CC and CFLAGS are default macros that invoke the C compiler with the
/NOLIST and /OBJECT qualifiers. Consider the following dependency rule:
[ALDEN]MOD2.0BJ DEPENDS_ON [STANLEY]MOD2.C

MMS applies the built-in rule that updates an .OBJ file from a .C file,
expanding the special macros in this rule as follows:
CC /NOLIST/OBJECT=[ALDEN]MOD2.0BJ [STANLEY]MOD2.C

You can use the MMS$CHANGED_LIST special macro to get listings of files
that have changed since the last time the system was built. For example,
consider the following description file:
PROG.EXE : PRINT.FLG, MODl.OBJ, MOD2.0BJ, MOD3.0BJ
COPY NLAO: PRINT.FLG
! Make the revision date of PRINT.FLG more current
PURGE PRINT.FLG
LINK/EXEC=PROG MODl.OBJ, MOD2.0BJ, MOD3.0BJ
PRINT.FLG : MODl.C, MOD2.C, MOD3.C
! Print the sources that have changed
PRINT $(MMS$CHANGED_LIST)

The COPY command in the first dependency rule ensures that PRINT.FLG
has approximately the same revision time as PROG.EXE. Sources newer
than PROG.EXE will also be newer than PRINT.FLG and will be printed
only when they are more recent than the last linking of PROG.EXE. The
MMS$CHANGED_LIST special macro expands to a list of all the source files
that have changed, and each changed source listing is submitted to the print
queue.
The following example shows how you could use MMS$TARGET and
MMS$CHANGED_LIST in an action line to represent the current target and
a list of the revised sources. Consider the following description file:
PROG.EXE DEPENDS ON MODl.OBJ, MOD2.0BJ, MOD3.0BJ
LINK/EXEC=PROG MODl.OBJ, MOD2.0BJ, MOD3.0BJ
! Needed to update $(MMS$CHANGED_LIST) to make $(MMS$TARGET)

Your directory contains the following entries:
$

DIR/DATE=MODIFIED

Directory USER$: [MICHAELS]
MOD1.0BJ;2
MOD2.0BJ;l
MOD3.0BJ;2
PROG.EXE;l

2-DEC-1987
2-DEC-1987
2-DEC-1987
2-DEC-1987

13:50
09:22
14:06
11:47

Total of 4 files
$

MMS Description Files

2-19

Because MODI.OBJ and MOD3.0BJ have changed since PROG.EXE was
last linked, the following lines are displayed when you run MMS:
LINK/EXEC=PROG MODl.OBJ, MOD2.0BJ, MOD3.0BJ
! Needed to update MODl.OBJ, MOD3.0BJ to make PROG.EXE

MMS$TARGET is expanded to the name of the target being updated, and
MMS$CHANGED_LIST is expanded to a list of the revised sources.

2.5 Defining Your Own Rules
MMS has built-in rules that allow it to figure out unstated dependencies and
to perform actions necessary to update targets. However, the list of built-in
rules may not contain all the rules you need, or you may want to redefine
existing rules. MMS provides you with the ability to include user-defined
rules in a description file. Once you define a new rule, MMS uses the
new rule every time it builds your system with that description file. The
user-defined rule overrides the built-in rule.

2.5.1

Creating a User-Defined Rule
You create a user-defined rule by listing the source and target file types
and writing an action to update the target. The file types of the source and
target must be known to MMS through the suffixes precedence list. The
user-defined rule can use multiple action lines that can consist of default
macros, special macros, or constant strings.
The format of a user-defined rule is as follows:
.SRC.TAR
action line ...

[!comment]
[!comment]

.SRC is the file type of the source. .TAR is the file type of the target. The
action line is a command-language command that MMS should execute to
update a file of the target type from a file of the source type. You can specify
as many action lines as necessary to update the target.
The following description file, NEWLINK.MMS shown in Example 2-4,
contains a user-defined rule that redefines the default MMS rule for
linking.

2-20 MMS Description Files

Example 2-4:
$

Description File Using a User-Defined Rule

TYPE NEWLINK.MMS

! User-defined rule

«)

.OBJ.EXE
$(LINK) $(LINKFLAGS) $(MMS$SOURCE_LIST)
! Executable images and their sources
!

8MAIN.EXE

DEPENDS_ON MAIN.OBJ, SUBl.OBJ

! Object files and their sources
@>MAIN.OBJ DEPENDS_ON MAIN.PAS
SUBl.OBJ DEPENDS ON SUBl.PAS

0 This user-defined rule allows more than one object to link by changing

8
0

the special macro MMS$SOURCE to MMS$SOURCE_LIST, which
expands to a list of all the target's sources. The user-defined rule also
uses the default macros, LINK ·and LINKFLAGS, for linking the object
files.
The executable target no longer needs an action line because the userdefined rule takes precedence.
The built-in rule for compiling Pascal source code files is used because
there is no user-defined rule to override it.

You can use this user-defined rule for building a multiobject software system.
Notice that you do not need another action line for the executable image
target. The user-defined rule logically comes before any targets in your
description file. The action line is listed on the line after the source and
target pair and is indented at least one space or tab.

2.5.2

Using User-Defined Rules
To use the description file NEWLINK (shown in Example 2-4) to build your
software system, you must have the following files in your current directory:
$

DIR/DATE=MODIFIED

Directory DISKl: [BUILD]
MAIN.PAS;l
NEWLINK.MMS;2
SUBl.PAS;lO

3-JUL-1987 13:48
14-JUL-1987 13:20
3-JUL-1987 13:47

MMS Description Files

2-21

Total of 3 files.
$ MMS/DESCRIPTION=NEWLINK

0 PASCAL /NOLIST/OBJECT=MAIN MAIN.PAS
PASCAL /NOLIST/OBJECT=SUBl SUBl.PAS

@ LINK /TRACE/NOMAP/EXEC=MAIN MAIN.OBJ, SUBl.OBJ
0 MMS output shows that MMS uses a built-in rule for compiling.
8 MMS output shows that MMS uses the user-defined rule for linking.

2.6 Using Action Lines
You need action lines when you want to link more than one object file or you
want to use different compilation options for each source code file. Built-in
rules do not allow for these cases because built-in rules handle only one
object file and compile each source code file with the same defaults.
You can supply an action line for any source or target line. Action lines
override all built-in rules and user-defined rules in a description file. Action
lines are made up of any combination of default macros, special macros, and
user-supplied strings. To keep your description file simple, use built-in rules
as much as possible. One user-defined rule can apply to several different
target and source lines, so it is still preferable to an action line. However,
when the action is so specific that it must be described for that individual
case, then you must use action lines.
Consider the description file, ACTION_LINES.MMS, shown in
Example 2-5.

2-22 MMS Description Files

Example 2-5:
$

Description File Using Action Lines

TYPE ACTION LINES.MMS
! Executable image and its sources

MAIN.EXE

DEPENDS ON MAIN.OBJ, SUBl.OBJ

$(LINK) $(LINKFLAGS) $(MMS$SOURCE_LIST)
Object files and their sources
MAIN.OBJ DEPENDS ON MAIN.PAS

@
@)

PASCAL JLIST MAIN.PAS

SUBl.OBJ DEPENDS ON SUBl.PAS
$(PASCA~) /LIST /MACHINE_CODE $(MMS$SOURCE)

0 This action line is composed entirely of macros and controls the way
MMS links its object files. Earlier you used a user-defined rule for the
same result. When a rule is used more than once, using a user-defined
rule is the better approach. However, in this case, the rule is applied
only once, so using the action line results in a simpler description file.

8 This action line has no macros, only explicit strings.
0 This action line has a combination of explicit strings and macros.
It is better to write a description file with consistent action lines than to
mix the actions lines as in this example. This was done for the purpose of
demonstrating the variety of ways that you can write an action line.

2.6.1

Multiple Action Lines
Sometimes a target requires a series of actions to update it. In that case,
you can use more than one action line after a target or source line. Consider
the description file, BALANCE.MMS, shown in Example 2-6.

MMS Description Files

2-23

Example 2-6:

8
e

Description File Using Multiple Action Lines

RESULTS.DIF DEPENDS_ON ACCOUNTS.EXE, BENCHMARK.DAT
RUN ACCOUNTS.EXE
! Runs ACCOUNTS
DIFFERENCES/OUTPUT=RESULTS.DIF ACCOUNTS.DAT, BENCHMARK.DAT
! Compares program output to master file
TYPE RESULTS.DIF
! Displays results of comparison
ACCOUNTS.EXE DEPENDS ON ACCOUNTS.OBJ
LINK ACCOUNTS.OBJ
! Links ACCOUNTS program

0 If either ACCOUNTS.EXE or BENCHMARK.DAT is newer than
RESULTS.DIF, MMS executes the action lines that update RESULTS.DIF.
If ACCOUNTS.OBJ is newer than ACCOUNTS.EXE, MMS first executes

8
8
8

the action line to update ACCOUNTS.EXE.
MMS then runs the program ACCOUNTS.EXE.
MMS runs the DIFFERENCES utility to compare the program's output
with a master file.
MMS displays the results of the comparison.

If you use the previous description file example, the output would be as

follows:
$ MMS/DESCRIPTION=BALANCE
LINK ACCOUNTS.OBJ
! Links ACCOUNTS program
RUN ACCOUNTS.EXE
! Runs ACCOUNTS
DIFFERENCES/OUTPUT=RESULTS.DIF
ACCOUNTS.DAT, BENCHMARK.DAT
! Compares program output to master file
TYPE RESULTS.DIF
! Displays results of comparison
Number of difference sections found: 0
Number of difference records found: 0
DIFFERENCES /MERGED=l/OUTPUT=USER$: [ALISON]RESULTS.DIF;lUSER$: [ALISON]ACCOUNTS.DAT;19USER$: [ALISON]BENCHMARK.DAT;27
$

When you run MMS, all action lines and any comments specified on action
lines are written to SYS$0UTPUT or to a file you specify with the MMS
/OUTPUT qualifier. The /OUTPUT qualifier is described in the Command
Dictionary.

2-24

MMS Description Files

2.6.2

$STATUS and $SEVERITY
As each action line completes execution, MMS executes a command in the
subprocess to write the value of $STATUS to a mailbox. The parent process
can then determine if the action line executed successfully. The values
of $STATUS and $SEVERITY are set when the execution of this internal
MMS command succeeds. Consequently, $STATUS and $SEVERITY
always indicate success. You cannot test the values of these variables in a
description file. You can, however, control the behavior of MMS with the
/[NO]IGNORE qualifier because it tells MMS what to do when it encounters
warning, error, or fatal errors. See the Command Dictionary for more
information on severity errors.

2.6.3

MMS$STATUS
MMS uses a special symbol, MMS$STATUS, to record the return status
of the last action line it executed. MMS$STATUS is set in the parent
process running MMS and reflects the value of $STATUS returned from
the child process. The value of MMS$STATUS is constantly changing with
the completion of each action line. You cannot use MMS$STATUS from
within the child process because symbols are passed only from the parent
to the child process when the child process is created. When MMS exits,
MMS$STATUS reflects the status of the last command executed in the child
process.
If the value of MMS$STATUS is an even number, the last action line terminated with an error. If the value of MMS$STATUS is an odd number, the
last action line executed successfully. To check the value of MMS$STATUS,
issue the DCL command SHOW SYMBOL after MMS has finished processing your description file. Do not confuse MMS$STATUS with the $STATUS
condition value returned by MMS itself. MMS$STATUS contains the status
of the last action line executed; $STATUS contains the status resulting from
the termination of the MMS image.

2.6.4

Action Line Prefixes
An action line prefix is a single-character modifier that controls the
processing of a single action line in a description file.

MMS Description Files

2-25

The two action line prefixes are described in Table 2-1.
Table 2-1 : MMS Action Line Prefixes

Prefix

Function

- (Ignore)

Causes MMS to ignore errors generated by the action
line on which the prefix appears.

@(Silent)

Suppresses the writing to the output file of the action
line on which the prefix appears. (The output file can
be either SYS$0UTPUT or the file specified by the
/OUTPUT qualifier.)

You cannot override either action line prefix from the MMS command line.

An action line prefix must appear as the first nonblank character on an
action line; however, a prefix may not appear in column 1 of the line. The
rest of the action line must be separated from the prefix by at least one
space or tab. You can use both prefixes on the same action line by typing
them next to each other with no intervening spaces or tabs. The following
example shows the use of both prefixes:
A : B

@-Write SYS$0UTPUT "It worked!"

MMS also provides two directives (discussed in Section 2. 7), .IGNORE and
.SILENT, that are similar in function to - and@, respectively. The difference
between the action line prefixes and the directives with the same functions
(.IGNORE and .SILENT) is that a prefix affects the processing of only one
line in the description file, while a directive affects the processing of the
entire file.

2.6.5 Ignore Prefix { - )
The Ignore action line prefix ( - ) directs MMS to ignore any errors that occur
during the processing of the action line on which the prefix appears.
The following dependency rule tests the BASIC compiler with a source
file known to contain errors. Normally, the BASIC compiler aborts the
compilation when it encounters an error, and MMS aborts execution as well.
In this case, the Ignore prefix directs MMS to ignore the error and execute
the EDIT command.
TESTERR : ERRORS.BAS
- BASIC /LIST=ERRORS ERRORS
EDIT/COMMAND=EXTRACT.EDT ERRORS.LIS

2-26 MMS Description Files

2.6.6

Silent Prefix (@)
The Silent action line prefix (@ ) stops MMS from writing an action line to
SYS$0UTPUT or to the file specified by the /OUTPUT qualifier. This prefix,
which affects only the action lines on which it appears, is useful when you
do not want certain commands echoed at execution.
For example, the Silent action line prefix directs MMS to suppress the
display of the following action line:
@ DELETE *.LIS;*

The Silent action line prefix can be useful in cleanup procedures. In the
next example, MMS deletes compilation listings from the [LISTINGS]
directory and returns to the [WORKING] directory. Because the Silent
prefix suppresses the action lines, MMS can do its work silently and then
display the text "Cleanup done" when the task is completed.
CLEANUP :
@ SET DEFAULT [LISTINGS]
@ DELETE *.*;*
@ SET DEFAULT [WORKING]
@ WRITE SYS$0UTPUT "Cleanup done"

MMS assumes that an at sign ( @ ) followed by a space or tab signifies the
Silent prefix. If you want to invoke a command procedure from an action
line, you must omit the space between the at sign and the name of the
command procedure.

2.6. 7

Action Line Restrictions
Action lines are subject to the following restrictions:
•

The maximum length of an uncontinued action line is 251 characters.
The maximum length of a continued action line is 1019 characters. If
you use VAX DEC/Shell as your Command Language Interpreter (CLI),
the limits are 131 and 507 characters, respectively, for uncontinued and
continued action lines.

•

The maximum length of a quoted string of a comment in action lines is
restricted to 130 characters.

•

Quotes imbedded in other quotes on action lines may not behave as
expected. However, if you assign the inner quote to be a DCL symbol,
you can use the DCL symbol within the outer quoted string.

MMS Description Files

2-27

•

An action line cannot receive data from SYS$INPUT. For example, an
action line may not contain the DCL command CREATE and cannot
read data from the terminal.

•

An action line may not contain the DCL commands LOGOUT, EXIT, or
STOP.
An action line can spawn a subprocess only by using the $(MMS)
reserved macro (see Section 3.3). The DCL command SPAWN is not
allowed in an action line.
An action line may not contain the DCL commands SET VERIFY or
SET ON. You can use these commands in a command procedure that you
invoke from an action line. If you use SET VERIFY, however, you must
be sure to issue SET NOVERIFY before the command procedure ends.
An action line may not contain the DCL command GOTO or labels. You
can use GOTO or labels in a command procedure that you invoke from
an action line because action lines are executed individually.
You cannot direct output to TT: from an action line because MMS
equates TT: as SYS$INPUT and this can result in MMS hanging.

•

•
•

You cannot test the values of $STATUS and $SEVERITY in your
description file because the value is always success. The value is set
when the execution of an internal MMS command succeeds. The value
of MMS$STATUS also changes with the completion of each action line
executed.

•

You cannot use the multiline form of IF - THEN - ELSE - ENDIF from
an action line; each action line must be a complete DCL command~

2. 7 Using Directives
A directive is a word that instructs MMS to take a certain action as
it processes a description file. A directive can appear on any line in the
description file, but it controls the processing of the entire file.
A directive must start in column 1 of a line. You can type a directive in
either uppercase or lowercase letters, or a combination of both. Table 2-2
lists the directives and their functions. Detailed descriptions of the
directives are provided in the sections that follow.

2-28 MMS Description Files

Table 2-2:

2. 7.1

MMS Directives

Directive

Function

.IGNORE

Causes MMS to ignore all errors generated by all action
lines and to continue processing the description file.

.SILENT

Suppresses the writing of all action lines to the output
file (whether to SYS$0UTPUT or to the file specified by
the /OUTPUT qualifier).

.DEFAULT

Indicates actions to be performed if MMS built-in rules or
user-defined rules do not specify how to update a target.

.SUFFIXES

Clears, adds to, or redefines the suffixes precedence list .

.INCLUDE

Includes the specified file in the description file .

.FIRST

Indicates actions to be performed before MMS has
executed any action lines to update the target.

.LAST

Indicates actions to be performed after MMS has executed all the action lines that update the target.

.IFDEF

Causes subsequent lines of a description file to be
processed only if the specified macro is defined.

.ELSE

Causes subsequent lines of a description file to be
processed if the specified macro for the .IFDEF directive
is undefined.

.ENDIF

Terminates the set of lines in the description file whose
processing is controlled by .IFDEF or .ELSE.

.IGNORE Directive
The .IGNORE directive tells MMS to ignore warnings, errors, and fatal
errors that occur during the execution of an action line and to continue
processing the description file. Without the .IGNORE directive, MMS aborts
execution if it detects an error while processing an action line.
The .IGNORE directive in the following description file tells MMS to
continue processing even if it encounters errors while running Digital
Standard Runoff (DSR) to update the target:
. IGNORE
BOOK.MEM : CHAPTERl.MEM, CHAPTER2.MEM, CHAPTER3.MEM, CHAPTER4.MEM
COPY/LOG CHAPTERl.MEM BOOK.MEM
APPEND/LOG CHAPTER2.MEM BOOK.MEM
APPEND/LOG CHAPTER3.MEM BOOK.MEM
APPEND/LOG CHAPTER4.MEM BOOK.MEM

MMS Description Files 2-29

CHAPTERl.MEM : CHAPTERl.RNO
RUNOFF CHAPTER!
CHAPTER2.MEM : CHAPTER2.RNO
RUNOFF CHAPTER2
CHAPTER3.MEM : CHAPTER3.RNO
RUNOFF CHAPTER3
CHAPTER4.MEM : CHAPTER4.RNO
RUNOFF CHAPTER4

If CHAPTER3.RNO contains DSR errors, and you run MMS with this
description file (BOOK.MMS), the following lines may appear on your
screen:
$ MMS/DESCRIPTION=BOOK
RUNOFF CHAPTER!
DIGITAL Standard Runoff Version V2.0-014: No errors detected
5 pages written to "USER$: [MICHAELS]CHAPTERl.MEM;l"
RUNOFF CHAPTER2
DIGITAL Standard Runoff Version V2.0-014: No errors detected
16 pages written to "USER$: [MICHAELS]CHAPTER2.MEM;l"
RUNOFF CHAPTER3
%RUNOFF-W-CJL, Can't justify line
on output page 2; on input line 46 of page 1 of file "USER$: [MICHAELS] CH
APTER3.RNO;l"
%RUNOFF-W-CJL, Can't justify line
on output page 2; on input line 52 of page 1 of file "USER$: [MICHAELS] CH
APTER3.RNO;l"
%RUNOFF-W-TFE, Too few end commands
on output page 3; on input line 77 of page 1 of file "USER$: [MICHAELS] CH
APTER3.RNO;l"
%RUNOFF-W-BMS, Bad margin specification: ".lm70
on output page 4; on input line 102 of page 1 of file "USER$: [MICHAELS]C
HAPTER3.RNO;l"
%RUNOFF-W-COR, Can't open required file "TABLEl.RNO"
on output page 5; on input line 154 of page 1 of file "USER$: [MICHAELS]C
HAPTER3.RNO;l"
DIGITAL Standard Runoff Version 2.0-014: 5 diagnostic messages reported
10 pages written to "USER$: [MICHAELS]CHAPTER3.MEM;l"
RUNOFF CHAPTER4
DIGITAL Standard Runoff Version V2.0-014: No errors detected
13 pages written to "USER$: [MICHAELS]CHAPTER4.MEM;l"
COPY/LOG CHAPTERl.RNO BOOK.MEM
%COPY-S-COPIED, USER$: [MICHAELS]CHAPTERl.MEM;l copied to USER$: [MICHAELS] BOOK.ME
M;l (35 blocks)
APPEND/LOG CHAPTER2.MEM BOOK.MEM
%APPEND-S-APPENDED, USER$: [MICHAELS]CHAPTER2.MEM;l appended to USER$: [MICHAELS]B
OOK.MEM;l (1452 records)
APPEND/LOG CHAPTER3.MEM BOOK.MEM
%APPEND-S-APPENDED, USER$: [MICHAELS]CHAPTER3.MEM;l appended to USER$: [MICHAELS]B
OOK.MEM;l (1508 records)
APPEND/LOG CHAPTER4.MEM BOOK.MEM
%APPEND-S-APPENDED, USER$: [MICHAELS]CHAPTER4.MEM;l appended to USER$: [MICHAELS]B
OOK.MEM;l (621 records)
$

2-30

MMS Description Files

Although errors occurred in the processing of CHAPTER3.RNO, MMS
continued to execute action lines, successfully processing CHAPTER4.RNO.
Had .IGNORE not been specified, MMS would have terminated execution
upon encountering errors in CHAPTER3.RNO; the last action line would not
have been executed.
NOTE

You should be careful about executing MMS with the .IGNORE
directive. If errors occur during processing, the target may be
updated yet still contain errors of which you will be unaware.
To override the .IGNORE directive for a particular MMS build, use the
/NOIGNORE, /IGNORE, /IGNORE=WARNING, or /IGNORE=ERROR qualifier on the MMS command line when invoking MMS. (See the Command
Dictionary for more information on the /IGNORE qualifier.)

2.7.2

.SILENT Directive
The .SILENT directive tells MMS to suppress the display of action lines.
Normally, MMS writes action lines either to SYS$0UTPUT or into a file
specified by the /OUTPUT qualifier. Action lines are always executed even if
they are not displayed, unless you specify the /NOACTION qualifier on the
command line. The /OUTPUT and /NOACTION qualifiers are described in
the Command Dictionary.
The .SILENT directive does not suppress the display of error messages
generated by execution of action lines.
The following example illustrates the use of the .SILENT directive:
. SILENT
FROG.EXE : MODl.OBJ, MOD2.0BJ
LINK/EXEC=PROG MODl.OBJ, MOD2.0BJ
MODl.OBJ

MODl.C

MOD2.0BJ : MOD2.C

MMS processes this description file without displaying action lines. The
Command Language Interpreter (CLI) prom pt returns when the target,
PROG.EXE, has been updated.
To override the .SILENT directive for a particular MMS build, use the
NERIFY qualifier on the MMS command line when invoking MMS. (The
NERIFY qualifier is described in the Command Dictionary.)

MMS Description Files

2-31

2.7.3

.DEFAULT Directive
The .DEFAULT directive tells MMS to continue processing the description
file even if it encounters a dependency rule for which there is neither a
specified action line nor applicable built-in or user-defined rules. Rather
than abort execution in such a situation, MMS executes the default action
you specify and continues processing the description file.
The .DEFAULT directive has the following format:
.DEFAULT
action line ...

The action line is a command-language command that MMS executes by
default. You can specify as many action lines as you like.
The .DEFAULT directive can be useful when you are developing a system
that contains inoperative parts and you want MMS to process the operating
portions and inform you about the inoperative parts. If you have only one
module, TEST.D, finished for your system, you can build the system if your
description file, TESTSYS.MMS, is as follows:
.DEFAULT
! Source $(MMS$TARGET) not yet added
TEST.A

TEST.B

TESTl.C TEST2.E TEST3.F

TESTl.C : TESTl.D
COPY TESTl.D TESTl.C

When MMS processes the TESTSYS.MMS description file, it expands the
MMS$TARGET special macro to the name of the target and writes the
following lines to SYS$0UTPUT:
$ MMS/DESCRIPTION=TESTSYS
COPY TESTl.D TESTl.C
Source TEST2.E not yet added
Source TEST3.F not yet added
Source TEST.B not yet added
Source TEST.A not yet added
$

By using the .DEFAULT directive, MMS reminds you of the modules you
have not yet implemented.

2-32 MMS Description Files

Another way to use the .DEFAULT directive is to copy files from one
directory to another. For example:
.DEFAULT :
COPY $(MMS$SOURCE) $(MMS$TARGET)
TEST.ELI :

[PROJECT.FILES]TEST.BLI

PROG.BLI :

[PROJECT.FILES]PROG.BLI

The sources in this description file exist in a common directory for the
project. Because these dependency rules have no action lines and there are
no built-in or user-defined rules that apply, MMS executes the action line
specified by .DEFAULT and copies the required files into your directory.
(The MMS$SOURCE and MMS$TARGET special macros are described in
Section 2.4.)
NOTE

.DEFAULT cannot be changed or overridden from the MMS
command line.

2.7.4 .SUFFIXES Directive
The .SUFFIXES directive allows you to redefine the suffixes precedence list
so that you can reorder the list of file types, add new file types, or disable
recognition of all file types.
MMS uses the suffixes precedence list to determine the order in which it
looks for sources and targets when applying built-in rules. MMS also uses
this list to determine which built-in rule will update the specified target.
Section 2.2 contains a detailed discussion of how the suffixes precedence list
and MMS built-in rules work together. Also, Table C-4 lists the suffixes in
order of their precedence.
The .SUFFIXES directive has the following format:
.SUFFIXES [file types list]

The file types list is a list of file types in order of precedence. If you omit the
file types list entirely, the suffixes precedence list is cleared and all built-in
rules are disabled.
Once you set up a new list of suffixes, MMS recognizes only the specified file
types and enables built-in and user-defined rules for the specified suffixes.

MMS Description Files

2-33

2.7.5

Adding a New File Extension to the Suffixes List
In previous examples, the description files used file types that MMS knew
about through its built-in rules. Sometimes during software development,
you need file types that MMS does not know about (for example, when you
use a new programming language), or you use input and output files for a
custom application, or you have included files with other file types. You can
use user-defined rules and action lines in the description file to tell MMS
about new file types. First, you add the file types to the MMS suffixes list,
and then you write a user-defined rule or action line for the file type.
MMS uses the suffixes precedence list to analyze the relationship between
file types. Table C-4 lists the suffixes or file types in their order of precedence, from left to right, targets to sources. The targets at the beginning of
the list are created from some source to the right in the list. If you attempt
to write a user-defined rule for a new file type without adding the file type
to the list, the description file fails when it is run.

2.7.6

Using the .SUFFIXES Directive in a Description File
To add a new file type to your description file, use the directive .SUFFIXES.
It clears the default suffixes list and allows you to write a new list in the
description file. Table 2-2 lists the directives and their functions.
If you want MMS to access a CMS library, all the file types that could come
from the library must also be present in the suffixes list. (See Table C-4
for the Suffixes Precedence List.) When you write a new suffixes list in the
description file, it must contain all the file types that occur in your software
system, including the following:

•
•
•
•

Executable files
Different types of library files
Object files
Source code files

•

Included files

Consider the description file NEW_SUFFIX.MMS shown in Example 2-7.

2-34 MMS Description Files

Example 2-7:
$

Description File Using the .SUFFIXES Directive

TYPE NEW SUFFIX.MMS
! Set a new suffixes list
!

0.SUFFIXES
fj,SUFFIXES .EXE .OBJ .NEW .FOR
! User-defined rules

@.NEW.OBJ
@NEW_COMPILER $(MMS$SOURCE) $(MMS$TARGET)
0.0BJ.EXE
$(LINK) $(LINKFLAGS) $(MMS$SOURCE_LIST)
The executable and its sources
MAIN.EXE DEPENDS_ON MAIN.OBJ, SUBl.OBJ
Object files and their sources

G) MAIN.OBJ DEPENDS ON MAIN.FOR

CD SUBl.OBJ DEPENDS=ON SUBl.NEW

0 The first .SUFFIXES list clears the default suffix list. If you do not clear
the default suffixes list before adding a new file type, MMS appends
the new file types that you add to the end of the list. This is risky
because there is an implied hierarchy in the suffixes list. Adding a new
type of a source code file to the end of the list works, but adding an
intermediate file type to the end of the list destroys the order of the
suffixes precedence list.
fj This line contains the new suffixes list with all the file types used to

build this system.

8 This is the user-defined rule for the new file type just added to the suffix
0

precedence list. The command procedure NEW_COMPILER.COM is
invoked to call the new compiler.
The new compiler compiles the source code file in MMS$SOURCE into
an object file named by (MMS$SOURCE_LIST).

G) A built-in rule is applied for compiling the FORTRAN code file.

CD The new user-defined rule is applied for compiling and linking .NEW.

MMS Description Files

2-35

2.7.7

Building a System with a New File Extension
To build your system with the description file NEW_SUFFIX, you must have
the following files in your current directory:
$

DIR/DATE=MODIFIED

Directory DISKl: [BUILD]
MAIN.FOR;2
NEW_COMPILER.COM;S
NEW_SUFFIX.MMS;l
SUBl.NEW;l

17-JUL-1987
17-JUL-1987
17-JUL-1987
17-JUL-1987

14:27
14:27
14:27
14:27

Total of 4 files

MMS/DESCRIPTION=NEW_SUFFIX
FORTRAN /NOLIST/OBJECT=MAIN MAIN.FOR
@NEW COMPILER SUBl.NEW SUBl.OBJ
LINK /TRACE/NOMAP/EXEC=MAIN MAIN.OBJ SUBl.OBJ

0 MMS uses the new user-defined rule to com pile the new language.
Order of Suffixes

The order of suffixes changes according to their use:

2.7.8

•

In a dependency rule, the target is on the left and the source is on the
right.

•
•

In a suffixes list, the target is on the left and the source is on the right.
In a user-defined rule, the source is on the left and the target is on the
right.

Using the .SUFFIXES Directive with CMS Files
If you add a rule in your description file that directs MMS to build a .FOR
file by fetching it from a CMS library, the relationship between the rules and
the file types might be as shown in Figure 2-2.

2-36 MMS Description Files

Figure 2-2:

1.EXE

CMS Rules

.OBJ

~ ~
I

1.FOR

1.BAS

1.FOR-1

I
ZK-1665-GE

Section 4.2 explains how to specify CMS elements in description files. (The
tilde ( . . . ) signifies a file in a CMS library.) When MMS considers .FOR as
a possible target, it discovers that a rule exists for building .FOR files from
.FOR- files. Therefore, it looks for a file named MODS.FOR in the CMS
library. If one exists, it applies the known rule to update the .FOR target;
if it cannot find such a file, it continues searching for a file to use. If MMS
does locate MODS.FOR in the library, it can then use this file to create all
the necessary sources that finally result in an updated MODS.EXE, the
original target. The simple dependency MOD3.EXE : could result in the
following sequence of actions:
MOD3.FOR DEPENDS_ON MOD3.FORCMS FETCH MOD3.FOR
MOD3.0BJ DEPENDS ON MOD3.FOR
FORTRAN/OBJ~MOD3 MOD3.FOR
MOD3.EXE DEPENDS ON MOD3.0BJ
LINK/EXEC=MOD3 MOD3.0BJ

You can specify a null file type in the suffixes precedence list by using a freestanding period. For example, the following precedence list directs MMS to
look for files with null file types before looking for .B32 files:
.SUFFIXES .EXE .OBJ . . B32

2.7.9

.INCLUDE Directive
The .INCLUDE directive allows you to include other files in a description
file. You can use this directive when you have stored common macros or
user-defined rules in a separate file that can then be included by several
description files.

MMS Description Files

2-37

The .INCLUDE directive has the following format:
.INCLUDE filespec

A filespec is a VMS file specification or a logical name that identifies the
included file. The default file type is .MMS.
The line in the description file on which the .INCLUDE directive occurs is
replaced with the contents of the specified file.
Included files may themselves include files, up to a depth of 16 or the
maximum open file limit for your current process (as indicated by the
FILLM quota) or whichever is less. MMS treats lines read from an included
file as though they came from the original description file, except when it
detects syntax errors. If an error occurs, the error message indicates the
line number and the file in which the error was detected.

2. 7.10

.FIRST Directive
The .FIRST directive tells MMS to execute certain action lines before it
executes the action lines that update the target. The .FIRST directive works
with single or multiple targets. If you have selected multiple targets, then
.FIRST is executed before the entire group of targets.
The .FIRST directive has the following format:
.FIRST
action line ...

The action line is a command-language command that MMS executes before
it updates the target. You can specify as many action lines with .FIRST as
you like.
MMS executes the action lines that accompany the .FIRST directive only
if the target requires updating. The actions are executed before those that
actually update the target.
The following example shows how you might use .FIRST to send a mail
message to your process to notify you when MMS begins processing your
description file:
.FIRST
OPEN/WRITE MSGTEXT MSGTEXT.TXT
WRITE MSGTEXT "Build of $(MMS$TARGET) now beginning"
CLOSE MSGTEXT
MAIL MSGTEXT.TXT ANDERSON /SUBJECT="Report from MMS"

2-38 MMS Description Files

BOOK.MEM : CHAPTERl.MEM, CHAPTER2.MEM, CHAPTER3.MEM, CHAPTER4.MEM
COPY/LOG CHAPTERl.MEM BOOK.MEM
APPEND/LOG CHAPTER2.MEM BOOK.MEM
APPEND/LOG CHAPTER3.MEM BOOK.MEM
APPEND/LOG CHAPTER4.MEM BOOK.MEM
CHAPTERl.MEM : CHAPTERl.RNO
RUNOFF CHAPTERl
CHAPTER2.MEM : CHAPTER2.RNO
RUNOFF CHAPTER2
CHAPTER3.MEM : CHAPTER3.RNO
RUNOFF CHAPTER3
CHAPTER4.MEM : CHAPTER4.RNO
RUNOFF CHAPTER4

When this description file (BOOK.MMS) is processed, the following lines
appear on your terminal (or in your output file):
OPEN/WRITE MSGTEXT MSGTEXT.TXT
WRITE MSGTEXT "Build of BOOK.MEM now beginning"
CLOSE MSGTEXT
/SUBJECT="Report from MMS"
MAIL MSGTEXT.TXT ANDERSON
RUNOFF CHAPTERl
RUNOFF CHAPTER2
RUNOFF CHAPTER3
RUNOFF CHAPTER4
COPY CHAPTERl.MEM BOOK.MEM
APPEND CHAPTER2.MEM BOOK.MEM
APPEND CHAPTER3.MEM BOOK.MEM
APPEND CHAPTER4.MEM BOOK.MEM

2.7.11

.LAST Directive
The .LAST directive tells MMS to execute certain action lines after it has
executed the action lines that update the target. The .LAST directive works
with a single target or with multiple targets. If you have selected multiple
targets, then .LAST is executed after the entire group of targets.
The .LAST directive has the following format:
.LAST
action line ...

The action line is a command-language command that MMS executes after
it updates the target or targets. You can specify as many action lines with
.LAST as you like.
MMS executes the action lines that accompany the .LAST directive only
if the target requires updating. The actions are executed after those that
actually update the target.

MMS Description Files

2-39

The following example shows how you might use .LAST:
A.EXE : A.OBJ
LINK [GREGORY.OBJECTS]A.OBJ
A.OBJ : A.FOR
FORTRAN/LIST=[GREGORY.LISTINGS]A.LIS /OBJECT=[GREGORY.OBJECTS] A.FOR
.LAST
SET DEFAULT [GREGORY.OBJECTS]
DELETE/LOG A.OBJ;*
SET DEFAULT [GREGORY.LISTINGS]
PURGE/LOG A.LIS

If A.EXE needs to be updated, the LINK command is executed and produces
an object file in the directory [GREGORY.OBJECTS]. If A.OBJ needs to be
updated before it can update A.EXE, the FORTRAN command is executed
and produces a listing in the directory [GREGORY.LISTINGS]. After A.EXE
is up-to-date, the action lines associated with .LAST are executed to delete
the object file and purge the listings directory. Notice the output that might
be produced on your screen when you use the description file ADESC.MMS.
$ MMS/DESCRIPTION=ADESC
FORTRAN/LIST=[GREGORY.LISTINGS]A.LIS /OBJECT=[GREGORY.OBJECTS] A.FOR
LINK [GREGORY.OBJECTS]A.OBJ
SET DEFAULT [GREGORY.OBJECTS]
DELETE/LOG A.OBJ;*
%DELETE-I-FILDEL, USER$:[GREGORY]A.OBJ;l deleted (3 blocks)
SET DEFAULT [GREGORY.LISTINGS]
PURGE/LOG A.LIS
%PURGE-I-FILPURG, USER$: [GREGORY.LISTINGSJA.LIS;4 deleted (6 blocks)

MMS allows you to perform a set of commands before or after all other
actions through the use of the .FIRST and .LAST directives. The .FIRST
and .LAST sections are executed only if MMS decides to take other actions
to update a target.

2.7.12

.IFDEF, .ELSE, and .ENDIF Directives
The .IFDEF directive tests whether a specified macro is defined. You use
this directive to cause MMS not to process certain lines in your description
file if the macro is undefined.
The .IFDEF directive has the following format:
.IFDEF macro
[description file line] ...
. ENDIF

Macro is the name of the macro being tested. The description file line is zero
or more action lines that are valid in a description file.
2-40 MMS Description Files

The .IFDEF directive must always be accompanied by a matching .ENDIF
directive. MMS checks for a definition of the macro specified with the
.IFDEF directive. If the macro is undefined, all lines of the description file
between .IFDEF and .ENDIF (even lines that contain .IFDEF directives) are
ignored.
Consider the following description file, FORPROG.MMS:
.IFDEF VAX
A.OBJ : A.FOR
FORTRAN A
.END IF
. IFDEF PDP 11
A.OBJ : A.FOR
FORTRAN/PDPll A
.ENDIF

When you invoke MMS with this description file, you can define one of the
macros on the command line to determine which action line gets executed.
For example:
$ MMS/DESCRIPTION=FORPROG/MACRO="VAX"
FORTRAN A /NOLIST/OBJECT=A.OBJ A.FOR
LINK A.OBJ
$

Because the command line defines the macro VAX, the command FORTRAN
A is executed and the commands associated with the undefined macro
PDPll are ignored.
You may use the .ELSE directive in conjunction with the .IFDEF directive
but never alone. If the specified macro for the .IFDEF directive is undefined,
MMS skips all the subsequent lines of the description file until it comes
to a .ELSE or a .ENDIF directive. The next example of a description file
shows the format for a .IFDEF directive using .ELSE and a nested .IFDEF
directive:
.IFDEF VAX
.IFDEF CURRENT
A.OBJ : A.FOR
FORTRAN A
.ENDIF
A.EXE : A.OBJ
LINK A.OBJ
.ELSE
A.OBJ : A.FOR
FORTRAN/PDPll A
.ENDIF

MMS Description Files 2-41

MMS reads the line beginning with the .IFDEF directive and tests whether
the macro is defined. If the macro is defined, MMS processes the action
lines between .IFDEF and the second .ENDIF except for the lines between
the .ELSE and the second .ENDIF. If the specified macro for the .IFDEF
directive is undefined, MMS skips all the action lines including the nested
.IFDEF, until it reaches the .ELSE directive. MMS then processes the
subsequent lines to the .ENDIF. When you invoke MMS with the FORPROG
description file, you can define the nested macro on the command line as
follows:
$ MMS/DESCRIPTION=FORPROG/MACRO="VAX=CURRENT"
FORTRAN A
$

2-42 MMS Description Files

Chapter 3

Advanced Description File Techniques

Once you become familiar with MMS, you can use advanced techniques
in your description file to make it more flexible and useful. This chapter
describes the following techniques:

3.1

•

Double colon dependencies

•

Invoking MMS from a description file

•

Invoking MMS from a command procedure

•

Invoking a command procedure from a description file

•
•

Gathering statistics
Doing parallel processing

•

Producing multiple outputs

•

Changing build options

Using Double Colon Dependencies
In writing MMS dependency rules, you can specify the same target in more
than one dependency rule, provided that you specify only one action for
updating that target. For example, the following construction is legal:
MOD2.0BJ, MOD3.0BJ : DEFSl.DEF
MOD2.0BJ : DEFS2.DEF
PASCAL MOD2

MOD2.0BJ appears in the target list of two dependency rules, but only one
action (PASCAL MOD2) is specified for it.

Advanced Description File Techniques

3-1

In contrast, the following construction is invalid:
MOD2.0BJ, MOD3.0BJ : DEFSl.DEF
PRINT DEFSl.DEF
MOD2.0BJ : DEFS2.DEF
PASCAL MOD2

Two different actions are specified for MOD2.0BJ, requiring MMS to take
two different actions if one of MOD2.0BJ's dependencies is changed.
If you want MMS to take different actions depending on which sources have
changed, MMS allows you to use a double colon rather than a single colon
to separate the target list from the source list in a dependency rule. (You
can use the keyword ADDITIONALLY_DEPENDS_ON in place of the
double colon.) For example, in the previous dependency rules, MMS was to
execute the PRINT command if DEFSl.DEF had changed and the Pascal
command if MOD2.PAS had changed. The double colon or the keyword
ADDITIONALLY_DEPENDS_ON directs MMS to allow the same target to
be specified in more than one dependency rule, each of which may require
different actions to update the target. By using the double colon, you can
modify the previous example to execute as you intended:
MOD2.0BJ, MOD3.0BJ :: DEFSl.DEF ! If at least one source is
PRINT DEFSl.DEF
! newer than targets, print DEFSl.DEF
MOD2.0BJ :: DEFS2.DEF
PASCAL MOD2

! If MOD2.PAS or DEFS2.DEF is newer than
! MOD2.0BJ, compile MOD2.PAS

Note that in this example, if DEFS2.DEF or MOD2.PAS is newer than
MOD2.0BJ and DEFSl.DEF, both action lines are executed. However, that
is the normal behavior of MMS. In effect, double colons produce the same
result as single colons, so their usefulness is limited.
In a description file, a given target can be included either in a single colon
dependency rule or in a double colon dependency rule, but not in both. MMS
issues an error message if you try to specify both kinds of rules for the same
target.

3.2 Maintaining a Library of Object Files
You can use MMS to maintain a library of object files. Consider the library
called UTIL.OLB, which contains three object modules: MODI.OBJ,
MOD2.0BJ, and MODS.OBJ. If one of these object modules is updated, it
should be added to the library. A description file for this system might look
like the following:

3-2

Advanced Description File Techniques

UTIL.OLB :: MODl.OBJ
LIER UTIL.OLB MODl.OBJ
UTIL.OLB :: MOD2.0BJ
LIER UTIL.OLB MOD2.0BJ
UTIL.OLB :: MOD3.0BJ
LIER UTIL.OLB MOD3.0BJ

UTIL.OLB depends on all three object modules, but MMS takes different
actions depending on which module is out of date. However, library module
file specifications are not allowed as targets in double colon dependency
rules. For example, the following dependency rules cause MMS to perform
the same actions as the previous examples but they are written with the
single colon rule:
UTIL(MODl) : MODl.OBJ
LIER UTIL.OLB MODl.OBJ
UTIL(MOD2) : MOD2.0BJ
LIER UTIL.OLB MOD2.0BJ
UTIL(MOD3) : MOD3.0BJ
LIER UTIL.OLB MOD3.0BJ

When using the library module specification format, only the single colon is
acceptable to MMS.

3.3 Invoking MMS from a Description File
When you invoke MMS, it runs two processes as it updates a target. The
first process, your current process, executes MMS. The second process, a
spawned subprocess, executes the action line you specified in the description
file to update the target. MMS creates a spawned subprocess only when
the target needs updating, and it creates only one spawned subprocess to
execute all the actions in the description file. The subprocess is created
when the first action is executed; it remains active until the MMS image
terminates.
While a subprocess executes an action (such as a DCL command), the parent
process waits until it is notified that the subprocess has finished executing
commands. If you monitor the parent process, you may find it idle.
You can invoke MMS from a description file while MMS is updating a target.
Consider the following description file:
MAIN.EXE DEPENDS ON MAIN.OBJ
MMS/DESCRIPTION=TOOLS LIB
LINK MAIN.OBJ, TOOLS_LIB/LIB
MAIN.OBJ DEPENDS ON MAIN.PAS

Advanced Description File Techniques

3-3

In this example, the executable file MAIN.EXE is rebuilt if MAIN.OBJ
has been changed since the last build. However, before MMS performs the
linking action, an MMS subprocess is invoked to rebuild and update the
library if necessary.

3.3.1

Using the $(MMS) Reserved Macro
You can also invoke MMS from within a description file by specifying the
reserved macro $(MMS) on an action line where you want MMS to be
invoked again.
When you invoke MMS from a description file with the $(MMS) reserved
macro, another subprocess is used to execute the new invocation of MMS.
The second invocation of MMS runs as a spawned subprocess that inherits
any existing symbol definitions. The original subprocess is treated as a
parent process for the subsequent MMS execution.
As MMS processes the description file, it executes any action line that
contains the reserved macro $(MMS), even if you specified the /NOACTION
qualifier on the command line. (/NOACTION suppresses the execution of
action lines and is described in the Command Dictionary.) Thus, the MMS
subprocess is created but no other actions are performed.

3.3.2

Process Quotas for MMS Subprocesses
When a subprocess is created, the VMS operating system automatically
assigns it a portion of the quotas established for your main process. Under
heavily loaded systems, it is possible for the top-level MMS subprocess to
complete before VMS has finished with the exit-cleanup code for the secondlevel MMS subprocess. If MMS tries to invoke another subprocess, you may
receive the following error message:

%MMS-F-DRVINSQUO, Your process needs a PRCLM of at least 2, current value is 0.

In this case, you can increase your PRCLM quota or add the DCL WAIT
statement in your description file. For example:
IF F$SEARCH ("$ (MMS$SOURCE) ") .NES. "" THENDESCRIPTION = "/DESCRIPTION=$(MMS$SOURCE)"
- $(MMS) /NOSKIP$(MMSQUALFIERS)/OVERRIDE/RULES=BUILD COM:DESCRIP BUILD' DESCRIPTION' $(MMS$SOURCE)
WAIT 0:0:5
- $(MMS) /NOSKIP$(MMSQUALIFIERS)/OVERRIDE/RULES=BUILD COM:PLI/DESCRIPTION=$ (MMS$SOURCE)

3-4

Advanced Description File Techniques

3.3.3

Process Quotas for Using MMS
To invoke MMS as a top-level process, you need the minimum process quotas
shown in Table 3-1.
Table 3-1:

MMS Process Quotas

Process

Quota

PRCLM

A subprocess limit of 2

FILLM

An open file limit of 16

BYTLM

A buffered I/O byte limit of 8192 (nonrecursive) and 13000 (recursive)

ASTLM

An asynchronous trap limit of 25

If you get the error message reflecting a "virtual memory exceeded" error,
you may also need to increase your PGFLQUO (page file quota). If you use
MMS recursively, that is, you invoke MMS from within an MMS process,
then MMS requires even higher quotas.

3.3.4

MMS Reserved Macros
MMS includes two other reserved macros, $(MMSQUALIFIERS) and
$(MMSTARGETS), which you can use when you invoke MMS as a subprocess. Both of these qualifiers pass to the subprocess the same information
you specified on the command line that invoked MMS:
•
•

$(MMSQUALIFIERS) passes the command-line qualifiers.
$(MMSTARGETS) passes the targets from the command line.

These two macros and $(MMS) are reserved macros; you cannot redefine
them.
The $(MMSQUALIFIERS) macro does not pass the /DESCRIPTION,
/OUTPUT, /IGNORE, and /NORULES qualifiers. To use these qualifiers
when invoking MMS from a description file, you must explicitly specify them
after $(MMSQUALIFIERS), as shown in the following example:
TESTS.EXE :
$(MMS) $(MMSQUALIFIERS) /DESCRIPTION=[GREGORY]TESTBUILD $(MMSTARGETS)

Advanced Description File Techniques 3-5

If you do not use the $(MMSQUALIFIERS) macro, MMS uses the default
qualifiers. A list of the default qualifiers and complete descriptions of all
MMS qualifiers are contained in the Command Dictionary.

The following example shows a description file, ALL.MMS, that contains two
subprocess invocations of MMS:
ALL.EXE : A.OBJ, B.OBJ
LINK/EXEC=ALL A,B
A.OBJ :
$(MMS) $(MMSQUALIFIERS) /DESCRIPTION=A A.OBJ
B.OBJ :
$(MMS) $(MMSQUALIFIERS) /DESCRIPTION=B B.OBJ

Before MMS can update the target, ALL.EXE, it must check the two sources,
A.OBJ and B.OBJ, to make sure they are up-to-date. If either needs to be
updated, MMS spawns a subprocess, using the specified description file. If
both A.OBJ and B.OBJ need to be updated, the output from this example is
the following:
$ MMS/DESCRIPTION=ALL
MMS /DESCRIPTION=A A.OBJ
PASCAL A
MMS /DESCRIPTION=B B.OBJ
PASCAL B
LINK/EXEC=ALL A,B
$

If you invoke MMS with the /NOACTION qualifier and the same description
file, the following output results:
$ MMS/DESCRIPTION=ALL/NOACTION
MMS /NOACTION /DESCRIPTION=A A.OBJ
PASCAL A
MMS /NOACTION /DESCRIPTION=B B.OBJ
PASCAL B
LINK/EXEC=ALL A,B
$

The MMS subprocesses are created, but the PASCAL and LINK commands
are not executed to update the targets because you specified /NOACTION on
the MMS command line.

3.4 Invoking MMS from a Command Procedure
The previous description files have built software systems in a fixed way.
You can build variations of your software system without modifying the
description file by invoking MMS from a command procedure. The command
procedure controls the actions MMS performs. You can use user-defined
macros in a command procedure to change MMS's default actions.
3-6 Advanced Description File Techniques

Some of the ways you can vary building your software systems can include
the following:
•
•
•

Using /DEBUG versus /NODEBUG images
Producing listing files versus no listing files during compilation
Using /OPTIMIZE versus /NOOPTIMIZE during compilaton

It is better to have the description file reflect the basic structure of your
software system and use command procedures to produce variations in your
build process. The description file should not be concerned with changing
the details of compile and link options.
Command Procedures and User-Defined Macros

MMS has two types of built-in macros: default macros and special macros.
MMS default macros stand for parts of built-in actions and can be overridden. MMS special macros stand for targets and sources and cannot be
overridden. The special macros are defined when you invoke MMS and cannot be changed. Default macros are a set of string variables containing the
names of VMS utilities and qualifiers.
You can create a user-defined macro for a CLI symbol. With the /OVERRIDE
qualifier, you can instruct MMS to use the value of the user-defined macro in
your command procedure over the default value of the CLI symbol. Consider
the command procedure, DEBUG_VERSION.COM, and the MMS description
file SYSTEMl.MMS, shown in Example 3-1.

Advanced Description File Techniques

3-7

Example 3-1:

Invoking MMS from a Command Procedure

TYPE DEBUG VERSION.COM

$
$
$
$
$

-------------------------------------------------------

Corrunand procedure using the /OVERRIDE qualifier with MMS

Create the user defined macros we want

$ !

0$ PFLAGS = "/LIST/NOOPTIM/DEBUG"
0$ LINKFLAGS = "/MAP/DEBUG"
$

$ ! Invoke MMS and direct it to use our macros
$ !

@$ MMS /DESCRIPTION=SYSTEMl /OVERRIDE
$

-------------------------------------------------------

TYPE SYSTEMl.MMS

MAIN.EXE DEPENDS ON MAIN.OBJ
MAIN.OBJ DEPENDS_ON MAIN.PAS

0 PFLAGS and LINKFLAGS are CLI symbols with the same names as
those of the default macros but set with new values.

8 MMS with the /OVERRIDE qualifier is invoked from within the com-

mand procedure to use the new CLI symbol values instead of the built-in
default values.
The description file describes the dependencies.

This example produces a software system very different from the one MMS
would normally have built. The user-defined macro definitions in the command procedure appear in the MMS output exactly where the default macro
actions would have appeared. To invoke this command procedure you need
the following files in your current directory:
$

DIR/DATE=MODIFIED

Directory DISKl: [BUILD]
MAIN.PAS;3
DEBUG_VERSION.COM;2
SYSTEMl.MMS;l

18-JUL-1987 16:35
18-JUL-1987 16:35
18-JUL-1987 16:35

Total of 3 files.

@DEBUG_VERSION

3-8 Advanced Description File Techniques

PASCAL /LIST/NOOPTIM/DEBUG MAIN.PAS
LINK /MAP/DEBUG MAIN.OBJ

MMS uses the user-defined rules to compile and link your program.

3.5 Invoking a Command Procedure from a Description File
You can invoke DCL command procedures from your description file. The
following example describes a command procedure that loops until a given
file becomes available. You can invoke that command procedure, called
GETFILE.COM, from your description file as in Example 3-2.
Example 3-2:

Invoking a Command Procedure from a Description File

$TYPE GETFILE.COM
$ LABEL:
$ IF "' 'F$SEARCH("' 'Pl' ")'II .NES. 1111 THEN GOTO DONE
$WAIT +:'P2'
$ GOTO LABEL
$ DONE:
$TYPE GET_NEXT.MMS
GET NEXT INFO :
- MAIL NL: $(MY PROC)/SUBJECT="string"
@GETFILE ANSWER.IN 15
@ANSWER.IN
$MMS/DECRIPTION=GET_NEXT

You can use this command procedure when you start MMS in a batch job.
ANSWER.IN corresponds to the Pl parameter, and 15 is the polling interval
(in minutes) that corresponds to the P2 parameter. ANSWER.IN might
modify the environment in some way. For example, it might set a CMS
library at a point where MMS cannot find the right CMS library.
The $(MY_PROC) macro in this description file is assumed to be a DCL
symbol that represents a valid electronic mail address.
NOTE

Be sure you do not leave a space between the at sign (@) and the
name of the command procedure, so that MMS does not interpret
the at sign as the Silent action line prefix.

Advanced Description File Techniques 3-9

3.6 Changing System Build Options
During software development, the number of description files and major
aspects of build procedures can change frequently. You can edit the
command procedure to make the changes. As the MMS description file
becomes stable, you can create a command procedure that prompts you
for different system-building options. You can write a very complicated
command procedure that asks you for compilation options, for link options,
and for executable targets (when your description file has multiple targets).
The command procedure can send you mail when the build is complete and
move the results to another directory. You can also do some error checking
for your input or add a default option for your input.
The command procedure CHANGE_OPTIONS.COM, shown in Example 3-3,
uses the DCL INQUIRE command to change compiling and linking options
for a system build.
Example 3-3:

Command Procedure to Change Build Options

TYPE CHANGE OPTIONS.COM

$
$
$
$

Command procedure to vary build options for MMS

Ask for compilation and linking options

$ INQUIRE PFLAGS "Enter PASCAL compilations options"
$ INQUIRE LINKFLAGS "Enter link options"
$ !
$ ! Invoke MMS and direct it to use new default macros
$

$ MMS /DESCRIPTION=SYSTEMl /OVERRIDE
$

TYPE SYSTEMl.MMS

MAIN.EXE DEPENDS ON MAIN.OBJ
MAIN.OBJ DEPENDS ON MAIN.PAS

ct Enter PASCAL compilations options:

/LIST/NOOPTIM/DEBUG

C» Enter link options:

/MAP/DEBUG
~PASCAL /LIST/NOOPTIM/DEBUG MAIN.PAS
~ LINK /MAP/DEBUG MAIN.OBJ

(continued on next page)

3-1 O Advanced Description File Techniques

Example 3-3 (Cont.):

Command Procedure to Change Build Options

@) $

EDIT MAIN.PAS

0 $

@CHANGE OPTIONS

t) Enter PASCAL compilations options:
/NODEBUG/NOLIST
t) Enter link options:
/NOMAP/NODEBUG
@ PASCAL /NODEBUG/NOLIST MAIN.PAS
@LINK /NOMAP/NODEBUG MAIN.OBJ

0 The command procedure prompts you for compiling and linking options.
8 The system is built using the options you supplied.
8 The MAIN.PAS file is edited to force MMS to rebuild the system. If you
0

invoked MMS again without changing anything, MMS would find the
system up-to-date and take no action.
The command procedure prompts you for options that change the way
you built your system the last time.

Nate that if you change the way a system is built either by modifying the
description file or by modifying the command procedure that calls it, MMS
does not necessarily rebuild the system. MMS bases its actions on the dates
of the software system itself. MMS does not compile or relink the system
just because you added a user-defined macro to your description file or your
command procedure.
To invoke the CHANGE_OPTIONS command procedure, you need the
following files in your current directory:
$

DIR/DATE=MODIFIED

Directory DISKl: [BUILD]
CHANGE_OPTIONS.COM;l
MAIN.PAS;3
SYSTEMl.MMS;l

21-JUL-1987 15:51
18-JUL-1987 16:35
18-JUL-1987 16:35

Total of 3 files.

@CHANGE_OPTIONS

Advanced Description File Techniques

3-11

3. 7 Gathering Statistics
The examples in the following sections describe the methods for using MMS
to gather statistics about your files.

3.7.1

Finding Missing Sources
If you have stored the sources for your software system in a source directory

or CMS library and you want to make sure all the sources are there, you can
get a list of any missing files by inserting the .DEFAULT directive in your
description file. For example:
.DEFAULT :
IF "''F$SEARCH("MISSING.SRC")'" .EQS. ""THEN COPY NL: MISSING.SRC
OPEN/APPEND MSING MISSING.SRC
WRITE MSING "missing $(MMS$TARGET_NAME)"
CLOSE MSING

When you process this description file with MMS, MISSING.SRC contains
the list of missing files.

3.7.2

Creating a Checkpoint File
You can use MMS to create a checkpoint file that indicates when MMS
finishes building a target. For example, if your directory contains source
files TESTl.C, TEST2.C, and TEST3.C and you want MMS to create .EXE
files from each of these sources and also to inform you when each target is
complete, the following example shows a description file that accomplishes
these tasks. This description file builds TESTl.EXE, TEST2.EXE, and
TEST3.EXE and creates a file called CHECK.PNT that indicates the time
the executable files were completed.
! Suffixes list with .PNT in the first position .
. SUFFIXES
.SUFFIXES .PNT .EXE .OBJ .C .C! User-defined rule to build .EXE files from .PNT files .
. EXE.PNT :
IF "''F$SEARCH("CHECK.PNT")'" .EQS. ""THEN COPY NL: CHECK.PNT
OPEN/APPEND CHECK CHECK.PNT
WRITE CHECK "Completed build of $ (MMS$SOURCE) at ' ' f$time () '"
CLOSE CHECK

3-12

Advanced Description File Techniques

MAIN_TARGET : TESTl.PNT, TEST2.PNT, TEST3.PNT
MAIL CHECK.PNT MICHAELS /SUBJECT="Build summary of $(MMS$TARGET_NAME) ending at ''f$time()'"
DELETE CHECK.PNT;

NOTE

The executable files will be built before the .PNT files are processed. The .PNT files are temporary files that allow the actions
that produce the file to be localized in one place (the .EXE.PNT
rule).
When you run MMS, the action lines are displayed as follows:
CC /NOLIST TESTl.C
LINK /TRACE TESTl.OBJ
IF '" 'F$SEARCH("CHECK.PNT") '" .EQS. "" THEN COPY NL: CHECK.PNT
OPEN/APPEND CHECK CHECK.PNT
WRITE CHECK "Completed build of TESTl.EXE at ''f$time()'"
CLOSE CHECK
CC /NOLIST TEST2.C
LINK /TRACE TEST2.0BJ
IF "''F$SEARCH("CHECK.PNT")'" .EQS. ""THEN COPY NL: CHECK.PNT
OPEN/APPEND CHECK CHECK.PNT
WRITE CHECK "Completed build of TEST2.EXE at ''f$time()'"
CLOSE CHECK
CC /NOLIST TEST3.C
LINK /TRACE TEST3.0BJ
IF "''F$SEARCH("CHECK.PNT")'" .EQS. ""THEN COPY NL: CHECK.PNT
OPEN/APPEND CHECK CHECK.PNT
WRITE CHECK "Completed build of TEST3.EXE at ''f$time()'"
CLOSE CHECK
MAIL CHECK.PNT MICHAELS/SUBJECT="Build summary of MAIN TARGET
ending at ''f$time()'"
DELETE CHECK.PNT;

The mail message sent to your process looks like the following:
From:
To:
Subj:

MICHAELS
21-FEB-1987 14:48
MICHAELS
Build summary of MAIN_TARGET ending at 21-FEB-1987 14:48:06.85

Completed build of TESTl.EXE at 21-FEB-1987 14:47:32.99
Completed build of TEST2.EXE at 21-FEB-1987 14:47:49.65
Completed build of TEST3.EXE at 21-FEB-1987 14:48:06.33

3.8 Creating and Using Time Stamps
You can use MMS to create time stamps for such purposes as tracking the
progress of the system and determining whether any sources have changed
since the last time the system was built.
You can use either DCL symbols or included files to create a time stamp.
Advanced Description File Techniques 3-13

3.8.1

Using DCL Symbols
The following description file creates the file CMSMODS.RPT, which reports
the number of modified sources by checking replace operations in the CMS
library.
PROJECT SOURCES = PARSE.Y, TOUCH.C, GM.C, DRIVE.C, CLP.C, LEX.C, GRAFBUILD.C, GRAFWALK.C, LFS.C, MACROBANK.C, MB.C, MMSPRINT.C, UTILS.C, EXECCMD.C, RULES.C, LBR.C, CMSACCESS.C, MMSMSG.MSG, FILTER.C, GRAPH.H, GLOBALS.H, LBRDEF.H, PDEFS.H, TOKEN.H, CLP.H, TC.H
! Special CMS filetypes not included by default .
. SUFFIXES : .Y .Y! New CMS rules (Note: no real CMS fetches occur)
.MSG-.MSG :
COPY NL: $(MMS$TARGET NAME) .MSG
! Create the new time stamp file
PUR $(MMS$TARGET_NAMEl.MSG
! Remove the old one, if any
MODS = MODS + 1
! Increment the modification counter
.H-.H :
COPY NL: $(MMS$TARGET NAME) .H
PUR $(MMS$TARGET_NAME).H
MODS = MODS + 1

.c-.c :
COPY NL: $(MMS$TARGET NAME) .C
PUR $(MMS$TARGET_NAME).C
MODS = MODS + 1
.Y-.Y :
COPY NL: $(MMS$TARGET NAME) .Y
PUR $(MMS$TARGET_NAME).Y
MODS = MODS + 1
Primary Target
MODS : INIT $(PROJECT_SOURCES)
IF II'' F$SEARCH ( "CMSMODS. RPT") '" . EQS. "" THEN COPY NL: CMSMODS.RPT
OPEN/APPEND CHECK CMSMODS.RPT
WRITE CHECK "''MODS' MODIFICATIONS DETECTED AT ' ' F$TIME () '"
CLOSE CHECK
INIT :
MODS = 0

CMSMODS.RPT can be used in some form as input to a program that prints
a graph of CMS replace operations with relation to a number of days. Such
a graph can be used as an indication of how stable a given project's source
code is with respect to its milestones.
It is a good idea to run a description file such as the one in this example on
a daily or otherwise frequent basis. You may want to put the appropriate
MMS command in your LOGIN.COM file.

3-14 Advanced Description File Techniques

3.8.2

Using Included Files
Consider the following directories and files:
[DIRl] contains FILEl.X
[DIR2] contains FILE2.Y
[DIR3) contains FILE3.Z

MMS can build a file to report changes to these files. The following description file creates the file CHANGES.DOC, which reports when changes were
made to the source:
. SILENT
RECORD CHANGE = .INCLUDE CHANGE.REC
REPORT CHANGE : INIT FILEl.TIM FILE2.TIM FILE3.TIM
IF "' 'F$SEARCH ("CHANGES. DOC")'" . NES. "" THEN TYPE CHANGES.DOC
IF 1" 'F$SEARCH ("CHANGES. DOC") '" . EQS. 1111 THEN WRITE SYS$0UTPUT "No changes detected"
INIT
IF "', F$SEARCH ("CHANGES. DOC")'
NES.
THEN DELETE CHANGES.DOC;*/NOLOG
II

•

II"

Testing the time stamps
FILEl.TIM : [DIRl)FILEl.X
$(RECORD_CHANGE)
FILE2.TIM : [DIR2)FILE2.Y
$(RECORD_CHANGE)
FILE3.TIM : [DIR3)FILE3.Z
$(RECORD_CHANGE)

Because the .SILENT directive suppresses the display of action lines, MMS
displays one of two pieces of information when it processes this description
file:
•

If no changes were made to the files, MMS prints "No changes detected,"
as instructed in the REPORT_CHANGE action line.

•

If changes were made to the files, MMS displays the contents of the file
CHANGES.DOC, as instructed in the REPORT_CHANGE action line.
CHANGES.DOC lists the files that were changed and the times the
changes were made.

Advanced Description File Techniques 3-15

CHANGE.REC, the file included by the RECORD_CHANGE macro, is the
recording procedure (rule) for making a change. It contains the following
actions:
IF "' 'F$SEARCH("CHANGES.DOC"), II .EQS. "" THEN COPY NL: CHANGES.DOC
OPEN/APPEND CHANGE CHANGES.DOC
WRITE CHANGE "Changes to $(MMS$SOURCE) noted ''f$time()'"
CLOSE CHANGE
COPY NL: $(MMS$TARGET NAME) .TIM
PURGE $(MMS$TARGET_NAME) .TIM

You can substitute different recording procedure files for CHANGES.REC
without changing the description file every time. To do so, create the same
description file described in the example, but omit the RECORD_CHANGE
macro. Also, replace the invocations of the RECORD_CHANGE macro with
.INCLUDE $(REC_PROC). After these changes, the description file appears
as follows:
.SILENT
REPORT CHANGE : INIT FILEl.TIM FILE2.TIM FILE3.TIM
IF ",, F$SEARCH ("CHANGES. DOC") I II • NES. " I I THEN TYPE CHANGES.DOC
IF ,,, , F$SEARCH ("CHANGES. DOC") , II • EQS. 1111 THEN WRITE SYS$0UTPUT "No changes detected"
INIT
IF ",, F$SEARCH ("CHANGES. DOC") , II • NES.
THEN DELETE CHANGES.DOC;*/NOLOG

II"

Testing the time stamps
FILEl.TIM : [DIRl]FILEl.X
.INCLUDE $(REC_PROC)
FILE2.TIM : [DIR2]FILE2.Y
.INCLUDE $(REC_PROC)
FILE3.TIM : [DIR3]FILE3.Z
.INCLUDE $(REC_PROC)

REC_PROC is a macro that you define on the MMS command line to be the
name of a recording procedure file you want to use at the time. Type the
following command line to use the file of your choice:
$ MMS/MACRO="REC_PROC=@filename"

3-16

Advanced Description File Techniques

3.9 Deleting Files Selectively
Usually after updating your system, you will want to delete the intermediate
files from your working directory. Or you might want intermediate files to
be deleted automatically after an MMS build. You can accomplish this task
in three different ways:
•

Create a command procedure.

•
•

Use a macro definition.
Use the .LAST directive.

The first two methods are described in the following sections. The use of the
.LAST directive is described in Section 2. 7.11.

3.9.1

Using a Command Procedure
To use a command procedure to delete files selectively, create the procedure
in the description file. Modify the dependencies or the default rules to
include the following actions:
IF "''F$SEARCH("DELETE.COM")'" .EQS. "" THEN COPY NL: DELETE.COM
OPEN/APPEND DEL FILE DELETE.COM
WRITE DEL_FILE "$DELETE $(MMS$SOURCE);"

NOTE

Usually, you will want to modify only the .OBJ.OLE rule to
include these actions. However, to delete everything, you can
modify all the rules you use; take care that you are deleting only
those files you want deleted.
The modified .OBJ.OLE rule appears as follows:
.OBJ.OLE :
IF "' 'F$SEARCH("$ (MMS$TARGET) ")I II .EQS. "" THEN $(LIBR)/CREATE $(MMS$TARGET)
$(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
IF "' 'F$SEARCH("DELETE.COM'') I " .EQS .. "" THEN COPY NL: DELETE.COM
OPEN/APPEND DEL FILE DELETE.COM
WRITE DEL FILE-;;-$ DELETE $(MMS$SOURCE);"

Advanced Description File Techniques

3-17

Once you have modified the rule, add a target such as the following to your
description file:
DELETE : MYPROG.EXE
- @DELETE.COM

! The name of the target

Note that the Ignore action line prefix(-) is used to prevent MMS from
aborting execution if it detects errors (such as the absence of files) while
deleting files.
To delete .OBJ files that MMS created during a build, you need type only
the following:
$

MMS/SKIP_INTERMEDIATE DELETE

The /SKIP_INTERMEDIATE qualifier causes MMS not to rebuild the files
that were deleted.

3.9.2

Using a Macro Definition
There are two ways of using macros for the selective deletion of files:
•
•

Use a macro definition on the MMS command line.
Use a DCL symbol as a macro.

To use a macro on the command line to delete files, modify the desired rule
to include the following action:
IF "$(CLEAN)" .NES "" THEN DELETE $(MMS$SOURCE);

Thus, the .OBJ.OLE rule appears as follows:
.OBJ.OLE :
IF "' 'F$SEARCH ("$ (MMS$TARGET) ")'II .EQS. "" THEN $(LIBR)/CREATE $(MMS$TARGET)
$(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
IF "$(CLEAN)" .NES ""THEN DELETE $(MMS$SOURCE);

The command line is the following:
$

MMS/CMS/SKIP/MACRO="CLEAN=CLEAN"

You can equate the macro to any character string that you like; MMS simply
needs to be able to expand the CLEAN macro to something other than the
null string.

3-18

Advanced Description File Techniques

To use a DCL symbol as a macro for deleting files, add the same action line
to the desired rule as for using a macro on the command line. However,
substitute "CLEAN" for $(CLEAN), as follows, where CLEAN is a global CLI
symbol:
.OBJ.OLE
IF '"'F$SEARCH("$(MMS$TARGET)")'" .EQS. 1111 THEN $(LIBR)/CREATE $(MMS$TARGET)
$(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
IF '"'CLEAN'" .NES 1111 THEN DELETE $(MMS$SOURCE);

You can use the same macro definition on the command line as in the
previous example. If you do not want to define the macro on the command
line, make sure that the DCL symbol CLEAN is defined before you invoke
MMS. Then the command line can be shortened as follows:
$

MMS/CMS/SKIP

3.1 O Using Parallel Processing
If you have a large system to build, you can process different parts of it

simultaneously by adding rules, such as the following, to the beginning of
your existing description file:
PARALLEL PROC : TARGl TARG2 TARG3
! Files submitted

Names for parts of your system

TARGl :
MMS/CMS/OUT=TARGl.COM/NOACTION PROG.EXE
SUBMIT $(MMS$TARGET_NAME)
TARG2 :
MMS/CMS/OUT=TARG2.COM/NOACTION MOD.EXE
SUBMIT $(MMS$TARGET_NAME)

The rules building the parts of your system
FROG.EXE : PROG.OBJ
action
MOD.EXE : MOD.OBJ
action

This description file causes MMS to process the parts of your system "in
parallel" or simultaneously, resulting in shorter processing time and earlier
error detection.

Advanced Description File Techniques

3-19

3.11

Using MMS in Complex Examples
This section demonstrates the following advanced uses of MMS:
•
•

3.11.1

A description file that uses object libraries
A description file that results in multiple outputs

MMS and Object Libraries
Example 3-4 contains a sample MMS description file using object libraries.

Example 3-4:

Description File Using Object Libraries

DESCRIP.MMS
!

This description file builds the INTERCOM facility.

Define macros for the following commands and built-in rules
DEBUG
TRACE
LIST
BFLAGS
MF LAGS
CLDFLAGS
!LIBRFLAGS
LIBRFLAGS
LINKFLAGS

/noDEBUG
/no TRACE
/LIST=LIS$:
${LIST) ${DEBUG) /TERM=STAT
${LIST) ${DEBUG)
${LIST)
/LOG
/FULL ${DEBUG) ${TRACE) /MAP=LIS$:

! TNAME gives just the name portion of the target
TNAME
I

i8
.SUFFIXES
.SUFFIXES

= 'F$PARSE{"MMS$TARGET_NAME",,,"NAME","SYNTAX_ONLY")
Define "built-in" rules

.EXE .OLB .OBJ .B32 .BLI .MAR .CLD .L32 .R32 .REQ .SDL .MSG

(continued on next page)

3-20 Advanced Description File Techniques

Example 3-4 (Cont.):
.B32.0BJ
.MSG.OBJ
.MAR.OBJ
.CLO.OBJ
.REQ.L32

Description File Using Object Libraries

$(BLISS) $(BFLAGS) /OBJ=$(MMS$TARGET) $(MMS$SOURCE)
MESSAGE $(LIST) /OBJ=$(MMS$TARGET) $(MMS$SOURCE)
$(MACRO) $(MFLAGS) /OBJ=$(MMS$TARGET) $(MMS$SOURCE)
SET COMMAND /OBJECT=$(MMS$TARGET) $(CLDFLAGS) $(MMS$SOURCE)
$(BLISS) /LIBRARY $(BFLAGS) /NOOBJ $(MMS$SOURCE)

.OBJ.OLE
@)
@ IF F$SEARCH(F$PARSE( 11 $(MMS$TARGET) 11 ) .NES. F$SEARCH( 11 $(MMS$TARGET) 11 ) THEN COPY/LOG $(MMS$TARGET) $(MMS$TARGET)
@ IF F$SEARCH("$ (MMS$TARGET) 11 ) .EQS. 1111 THEN $(LIBR)/CREATE/LOG $(MMS$TARGET)
$(LIER) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
Define groups of OBJs, how modules in the OLB relate to OBJs
OLB ELEMENTS =
NOTEFILE=OBJ$:NOTEFILE.OBJ
CLASS=OBJ$:CLASS.OBJ
ENTRY=OBJ$:ENTRY.OBJ
KEYWORD=OBJ$:KEYWORD.OBJ
NOTE=OBJ$:NOTE.OBJ
PROFILE=OBJ$:PROFILE.OBJ
USER=OBJ$:USER.OBJ
CALLABLE INTERCOM=OBJ$:CALLABLE INTERCOM.OBJ
CALLUSER~OBJ$:CALLUSER.OBJ
PARSEACT=OBJ$:PARSEACT.OBJ
INTERCOMTPU=OBJ$:INTERCOMTPU.OBJ
FILEIO=OBJ$:FILEIO.OBJ
.HANDLER=OBJ$:HANDLER.OBJ
ITEMSIZE=OBJ$:ITEMSIZE.OBJ
ITEMLIST=OBJ$:ITEMLIST.OBJ
IDPARSE=OBJ$:IDPARSE.OBJ
INTERCOMMSG=OBJ$:INTERCOMMSG.OBJ
INTERCOMUTIL=OBJ$:INTERCOMUTIL.OBJ
INTERCOM$COMMAND TABLE=OBJ$:COMMANDS.OBJ
INTERCOM$MAIN=OBJ$:INTERCOM$MAIN.OBJ
INTERCOM$SERVER=OBJ$:INTERCOM$SERVER.OBJ
TFRVEC=OBJ$:TFRVEC.OBJ

(continued on next page)

Advanced Description File Techniques 3-21

Example 3-4 (Cont.):

Description File Using Object Libraries

Define the main targets.

These are put in the kit.

MAIN TARGETS =
OBJ$:INTERCOM$SHARE.EXE, OBJ$:INTERCOM$MAIN.EXE, OBJ$:INTERCOM$SERVER.EXE, OBJ$:INTERCOM$SECTION.GBL, OBJ$:INTERCOM$HELP.HLB, SRC$:INTERCOM INTERFACE.TPU, SRC$:INTERCOM$STARTUP.COM, SRC$:INTERCOMDCL.CLD

Define dependency rules.
Specify the main target(s) -- everything.
This is the first dependency rule in this file;
by calling this target "*", we can say "MMS *" at DCL level.

$ (MAIN_TARGETS)
CONTINUE
Define the kit (this is not built by default)
Use "MMS OBJ$:INTERCOM_KIT" to build the installation kit.

OBJ$:INTERCOM_KIT
CONTINUE
OBJ$:INTERCOMOOO.A

OBJ$:INTERCOMOOO.A
$(MAIN_TARGETS), SRC$:KITINSTAL.COM, SRC$:SPKITBLD.COM

,9
- DELETE NNP$: [INTERCOM.TEMP]*.*.*
COPY $(MAIN TARGETS),SRC$:KITINSTAL.COM NNP$: [INTERCOM.TEMP]
@SRC$:SPKITBLD.COM $(TNAME) OBJ$: NNP$: [INTERCOM.TEMP]*.*
- DELETE NNP$: [INTERCOM.TEMP]*.*.*
Build the documents (not built by default)
SPECS

OBJ$:INTERCOMPLAN.MEM, OBJ$:INTERCOMSPEC.MEM
CONTINUE

!To say "MMS SPECS" at DCL

OBJ$:INTERCOMPLAN.MEM
: SRC$:INTERCOMPLAN.RNO
COPY NL: SYS$SCRATCH:INTERCOMPLAN.RNT
!Create dummy file
RUNOFF /INTERMEDIATE=SYS$SCRATCH:INTERCOMPLAN /NOOUTPUT SRC$:INTERCOMPLAN
RUNOFF /CONTENTS /OUTPUT=SYS$SCRATCH:INTERCOMPLAN SYS$SCRATCH:INTERCOMPLAN
RUNOFF SRC$:INTERCOMPLAN /OUT=OBJ$:INTERCOMPLAN
- DELETE SYS$SCRATCH:INTERCOMPLAN.*;*

(continued on next page)

3-22 Advanced Description File Techniques

Example 3-4 (Cont.):

Description File Using Object Libraries

OBJ$:INTERCOMSPEC.MEM
: SRC$:INTERCOMSPEC.RNO
COPY NL: SYS$SCRATCH:INTERCOMSPEC.RNT
!Create dummy file
RUNOFF /INTERMEDIATE=SYS$SCRATCH:INTERCOMSPEC /NOOUTPUT SRC$:INTERCOMSPEC
RUNOFF /CONTENTS /OUTPUT=SYS$SCRATCH:INTERCOMSPEC SYS$SCRATCH:INTERCOMSPEC
RUNOFF SRC$:INTERCOMSPEC /OUT=OBJ$:INTERCOMSPEC
- DELETE SYS$SCRATCH:INTERCOMSPEC.*;*
Build the executables and libraries
LINK SHR = $(LINK) $(LINKFLAGS) /SHAR=$(MMS$TARGET) $(MMS$SOURCE)/OPT /NODEBU
LINK=EXE =$(LINK) $(LINKFLAGS) /EXEC=$(MMS$TARGET) $(MMS$SOURCE)/OPT

OBJ$:INTERCOM$SHARE.EXE
OBJ$:INTERCOM$MAIN.EXE
OBJ$:INTERCOM$SERVER.EXE

$(LINK SHR)
$(LINK-EXE)
$(LINK=EXE)

SRC$:INTERCOM$SHARE.OPT OBJ$:INTERCOM.OLB
SRC$:INTERCOM$MAIN.OPT
OBJ$:INTERCOM.OLB
SRC$:INTERCOM$SERVER.OPT OBJ$:INTERCOM.OLB

OBJ$:INTERCOM$SECTION.TPU$SECTION
: SRC$:INTERCOM INTERFACE.TPU
DEFINE /NOLOG /USER INTERCOM$SECTION OBJ$:INTERCOM$SECTION
- EDIT /TPU /SECTION=EVESECINI /NOJOURNAL /NODISPLAY /COMMAND=$(MMS$SOURCE)
OBJ$:INTERCOM$HELP.HLB
: SRC$:INTERCOMHELP.HLP @)
@ IF F$SEARCH (F$PARSE (II$ (MMS$TARGET) II)) . NES. F$SEARCH ( "$ (MMS$TARGET) II) THEN COPY/LOG $(MMS$TARGET) $(MMS$TARGET)
@IF F$SEARCH( 11 $(MMS$TARGET) 11 ) .EQS. '"' THEN $(LIBR)/CREATE/LOG/HELP $(MMS$TARGET)
$(LIBR) $(LIBRFLAGS) /HELP $(MMS$TARGET) $(MMS$SOURCE)
Anything depending on INTERCOM.OLE is presumed to depend on all its modules.
OBJ$:INTERCOM.OLB
CONTINUE

: OBJ$:INTERCOM.OLB($(0LB_ELEMENTS))

! Any BLISS modules that REQUIRE 'INTERCOMREQ' also depend on INTERCOMLIB.L32,
! since it is referenced by INTERCOMREQ.REQ.
We combine these two in a macro.
COM_REQ

= SRC$:INTERCOMREQ.REQ OBJ$:INTERCOMLIB.L32

(continued on next page)

Advanced Description File Techniques 3-23

Example 3-4 (Cont.):
!

Description File Using Object Libraries

. B32 sources

OBJ$:NOTEFILE.OBJ
OBJ$:CLASS.OBJ
OBJ$:ENTRY.OBJ
OBJ$:NOTE.OBJ
OBJ$:KEYWORD.OBJ
OBJ$:PROFILE.OBJ
OBJ$:USER.OBJ
OBJ$:FILEIO.OBJ
OBJ$:HANDLER.OBJ
OBJ$:ITEMLIST.OBJ
OBJ$:ITEMSIZE.OBJ
OBJ$:INTERCOMUTIL.OBJ
OBJ$:IDPARSE.OBJ
OBJ$:CALLUSER.OBJ
OBJ$:PARSEACT.OBJ
OBJ$:INTERCOMTPU.OBJ
OBJ$:INTERCOM$MAIN.OBJ
OBJ$:INTERCOM$SERVER.OBJ
OBJ$:CALLABLE_INTERCOM.OBJ

SRC$:NOTEFILE.B32
SRC$:CLASS.B32
SRC$:ENTRY.B32
SRC$:NOTE.B32
SRC$:KEYWORD.B32
SRC$:PROFILE.B32
SRC$:USER.B32
SRC$:FILEIO.B32
SRC$:HANDLER.B32
SRC$:ITEMLIST.B32
SRC$:ITEMSIZE.B32
SRC$:INTERCOMUTIL.B32
SRC$:IDPARSE.B32
SRC$:CALLUSER.B32
SRC$:PARSEACT.B32
SRC$:INTERCOMTPU.B32
SRC$:INTERCOM$MAIN.B32
SRC$:INTERCOM$SERVER.B32
SRC$:CALLABLE_INTERCOM.B32

$(COM REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM-REQ)
$(COM=-REQ)

OBJ$:CXF.L32
OBJ$:CXF.L32
OBJ$:CXF.L32
OBJ$:CXF.L32
OBJ$:CXF.L32
OBJ$:CXF.L32
OBJ$:CXF.L32

OBJ$:USERDEF.L32
OBJ$:USERDEF.L32
OBJ$:USERDEF.L32

OBJ$:USERDEF.L32

! .MAR sources

OBJ$:TFRVEC.OBJ
!

SRC$:TFRVEC.MAR

.REQ sources

OBJ$:CXF.L32
OBJ$:USERDEF.L32

SRC$:CXF.REQ
SRC$:USERDEF.REQ

OBJ$:INTERCOMLIB.L32
OBJ$:INTERCOMLIB.L32

! Several require files are combined to form a single BLISS library

OBJ$:INTERCOMLIB.L32

: SRC$:INTERCOMTRUC.REQ SRC$:INTERCOMMAC.REQ SRC$:RTN.REQ OBJ$:INTERCOMMSG.R32 OBJ$:NOTEITEMS.R32
$(BLISS) /LIBRARY $(BFLAGS) /NOOBJ /NOLIST /LIBR=$(MMS$TARGET)SRC$:INTERCOMTRUC.REQ+SRC$:INTERCOMMAC.REQ+SRC$:RTN.REQ+OBJ$:INTERCOMMSG.R32+0BJ$:NOTEITEMS.R32

. MSG source

OBJ$:INTERCOMMSG.OBJ
!

SRC$:INTERCOMMSG.MSG

. CLO sources

OBJ$:COMMANDS.OBJ

3-24

SRC$:COMMANDS.CLD

Advanced Description File Techniques

0 The following logical names are used in this MMS file:
SRC$

Directory containing all sources that can be modified

OBJ$

Directory containing all machine-produced files

LIS$

Directory containing listing files

A simple command procedure is used to define these logical names.
These can refer to the group-wide source directory or can be defined as
a search list for a local copy of a module instead of the group-wide or
shared module. The logical names were defined in either of the following
formats:
$ DEFINE SRC$ NNP$: [INTERCOM.SRC]
$DEFINE SRC$ NNP$: [HILT.INTERCOM.SRC], NNP$: [INTERCOM.SRC]

No CMS elements are explicitly mentioned in the MMS description
file. Instead, NNP$:[1NTERCOM.SRC] is specified as a CMS reference
directory (see HELP CMS MODIFY LIBRARY /REFERENCE_COPY).
Any module replaced in the CMS library causes a new version of the file
to be put in this directory.
All file references include the file directory to allow the MMS file to be
used correctly from any default directory. Similarly, dependencies are
explicitly described.
fj Only the necessary suffixes were included in the suffixes list. This
together with explicit specification of the dependencies should help MMS
improve performance.
8 The rules for building an .OLB from .OBJ files (or an .HLB from .HLP
files) takes search-lists into account. Only the first directory in the
search-list is used to store the new .OBJs.
The default actions were redefined to allow you to use the entire source
and target specifications instead of just the file name. For example,
/OBJ=OBJ$:CLASS.OBJ was used instead of just /OBJ=CLASS.
The first action line checks whether local .OLB is different from the
first .OLB found by the search list. If so, the .OLB is copied to the local
directory. The second line tests whether the .OLB really exists, and the
third inserts the .OBJ into the .OLB. The first two lines are prefixed by
@,so they are not echoed in the log files.

Advanced Description File Techniques

3-25

0 The SPKITBLD command procedure builds a VMS installation kit.

3.11.2

Creating an empty, temporary subdirectory as a staging area is necessary because SPKITBLD uses BACKUP to create the save-set. BACKUP
would copy all versions instead of only the highest versions of the files.
Options files are used to build all the executable images. The LINK_
EXE and LINK_SHR macros are used to specify the actions and the
qualifiers to produce the .EXE file. LINK_SHR overrides any /DEBUG
qualifier that might be specified in LINKFLAGS.

Producing Multiple Outputs with MMS
Using MMS to describe and build systems that have actions with more
than one output becomes complicated because MMS cannot express multiple
output dependencies. Most actions involved in building a system have a
single input and a single output. For example:
ABC.OBJ DEPENDS ON ABC.FOR
FORTRANfNOLIST/OBJECT=ABC ABC.FOR

This example contains the action line that uses the FORTRAN compiler to
produce an object file from a FORTRAN source file.
MMS can also describe cases in which multiple inputs are present. For
example:
ABC.OBJ DEPENDS ON ABC.FOR DEF.TXT
FORTRANfNOLIST/OBJECT=ABC ABC.FOR

This example contains a source file, ABC.FOR, which contains an include
file, DEF.TXT. Both files are needed to produce the object file, ABC.OBJ.
However, MMS syntax cannot express the case in which multiple outputs
are needed. For example, if you want to produce a listing of the compilation
in the first example, you could use the following dependency and action
lines:
ABC.LIS ABC.OBJ DEPENDS ON ABC.FOR
FORTRAN/LIST=ABCfOBJECT=ABC ABC.FOR

This example does produce the correct results, in that valid listing and
object files will be produced, but it does not produce the results correctly.
The previous example is really a shorthand notation for the following:
ABC.LIS DEPENDS ON ABC.FOR
FORTRAN/LIST=ABC/OBJECT=ABC ABC.FOR
ABC.OBJ DEPENDS ON ABC.FOR
FORTRAN/LIST=ABC/OBJECT=ABC ABC.FOR

3-26 Advanced Description File Techniques

You ~an assume that both the listing and object target appear as sources
elsewhere in the description file. When you invoke MMS, both targets are
built but the action line is triggered twice. This example produces the listing
and object files redundantly and, therefore, violates the principle of minimal
action of MMS.
3.11.2.1

Independent Outputs

In the previous example, you may consider the object and the listing files as
independent. The compiler produces them independently and the revision
time of the files is different. When the outputs are independent, it seems
safe to produce them independently. You might describe their relationship in
the following description file:
ABC.LIS DEPENDS ON ABC.FOR
FORTRAN/LIST=ABC/NOOBJECT=ABC ABC.FOR
ABC.OBJ DEPENDS ON ABC.FOR
FORTRAN/NOLIST/OBJECT=ABC ABC.FOR

This example solves the problem of producing two listings and does produce
correct results because no actions on listing and object files are sensitive
to whether the files were created by the same operation. However, if a
configuration change occurs (for example, the compiler is updated), and the
object file ABC.OBJ is missing, then invoking MMS with this description
file results in a new object file but no new listing file. This demonstrates
that the files are not independent. You would normally expect that listing
and object files are produced by the same operation. The files are consistent
as long as they convey the same information (for example, compiler version
indentification).
3.11.2.2

Dependent Outputs

The dependence of outputs is demonstrated clearly by the environment files
and object files produced from a Pascal source file. Consider the following
two Pascal source files, A.PAS and B.PAS:
{A.PAS}
[ INHERIT('b')
BEGIN
bproc
END.

] PROGRAM a;

{B.PAS}
MODULE b
PROCEDURE bproc;
BEGIN
END;
END.

Advanced Description File Techniques

3-27

When compiled and linked, these modules produce the executable image
AB.EXE. Consider the dependencies in the following description file:
AB.EXE DEPENDS ON A.OBJ B.OBJ
LINK/EXECUTABLE=AB.EXE A.OBJ, B.OBJ
A.OBJ DEPENDS ON A.PAS B.PEN
PASCALfOBJECT=A A.PAS
B.OBJ DEPENDS ON B.PAS
PASCALfENVIRONMENT=B/OBJECT=B B.PAS

This description file should work correctly but it is flawed. The file, B.PEN,
never appears as a target. It is created when B.PAS is compiled and is then
used as a source for creating A.OBJ. The description file would be more
accurate if the B.OBJ dependency rule were changed as follows:
B.OBJ B.PEN DEPENDS ON B.PAS
PASCAL/ENVIRONMENT=B/OBJECT=B B.PAS

This example does produce a redundant compilation, but at least the description file is complete and consistent. However, under certain circumstances,
the system does not link correctly because the linker checks that all references to an environment file are consistent. The linker does the checking
with an "entity identification check," which is inserted into object files that
refer to an environment file. Because you cannot predict the order of compilation in all circumstances, MMS can produce object files referring to
different environment files (with different identifications). The linker then
sends the warning message ENTIDMTCH.
If you attempt to produce the environment file separately, you may build the
system incorrectly. For example, consider the following description file:
B.OBJ DEPENDS ON B.PAS
PASCAL/NOENVIRONMENT=B/OBJECT=B B.PAS
B.PEN DEPENDS ON B.PAS
PASCAL/ENVIRONMENT=B/OBJECT=B B.PAS

In this example, an object file produced with the /NOENVIRONMENT
qualifier does not contain the entity indentification check, and therefore
strong typing across modules is defeated.

3.11.3

Multiple Outputs Work-Around
Because you cannot safely express the idea of multiple outputs in the
source-target part of the dependency rule, you can modify the action line to
produce safe results. It is safest to proceed from the redundant compilation
description file. If you can avoid the extra compilation, then the description

3-28 Advanced Description File Techniques

file is complete and the resulting system is built correctly and with a
minimum of actions.
You can introduce a context variable into the action block to monitor
whether the compilation has or has not been performed. Consider the
following description file:
AB.EXE DEPENDS ON A.OBJ B.OBJ
LINK/EXECUTABLE=AB.EXE A.OBJ, B.OBJ
A.OBJ DEPENDS ON A.PAS B.PEN
PASCALfOBJECT=A A.PAS
B.OBJ B.PEN DEPENDS ON B.PAS
IF F$TYPE(B_COMPILED)
.EQS. 1111 THEN B_COMPILED=O
IF .NOT. B COMPILED THENPASCAL/ENVIRONMENT=B/OBJECT=B B.PAS
IF .NOT. B COMPILED THENB COMPILED=l

In this example, B.OBJ and B.PEN are always produced by the same
operation. However, the case in which B.OBJ is missing still generates an
inconsistency. You can avoid this only by introducing false information into
the A.OBJ dependency rule as follows:
A.OBJ DEPENDS ON A.PAS B.PEN B.OBJ
PASCAL/OBJECT=A A.PAS

In this example, MMS can guarantee that both B.OBJ and B.PEN must
exist, and because of their coproduction they are simultaneously updated.
The net effect of this work-around is to treat B.OBJ and B.PEN as one
entity.

Advanced Description File Techniques

3-29

Chapter 4

Accessing Libraries with MMS

This chapter describes how you can specify sources and targets that are
stored in libraries. The following sections describe how MMS can access or
update information in the following types of libraries:
•
•
•
•
•

4.1

VMS libraries created with the LIBRARY utility
VAX DEC/Code Management System (CMS) libraries
VAX FMS libraries
The VAX Common Data Dictionary (CDD/Plus)
VAX Source Code Analyzer (SCA) libraries

Creating and Accessing Files in VMS Libraries
You can use MMS to access files that are contained in VMS libraries and to
create library files using certain built-in rules. The built-in rules that MMS
uses to create library files are listed in Section C. 7 in Appendix C. These
rules tell MMS to create the specified library if one does not already exist;
they then cause MMS to replace the source module in the target library.
NOTE

You cannot use MMS to access modules in an RSX library because
only a module's revision date is recorded, not its revision time.

Accessing Libraries with MMS 4-1

4.1.1

Formatting Library Module Specifications
To specify that a source or target in a dependency rule is a module in a VMS
library, use the following format. Avoid adding any spaces or tabs as they
may cause problems in processing.
library (module [=filespec), . . .

)

The library is a VMS file specification that denotes a library. The default file
type is .OLB if you are referring to a module within the library. If you are
referring to the entire library, there is no default file type. The module is the
name of the module in the library. The filespec is the VMS file specification
that corresponds to the module in the library. The default file type depends
on the file type of the library.
The format shown in this section describes how to refer to modules within
a library. You can also use MMS to process the library file itself simply by
providing the library file specification (for example, CRTLIB.OLB).
There is a restriction in using library module specifications as targets in a
double colon dependency rule. See Section 3.1 for more information.

4.1.2

Using Logical Names in a Library Module Specification
You can use a logical name for the name of the module if you supply the
action lines that update the target. MMS cannot apply its built-in rules to a
logical name because it relies on file types to determine which built-in rule
is appropriate.
For example, CRTLIB(C$STRLEN=STRLEN.OBJ) designates that the
module C$STRLEN is in library CRTLIB. OLB; C$STRLEN is found in the
file named STRLEN. OBJ.

4.1.3

Specifying Multiple Modules
You can specify multiple modules in the same library in two ways:
•

You can enclose the module names in one set of parentheses and separate them with commas. For example, to refer to three modules in the library CRTLIB.OLB, you can specify CRTLIB(C$STRLEN=STRLEN.OBJ,
C$STRPAD=STRPAD. OBJ, C$STRIND=STRIND. OBJ).

4-2 Accessing Libraries with MMS

•

4.1.4

You can use the VMS* and% wildcard characters. For example, the
specification CRTLIB(C$*) directs MMS to look for all modules in the
library CRTLIB.OLB whose names begin with the characters C$. In
the same way, the specification CRTLIB(C$STR%) directs MMS to look
for all modules in CRTLIB.OLB whose names begin with the characters
C$STR followed by only one character.

Accessing Library Modules with Non-VMS File Specifications
You can use a complete library specification when you need to access library
modules whose names do not correspond to VMS file specifications (for
example, C$STRLEN=STRLEN.OBJ). However, MMS can interpret shorter
specifications as follows:
•

If the module's name in the library is the same as its file name, you can
provide just the module name in parentheses after the library name. For
example, if the module in the previous example were named STRLEN,
you could refer to the module in the library as CRTLIB(STRLEN).

•

If the module's file type is associated by default with the type of the library, you can omit the file type. In the specification CRTLIB(STRLEN),
MMS assumes that the file name is STRLEN.OBJ, because .OLB libraries are assumed to contain .OBJ modules. If the module's file type
is something other than the default for that kind of library, you must
supply the file type. For example, if the module were STRLEN.C, you
would have to specify CRTLIB(STRLEN.C). MMS would then expand
this specification to the following two dependencies:
CRTLIB(STRLEN=STRLEN.OBJ)

: STRLEN.OBJ

STRLEN.OBJ : STRLEN.C

4.1.5

Using Special Macros with Library Specifications
When used with library specifications, certain MMS special macros have
slightly different meanings:
•

If a library is the source in a dependency rule, MMS$SOURCE expands
to the complete specification of the module in the library. For example,
in the specification CRTLIB(C$STRLEN=STRLEN), MMS$SOURCE
expands to CRTLIB.OLB(C$STRLEN=STRLEN.OBJ).

•

If a library is the target in a dependency rule, MMS$TARGET expands to the name of the library. For example, in the specification
CRTLIB(C$STRLEN), MMS$TARGET becomes CRTLIB.

Accessing Libraries with MMS

4-3

•

If a library is the target in a dependency rule, MMS$TARGET_NAME

expands to the module name (without its file type). For example, if
the library module is STRLEN, MMS$TARGET_NAME expands to
STRLEN.
In addition to these MMS special macros, there is another special macro,
MMS$LIB_ELEMENT, which you can use only in library specifications.
MMS$LIB_ELEMENT expands to the string between parentheses, that is,
to the module name and its corresponding file specification. For example,
in the specification CRTLIB(STRLEN), MMS$LIB_ELEMENT becomes
STRLEN=STRLEN. OBJ. The expansion of MMS$LIB_ELEMENT does not
depend on whether the library is the source or the target in a dependency
rule. If the library is specified as both the source and the target, then the
target is expanded.

4.1.6

Using Libraries as a Source
The use of libraries as a source is illustrated in the following example.
Suppose your description file contains the following dependency rules:
TOOLTITLE.EXE : SYS$LIBRARY:CRTLIB.OLB, USER$: [WATKINS]FLIB.OLB
LINK TOOLTITLE.OBJ, SYS$LIBRARY:VAXCRTL/LIB, USER$: [WATKINS]FLIB/LIB
TOOLTITLE.OBJ : SMGTEXLIB.TLB(SMGDEF=SMGDEF.H)
CC TOOLTITLE + SMGTEXLIB/LIB

TOOLTITLE.C is a C program that includes the file SMGDEF.H, which
is stored in the text library SMGTEXLIB.TLB under the name SMGDEF.
The action line in the second dependency rule invokes the C compiler to
compile TOOLTITLE.C and the text library. You must state this action line
explicitly. In this case, specifying only the target and source is not sufficient.
The first dependency rule invokes the VAX Linker to link TOOLTITLE.OBJ
with one system library and one user library.

4.2 Using MMS with CMS
If the VAX DEC/Code Management System (CMS) is installed on your

system, you can use MMS to access elements in CMS libraries. CMS
elements are denoted by the tilde ( - ). You should be familiar with CMS
before you read this section.
MMS provides default macros and special macros tailored for use with CMS.
Appendix C lists the default macros and the special macros.

4-4

Accessing Libraries with MMS

MMS can build your system software from source code files stored in CMS
libraries. MMS fetches the source code file from its library, compiles the
code into object files, then links the object files into executable images. l\'.IMS
treats the CMS library as the source for your source code files.
MMS treats the source code in your directory and an element in a CMS
library, just as it does any other source or target pair. If the source code
file in the default directory is missing, MMS fetches that element from its
CMS library. If the source code file in the default directory is older than the
library element, MMS fetches the element. Figure 4-1 illustrates a software
system using CMS libraries.
Figure 4-1:

A Software System Using CMS Libraries

MAIN.EXE

MAIN.OBJ

SUB1.0BJ

MAIN.PAS

SUB1.PAS

MAIN.PAS-

SUB1.PASZK-5887-GE

0 The executable file depends on the object files.
8 The object files depend on the sources in the your directory.
0 The sources in your directory depend on elements in CMS libraries.

Accessing Libraries with MMS 4-5

MMS supports only one CMS qualifier: /GENERATION. The default macro
CMSFLAGS expands to the /GENERATION qualifier. You can also specify
/GENERATION and a generation number after the tilde (-)in the element
name, as shown in this example:
FROG.OBJ :

[OTHER.CMS]PROG.C-/GEN=4Al

The tilde format for an explicit reference to a CMS element is useful when
you are certain that the most up-to-date source is stored in the CMS library.
A more convenient use of MMS with CMS is to let MMS determine where
the newest source is located and to fetch the CMS element automatically,
if necessary. To take advantage of this feature, you must use the /CMS
qualifier on the MMS command line and you should not use the tilde format
for specifying the source.

4.2.1

Using CMS Commands in a Description File
You can use any CMS command in an MMS description file.
As MMS examines target and source lines in your main process, it uses
the CMS$LIB logical name to establish the CMS directory from which
sources will be fetched if the target must be updated. If you use the CMS
SET LIBRARY command in an action line, that command is executed in
the subprocess where MMS normally executes action lines. Such an action
establishes a new library as the current default for any subsequent action
lines that execute CMS commands; however, the value of CMS$LIB is not
changed in the main process because the CMS SET LIBRARY command
is executed in the subprocess. MMS still looks for sources in the library
represented by CMS$LIB.
The MMS qualifier /REVISE_DATE has no effect when MMS is accessing
elements in CMS libraries.

4.2.2

Automatic Access of CMS Elements from Dependency Rules
The /CMS qualifier directs MMS to look for sources in the current default
CMS library, as well as in the directories specified in the description file.
If the CMS element has been replaced in the library since the file in the
specified directory was last revised, MMS directs CMS to fetch the source
from the library so that the target can be rebuilt. MMS has built-in rules
that instruct CMS how to find the correct source (see Section C.9 for the
built-in CMS rules). MMS uses the sources fetched from CMS to update the
target by executing the action lines in the description file. The CMSFLAGS

4-6

Accessing Libraries with MMS

default macro determines which generation of an element is fetched as the
source or from which class the source element is fetched.
If the file in the specified directory is newer than the CMS element, MMS
uses that file. Therefore, you could edit a source in your directory and build
a new system with the edited source, rather than with the corresponding
CMS element.

For example, consider a description file that contains the following
dependencies:
A.EXE

A.OBJ

A.PAS

If you invoke MMS with the /CMS qualifier, MMS processes the description
file by looking in the current default CMS library for A.PAS. If it locates
that source, it compares the revision time with the revision time of A.PAS in
the current directory (if A.PAS exists there). If the CMS element is newer,
MMS uses it to update A.OBJ.

The CMSFLAGS default macro always fetches the most recent generation
of an element on the main line of descent. You can redefine CMSFLAGS to
indicate a specific element generation or the element generation that belongs
to a particular class. However, if you do so, you must be aware that if newer
generations exist in the library, they will not be fetched; MMS will check the
time of the element designated by the CMSFLAGS macro against the time
of the file in your directory. If the file is newer, MMS will use it even though
more recent generations of the element may exist in the library.
The /NOCMS qualifier directs MMS not to look automatically for sources
in the current default CMS library; /NOCMS is the default. The /CMS and
/NOCMS qualifiers are described in full in the Command Dictionary.

4.2.3

Explicit References to CMS Elements in Dependency Rules
The /CMS qualifier causes MMS to compare the times of a CMS element
and a file in the specified directory, if both exist. You can also direct MMS to
check only the CMS element by putting a tilde immediately after the source
file name in a dependency rule. For example, the tilde in the following
target or source line directs MMS to look for the source PROG.C in the
current default CMS library:
PROG.OBJ : PROG.C-

If you use the tilde format to indicate CMS elements, you can specify only
one element in a given dependency rule. You cannot specify a list of CMS
elements if their file specifications are followed by tildes.
Accessing Libraries with MMS 4-7

If the element is in a CMS library other than the current default library, you
must type the library specification before the element name:
FROG.OBJ :

[OTHER.CMS]PROG.C-

You may not be able to access elements in a CMS library that reside on a
DECnet node other than your own.

4.2.4

Using CMS Elements to Build the System
The following example demonstrates how to build your software system with
CMS elements. Consider the description file CMS_MMS.MMS, shown in
Example 4-1.
Example 4-1:
$

Description File Using CMS Libraries

TYPE CMS MMS. MMS
! Executable target
!

0MAIN.EXE : MAIN.OBJ, SUBl.OBJ
LINK $(MMS$SOURCE_LIST)
Object files and their sources
f9MAIN.OBJ
SUBl.OBJ

MAIN.PAS
SUBl.PAS

! Where the sources are stored

@)MAIN.PAS
SUBl.PAS

DISKl: [SYSTEM2 LIB]MAIN.PASDISKl: [SYSTEM2=LIB]SUB1.PAS-)

0 The executable target is stated.
8 The objects or targets are stated.
8 Each source code file has a target or source line. The element in the
CMS library is the source.

4-8

Accessing Libraries with MMS

You can build your system with the description file CMS_MMS.MMS, as
shown in Example 4-2.
Example 4-2:

Building a System from CMS Library Elements

DIR/DATE=MODIFIED
Directory DISKl: [TEST]
CMS_MMS.MMS;l

30-JUL-1987 13:10

Total of 1 file.

f)$

MMS/DESCRIPTION=CMS_MMS

mms$cmslib :== 'f$logical("CMS$LIB")
IF mms$cmslib .nes. "DISKl: [SYSTEM2_LIB]" THEN
CMS SET LIBRARY DISKl: [SYSTEM2 LIB]
@)cMS FETCH MAIN .PAS /GEN=l+ '"' %CMS-S-FETCHED, generation 1 of element MAIN.PAS fetched
IF mms$cmslib .EQS. "" THEN CMS SET LIBRARY 1234
IF mms$cmslib .NES. "" .AND. mms$cmslib .NES. "DISKl: [SYSTEM2_LIBJ"
THEN CMS SET LIBRARY 'mms$cmslib'
~ASCAL /NOLIST/OBJECT=MAIN MAIN.PAS
mms$cmslib :== 'f$logical("CMS$LIB")
IF mms$cmslib .nes. "DISKl: [SYSTEM2_LIB]" THEN
CMS SET LIBRARY DISKl: [SYSTEM2 LIB]
0cMs FETCH SUBl. PAS /GEN=l+ 1111 <
%CMS-S-FETCHED, generation 1 of element SUBl.PAS fetched
IF mms$cmslib .EQS. '"' THEN CMS SET LIBRARY 1234
IF mms$cmslib .NES. "".AND. mms$cmslib .NES. "DISK1:[SYSTEM2_LIB]"
THEN CMS SET LIBRARY 'mms$cmslib'
<DPASCAL /NOLIST/OBJECT=SUBl SUBl.PAS
fjLINK MAIN.OBJ, SUBl.OBJ
@)$

DIR/DATE=MODIFIED

Directory DISKl: [TEST]
MAIN.EXE;l
MAIN.OBJ;l
MAIN.PAS;l
SUBl.OBJ;l
SUBl.PAS;l
CMS_MMS.MMS;l

30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987

13:19
13:19
13:10
13:19
13:10
13:10

Total of 6 files.

0 The default directory contains only the software description.
f) MMS is invoked using the CMS_MMS.MMS description file.
6) MMS fetches the missing source code file MAIN.PAS from CMS. Note
that MMS fetches the latest generation of each element by using the 1+
notation.
8 MMS compiles the source code file MAIN.PAS.
Accessing Libraries with MMS 4-9

0 MMS fetches missing source code file SUBl.PAS from CMS.

CD MMS compiles the source code file SUBl.PAS.
8 MMS links the object files using the action line.
0 The default directory has a complete software system.
MMS fetches sources from CMS if the source code file in your directory is
missing or older. In this example, only the description file is in the default
directory before you invoke MMS. There is no source code to compile in your
default directory, but because the description file states the source of each
source code file, MMS fetches the source code files from CMS.
Because of the MMS built-in rule for accessing CMS libraries, MMS generates more output when it fetches source files from CMS than when it
builds a system with files from your directory. The extra actions reflected in
the output are concerned with checking that the CMS library is set to the
correct place before and after the fetch in case the source code is stored in
more than one library.
Appendix C contains a full list of extensions that MMS must know to fetch
files from a CMS library and to access other libraries.

4.2.5

Using CMS Libraries to Rebuild the System
Rebuilding a system from a CMS library is similar to all other system
rebuilding in that MMS first checks that all parts of the system are present
and up-to-date and then re-creates executable files and object files that are
old or missing. MMS also uses the CMS library as the source to update old
and missing source code.
Example 4-3 is an example of what can happen during the software
development cycle. You reserve an element, fix a bug in the element, and
test the fix before replacing the code element in the library. No one else has
updated the library element since the last system build.

4-10

Accessing Libraries with MMS

Example 4-3:

Ct$

Rebuilding Using CMS Libraries

DIR/DATE=MODIFIED

Directory DISKl: [TEST]
MAIN.EXE;l
MAIN.OBJ;l
MAIN.PAS;l
SUBl.OBJ;l
SUBl.PAS;l
CMS_MMS.MMS;l

30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987

13:15
13:13
13:10
13:13
13:10
13:10

Total of 6 files.

$ CMS SET LIBRARY DISKl: [SYSTEM2 LIB]
%CMS-I-LIBIS, CMS library is DISKl: [SYSTEM2_LIB]

@$ CMS RESERVE SUBl.PAS "Fixing a bug in stack handler"
%CMS-S-RESERVED, generation 1 of element SUBl.PAS reserved

@)$
$

EDIT SUBl.PAS
PURGE
DIR/DATE=MODIFIED

Directory DISKl: [TEST]
MAIN.EXE;l
MAIN.OBJ;l
MAIN.PAS;l
SUBl.OBJ;l
SUBl. PAS; 3
CMS_MMS.MMS;l

30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987

13:15
13:13
13:10
13:13
13:17
13:10

Total of 6 files.

MMS/DESCRIPTION=CMS_MMS

0PASCAL /NOLIST/OBJECT=SUBl SUBl.PAS
LINK MAIN.OBJ, SUBl.OBJ

Ct You have a complete, up-to-date system from a previous system build.
@ You reserve a CMS element.

0
0
0
0

You modify SUBl.PAS to fix a bug.
One source code file SUBl.PAS is newer than its object SUBl.OBJ.
You invoke MMS to rebuild the system.
MMS rebuilds the system from files in your default directory fetching nothing from the library. MMS compiles SUBl.PAS and links
MAIN.OBJ and SUBl.OBJ.

Accessing Libraries with MMS

4-11

When you invoke MMS in Example 4-3, MMS does not fetch any files from
the CMS library. Nothing in your directory is missing and nothing is older
than its library element.
In the next example, you have a complete, up-to-date copy of the entire
system in your directory. However, another person has updated one of the
code files in the CMS library after you built your copy of the system. When
you invoke MMS to see if your system is up-to-date, MMS detects the newer
file in the CMS library and fetches the updated file from the library. It
rebuilds the system using the newly fetched file. This demonstrates how
MMS uses the CMS library as the source of your targets. Just as an object
file is rebuilt if the code has changed, your file is updated if the library has
changed. For example:

DIR/DATE=MODIFIED

Directory DISKl: [TEST]
MAIN.EXE;2
MAIN .OBJ; 1
MAIN.PAS;l
SUB1.0BJ;2
SUBl. PAS; 3
CMS_MMS.MMS;l

30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987
30-JUL-1987

13:15
13:13
13:10
13:13
13:10
13:10

Total of 6 files.

8$ ! (Another user reserves, changes and replaces MAIN.PAS)
@)$

MMS/DESCRIPTION=CMS_MMS

mrns$cmslib :== 'f$logical("CMS$LIB")
IF mrns$cmslib .nes. "DISKl: [SYSTEM2 LIB]" THEN
CMS SET LIBRARY DISKl: [SYSTEM2 LIB]
8cMS FETCH MAIN.PAS /GEN=l+ ""
%CMS-I-FILEXISTS, file already exists, DISKl: [TEST]MAIN.PAS;2 created
%CMS-S-FETCHED, generation 2 of element MAIN.PAS fetched
IF mrns$cmslib .EQS. "" THEN CMS SET LIBRARY 1234
IF mrns$cmslib .NES. "" .AND. mrns$cmslib .NES. "DISKl: [SYSTEM2 LIB]"
THEN CMS SET LIBRARY 'mrns$cmslib'
@tFASCAL /NOLIST/OBJECT=MAIN MAIN.PAS
LINK MAIN.OBJ, SUBl.OBJ

0 Your directory has a complete, up-to-date system.
8 Another person updates a file in the project's CMS library.
0 You invoke MMS to update your system.
8 MMS fetches the newer source code in the library.

0 MMS compiles and links the newer source code.

4-12

Accessing Libraries with MMS

When creating the "official" release of a software product, you want to be
sure that the release is built from code in the library, not from test code that
you may have in your default directory. It is better to create a [RELEASE]
directory that is used only for building the system from its CMS libraries.
No other operations are performed in that directory.

4.2.6

Building a System from a Specified CMS Class
You can build your system from a specified CMS class. Building with a class
specifier in CMS is identical to building from current generations in CMS.
In building a system from a specified CMS class, MMS still uses the CMS
elements as the sources but it uses the designated class of generations, not
necessarily the current generations. MMS allows you to find and modify old
source code and re-create previous versions of your system by building from
a specific CMS class.
MMS looks for the description file on the main line of descent, unless you override the default macro CMSFLAGS. If you specify
/MACRO="CMSFLAGS=/GENERATION =class-name", MMS instead uses
the specified class. If MMS cannot find a description file in either your
default directory or the CMS library, it aborts execution.
You can use a user-defined macro to control the class that MMS fetches. The
user-defined macro is used as a qualifier to one of MMS's actions. For example, you define the macro CMSFLAGS, which contains the qualifiers MMS
uses when it fetches an element from a CMS library. A /GENERATION
qualifier on this macro causes MMS to fetch files from a certain class.
Consider the command procedure BUILD_CLASS.COM and the description
file SYSTEM3.MMS in Example 4-4.

Accessing Libraries with MMS

4-13

Example 4-4:

Description File for Building from a CMS Class

8$ TYPE BUILD CLASS. COM
$

Command procedure to build any CMS class of SYSTEM2.

$
$
$

Create the user defined macros we want

8$ INQUIRE CLASS "Enter name of class to build"
0$ CMSFLAGS = "/GENERATION=" + CLASS
$

$
$

! Invoke MMS and direct it to use our macros
!

8$ MMS /DESCRIPTION=SYSTEM3 /OVERRIDE
$

0$ TYPE SYSTEM3.MMS
Executable target
MAIN.EXE : MAIN.OBJ, SUBl.OBJ, SUB2.0BJ
LINK $(LINKFLAGS) $(MMS$SOURCE_LIST)
Object files and their sources
MAIN.OBJ
SUBl.OBJ
SUB2.0BJ

MAIN.PAS
SUBl.PAS
SUB2.PAS

! Where the sources are stored

MAIN.PAS
SUB1.PAS
SUB2.PAS

DISKl: [SYSTEM3_LIB]MAIN.PASDISKl: [SYSTEM3_LIB]SUB1.PASDISKl: [SYSTEM3_LIB]SUB2.PAS-

8 The command procedure invokes MMS.
8 The command procedure prompts you for the name of the CMS class to

build.
The CMSFLAGS macro (which is used by the built-in rule for fetching
your source files) is set and the /GENERATION qualifier is added to the
class name.

8 The procedure invokes MMS with the /OVERRIDE qualifier so that your

4-14

macro is used instead of the default.
The description file lists where the source files are stored in the CMS
library.

Accessing Libraries with MMS

You can insert the MMS description file and its calling command procedure
into the appropriate CMS class. In this way, the description file in a given
class builds that class. As a system changes, you can continue to put a copy
of the description file in each new class you create.

4.2. 7

Building a System from a Previous Class
In this example, you build your system from a previous class in a directory
that is empty except for the command procedure and the description file.
MMS fetches files from CMS only if the library copy is newer than your copy.
The files in the previous class are certain to be older than your code, so
MMS does not fetch them unless you build the previous releases in a clean
directory. For example, consider the system build shown in Example 4-5.
Example 4-5:

Ct$

Building a System from a Previous CMS Class

DIR/DATE=MODIFIED

Directory DISKl: [VERSION13]
BUILD_CLASS.COM;4
SYSTEM3.MMS;3

5-AUG-1987 13:17
5-AUG-1987 13:09

Total of 2 files.

fi$

@BUILD_CLASS

(continued on next page)

Accessing Libraries with MMS

4-15

Example 4-5 (Cont.):

Building a System from a Previous CMS Class

~nter name of class to build:

VERSION 1 3

mms$cmslib :== 'f$logical("CMS$LIB")
IF mms$cmslib .nes. "DISKl: [SYSTEM3_LIB]" THEN
CMS SET LIBRARY DISKl: [SYSTEM3 LIB]
%CMS-I-LIBIS, CMS library is DISKl: [SYSTEM3 LIB]
8cMS FETCH MAIN.PAS /GEN=VERSION_1_3 ""
%CMS-S-FETCHED, generation 2 of element MAIN.PAS fetched
IF mms$cmslib .EQS. "" THEN CMS SET LIBRARY 1234
%CMS-E-NOREF, error referencing 1234
-CMS-E-MUSTBEDIR, 1234 must be a directory specification
%CMS-W-UNDEFLIB, CMS library is now undefined
IF mms$cmslib .NES. "" .AND. mms$cmslib .NES. "DISKl: [SYSTEM3_LIB]" THEN CMS SET LIBRARY 'mms$cmslib'
PASCAL /NOLIST/OBJECT=MAIN MAIN.PAS
mms$cmslib :== 'f$logical("CMS$LIB")
IF mms$cmslib .nes. "DISK1:[SYSTEM3_LIB]" THEN
CMS SET LIBRARY DISKl: [SYSTEM3_LIB]
%CMS-I-LIBIS, CMS library is DISKl: [SYSTEM3 LIB]
8cMs FETCH SUBl.PAS /GEN=VERSION_1_3 1111
%CMS-S-FETCHED, generation 1 of element SUBl.PAS fetched
IF mms$cmslib .EQS. "" THEN CMS SET LIBRARY 1234
%CMS-E-NOREF, error referencing 1234
-CMS-E-MUSTBEDIR, 1234 must be a directory specification
%CMS-W-UNDEFLIB, CMS library is now undefined
IF mms$cmslib .NES. 1111 .AND. mms$cmslib .NES. "DISKl: [SYSTEM3_LIB]"
THEN CMS SET LIBRARY 'mms$cmslib'
PASCAL /NOLIST/OBJECT=SUBl SUBl.PAS
mms$cmslib :== 'f$logical("CMS$LIB")
IF mms$cmslib .nes. "DISKl: [SYSTEM3 LIB]" THEN CMS SET LIBRARY DISKl: [SYSTEM3 LIB]
%CMS-I-LIBIS, CMS library is DISKl: [SYSTEM3_LIB]
8cMS FETCH SUB2.PAS /GEN=VERSION 1 3 ""
%CMS-S-FETCHED, generation 3 of-element SUB2.PAS fetched
IF mms$cmslib .EQS. 1111 THEN CMS SET LIBRARY 1234
%CMS-E-NOREF, error referencing 1234
-CMS-E-MUSTBEDIR, 1234 must be a directory specification
%CMS-W-UNDEFLIB, CMS library is now undefined
IF mms$cmslib .NES. "" .AND. mms$cmslib .NES. "DISKl: [SYSTEM3_LIB]" THEN CMS SET LIBRARY 'mms$cmslib'
CDPASCAL /NOLIST/OBJECT=SUB2 SUB2.PAS
LINK/TRACE/NOMAP/EXEC=MAIN MAIN.OBJ, SUBl.OBJ, SUB2.0BJ

6)$

DIR/DATE=MODIFIED

Directory DISKl: [VERSION13]

(continued on next page)
4-16

Accessing Libraries with MMS

Example 4-5 (Cont.}:
BUILD_CLASS.COM;4
MAIN.EXE;l
MAIN.OBJ;l
MAIN.PAS; 1
SUBl.OBJ;l
SUBl. PAS; 1
SUB2.0BJ;l
SUB2.PAS;l
SYSTEM3.MMS;3

Building a System from a Previous CMS Class
5-AUG-1987 13:17
5-AUG-1987 13:22
5-AUG-1987 13:21
30-JUL-1987 13:22
5-AUG-1987 13:22
30-JUL-1987 13:10
5-AUG-1987 13:22
5-AUG-1987 13:12
5-AUG-1987 13:09

Total of 9 files.

0 Your directory contains the command procedure and the description file.
8 You invoke the command procedure.
0 You enter the class name.
0 MMS fetches all program code from the chosen class using the macro
CMSFLAGS to override the default.
0 The source code is compiled and linked normally.
<D Your directory contains the complete system.
After you have built the previous version of your system, you can fix the bug
you may have found. The following steps ensure a complete and accurate
system:
•
•
•
•

Reserve the CMS element generation with the bug.
Edit the element to fix the bug.
Replace the CMS element as an alternate line of descent.
Replace the generation that was in the CMS class with the fixed version
(CMS INSERT GENERATION /SUPERSEDE).

Using Logical Names for CMS Library Specifications

When writing CMS library specifiers in a description file, you can use logical
names instead of a hard-coded device and directory name. This allows the
exact location of the library to change, and can make the description file
easier to read. The command procedure that invokes MMS can set the
logical name (or perhaps it is set in a group or system logical name table).

Accessing Libraries with MMS

4-17

4.2.8

Using the .INCLUDE Directive to Include CMS Files
You can also use the tilde format with the .INCLUDE directive to include
files that are stored in the current default CMS library. For example:
.INCLUDE RULES-

This line in the description file directs MMS to fetch the file RULES.MMS
from the current CMS library. (The .INCLUDE directive is discussed in
Section 2.7.9.)
When a tilde occurs in your description file, MMS looks for the file in the
current CMS library, even if you specify /NOCMS on the command line.
However, if the CMS element is newer than the target in the dependency,
the element is not fetched from its CMS library unless an action line directs
CMS to fetch the source.

4.2.9

Using a User-Defined Rule to Access a Single CMS Element
The following example shows a user-defined rule for accessing a single-file
CMS element:
.C-.OBJ :
CMS FETCH $(MMS$CMS ELEMENT) $(CMSFLAGS) $(CMSCOMMENT)
$(CC) $(CFLAGS) $(MMS$CMS_ELEMENT)

This dependency rule tells MMS to do the following:
Fetch the .C source file from the current default CMS library, applying
the qualifiers specified by the CMSFLAGS macro and writing to the.
CMS history file the remark specified by the CMSCOMMENT macro.
2. Run the C compiler on the file fetched from the CMS library, applying
the qualifiers specified by the CFLAGS macro.
1.

CMSFLAGS and CMSCOMMENT are default MMS macros. You can
redefine them so that the same qualifiers or the same remarks are used for
all accesses to CMS elements.

4.2.10

Accessing a CMS Element Not in the Default CMS Library
The next example shows how to access a CMS element that is not in the
current default CMS library.

4-18

Accessing Libraries with MMS

TEST.C : [OTHER.CMS]TEST.CCMS SET LIBRARY [OTHER.CMS]
CMS FETCH TEST.C "Auto fetch from MMS"

This dependency rule causes MMS to set the current default CMS library to
[OTHER.CMS], fetch the element TEST.C, and write the specified remark
to the CMS history file. (MMS does not reset the CMS library back to the
default in this example. This action differs from that of the built-in rules for
CMS element access. See Section C.9 in Appendix C.)

4.2.11

Accessing Description Files in CMS Libraries
If a description file does not exist in your default directory, and if you have
defined a CMS library, you can request that MMS retrieve the description
file from the CMS library by using the /CMS qualifier on the MMS command
line. If the description file exists in your directory and is newer than the
element in the CMS library, MMS uses the file in your directory.
If you know that the description file you want to use is stored in a CMS
library, you can explicitly request MMS to use that file. When you use
the /DESCRIPTION qualifier on the MMS command line, you can follow the name of the description file with a tilde character so that MMS
automatically fetches the file from the current CMS library. For example:
$

MMS/DESCRIPTION=ALL-

This command directs MMS to fetch the description file ALL.MMS from the
current CMS library.
If the file you specify with /DESCRIPTION does not exist in the current
CMS library, MMS issues an error message.

4.3 Checking for Replacement of CMS Elements
If more than one programmer is working on a project, you may want to

wait for someone else to replace an element in the project CMS library
before you do a particular task. MMS can automatically check for element
replacements at specified intervals by using the command procedure in the
next example. Besides the command procedure, you also need a description
file that tells MMS which element to look for and how to notify you when
the element has been replaced. Such a description file might be named
THERE.TIM, as in the next example.
·

Accessing Libraries with MMS

4-19

THERE.TIM : NEEDED.FOR! The name of the element
IF " I I F$SEARCH ("THERE. TIM") I " • NES "" THEN MAIL NL: 'F$GETJPI(" ","USERNAME")'/SUBJECT="$(MMS$SOURCE) is back in the CMS library."
SET DEFAULT 1234567890 ! Causes MMS to abort with $STATUS = failure

The command procedure CHECKCMS.COM that loops until the specified
element is available in the CMS library is as follows:
$ CMS SET LIBRARY [LOUISE]
! The CMS library
$ SET DEFAULT [LOUISE.WORK]
! Your working directory
$IF "''F$SEARCH("THERE.TIM")'" .EQS. "" THEN COPY NL: THERE.TIM
$ LOOP:
$ MMS/DESCRIPTION=THERE
$ IF .NOT. $STATUS THEN EXIT
$ WAIT 0:5
! or some interval
$ GOTO LOOP

When submitted to the batch queue, this command procedure runs MMS,
which checks to see whether the element in the CMS library is newer than
THERE.TIM. If it is not (that is, if the element has not been replaced in the
CMS library), $STATUS is 1, and MMS waits the specified interval before
trying again. If the element has been replaced, the first bit in $STATUS
is 0, and MMS mails you the message "NEEDED.FOR is back in the CMS
library."
You can run this procedure in a subprocess (instead of submitting it to the
batch queue) by typing the following command:
$ SPAWN/NOWAIT @CHECKCMS

4.4 Accessing Forms in an FMS Library
If VAX FMS is installed on your system, you can use MMS to access forms

stored in FMS libraries. You should be familiar with FMS before reading
this section.
To specify an FMS form in a dependency rule, use the same syntax as for
files in VMS libraries. This syntax is explained in detail in Section 4.1. The
file type .FLB after the library name informs MMS that the library contains
FMS forms. The default file type for FMS forms is .FRM.
For example, consider the following dependency rule:
A.FLB(B) : B.FRM
$(FMS) $(FMSFLAGS) A.FLB B.FRM

B.FRM is the source that updates the target Bin the FMS library A.FLB.
FMS and FMSFLAGS are default macros that invoke FMS with the
/REPLACE qualifier.
4-20 Accessing Libraries with MMS

MMS uses the insertion time of a form in an FMS library to determine
whether a source is newer than the target. You cannot use the /REVISE_
DATE qualifier with references to FMS forms. (See the Command Dictionary
for a description of /REVISE_DATE.)

4.5 Accessing Definitions in COD/Plus
If the VAX Common Data Dictionary (CDD/Plus) is installed on your system,
you can use MMS to access records and other definitions stored in CDD/Plus,
as long as the definitions have the revision time attribute. You should be
familiar with CDD/Plus before reading this section.

In a dependency rule, you follow the path name of a CDD/Plus definition
with the caret ( A ) to inform MMS that the source is stored in CDD/Plus.
For example:
A.OBJ : A.PAS, CDD$TOP.B.C.D.EA
PASCAL A.PAS

! CDD record referred to in A.PAS

In this example, the target A.OBJ resides in your current directory.
MMS uses the CDD/Plus path specification to find the source and check its
revision time against that of the target, A.OBJ. Then, MMS retrieves the
revision time for the specified CDD definition. The definition must have the
revision time attribute. If the definition is not found in CDD/Plus, MMS
attempts to locate it at the specified path by using the CDD compatibility
interface. In this case, MMS assumes that the definition is in a dictionary
or subdirectory that has not yet been upgraded to CDD/Plus. If MMS cannot
find the definition by using the CDD compatibility interface, it returns an
error.
CDD/Plus maintains a history list that includes the date and time that a
CDD/Plus definition was accessed and an optional remark that you supply
to document the access. To insert a remark in the CDD/Plus history list
when MMS accesses a CDD/Plus definition, use the /AUDIT qualifier after
the caret in the CDD/Plus specification. Follow the IAUDIT qualifier with
a quoted string that contains the remark that is to be inserted in the
CDD/Plus history file. For example:
A.OBJ : A.PAS, CDD$TOP.B.C.D.EA/AUDIT="Accessed by MMS to update A"
PASCAL A

MMS writes the remark that follows the /AUDIT qualifier into the CDD/Plus
history list for the specified definition. You must place the /AUDIT qualifier
after the caret character; separate the qualifier from the remark with an
equal sign or colon. You cannot use /AUDIT on the MMS command line.

Accessing Libraries with MMS

4-21

MMS also provides the default macro CDDFLAGS. This macro is defined to
be the null string, but you can redefine it so that the same remark is written
to the history file for all accesses to CDD/Plus entities. For example, you
could set up your description file as follows:
CDDFLAGS = /AUDIT="Record accessed by MMS"
A.OBJ : A.PAS, CDD$TOP.B.C.D.EA
PASCAL A
Q.OBJ : Q.PAS, CDD$TOP.L.M.N.OA
PASCAL Q
V.OBJ : V.PAS, CDD$TOP.W.X.Y.ZA
PASCAL V

When MMS accesses one of these sources from CDD/Plus, it writes the
string that is the value of CDDFLAGS into the history file.
The following restrictions apply to CDD/Plus access:
•

You cannot use the /REVISE_DATE qualifier with references to
CDD/Plus entities. (See the Command Dictionary for a description of the
/REVISE_DATE qualifier.)

•

Information produced from using the /AUDIT qualifier is not examined
during CDD/Plus node comparisons.

•

The /NOACTION qualifier has no effect on the /AUDIT qualifier.
That is, if you have suppressed the execution of action lines with the
/NOACTION qualifier, the remark you supply with /AUDIT is still
written to the CDD/Plus history file.

4.6 Using MMS with SCA
When you specify the /SCA_LIBRARY qualifier, MMS generates an SCA
library during the build process. Example 4-6 demonstrates how to use
MMS with the /SCA_LIBRARY qualifier.

4-22 Accessing Libraries with MMS

Example 4-6: Using MMS with the /SCA_LIBRARV Qualifier
$

SET DEFAULT [SYSTEMl]
SCA CREATE LIB [.SCALIB]
%SCA-S-NEWLIB, SCA Library created in DISK1$: [SYSTEMl.SCALIB]
%SCA-S-LIB, your SCA Library is DISK1$:[SYSTEM1.SCALIB]

@$ TYPE SCA.MMS
FROG.EXE
PROG.OBJ
FROG.OBJ : PROG.C
$

@)$
TYPE
main ()

PROG.C

{

int total;
total = 2 + 2;
}

MMS/SCA LIBRARY/DESCRIPTION=SCA FROG.EXE
CC /NOLISTfOBJECT=PROG/ANALYSIS DATA=PROG PROG.C
mms$scalib = F$TRNLNM( "SCA$LIBRARY")
mms$scasetlib = 0
IF mms$scalib .EQS. "" .AND. "SCA$LIBRARY: 11 .NES.11SCA$LIBRARY:11 THEN mms$scasetlib = 2
IF mms$scalib .NES. 1111 .AND. 11 SCA$LIBRARY: 11 .NES.11SCA$LIBRARY: 11 .AND. mms$scalib .NES. "SCA$LIBRARY: 11 THENmms$scasetlib = 3
IF F$SEARCH( 11 SCA$LIBRARY:SCA$EVENT.DAT 11 ) .EQS. 1111 THENmms$scasetlib = (mms$scasetlib .AND . . NOT. 2) .OR. 4
IF (mms$scasetlib .AND. 4) .EQ. 4 THEN SCA CREATE LIBRARY SCA$LIBRARY:
IF (mms$scasetlib .AND. 2) .EQ. 2 THEN SCA SET LIBRARY SCA$LIBRARY:
0$ SCA LOAD FROG
%SCA-S-LOADED, module PROG loaded
%SCA-S-COUNT, 1 module loaded (1 new, 0 replaced)
IF mms$scasetlib THEN SCA SET LIBRARY 'mms$scalib'
LINK /TRACE/NOMAP/EXEC=PROG PROG.OBJ
$

0 Set default to your system directory, and initialize the SCA library.

8
@)

0
0

A side effect of initializing the library is that the logical name
SCA$LIBRARY is now defined.
The MMS description file describing the system dependencies.
The source code file that MMS uses to compile and link our target and
sources.
MMS/SCA_LIBRARY is invoked with the target PROG.EXE specified.
SCA loads the SCA data file into the SCA library.

Accessing Libraries with MMS 4-23

Command Dictionary

Insert tabbed
divider here.
Then discard
this sheet.

MMS

MMS
The MMS command invokes the VAX DEC/Module Management System.
By default, it searches in your current directory for the description file
DESCRIP.MMS. If DESCRIP.MMS does not exist, MMS then searches for
a description file named MAKEFILE., and then for a file named targetname.MMS (see Section 1.2 and the /DESCRIPTION qualifier for more
information).

Format
MMS

[/qualifier ... ] [target, ... ]

Qualifiers
/[NO]ACTION
/CHANGED=(source1, source2, ... )
/[NO]CHECK_STATUS
/[NO]CMS
/[NO]DESCRIPTION[=filespec ... ]
/[NO] FORCE
/[NO]FROM_SOURCES
/HELP[="topic"]
/IDENTIFICATION
/[NO] IGNORE[=Options]
/[NO] LIST[=files pee]
/[NO] LOG
/MACRO=filespec
/OUTPUT=filespec
/[NO]OVERRIDE
/[NO]REVISE_DATE
/[NO]RULES[=filespec]
/[NO]SCA_LI BRA RY[ =library-name]
/[NO]SKIP_INTERMEDIATE
/[NO]VERIFY

Defaults
/ACTION
See text
/NOCHECK_STATUS
/NOC MS
/DESCRIPTION[=filespec ... ]
/NOFORCE
/NOFROM_SOURCES
See text
See text
/NOIGNORE
/NOLIST
/NO LOG
See text
See text
/NOOVERRIDE
/NOREVISE_DATE
/RU LES[=filespec]
/NOSCA_LIBRARY
/NOSKIP_INTERMEDIATE
/VERIFY

Command Dictionary

CD-3

MMS

Parameters
/qualifier

MMS qualifiers modify the MMS command. You can place qualifiers
anywhere on the command line after the MMS command. The notation ( D )
following a qualifier indicates the default form.
You can abbreviate all MMS qualifiers and their parameters, but you must
be sure that the abbreviations are unique so they will not be confused with
other command-line interface (CLI) qualifiers. If you type an ambiguous
abbreviation, the CLI issues an error message.
You can continue an MMS command to the next line by using the DCL
continuation character, a hyphen ( - ), as the last character on the command
line.
target

The name of a target, which can be either a VMS file specification, a logical
name, a library specification enclosed in quotes, or a mnemonic name.
Unless you use the /NODESCRIPTION qualifier on the command line,
you need not type the qualifiers and targets you want to use. MMS
assumes default qualifiers and updates the first target in the description file
whenever you type the MMS command, or if you specified a target on the
command line, MMS updates the target itself.

Qualifiers
/ACTION (D)
/NO ACTION
Controls whether MMS executes the action lines in a description file. These
qualifiers affect only the execution of action lines, not the behavior of MMS.

The /ACTION qualifier displays action lines as they are invoked. MMS does
not display any information on dependencies.
If you specify /NOACTION, MMS does not execute the action lines, but
instead writes them to an output file (either SYS$0UTPUT or the file
specified by the /OUTPUT qualifier). /NOACTION is useful for determining
what actions MMS would have executed had the system actually been built.
You can also use /NOACTION in combination with the /OUTPUT qualifier
CD-4 Command Dictionary

MMS
to generate a command procedure (see the description of the /OUTPUT
qualifier).
/NOACTION overrides the Silent action line prefix(@) described in
Section 2.6.6. Note that the $(MMS) reserved macro is executed even if
you specify /NOACTION. Therefore, you can see what actions MMS would
have executed in the subprocess. See Section 3.3 for information about the
$(MMS) macro.
/NOACTION does not affect the /AUDIT qualifier that you can provide with
references to CDD records. That is, if you suppress the execution of action
lines with the /NOACTION qualifier, the remark you supply with /AUDIT is
still written to the CDD history file. The /AUDIT qualifier and CDD records
are described in Section 4.5.
/CHANGED=(source1, source2, ... )

Directs MMS to treat only the specified sources as having been changed,
regardless of their actual modification times. No date checking is performed
at all; MMS simply rebuilds any targets that depend on one or more of the
specified sources. This qualifier affects the behavior of MMS but not the
execution of action lines.
/CHECK_STATUS
/NOCHECK_STATUS (D)

Controls whether MMS returns a value in the symbol MMS$STATUS
instead of updating a target. This symbol contains the status of the last
action line executed by MMS. These qualifiers affect both the execution of
action lines and the behavior of MMS.
When you specify the /CHECK_STATUS qualifier, MMS checks whether a
target is up-to-date by determining whether any actions would be executed if
the /ACTION qualifier was specified. MMS issues an informational message
and sets MMS$STATUS to 1 if no actions would be executed (that is, if
the target is up-to-date). If the target needs to be updated, MMS sets the
MMS$STATUS value to 0.
/CHECK_STATUS has precedence over both the /ACTION and /REVISE_
DATE qualifiers if they a pp ear on the same command line. In this case, only
/CHECK_STATUS is processed.
The /NOCHECK_STATUS qualifier directs MMS to process the description
file as it normally would, executing action lines if necessary.

Command Dictionary CD-5

MMS
/CMS
/NOCMS (D)

Controls whether MMS looks for source files, description files, and included
files in the current default CMS library as well as in the specified directories.
CMS must be installed on your system. See Section 4.2 for information on
using MMS to. access elements in CMS libraries. These qualifiers affect both
the execution of action lines and the behavior of MMS.
When you specify the /CMS qualifier and the source in the CMS library
is newer, MMS fetches it from the CMS library. If the source in the CMS
library is older, MMS instead uses the source in the specified directory.
/CMS also directs MMS to look in the current default CMS library for a
description file and any files included with the .INCLUDE directive or
specified with the /RULES qualifier. If MMS does not find a description file
in either the specified directory or the current default CMS library, it aborts
execution.
The /CMS qualifier also directs MMS to apply CMS built-in rules where
appropriate. (See Section C.9 for information about CMS built-in rules.)
The /NOCMS qualifier directs MMS not to look in the current default
CMS library for source files, description files, rules files, or included files.
However, if any file specifications in the description file are followed by a
tilde ( - ) to indicate specific CMS elements, MMS looks for the files in the
CMS library regardless of whether /NOCMS is in effect.
If you specify /NOCMS or the combination /CMS/NO RULES, and the sources
do not exist in the specified directory, MMS aborts execution.
/DESCRIPTION[:filespec ...](D)
/NODESCRIPTION target

Controls whether MMS looks for a description file to update the target.
These qualifiers affect the behavior of MMS but not the execution of action
lines.
The filespec is a VMS file specification or a logical name that identifies the
description file. The default file type is .MMS. If a tilde (-)follows the file
specification, MMS fetches the description file from the default CMS library
even if the description file exists in the default directory. The target is a
VMS file specification or a mnemonic name that designates the target to be
built.

CD-6

Command Dictionary

MMS
When you specify more than one description file, separate the file specifications with either commas ( , ) or plus signs ( + ) and enclose them in
parentheses or quotation marks.
If you use commas, the description files are processed separately and the list
of files must be enclosed in parentheses. For example:
$

MMS/DESCRIPTION=(A, B)

If you use plus signs, the description files are concatenated and processed as
one file. The list of files must be enclosed in quotation marks. For example:
$

MMS/DESCRIPTION="A + B"

You can combine separate description files with description files to be
concatenated and processed as one file. For example:
$

MMS/DESCRIPTION=("A + B", CLEANUP)

This command line directs MMS to process A.MMS and B.MMS as one file,
and CLEANUP.MMS as another. In this case, there are two default targets:
the first one is in either A.MMS or B.MMS (depending on the contents of the
two files) and the second one is in CLEANUP.MMS.
If you specify a list of description files in parentheses and a list of targets,
the rules for updating all the listed targets must occur in all the listed
description files. For example:
$

MMS/DESC=(A,B) X,Y,Z

In this case, the rules for updating X, Y, and Z must appear in both
description files, A.MMS and B.MMS.
If you specify a concatenated list of description files and a list of targets,
the rules for updating all the listed targets must occur in the concatenated
description file. For example:
$

MMS/DESC="A + B" X,Y,Z

In this case, the description file formed by the concatenation of A.MMS and
B.MMS must contain the rules for updating X, Y, and Z.
If you specify the /DESCRIPTION qualifier without a file specification
or if you do not specify /DESCRIPTION, MMS looks first for the default
description file DESCRIP.MMS. If it cannot locate that file, it looks for
one called MAKEFILE.; if it cannot find MAKEFILE., it looks for targetname.MMS. If MMS finds target-name.MMS, it does not update the first
Command Dictionary

CD-7

MMS
target in the description file, but instead attempts to directly update the
target indicated by target-name.MMS. For example:
$

MMS MAIN. EXE

In this example, if DESCRIP.MMS and MAKEFILE. are not present, MMS
looks for a file named MAIN.MMS. If MAIN.MMS exists, MMS directly

processes the target you specified on the command line, MAIN .EXE. See
Section 2.1.2 for more information.
If MMS cannot find any one of these files, it attempts to use built-in rules to
build the target.
If you use the /NODESCRIPTION qualifier, you must specify a target on the
command line. /NODESCRIPTION directs MMS to ignore all description
files and to build the target specified on the command line.
/FORCE
/NOFORCE(D)

Controls whether MMS executes the action lines necessary to update one
specific target. These qualifiers affect the behavior of MMS but not the
execution of action lines.
When you specify the /FORCE qualifier, MMS does not check whether the
target or its sources are up-to-date, but simply rebuilds the specified target
by executing the action lines. MMS also executes any .FIRST and .LAST
directives associated with the target.
The /FORCE qualifier is useful for quickly rebuilding a single target.
/FROM_SOURCES
/NOFROM_SOURCES (D)

Directs MMS to build a target from its sources, regardless of whether the
target is already up-to-date. This qualifier affects the execution of action
lines and the behavior of MMS.
When you specify the /FROM_SOURCES qualifier, MMS does not compare
the revision times of the specified sources and target. Instead, it executes
the action lines in the description file necessary to update the target. The
/FROM_SOURCES qualifier is useful when you want to guarantee that an
entire system is rebuilt, perhaps for an internal release.

CD-8

Command Dictionary

MMS
If you specify the /CMS and /FROM_SOURCES qualifiers on the MMS
command line, MMS uses the sources found in the default CMS library. If
you do not use /CMS, MMS uses the sources found in the specified directory.

The /FROM_SOURCES qualifier overrides the /SKIP_INTERMEDIATE
qualifier.
/HELP[="topic"]

Provides information about MMS and its qualifiers. The topic is an MMS
topic on which you want information.
The /HELP qualifier displays information about MMS on your terminal.
If you specify the /HELP qualifier without a topic, MMS displays general
information and a list of qualifiers. To get help on a specific topic, type
/HELP with an equal sign ( =) and the topic. The topic must be enclosed in
quotation marks. For example:
$

MMS/HELP="/RULES"

See Section 1.3 for more information.
/IDENTIFICATION

Directs MMS to display an informational message with the version number
and copyright date of the MMS image you are running. MMS does not
process any description files or qualifiers; it simply displays an informational
message on your screen.
You should include the version number and copyright date with any MMS
Software Performance Reports (SPRs) you submit.
/IGNORE[:options]
/NOIGNORE (D)

Directs MMS to specify the severity levels of errors that MMS normally
ignores when it executes action lines. The parameters correspond to the
DCL severity levels W, E, and F. The /NOIGNORE qualifier directs MMS to
abort execution when it finds an error. These qualifiers affect the execution
of action lines but not the behavior of MMS.
The options field can contain the keyword WARNING, ERROR, or FATAL.
WARNING directs MMS to ignore W errors and continue processing, but
to abort execution if it finds either an E or an F error. If you specify the
/IGNORE qualifier without parameters, WARNING is the default. ERROR
directs MMS to ignore both W and E errors, but to abort execution if it
finds an F error. FATAL directs MMS to ignore all errors, and to continue
Command Dictionary

CD-9

MMS
processing the description file. This parameter is equivalent to the .IGNORE
directive.
When you specify /IGNORE, the errors that MMS ignores are those
generated by the execution of action lines rather than MMS errors.
/IGNORE does not stop MMS error messages from being generated or
displayed. Informational messages are always displayed, regardless of
whether you use the /IGNORE qualifier.
NOTE

Take caution when executing MMS with the /IGNORE qualifier;
if errors occur during processing, the target may be updated but
still contain errors of which you will not be aware.
The .IGNORE directive and the Ignore action line prefix are similar to
the /IGNORE=FATAL qualifier. However, instead of typing them on the
command line, you include them in the description file. Sections 2.6.5 and
2. 7 .1 describe the Ignore action line prefix and the .IGNORE directive in
detail.
To override the .IGNORE directive contained in a description file, you must
type the /IGNORE[=WARNING], /IGNORE=ERROR, or /IGNORE=FATAL
qualifier explicitly on the MMS command line. You cannot override the
Ignore action line prefix on the MMS command line.
/LIST[=filespec]
/NOLIST (D)

Controls whether MMS writes dependencies and action lines to an output
file as it processes the description file. These qualifiers affect the behavior of
MMS but not the execution of action lines.
When you specify the /LIST qualifier, MMS creates a complete listing of all
dependencies, dependents, and actions that need to be processed to update
the target. MMS creates this listing as it processes the description file,
and writes the listing to the output file, or to SYS$0UTPUT if you did not
specify a file.
The /LIST qualifier is useful during the debugging of description files. You
can also use /LIST in combination with the /NOACTION qualifier to display
the dependency list and action lines without executing any actions.

CD-10 Command Dictionary

MMS
/LOG
/NOLOG {D)

Controls whether MMS displays informational messages as it processes the
description file. These qualifiers affect the behavior of MMS but not the
execution of action lines.
The /LOG qualifier directs MMS to write all informational messages to your
terminal screen while it processes the description file. The /LOG qualifier is
useful for debugging your description files. These messages indicate what
MMS finds and what it assumes as it processes the description file. You
should include these messages with any MMS Software Performance Reports
(SPRs) you submit. To save these messages in a file, type the following:
$
$

DEFINE SYS$0UTPUT MYFILE.LOG
MMS/LOG

DEASSIGN SYS$0UTPUT

The /NOLOG qualifier prevents MMS from displaying informational
messages. However, if you specify /NOLOG/CHECK_STATUS on the same
command line, MMS does display the informational message that reports
the value of MMS$STATUS. (See the description of the /CHECK_STATUS
qualifier for more information about MMS$STATUS.)
/MACRO:filespec I "macro", ...

Directs MMS to add to or override the macro definitions in the description
file. This qualifier affects the behavior of MMS but not the execution of
action lines.
The filespec is a VMS file specification or a logical name that identifies a file
of macro definitions. The default file type is .MMS. The macro string is a
macro definition enclosed in quotation marks. Use the same format as for
macro definitions in description files, that is, name =string.
With the /MACRO qualifier, you can specify a macro definition on the MMS
command line. You can also specify a file of macro definitions to use in your
description file. Section 2.3 discusses the use of macros.

Command Dictionary CD-11

MMS
You can define macros in three locations:
•
•
•

In a description file
In a macro definitions file
On the command line

To specify more than one macro definition on the MMS command line,
enclose the list of macros in parentheses. For example:
$

MMS/MACRO= (II A=MACl II I

B=MAC2 II)

You can also specify both a macro definition and a file on the same command
line. For example:
$

MMS/MACRO= ( 11 A=MACl II I

MACROS)

/OUTPUT:filespec

Directs MMS to write action lines and output to the specified file. Error
messages preceded by "%MMS" are not written to this output file, but
instead are written to SYS$ERROR. The /OUTPUT qualifier affects the
behavior of MMS but not the execution of action lines.
The filespec is a VMS file specification or a logical name that identifies the
output file. The default file type is .LOG. If you do not specify the /OUTPUT
qualifier on the MMS command line, MMS writes all action lines, messages,
and output to SYS$0UTPUT.
If you specify the /NOVERIFY qualifier on the same MMS command line
with /OUTPUT, MMS does not write action lines to the output file.
If you specify /OUTPUT and your command-line interpreter is DCL, MMS

automatically prefixes a dollar sign ( $) to any action line that does not
begin with one. Thus, you can use the file generated by /OUTPUT as a DCL
command procedure.
/OVERRIDE
/NOOVERRIDE (D)

Controls the order in which MMS applies definitions when it processes
macros. These qualifiers affect the behavior of MMS but not the execution of
action lines.

CD-12

Command Dictionary

MMS
When you specify the /OVERRIDE qualifier, MMS overrides the macro
definitions in the description file with CLI symbol definitions. To find the
macro definitions that should have precedence, MMS looks at symbols
defined by the CLI assignment statement, scanning the CLI symbol table
for the body of the macro. If the body of the macro is not in the CLI symbol
table, MMS substitutes a null string for all invocations of the macro.
The /OVERRIDE qualifier imposes the following order of application when
MMS processes macro definitions:
Command line
2. CLI symbol
3. Description file
4. Built-in
1.

Once MMS finds a definition for a macro, it does not search those locations
farther down the list for more definitions. If MMS finds more than one
definition in the same location (such as on a command line), it uses the last
definition it processed, unless the location is a description file. MMS issues
an error message if a macro is defined more than once in a description file.
The /NOOVERRIDE qualifier imposes the following order, which is the
default hierarchy:
1. Command-line
2. Description file
3. Built-in
4. CLI symbol
/REVISE_DATE
/NOREVISE_DATE (D)

Controls whether MMS changes only the revision dates of all targets that
need updating, or performs the update. These qualifiers affect the behavior
of MMS, not the execution of action lines.
When you specify the /REVISE_DATE qualifier, MMS changes only the
revision dates of targets that need updating; it does not direct MMS to
execute the action lines that actually do the updating. If any files are
missing, /REVISE_DATE causes MMS to create them. If MMS cannot create
a missing file, or if it cannot update the revision date of an existing file, it
issues an error message.
Command Dictionary

CD-13

MMS
The /REVISE_DATE qualifier is useful for reducing the number of superfluous compilations, for example, when you change only a comment line in
a required file. However, /REVISE_DATE can defeat the purpose of using
MMS, so use this qualifier with caution.
As it changes the revision times, MMS writes the name of the revised files
to an output file (or to SYS$0UTPUT if no file is specified). If you specify
the /REVISE_DATE and /NOVERIFY qualifiers, the names of revised files
are suppressed. (Section 2.7.2 describes the .SILENT directive.)
Unless you specify a target on the command line, the /REVISE_DATE
qualifier causes MMS to revise the first target (and its sources) in the
description file. If you specify multiple targets on the command line, those
targets and their sources are revised. /REVISE_DATE does not change
the value of MMS$STATUS. (See Section 2.6.3 for information about
MMS$STATUS.)
The /REVISE_DATE qualifier has precedence over the /ACTION qualifier if
they both appear on the same command line. In that case, only /REVISE_
DATE is processed.
The /NOREVISE_DATE qualifier directs MMS to build the system by
updating targets as necessary (as long as the /CHECK_STATUS qualifier is
not specified on the same command line).
/RULES[=filespec] (D)
/NORULES

Controls whether MMS applies user-defined built-in rules and a suffixes
precedence list when it builds a system. These qualifiers affect the behavior
of MMS but not the execution of action lines.
The filespec is a VMS file specification or a logical name that identifies
the file of user-created rules that MMS is to use. When you supply a file
specification with the /RULES qualifier, MMS replaces the built-in rules it
normally uses with the built-in rules and suffixes list in the file you specify.
The file specified with /RULES has precedence over the file represented by
MMS$RULES.
If you specify /RULES without a file specification, MMS translates the

logical name MMS$RULES to locate the user-defined built-in rules file. If
MMS$RULES is not defined, MMS uses its own built-in rules.

CD-14 Command Dictionary

MMS
The /NORULES qualifier prevents MMS from using its built-in rules or the
suffixes precedence list. It also prevents MMS from applying user-defined
rules and default macros. When you specify /NORULES, MMS applies only
the dependency rules contained in the description file.
/SCA_LIBRARV[=library-name]
/NOSCA_LIBRARV (D)

Controls whether MMS generates an SCA library during the build process.
When you specify a library name with the /SCA_LIBRARY qualifier, MMS
defines the macro $(SCALIBRARY) to be that library name. If you use
/SCA_LIBRARY without specifying a library name, SCA$LIBRARY is the
value of $(SCALIBRARY). If you do not specify /SCA_LIBRARY, /NOSCA_
LIBRARY is the default.
The macro $(SCA) is defined to be SCA regardless of the setting of the
/SCA_LIBRARY qualifier.
The macro $(MMSQUALIFIERS) contains the setting of the /SCA_LIBRARY
qualifier.
When you specify the /SCA_LIBRARY qualifier, built-in rules for BASIC,
BLISS-32, C, COBOL, FORTRAN, MACRO, Pascal, PL/I, and SCAN change.
Table C-2 lists the macros that change when you specify the /SCA_LIBRARY
qualifier.
NOTE

You may prefer to defer the loading of modules into the SCA
library until after all compilations are completed. In this case,
you should define the default rules for compilation in your
description file to be the same as the default rule provided by
MMS when the /NOSCA_LIBRARY qualifier is specified. You
should also include a .LAST directive, which then loads the SCA
database. For example:
.LAST :
$(SCA) SET LIBRARY $(SCALIBRARY)
$(SCA) LOAD*

Command Dictionary CD-15

MMS
/SKIP_INTERMEDIATE
/NOSKIP_INTERMEDIATE (D)
Controls whether MMS builds intermediate source/target files. These
qualifiers affect the behavior of MMS, not the execution of action lines.

The /SKIP_INTERMEDIATE qualifier directs MMS to determine whether a
target is up-to-date without rebuilding intermediate files unless they need to
be updated.
MMS first checks the target date against the dates of its sources. If the
target is newer than its sources, MMS determines that the target does not
need to be rebuilt; if MMS cannot find some intermediate files, it acts as
though they already exist, and skips over them to check their sources, and
so on.
For example, if you have a .C file and an .EXE file, but no .OBJ file, and
the time of the .EXE file is more recent than that of the .C file, the /SKIP_
INTERMEDIATE qualifier prevents MMS from building the .OBJ file and
the .EXE file because the target is already up-to-date with regard to its
nearest source. Using /SKIP_INTERMEDIATE saves time and disk space.
If the target is older than its sources, MMS determines that the target does
need to be rebuilt. It then ensures that all of the target's immediate sources
exist; if any do not, MMS works from the bottom up by first rebuilding the
missing sources, then rebuilding the target. If the sources contain included
files that have changed, are located in a CMS library, or both, MMS also
fetches the included files and recompiles the source files, then rebuilds the
system. For example:
! SYSTEM2.MMS

SYSTEM2 : MAIN.EXE, MOD.EXE
MAIN.EXE : MAIN.OBJ
MAIN.OBJ : MAIN.C, DEFSl.H, DEFS2.H
MOD.OBJ : MOD.C, DEFS2.H

If the included file DEFSl.H changes, when you specify the /SKIP_
INTERMEDIATE qualifier, MMS does the following:

Determines that one of the target's sources is newer than the target, and
that the target must be rebuilt.
2. Verifies that MAIN.OBJ depends on MAIN.C, which contains the
included files DEFSl.H and DEFS2.H.
1.

CD-16 Command Dictionary

MMS
3. Fetches MAIN.C, DEFSl.H, and DEFS2.H from the CMS library and
recompiles MAIN.C.
4. Since MAIN.OBJ is now newer than MAIN.EXE, MMS rebuilds
MAIN.EXE.
5. Since none of the sources for MOD.EXE have changed, MMS does not
need to fetch them from CMS, and target SYSTEM2 is now up-to-date.
The /NOSKIP_INTERMEDIATE qualifier directs MMS to ensure that all
intermediate source files exist and are up-to-date. If any intermediate
source files do not exist, MMS builds them. This is the default.
/VERIFY (D)
/NO VERIFY

Controls whether MMS displays action lines before executing them. These
qualifiers affect the behavior of MMS, not the execution of action lines.
The /VERIFY qualifier directs MMS to display each action line before
executing it. MMS writes action lines either to SYS$0UTPUT or to a file
you specify on the /OUTPUT qualifier.
If you specify the /REVISE_DATE qualifier in combination with the /VERIFY

qualifier, MMS displays the names of files whose dates have been revised.
When you specify the /NOVERIFY qualifier, MMS suppresses the display
(but not the execution) of action lines. Any error messages generated by
the execution of action lines continue to be displayed. If you specify the
/REVISE_DATE and /NOVERIFY qualifiers on the same command line, the
names of files whose dates have been revised are not displayed.
The behavior of the /NOVERIFY qualifier is identical to that of the Silent
action line prefix and the .SILENT directive (see Sections 2.6.6 and 2.7.2,
respectively). If a description file contains the .SILENT directive, to override
it you must type the /VERIFY qualifier explicitly on the MMS command line.
You cannot override the Silent action line prefix from the MMS command
line.

Command Dictionary CD-17

Appendix A

Error Messages

This appendix lists messages produced by MMS. The messages are
accompanied by explanations and suggested actions to recover from errors.

A.1

Message Display
MMS messages are issued on the current output device identified by the
logical name SYS$0UTPUT. If you are running MMS interactively, this
device is a terminal; if you are running MMS in batch mode, messages are
written into the log file.

A.2 Severity Levels
The severity level of a message is included in the status message and
indicates the general nature of the message.
Informational (I) messages inform you of MMS's actions during the systembuilding process. You can control the display of these messages by specifying
the /[NO]LOG qualifier on the command line (some informational messages
are displayed regardless of whether you specify /LOG).
Warning ( W) messages indicate that MMS has encountered a minor
error. If the error occurs during the execution of an action line, processing
stops unless you specify the /IGNORE=FATAL, /IGNORE=ERROR, or
/IGNORE=WARNING qualifiers on the command line.
Fatal ( F) messages indicate that MMS is terminating because of a problem
that prevents it from continuing any further.
MMS does not generate Success ( S ) or Error ( E ) messages.

Error Messages A-1

A.3 MMS Messages
This section lists all MMS messages along with brief descriptions and
recommended user actions. Items enclosed in single quotation marks
indicate variable information.
ABORT, For target 'target name,' CLI returned abort status: %X' status.'

Explanation: Execution of an action line in the description file returned a fatal or warning error. By default, MMS aborts execution.
User Action: Correct the error in the action line.
BADTARG, Specified target' target name' does not exist in the description
file.

Explanation: You specified a target on the command line that
does not exist in your description file.
User Action: Correct the command line or the target specification
in the description file.
CDDACCERR, CDD access error on path ' path specification.'

Explanation: The VAX Common Data Dictionary (CDD) signaled
an error while attempting to access the path specified in your
description file.
User Action: Verify the path specification and correct the description file.
CDDNOAUD,

CDD audit string not found.

Explanation: You used the IAUDIT qualifier with a CDD element
specification, but you did not supply a remark to be included in the
CDD audit history file.
User Action: Edit the description file to remove the /AUDIT
qualifier or to include a remark with it.
CDDNOTIME,

CDD path 'name' has no time attribute.

Explanation: The CDD path specification in your description file
is not associated with a revision time. Therefore, MMS cannot
determine whether the CDD element is newer than your target.
User Action: You cannot use a CDD record that is not associated
with a revision time. Correct the description file to specify a
different CDD element.
A-2

Error Messages

CDDPLSERR, Error returned from CDD/Plus.
Explanation: An error occurred in the processing of your description file when MMS tried to access a CDD/Plus element. This
message is preceded by a message from CDD/Plus to help you locate
the error.
·
User Action: Correct the condition that caused the first error and
try again.
CDDPRIERR, Prior severe CDD error has occurred.
Explanation: An error occurred earlier in the processing of your
description file when MMS tried to access a CDD element. This
message is preceded by one of MMS's other error messages that
pertain to the CDD and by a message from the CDD itself to help
you locate the error.
User Action: Correct the condition that caused the first error and
try again.
CLPHELP, Please type HELP MMS for help on DEC/MMS.
Explanation: For some reason MMS cannot access the help
library from the /HELP qualifier on the MMS command.
User Action: Type the DCL command HELP MMS instead.
CMSABORT, Aborted with CMS errors.
Explanation: One or more errors were returned by Callable CMS
and MMS cannot continue processing.
User Action: The CMS message printed after %MMS-WCMSCALL will describe what caused the problem. Refer to the
Guide to VAX DEC I Code Management System for more information.
CMSBADGEN, Illegal generation 'value' specified in description file.
Explanation: The generation value specified by the /GENERATION
qualifier is not valid.
User Action: Correct the generation value or the CMS library.
CMSBADLIB, There is a problem with the specified CMS library 'library
name.'
Explanation: MMS is unable to access the specified CMS library.
User Action: Correct the CMS library or the description file.

Error Messages A-3

CMSBADTIM, Invalid time field in CMS history file for file 'filespec.'

Explanation: The time field in the history portion of the file in the
element is in a nonstandard format.
User Action: Reserve and then replace the CMS element that
contains the specified file. If this element belongs to a specified
CMS class, perform the steps necessary to replace the newly
created generation of that element into that CMS class.
CMSCALL,

Callable CMS has returned an error.

Explanation: Callable CMS, used in conjunction with CMS
Version 2 libraries, has returned an error to MMS. The specific
error is printed on the next line.
User Action: Refer to the Guide to VAX DEC/Code Management
System for more information on the CMS error returned.
CMSNOCLAS,

Specified class name 'name' not found in CMS library
' library name.'

Explanation: MMS could not find the given class name (specified
with /GENERATION in the CMS library).
User Action: Correct the CMS library or the description file.
CMSNOELE, Element 'element name' not found in CMS library.

Explanation: MMS could not find the specified element in the
CMS library.
User Action: Correct the CMS library or the description file.
CMSNOFIL,

File 'filespec' not found in CMS library.

Explanation: MMS could not find the specified file in the CMS
library.
User Action: Correct the CMS library or the description file.
CMSNOGEN, No generation value specified.

Explanation: You did not specify a value with the /GENERATION
qualifier.
User Action: Add the value to the /GENERATION qualifier.

A-4

Error Messages

CMSNOLIB, Your default CMS library is undefined.
Explanation: You do not have a CMS library defined but you used
/CMS on the command line or a tilde ( ,.,. ) in the description file.
User Action: Define a CMS library.
CMSNOSUP,

DECIMMS cannot access DEC/CMS, or DEC/CMS is not
installed.

Explanation: You are trying to access a source in a CMS library,
but MMS was installed without CMS support.
User Action: CMS must already be installed on your system
before you install MMS if you want access to CMS libraries.
CMSPROBLEM, Problem with CMS control file 'filespec.'
Explanation: The specified control file is either missing or has
been opened by another user without using CMS.
User Action: Check to see whether the file is in the specified CMS
library. If it is, make sure it is closed and try running MMS again.
If the file is not in the CMS library, correct the library.
CMSPROCED, Proceeding with CMS library access.
Explanation: MMS is now accessing the specified CMS library.
User Action: None. This is an informational message that appears after the CMSWAIT message when MMS finally succeeds in
accessing the library.
CMSWAIT, CMS library library name' is in use. Please wait ...
1

Explanation: The specified CMS library is currently being accessed by another user. This message is printed at 4-second
intervals until access is successful.
User Action: Wait until MMS succeeds in accessing the CMS
library.
DRVBADPARSE, Parser detected a fatal syntax error in the description
file.
'
Explanation: The description file contains a syntax error. MMS
did not attempt to build the system.
User Action: Correct the erroneous line in the description file.

Error Messages A-5

DRVDEPFIL, Using description file 'filespec.'

Explanation: MMS is using the specified description file to build
the system.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
DRVFMSSUP, DEC/MMS is installed with support for VAX FMS.

Explanation: You can access forms stored in VAX FMS libraries
with this version of MMS.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
DRVINSQUO, Your process needs a 'quota name' of at least 'value,'
current value is 'value.'

Explanation: At least one of the process quotas set by your system
manager has been exceeded, and the remaining process quotas at
the time MMS was invoked were insufficient to run MMS reliably.
The BYTLM value relates to the buffered I/O byte count quota;
the ASTLM value relates to the AST limit of your process; the
PRCLM value relates to the subprocess limit of your process; and
the FILLM value relates to the open file limit of your process. You
can obtain information about your process-specific parameters by
typing the DCL command SHOW PROCESS/QUOTA.
User Action: Request that your system manager increase process
quotas.
DRVNOFMSSUP, DEC/MMS is installed without support for VAX FMS.

Explanation: You cannot access forms stored in VAX FMS
libraries because you did not install FMS before you installed MMS
on your system.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
DRVOUTFIL, Using output file 'filespec.'

Explanation: MMS is writing all action lines and their resulting
output to the specified output file. Note that messages preceded by
"%MMS" are not written into this file, but to SYS$ERROR.
User Action: None. This is an informational message. It appears
only if you have invoked MMS with the /LOG qualifier.

A-6

Error Messages

DRVPARSERR,

Parser error: 'message' in file 'filename,' line 'number.'

Explanation: The MMS parser failed, for the reason explained in
the message text.
User Action: Correct the erroneous action line in the description
file.
DRVQUALIF, Using non-defaulted qualifiers 'qualifier name.'

Explanation: MMS is processing your description file using the
specified qualifiers. These qualifiers, which are not enabled by
default, correspond to the value of the $(MMSQUALIFIERS)
reserved macro.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
DRVRULFIL, Using rules file 'filespec.'

Explanation: MMS is reading its default rules from the specified
rules file.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
DRVSUBCLI, Using ' CLI name' for the subprocess CLI.

Explanation: MMS is using the specified CLI to execute the
subprocess.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
EXEBADREAD, Could not read command output from subprocess.

Explanation: The MMS main process was unable to read the
results of the action lines executed by the subprocess.
User Action: This message indicates a problem with your system,
possibly resulting from insufficient quotas or a mailbox problem.
Check with your system manager.
EXEBADWRT, Could not write command line to subprocess.

Explanation: The MMS main process was unable to send an
action line to the subprocess for execution.
User Action: This message indicates a problem with your system,
possibly resulting from insufficient quotas or a mailbox problem.
Check with your system manager.
Error Messages A-7

EXECANTWAKE, Could not wake up main process.
Explanation: After executing an action line, the subprocess was
unable to wake up the main process.
User Action: This message indicates a problem with your system,
possibly resulting from insufficient quotas or a mailbox problem.
Check with your system manager.
EXEDELPROC,

Subprocess terminated abnormally.

Explanation: The subprocess terminated unexpectedly, possibly
because you used illegal commands like STOP or LOGOUT in your
description file or because the subprocess was stopped by another
process.
User Action: Remove any invalid commands from the description
file.
EXEDELSES,

Cleanup of subprocess %X value' failed.
1

Explanation: The $DELPRC system service could not delete the
subprocess that was executing action lines.
User Action: Type the DCL command SHOW SYSTEM/SUB to
determine whether the subprocess still exists. If it does, type the
STOP command to delete it: STOPIID= value.' If the subprocess
does not still exist and this message was preceded by the message
%MMS-F-EXEDELPROC, the subprocess was probably deleted by
a user command such as LOGOUT. If this is the case, remove the
offending command from the description file.
1

EXENCRE, Could not create subprocess for executing action lines.
Explanation: MMS could not create the subprocess for executing
action lines.
User Action: Check your quotas, and raise them if necessary. This
message could also indicate a system problem. Check with your
system manager.
EXENEF, Unable to allocate event flag.
Explanation: MMS was unable to allocate an event flag that
allows the MMS main process to communicate with the subprocess.
User Action: This message indicates a system problem. Check
with your system manager.

A-8

Error Messages

EXENOAST,

Could not enable AST.

Explanation: MMS could not enable an AST that allows the main
MMS process to send input to the subprocess and the subprocess to
send output back to the main process.
User Action: This message indicates a system problem. Check
with your system manager.
EXENOMBX,

Unable to create mailbox for communicating with
subprocess.

Explanation: MMS could not create a mailbox for the MMS main
process to use in communicating with the subprocess.
User Action: This message indicates a problem with your process's
creation of mailboxes. Check with your system manager.
EXEPROCID,

PID of created subprocess is %X value.'
1

Explanation: The process ID of your subprocess is the value
specified in the message.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
EXESTRING,

Quoted string must be under 'value' characters.

Explanation: A quoted string in an action line exceeded the
maximum length allowed.
User Action: Correct the action line in the description file.
EXETOOBIG,

Command too large. Maximum length is 'value' characters.

Explanation: The command on an action line exceeded the maximum command length allowed.
User Action: Correct the command in the description file.
FMSNOSUPP,

DEC/MMS is installed without VAX. FMS support.

Explanation: Your description file specifies a form in an FMS
library but you installed MMS without FMS support.
User Action: VAX. FMS must already be installed on your system
before you install MMS if you want access to FMS forms.

Error Messages A-9

FMSNOWILD, Wild cards are not allowed for VAX FMS library access.

Explanation: You cannot use a wildcard character in the specification of an FMS form.
User Action: Correct the description file to specify the forms you
want MMS to access.
GFBTYPEMIX, Illegal single/double colon rule mix for 'item' in line
'number.'

Explanation: The item named was specified as a target in both a
single colon and a double colon dependency rule.
User Action: Choose the rule you want for the build and make the
description file consistent with respect to this target.
GMBADMOD, Missing left parenthesis in library specification 'filespec.'

Explanation: A library specification is missing a left parenthesis.
User Action: Insert the missing parenthesis.
GMFUTURE, Time for 'filename' is in the future: 'time.'

Explanation: MMS is attempting to access a target whose creation
date is later than the current time. This can occur when system
clocks are not exactly synchronized.
User Action: Adjust the date of the file and try again. If necessary, adjust the system clocks.
GMLCKRTRY, File 'filename' is locked by another user; retrying...

Explanation: MMS is unable to get the modification date/time
for files that are open for exclusive access by another process
(for example, an .OBJ file that is currently being generated by a
compilation currently in progress). MMS attempts the retry for
5 minutes.
User Action: Unlock the file or wait for MMS to time out.
GMRTRYEXC, File ' filename' is locked by another user; retry limit
exceeded. MMS will assume it is current.

Explanation: MMS has attempted to access a locked file; after
5 minutes, MMS assumes the file is current and continues processing.
User Action: None. This is an informational message that appears
once MMS has completed its 5-minute retry.
A-10

Error Messages

GMTIMFND, Time for 'filespec' is 'time.'
Explanation: The specified time is the latest revision time MMS
found for the specified file.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
GWKBEGWLK,

Starting the build at target 'target name.'

Explanation: MMS will start its build process by trying to update
the specified target.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
GWKCANT, MMS cannot update target 'target name.'
Explanation: MMS cannot update the specified target because
neither the description file nor the built-in rules indicate how to
do it. Because you instructed MMS to ignore severe errors (using
either .IGNORE or /IGNORE=FATAL), processing of the description
file continues.
User Action: Revise the description file. Either remove the dependency on the target or describe how to update the target.
GWKCHGEXC, $(MMS$CHANGED_LIST) exceeds maximum VMS string
length; setting it to NULL.
Explanation: The string for the $(MMS$CHANGED_LIST) macro
has exceeded the maximum VMS string size of 64KB. MMS sets
the macro to null.
User Action: Reduce the number of sources for the target being
updated.
GWKCONECT, Target 'target name' found in circular dependency.
Explanation: The specified targets are involved in a circular
dependency; that is, a source depends on its target. This message
is always issued after the GWKLOOP message, which indicates
the target for which a circular dependency was detected in the
description file.
User Action: Revise the description file to remove circular
dependencies.

Error Messages

A-11

GWKCURRNT, Target 'target name' is already up-to-date.
Explanation: MMS has not updated the specified target because
it is already up-to-date.
User Action: None. This is an informational message.
GWKEXESTS, Status of executed command is %X condition code.'
1

Explanation: MMS has executed a CLI command in an attempt
to update a target. The resulting condition code of the command is
displayed in this message, and MMS attempts to decode its text in
the following message line. If the next message line is blank, MMS
cannot decode the message.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
GWKHSHOVER, Internal Hashtable Overflow.
Explanation: This is an MMS internal error.
User Action: Collect as much information as possible and submit
a Software Performance Report (SPR).
GWKLOOP, Circular dependency detected at target 'target name.'
Explanation: The specified target is indirectly its own source.
That is, you are asking MMS to make a target from the target
itself, which is not legal. The ensuing GWKCONECT messages
specify all relevant targets involved in the circular dependency.
User Action: Revise the description file to remove circular
dependencies.
GWKNEEDUPD, An update is required for target 'name.'
Explanation: This message is issued when /CHECK_STATUS is
specified.
User Action: None. This is an informational message.

A-12

Error Messages

GWKNOACTS, Actions to update 'target name' are unknown.
Explanation: MMS cannot determine what actions to take in
updating the specified target. This message may indicate a problem
with the .SUFFIXES list or with your user-defined rules. There
may be no built-in rule or user-defined rule for MMS to use. The
file types in the user-defined rule might not be in the .SUFFIXES
list, or they might be in the wrong order.
User Action: Revise the description file. Specify the actions
needed to update the target.
GWKNOPRN, There are no known sources for the current target 'target
name.'
Explanation: MMS has found no sources for the current target.
User Action: Create a source file that can update the target.
GWKNOREV,

Cannot update modification time for file 'filespec.'

Explanation: MMS is unable to modify the revision time of the
specified file, as directed by the /REVISE_DATE qualifier on the
command line, because an error occurred. A possible reason for the
error is that the file's protection prohibited write access.
User Action: Correct the file protection so that write access is
allowed.
GWKOLDNOD, Target 'target name' is older than 'source names.'
Explanation: The specified target is older than the specified
sources, so MMS will update it.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
GWKSRCEXC,

$CMMS$SOURCE_LIST) exceeds maximum VMS string
length; setting it to NULL.

Explanation: The string for the $(MMS$SOURCE_LIST) macro
has exceeded the maximum VMS string size of 64KB. MMS sets
the macro to null.
User Action: Reduce the number of sources for the target being
updated.

Error Messages A-13

GWKUPDONE,

Completed update for target 'target name.'

Explanation: MMS has updated the specified target.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
GWKUPDTIM, Updating modification time for file 'filespec.'

Explanation: MMS is changing the revision time of the specified
file, as directed by the /REVISE_DATE qualifier.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier, in addition
to /REVISE_DATE.
GWKWILLEX, MMS will try executing action line to update target 'target
name.'

Explanation: MMS will execute the action line to update the
current target for one of the following reasons: at least one source
may be more recent than the target, or the target may have no
sources.
User Action: None. This is an informational message that appears
only if you have invoked MMS with the /LOG qualifier.
!DENT, DEC/MMS 'versfon' COPYRIGHT ( C) 'date' DIGITAL
EQUIPMENT CORPORATION

Explanation: This message provides the version number and
copyright date of the MMS image installed on your system. You
should include this information with any Software Performance
Reports (SPRs) that you submit about MMS.
User Action: None. This is an informational message that appears only if you have invoked MMS with the /IDENTIFICATION
qualifier.
INTERNERR, Internal MMS Error. Please Report Error #'number.'

Explanation: An MMS internal component failed.
User Action: Collect as much information as possible and submit
a Software Performance Report (SPR).

A-14

Error Messages

LBRNOELEM, Illegal library element is specified in 'filespec.'

Explanation: You used incorrect syntax to specify a library
module.
User Action: Correct the module syntax in the description file.
LEXFILELOOP,

Included file 'filespec' is already open.

Explanation: An included file is itself included at some deeper
level. If undetected, this situation would cause an infinite sequence
of included files.
User Action: Remove the second level of inclusion in the file.
LEXIFERR, Encountered .ENDIF without matching .IFDEF.

Explanation: MMS found an .ENDIF directive in your description
file but no corresponding .IFDEF directive.
User Action: Correct the description file to remove the .ENDIF
directive or add the necessary .IFDEF.
LEXILLNAME,

Specified target name 'target' on line 'number' is illegal.

Explanation: You used incorrect syntax to indicate the target on
the specified line number of the description file.
User Action: Correct the description file.
LEXUNEXEND, Continuation character found at end of file.

Explanation: MMS found a hyphen ( - ) or a backslash ( \ ) continuation character at the end of the description file.
User Action: Revise the description file. Delete the continuation
character or add another line.
LFSBADFP,

Cannot find source for target 'filespec.'

Explanation: MMS cannot process an invalid file specification.
This error can occur if you specified an undefined logical name as
the target.
User Action: Correct the syntax of the file specification and invoke
MMS again.

Error Messages A-15

MBBADMODE, Unknown mode parameter 'mode number.'
Explanation: An internal MMS component failed.
User Action: Collect as much information as possible and submit
a Software Performance Report (SPR).
MBREDEFILL, Illegal attempt to redefine macro 'macro name.'
Explanation: You attempted to redefine the specified macro in
the description file. You cannot define the same macro twice in one
description file. The attempt is ignored, and the original definition
applies.
User Action: If you want to redefine a macro, you must use the
/MACRO qualifier on the MMS command line.
NOACCESS, Unable to access file 'file.'
Explanation: This message is followed by one or more messages
describing why the file could not be accessed.
User Action: Modify the file protection of the inaccessible file.
NOLIBSPECDBL, Library module specifications not allowed as targets in
double colon rules: 'filespec.'
Explanation: You used a library module specification as a target
in a double colon dependency rule.
User Action: Rewrite the dependency as a single colon dependency
using the library module specification or use only the library file
name in your double colon dependency rule. You can write the
preferred single colon syntax by using library module specifications.
For example:
UTIL(MODl) : MODl.OBJ
LIBR UTIL.LIB MODl.OBJ
UTIL(MOD2) : MOD2.0BJ
LIER UTIL.LIB MOD2.0BJ

The following dependency rule is correct for the double colon use:
UTIL.OLB :: MODl.OBJ
LIBR UTIL.LIB MODl.OBJ
UTIL.OLB :: MOD2.0BJ
LIBR UTIL.LIB MOD2.0BJ

A-16

Error Messages

NOMACFIL,

Cannot open macro file 'filespec.'

Explanation: You specified either an illegal or a nonexistent file
in the command line macro definitions.
User Action: Create the file, or correct the file specification.
NOOUTFIL,

Cannot open output file 'filespec.'

Explanation: MMS failed to create the output file.
User Action: Verify that the file specification is legal, check your
disk quota, or check the protection of an existing file of the same
name as the output file.
NOSTATUS, Unable to set MMS$STATUS to 'value.'
Explanation: MMS received an error from VMS when trying to
set the symbol MMS$STATUS. This error may occur if you have
exceeded the available space for symbols defined by your process, or
if symbol scope is set to noglobal.
User Action: Either remove some of your symbols or have the
system manager change the SYSGEN parameter CLISYMTBL or
set symbol scope to global.
NOTARGET, No target specified.
Explanation: You did not specify a target for MMS to build.
User Action: Specify a target on the MMS command line, or
correct the description file so that it specifies a target.
UTLALLOCFAIL,

Failed to allocate memory for dynamic data structures.

Explanation: An MMS call to obtain more virtual memory failed.
Either your description file is too large or a system service failed
unexpectedly.
User Action: Try trimming your description file. If this fails,
consult your system manager about increasing the size of virtual
address space available to your system processes. If this fails,
submit a Software Performance Report (SPR).

Error Messages

A-17

UTLBADMAC, Unterminated macro name 'string.'

Explanation: The character combination $( was encountered
without a matching closing parenthesis. As a result, on the line
that contains the offending macro, all characters to the right of the
$( are ignored.
User Action: Correct the erroneous line.
UTLUNDERFLOW, Deallocation of unallocated space.

Explanation: This is an internal MMS error.
User Action: Collect as much information as possible and submit
a Software Performance Report (SPR).

A-18

Error Messages

Appendix B

MMS and UNIX make Comparisons

This appendix briefly compares the characteristics of MMS and the UNIX
Version 7 make utility. It is designed to ease the transition to MMS for
users already familiar with make.
Because VMS and UNIX are very different operating systems, certain
system-imposed changes were necessary to provide the features of make on
VMS. The experienced user of make will notice the following differences:
•

•

•
•

•

In the absence of a /DESCRIPTION or /NODESCRIPTION qualifier,
MMS looks first for the description file DESCRIP.MMS. It looks for
MAKEFILE. only if it cannot locate DESCRIP.MMS. If it cannot find
DESCRIP.MMS or MAKEFILE., it looks for target-name.MMS.
In the target or source line of a dependency rule, there must be at
least one space or tab on either side of the colon or double colon that
separates the list of targets from the list of sources. The space or tab
prevents MMS from trying to interpret the colon or colons as part of a
VMS file specification.
With MMS, you can use commas as well as spaces to separate the
elements in a list of targets or sources.
You can use either a number sign ( #) or an exclamation point ( ! ) as a
comment character. On target or source lines, as well as on blank lines
that separate dependency rules, you can use the number sign and the
exclamation point interchangeably; however, on action lines, you can use
only the exclamation point to indicate a comment.
In MMS, subprocesses are not executed independently of one another.
Therefore, it is possible to define logical names, change directories, and
in general manipulate the subprocess environment at will.
The dummy target .PRECIOUS, found in make, is not implemented
inMMS.

MMS and UNIX make Comparisons

B-1

•

•
•
•

•

When invoking a macro in MMS, you must enclose the macro name in
parentheses. That is, $(A) is a legal invocation of an MMS macro, but
$A is not.
MMS action lines may begin with either a space or a tab. MMS assumes
that any line that begins with a space or tab is an action line unless the
preceding line ends with a continuation character.
MMS has different built-in rules from those of make. See Table C-6 for
the format and contents of MMS built-in rules.
MMS requires you to separate the Silent ( @ ) and Ignore ( - ) action line
prefixes from the rest of the action line by at least one space.
In a description file, the line continuation character can be either a
hyphen ( - ) or a backslash ( \ ). On the MMS command line, only the
hyphen is legal.
In the specification of a VMS library module, you can use the question
mark (?) wildcard character as a synonym for the percent sign ( % )
wildcard character.
MMS has an optional format for dependency rules:
FROG.OBJ DEPENDS ON PROG.C
UTIL.LIB ADDITIONALLY DEPENDS ON MODl.OBJ

In this format, you can use DEPENDS_ON in place of the colon, and
ADDITIONALLY_DEPENDS_ON in place of the double colon.
For compatibility with make, MMS provides alternative formats for
dependency rules, user-defined rules, and directives, and recognizes
2-character abbreviations for special macros. The experienced user of make
will recognize the following make features in MMS:
•

MMS allows the following alternative format for dependency rules:
target . . .

•

[source . . .

] ; [action line . . .

]

In this format, the only legal comment character is an exclamation point
( ! ). You cannot use the Ignore ( - ) action line prefix with this format
because the hyphen is interpreted as a line continuation character.
MMS allows the following alternative format for user-defined rules:
. SRC. TAR : ; action line . . .

In this format, you must include at least one space or tab on each side
of the colon and the semicolon to prevent MMS from trying to interpret
the rule as a file specification. You cannot use the Ignore ( - ) action
line prefix with this format because the hyphen is interpreted as a line
continuation character.
B-2 MMS and UNIX make Comparisons

•
•
•

You can place a colon after the name of a directive. For example, you
can specify either .SILENT or .SILENT: in a description file.
The period preceding the .INCLUDE directive is optional.
You can abbreviate MMS special macros to two characters (see
Table C-3).

MMS and UNIX make Comparisons

B-3

Appendix C

MMS Built-In Features
This appendix contains tables of MMS built-in features, including the
default macros, the suffixes precedence list, and the built-in rules.
Chapter 2 contains detailed information about how these three features
work together in MMS.
The tables in this appendix are arranged as follows:
•
•
•
•
•
•

Table C-1 lists the default macros.
Table C-2 lists the changed default macros when you use the /SCA_
LIBRARY qualifier.
Table C-3 lists the special macros.
Table C-4 contains the suffixes precedence list.
Table C-5 lists and describes the directives used in a description file.
Table C-6 contains the standard built-in rules.

Section C. 7 describes the built-in rules for accessing VMS libraries.
Section C.8 lists the built-in rules that change when you use the /SCA_
LIBRARY qualifier. Section C.9 includes the built-in rules for accessing
CMS library elements.
For information on using MMS to create and access elements in VMS
libraries, see Section 4.1; in CMS libraries, see Section 4.2.

MMS Built-In Features C-1

C.1

Default Macros
MMS uses the default macros, shown in Table C-1, to build your system if
none are specified or redefined.
Table C-1:

MMS Default Macros'

Macro

Definition

ANLFLAGS

/OUTPUT=$(MMS$TARGET_NAME).ANL

MACRO

BASFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

BASIC

BFLAGS 1

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

BLIBFLAGS 1

/NO LIST

BLISS

BLISS16

BLISS/PDPll

CDDFLAGS
CFLAGS

null string
/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

CLDFLAGS

null string

CMS

CMSCOMMENT

null string

CMSFLAGS

/GEN=$(MMS$CMS_GEN)

COBFLAGS 1

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

COBOL

CORAL

CORFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

DBLFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

DIBOL

FFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

FMS

FMSFLAGS

/REPLACE

This default macro changes when you use the /SCA_LIBRARY qualifier. (See Table C-2.)

(continued on next page)

C-2

MMS Built-In Features

Table C-1 (Cont.):

MMS Default Macros

Macro

Definition

FORMS

FORMS_EXOBJ_
FLAGS

/NOLIST/OUTPUT=$(MMS$TARGET_NAME).OBJ

FORMS_TRANS_
FLAGS

/NOLIST/OUTPUT=$(MMS$TARGET_NAME).FORM

FORT

FORTRAN

LIBR

LIBRARY

LIBRFLAGS
LINK

/REPLACE
LINK .

LINKFLAGS

fTRACE/NOMAP/EXEC=$(MMS$TARGET_NAME).EXE

MACRO

MFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

MSGFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

PASCAL

PENVFLAGS
PFLAGS

/NO LIST

/NOLIST/OBJECT=$(MMS$TARGET_NAME);0BJ

PLI
PLIFLAGS

PLI
1

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

null string

RALFLAGS
RALLY

RALLY

RFLAGS

/OUTPUT=$(MMS$TARGET_NAME).OBJ

RPG

RPG FLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

RUNOFF

SCA

SCAFLAGS

/LOG

SCALIBRARY

SCAN
SCANFLAGS

Not defined
SCAN

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ

1 This default macro changes when you use the /SCA_LIBRARY qualifier.

(See Table C-2.)

MMS Built-In Features

C-3

C.2 Default Macro Changes with the /SCA_LIBRARY
Qualifiers
Table C-2 lists the default macro changes with the /SCA_LIBRARY
qualifier.
Table C-2:

The /SCA_LIBRARY Qualifiers Default Macros

Macro

Definition

SCA

SCALIBRARY

Library name from the /SCA_LIBRARY qualifier

BAS FLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_
DATA=$(MMS$TARGET_NAME).ANA

BFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_
DATA=$(MMS$TARGET_NAME).ANA

BLIBFLAGS

/NOLIST/ANALYSIS_DATA=$(MMS$TARGET_NAME).ANA

CFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_
DATA=$(MMS$TARGET_NAME).ANA

COBFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).0BJ/ANALYSIS_
DATA=$(MMS$TARGET_NAME).ANA

FFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_
DATA=$(MMS$TARGET_NAME).ANA

MFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_
DATA=$(MMS$TARGET_NAME).ANA

PFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_
DATA=$(MMS$TARGET_NAME).ANA

PLIFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).0BJ/ANALYSIS_
DATA=$(MMS$TARGET_NAME).ANA

SCANFLAGS

/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_
DATA=$(MMS$TARGET_NAME).ANA

C.3 Special Macros
Table C-3 lists the MMS special macros and describes their functions. The
table also lists a symbol that you can use as an abbreviation for each macro.

C-4 MMS Built-In Features

Table C-3:

MMS Special Macros

Macro

Symbol

Meaning

MMS$TARGET

Expands to the mnemonic name or the
complete file specification of the target
currently being updated.

MMS$TARGET_NAME

Expands to the mnemonic name or the file
name (excluding the file type) of the target
being updated. The device, directory, and
node information are included.

MMS$SOURCE

Expands to the source file specification.

MMS$SOURCE_LIST

Expands to a comma list of the full file
specifications of all sources specified
in this dependency rule, including any
sources implied by built-in rules.

MMS$CHANGED_LIST

Expands to a comma list of the full file
specifications of all sources that have
changed since the target was updated,
including any sources implied by built-in
rules.

MMS$LIB_ELEMENT

Expands to the name of a module in a
VMS library and its file name, including
the file type (see Section 4.1).

MMS$CMS_ELEMENT

Expands to the implicit CMS element
specification (if the source file is a CMS
element).

MMS$CMS_GEN

Expands to the CMS generation specified
by the source file (if the source is a CMS
element).

MMS$CMS_LIBRARY

Expands to the CMS library specification
(if the source is a CMS element).

MMS Built-In Features C-5

C.4 Suffixes Precedence List
Table C-4 provides the MMS suffixes precedence list.
Table C-4:
.SUFFIXES

Suffixes Precedence List
.ANL .EXE .OLB .MLB .HLB .TLB .FLB .OBJ .FORM
.BLI .B32 .C .COB .FOR .BAS .B16 .PLI .PEN .PAS
.MAC .MAR .CLD .MSG .COR .DBL .RPG .SCN .IFDL
.RBA.RC.RCO.RFO.RPA.SC.SCO.SFO.SPA.SPL
.SQLMOD .RGK .RGC .MEM .RNO .HLP .RNH .L32
.REQ .R32 .Ll6 .R16 .TXT .H .FRM .MMS .DDL .COM
.DAT .OPT .CDO .SDML .ADF .GDF .LDF .MDF .RDF
.TDF .ADF- 1 .ANL- .B16- .B32- .BAS- .BLI- .C.CDO- .CLD- .COB- .COM- .COR- .DAT- .DBL.DDL- .FOR- .FRM- .GDF- .HLP- .H- .IFDL- .LDF.MAC- .MAR- .MDF- .MMS- .MSG- .OPT- .PAS.PL!- .R16- .R32- .RBA- .RC- .RCO- .RDF- .REQ.RFO- .RGC- .RNH- .RNO- .RPA- .RPG- .SC- .SCN.SCO- .SDML- .SFO- .SPA- .SPL- .SQLMOD- .TDF.TXT-

1A tilde ( - ) after a file type indicates that the file is in a CMS library. See Section 4.2 for
information on using MMS to access CMS elements.

C.5 Directives
Table C-5 lists and describes all the MMS directives.
Table C-5:

MMS Directives

Directive

Function

.DEFAULT

Indicates actions to be performed if MMS built-in rules
or user-defined rules do not specify how to update a
target.

.ELSE

Causes subsequent lines of a description file to be
processed if the specified macro for the .IFDEF directive
is undefined.

(continued on next page)

C-6

MMS Built-In Features

Table C-5 (Cont.):

MMS Directives

Directive

Function

.ENDIF

Terminates the set of lines in the description file whose
processing is controlled by .IFDEF or .ELSE .

.FIRST

Indicates actions to be performed before MMS has
executed any action lines to update the target .

.IFDEF

Causes subsequent lines of a description file to be
processed only if the specified macro is defined .

.IGNORE

Causes MMS to ignore all errors generated by all action
lines and to continue processing the description file .

.INCLUDE

Includes the specified file in the description file .

.LAST

Indicates actions to be performed after MMS has executed all the action lines that update the target .

.SILENT

Suppresses the writing of all action lines to the output
file (whether to SYS$0UTPUT or to the file specified by
the /OUTPUT qualifier) .

.SUFFIXES

Clears, adds to, or redefines the suffixes precedence list.

C.6 Built-In Rules
Table C-6 lists the sources, targets, and actions for the MMS built-in rules.
Table C-6:

MMS Built-In Rules

Source

Target

Action

.B16 1

.OBJ

$(BLISS16) $(BFLAGS) $(MMS$SOURCE)

.B32 1

.OBJ

$(BLISS) $(BFLAGS) $(MMS$SOURCE)

.OBJ

$(BASIC) $(BASFLAGS) $(MMS$SOURCE)

.BAS
.BLI

.OBJ

$(BLISS) $(BFLAGS) $(MMS$SOURCE)

.c1

.OBJ

$(CC) $(CFLAGS) $(MMS$SOURCE)

.CLD

.OBJ

SET COMMAND /OBJECT=$(MMS$TARGET_NAME)

1The use of the /SCA_LIBRARY qualifier changes some of these built-in rules. See Section C.8
for a list of rules changes.

(continued on next page)

MMS Built-In Features

C-7

Table C-6 (Cont.):
Source

Target

MMS Built-In Rules
Action
$(CLDFLAGS) $(MMS$SOURCE)

.COB

.COR

.OBJ

$(COBOL) $(COBFLAGS) $(MMS$SOURCE)

.OBJ

$(CORAL) $(CORFLAGS) $(MMS$SOURCE)

.DBL

.OBJ

$(DIBOL) $(DBLFLAGS) $(MMS$SOURCE)

.EXE

.ANL

ANALYZE/IMAGE $(ANLFLAGS) $(MMS$SOURCE)

.FOR 1

.OBJ

$(FORT) $CFFLAGS) $(MMS$SOURCE)

.FORM

.OBJ

$(FORMS) EXTRACT OBJECT $(FORMS_EXOBJ_FLAGS)
$(MMS$SOURCE)

.IFDL

.FORM

$(FORMS) TRANSLATE $(FORMS_TRANS_FLAGS)
$CMMS$SOURCE)

.MAC

.OBJ

$(MACRO) $(MFLAGS) $(MMS$SOURCE)

.MAR1

.OBJ

$(MACRO) $(MFLAGS) $(MMS$SOURCE)

.MSG

.OBJ

MESSAGE $(MSGFLAGS) $(MMS$SOURCE)

.OBJ

.ANL

ANALYZE/OBJECT $CANLFLAGS) $(MMS$SOURCE)

.OBJ

.EXE

$(LINK) $CLINKFLAGS) $(MMS$SOURCE)

.OBJ

$(PASCAL) $(PFLAGS) $(MMS$SOURCE)

.PAS

.PEN

$(PASCAL) /ENVIRON=$(MMS$TARGET)

.PLI 1

.OBJ

$(PLI) $(PLIFLAGS) $(MMS$SOURCE)

.Rl6

.L16

$(BLISS16) /LIBRARY=$(MMS$TARGET)

.R32

.L32

$(BLISS) /LIBRARY=$(MMS$TARGET)

.REQ1

.L32

$(BLISS) /LIBRARY=$(MMS$TARGET)

.RGC

.RGK

$(RALLY) DEFINE KEYS $CRALFLAGS) $(MMS$SOURCE)
$(MMS$TARGET)

.RNH

.HLP

$(RUNOFF) $CRFLAGS) $(MMS$SOURCE)

.RNO

.MEM

$(RUNOFF) $(RFLAGS) $(MMS$SOURCE)

.PAS

$(PENVFLAGS) $(MMS$SOURCE)

$(BLIBFLAGS) $(MMS$SOURCE)
.RPG

.OBJ

$(RPG) $(RPGFLAGS) $(MMS$SOURCE)
$CBFLAGS) $(MMS$SOURCE)

1
The use of the /SCA_LIBRARY qualifier changes some of these built-in rules. See Section C.8
for a list of rules changes.

(continued on next page)
C-8 MMS Built-In Features

Table C-6 {Cont.):
Source

Target

MMS Built-In Rules
Action
$(BFLAGS) $(MMS$SOURCE)

.SCN

.OBJ

$(SCAN) $(SCANFLAGS) $(MMS$SOURCE)

1The use of the /SCA_LIBRARY qualifier changes some of these built-in rules. See Section C.8
for a list of rules changes.

C.7 Built-In Rules for Library Files
The following example shows how to build a help library:
.HLP.HLB
IF "''F$SEARCH("$(MMS$TARGET)")'" .EQS. 1111 THEN $(LIBR)/CREATE/HELP $(MMS$TARGET)
$(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)

The following example shows how to build a macro library:
.MAR.MLB
IF 11 ''F$SEARCH("$(MMS$TARGET)")'" .EQS. 1111 THEN $(LIBR)/CREATE/MAC $(MMS$TARGET)
$(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
.MAC.MLB
IF '"'F$SEARCH( 11 $(MMS$TARGET) 11 ) ' 11 .EQS. 1111 THEN $(LIBR)/CREATE/MAC $(MMS$TARGET)
$(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)

The following example shows how to build an object library:
.OBJ.OLB
IF '" 'F$SEARCH("$ (MMS$TARGET) 11 ) I " .EQS. "" THEN $(LIBR)/CREATE $(MMS$TARGET)
$(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
.TXT.TLB
IF "' 'F$SEARCH("$ (MMS$TARGET) ")I" .EQS. "" THEN $(LIBR)/CREATE/TEXT $(MMS$TARGET)
$(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)

The following example shows how to build a FMS library:
.FRM.FLB
IF "' 'F$SEARCH ("$ (MMS$TARGET) ")I" .NES. "" THEN $(FMS)/LIBRARY $(FMSFLAGS) $(MMS$TARGET) $(MMS$SOURCE)
IF "' 'F$SEARCH("$ (MMS$TARGET) ")I" .EQS. "" THEN $(FMS)/LIBRARY/CREATE $(MMS$TARGET) $(MMS$SOURCE)

MMS Built-In Features C-9

C.8 Built-In Rules for the /SCA_LIBRARY Qualifier
This section lists the changes to built-in rules when you use the /SCA_
LIBRARY qualifier.
. BAS.OBJ :
$(BASIC) $(BASFLAGS) $(MMS$SOURCE)
mrns$scalib = F$TRNLNM( 11 SCA$LIBRARY 11
mrns$scasetlib = 0
IF mms $ scalib . EQS. 11 11 • AND. 11 $ ( SCALIBRARY) 11 • NES. 11 SCA$LIBRARY: 11 THENmms $ scasetlib = 2
IF mms$scalib .NES. 1111 .AND. 11 $ (SCALIBRARY) 11 .NES. 11 SCA$LIBRARY: 11 .AND.mms$scalib .NES. 11 $(SCALIBRARY) 11 THEN mrns$scasetlib = 3
IF F$SEARCH( 11 $(SCALIBRARY)SCA$EVENT.DAT 11 ) .EQS. 1111 THEN mms$scasetlib = (mrns$scasetlib .AND . . NOT. 2) .OR. 4
IF (mms$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY)
IF (mms$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) $(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET NAME) .ANA
IF mrns$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) 'mrns$scalib'
.BLI.OBJ :
$(BLISS) $(BFLAGS) $(MMS$SOURCE)
mrns$scalib = F$TRNLNM( 11 SCA$LIBRARY 11
mrns$scasetlib = 0
IF mrns$scalib .EQS. 1111 .AND. 11 $ (SCALIBRARY) 11 .NES. 11 SCA$LIBRARY: 11 THEN rnms$scasetlib = 2
IF mrns$scalib .NES. 1111 .AND. 11 $ (SCALIBRARY) 11 .NES. 11 SCA$LIBRARY: 11 .AND. rnrns$scalib .NES. 11 $(SCALIBRARY) 11 THEN mrns$scasetlib = 3
IF F$SEARCH( 11 $(SCALIBRARY)SCA$EVENT.DAT 11 ) .EQS. '"'THEN rnrns$scasetlib = (mrns$scasetlib .AND . . NOT. 2) .OR. 4
IF (mrns$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY)
IF (mrns$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) $(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET NAME) .ANA
IF mrns$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) 'mrns$scalib'
.B32.0BJ :
$(BLISS) $(BFLAGS) $(MMS$SOURCE)
mms$scalib = F$TRNLNM( 11 SCA$LIBRARY 11
mms$scasetlib = 0
IF mrns$scalib .EQS. 1111 .AND. 11 $ (SCALIBRARY) 11 .NES. 11 SCA$LIBRARY: 11 THEN rnrns$scasetlib = 2
IF mrns$scalib .NES. 1111 .AND. 11 $ (SCALIBRARY) 11 .NES. 11 SCA$LIBRARY: 11 .AND. rnrns$scalib .NES. 11 $(SCALIBRARY) 11 THEN mrns$scasetlib = 3
IF F$SEARCH( 11 $(SCALIBRARY)SCA$EVENT.DAT 11 ) .EQS. '"'THEN rnrns$scasetlib = (mrns$scasetlib .AND . . NOT. 2) .OR. 4
IF (mrns$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY)
IF (mms$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) $(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET NAME) .ANA
IF mms$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) 'mrns$scalib'

C-10

MMS Built-In Features

.C.OBJ :
$(CC) $(CFLAGS) $(MMS$SOURCE)
mms$scalib = F$TRNLNM( 11 SCA$LIBRARY 11
mms$scasetlib = 0
IF mms$scalib .EQS. 1111 .AND. "$ (SCALIBRARY)" .NES. "SCA$LIBRARY:" THEN mms$scasetlib = 2
IF mms$scalib .NES. "" .AND. "$ (SCALIBRARY)" .NES. "SCA$LIBRARY:" .AND. mms$scalib .NES. "$(SCALIBRARY)" THEN mms$scasetlib = 3
IF F$SEARCH ( 11 $ (SCALIBRARY) SCA$EVENT. DAT") .EQS. '"' THEN mms$scasetlib = (mms$scasetlib .AND . . NOT. 2) .OR. 4
IF (mms$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS)
$(SCALIBRARY)
IF (mms$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS)
$(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET NAME) .ANA
IF mms$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) 'mms$scalib'
.COB.OBJ :
$(COBOL) $(COBFLAGS) $(MMS$SOURCE)
mms$scalib = F$TRNLNM( "SCA$LIBRARY"
mms$scasetlib = 0
IF mms$scalib .EQS. 1111 .AND. 11 $ (SCALIBRARY)" .NES. "SCA$LIBRARY:" THEN mms$scasetlib = 2
IF nuns$scalib .NES. 1111 .AND. 11 $(SCALIBRARY) 11 .NES. 11 SCA$LIBRARY:" .AND. mms$scalib .NES. 11 $(SCALIBRARY) 11 THEN mms$scasetlib = 3
IF F$SEARCH("$(SCALIBRARY)SCA$EVENT.DAT 11 ) .EQS. 1111 THEN mms$scasetlib = (mms$scasetlib .AND . . NOT. 2) .OR. 4
IF ((mms$scasetlib .AND. 4) .EQ. 4) THEN SPAWN/WAIT/NOSYMBOLS $(SCA) CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY)
IF ((mms$scasetlib .AND. 4) .EQ. 4) .OR. ((nuns$scasetlib .AND. 2) .EQ. 2) THEN DEFINE/USER SCA$LIBRARY $(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET_NAME) .ANA
.FOR.OBJ :
$(FORT) $(FFLAGS) $(MMS$SOURCE)
mms$scalib = F$TRNLNM( 11 SCA$LIBRARY"
mms$scasetlib = 0
IF mms$scalib .EQS. 1111 .AND. 11 $ (SCALIBRARY)" .NES. "SCA$LIBRARY:" THEN mms$scasetlib = 2
IF mms$scalib .NES. 1111 .AND. "$ (SCALIBRARY) 11 .NES. 11 SCA$LIBRARY:" .AND. mms$scalib .NES. 11 $(SCALIBRARY) 11 THEN nuns$scasetlib = 3
IF F$SEARCH ( 11 $ (SCALIBRARY) SCA$EVENT. DAT") . EQS. 1111 THEN mms$scasetlib = (mms$scasetlib .AND . . NOT. 2) .OR. 4
IF (mms$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY)
IF (nuns$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) $(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET NAME) .ANA
IF mms$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) 'nuns$scalib'

MMS Built-In Features

C-11

.MAR.OBJ :
$(MACRO) $(MFLAGS) $(MMS$SOURCE)
mms$scalib = F$TRNLNM( "SCA$LIBRARY"
mms$scasetlib = 0
IF mms$scalib .EQS. "" .AND. "$ (SCALIBRARY)" .NES. "SCA$LIBRARY:" THEN mrns$scasetlib = 2
IF mms$scalib .NES. "" .AND. "$ (SCALIBRARY)" .NES. "SCA$LIBRARY:" .AND. mrns$scalib .NES. "$(SCALIBRARY)" THEN rruns$scasetlib = 3
IF F$SEARCH("$(SCALIBRARY)SCA$EVENT.DAT") .EQS. "" THEN mrns$scasetlib = (rruns$scasetlib .AND . . NOT. 2) .OR. 4
IF (rruns$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY)
IF (rruns$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) $(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET NAME) .ANA
IF rruns$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) 'rruns$scalib'
.PAS.OBJ :
$(PASCAL) $(PFLAGS) $(MMS$SOURCE)
mms$scalib = F$TRNLNM( "SCA$LIBRARY"
mms$scasetlib = 0
IF rruns$scalib .EQS. '"' .AND. "$(SCALIBRARY)" .NES. "SCA$LIBRARY:" THEN mrns$scasetlib = 2
IF rruns$scalib .NES. "" .AND. "$ (SCALIBRARY)" .NES. "SCA$LIBRARY:" .AND. mrns$scalib .NES. "$(SCALIBRARY)" THEN rruns$scasetlib = 3
IF F$SEARCH("$(SCALIBRARY)SCA$EVENT.DAT") .EQS. ""THEN mms$scasetlib = (rruns$scasetlib .AND . . NOT. 2) .OR. 4
IF (mms$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY)
IF (mms$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) $(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET NAME) .ANA
IF rruns$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) 'rruns$scalib'
.PLI.OBJ :
$(PLI) $(PLIFLAGS) $(MMS$SOURCE)
mms$scalib = F$TRNLNM( "SCA$LIBRARY"
rruns$scasetlib = O
IF mms$scalib .EQS. "" .AND. "$(SCALIBRARY)" .NES. "SCA$LIBRARY:" THEN mms$scasetlib = 2
IF rruns$scalib .NES. "" .AND. "$ (SCALIBRARY)" .NES. "SCA$LIBRARY:" .AND. mms$scalib .NES. "$(SCALIBRARY)" THEN rruns$scasetlib = 3
IF F$SEARCH("$(SCALIBRARY)SCA$EVENT.DAT") .EQS. ""THEN mms$scasetlib = (mms$scasetlib .AND . . NOT. 2) .OR. 4
IF (mms$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY)
IF (mms$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) $(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET NAME) .ANA
IF rruns$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) 'rruns$scalib'

C-12

MMS Built-In Features

.REQ.L32 :
$(BLISS)/LIBRARY=$(MMS$TARGET) $(BLIBFLAGS) $(MMS$SOURCE)
mms$scalib = F$TRNLNM( 11 SCA$LIBRARY 11 )
mms$scasetlib = 0
IF mms$scalib .EQS. 1111 .AND. 11 $ (SCALIBRARY) 11 .NES. 11 SCA$LIBRARY: 11 THEN mms$scasetlib = 2
IF mms$scalib .NES. 1111 .AND. 11 $ (SCALIBRARY) 11 .NES. "SCA$LIBRARY:" .AND. mms$scalib .NES. "$(SCALIBRARY) 11 THEN mms$scasetlib = 3
IF F$SEARCH( 11 $ (SCALIBRARY)SCA$EVENT.DAT 11 ) .EQS. 1111 THEN mms$scasetlib = (mms$scasetlib .AND . . NOT. 2) .OR. 4
IF (mms$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY)
IF (mms$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) $(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET NAME) .ANA
IF mms$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) 'mms$scalib'
.R32.L32 :
$(BLISS)/LIBRARY=$(MMS$TARGET) $(BLIBFLAGS) $(MMS$SOURCE)
mms$scalib = F$TRNLNM ( 11 SCA$LIBRARY 11 )
mms$scasetlib = 0
IF mms$scalib .EQS. 1111 .AND. 11 $(SCALIBRARY) 11 .NES. 11 SCA$LIBRARY:" THEN mms$scasetlib = 2
IF mms$scalib .NES. 1111 .AND. 11 $ (SCALIBRARY) 11 .NES. 11 SCA$LIBRARY:" .AND. mms$scalib .NES. 11 $(SCALIBRARY) 11 THEN mms$scasetlib = 3
IF F$SEARCH( 11 $(SCALIBRARY)SCA$EVENT.DAT 11 ) .EQS. 11 " THEN mms$scasetlib = (mms$scasetlib .AND . . NOT. 2) .OR. 4
IF (mms$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY)
IF (mms$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) $(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET NAME) .ANA
IF mms$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) 'mms$scalib'
.SCN.OBJ :
$(SCAN) $(SCANFLAGS) $(MMS$SOURCE)
mms$scalib = F$TRNLNM( 11 SCA$LIBRARY 11
mms$scasetlib = 0
IF mms$scalib .EQS. 1111 .AND. "$ (SCALIBRARY)" .NES. "SCA$LIBRARY:" THEN mms$scasetlib = 2
IF mms$scalib .NES. 1111 .AND. "$ (SCALIBRARY)" .NES. "SCA$LIBRARY:" .AND. mms$scalib .NES. "$(SCALIBRARY)" THEN mms$scasetlib = 3
IF F$SEARCH ( "$ (SCALIBRARY) SCA$EVENT. DAT") . EQS. 1111 THEN mms$scasetlib = (mms$scasetlib .AND . . NOT. 2) .OR. 4
IF ((mms$scasetlib .AND. 4) .EQ. 4) THEN SPAWN/WAIT/NOSYMBOLS $(SCA) CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY)
IF ((mms$scasetlib .AND. 4) .EQ. 4) .OR. ((mms$scasetlib .AND. 2) .EQ. 2) THEN DEFINE/USER SCA$LIBRARY $(SCALIBRARY)
$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET_NAME) .ANA

MMS Built-In Features C-13

C.9 Built-In Rules for CMS Access
This section lists the built-in rules for CMS access. A tilde (,...) after a file
type indicates that the file is in a CMS library.
. ANL-.ANL :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .ANL $(CMSFLAGS) $(CMSCOMMENT)
.ADF-.ADF :
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .ADF $(CMSFLAGS) $(CMSCOMMENT)
.B16-.B16 :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .B16 $(CMSFLAGS) $(CMSCOMMENT)
.B32-.B32 :
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .B32 $(CMSFLAGS) $(CMSCOMMENT)
.BAS-.BAS :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .BAS $(CMSFLAGS) $(CMSCOMMENT)
.BLI-.BLI :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .BLI $(CMSFLAGS) $(CMSCOMMENT)

.c-.c
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .c $(CMSFLAGS) $(CMSCOMMENT)
.CLD-.CLD :
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .CLD $(CMSFLAGS) $(CMSCOMMENT)
.COB-.COB
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .COB $(CMSFLAGS) $(CMSCOMMENT)

C-14

MMS Built-In Features

.COR-.COR :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .COR $(CMSFLAGS) $(CMSCOMMENT)
.COM-.COM
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .COM $(CMSFLAGS) $(CMSCOMMENT)
.DAT-.DAT
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .DAT $(CMSFLAGS) $(CMSCOMMENT)
.DBL-.DBL
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .DBL $(CMSFLAGS) $(CMSCOMMENT)
.DDL-.DDL
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .DDL $(CMSFLAGS) $(CMSCOMMENT)
.FOR-.FOR
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .FOR $(CMSFLAGS) $(CMSCOMMENT)
.FRM-.FRM
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .FRM $(CMSFLAGS) $(CMSCOMMENT)
.GDF-.GDF
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .GDF $(CMSFLAGS) $(CMSCOMMENT)
.H-.H
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(~.MS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .H $(CMSFLAGS) $(CMSCOMMENT)
.HLP-.HLP
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .HLP $(CMSFLAGS) $(CMSCOMMENT)

MMS Built-In Features

C-15

.IFDL-.IFDL :
IF "$(MMS$CMS LIBRARY)" .NES. ""THEN DEFINE/USER CMS$LIB $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .IFDL $(CMSFLAGS) $(CMSCOMMENT)
.LDF-.LDF :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .LDF $(CMSFLAGS) $(CMSCOMMENT)
.MAC-.MAC :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .MAC $(CMSFLAGS) $(CMSCOMMENT)
.MAR-.MAR :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .MAR $(CMSFLAGS) $(CMSCOMMENT)
.MDF-.MDF :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .MDF $(CMSFLAGS) $(CMSCOMMENT)
.MMS-.MMS :
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .MMS $(CMSFLAGS) $(CMSCOMMENT)
.MSG-.MSG :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .MSG $(CMSFLAGS) $(CMSCOMMENT)
.OPT-.OPT :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .OPT $(CMSFLAGS) $(CMSCOMMENT)
.PAS-.PAS :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .PAS $(CMSFLAGS) $(CMSCOMMENT)
.PLI-.PLI :
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .PL! $(CMSFLAGS) $(CMSCOMMENT)

C-16

MMS Built-In Features

.R16-.R16 :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .R16 $(CMSFLAGS) $(CMSCOMMENT)
.R32-.R32
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .R32 $(CMSFLAGS) $(CMSCOMMENT)
.RBA-.RBA
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .RBA $(CMSFLAGS) $(CMSCOMMENT)
.RC-.RC
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .RC $(CMSFLAGS) $(CMSCOMMENT)
.RCO-.RCO
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .RCO $(CMSFLAGS) $(CMSCOMMENT)
.REQ-.REQ
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .REQ $(CMSFLAGS) $(CMSCOMMENT)
.RFO-.RFO
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).RFO $(CMSFLAGS) $(CMSCOMMENT)
.RGC-.RGC
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .RGC $(CMSFLAGS) $(CMSCOMMENT)
.RNH-.RNH
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .RNH $(CMSFLAGS) $(CMSCOMMENT)
.RNO-.RNO
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME).RNO $(CMSFLAGS) $(CMSCOMMENT)

MMS Built-In Features

C-17

.RPA-.RPA :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .RPA $(CMSFLAGS) $(CMSCOMMENT)
.RPG-.RPG
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .RPG $(CMSFLAGS) $(CMSCOMMENT)

.sc-.sc
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .SC $(CMSFLAGS) $(CMSCOMMENT)
.SCN-.SCN
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .SCN $(CMSFLAGS) $(CMSCOMMENT)

.sco-.sco
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .sco $(CMSFLAGS) $(CMSCOMMENT)
.SFO-.SFO
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .SFO $(CMSFLAGS) $(CMSCOMMENT)
.SDML-.SDML :
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .SDML $(CMSFLAGS) $(CMSCOMMENT)
.SPA-.SPA
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .SPA $(CMSFLAGS) $(CMSCOMMENT)
.SPL-.SPL
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .SPL $(CMSFLAGS) $(CMSCOMMENT)
.SQLMOD-.SQLMOD :
IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .SQLMOD $(CMSFLAGS) $(CMSCOMMENT)

C-18

MMS Built-In Features

.TDF-.TDF :
IF nuns$cmslib .nes. "$(MMS$CMS LIBRARY)" THEi.~ $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .TDF $(CMSFLAGS) $(CMSCOMMENT)
.TXT-.TXT
IF nuns$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY $(MMS$CMS LIBRARY)
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$(MMS$TARGET_NAME) .TXT $(CMSFLAGS) $(CMSCOMMENT)

MMS Built-In Features C-19

Glossary

action

A command-language command that MMS executes to update a target.
(See also action line.)
action line

The part of the dependency rule that contains the commands that tell
MMS how to use the source or sources to update the target. (See also
dependency rule.)
action line prefix

A special character placed at the beginning of an action line that
influences how MMS executes the action. (See also action line.)
built-in rule

A command that MMS uses when the description file does not explicitly
describe the processing needed to update a target.
default macro

A name that represents a character string that defines commonly used
operations. MMS built-in rules are expressed in terms of default macros.
(See also built-in rule and macro.)
dependency rule

The description of a relationship between a target and one or more
sources, and the action or actions required to update the target.
Dependency rules are contained in the description file. (See also
description file.)

Glossary-1

description file

A text file that contains the dependency rules, comments, macros, and
directives that MMS uses to build your system. (See also dependency
rule, directive, and macro.)
directive

A word that specifies an action for the processing of the description file.
included file

A shared file used during software development that contains code or
constant declarations.
library module specification

A VMS file specification for a module in a library.
macro

A name that represents a character string. The string is substituted for
the name in a dependency rule.
macro invocation

The execution of the macro that replaces the macro name with its
definition.
mnemonic name

A name that identifies the purpose of a sequence of related actions. It
can be used as either a source or a target in the description file. (See
also source and target.)
object library

A single file that contains multiple object files. (See also object module.)
object module

One or more object files that comprise an object library.
source

In a dependency rule, an entity that is used to create or to update the
target. A source can be a VMS file specification or a mnemonic name.
(See also dependency rule and mnemonic name.)

Glossary-2

special macro

A name that represents a character string that expands to source or
target names in the dependency currently being processed. A special
macro is used instead of a target or source file specification when writing
general user-defined rules. (See also dependency rule, macro, and
target.)
suffixes precedence list

A list of file types to which MMS refers when it needs to know which
source file can update the specified target.
target

In a description file, the entity that is to be updated. A target can be a
VMS file specification or a mnemonic name. (See also mnemonic name.)
user-defined rule

A rule that the user specifies in the description file to add to and/or
replace MMS built-in rules. (See also built-in rule.)

Glossary-3

Index
A
Action line, 2-3, 2-22
command procedures, 2-28
comments, 2-24
definition of, 1-4
effect of /ACTION on, CD-4
errors, 2-29
example, 2-22
format of, 2-3
multiple, 2-2, 2-23
multiple objects, 2-22
omitting source, 2-6
precedence, 2-22
restriction, A-9
restrictions on, 2-27
suppression of display, 2-27
Action line prefixes
see also individual prefix
directives
difference between, 2-26
format of, 2-25
ignore ( - }, 2-26
silent (@ } , 2-27
/ACTION qualifier, CD-4
ADDITIONALLY_DEPENDS_ON
in dependency rules, 3-2
ASTLM, 3-5
/AUDIT qualifier, 4-21, CD-5, A-2

B
Backslash
continuation character, 8-2
Building software systems, 1-6 to 1-18
See also Software system

Built-in macro, 3-7
Built-in rule, 2-6, 2-8 to 2-18, 2-33, CD-14, B-2
default macros, 2-12
definition of, 1-5
example of, 2-8, 2-11
for CMS libraries, C-14
for libraries, C-9
for library files
table, C-9
linking objects, 1-9
modifying, 3-17
override, 2-8
table, C-7
with /SCA_LIBRARY, C-10
BYTLM, 3-5

c
Callable CMS, A-3
Caret format
See up-arrow character
COD, 4-1
definition
syntax of, 4-21
history list, 4-21
path specification, 4-21
record, CD-5, A-3
CDDFLAGS default macro, 4-22
COD/Plus
access
restrictions, 4-22
definitions
access to, 4-21
record, A-3
CFLAGS
default macro, 2-17, 4-18

lndex-1

/CHANGED qualifier, CD-5
Checkpoint file, 3-12
/CHECK_STATUS qualifier, CD-5
precedence, CD-5
Child process, 2-25
CU symbol, 3-7, 3-8
CU symbol table, CD-13
CLISYMTBL
SYSGEN parameter, A-17
CMS, 2-36, 3-14, 4-4
access to single element, 4-18
building from current generations, 4-13
callable, A-3
class
specifying, 4-13
commands
in gescription files, 4-6
elements
access restriction, 4-8
automatic access of, 4-6
explicit references to, 4-7
including with .INCLUDE, 4-18
library specfication, 4-8
specifying, 4-7
.INCLUDE directive, 4-18
libraries, 4-1
access to, 4-4, A-3
built-in rules for, C-14
rules, 4-18, CD-6
user-defined rules, 4-18
using with MMS, 4-4
CMS$LIB logical name, 4-6
CMSCOMMENT default macro, 4-18
CMSFLAGS default macro, 4-6, 4-7, 4-13, 4-18
redefining, 4-7
CMS INSERT command, 4-17
/CMS qualifier, 3-19, 4-6, 4-7, 4-19, CD-6
/GENERATION, 4-13
CMS SET LIBRARY, 4-6
CMSWAIT, A-5
Colon, 2-2
Command procedure, 3-6
generated with /OUTPUT, CD-12
invoke
from description file, 3-9
invoking MMS, 3-6
Comment character ( ! }, B-1
Comment character(#}, B-1
restriction, B-1
Comment line, 2-3, 2-4, 2-24
Concepts of MMS, 1-3 to 1-6

lndex-2

Continuation character
backslash, B-2
hyphen, 2-3, 2-4, 2-13, A-15
hyphen(-}, B-2
Continuation character(-}, B-2

D
DCL commands, 2-28
DCL severity levels, CD-9
DCL symbol, 3-9, 3-14
DCL WAIT, 3-4
/DEBUG qualifier
compiling with, 2-17
.DEFAULT directive, 2-32, 3-12
overriding, 2-33
Default macro, 2-12, 3-7
CDDFLAGS, 4-22
CMSCOMMENT, 4-18
CMSFLAGS, 4-7, 4-13
FMSFLAGS, 4-20
LINK, 2-21
LINKFLAGS, 2-21
redefine
example, 2-17
redefining, 2-17
table, C-2
table of, C-2
with /SCA_LIBRARY
table, C-4
$DELPRC system service, A-8
Dependencies, 1-5
definition of, 1-3
in a single source system
figure, 1-5
Dependency rule, 2-2
action lines, 2-2
ADDITIONALLY_DEPENDS_ON, 3-2
alternative format for, B-2
circular dependency restriction, A-11
comments in, 2-3
continuing, 2-3
example, 2-3
double-colon in, 3-1, 3-2, A-1 O
format, 2-2
implied, 2-9, 2-20
multiple dependencies, 3-1
optional format, B-2
source, 2-2
omitting, 2-9
tab restriction, B-1

Dependency rule (Cont.)
target, 2-2
Dependency tree, 1-6
DEPENDS_ON, 2-2
DESCRIP.MMS, CD-3, 8-1
Description file, 2-1 to 2-42
advanced techniques, 3-1
built-in rules, 2-11
CMS commands in, 4-6
concatenated, CD-7
creation of, 2-1
definition of, 1-3
dependencies in, 1-3
elements, 2-1
action lines, 2-1
built-in rules, 2-1
comment lines, 2-1
directives, 2-1
user-defined rules, 2-1
example of, 2-11
in CMS libraries, 4-19
invoking, 2-1
invoking command procedures, 3-9
invoking MMS from, 3-3
.SUFFIXES
example, 2-34
/DESCRIPTION qualifier, 4-19, CD-6, B-1
Diagnostic messages
See Error messages
DIFFERENCES utility, 2-24
Directives, 2-28
see also individual directives
.DEFAULT, 2-32
.ELSE, 2-40
.ENDIF, 2-41
.FIRST, 2-38
.IFDEF, 2-40
.IGNORE, 2-29
.INCLUDE, 2-37
.LAST, 2-39
.SILENT, 2-31
.SUFFIXES, 2-33
table, 2-28, C-6
Double colon
in dependency rules, 3-2

Error message (Cont.)
COD, A-2
fatal, 2-25, A-1
severity level, A-1
warning, 2-25, A-1
Error messages, A-2 to A-18
EXIT DCL command, 2-28

F
Fatal error, 2-25, CD-10
Fatal message, A-1
File
access in SCA library, 4-22
deleting, 3-17
intermediate, CD-16
protection, A-13
specifications
library modules, 3-3
types, 2-33
adding new, 2-34
built-in rule, 2-8
null, 2-37
precedence, 2-34
File.checkpoint
See checkpoint file
File.included
See included file
FILLM, 3-5
quota, 2-38
.FIRST directive, 2-38
example of, 2-38
FMSFLAGS default macro, 4-20
FMS forms
access to, 4-20
syntax of, 4-20
FMS libraries, 4-1 , A-6
/FORCE qualifier, CD-8
/FROM_SOURCES qualifier, CD-8
precedence, CD-9

G
/GENERATION CMS qualifier, 4-6, 4-13, A-3
GOTO DCL command, 2-28

.ELSE directive, 2-40
.ENDIF directive, 2-41, A-15
Error message, 3-5, A-1

Help
getting, 1-3
HELP library, CD-9

lndex-3

/HELP qualifier, CD-9, A-3
Hierarchy of rule application, 2-7

/IDENTIFICATION qualifier, CD-9, A-14
.IFDEF directive, 2-40, A-15
.IGNORE directive, 2-29, CD-10
overriding, 2-31
Ignore prefix(-), 2-26, 3-18, CD-10
restriction, CD-11, B-2
/IGNORE qualifier, 2-25, 2-31, CD-9, A-1
restriction, CD-1 O
Included files, 2-34, 3-15
building system with, 1-11
definition of, 1-11
in a system
figure, 1-12
infinite loop, A-15
nested, 2-38
rebuilding system with, 1-21
source code in, 1-11
.INCLUDE directive, 2-37, 4-18, CD-6, B-3
INQUIRE command, 3-10
Invoking MMS, 1-2

L
.LAST directive, 2-39, 3-17, CD-15
example, 2-40
multiple targets, 2-39
Library
as sources, 4-4
built-in rules for, C-9
CMS, 4-4
access to elements in, 4-6, 4-7
FMS, 4-20
syntax of forms in, 4-20
object
building system with, 1-16
VMS, 4-1
syntax of modules in, 4-2
Library module, 4-2
as targets, 3-3
double colon dependencies, 3-3, 4-2
file specifications, 3-3, 4-2
restriction, 4-2
logical names, 4-2
multiple, 4-2
non-VMS file specifications, 4-3
specification, A-16

lndex-4

Line, action
See action line
LINK DCL command, 2-40
LINKFLAGS
redefined, 3-8
/LIST qualifier, CD-10
Logical names, 3-25
CMS library specifications, 4-17
library modules, 4-2
restriction, 4-2
SCA$LIBRARY, 4-23
LOGOUT DCL command, 2-28
/LOG qualifier, CD-11

M
Macro, 2-12
built-in, 3-7
CU symbol, 2-14, 3-19
default, 2-12, 3-7
LINK, 2-21
LINKFLAGS, 2-21
table of, C-2
defining, 2-14, 2-15, 2-20
defining in a file, 2-16
defining on command line, 2-16
defining on the command line, 3-18, CD-11
definition file, 2-16
example of, 2-15
expanding, 2-15, 3-18
format of, 2-13
invoking, 2-14, 2-15
$MMS, 3-4
$(MMSQUALIFIERS), 3-5
$(MMSTARGETS), 3-5
processing
order of, 2-14
punctuation, 2-14
recursive, 2-15
redefining, 2-16, 2-17
special, 2-18, 3-7
abbreviations, B-3
definition, 2-18
expansion of, 2-20
MMS$TARGET, C-4
MMS$TARGET_NAME, C-4
replacing, 2-18
symbols, 2-18
table of, C-4
used with libraries, 4-3
user-defined, 2-20, 3-7

/MACRO qualifier, 2-14, 2-16, 3-16, 4-13, CD-11,
A-16
MAKEFILE., CD-3, B-1
make utility
differences with MMS, B-1
Messages
error, A-2
Messages, MMS, A-1
MMS
concepts, 1-3 to 1-6
help, 1-3
invoking, 1-2
overview, 1-1 to 1-2
$MMS
special macro, 2-28
MMS$CHANGED_LIST
example of, 2-19
MMS$LIB_ELEMENT, 4-4
MMS$RULES
logical name, CD-14
MMS$SOURCE, 2-9, 2-13, 2-18, 2-21, 2-35
example of, 2-18
used with libraries, 4-3
MMS$SOURCE_LIST, 2-13, 2-21, 2-35
MMS$STATUS, 2-25, CD-5, CD-11, CD-14, A-17
MMS$TARGET, 2-32, C-4
example of, 2-19
used with libraries, 4-3
MMS$TARGET_NAME, 2-13
special macro, C-4
used with libraries, 4-4
$(MMS) reserved macro, 3-4, CD-5
MMS command, CD-3
abbreviating, CD-4
qualifiers, CD-4
see also Qualifiers
$(MMSQUALIFIERS) reserved macro, 3-5, CD-15
MMS quotas, 3-5
$(MMSTARGETS) reserved macro, 3-5
Mnemonic names, 2-2, 2-5
Multiple outputs, 3-26
Multiple programming language system
building, 1-9
figure, 1-10
rebuilding, 1-21
Multiple source system
building, 1-8
figure, 1-9
rebuilding, 1-21
Multiple targets
building system with, 1-13

Multiple targets (Cont.)
rebuilding system with, 1-22
system with more than one executable image
figure, 1-15

N
/NOACTION qualifier, 2-31, 3-4, 4-22, CD-4
/NOCHECK_STATUS qualifier, CD-5
/NOCMS qualifier, 4-7, 4-18, CD-6
/NODESCRIPTION qualifier, CD-4, CD-6, CD-8
/NOIGNORE qualifier, CD-9
/NOLIST qualifier, 2-17, 2-19, CD-10
/NOLOG qualifier, CD-11
/NOOVERRIDE qualifier, CD-12
/NOREVISE_DATE qualifier, CD-13
/NORULES qualifier, CD-6, CD-14
/NOSCA_LIBRARY qualifier, CD-15
/NOSKIP_INTERMEDIATE qualifier, CD-16
/NOVERIFY qualifier, CD-17
Null string, 4-22

0
Object files, 3-3
Object libraries, 3-20
maintaining, 3-2
Object library
building system with, 1-16
definition of, 1-16
in a system
figure, 1-17
rebuilding system with, 1-22
Object module
definition of, 1-16
/OBJECT qualifier, 2-17, 2-19
/OUTPUT qualifier, 2-24, 2-26, 2-31, CD-4, CD-12
/OVERRIDE qualifier, 2-14, 3-7, 4-14, CD-12
Overview of MMS, 1-1 to 1-2

p
Page file quota, 3-5
Parallel processing, 3-19
Parent process, 2-25, 3-3
PASCAL, 2-9, 2-13
environment files, 3-29
.PEN files, 3-29
PFLAGS, 2-9, 2-13
redefined, 3-8
PGFLQUO, 3-5

lndex-5

PRCLM, 3-4, 3-5
Precedence list, 2-33
table of, C-6
.PRECIOUS restriction, 8-1
Process quotas
See quotas

Q
Qualifiers
abbreviating, CD-4
/ACTION, CD-4
/AUDIT, 4-21
/CHANGED, CD-5
/CHECK_STATUS, CD-5
/CMS, 4-6, 4-19, CD-6
/DESCRIPTION, CD-6
/FORCE, CD-8
/FROM_SOURCES, CD-8
/HELP, CD-9
/IDENTIFICATION, CD-9
/IGNORE, CD-9
/LIST, CD-1 O
/LOG, CD-11
/MACRO, CD-11
/OUTPUT, CD-12
/OVERRIDE, CD-12
/REVISE_DATE, CD-13
/RULES, CD-14
/SCA_LIBRARY, CD-15
/SKIP_INTERMEDIATE, CD-16
NERIFY, CD-17
Quotas, A-7
page file, 3-5
process, 3-5, A-6

R
Rebuilding software systems, 1-18 to 1-22
See also Software system
Reserved macros
$(MMS), 3-5
$(MMSQUALIFIERS), 3-5
$(MMSTARGETS), 3-5
Restrictions to COD/Plus access, 4-22
/REVISE_DATE qualifier, CD-13, A-13
CMS libraries, 4-6
FMS forms, 4-21
precedence, CD-14
restriction, CD-14
Revision time, 2-6, CD-8, A-2

lndex-6

RSX libraries, 4-1
Rule
built-in
see built-in rules
dependency
see dependency rule
file, 4-18
hierarchy of application, 2-7
user-defined
see user-defined rules
/RULES qualifier, CD-14
precedence, CD-14

s
SCA
data file, 4-23
library, 4-1, 4-22
$(SCA) macro, CD-15
SCA database, CD-15
$(SCA_LIBRARY) macro, CD-15
/SCA_LIBRARY qualifier, 4-22, CD-15
built-in rule changes, C-1 O
macro changes, C-4
SET NOVERIFYDCL command, 2-28
SET ON DCL command, 2-28
SET VERIFY DCL command, 2-28
$SEVERITY, 2-25
Severity errors, 2-25, A-11
.SILENT directive, 2-31, 3-15, CD-17
example, 2-31
overriding, 2-31
used with a colon, 8-3
Silent prefix (@ ), 2-26, 2-27, CD-5, CD-17
restriction, 8-2
Single source system
building, 1-7
dependencies in
figure, 1-5
rebuilding, 1-20
/SKIP_INTERMEDIATE qualifier, 3-18, 3-19, CD-16
Software system
building, 1-6 to 1-18
multiple programming language system, 1-9
figure, 1-10
multiple source system, 1-8
figure, 1-9
single source system, 1-7
with an object library, 1-16
figure, 1-17
with a specific target, 1-15

Software system
building (Cont.)
with included files, 1-11
figure, 1-12
with multiple targets, 1-13
missing component, 1-20
rebuilding, 1-18
figure, 1-19
multiple programming language system, 1-21
multiple source system, 1-21
single source system, 1-20
with an object library, 1-22
with included files, 1-21
with multiple targets, 1-22
with more than one executable image
figure, 1-15
Source, 2-3
a non-file, 2-6
definition of, 1-4
libraries, 4-4
missing, 3-12
mnemonic names for, 2-5
multiple, 2-6
Source code
file, 2-6
included files with, 1-11
SPAWN DCL command, 2-28
Special macros, 2-12
See Macro, special
expansion of, 2-20
See Macro, special, 2-18
Specific target
building, 1-15
Statistics, 3-12
$STATUS, 2-25, 4-20
STOP DCL command, 2-28, A-8
Subprocesses, 4-20, A-8, B-1
CMS as a, 4-6
invoking MMS as, 3-3
process quotas, 3-4
spawned, 3-3
.SUFFIXES directive, 2-33, A-13
adding new file type, 2-34
format of, 2-33
Suffixes precedence list, 2-10, 2-33, CD-14
figure, 2-1 O
null file type, 2-37
table of, C-6
Symbol scope, A-17
SYS$ERROR, CD-12, A-6
SYS$1NPUT, 2-28

SYS$0UTPUT, 2-24, 2-31, 2-32, CD-4
SYSGEN parameter
CLISYMTBL, A-17
System building
changing options, 3-1 O
from CMS class, 4-13
problem solving, 1-5
recreating previous versions, 4-13
user-defined rules, 2-21

T
Target, 2-2, 2-23
a non-file, 2-6
building specific, 1-15
default, CD-7
definition of, 1-4
mnemonic names for, 2-5
multiple, 2-6
building system with, 1-13
rebuilding system with, 1-22
on command line, 2-4, 2-6
TARGET-NAME.MMS, CD-3
lilde
CMS elements, 4-4
format, 4-4, 4-6, 4-7, 4-18, 4-19, CD-6, A-5
lime, revision
See revision time
lime stamps, 3-13

u
Up-arrow character ( "), 4-21
User-defined macros, 2-12, 3-7, 3-16
User-defined rules, 2-20
accessing CMS element, 4-18
alternative format for, B-2
built-in rule
precedence, 2-20
creating, 2-20
example of, 2-20
format, 2-20

v
VAX DEC/Module Management System, See MMS
/VERIFY qualifier, 2-31, CD-17
Virtual memory, 3-5
VMS library access, 4-1
VMS wildcard characters
See wildcards

lndex-7

w
Warning errors, CD-10
Warning message, A-1
Wildcards, A-1 o
%, B-2
?, B-2
VMS, 4-3

lndex-8

How to Order Additional Documentation

Technical Support
If you need help deciding which documentation best meets your needs, call 800-343-4040

before placing your electronic, telephone, or direct mail order.

Electronic Orders
To place an order at the Electronic Store, dial 800-DEC-DEMO (800-332-3366) using
a 1200- or 2400-baud modem. If you need assistance using the Electronic Store,
call 800-DIGITAL (800-344-4825).

Telephone and Direct Mail Orders
Your Location

Call

Contact

Continental USA,
Alaska, or Hawaii

800-DIGITAL

Digital Equipment Corporation
P.O. Box CS2008
Nashua, New Hampshire 03061

Puerto Rico

809-754-7575

Local Digital subsidiary

Canada

800-267-6215

Digital Equipment of Canada
Attn: DECdirect Operations KA02/2
P.O. Box 13000
100 Herzberg Road
Kanata, Ontario, Canada K2K 2A6

International

Local Digital subsidiary or
approved distributor

Internal 1

USASSB Order Processing - WMO/E15
or
U.S. Area Software Supply Business
Digital Equipment Corporation
Westminster, Massachusetts 01473

1For internal orders, you must submit an Internal Software Order Form (EN-01740-07).

Reader's Comments

Guide to VAX DEC/Module Management
System
AA-P119E-TE

Please use this postage-paid form to comment on this manual. If you require a written
reply to a software problem and are eligible to receive one under Software Performance
Report (SPR) service, submit your comments on an SPR form.
Thank you for your assistance.

I rate this manual's:
Accuracy (software works as manual says)
Completeness (enough information)
Clarity (easy to understand)
Organization (structure of subject matter)
Figures (useful)
Examples (useful)
Index (ability to find topic)
Page layout (easy to find information)

Excellent

Good

Fair

Poor

D
D
D
D
D
D
D
D

I would like to see more/less
What I like best about this manual is
What I like least about this manual is

I found the following errors in this manual:
Page
Description

Additional comments or suggestions to improve this manual:

I am using Version ___ of the software this manual describes.
Name/Title
Dept.
Date

Company
Mailing Address
Phone

Do Not Tear - Fold Herc and Tape
No Postage
Necessary
if Mailed
in the
United States

BUSINESS REPLY MAIL
FIRST CLASS PERMIT NO. 33 MAYNARD MASS.
POST AGE WILL BE PAID BY ADDRESSEE

DIGIT AL EQUIPMENT CORPORATION
Corporate User Publications-Spit Brook
ZK01-3/J35
110 SPIT BROOK ROAD
NASHUA, NH 03062-9987

111 ..... 11.11 ... , 11 .... 1.11.1, , 1.1 .. 1•• 1, 1. , , 1.11 .. I
Do Not Tear - Fold Here

Reader's Comments

Guide to VAX DEC/Module Management
System
AA-P 119E-TE

I rate this manual's:

Excellent
Accuracy (software works as manual says)
D
Completeness (enough information)
D
Clarity (easy to understand)
D
Organization (structure of subject matter)
D
Figures (useful)
D
Examples (useful)
D
Index (ability to find topic)
D
Page layout (easy to find information)
D

Good

Fair

Poor

D
D
D
D
D
D
D
D

I would like to see more/less
What I like best about this manual is
What I like least about this manual is

I found the following errors in this manual:
Page
Description

Additional comments or suggestions to improve this manual:

I am using Version ___ of the software this manual describes.
Name/Title
Dept.
Company

Date

Mailing Address
Phone

Do Not Tear - Fold Here and Tape
No Postage
Necessary
1f Mailed
in the
United States

BUSINESS REPLY MAIL
FIRST CLASS PERMIT NO. 33 MAYNARD MASS.
POSTAGE WILL BE PAID BY ADDRESSEE

DIGIT AL EQUIPMENT CORPORATION
Corporate User Publications-Spit Brook
ZK01-3/J35
110 SPIT BROOK ROAD
NASHUA, NH 03062-9987

Ill ... .. 11, 11 ... 1 II 1111I1 II 1 I 11 1.1 .. I.. I•I•.. 1.11 .. I
Do Not Tear - Fold Here - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -