Digital PDFs

MISC-684178E0

1985

261 pages

Original

20MB

Document:	VAX/VMS Software Language and Tools Handbook
Order Number:	MISC-684178E0
Revision:
Pages:	261
Original Filename:

OCR Text

VAX/VMS Software
Language and Tools Handbook

Digital believes the information in this publication is accurate as of its publication date; such information is subject to change without notice. Digital is
not responsible for any inadvertent errors.
The following are trademarks of Digital Equipment Corporation:
DEC
DECmate
DECsystem-lO
DECSYSTEM-20
DECUS
DECwriter
DIBOL
MASSBUS

MicroPDP-ll
MicroIbwer/Pascal
PDP
PIOS
Professional
Q-BUS
Rainbow
RSTS

RSX
RT
ULTRIX
UNIBUS
VAX
VMS
VT
\Xbrk Processor

IBM is a registered trademark of International Business Machines Corporation.
CROSSTALK XVI is a registered trademark of Microstuf, Inc.
SONY and VDX-lOoo are registered trademarks of Sony Corporation.
MARK IV is a registered trademark of the Norpak CorporationOntario, Canada.
Copyright © 1985 Digital Equipment Corporation. All Rights Reserved.

Contents

Preface ...................................................... i
Introduction to VAXIVMS Software . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. xiv

Chapter 1 • The VAX/YMS Software Devdopment Environment
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. I-I
The VAX Common Language Environment ................... ; . . .. 1-2
VMS Runtime Capabilities ...................... '" . .. . . . . . .. 1-3
~ervices and Products ..................•............ ;........... 1-3
The VMS Operating System ........ ; ............•....... ; .. . .. 1-5
The VMS Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . .. 1-6
The Digital Command Language .... '.' .. , ............. ,. .... \-6
VMS Record Management Services (RMS) ....................' -.1-6
The VMS Runtime Library (RTL) ....... , .•..•.. , ........... , 1-7
VMS Program Developm~nt Utilitie~ " . '. , ..... : . . .. . . . . . . . . . . . .. 1-7
VAXTPU (Text Processing Utility) ............................ 1-8
The EDT Text Editor . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . .. 1-8
The DSR Text-Formatting Utility .............. ;'........ , .... 1-9
The VAX Symbollc Debugger Utility ...................... ;.. 1-9
Optional VAX Program Development Products ............. , ... ; 1-10
VAX Languages ..................... '.' ......•.....-'. . . . .. 1-10
VAXProductivityTools ..................... : ............ ; '1-14
Related VAX Program Development Products .... '..... ; ... ;. _.... 1-18

Chapter 2 • VAX Program Development Productivity Tools
OvelView .................................................. 2-1
VAXDEC/CMS (Code Management System) ....................... 2-3
VAX DEC/CMS Features ..................................... 2-4
Using VAX DEc/CMS ....................................... 2-4
Concurrent Development .................................. 2-5
Classes and Groups ...................................... 2-6
Project Information ...................................... 2-7
VAX DECIMMS (Module Management System) ................... 2-7
VAX DEC/MMS Features ................................... 2-8
Using VAX DECIMMS ..................................... 2-9
Dependency Rules .................................... 2-10
Compatibility In The VMS Environment ..................... 2-11
VAX DEC/Shell ........................................... 2-12
VAX DEC/Shell Features .................................. 2-12
Using The VAX DEC/Shell ................................ 2-12
The VAX DEC/Shell As A Programming Language ........ . . . . . 2-13
The VAX DEC/Shell Runtime Library. . . . . . . . . . . . . . . . . . . . . . . . 2-13
VAX DEC/fest Manager .................................... 2-16
Features of VAX DEC/fest Manager ........................... 2-16
Using VAX DEC/fest Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 -16
Steps In Regression Testing ................................ 2-17
Steps In Regression Testing With DEC/fest Manager ............ 2-18
Organizing Tests ........................................ 2-18
Running Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 -19
Evaluating Test Results ................................... 2-20
The VAX Language-Sensitive Editor ............................. 2-20
"Language-Sensitive" Features ............................... 2-21
Using The VAX Language-Sensitive Editor ...................... 2-22
Online Help With The VAX Language-Sensitive Editor .......... 2-23
Wmdows Provide Added Flexibility ........................ 2-23
Thiloring Your Environment ............................... 2-24
VAX Text Processing Utility (VAXTPU) ....................... 2-24
VAX n:rformance and Coverage Analyzer (VAX PCA) ............. 2-25
Features of The VAX n:rformance and Coverage Analyzer ......... 2-25
Using The Collector ..................................... 2-26
Using The Analyzer ..................................... 2-27
PLOT And TABULATE Functionality .......................... 2-27
VAX GKS ................................................. 2-27
Features of VAX GKS ........................................ 2-28
Using VAX GKS ............................................ 2-28
VAX GKS Output ....................................... 2-29

VAX GKS Input ......................................... 2-31
VAX GKSMetafiles ...................................... 2-31
Chapter 3 • VAX Programming Languages
Overview .................................................. 3-1
Introduction: General Features of VAX Programming Languages ....... 3-3
VAXAda ................................................... 3-5
Features of VAX Ada ....................................... 3-5
Who Uses VAX Ada ........................................ 3-5
VAXlVMS Implementation of Ada ............................. 3-6
Ada Program Units ........................................ 3-7
Major Features of The Ada Programming Language ............... 3-8
VAXAPL .................................................. 3-12
Features ofVAXAPL ...................................... 3-13
Characteristics ........................................... 3-13
VAXBASIC ................................................ 3-14
Features of VAX BASIC ..................................... 3-15
WhoUsesVAXBASIC? .................................... 3-15
General Characteristics .................................... 3-16
Structured Programming ................................... 3-16
VAX BLISS-32 .............................................. 3-18
Features of VAX BLISS-32 ........ _.......................... 3-18
Whatls VAX BLISS-32 Used For? ............................ 3-19
The VAXBLISS-32 Compiler ................................ 3-19
Library and Require Files ................................... 3-20
MACROS ............................................... 3-20
Debugging .............................................. 3-21
transportability Features ................................... 3-21
VAXC .................................................... 3-24
Features of VAX C ........................................ 3-24
Who Uses VAX C? ........................................ 3-25
The Language ........................................... 3-25
Compatibility Across Implementations ..................... , .. 3-26
VAX COBOL ............................................... 3-27
Features of VAX COBOL. ................................... 3-28
Who Uses VAX COBOL? ................................... 3-28
Structured Programming ................................... 3-28
Data Types .............................................. 3-30
VAXDIBOL ................................. c •.•.......... 3-30
FeaturesQfVAXDIBOL .................................... 3-31
Who UsesVAXDIBOL? .................................... 3-31
DIBOL Language Statements ................................ 3-32
Program Structure ........................................ 3-32

Operating Procedures ..................................... 3-33
Compilation and The DIBOL Compiler ........................ 3-34
Contents of The Listing File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3,34
VAXDSM ................................................. 3-35
Features ofVAXDSM ...................................... 3-35
Who Uses VAX DSM? .. , ................................... 3-35
DataManagement ........................................ 3-36
The Precompiler ......................................... 3-37
Procedure Calls .......................................... 3-38
VO Options ............................................. 3-38
Shared Memory Areas ..................................... 3-38
The DSMJob Controller ................................... 3-38
Journaling .............................................. 3-39
System and Library Utilities ................... , ............. .3-39
VAX FORTRAN ............................................. 3-39
Features of VAX FORTRAN ................................. 3-40
Who Uses VAX FORTRAN? ............................... '.' 3-40
Language Characteristics .................................... 3-40
VAX LISP ....................................... , ......... 3-43
Features of VAX LISP ...................................... 3-43
Who Uses VAX LISP? ...................................... 3-44
Using VAX LISP .......................................... 3-45
Invoking LISP .......................................... 3-45
Using Command Levels .................................. 3-45
Controlling Input ....................................... 3-46
Creating Programs ...................................... 3-46
VAX PASCAL ............................................... 3-48
Features of VAX PASCAL ................................... 3-48
Who Uses VAX PASCAL .................................... 3-48
VAXPLII ................................................. 3-52
FeaturesofVAXPLII ...................................... 3-52
Who Uses VAX PLII ....................................... 3-52
VAX RPG II ................................................ 3-75
Features of VAX RPG II .................................... 3-75
Who Uses VAX RPG II? ............................. ; ...... 3-76
Language Characteristics and Functions ....................... 3-77
The VAX RPG II Editor ..................................... 3-78

Chapter 4 • VMS Services
Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 4-1
VMS Record Management Services (RMS) . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Files .................................................... 4-3
RMS Provides Three Record-access Modes ...................... '1-3

Sequential Access Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Random Access Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Record's File Address (RFA) Access Mode ..................... 4-4
Dynamic Access .................. ; . . . . . . . . . . . . . . . . . . . . . . 4-4
RMS File Attributes ........................................ 4-5
Storage Media .......................................... 4-5
File Specification ........................................ 4-5
RMS Record Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 4-6
Program Operations On RMS Files .... . . . . . . . . . . . . . . . . . . • . . . . . 4-6
File Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
File Organization and Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Program Sharing ........................................ 4-7
Record Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Record va Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
RMS Utilities .............................................. 4-8
Using RMS ............................................... 4-9
The Digital Command Language (DeL) ......................... 4-11
Command Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Command Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Formatting Command Procedures .....•.................... 4-13
The VMS Runtime Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Features of The Runtime Library ............................. 4-14
Organization of The Runtime Library ........ _................ 4-14
Functional Listing of VMS RTL Procedures ..•.................. 4-15
VMS System Setvices ......................... ; .......... ; ... 4-19
CaIling System SelVices ............•.........•............. 4-21
VMS System SelVices and System Integrity .................... 4-21
VMSSecurity System SelVices ............................... 4-22
VMS Event-flag System SelVices .............................. 4-22
Event,flag Numbers and Event-flag Clusters ............. " ... 4-23
AST (Asynchronous System li-ap) SelVices ...................... .4-23
Logical Name SelVices ................................ : .... 4-24
Input/Output System SelVices ............................... 4,24
Process-Control SelVices ................................... 4-24
VMS Tuner and Time-Conversion System SelVices. . . . . . . . . . . . . . . . 4-25
VMS Condition-Handling System SelVices ...................... 4-25
VMS Memory-Management System Setvices .................... 4-26
VMS Lock-Management System SelVices ....................... 4-26

Chapter 5 • VMS Program Development Utilities
ChapterOvetview ................................ \ .......... 5-1
The VAXlVMS Symbolic Debugger ................. ; .......... ' .. 5-3
The Debugger Is Interactive ..............................•. 5-3

The DebuggerIs Symbolk .......... " .................', ... 5-3
TheDebuggerIsMultilingual ............. ; ................ 5-4
TheI>~bugger'sFeatures and Commands ..................... 5-5
UserlnterfaceFeaturesofTh~VMSDebuggerUtility .......... ;. 5-5
VAX SORTIMERGE ............................. ; ....•. '...... 5-6
VAX UNKER ............................ " ...............' .... 5-8
The VAX1ext Processing Utility (VAXTPU) ......... " . "' ......... 5-12
VAXTPUlnterfaces ................................ ;.......... 5-12
TheEVE·lnterface .............................. ~., ...... 5-13
The EDT Keypad-Emulator Interface. . . . . . . . . . . . . . . . . . . . . . . . 5-14
Special Features .................... c' • " • • • • • • • • • • • • • • • • . • . • • 5-14
Hardware and Terminals That VAXTPU Supports ...... ; . . . .. . . . . 5 -15
The VAXTPU Language ...........................•........ " 5-15
VAXTPUDataTypes ........................ : .............. 5-15
VAXTPU Language Statements. . . . . . . . . . . . . . . . . . . . . . . . .. . . .. . 5-16
VAXTPU Built-in Procedures ............................. ; .. . . 5~ 17
VAXTP:UUser-writtenProcedures ............................. 5-17
InvokingVAXTPU ......................... , ..... , .. ·.. 0. 0 ' •• 5,18
EDITIVAXTPU Command Q_ers ........... ; •.....
i.; 5-19
Initialization Files. , .... , ......
5-19
Leaving A VAXTPU Editing Session ....
5-20
The Em Editor ....................
,5-20
Tht; VAX Document-formatting Utility (DSR) ........................ 5-22
Other Program Development Utilities ........ " ..................' 5-27
The Command Definition Utility (CDU) .................... , ... 5-27
Object Analyzer Utility ... , ...................... ; ... , .....• 5-28
Message Utility ............................' ............
5-28
The VAX Exchange Utility (EXCHANGE) .•........ , .....•..... 5,28
"0 •• ,

....... ,

• • • ,0

•••••

,' • • • • • • • • • • ,

•••••

••

• • .0 .

••••

Chapter~. •
.

.........................

;'.

VAX Program Migration and Cross-Development Tools
.

.' '.

. '

Overview ........................... '................. ". . . .. 6-1
VAXELN Toolkit Overview ......................... : ........... 6-3
VAXELN Systems ....................................... '.' .. 6-3
Toolkit Components ................................. : ...... 6-5
VAX:811 RSX ..................' ................................ 6-8
Program Development Capabilities ............. ' ............... 6-9
General AcceSs ............................ : . . . . . . . . . . . . . . 6-11
Disk and 'Thpe \blumes .................................... 6-11
Intersystem Facilities ........ : ............................. 6-12
Compatibility ..... '" .. ~:: . ::: .......... , ................ 6-12
MCR Compatibility ...................................... " 6-12
Indirect Command File Compatibility ......•• : . .. . . . . . .. . . . . . . 6-13
VeneralAreas ofIncompatibility ............................. 6-14

Compatibility With Other Derivatives of RSX -11 . . . . . . . . . . . . . . . . . 6-14
Optional Software ........................................ 6-14
MicroIbwer/Rtscal-VMS ..................................... 6-15
Chapter 7 • Language and Tool Integration in the
VAXlVMS Environment
Overview, ....................................... .,. . . . . . . . . . 7-1
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
The Program Development Life Cycle .......................... 7-3
Phase 0: Business and Risk Analysis .......................... 7-5
Phase 1: Design ......................................... 7-5
Phase 2: Implementation .................................. 7-6
Phase 3: Qualification .................................... 7-6
Phase 4: Volume Production, Maintenance and Evolution ......... 7-7
Here's A Specific Example .................................... 7-11
Your Department . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Getting Started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
Defining and Analyzing The Software System With VAXlVMS ...... 7-15
Designing The Software System With VAXlVMS ................. 7-19
Implementing The Software System With VAXlVMS .............. 7-22
VMS Services In The Implementation Phase ........ . . . . . . . . . . 7-26
Using The VAX Language-Sensitive Editor During
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27
Using VAX DEBUGGER In The Implementation Phase .......... 7-28
Using DEClCMS And DEClMMS Together .................... 7-29
Using Related VAX Software Products In Implementation Phase ... 7-29
Testing and 'krifying The Software System With VAXlVMS . . . . . . . 7-31
Using The VAX Performance and Coverage Analyzer (PCA) ...... 7-36
Using The DEC/Test Manager In The Testing Phase ............ 7-36
Maintaining The Software System With VAXlVMS. . . . . . . . . . . . . . . . 7-37
Conclusion. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 7-42
List of Figures
Figure
Number

1-1:
1-2:
1-3:
1-4:
1-5:
1-6:
1-7:

Description
VAXlVMS Services and Products used for Program
Development . . . . . . . . . . . . . . .. . . . . . . . . . .. . . . . . . . .. 1-4
The VMS Operating System ......................... 1-5
VMS Services .................................... 1-6
VMS Program Development Utilities . . . . . . . . . . . . . . . . .. 1-8
VAX High-Level Programming Languages. . . . . . . . . . . .. 1-11
VAX Program Development Productivity Tools. . . . . . . .. 1-15
Related Program Development Products. . . . . . . . . . . . .. 1-19

2c 1:
2-2:
2-3:
2-4:
2-5:
2-6:

Overview of Chapter 2 ........ ; ..... : ....... , .. :. . . 2-2
Element TEST.FOR with Main Line and Variant Generation 2-6
Generation 2Al Merged into the Main Line of Descent ... 2c6
How MMS Builds a Software System .................. 2-9
Dependency Rule Format ......................... 2·10
Sample Dependency Rule .............. . ii ........ 2-11

3-1:
3-2:
3-3:
3-4:
3-5:
3-6:
3-7:
3-11:
3-12:
3-13:
3-14:

Overview of Chapter 3 ........................ : .... 3-2
Sample Ada Program Listing ............... 3-10,3-11,3-12
Sample Structured VAX Basic Program ..... : , ... , .. ·3-2,3-3
Statement Modifiers. . .. . . . . . . . . . . . . . . . • . . . . . . . . .. 3~18
Sample VAX BUSS-32 Program Listing .... , .. 3-22,3-23,3-24
Sample VAX C Program .................•. ; : . . . . . . 3-27
Use of VAX COBOL Structured Programmirig-Techniques'; 3-29
SampleVAXB\SCALProgtainListing .. '.. : .:.: ....... 3-51
Sample PLlIProgram Listing .................... , . .' 3·55
Typical RPG II Program Showing a CALL Statement : ... 3-60
A Typical RPG II Program Used to Generate Mailing
·.3-60
Labels ..... , ...... :.. '.: ../; ..... ; •.........
"0 • • • • •

4-1:
4-2:
4-3:

Overview of Chapter 4 ......' .... , ....... ~ .....•..... .4-2
Sample RMS Program ..... ~ .... '" ........... ; .. : .'. 4-2
General-Purpose and Language-Support RTL· ,',
Procedures .' ...................• ~ ...,., .: .,,";' .. 0 • " ,: 4-15

5-1:
5-2:
5~3:

Overview of Chapter 5 ................ : ............ 5-2
VAXTPU As a Base for EVE and the EDT Keypad
Emulator .... ': .......... ; .......... ': .......... '. 5-13
VAXTPU As II BasHor User-written Interfaces ........ :'. 5-13

6-1:

OvervieW of Chapter 6 ........ '..................... 6-2

7·1:

OverviewofChapter7 .... : •........ : ..... : .. :.. :..... 7-2
The VMS Productivity Environment for Program
Devdopment .. , ............................... ,. 7-8
A Mood Program Devdopment Department. . . . . . . • . .. 7-12
Defining and Analyzing the Software System
",
with VAXlVMS .................................. 7-i6
Designing the Software System with VAXIVMs ......... 7-20
Implementing the Software System With vAXNMs. . . . .. 7-24
'Jesting and \erifying the Software SyStem with VAXIVMS. 7-34
Maintaining the Software System With VAXlVMS . . . . . .. 7-40

7~2:

7-3:
7A:
7-5:
7-6:
7-7:
7-8:

List of Thbles
Thble
Number
2-1:
3-1:
4-1:
4-2:
4-3:
4-4:
5-1:
5-2:
5-3:
5-4:
5-5:
5-6:
7-1:
7-2:

Description
VAX DEC/Shell Utilities and Commands .............. 2-14
Cross Refererence Chart for VAX Languages, Tools, and
Related Program Development Products. . . . . . . . . . . . . . . 3-4
Comparison of RAB and FAB Parameters for Record
Operations ...................................... 4-9
VMS Runtime Library Facilities ..................... 4-14
Functional Grouping of VMS R1L Facilities. . . . . . . . . . .. 4-15
The Functional Grouping of VMS System Services ...... 4-20
Qualifiers to the DCL command EDITIfPU ............ 5-19
Selected Examples of DSR Subject-Matter
Formatting Commands ...................... . . . .. 5-24
DSR Graphic, List,and Note Formatting Examples ...... 5-25
Miscellaneous Formatting Commands. . . . . . . . . . . . . . .. 5-26
DSR Flag, Index, and Table of Contents Commands .... . 5-26
DSR Run Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27
The Program Development Life Cycle ................. 7-4
VAXlVMS Products Used in The Product Development
Life Cycle ...................................... 7-10

Preface

The VAX/VMS Languages and Tools Software Handbook is a comprehensive reference guide to the latest software development products available from
Digital. It is part of a three-volume set titled, VAX/VMS Software. The other
handbooks in this set are, The VMS System Software Handbook and The VAX

In/ormation Management Handbook.
Digital has developed many products to meet the varied needs of today's program development shop. These include industry-standard, high-level language
compilers, program preparation and development tools, and even many tools
that allow programmers familiar with other operating systems to take advantage
of the power and flexibility of the VMS software development environment.

Handbook Organization
• Chapter 1 - "The VAXNMS Software Development Environment" gives you
an introduction to the family of VAXNMS program development software
products and the single integrated environment they are part of.
If you are not familiar with these software products and their relationship to
each other and to the VMS operating system, this chapter will give you the
overview you need before proceeding to the specifics of VAXlVMS program
development software products .
• Chapter 2 - "VAX Program Development Productivity Tools." This chapter
describes the many VAX productivity tools that can be used in conjunction
with VAX languages. These tools streamline the program development environment by giving programmers control over the many tedious and time-consuming aspects of "building" software systems.
Each tool is covered in its own section of the chapter and includes a general
description of the tool's features and benefits.

• Chapter 3 - "VAX Programming Languages". This chapter describes the
most widely used VAX Languages. It is organized alphabetically by language
name and includes the features, benefits, and primary applications of each
language. Detailed information on commands and compilers, and a sample
program listing is also included.
• Chapter 4 - "VMS Program Development SelVices". The foundation on
which VAX productiviry tools and languages operate is the VMS operating system. Chapter 4 describes four selVices provided by the operating system and
used in program development. These include, the Digital Command Language(DCL), Digital R~cord Management SelVices (RMS) , the VAX Runtime
Library (RTL), and VMS System SelVices.
• Chapter 5 - "VMS Program Development Utilities." This chapter gives you
an introduction to VMS's program developm~nt utilities. Included are
descriptions of VAXTPU and EDT text editors, the VAX Symbolic Debugger,
Linker, Librarian, and manyother sophisticated utiliryprograms that are an.
integral part of the VAXlVMS program development environment.
.
• Chapter 6 - "VAX Program Migration and Cross,Development Tools."
Three optional VAXlVMS software products - VAXELN, VAX-ll RSX, and
MicroIbwerlPascal-VMS - make it possible for you to use your VAX system
as a host program development system to develop applications that can then
be run on other Digital systems. This chapter introduces you to both of these
products.
• Chapter 7 - "Language and Tool Integration in the VAXlVMS Software
Development Environment." This chapter gives you a brief overview of the
program development life cycle as we define it at Digital and shows you how
our software products interact to make each phase of the development cycle
as productive and cost effective as possible .

• Scope of the VAXNMS Handbook Set
It is not the intent of thiS handbook set to describe all VAXlVMS software products. Products covered in these three volumes pertain to the subject of the specific handbook they appear in. For example, the VAX Languages and Tools
Handbook describes VAXlVMS software products used for software development. Many product not discussed in these three volumes are covered in other
handbooks or related documentation.

• Related Publications
The following publications can provide you with additional infonnation on
VAXlVMS software products discussed in this Handbook Set and can be
obtained through your local Digital Sales Office or Sales Representative. Or, in
the United States, for more infonnation, an online demonstration of many of
the products discussed in this handbook, or to purchase a product, call:
Digital's ElectronicStore (1-800-332-3366) with a VT100 compatible tenninal
and a 1200 baud modem and follow the directions that appear on your screen.
• You can find specific hardware/software support guidelines for VAXlVMS
software products by referencing the Software Product Description (SPD) of
a particular product. Information in the Alphabetical Index (SPD 00.01.11),
The VMS Operating System SPD (25.01.22), and The VAXlVMS Optional
Software Cross-Reference Table SPD (25.99.37) is particularly useful in determining the type of VMS operating system support and the SPD number of a
product.

• VAXSo/twareSource Book \blume 1, Application Software; \blume2, System
Software
• The Digital Dictionary provides generic and Digital-specific definitions for the
technical terminology found in this handbook set.
• VAXIVMS Internals and Data Structures. This book describes indepth the VMS
operating system's executive and a number of its related subsystems.
• User and reference manuals can also be obtained for each of the products
described in this handbook set. You can find out how to order these manuals
for the software products running of your specific VAX processor in the ~r
ipherals and Supplies Group's Documentation Products Directory.

Introduction to VAXlVMS Software

Computing resources, hardware and software, make it possible for an organization to effectively deal with a multiplicity of both day-to-day and long-range
operating needs. Typically, these include data processing, program development, and information management requirements.
A grouping of computer resources creates a computing environment. To be
effective, a computing environment must be made up of resources that are
compatible with each other and designed to work together toward a common
goal. Digital's VAXlVMS software products are designed to create such a computing environment - the VAXlVMS Productivity Environment.

The VAXlVMS Productivity Environment
• TIlE VMS PRODUCTIVIlY ENVIRONMENT'S FOUR SUBSETS
Digital's VAXlVMS productivity environment is made up of many different
software products. Even though all these products have been designed to operate as a single integrated environment, they are can be organized, by function,
into four logical groups. Each group is a subset of the overall VAXlVMS productivity environment and provides VAXlVMS users with specific capabilities.
These four groups of software products are the
1. VMS operating system group (including S¢lVic~ and utilities).
2. VAX program development group.
3. VAX information ljllIIlagement group:
4. Related VAX software group.

i'VAX LANGUAGES} Group 2- The program

_-.==:::;--__ '

group

Group 3The information

VAX TOOLS

development group

• TIIE VMS OPERATING SYSTEM GROUP (1)
When you buy a VAXlVMS system, in addition to the various hardware components, you receive a standard set of software programs essential for the basic
operation of your system. This group of software is the VMS Operating System,
a number of services provided- by the operating system, and many utility
programs u.sed for system management and progrrun developm~t. 11J.is group
serves as the foundation on which all VAX optional software products (those
products in groups 2-4) and applications prograrns generated from those
products operate.
.
.

VMS OPERATING SYSTEM

\.l.._ _ _~VMS SERVICES

VMS OPERATING
CAPABILITY

,""~~~~:;?/f - - - - V M S UTILITIES

The VMS Operating System, Services, and Utilities
The VMS Operating System gives you the flexibility and control you need to
successfully distribute computing resources throughout your organization's
computing environment. A few of the many unique features built iflto the VMS
operating system give you the ability to duster, network, and secure tesollrces
within your computing environment.
VMS services include the Digital Command Language, VAX Record Management Services, the VAX Runtime Library, and VMS System Services.
VMS Utilities are grouped into program development and system management
utilities.
The MicroVMS operating system supports Digital's MicroVAX processors and is
a full function, special packaging of the VMS operating system.
For more information on the VMS operating system group see the VMS System

Software Handbook.
Digital also offers you many optional software products that can be purchased
in addition to basic system software. These optional products have heen
designed to work in conjunction with VMS system software and perform a specific function. Software described in the next three groups are all optional
products.

• THE VAX PROGRAM DEVELOPMENT GROUP (2)
This group of optional software products is made up of a rich set of VAX programming languages and VAX program development productivity tools. With
this group of products (and many of the services and program development
utilities provided with the VMS operating system), you can build software that
runs on the full spectrum of VAX processors - MicroVAXNAX Station to VAX
8600 VAXcluster systems.

~
THE VMS OPERATING
SYSTEM AND PROGRAM
DEVELOPMENT
UTILITIES

VAX LANGUAGES

~_
-

VAXNMS
PROGRAM
DEVELOPMENT
CAPABILITIES

VAX TOOLS

The VAXlVMS Program Development Products
Included in the VMS program development software group are
• Over a dozen high-level (sixteen in all), industry-standard programming languages that are callable from each other - including VAX'· Ada$, VAX APL,
VAX BASIC, VAX BLISS, VAX C, VAX ,COBOL, VAX DIBOL, VAX FORTRAN,
VAX PASCAL, VAX PLII, and VAXRPG II.
• Numerous program development productivity tools that simplify many of the
tedious and time-consuming chores involved in large"scaleand labor-intensive, small"scale software development .
• Tools that aid in building software systems efficiently and reliably.

• THE VAX INFORMATION MANAGEMENT SOFTWARE GROUP (3)
Digital's VAX Information Management Software group offers you a variety of
integrated software products· to meet the diverse information management
needs of your organization. Products in this group run on the VMS operating
system and can be used with products in groups 1,2, and 4. For example, the
Common Data Dictionary (CDD) is often used extensively with products from
the Program Development Group (2) - VAX languages and tools - when
programmers build application programs.

*Ada is a registered trademark of the U.S. Department of Defense.

VAX INFORMATION
MANAGEMENT
CAPABILITIES

+
VMS OPERATING
SYSTEM

VAX INFORMATION
MANAGEMENT
PRODUCTS

The VAX Infonnation Management Products
VAX Information Management products are used for

• Creating a variety of database management systems.
• Application development and control.
• Report generating.
• Easy-to-use querying.
A description of the VAX information management products and its associated
software products can be found in The VAX Information Management
Handbook .

• THE RELATED VAX SOF1WARE GROUP (4)
Related VAX software products enhance the capabilities found in the three
groups of software products just discussed. These products are used to move
and develop software products between DEC systems and make it possible for
VAX systems to communicate with other DEC systems in a data communications
network.
VAX DATA
COMMUNICATION
AND PROGRAM
CROSS·DEVELOPMENT
CAPABILITIES
VMS OPERATING
SYSTEM

• VAXELN
DIGITAL NETWORK
• VAX·11 RSX
ARCHITECTURE
• MICROPOWER/PASCAL·VMS

Chapter 1 • The VAXlVMS Software Development
Environment

• Introduction
To hdp you better manage your software assets, Digital offers you the VAXNMS
Software Devdopment Environment. This highly integrated environment comprises software products designed to a common specification and emb()dying a
common set of characteristics. These products run on a single operating system
(VMS) and give you and other programmers a consistent environment for the
design, implementation, testing, and suppott of software programs.
These products hdp you
• Organize and manage your software projects more economically.
• Build more rdiable code.
• Code and debug programs easier.
• Understand your product and its performance.
• Manage changes to code and build your system efficiently.
• Control the evolution of your programming environment.
Thefutegration of the VMS Operating System, VAX Languages and Tools, and
Program Devdopment Utilities is made possible by
• A common architecture to which all these products conform.
• Corrimon runtime capabilities available to all applications that are· created
and runon the VMS operating system.

1-2 • The VAX/VMS Software Development Environment

The VAX Common Language Environment
When we first designed the VAX!VMS Software Development Environment, it
was necessary to create standards to control the design and implementation of
products that would exist within that environment_ These standards ensures all
products, their future releases, and any new VAX product offerings are compatiblewith the existing products in the environment. This common design goal is
the VAX Common Language Environment.
The VA1( Calling Standard, the Guide to Modular Procedures, and the VAX
Condition and E,xception Handling Standard are the basis of the VAX Common
Language Environment. The calling standard defines the mechanisms for passing arguments between program modules, The Guide to Modular Procedures
provides a consistent setof software programming pragmatics, and the Condition and Exception Handling Standard defines the mechanisms that ensure
consistency in error and exception handling routines, regardless of the m~ of
programming languages in use. For example, in no other program development
system on the market today, can you write a program module in Basic that calls
another module in written FORTRAN and then calls a math routine written in
Pascal - all in one Ada program.
As an extension of the VAX Common Language Environment, our VAX tools
have a number of common characteristics.
• They are all based on the VMS Operating System and the VAX Common Language Environment.
• They can be used with many VAX languages - either they are language neutral or they provide capabilities that allow you to tailor them to support the
various languages they are aimed at.
• They can be used with many different designs or methodologies.
• They have been designed to help you in portions of the software development
. task that consume large amounts of your time.
• The tools are designed to be consistent in terms of user input and response to
that input. They use the same standard command language, prompts, and
error messages.
• The tools are based on a compatible set of data formats - the VAX data types,
descriptors, and calling standard.
• Many of these tools can be extended and tailored to your unique requirements. This helps you adapt our set of products to your local needs, whether
it is customs and standards or defaults that are particularly appropriate to
your shop.

1-3

NMS Runtime Capabilities
A few important runtime capabilities of the VMS operating system are
• A set of routines that manage record and file 110 for all languages the VAX

Record Management SelVices (RMS).
• A common mechanism for handling exceptions. The VAX Runtime Library
(R1L) provides a common set of procedures for exception handling and common-resource handling that enable languages to work together. VAX condition handling provides a low-Ievd, powerful mechanism for dealing with
exceptions in various languages.

• VMS system services. The VMS operating system has many services that can
be used by an application program at runtime. Process control, memory management, and system security services, for example, are areas in which the
VMS operating system can provide special operating -capabilities to application programs at runtime.
• The VMS Runtime library. A set of language-dependent procedures ensures
correct operation of complex language features, and hdps enforce consistent
operations on data across the languages. A set of language-independent routines establishes a common runtime capability for user programs. The runtime library has many math,· screen-management, and· general-purpose
procedures.

• Services and Products
The software facilities found in the VAXiVMS softwaredevdopment environment are divided into six basic categories. .
• The VMS Operating System.

• VMS Se~ces ...
II VMS Pl'Qgram Devdopment Utilities.

.. VAXLanguages~
• VAX Software Tools.
• Related VAX ;Program Devdopment Products.
Each category is further-divided into specifk services or products as illustrated
in Figure 1-1.

1-4 • The VAX/VMS Software Development Environment

VMS CORE SERVICES
1. The VMS Operating System
2. VMS Services
- The Digital Command Language (DCl)
- The VMS Runtime Library (RTl)
- VMS system services
- The VAX Record Management Services
(RMS)
3. The VMS Program DeveloPment Utilities
- The VAXIVMS Symbolic Debugger
-Sort/Merge
- The VAX Linker
- The VAX Li brarian
- VAXTPU text processing utility
- DSR text-formatting utility
- Mail
VAX OPTIONAL PROGRAM
DEVELOPMENT PRODUCTS
4. VAX Languages
- VAX Ada
- VAX Api
- VAX BASIC
- VAX BLISS
- VAXC
- VAX COBOL
- VAX CORAL
- VAX DIBOl
- VAX DSM
- VAX FORTRAN
- VAX LISP
- VAX PASCAL
- VAX PLiI
- VAX RPGII
- Other VAX Languages

,~---====6

6.10

5. VAX Software Productivity Tools
- VAX DEC/Code Management System
(CMS)
- VAX DEC/Module Management System
(MMS)
- VAX Language-Sensitive Editor (LSE)
- VAX Performance and Coverage
Analyzer (PCA)
- VAX DEC/Shell
VAX DEClTest Manager
- VAX Graphical Kernel System (GKS)
6. Related Program Development Products
6.1 VAX CDD
6.7 VAX FMS
6.2 VAX DBMS
6.8 DECnet Communications
Products
6.3 VAX Datatrieve
6.4 VAX RdblVMS (ElN)
6.9 VAXElN
6.10 VAX-11 RSX
6.5 VAX ACMS
6.6 VAX TDMS
6.11 MicroPower/Pascal-VMS

Figure 1-1 • VMS Services and Products used for Program Development

1-5

The VMS Operating System
VMS is a general-purpose operating system widely used for the simultaneous
execution of timesharing, batch, or realtime application programs by many
users.
Applications can be developed and run across the entire line of VAX processors,
within limits of existing program size and available memory. User-mode applications developed with VMS will run on MicroVMS without modification.
The VMS Operating System gives you extensive online help. You can receive
help by using the HELP command. The HELP facility provides you with information on the syntax used to invoke the languages, selVices, and utilities supported by the system. In many instances, HELP text also includes examples that
use those commands. Besides being able to access HELP at the operating system
level, many of the software products that run on VMS have their own HELP
facilities that can be accessed while using those software products. For
example, HELP can be requested from within VMS editors, the VMS Mail utility, and some language development environments.
.
THE VMS OPERATING SYSTEM
Memory Management Facilities
° Physical Memory Resource Allocation
- Pager
- Swapper
• Process
° Image

Process and
Time

Data StructurEls

° Page Tables
o. 1/0 Database .

° l>ch~duler Data
1/0 Subsystem
• Device Drivers
° 1/0 Support Routines

Process and Time Management
o· Scheduler
o. Process Control
VMS. Help Facility

Figure J-2 • The VMS Operating System
For more information on the VMS operating system, see the VMS System Software Handbook and VAXIVMS Internals and Data Structures*.

*Kenah and Bates, 1984, The Digital Press, Order no. EY-OOQ14-DP

1-6. The VAX/VMS Software Development Environment

The VMS Services
Complementing the operating system· are four layers of seMces essential for
bqsic system operation and program development. These are called the VMS
seMces and include
~ The Digital Command Language (OCL),

• The VAX Runtime Library (RTL).
• TheVAXRecord Management SeMces (RMS).
• The VMS System SeMces;

VMS SERVICES
• The Digital Command Language (DCL)
• VMS Runtime Library (RTL)
• VMS Record Management .
Services (RMS)
• System Services

Figure 1-3 • VMS Seroices

• TIlE DIGITAL COMMAND LANGUAGE
The Digital Command Language (OCL) is the language through which you
communicate with the VMS operating system. DCL contains an extensive set of
commands that allows you to
• Develop and execute programs.

• \Xbrk with files and directories of fileS.
• Obtain information about your VAX!VMS system. .

• VMS RECORD MANAGEMENT SERVICES(RMS)
VAX Record Management SeMces (RMS) are used by programmers to handle II

o within a program. RMS routines are system routines that provide an efficient
and flexible means of handling files and their data, and allow sharing of files
across languages.

1·7

RMS is the default VO service for all VAX languages. VAX languages in the VAX
Common Language Environment use identical representations for many data
types. Therefore, @es associated with a prpgram written in one VAX language
can be read and used by another program, even if it is written in a different
language. VAX RMS can also be used with Digital's DECnet-VAX software to
manipulate @es across many VAX systems. (For more on using RMS with Digital
Network Architecture products, see the VMS System Software Handbook,
Chapter 6.)
The RMS Utilities and a File Definitions Language (FDL) complement RMS
procedures by providing additional capabilities for creating and maintaining
RMS@es.
For more information on VAX RMS see Chapter 4 of this handbook.

• TIIE VMS RUNTIME LIBRARY (RTL)

The VMS Runtime Library's,set of language.independ~t procedures reduces
the time. it takes you to design and implement an application program. These
procedures can be called from any language iri the VAX Common Language
Environment.
Because application programs can call VMS general·purpose routines (data
management, for example), you can skip designing many of those elements and
concentrate on the central application.
The Runtime Library provides runtime support for VAX high,levellanguages.
All procedures in the Runtime Library follow all standard call and condition
handling conventions.
The common Runtime Library provides language·support procedures general
string manipulation, VO andVO conversions, terminal-independent screen
handling, and many more procedures.
For more inforination on the VAX RTL, see Chapter 4 of this handbook.

VMS Program Development Utilities
A few of the many VMS program development utilities include
• VAXTPU (text editor)
• EDT (text editor)
• DSR (text formatter)
• VAXIVMS Symbolic Debugger
• VMS Linker
• VMS SortlMerge
• Other program development utilities

/-8 • The VAX/VMS Software Development Environment

• VAXTPU (Text Processing Utility)
• EDT Text Editor
• DSR Text-Formatting Utility
• VAX Debugger
• Linker ,
• Sort/Merge
-librarian
• Other Utilities

'c--:::::==::::::::___

Figure 1-4· VMS Program Development Utilities
"

• VAXTPU(TEXT PROCESSING UTIU1Y)
VAXTPU is a high-performance programmable text processing utility. VAXTPU
is a tool designed to aid application and system programmers in the develope
ment of text processing interfaces. The utilitY includes a compiler, all mterpreter, al'ligb-level procedural language, and two editing interfaces written in
VAXTPU. One interface emulates the EDT text edit~r while the other was built
based on interactive human factors testing.
You can tailor one of the existingVAXTPU editing interface to suit your editing
style, or you can write your own editing interface with VAXTPU. You can use
VAXTPUto design an intelligent editor for a specific environment;
For more information on VAXTPU, see Chapter 5 of this handbook.

• TIIE EDT TEXT EDITOR
EDT is Digital's easy"to-learn editor ideally suited for the novkeor general-pur-

pose user. In line mode, you can issue commands to EDT to change a single line
of text or many lines; In keypad mode, EDT is a character:oriented editor and
enables advanced users to edit any form of ASCII @es - program source @es,
- manuscripts, or correspondence. Because EOT is keypadoriented,it,does -9,ot
require an entire line of tt;xt to be replaced each time a9Iaracter is changed.
EDT also has an extensive HELP facility, which is av3.ilable online during an
editing session.
For more information on the EDT Text Editor, see Chapter 5 of this
handbook. '
,

1·9

• TIlE DSR TEXT-FORMATTING UTILI1Y
Digital's Standard Runoff (DSR) text-formatting utility extends the basic functions of VMS's text editors into a sophisticated text processing system, ideal for
creating and maintaining the extensive documentation necessary to support any
program development effort. With DSR's powerful command set, you can create documentation ranging from a simple form letter to a multichaptered
manual.
For more information on the DSR Text-formatting utility, see Chapter 5 of this
handbook
• TIlE VAX SYMBOLIC DEBUGGER UTILI1Y
The VAXlVMS Symbolic Debugger utility is a powerful and flexible tool that
aids you in locating errors in programs.
The DEBUGGER
• Is interactive. You can execute debugger commands from your terminal and
see their effects immediately.
• Is symbolic. You can refer to program locations by the symbols you used for
them in your program.
• Supports many languages. If your application is written in more than one Ian·
guage, you can change from one language to another in the course of a debugging session.
• Permits a variety of data forms and types for entry and display.
• Allows you to select and display your program's language statements.
• Has a screen mode that provides multiple windows for screen-oriented
debugging.
• Has a debugger-defined keypad key definitions for many types of terminal's
numeric keypad.
• Provides online help.

1-10 • The VAX/VMS Software Development Environment

See Chapter 5 of this handbook for more information· on the VAXlVMS Sym- .
bolic Debugger.
Other VMS utilities us~ for program deVelopment include
• The Linker Utility (LINK) .
•. The SORTIMERGE Utilities:
• The LIBRARIAN Utility.
• TheCommand Defulltion utility (CDU).
• The MESSAGE Utility.
• The DIFFERENCES Utility.
• Other VMS program d~elopment utilities.
~ Chapter 5 of this handbook for more information on each of these and
other VMS utilities. For a discussion of the VMS system management utilities,
see the VMS System SoftwareHandbook.

Optional VAX Program Development Products
• VAX LANGUAGES
At the center of the VAXlVMS software development environment is. the family
of VAX programming languages. Applications and system programmers have a
diversified range of higher-level progranuning languages at their disposal. In
addition to the assembly-level language, VAX MACRO, VAX programming languages range from Ada to RPG II. For an indepth coverage of each of the languages introquced below, turn to Chapter .3 of this handbook.

1-11

Other VAX
Languages L---1,...J,.,-::-L-,..?I

OTHER VAX LANGUAGES
OPS5·
LISP

C-ELN
.CORAL

DSM
PASCAL-ELN

Figure 1-5 • VAX High-Level Programmzi:lg Languages

VAX AM - Ada is a m,o.dem, higher-order progrllmming language designed
as II result of a competition spoJ;lsoredby the UJ;lited States Department of"
Defense. Although Ada. has now become the single programming lang\l3ge'.
for all missi~n-critical Department9f[)efense software, it is also.well.suit~d
to many civilian applications; such as CAD/CAM, or process control. Ada is
ideal for large applications that must be developed and mrul1tainedbYffillJ;lY
programmers.

VAXApL - VAX APL (A Programm,ing LmgulIge) is a compact arid v~atik .
programming langullge that runs on the VAX series of computers.:l'l1iS language
is especially suited to handle numeric and character data organized as lists and
tables. It is useclextensively in such areas as the manipulating of data..th~
designing of systems, .and the computing. of mathematical and sdentJfic
solutions.
.
.

1-12 • The VAX/VMS Software Development Environment

VAX BASIC - The VAX BASIC product gives you the benefits of a highly
interactive programming environment and a high-performance development language that is fully integrated with the VAXlVMS Software Development Environment.
The VAX BASIC language provides a structured language, powerful mathematical and string handling facilities, support for symbolic variable names!debugging, and full RMS indexed, sequential, and relative 110 operations;
VAX BASIC can be used as if it were either an interpreter or a compiler. A fast
RUN command and support for direct execution of unnumbered statements
(immediate mode) gives you the feel of an interpreter.

VAX Bliss-32 - VAX Bliss-32 is a high-level systems implementation language.
The Bliss-32 language supports development of modular software according to
structured programming concepts by providing an advanced set of language
features. It provides access to most of the hardware features of the VAX systems
to facilitate programming of time-critical and hardware-dependent
applications.
VAX C - VAX C fully supports D:lany of the language features of C, as described
in The C Programming Language". VAX C provides program flow control constructs for logical and efficient program structuring, and a rich assortment of
operators and common run-time routines (only those UNIX-specific routines
that cannot be reasonably emulated under VAXlVMS are omirted.) VAX C even
includes language extensions developed since the Kernighan and Ritchie book
was published, including the structure assignment feature.
VAX COBOL - VAX COBOL is a high-performance implementation of COBOL.
It is based on American National Standard Programming Language COBOL,
X3.231974, the industry-wide accepted standard for COBOL. Most features
planned for the next COBOL standard, based on the specifications in the Draft
Proposed Revised X3 .23 American National Standard Programming Language
COBOL, are also included.
.
VAX COBOL also supports an embedded Data Manipulation Language (DML)
interface to VAX DBMS, Digital'sCODASYL compliant Datai>ase Management
System. Also, it allows access to common record definitions stored in the VAX
Common Data Dictionary. VAX COBOL's support of features in the next ANSI
COBOL standard, of the VAX Information Architecture, and of .other Digitalde6hed extensions to COBOL makeS possible a wider range! of COBQL app~ca
tions on the VAX..

*by B. Kemighan.andD. Ritchie

1-13

VAX DIBOL - VAX DIBOL (Digital Interactive Business Oriented Language)
is a high-level, procedural language designed specifically for interactive data
processing in the business environment_ It takes full advantage of the VMS
system's facilities_
VAX DIBOL is based on the DIBOL Standards Organization's DIBOL-83 definition of the language_ VAX DIBOL is highly compatible with DIBOL-83 implementation on other operating systems_
VAX DIBOL consists of a DIBOL compiler, a sharable runtime library, a program
debugging aid called the DIBOL Debugging Technique (DDT), and a set of uti!ityprograms that facilitate data handling, data storing, and interprogram
communication_

VAX DSM - VAX DSM (Digital Standard MUMPS) is a user data management
and language processing system_ The DSM language is a high-level, interpretive
language well suited for the processing of variable-length string data. It conforms to the American National Standard MUMPS specification Xl1.1-1977.
VAX FORTRAN - VAX FORTRAN is a high performance, industry-leading
implementation of the FORTRAN language. VAX FORTRAN is based on the
American National Standard FORTRAN X3.9-1978 (commonly called FORTRAN-77). The VAX FORTRAN compiler supports this standard at the full-language level. Also, it provides full support for many industry-standard
FORTRAN features based on FORTRAN-66, the previous ANSI standard. The
qualifier /NOF77 will select the FORTRAN-66 behavior where the two standards conflict.

VAX USP - For the past 20 years, the LISP programming language has been
associated with artificial intelligence (AI) research. The LISP ("LIS"t
"P"rocessing) programming language is based on a paper, published in 1958 by
John McCarthy, dealing with non-numeric computation. It differs from the
majority of higher-level programming languages in that LISP programs do not
use numeric computation as a basis for program execution (although it does
support facilities for numeric computation).
LISP is particularly useful for the manipulation of symbolic data. Symbols can
be thought of as words; lists of symbols are then equivalent to sentences or
statements. Because LISP's symbolic processing and knowledge representation
capabilities can be used to represent human thought patterns and associations,
the LISP programming language has become an essential tool for researchers as
they attempt to make computers simulate human behavior and thought.

1-14 • The VAX/VMS Software Development Environment

VAX Ihsca/- VAX Pascal is a multipass, optimizing compiler that is a powerful superset of the Pascal language as defined by Jensen and Wirth in Pascal
User Manual and Report (1974). VAX Pascal accepts programs that are compatible with either the ANSIIIEEE 770X3.97 standard or the ISO standard
(DIS 7185).
Pascal's block structUred nature, flexible data types and English,like stat~ments
result in significant ease-of-use benefits. These benefitS include ease of program
generation atld ease of reading, modifying, and maintaining programs.

VAX PUI , VAX PLlIis an extended implementation of the General Purpose
Subset (X3.74-1981, "SubsetG") ofANSIPLII, X3.53 -1976. PLlIwas designed
to be useful in scientific, commercial, and system programming, especially on
small and medium-sized computer systems. The goals of the design of Subset G
were to include features that are easy to learn, easily portable from one computer system to another, to exclude sddom used features that increase runtime
complexity.
VAX RPG II - RPG (Report Program Generator) is a powerful, business-oriented language specifically oriented togeiJ.erating a wide variety of simple and
complex business reports; RPG is a partially nonprocedural language, and is
therefore not. suited to all business applications. However, where it's
appropriate, RPG can significantly increase your productivity and greatly
improve turn-around time for generation and @e maintenance application
devdopment cycles.
RPG II is an enhanced version of RPG, which was devdoped by International
Business Machines Corporation in the early 1960s. RPG II incorporates a wide
variety of additional features not present in the original RPG, and provides extra
advantages in simplicity, ease-of-use, and power. RPG II has become a popular
and widdy used bUsiness application language. It is an important language for
many small business users.

• VAX PRODUCTIVI1Y IDOLS
VAX productivity tools hdp youwrite,cdmpile, link, and maintain systeiIis'and
applications designs by addressing multiple phases of the software devdopment life cycle. For more on VAX Program Devdopment Productivity Tools,
turn to Chapter 2 of this handbook.

1-15

VAX PROGRAM DEVELOPMENT
PRODUCTIVITY TOOLS

~
) J

Programming Tools

1. Interface to VAX/VMS
SymbOlic Debugger
(See Chapter 5)

Project Management
Tools

II
\7

PROGRAMMING TOOLS

1. VAXIVMS Symbolic Debugger
2. Language-Sensitive Editor
3. Performance and Coverage Analyzer (PCA)
PROJECT MANAGEMENT TOOLS

4 .. DEC/Code Management System (CMS)
5. DEC/Module Management System (MMS)
6. DECIlest Manager
GRAPHICS TOOLS (For device-independent .
graphics application programs)

7. GKS

8. DECOR

Figure 1-6 • VAX Program DevelopmentProductivityTools

1-16 • The VAX/VMS Software Development Environment

VAX DEC/CMS - VAX DEC/Code Management System (CMS) is a program
librarian for the development and evolution of application software in the
VAXlVMS Software Development Environment. It comprises a set of commands that enables software developers to cooperatively manage the files of
ongoing projects. A few of the many operations CMS performs are
• Storing ASCll files in a project library.
• Maintaining a history of an-library modifications.
• Managing concurrent modifications.
• Identifying and "freezing' software for release or rriilestones.

VAX DEc/MMS - Digital's VAX Module Management System (MMS) is
designed to manage ·system builds' for developers during day-to-day development, imple.mentation, anc,l maintenance of a software system.
In the development of a large softWare system, many of the dependent modules,
of whiCh the system is made, are typically in various states of completion. VAX
DEClMMS dctermities whiCh modules need to be reCompiled, and ensures the
software system is recompiled and linked withall'the latest changes. VAX DEC!
MMS can also interact with VAX DEClCMS and extract files from CMS libraries
when building a software system.
VAX DEC/Shell - VAX DEC/Shell is an optional software product that allow
programmers, familiar with UNIX V7, to operate in the VAXIVMS Software
Development Environment with a command language and utilities based on
the Bourne Shell.
When using the DEC/Shell, you are not just limited to its commands and utilities. All the power and features of the Digital~ommand language (DeL) are also
available. For example, you can use DECIShellto write a command procedure
with "Shell' and DCL commands. One important feature of the DEC/Shell that
allows you to mix commands in pipelines.
The three major components of VAX DEC/Shell are the command-line interpreter, utilities, and the Shell script language.
VAX DEC/Test Manager - Testing is a necessary and costly part of software
development. VAX DECITest Manager manages the testing process to help you
produce higher-quality products with less maintenance.
VAX DECI1est Manager is an automated regression testing system. That is, it
automatically executes user-defined tests on existing software products and
compares the test output against the product's benchmarks to determine if the
software is perfortning as expected. It gives you the flexibility to organize and
select tests for execution, run those tests, and in verifying and review the results.

1-17

VAX DEClTest Manager makes software maintenance more manageable and
helps you during the implementation of an application program_ You can insert
specific tests into a group and to then call those tests (or those of other programmers) independently_

VAX Language-Sensitive Editor - The VAX Language-Sensitive Editor is a
multilanguage, multiwindow, screen-oriented editor designed specifically
for program development. It is "language sensitive" in that it provides you
with information on all the VAX languages it supports_ It gives you full access
to detailed templates of all of the major constructs in each of these
languages_
The VAX Language-Sensitive Editor works with many VAX languages and the
VAX Debugger and VAX R:rformance and Coverage Analyzer. Within a single
editing session you can write code, edit, compile, and review and correct compilation errors. You can customize and extend the editor to meet your unique
programming needs.

VAX /+r/ormance and Coverage Analyzer - The VAX R:rformance and Coverage
Analyzer is a program development tool for measuring and tuning the performance of user-mode applications programs. It also measures test coverage, showing that routines, lines, or even individual code paths in a program are executed
by a given suite of test input.
The VAX R:rformance and Coverage Analyzer consists of two parts: A Collector that collects performance or coverage data from a running program, and the
Analyzer that later processes the data to produce various reports. The Collector
can collect program counter sampling data, page fault data, system service
counts, I/O usage data, exact execution counts at specified locations, and test
coverage data. The VAX R:rformance and Coverage Analyzer is fully symbolic
and can be used with all languages that have VAX Debugger Support.

VAX GKS - VAX GKS is a productivity tool for developing device-independent
graphics applications. VAX GKS is ideally suited for writing applications to be
used in automotive, CAD/CAM, chemical, educational, environmental, and scientific areas.
With VAX GKS, you can create one application program for many different
graphics I/O devices. No longer do you have to recode applications every time a
new device is incorporated into your computing environment.
VAX GKS is based on the ANSI and ISO graphics standards. VAX GKS, Level Ob,
provides basic output and input capabilities.

1-18 • The VAX/VMS Software Development Environment

VAX DECOR - VAX DECOR is a graphics subroutine package that provides
an interface between an application program and graphics devices. The
interface is device-independent and supports user-developed device handlers, as well as those supplied with VAX DECOR.

VAX DECOR is Digital's implementation of the SIGGRAPHIACM Graphics
Standards Planning Committee's CORE proposal. It provides a device-independent interface between an application program and supported graphic devices.
• RELATED VAX PROGRAM DEVELOPMENT PRODUCTS
These products include VAX information management capabilities, which are
needed for the implementation of database applications, for example.

• VAX Common Data Dictionary (CDD)
• VAX Database Management System (DBMS)
• VAX Relational Database Management System (RdbIVMS)
• VAX Datatrieve
• The VAX Terminal Data Management System (IDMS)
• The VAX Forms Management System (FMS)
• The VAX Application Control & Management System (ACMS)
Products used to develop applications for other target systems include

• VAXELN
• VAX-llRSX
• MicroIbwerlPascal-VMS

1-19

1, VAXCDD
2, VAX DBMS
3. VAX Datatrieve
4. VAX RdblVMS (ELN)
5. VAXACMS
6. VAXTDMS
7. VAX FMS
8. DECnet Communication Products
9. VAXELN
10. VAX-11 RSX
11. MicroPower/Pascal-VMS

Figure 1-7· Related Program Development Products

VAXACMS

VAX ACMS, the VAX Application'Conitol'and Managemeni:Systeiri, wa~
designed'to,~uce the lifecyde costs involved in designing, developing, maintaining and controlling transaction processing and other complex VAXNMS
applications
'

Un1ik~ ttaditioruil application devdopmeJIt tQp1s, ACMS allows for the replacement of large amounts of application code with high level definitions stored in
the VAX Common Data. Dictionary. WIth the use of such definitions, users pow
have available a fourth generation-like language facility that can significantly
reduce the development and maintenance lifecyde costs of large, complex software projects.
Fotmore on VAX ACMS, see the VAX In/ormation Management Handbook.

1-20 • The VAX/VMS Software Development Environment

VAX COMMON DATA DICTIONARY (CDD) - The CDD is a centrallocation for the storage of data definitions used by many VMS software products.
The CDD is required when using VAX DATATRIEVE, VAX RdbIVMS, VAX
TDMS, and the VAX ACMS product set. The CDD can be used in conjunction
with most. VAX programminglap.guages, which access record definitions in
the CDD at compile time.
Using the CDD you can
• Create sharable definitions with a data definition language (CDDL) that can
be understood by many VAX programming language compilers and several
other VAX Information Architecture Products.
.

• Modify data definitions in the dictionary without editing the programs and
procedures using the definitions, as long as you don't ddete fidds or change
their names.
• Specify which users have access to individual definitions, using thirteen sepacilte access privileges and four possible user identification criteria.
• Copy definitions at compile time into a program written in one of the VAX
programming languages.
• Document the use of a particular definition by making entries into the definitions' history list.
• Maintain an area of the dictionary for the storage of data definitions for privileged use.
rOf mQre on the CDD,
s~
the VAX
In/ormation
Management
Handbook.
., .
.
.
.
'
~,

VAX DATABASE MANAGEMENT SYSTEM (DBMS) - VAX DBMS is
Digital's CODASYL-compliant datab~se management system. VAX DBMS
provideuophistica~edcapabilities forcrtfating, accessing,. and maintaining
large databases. The major advantages ofVAX DBMS are lis 'efficienCy and its
ability to coittroltbe sl:iaring Of the saine data by a large nUrllber of users, all
ilsingthe system at: the same time. .
,

1-21

VAX DBMS is also compatible with other VMS software products_ You can
access a VAX DBMS database from any application program written in a highlevd language that conforms to the VMS calling standard. This is accomplished
through interface to VAX DBMS, called Database Query (DBQ).

With VAX DBMS, you can
• Create and maintain multiple databases.
• .Separate data definitions from the applications programs that use them.
• Centralize all data definitions from the applications programs that use them.
• Define useful relationships between records.
• Separate data definitions from data storage.
• 'Thilor user views of data.
• Centralize the administration of data.
• Maintain data integrity and security.
• Allow conciIrrent access to databases.
For more on the DBMS, see the VAX In/ormation Management Handbook.

VAX RELATIONAL DATABASE MANAGEMENT SYSTEM (VAX Rdb/
VMS) - VAX RdblVMS provides facilities for creating, accessing, and main~
taining relational databases. In a rdational database, data is stored in the
form of two-dimensional tables, instead of in the form of complex hierarchies or networks. VAX RdblVMS provides all the advantages of a full-feature
database management system, including data security and optimized data
access. At the same time, it provides easy -to-use features inherent in a rdational-style database.
VAX RdbNMS is easy to use and understand. With it, you maintain and create a
database without the services of a professional database administrator.

1-22 • The VAX/VMS Software Development Environment

Two VAX Rdb products are currently available - VAX RdblVMS and VAX Rdbl
ELN. VAX RdblVMS runs on the VMS operating system; VAX RdblELN, on the
VAXELN system.
With VAX RdblVMS you can
• Create and maintain relational databases.
• Store and retrieve data.
• Separate data definitions from the application programs that use them.
• Store all data definitions either in the database files or in the VAX Common
Data Dictionary (CDD), for common use and maintenance.
• Establish dynamic relationships between records.
• Tailor user views of data.
• Centralize the administration of data.
• Maintain data integrity and security.
• Use a database concurrently with other users.
• Ensure against data inconsistency during concurrent updating.
• Recover from errors and/or inadvertent terminations.
For more on the RdbIVMS, see the VAX In/ormation Management Handbook.

1-23

VAX DATATRIEVE - VAX DATATRlEVE is an easy-to-use tool for managing
and manipulating data either interactively at a terminal or from an applications program_ If you know as few as ten simple, English-like commands and
statements, you can interactively retrieve, store, modify, and sort data, and
report on it in meaningful ways_ With VAX DATATRlEVE, you can
• Create data definitions that can be used to store and retrieve data uniformly,
either interactively or from application programs
• Store or modify data in RMS files, VAX DBMS databases, or VAX RdbNMS
databases.
• Retrieve data from RMS files, VAX DBMS databases, or VAX RdblVMS
databases and display the data on a terminal, write it to a data file, or print it.
• Produce formatted reports using specified selections of data display or data
collection.
• Create pie charts, bar and line graphs, and plots based on specified selections
of data.
• Use forms to format the terminal screen for data display or data collecting.
• Use a text editor to correct syntax errors and typing mistakes..
• Access data files located on remote systems.
• Call VAX DATATRlEVE functions (including data access) from a program
written in a high-level VAX programming language such as COBOL,FORTRAN,or PLiI.
For more on VAX DATATRlEVE, see the VAX In/ormation Management
Handbook.

VAX TDMS - Digital's VAX Terminal Data Management System (TDMS) is a
productivity tool designed to reduce the high life cycle costs of developing
and maintaining forms-intensive terminal applications on VAXIVMS
systems.
TDMS offers you a wide range of features that make it easy to develop applications to display and collect information. TDMS also eliminates many of the burdens associated with conventional forms-based application design and
implementation.
TDMS provides an interface for defining the data exchange between screen(s)
and program(s). It replaces the often cumbersome coding of program/screen
interaction with definitions, which are stored independently in the VAX Common Data Dictionary.
For more on VAX TDMS, see the VAX In/ormation Management Handbook.

1-24 • The VAX/VMS Software Development Environment

VAX FMS - The VAX Forms Management System (FMS) is designed to aid in
the development of application programs that use video forms, FMS.man~
ages theseforms for application programs that use Digital's family o£VTlOO
and VT200 compatible terminals. Forms d~ned using YAX: FMS provides
you with the following features of those. terminals.
• Individual character attributes of reverse video, bold, blinking,and
underline.
.
• Line attributes ofdollble-width, double-height, and scrolling.
• Screenwide attributes such as 80- or 132-column lines and reverse videO.
• Alternate character sets including the VT100 special graphics character'set for
line drawing.
For more on VAX FMS, see the VAX Information ManagementHandbook:

VAXELN - The VAXELN Toolkit offers you a unique altertlative to the complex
productivity problem ofrealcime applialtion development. The V~N Toolkit letS you program in an extehded version of Pascal or C,With all the highlevel, easy programming featureSfoufid in both the VAX languages..
The VAXELN toolkit is an optional product that supports the development of
standalone, statically defined softWare systems (VAXELN systems) that run on
the entire range of VAX processors, ~ncluding the MicroVAX
supermicrocomputer. VAXELNsystem~ are developed under W4S, then run on
the target system as a standalone system, without VMS present;
Typical applications include industrial automaPon, Ethernet server networks,
arid networks in which mdividual proc~sors have dedicated functions and are
not needed simultaneously for general computing, for which a general operating system, like VMS, is not necessary.
For more ipformation.on VAXELN, see Chapter 6 ofthjs handbook.

1-25

VAX-ll RSX - VAX-ll RSX is an emulator for RSX-ll operating system family
and executes on all VMS and MicroVMS systems_ It runs in compatibility mode
on processors that support a PDP-ll instruction set subset in hardware or
microcode and it also runs on certain processors without this support by providing its own software emulation ofthe same PDP-ll instruction set subset. It
provides special capabilities that enable you to develop programs for execution
in any of the following enviro111TIents:
• VAXNMS compatibility mode
• MicroVAX IIIMicroVMS (software-emulated compatibility mode)
• VAXstation II1MicroVMS (software-emulated compatibility mode)
• RSX-11M -PLUS
• RSX-llM
• RSX-llS
• Micro/RSX

• P/OS
VAX -11 RSX also allows for the migration of many existing RSX-11 applications
to VAXNMS and MicroVMS.
For more information on this product, see Chapter 6 of this handbook.

MicroPowerlFhscal-VMS - MicroPoweriPascalNMS is a VAXlVMS optional
program development product. MicroPower/Pascal is a modular executive
and software development package JorPDP-ll(Q-bus) based microcomputer applications. It includes software components needed to create, build
and debug/test concurrent realtime application software that runs standalone on a target runtime microcomputer system.
For more information on this product, see Chapter 6 ofthis handbook.

Chapter 2 • VAX Program Development Productivity Tools

• Overview
VMS's program development productivity tools help extend your productivity
beyond the range of VMS services and program development utilities and VAX
languages. Because all of these tools are designed to function within the VMS
Software Development Environment, they greatly simplify the development of
application programs.
As Figure 2-1 illustrates, VAX productivity tools enhance the programmer's
ability to write, compile, link, and maintain systems and applications designs.
Besides serving as the basis for all development work done by VMS programmers, a subset of these tools, the VNXproduct ser, give ULTRIX and UNIX programmers the ability to access the VMS productivity environment with many
commands, utilities, and too~ that are similar to those they use to write programs on the UNIX or ULTRIX opera,tingsystems.
The development tools discussed in iliis· chapter are:.
• VAX DEc/CMS (Code ManagementSystem)
• VAX DEc/MMS (Module ManagementSystem)
• VAX DEC/Shell
• VAX: DECfI'est Manager
• The VAX Language-SensitiveEditot.
• TheVAX Ibfotmance and Coverage Analyier.:
• VAXGKS

2-2 • VAX Program Development Productivity Tools

This Chapter Covers the
VAX Program Development
Productivity Tools

~
VMS provides programmers with a
growing environment of
7
8
productivity tools that enhance
programming and project management
productivity.
VMS also provides programmers
familiar with UNIX the power
and versatility of VMS through
our VAX DEC/Shell and other VAX
tOOIS'

~
"'0
6.
.

9 VAX DEC Shell

'-r'~

) J

Programming Tools

1. Interface to VAXIVMS
Symbolic Debugger
(See Chapter 5)

Project Management
Tools

PROGRAMMING TOOLS

1. VAXIVMS Symbolic Debugger
2. Language·Sensitive Editor
3. Performance and Coverage Analyzer (PCA)

GRAPHICS TOOLS (For device-independent
graphics application programs)

7. GKS
8. DECOR (Not covered
in this chapter)

PROJECT MANAGEMENT TOOLS
4. DEC/Code Management System (CMS)
5. DEC/Module Management System (MMS)
6. DECITest Manager

Figure 2-1 • Overoiew Of Chapter 2

2-3

• VAX DEc/CMS (Code Management System)
VAX DEC/CMS is a program library system that members of a software project
use as an aid in program organization, development, and maintenance. CMS is a
tool that allows project members to do the following with minimal change in
work habits:
• Gain a more comprehensive view of project development
• Continue to maintain early versions of programs while working on current
project development
• Communicate project information more easily
• Control multiple versions of the same software
• Have a complete history of project software
Designed to run under the VMS operating system, CMS provides a method of
storing ASCII files. CMS maintains these files in project libraries. A library is a
subdirectory. Once a library has been built, project members can retrieve copies of files from the library, work on them using any standard editor, and then
replace them in the library. CMS keeps the original versions of the library files
and integrates any subsequent changes. CMS also allows more than one project
member to work on the same file at the same time without losing the modifications made by any project member.
As project development continues, CMS tracks changes to a project library by
storing the changes made with each retrieval and replacement file in the library.
As a result, CMS can reconstruct any previous version of a project file.
In addition to storing successive changes to library files, CMS monitors library
access. CMS enhances communication among project members by maintaining
both a record of who is currently working on a library file and a historical
record of library access. By entering CMS commands, project members can easily retrieve information about library transactions and contents.

2-4 • VAX Program Development Productivity Tools

VAX DEc/CMS Features
You can perfonn the following operations with CMS commands: .'
• Put a file ina library
• RetrieVe a file or files from a library for modification' , " .'
• Retrieve a file or files from a library for read-only purposes
• Group any selectio~ of files to access them together'
• Reconstruct any mil~stoneof Ii project by getting the versions of those files
used in the construction of that milestone
.. Detennine whether any other user is working on a file before you retrieve it
• Place library filesinta "classes" at any phase of development to represent
milestones
.
.
• Merge concurrent modifications to a file
• Obtam historicai infonnation' about all ttarlsactions that update the library
together with transactions that involve retrieving read-only copies of library
files, and the transactions associated with a particular file
• Obtain information that describes the organization of library files
• Obtain listings of anyfile stored in the library that shows:
any stage of development of the file itself
- the file history
- . when each line of changes were incorporated fita the file and py whom
• Compare two Asalfiles in yourworkingdirectoryor library
CMS also haS a callable interface available. CMS provides an on-line help facility
for infonnation on library structure, commands, syntax, and other relevant
topics.

Using VAX DEC/CMS
To create a CMS library, you need to create a subdirectory, and the CMS
CREATEILIBRARY command. Once your library has been created, use the
INSERT command to put copies of your programs (files), documents, and/or
tests into the library. These files are termed "elements: and can be managed by
the use ofvarious CMS commands. For an example of how CMS is used in the
implementation of a software program, see Chapter 7 of this handbook.

2·5

When you want to modify an element, you use the CMS RESERVE command to
retrieve a copy of the element file from the library. When you reselVe an element
from the library, CMS places a copy of the element in your default directory and
marks the library copy as reselVed by you. As long as you have the element
reselVed, CMS notifies any user who tries to reselVe, retrieve, or replace that
same element that you are working on it. (If you do not intend to modify an
element, CMS can retrieve an element without reselVing it.)
You can use any standard editor to work on files that you have reselVed. When
you have finished working on an element, you replace it in the library with the
CMS REPLACE command.
Each time you create an element by loading a file into a CMS library, CMS cre·
ates the first generation of the element. Figure 2·3 is a symbolic representation
of a newly created element, TEST FOR.
Every time you reselVe and then replace the element, CMS creates a new ele·
ment generation and gives it a unique generation number. CMS can store up to
600 generations of an element. CMS is an efficient file storage system because it
keeps only the differences between successive file versions. Lines that are dupli·
cated from generation to generation are not stored. Figure 2·2 illustrates
element TEST.FOR after one reselVation/replacement cycle.
CMS allows access to any generation of an element. Because CMS keeps track of
file modificatkms according to the succession of generations, you can reselVe
any generation of an element.

• CONCURRENT DEVELOPMENT
CMS handles concurrent development of the same element by allowing you to
establish alternate development paths, called lines of descent, for an element.
CMS maintains the separate lines of descent and allows you to merge them
when necessary during development. Generation 1 and 2 of element TEST FOR
(Figure 2·2) are on the main line of descent.
Because a concurrent reselVation might result in conflicting changes, CMS does
not allow more than one user to replace a concurrently reselVed element on the
same line of descent. In this case, one user can replace the element and create a
new generation on the same line of descent. Each other user who has this gener·
ation reselVed must create a variant generation. Figure 2·2 shows element
TESTFOR after two users have concurrently reselVed and replaced it.

2-6 • VAX Program Development Productivity Tools

Test For

(a)

(b)

(c)

Figure 2-2 • Element TEST.FOR with Main Line and Variant Generation
You can merge any two generations that are not on the same line of descent.
When you use the eMS RESERVE command with the lMERGE qualifier, eMS
merges the two named generations and from them creates a file in your default
directory. eMS flags any conflicts between the two lines of descent. Once you
have resolved the conflicts, if any, you can replace the element in the library.
Figure 2 -3 shows two lines of descent that have been merged. After testing, the
merged copy was then replaced.
.

Test For

Figure 2-3 • Generation 2Al Merged into the Main Line a/Descent

• CLASSES AND GROUPS
eMS allows you to associate an element generation with others in sets called
classes. For example, you can establish a class named RELEASEl that includes
generation 3 from one element, generation 5 from the second element, and so
on. An element generation can belong to more than one class. Thus you can

2·7

establish classes that reflect milestones in project development. You can
redefine classes for maintenance purposes, even after development has proceeded beyond the milestone. As an alternative, you can freeze a class so that
it cannot be redefined.
eMS allows you to associate simple elements with others in sets called groups.
For example, you can establish a group named DRIVERS that includes all of the
device driver code for your project. A group named utilities might contain all
the project utility routines. A group named SAMS could just be all of Sam's
code.
.

• PROJECT INFORMIITION
eMS provides commands that give information on project history, status, or
library contents. You can direct the output of these commands to a terminal, a
file, or a lineprinter.
eMS maintains a project history that is a record of all transactions that have
updated the library and transactions that have retrieved elements for reading
purposes only. Many transactions allow you to .enter a remark to describe the
reason for using the library. eMS records the remark along with the data, time,
user, and command issued.
The eMS library history provides a record of:
• 'fransactions that created specific element generations
• 'fransactions related to the eVolution of a specific element
• The entire transaction history for the library
You can use eMS commands to create a report that integrates historical information into an element.

• VAX DEClMMS (Module Management System)
VAX DEClMMS is a tool that automates and simplifies the building of software
systems. MMSis useful for building both simple programs, which may have only
one or two source files, and complex programs, which may consist of several
source files, message files, and documentation. It can rebuild all the components in a system, or only those that have changed since the system was last
built. MMS is also easy to use - with one command, you can build either a
small or a large system.

2-8 • VAX Program Development Productivity Tools

MMS handles all the steps that are necessary to build a software system accurately and economically.
MMS runs on the VMS operating system and can be used
• With any VMS-supported compiler.
• To access modules in VMS object-module libraries.
• To access elements in DEc/CMS libraries.
• To access declarations of Forms stored in the VAX CDD (Common Data
Dictionary).
• To access forms in VAX FMS (Forms Management System).
• To build documents.
• To build individual programs or entire systems.

VAX DEc/MMS Features
MMS controls the efficient building of a software system by determining which
components in the system have changed and then creating new versions of only
those files that depend on the changed components.
Figure 2-4 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 file that you want to update. Component B is a source for Component A, and
Components C and D are sources for Component B. (For example, A might be
an .EXE file, B might be an .OBJ file, and C and D might be source or definition
files). The commands that update B(by using C and D) and A (by using the
updated B) are called actions.

2-9

cp
I
I
I

/-4
/ /'

~
I
I
I

0.., "

/
'-

........ ---~---_/

<D MMS checks the revision time of the target (Component A).
® .MMS checks the revision time of the first source (Component B).
@ MMS checks the revision times of Components C and D again~t that of B.
.@) "the times of Components C and/or D are more. recent than tj1al of Component B, MMS

file

updates B aCcording to action lines that you specify in the description
(action lines tell
.MMS what commands to execute to update the components of a software system). " Bis
more recent than C and D. MMS does not do anything to B because it is already
up-to·date.

® Once .Component B is updated, it is more recent than the target. Therefore, MMS updates
Component A.

Figure 24 • HowMMS Buil4$aSoftwa.rgSystem
If the target has beentnodified-since tbesources were last changed, MMS dOes
not take any action to update the target. Instead, it issues a message to infonn
you that the target is already up-to-date.

Using VAX DEClMMS
When you use MMS to build your software system, you usually perfonn two
steps:
1. Create a description file
2. Invoke MMS

The description file contains.rules.that describt: how the.components of your
system are related, and the coJIllllaIldsth!lt .MMS;js to use in building them.
Once,you have created your description file, you can use it every time you
invoke MMS to build your system. In most cases,' you will' need a description
file; however, if your system is very simple, MMS can build it even if you have no
description file.

2-10 • VAX Program Development Productivity Tools

The description file is an ASCII text file that you can create and modify with
any text editor. It contains all the information MMS needs to update your
software system. You can think of the description file as a collection of rules
and instructions that describe how parts of your system are built, and which
parts depend on other parts.
The order in which MMS processes the rules in a description file does not
depend on the position of the rules in the description file. The order is implied
because the output of one step may the input of another step. For example if a
link step uses three object modules, then MMS cannot process the link step until
all three object modules are up-to-date.
You can leave out some steps of an MMS description file because MMS built-in
rules define certain commonly used actions.
When you invoke MMS, it looks in your current directory for a description file
called DESCRIP.MMS, unless you have specified the INODESCRIPTION qualifier to indicate that no description file is to be used. Once it locates the description file, MMS processes it.

MMS allows the "top-down" breakdown of a task. Thus, you can use mnemonic
names at the beginning of a description file to specify the order in which tasks
must be accomplished, and then specify the actions to accomplish those tasks
further on in the description file. With MMS, the structural information is all in
one place, the description file, giving a clear representation of the system.
• DEPENDENCY RULES
A description file contains· dependency rules. Dependency rules tell MMS the
relationships among the files in the software system and specify the actions
MMS is to perform to update those files.
The general dependency rule format is shown in Figure 2-5.
TARGET(S) : SOURCE(S)
ACTION LINE(S)

Figure 2-5· Dependency Rule Format
The target in a dependency rule is the file that is to be updated by MMS. The
source is the file that MMS uses to update the target. (A source in one dependency rule can also be a target in another rule, if it needs to be updated itself
before building its target.) The action lines contain commands that tell MMS
how to update the target using the source.

2-11

Figure 2-6 shows how the relationship between an object file and
source @e is expressed as a dependency rule.

aBASIC

TEST.OBJ : TEST.BAS
BASIC TEST

Figure 2-6 • Sample Dependency Rule
The dependency rule in Figure 2-6 tells MMS that it should execute the BASIC
command to create TEST.OBJ from TEST.BAS.
lOu usually have more than one dependency rule in a description @e. The number of rules depends on the size of your system. When MMS processes a depend~ncy rule, it uses the last-revision dates of the target and source @es to
determine whether the target should be updated. (The revision date indicates
the date and tinle the @e was mosuecently changed.) If you have not changed
any of the source @es since the last time the target was built, MMS does not
execute thedeperidency rule action line(s). If, however, you have changed any
of the source@es, MMS executes the action line(s) to make the target up to date.
MMS includes several default dependency rules, called built-in rules, that allow
MMS to automatically build targets that depend upon sources Written' in
VAX/VMS-supported languages. In addition, you can write your own
user-defined default rules.

Compatibility in the VMS Environment
'rou can use MMS to access @es that are contained in VMS object-module librar:
ies. You can also use MMS to create librarY@es, usingcer.taht built-iQ,ruiesthat
apply only to VMS libraries.
:.;

If VAX DEC/CMS (Code Management System) is installed on your system, you
can uSe MMS to acc~ elements in eMS libraries. MMS provides built-in rules
that apply only to CMS library access. From the MMS command line, you can
control whether MMS automatically looks for elements in a CMS library when: it
processes a description@e. You will probably want to keep your description@e
in a CMS hbrary so you can keep;track of the changes in dependencies of your
system. MMS can access the correct generation of the description @e in a_ CMS
library.
If the VAX CDD (Common Data Dictionary) is installed on YOllr sYstem, you Can
use MMS to access records stored the CDD. MMS provides built-in rules that
-apply only to CDDrecord access. If VAX EMS (Fo~sMariagement System) is
installed in your system, you can use MMS to. access forms stored in FMS librare
ies. To specify an FMSform in a dependency rule, use the@etype .FLB after the
library name. The default file type for FMS forms is .FRM.
For an example of using VAX DEClMMS in the implementation of a softwar~
program, see Chapter 7 of this handboOk.
-

2-12 • VAX Program Development Productivity Tools

• VAX DEC/Shell
If familiar with a UNIX program development environment, VAX DEC/Shell
gives you the capabilities of the Bourne shell and many utilities from the UNIX
V7 system. VAX DEC/Shell provides an alternative command line interface to
the VMS operating system.
VAX DEC/Shell:
• Gives you more than 50 of the most commonly used UNIX utilities
• Is not a UNIX emulator on VMS. It is integrated with VMS. DEC/Shell and
VMS commands may be freely intermixed, even on the same command line.
There are three major components of the DEC/Shell: the command-line interface, the Shell script language, and common utilities. When combined, these
components provide a program development environment familiar to users
experienced with UNIX V7 system.

VAX DEc/Shell Features
DEC/Shell includes:
• The UNIX V7 Bourne Shell
• A large number of UNIX utilities
• Pipes
• Input/output redirection to and from files
• A UNIX file syntax emulator

• A Shell runtime library
DEC/Shell also provides access to DCL commands and VMS programs. This
capability allows users familiar with the UNIX V7 system to take advantage of
the VMS operating system while working in a familiar programming
environment.

Using the VAX DEC/Shell
You can invoke the Shell from the OCL level or you can make the Shell your
default command interpreter when you log in.
To invoke the Shell from OCL, you use the SB\WN command with the ICLI
qualifier:
$

SPAWN/CLI_=SHELL

This command creates a subprocess with the DEC/Shell instead of DCL as the
command interpreter. In this subprocess, you can perform many of the tasks
you would do on a UNIX V7 system.

2-13

To make the Shell your command interpreter when you log in, you can
type fCLL = SHELLINOCOMMAND after your name at the username
prompt when logging into the system (Username:
SMITHfCLL=SHELLINOCOMMAND, for example), or ask the system
manager to make DEC/Shell the default command interpreter for your
account.

The VAX DEC/Shell as a Programming Language
While the DEC/Shell can be used primarily as a command interpreter, it is also a
powerful programming language. Many of the control structures used in the
Shell are similar to those used in the C Language (See Chapter 3 of this handbook). Given the Shell script language, control-flow constructs, and utilities,
you may find that the DEC/Shell is an adequate language for many of your programming needs.

The VAX DEC/Shell Runtime Library
The DEC/Shell includes a runtime library that has routines for UNIX and VMS
file name conversion, along with other general purpose routines. These routines
are intended to minimize difficulties in transporting existing UNIX applications
to VMS.
The Shell runtime library is provided as a convenience for those interested in
transporting UNIX C programs to VMS. It does not provide UNIX call-level
emulation, which is done by.the VAX C language.
.
This section lists' in alphlibetic Qrder the commands and utilities provided· by
the DEC/Shell and briefly describes the functioncOf each." . .

Table2-1- Utilities and Commands
Function
awk

R:rforms actions when lines of files match specified
patterns

basename

Removes file name affixes

cal

Displays a calendar

cat

Concatenates and displays files

Changes your working directory

chmod

Changes protection modes of files

chown

Changes owners of files

cmp

Compares two files

Copies files

date

Displays or sets the system date and tinle
(continued on next page)

2-14 • VAX Program Development Productivity Tools

Thble 2·1 • Utilities and Commands (Cont.)
Command

Function

R!rforms arithmetic calculations

del

Invokes the DeL command parser; also provides a
one-line escape to DeL

diff

Compares two files

diff3

Compares three versions of a file

echo

Echoes arguments on the standard output

Invokes the UNIX line editor

eval

Expands all command-line arguments and exeCutes the
result as a command

exec

Executes a command and exits

export

Passes environment variable to programs and subprocesses

expr

Evaluates arguments as an expression

false

Returns a failure status value

find

Searches directory hierarchies for files

grep

Searches files for a pattern

join

Joins files according to specified relations

kill

Terminates processes

lex

Generates lexical analysis programs

Connects your terminal to another node on the network

logout

Terminates an interactive terminal session

Lists the contents of a directory

Processes macros

mcr

Invokes the monitor console routine (MeR) command
parser

mkdir

Creates a directory

Moves files and directories

Dumps files in octal format or other formats

Formats and displays files

Shows process and system status
(continued on next page)

2-15

Table 2·1 • Utilities and Commands (Cont.)
Command

Function

pwd

Displays the name of your current directory

read

Assigns values from the next line read to the specified
variables

readonly

Prevents variables from being reassigned

Deletes @es from directories

rmdir

Deletes directories

sed

Edits input streams

set

Modifies and/or displays Shell environment characteristics

Invokes another Shell

sleep

Suspends execution for a specified interval

sort

Sorts and/or merges @es

tail

Displays the last part of a @e

tar

Saves and restores @es on. magnetic tape

tee

Writes standard input to standard output, making copies
in@es

test

Evaluates expressions

times

Reports the CPU time used by processes

touch

Updates the last modification dates of@es

11anslates characters

trap

Specifies commands to execute upon receipt of signals

true

Returns success status values

tty

Displays the name of your terminal

umask

Sets and/or displays default@eprotection

uniq

Displays nonrepeated lines in a @e

units

Converts quantities expressed in standard scales to their
equivalents in other scales

wait

Waits for completion of processes

Counts words, lines, and/or characters in@es

who

Displays a list of logged-in users on the system

yacc

Generates LR(l) parsing tables

2-16 • VAX Program Development Productivity Tools

• VAX DEC/Test Manager
The VAX DEC/Test Manager is a tool that organizes software tests and automates the way you run tests and evaluate their results. It provides an efficient
way to organize, run, and store the results of existing tests.
DEC/Test Manager is based on the concept of regression testing. Regression
testing is a method of ensuring that a program being developed runs correctly
and that new features added to a program do not affect the correct execution of
previously tested features.

In regression testing, you run established software tests and compare the actual
test re~ults with the results you expected to get. If these actual results do not
agree with what is expected, the software being tested may contain errors. If
errors do exist, the software being tested is said to have "regressed."

Features of VAX DEC/Test Manager
You can use DEC/Test Manager to create a library area for test result storage.
Test Manager allow~ you to:
• Create descriptions of software tests
• Group these tests descriptions into meaningful combinations for later runs
• Modify or display the test descriptions or groups
• Execute specific tests, groups of tests, or combinations of groups of tests
• Compare the results of each executed tests with its benchmark test results to
determine differences
• View test results interactively
• Update benchmarks as needed

Using VAX DEC/Test Manager
The following two lists detail the steps you might follow in a typical regression
testing procedure; The first describes the regression testing procedure without
using DEC/Test Manager; the second describes the same procedure with
DEC/Test Manager.

2·17

• S1EPS IN REGRESSION TESTING
1. Create tests by writing command files to test your software.
2. Organize your tests.
• Create a mechanism to allow ready access to tests as needed.
3. Run the test:
• If you wish to run a single test, submit its command file to the batch queue.
• If you wish to run a number of tests, create a command file that invokes
each test, and submit it to the batch queue.
• Examine the test results:
- Compare the results to those you would exp~. Note any differences
between the expected and actual results.
For incorrect test outputs, revise the program code to correct the
bugs. Repeat steps 3 and 4 until the test output is correct. Then save
the validated results.
4. Repeat Step 3 whenever you modify the program, or add new code. Then,
compare the current test outputs with the validated test outputs.

• If the current and validated test outputs match, the program being tested
is working correctly.
• If you find unexpected changes in test results, the new program probably
cOntains
or has "regressed."
• Correct the program at)d rerun the tests whose output~ have not matched._
~t this cycle until all reSults are valid. For furureiest runs, use theSe
validated test output~ as references againSt which ·to ~II).Pare the cUrrent
test outputs.

errors,

DECffest Manager automates· steps 2 through 4 described previously..When
you use DECffest Manager, you must still write your own tests and test data,
and create a command file that runs the test. However, DECffest Manager
automates the test of the testing procedure.

2,18 • VAX Program Development Productivity Tools

• STEPS IN REGRESSION JESTING WITH DECITEST MANAGER
1. Create tests by writing command @es to test your software.
2. Organize a DECfI'est Manager system by
• Creating a DEClfest Manager library
• Identifying each test and its related @es to DECfI'est Manager
• Placing tests into groups if you wish to categorize. them
3. Run the test. .
• Use DECfI'est Manager to select the testor set of tests you want to run.
4. Compare current test results with the benchmark results for a test.
• DECfI'est Managetautomatically compares test results with the expected
results (called benchmark@es) for a test. It records any differences in a
DECfI'est Manager-created differences @e.
5. Exanline test results.
• DECfI'est Manager provides an interactive subsystem that lets you immediately access test results. It also gives you the ability i:o group all tests that
gave incorrect results for easy ret~ting.
• If the current and v;mdated test outputs ritatch, the program being tested
is working correctly.
• If you firld unexpected changes in teSt results, the new program probably
contains errors, or has "regressed.»
6. Repeat steps 3 through 5 whenever you modifY the program or add new
code. Using DEClfest Manager, the selection and runrting of tests and the
evaluation ofresults will progress more quickly:

• ORGANIZING JESTS

1?EC!IestManager provides a number of structures for organizing a test systeffi~
The fl.rst of these is the test description. A test. description identifies.1i test to
DECfI'est Manager. It consist of fields whose c6ntents point to @es n~ded to
run the test.
The core of each test description is the template @e. A template@eisaDCL
command procedure that runs a specified test or that is the test itself. Each test
must have a teIpplate @e.
You can optionally specify a test prologue and a test epilogue. These are command procedures that extend the test environment. A prologue is a setup @e
run immediately before the template. An epilogue can function as a cleanup @e
or as a @ter fortest results and is run immediately after the template.

2-19

A variable in DEC/Test Manager is either a DCL symbol or a logical name.
You can use variables in templates, prologues, and epilogues. For example,
by using a variable in place of a particular test name in a template file, you
can use that same template file to run many tests. You must define variables
to DEC/Test Manager in a separate step, and also include them in each test
description that uses them.
)bu can categorize test descriptions by placing them in groups. For example, if
you have several tests that share a similar characteristic or function, such as testing a parser, you can create a group called .9\RSER and place those tests in this
group. A test can belong to more than one group.

• RUNNING TESTS
DEClTest Manager runs tests in batch mode. To run tests with DEClTest Manager, you select the tests you want to run by group or by test description name
and create a collection name for them to identify the tests as a set.
You can supply a prologue or epilogue file for a collection at the time you create
the collection. The prologue file is a command file that runs before the collection tests are run. The epilogue file is a command file that runs after the collection tests are run. You can also supply a default prologue or epilogue file that
will be run with each collection.
Once you create a collection, you submit it through DEClTest Manager to a
batch queue. DEC/Test Manager places the results of each test into an output
file called the result file. The result file contains the output of the test execution
at the time the collection was run.
With DEClTest Manager, it is possible to place a test in more than one collection, thus allowing concurrent use of tests.
DEC/Test Manager automatically compares the result file for a test against its
benchmark file. A benchmark file contains expected test output - that is, test
output you have determined to be correct for purposes of the test. DEClTest
Manager stores the status of the comparison (successful or unsuccessful) along
with any differences in the DEC/1f:st Manager library. If there are any differences between the result file and benchmark file, DEClTest Manager creates a
file called a differences file that stores the differences.

2'20 • VAX Program Development Productivity Tools

• EVALUATING TEST RESULTS
You can evaluate test output files interactivdy with the DEC/Test Manager
Review subsystem.
DECITest Manager generates a result description for each test in a collection. A
result description identifies the output files for each test and indicates the status
of each test. It has the same name as its corresponding test description.
Review allows you to
• Display the status of each test.
• Display or print test results of all related files.
• Create a new benchmark or replace the old benchmark file by updating it
with a result file.
• Place tests in groups while viewing their results. This provides a convenient
method of later rerunning tests.

• The VAX Language-Sensitive Editor
The VAX Language-Sensitive Editor is a powerful multilanguage, multiwindow,
screen-oriented editor specifically designed for program development and
maintenance. The Editor is "language-sensitive" in that it provides a description
of the syntax for each VAX language that it supports. The Editor helps both
novice and experienced programmers build syntactically correct programs
faster and with fewer errors, through VAX language-specific construct completion, and error detection and correction facilities.
The VAX Language-Sensitive Editor is highly integrated into the VMS development environment. It is invoked via the English-like Digital Command Lan-'
guage (DCL) or the DEC/Shell command language, and works in concert with
supported VAX languages and the VAX Symbolic Debugger to provide a highly
interactive environment that facilitates the EDIT-COMPILE-DEBUG portion of
the program developmenrcycle. This enables users to create and edit code, and
to compile and review, and correct compile-time errors in one streamlined editing session. The Editor can be invoked directly from the VAX Symbolic Debugger to correct source code errors found during a debugging session.
In addition, the VAX Language-Sensitive Editor offers you features to customize and extend your editing environment to meet any unique programming
needs.

2-21

"Language-Sensitive" Features
The VAX Language-Sensitive Editor
• 'Thi.Iors the editing sessions for each of the eight VMS languages it supports VAX Ada®, VAX BASIC, VAX BUSS-32, VAXC, VAX COBOL, VAX FORTRAN,
VAX PASCAL, and VAX PUI.
• Uses formatted language-specific source code templates for quick, efficient
source code entry_
• Allows compilation and review and correction of compile-time errors within
a single editing session.
• Provides for interactive editing capabilities during a debugging session.
• Allows users to tailor the defined language environments or to define their
own environment.

The VAX Language-Sensitive Editor interfaces with supported VAX languages
to provide a powerful tool for program development. For each supported VAX
language, the Language-Sensitive Editor provides a set of source code templates. These templates are formatted language constructs. that provide
keywords, punctuation, and placeholders. Templates are inserted into the editing buffer by successive expansions of tokens and placeholders. Placeholders
represent positionS in the source code where you must either provide additional
program text or choose from indicated syntactic options. Token~ are keywords
or function names that you can type into the editing buffer and eXpand into
templates fOr corresponding language constructs.
While in an editing session, you can complete the editing of his cod.e, compile it,
and review the compile-time errors. You may specify DCLqualifiers such as
/DEBUG and ILIBRARY when invoking the compiler from the VAX Lan~
guage-Sensitive Editor. The compilation may be performed interactively or in a
batch job.
The REVIEW command allows review .of compilation errors upOll compile
completion. The VAX Language-Sensitive Editor disphlYS the.compilation
errors in one window, with the corresp9Ildmg sOurce code displayed in a second window. For easy error correction, there is a GOIO SOURCE command to
position the cursor. at the point in the source code where the compiler detected
the error.

2-22 • VAX Program Development Productivity Tools

The VAX Language-Sensitive Editor can be invoked from the VAX Symbolic
Debugger providing the ability to make source code corrections as they are
found during a debugging session. Features include:
• User notification if the @e invoked by the editor is a different version than
that displayed in the VAX Symbolic Debugger.
• Ability to specify the @e and line number from which to start the editing
session with the default being the current source displayed in the VAX Symbolic Debugger.
• User choice of terminating debugging session with the editing session or
returning to the debugging s(!ssion.
The VAX Language-Sensitive Editor enables users not onlyto customize previously defined language environments but also to define their own environments. Once they have defined their own environment, the Editor lets them
save it in a @e, restore it for later editing sessions, and update it with new
definitions.

Using the VAX Language-Sensitive Editor
The Editor is invoked by the LSEDIT command: The language is determined
from the @e type of the @e specification given in the command.
For the new user,
• The keypad layout is the Same as for EDT.
• PF2 gives help on keys
• CTRLIZ allows you to enter line mode.

• CONTINUE or CTRLIZ allows return to keypad editing.
• There is a line mode HELP command.
When using templates, there are bracketed constructs that will be inserted into
the source@e. These are called placeholders. There are four commands of primary interest in inserting language constructs:
• C1RLIE - EX9\ND
• CTRLIK - ERASEPLACEHOLDER/FORWARD
• CTRLIN -

GOID PLACEHOLDER /FORWARD

• CTRLIP -

GOID PLACEHOLDER !REVERSE

2-23

Depending on the type of placeholder at the cursor position, EXPAND will
replace the placeholder with a sequence of keywords and!or placeholders, or it
will present a menu of choices, or it will tell you what you have to enter as
program text at that placeholder. A menu item is selected by using the arrow
keys and then EXPAND. Text may be typed when the cursor is within
placeholder brackets; the placeholder is automatically erased.
In addition to expanding placeholders, which are generally inserted for you,
you may type in a template name and EXffiND it. Templates are provided for
most keywords that introduce syntactic elements such as declarations and state.ments. For example, if you type in IF and then CTRUE (EXPAND), an IF statement will be inserted at that point. It will contain placeholders for things that
you must fill in. Templates are also provided for built-in functions and for the
statement placeholder.
To compile the contents of the current buffer and review the errors, use the
command COMPILEIREVIEW. This will display the errors in one window and
your code in the other.
To select an error, position the cursor on that error and press CTRUG (GOID
SOURCE). The cursor may be jumped forward from error to error using
CTRUF (NEXT ERROR) and backward using GRUB (PREVIOUS ERROR).
• ONLINE HELP WITII.THE VAX LANGUAGE-SENSITIVE EDTIOR
When you want help, you want it immediately. And you don't want to sift
throUgh pages to find the information you need. In addition to the help you get
by using th~ language-specific templates, the VAX Language-Sensitiv~ Editor
pl'QVides you with extensive online help facilities: for each supported language.
\bu can quickly access help on all placeholders, or call on language-speCific
online help topics directly from the Editor. If you are learning a new language,
or are new at program development, you will gain efficiencY as the Editor
guides you with information on language structures and text insertion. If you
are experienced in a language, thiS feature lets you access help on less familiar
language constructs.
Online help makesiteasiet
for you totode
it right, thehrst time:
.
.

• WINDOWS PRovIDE ADDED FLEXIBILITY
The screen fonnat for the VAX Language-Sensitive Editor is reSponsive to many

different progrrufuning approaches. It consists ofaprompt atea, a message
area, anddne or two windows. Editor commands are used to manipulate the
screen and its format.

2-24 • VAX Program Development Productivity Tools

You can create buffers to hold multiple files and can display any two buffers
simultaneously. This feature lest you save devdopffienttime by cutting and
pasting sections of code or text from one buffer to another. Or you can
designate READ ONLY buffers fOl"versioh control protection. Since the Editor
determines the language you are using by the filenameeriension, you can move
between different languages in different bUffers with the Editor providirig the
interfaces to the appropriate compiler.
To help you with partict:tlarly farge programs where you might need to reference another section of the code; the Editor provides a split-screen ca:pability. This feature enables you to view and work on two different sections of
the same program simultaneously.
• TAIWRING YOUR ENVIRONMENT
The Editor's design allows you to use all of its powerful capabilities and still be
able to incorporate any unique editing preferences you may have. You can create versions of the environment that you will work best in.
For easy editing, you can hind any col1UI)lUld or string of cotmnands to a spe. cific key. H you're presenclya VMS user, y~>u will quicklyrecognjze the default
keypad since it is simllat to that used with EDT. Another important Editor feature lets you choose overstrike or insert editing mode.
'
To match perSonal or specified coding conventions, you can modify the language-specific templates provided with the'Editor. NeW templates may be
added to those provided for the VAX languages,or you can designate a new
language name to represent a set of templates you have cl'eated. For example,
you can create a language called SPEC which contains templates, tokens and
placeholders for structured, formatted specification ,doPllI1ep.ts.
Once you have set up an' editing environment to your specifications, yort can
save it and use it for future editing sessions - for the same project odor new
applicatiohs.
• VAX 1EXT PROCESSING UTlll'IY (VAXTPU)
For more unique editing requirements, the VAX LlIIlguage-Sensitive Editor
provides commands to access the VAX Text Processing Utility (VAXTPU), a utility that is part of VMS. VAXTPU has an easy to use. high-level procedural language which allows users to write fupctions not provided by the. VAX
Language-Sensitive Editor to further customize the editing envirqnment. The
VAXTPU language provides fpr loop,ing and conditionals to.allow users to perform more powerful editing tasks.
For more on VAXTPU, see Chapter 5 of this handbook.

2-25

• VAX Performance and Coverage Analyzer (VAX PCA)
The VAX :r:erfonnance and Coverage Analyzer is a VMS software development
tool that helps you analyze the runtime behavior of your application programs.
The VAX :r:erformance and Coverage Analyzer serves two functions:
• It pinpoints execution bottlenecks and other performance problems. Using
this information, you can modify your programs to run faster.

• It provides you with test coverage analysis by measuring what parts ofa user
program are or are not executed by a given set of test data. Using this information, you can create tests that thoroughly exercise your programs.
By using the VAX :r:erfonnance and Coverage Analyzer, you can focus your
efforts on making improvements that will bring the biggest gains in a program's
efficiency.

Features of the VAX Performance and Coverage Analyzer
The VAX :r:erformance and Coverage Analyzer consists of two parts - the Collector and the Analyzer. The Collector gathers performance or test coverage
data on a running user program and writes that data to a performance data file.
The Analyzer - a separate, interactive program - then reads the performance
data file and processes the data to produce performance histograms and tables.
VAX PCA can collect and analyze the following kinds of data:

• Program counter sampling data
The program counter (PC) is sampled at a regularly specified interval (by
default, every 10 milliseconds). This information provides a good overview of
where your program is consuming the most time.
• Page fault data
This information lets you determine what sections of the program are causing
the most page faults.
• System services data
This information tells you which system services the program calls, how often
it calls them, and which sections of the program do the calling.
• Input/Output data
This information about all Record Management Services (RMS) calls in your
program can help you to understand your program's input/output behavior.
This is essential when trying to speed up an I/O-bound application program.

2-26 • VAX Program Development Productivity Tools

• Exact execution counts
This information about the exact number of times specified program locations are executed helps you to understand your program's dynamic
behavior.
• Test coverage data
This information shows you which code paths are or are not executed when
you test your program. Using this data, you can make your test more
complete.
Both the Collector and the Analyzer are fully symbolic, getting the required
symbol information from the Debug Symbol Table (DST) generated by the
compilers. Consequently, the VAX Performance and Coverage Analyzer works
with any of the VMS languages that produce DST information. These include
VAX Ada®, VAX BASIC, VAX Bliss, VAX C, VAX FOR1RAN, VAX MACRO, VAX
Pascal, VAX PLII, and VAX RPG II.

Using the Collector
When using the Collector to collect performance or coverage data from a program, you must
1. Compile your program with the /DEBUG qualifier.
2. Link your program using the LINKIDEBUG_ = SYS$LIBRARY:PCA$OB].OB]
command.
3. Run the program.
These steps ensure the necessary symbol table information is included in your
image and that your program is linked with the Collector. When the program
starts running, the Collector takes control and prompts you for commands.
Once you have invoked the Collector and gotten the Collector prompt
(PCAC», you are ready to enter Collector commands. First, you usually enter a
SET DATAFILE command to specify the name of the performance data file,
which will contain the collected performance data and all symbol information
needed by the Analyzer. Then, you enter commands that specify what performance or coverage data you want to gather. Commands for gathering data
include SET PCSAMPLING, SET PAGLFAULTS, SET SERVICES, SET
IO-.SERVICES, SET COUNTERS, and SET COVERAGE. Last, you enter the GO
command to start the data collection.
When the GO command is entered the Collector starts your program, gathers
the specified performance or test coverage data as the program.runs to completion, and writes this data to the performance data file.

2·27

The following example shows the Collector commands to gather program
counter sampling data for PRIMES:
PCA~) SET OATAFILE PRIMES.PCA
PCAC) SET PC_SAMPLING
PCAC) GO
Wheri the program finishes running, the Collector doses the data file. You are
then ready to run the Analyzer on the information in that file.
Additional collection runs can be made on your program by simply repeating
the RUN command to Wtiate another run. It is also possible to collect data from
many executions of the same program into a single data file.

Using the Analyzer
The Analyzer processes the data in a performance data file to produce histo·
grams, tables, and other reports. The Analyzer lets you interactively examine
the gathered data in various ways until you can pinpoint performance bottle·
necks or identifY code not covered by testing.
To run the Analyzer, you must use the PCA command at OCL level. This command accepts the name of a performance data file created by the Collector as a
parameter. When you enter this command, the Analyzer product heading and
prompt will appear on your terminal.

• ANALl'ZER PLOT AND TABULATE FEAnJRES- .
The two CQp:p;nands most frequendy used in th~ Aruil~.are PLOT and TABU:
LATE. ThesecOmniafidS lei: you preSent the info~atiod in the performance
data file either as histograms (the PWT command) or as tables of raw data
counts and percentages (the TABULtITE roinmand).Both commandS organize
data in the same ways; the only difference between the two commandS is in how
they format the output.
The summary page at the end of every histogram or table gives various statistics
and lists all qualifiers, node specifications, and filters used to generate the hisio~ oriable.
..,
."
--. - - -

• VAXGKS
The Graphical Kernel System (GKS) Srandard specifies a set of graphicS primitives or functions. The functions provide applications with a: graphic system to
produce.two-dimensional pictures·on vector or'raster graphics output devices.
The standard defipes twelve upwilrd compatible levels oHonctioriality to meet
thevarying-tiequirements'ofdifferent graphic-systems.
.

2-28 • VAX Program Development Productivity Tools

Anin international' stllndard,' GKS provides a common definition fora
graphics interface that implements functioriscommon t6 all applications.
Thus,-GKS permits the applications programmc::r to concentrate on the job
at hand, rather than on system level progr~m1Ding .details. 'This incrc::as;es
programmer productivity and decreases the development time for a graphics application. GKSalso makes an application portable alIlong machines
that implement the stall,d¥d.
.
.
.

FeatUres otVAX GKS
VAX GKSsuPPortsseveraI types of output functions that draw the following
components of a graphic image:
• Lines and Iblylines
• Markers and polymarkers
• Text strings
• Rectangular arrays of pixels
Input functions proVide the followinggeneraI facilities:
• Initialization of logical input devices
• Acquisition of input from logical input devices
• Control of echoing and ()ther eharactetistlcsoflogical input devices
VAX GKS provides a method to file graphical information. A file of graphical
information is useful for external storage, exchange, and reproduction of a
graphic image.

Using VAX GKS

".'

VAX GKS provides an interfaci!between an application program and a Collection of physical input and output devices. Each type of physical device is unique
in capabilities and characteristics. Since VAX GKS is a device independ~t
graphics system, the interface masks the low-level features of hardware device
and .communicates ,with all devic~ through a common interface· that allows
device~speclfic graphic liandlerslq p~rform th~ liardwareinstructions.
To provide a convenient and deviceindepend~tcoQrdinate system,}IOU
describe and constNct graphic images using \XQrkl Coordinate (We) systems.
\1Cbrld Coordinate systems pelt\lit th~,appliclltion'Progt!lffilIl~ to define arange
of values for the x-axis and y-axis that apply to a particular application rather
than a specific device. For example, an application can use\1Cbrld Coordinates
that range from-2 to 10 on the x-axis and from -6 to 6 on the y-axis.

2-29

In a WC system, the x-axis increases positively toward the right and negatively toward the left while the y-axis increases positively upwards and negatively downwards. The axes are always perpendicular and intersect at the
(0,0) point, known as the origin. The position of any given point is simply
the distance from the origin along the x-axis and the y-axis.
To compose a graphic image, you define the portion of the \Xbrld Coordinate
system that contains the points you wish to display. This portion of the World
Coordinate system is known as the world window. After defining the world
window, you specify the placement of the window onto a display surface.
Since the coordinates of a display surface are device dependent, VAX GKS
defines an imaginary display surface on which to project the image. The imaginary display surface represents a single, square device independent display surface for all devices. This display surface is known as the Normalized Device
Coordinate (NDC) space.
You can project the world window onto any portion of the NDC space. The
portion of the NDC space that contains the world window is known as the
world viewport.
A set of normalization transformations permits you to specify the world window and the world viewport limits.
The world viewport also defines a clipping rectangle. You can enable or disable
clipping to the world viewport boundary (the clipping rectangle). With clipping
enabled, points of an output function that fall outside the limits of the world
viewport are not displayed. With the clipping disabled, VAX GKS draws the
portion of the output whose locations extend beyond the limits of the world
viewport.

• VAX GKS OUTPUT
VAX GKS builds the display of a graphic image from two basic elements: output
functions and output function attributes. The output functions are abstractions
of basic operations adevice can perform (for example, drawing lines and printing character strings). The output function attributes tailor the appearance.of
the object drawn by an output function.

2-30 • VAX Program Development Productivity Tools
Each output function is defined in a \Xbrld Coordinate system_ The output
functions permit you to perform the following graphics operations:
• Draw lines
• Place markers
• Display text
• Fill a defined area
• Display an array of cells with individual colors
• Draw special, device-specific geometric shapes
For each output function, a set of output attributes describes the representation
of the respective graphic image_ For example, when you call the VAX GKS output function to draw a line (Draw Iblyline), polyline attributes specify theform,
thickness, and color of the line to draw. Initial values, supplied as default settings, display a general representation of the object drawn by each output function. You can change attribute values to tailor the display to application
requirements.
VAX GKS provides three methods to specify output function attributes. The
methods are:
• Individual
• Bundled
• Combination
With the individual method, you specify a value for each attribute of an output
function. For example, to draw an application specific line, you specify values
for the polyline attributes line type, width, and color. All subsequent calls to the
output function use the attribute values you specify until you explicitly change
the values.
With the bundled method, you select a set of predefined attribute values to
specify the representation of an output function. VAX GKS stores predefined
attribute values for each output function in a construct known as a bundle
table. The bundle table consists of several sets of predefined attribute values.
You specify an index into the bundle table to select a given set of attribute values
for an output function. You cannot change the attribute values in the bundle
tables, but you can select from several sets of predefined values to obtain the
desired image representation.

2-31

With the combination method, you specify values for some attributes individually, and specify an index into a bundle table for other attributes. Thus,
the combination method provides flexibility; it permits you to use
predefined attribute values that meet application demands and specify only
the unique attribute values.

• VAX GKS INPUT
VAX GKS supports input functions to provide for interaction between you and
the application program. The input functions enable a user at a physical input
device, such as a keyboard, to supply data to an application program.
, VAX GKS accepts input from logical input devices so that the interaction is independent of the available physical input devices.
Logical input devices are abstractions of the commonly available physical
,devices; they,deliver logical input values to the application program. The type
of data that each logical input device delivers distinguishes five basic classes of
logical input devices as follows:
• Locator - returns II, ~rld Coordinate point
•• Stroke - returns a sequence of~rld Coordinate points
" Valuator - returns a real number
, • Choice - returns a selectionfrom a number of choices(forexample, a menu}

." ~'S~ring - rettJrns an individual character or an entire text string
To accept data from a logical input device, an,' applicatiort program eitPer
describes the characteristics of an input device or uses inithdvalues that ptoYide>
default characteristics, and then requests input from a logical input deviee. Fol~
lowing a reqrrest for input, VAX GKS attempts to read a logical input value from
, the device. You control a physical input device to specify the data, ,
.

.~.

• VAX GKSME1AFILES

VAXGKS pn?vides an interface to a system'forfiling graphicl!lin£~tio~; A " .
file of graphical information is useful for ~xternal storllge, eJ{Cbahge, a~drepio- "
duction of a graphi<: l~lIge. TheVAX GKS interfa~e forfiling~faphi¢alin£0ffila,~
ti9P:.isthro~ Metafile Output and the Metafile Iqpl;¢. ':i/,? ;;:, '0;:;" >, ',:

,;:'\'"

'~~~f~f:;:.

0,_

Chapter 3 • VAX Programming Languages

• Overview
The large collection of VAX high-level programming languages is described in
this chapter. Each VAX language, presented in alphabetical order, is covered in
its own section that supplies information on language extensions, specialfeatures of each language, and a sample program listing.
Topics include
• The VAX Common Language Language .environment.
• The VAX high-level languages.

3-2 - VAX Programming Languages

'~".--~/
---.',

......

_--

THE FAMILY OF VAX PROGRAMMING LANGUAGES
VAX
FORTRAN

VAX
DIBOL

Other VAX

VAX APL

Languages~_~~~-V'1

LISP
DSM
CORAL

This chapter describes the family of VAX
languages that give application and systems
programmers a Common Language Environment in which programs
• Can be written in more than one language
that conform to a common camng standard,
• Use a common debugging utility (VMS
DEBUGGER),
• Use a common runtime library (VMS RTL),
• Use a common file 1/0 system (VMS RMS),
• Can call operating system services and use
a common handling of exceptions,

Figure 3-1 -Overview o/Chapter 3

3-3

• Introduction: General Features of VAX Programming
Languages
As we saw in Chapter 1, the VAXlVMS Software Development Environment
provides you with a continually evolving environment for the design of systems
and applications programs that use the VMS operating system. These designs
are used in a wide range of applications, including engineering, scientific, com- .
mercial, instructional, and system program implementation activities.
At the center of the productivity environment is the family of VAX programming languages. Applications and system programmers have a diversified range
of higher-level and assembly-level programming languages at their disposal. In
addition to the assembly-level language, MACRO, VAX programming languages
cover the gamut from VAX T " Ada® to VAX RPG II.
'
The following table, Thble 3-1, can be used to show the different components of
the VAXlVMS Software Development Environment as they might be used when
designing an application program that involves the use of one or more of the
VAX languages. The table indicates major data types supported by the languages, support for EXTERNAL data, data in the Common Data Dictionary,
and the ability to pass data and results between program modules (VAX Calling
Standard support). The table indicates language support in the VAX Symbolic
Debugger, access to the SORT/MERGE facilities of VMS, and whether forms
management utilities can be used.

In addition, the table shows file access methods available through the VAX RMS
file management system, and which access methods are supported by each of
the languages. Access to database facilities is shown, including the callable
interfaces to Datatrieve, DBMS (network database), and RdblVMS (relational
data base access).
The rightmost columns of this table show mtegration of the Common Language Environment with the VMS Programmer Productivity Tools. These Software Tools are language-neutral in many cases, but where appropriate they do
support language-specific operations, (For example, the Language Sensitive
Editor (LSE.) Following the table, you will see sections describing each of the
languages and the software tools in more detail.

Thble 3-1: • Cross-reference chart for VMS Services, VAX Languages, Software Tools, and Related Program Development Products.
Data Support
Numbers Strings
PRODUCT NAME

VAX Ada
VAX ApI
VAX BASIC
VAXC
VAX COBOL
VAXCORAL
VAXDIBOL
VAXFOR1RAN
VAX PASCAL
VAXPLJI
VAX RPG II

Program
Runtime

RMS File Access

Database
Access

Software Tool
Support

I F D F V D C E C C
N L E I A Y OX D A
T 0 C X R NM T D L
E A I EYAME
L
GTMDIMOR
E
A
N INN
S
T
R
L
GC
A
L
D

D S F T
EOMD
BR S M
U T
S
G
G
E
R

S S B R I
TEL E N
R·Q 0 L D
E U CAE
A E K T X
MN
I E
T
V D
I
E
A
L

D D R
A B D
T M B
A S
T
R
I
E
V
E

C M T L P
M M ESC
S S SEA
T
/
M
G
R

...';

oJ,

Y Y y y y
Y Y Y

Y Y
Y Y Y
Y Y
Y Y Y
Y Y
y

Y
Y
Y
Y

Declare

Y
Y Y Y Y Y
Y
Y Y Y
Y Y Y Y
Y
Y
y

Y
Y
Y Y
Y Y
Y
Y Y Y
Y Y
Y Y Y Y Y
Y Y Y Y
Y Y Y Y
Y Y Y
Y

* means access via CALL or other language featllre

*
...';

"1:

*
Y
...';
"1:
*
Y
,', oJ,
Y Y

...';

oJ,

...

* * *
-k
*
Y
-k
*
Y *
,,/,

oJ,

Y
Y Y

...';

-J~

...';

....';

Y
Y Y
"k
Y Y Y Y
Y Y * * *
* Y * Y Y
'1:

*
*

y
y
y
y

*
y

*
*

...';

y
y

...';

Y Y Y Y Y
* Y Y Y Y

y mea.ns actual Language support

*
*

oJ,

P
Y P
* "k P

*
1,

...';

" P P
...
1,
P
';

...';

-j,

y
y
y

Y Y Y Y Y
Y Y Y Y Y
y
y

y
y

'.h
"'"

y
y

Y Y Y Y Y
y
Y Y y

P means preprocessor support

>::

1;::
~
~
~.

.,t-<
;0

~1;;

3-5

User applications can be made up of individual program modules written in
many different VAX languages_ These languages all conform to a single calling standard, therefore, application systems can include modules written in
several languages. Modules can CALL, pass parameters, and/or read files in
cooperation with modules written in other VAX languages.

Ada is a modern, higher-order programming language designed as a result of a
competition sponsored by the United States Department of Defense. Although
Ada has now become the single programming language for all mission-critical
Department of Defense software, it is also well suited to many civilian applications, such as CAD/CAM, or process control. Ada is ideal for large applications
that musr be developed and maintained by many programmers.

Features of VAX Ada
• Ada is used in a variety of applications, including systems, computational,
general, and realtime programming.
.
• Besides providing powerful language features, Ada reduces software life cycle
costs by providing formodularization and separatecolilpilation using packages, scope rules, and a compilation database.
•, Ada allows- both bottom-up and top-down program' development: Ada'
.enhances software reliability through strong typiQg...
• In addition to being a suitable Ianguag~ f()t embedded realtime applications,
. Ada gives you features formultitasking,suchaitas'ks; rendezvolis, priorities,
and entry calls.

Who Uses VAX Ada ?
Users of VAX Ada Include:
• Government prime conttactors for which use of Ada has been specified as a
mandatory requirement.
• Major industrial corporations whose work as prime contractors has led to a
significant in-house Ada training effort. These internal resources are increasingly being used for non-government related, general-purpose programming.
• Educational instinitions seeking, for teaching purposes, a standard programming language that demonstrates modem ~rogramming techniques.

*Ada is a registered trademark of the U.S: Government (Ada Joint Program Office)

3-6 • VAX Programming Languages

VAXlVMS.Implementation of Ada
The Ada Compilation System fot the VMS operating system is a complete
implementatioo of theAda language, and conforms.fully lothe ANSI standard
and validated by the Ada· v.ilidation Office.
The VMS Ada compilatiQn system consists of:
• The Ada compiler
• The Ada Compilation Library Manager that provides support for programming teams through:
.
Shared; use 6£ a'Compilationlibraryhy many pr6gramffiers.

Th~ ability to share compiled Adac~e cither by rclerence 'or copy.
. Use of individual libraries as sublibraries of team libraries.
Automatic recompilationof obsolete units~
• High-level, fully symbolic debugging capability through the VMS debugger,
including support for:
.
M~ed Ada and non-Ada code .
-

Packages

--:: Multiprogramrriing
• Integration with the VMS operating system includes:'
Conformance to the VAX Calling Standard, which provides the ability to
call and be called by code written in other languages and to call VMS
'. syst~ seiVices and d~~ VMS Run-Ttine library.
;-The ~hility to handle VMS asynchronous system traps (ASl's) ..
Comprehensive diagnostic messages, including automatic syntax error
correction, geared to help the new Ada user.

3-7

Ada Program Units
An Ada program, also called an Ada system, is composed of one or more units,
each of which may be separately compiled. There are four types of units:
• Subprograms
• Tasks
• Packages
• Generic Units
All Ada program units have a similar two-part structure consisting of:
• A specification that identifies the calling user interface to the program unit.
• A body, which contains implementation details that can be hidden from the
user.
The specification and body can be separately compiled. This aids in large development efforts by allowing all specifications to be written first and by creating a
design structure. Unit bodies can be written and refined independently.

SUBPROGRAMS - S4bprograms are the basic units of execution in an Ada
system. A subroutine is a procedure that expresses a action.

TASKS - Thsks are independent, concurrent operations that communicate with
each other by exchanging messages. Tasks are used to implement Ada's concurrent processing feature.
PACKAGES - Packages are collections of resources, such as data type declarations, data objects, subprograms, tasks, or other packages. Because portions of
a package can be hidden from the user, packages are used to provide various
levels of data abstraction.

3-8 • VAX Programming Languages

The definition of the Ada programming language includes several predefined
library units_ Among these·are:

• CALENDAR
• DIRECTJO
• IO~CEPTIONS
• LOWLEVELIO
• SEQUENTIALJO
• SYSTEM
• TEXTJO
• UNCHECKED_CONVERSION
• UNCHECKED..-DEALLOCATION

GENERIC UNITS- A generic unit is a template of an algorithm that can be
tailored to particular needs at compile time. A generic program unit can be
created by adding a prefix to an existing program unit. This prefix is called the
generic part, and it defines any generic parameters. A generic routine is called
like a subroutine, and becomes nongeneric when it is called because it is passed
parameters that are defined to have a certain data type.
Major Features of the Ada Programming Language
VAX Ada supports these features.:
• Strong typing
• Data abstraction
• .Machine-dependent faciliti~s
• Exception handling
• Generic definitions
• Relative and absolute precision specification

STRONG 1YPING - Ada is a strongly typed language. This means that an
object (variable) of a given type may take on those values that are appropriate
only to that type, and certain predefined operations may be performed only to
data of that type. For example, an int~er value cannot be assigned to a real
variable without an explicit conversion.

3-9

A data type characterizes a set of values and a set of operations applicable to
those values. For example, integer is a data type with values represented by any
positive or negative whole number or zero. The predefined operations that can
be performed on the integer data type are addition, subtraction, multiplication,
division, modula, absolute value, and exponentiation.
Because type checking is done at compile time, strong typing ensUres that any
errors associated with incorrect data types are detected at compile time.

DATA ABSTRACTION - Data abstraction, or information hiding, obscures
the details of implementation, while providing users with mechanisms for
using the implementation. Abstraction allows us to focus on important characteristics while ignoring underlying details. For example, 'when we think of
integer data, we think of whole numbers and the operations that can be performed on them, rather than the fact that integer data is actually implemented as binary Is and Os by the computer.

SYSTEM-DEPENDENT FACIUTIES - Different systems built by various manufacturers will vary in such characteristics as the size of their storage unit, memory size, and the smallest and largest integer values supported. Ada provides a
package called, SyStem, which contains a collection of system defined constants
to represent system-dependent information. The values of these constants are
defined by the actual implementation.
There is also a feature called a pragma that allows the setting of parameters that
describe implementation features and attributes. There are predefined
pragmas, and the application is free to add others.

CONCURRENT PROCESSING - For many applications it is important that a
program be conceived as a number of parallel activities rather than a serial
sequence of actions.
Most high-order languages provide little or no support for handling such concurrent activities; they rely on facilities of the host operating system. Ada uses
tasks to support parallel activities directly within the language.

EXCEPTION HANDUNG - In many operations, especially in embedded
computer systems, it is critical that a system be able to recover quickly and efficientlyfrom error conditions.
Ada includes predefined exception conditions, and alSo permits the user to
define exceptions. It provides the ability to raise exception conditions, and to
actually handle conditions. When an exception qccurs, nomialproc~sing is
suspended and control passes to the exception handler.

3-10 • VAX Programming Languages

GENERIC DEFINITIONS - In many cases, the logic ofa program is inde~
pendent of types qf the values being manipulated; For example, in a simple
exchange routine that exchanges two elements of the same data type, the
algorithm, to do the exchange would be the same for any data type. However, in a strongly typed language such as Ada, all types muSt be defined at
compilation time. To use tQe,exchange routirleJor,yarious data types, a separate routine wouldhave to be coded for each dat~type.
The following is an example of a typical VAX Ada program.
This prograM has a "bacKstound task " that sorts an inteSer array
while "ano"ther task interacts wi"th the terhlina'l user.
The inte'l'actiue
tasK, .. ~~on.us~r cOMmand, will d~splay the array at',any time
durin'S' th~ s·o.~t.
(The QUICK~SORT procedure 15 not shown; it is
p"resuMed -that" QUICK_SORT has delay s.·tat"ements to R'eep it froM'
rU!lJl in,s. t Q,~ , f a.s t t )

.Packa!f-e t"o provide 110 oper.ations for objects of type

INTEGER and FLOAT
with TEXT_IO; use TEXT_IO;
pacKage IOPACKAGE is

end

paoka_e INTIO is ri"w lIiiTEGER:':IO(INTEGER)';
paoka_e FLOATIO is new FLOAT_IO(FLOAT);
IOPAtKAG~;
..
Main Pfo!frafft to sort an arr,BY and examine it as Ct.,is sorted.
All tasks in' this P'fO !f ram' have one Master. proce(fuie ·TASKSORT.,
which i,s' also their tmMediate Msste'r.

with TEXT_I'O. IOPACKAGE;
prooedure TASKSORT i's
use TEXT_IO. IOPACKAGE.INTIO;
pra!fma TIME_SLICE(O.3); -- enable interleaved

executi~n

Define array to be sorted.

type QUICKARRAY is anaY l INTEGER ran.'e .<»
A
QUICKARRAY( 1 •• 120);
ASI ZE : INTEGER;

of·INTEG.ER;

Specify quick sort procedure. to be provided by the user. and
to be use'd, br, th·~ sort~n!f task.

prooedure QUICK_SORT(A : QUICKARRAY; ASIZE :, INTEGER) is
Specjfr a sin(le task to perform the sort

task .QUICK is
:entry START (ARG, INTEGER)·;
end QUICK;
Specify another sin !fIe. task to do terminal I/O

separa~.;

3-11
tasK USER is
pr'.Ma PRIORITY(B)I

Give "interactive task"
hiSher priority than 50rtinf task

end USER;
Procedure to be used by the interactive task to print
out the arrav

procedure PRINT_ARRAY is
begin
for 1 in 1 •• ASIZE loop

PUT(A(I) .WIOTH=)3);
end loop;

NEW_LINE;
end;
Corresponding task body for specification QUICK;

contains a sYnchronization point for startinf the sort,
and a call to the sorting routioe

tasK bodY QUICK is
ARRAY-SIZE

INTEGER;

be fin

select
accept START (ARG: INTEGER) do

ARRAY_SIZE := ARG;
end START;
or
terminate";

end select;
PUT_LINE("The."sorting task has started");

QUICK_SORT(A.ARRAY_SIZE) ;
PUT_LINE("T~e

sorting task has COMPleted");

end QUICK;
Corresponding task body for specification USER;
uses two nested loops: the outer loop allows· YOU to
input the integer array for sorting; the inner loop
allows YOU to look at the array (or exit) while it is
bein~ sorted

tasK bodY USER is
I
INTEGER;
LAST
NATURAL;
SENTI NEL
STR I NG l.1 .. 120) : = (1. .120 => '

')l

beSin
lco"p

begin
PUT_LINE("Type in ihe nUMb~r of intefers YOU warit sorted,II);
PUT_LINEJ'land t:tten type a ~.II);

GETlASIZE) ;

PUT~LINE(,iNow, t·),ps.'
a storinf of inteSe"rs, separated 'by spa"ces,");
PUT.:..LINE(lIthat YOU w.an·t sorted. End,the: strin9' wit~ a «®.");
for I in 1 •• ASIZE loop

GET(A(I»;

end loop;
PUT("The initial array is ");

PRINT_ARRAY;
QUICK.START(ASIZE);

Start the sortin!f task by rend~zvous
with task QUICK·; synchronize USER and

QUICK

3-12 • VAX Programming Languages
Allow the terminal user to see the arraY or eKit any tiMe
he/she' wants.
loop
PUT_LINE(IITvpe:

t.o see partially sorted array

e to exit");

GET_LINE(SENTINEL. LAST);
if LAST

>= 1 and then (SENTINEI.(l) = 'E' or SENTINEUl) = 'e')

then
end if;

PRINLARRAY;
end loop;
exi t ;
exception

when END_ERROR =>
PUT_LINE("That(s all

f~lks!")i

exit;
when others =)
PUT_LINE("You've Made a mistake; try

a~ain");

SKIP_LINE;
end' loop;

end USER;
be~in

tasKs USER and QUICK are activated;
environment tasK for TASK SORT is created.

null;

end TASKSDRT;

procedure finishes when USER and QUICK
are done; control returns to' VAX/VMS

Should YOU run this Pfo.raMt YOU Must-make sure that the input
file is not a process-permanent file (SYSSINPUT); otherwise, the
lower priority 50rtin_ task will not run. To avoid using SYSSINPUTt
first .execute th~ fnllo~inf Del COMMand:

• DEFINE ADA$INPUT'lT

Figure 3-2 • Sample Ada Program Listt'ng

• VAXAPL
VAX APL (A Programming Language) is a compact and versatile programming
language that runs on the VAX series of computers. This language is especially
suited to handle nwneric and character data organized as' lists a~d tables and is
used extensively in such areas as the manipulating of data, the designing of systems, and the computing of mathematical and scientific solutions.
The language was originally designed as a notation language to explain concepts, not as a computer language. As such, APL is a language for communicating ideas, not just telling computers what to do.

3-13

Features of VAX APL
• VAX APL uses an interactive interpreter, so you don't have to compile or link
programs
• VAX APL has a number of special operations that lets you handle lists and
numbers as they now handle numbers.
VAX APL uses virtual memory to create a workspace that can expand as needed.
Because the symbol table and execution stack (SI) are part of the workspace,
they too can grow dynamically as long as memory is available.
There is also a complete set of APL system commands that can change the system environment, including listing and deleting files from disk and loading, saving, and copying VAX APL workspaces. Unlike other languages, which are
compiler-oriented, VAX APL is a sharable and reentrant interpreter that allows
you to edit functions or debug programs without ever leaving APL. VAX APL
also provides detailed error messages to assist you in detecting and debugging
errors.
Characteristics
Although it is also a high-level language like FORTRAN, COBOL, and PASCAL,
APL differs from these languages in several respects.
• SIMPLE SYN11\X - Most functions in APL are designed to manipulate data.
As long as the data is in an acceptable· format, the manipulation will take
place, allowing several functions to be placed one after another to create the
APL program. The few syntax rules that do exist in APL consistently apply to
both primitive (built,in) functions and the user-defined functions.
• MODULAR DESIGN - One APL program can easily call anotherAPL program and have data returned as a result. This allows youto build a library of
special purpose routines and to easily create top-down organization.
• TABLE HANDUNG - .APL uses very powerful primitive functions that can
act just as easily on an entire table as they can on a single number. VAX APL
can handle a table of up to 65535 dimensions.
• IMMEDIATE EXECUTION - VAX APL is an interactive language, therefore
you can see theresults of their efforts immediately after they are entered. It is
often faster. to use an APL function on a large table than it is to compile a loop
. in otherlan.guages to process the table.
To be highly productive, VAX APL users don't need to know much about the
VMS operating ~ysteffi;· The APL interpreter supplies· everything that will be
needed during a terminal session. In addition to providing a built -in editor, VAX
APL provides debugging aids, systems communication facilities, and a file system. This means you can edit and debug a program without ever leaving APL.

3-14 • VAX Programming Languages
~ting a program usually takes less time in APL than in many other languages.
BecaiIse of this time saving characteristic, APL is also cost efficient.
In APL, you don't need to reserve space for variables (DIMENSION) or specify
data types (INTEGER, REAL,etc.).Inpu~ aildoutput formatstatem~ts are
unnecessary. RoWs and columns of data CM be. manipulated without loops.
Compiling and linking are unnecessary because APL can e~ecute code
immediately.

These steps are unnecessary betause APL does them a~tomati~ally. This saves
time and allows you to concentrate on problem solving. For example a
progiammer can write a program to compute an average faster in APL than in
FORTRAN. A FORTRAN program to average a set of unknown numbers may

look like:
INTEGER N
REAL T. 0
T =0
N • 0
10
1000

WRITE (*.1000)
FORMAT ('$'t 'Enter next number ot .. Z to stop:
READ (*.*.ENO=100) 0
N = N + 1
T'=T+O
GO TO 10

100

IF (N .EI;). 0) THEN
WRITE (* .2000)."
• FORMAT, (' .No ,nuMbers to . . _,rase')
STOP
ENOIF

2000:-

WRITE (*.3000')' N. TIN
FORMAT ('~ The aver.a.e '"of the' fUf.:.,' "nuMbers "is-

3000
'~

Fl0.Z)

END

APL can use the following code to' do:the same thing:
'ENTER NUMBE'RS SEPAR,ATEO BY SPACES'
(+IX)+p,X~O

• VAXBASIC
The VAX BASIC product gives you the benefits of a highly interactive programmiIig enVironment and a high:perform8nce development language. It combines
the features of a compiled; structured BASIC and the RSTS/E BASICPLUS language with the performance benefits, provided bya VAXlar!guage that is fully
integrated with the VMS environment.
The VAXBASIC language is a highly extended implementation language. It provideSpowerful matheinati~aland stringhimdling facilities; support for' symbolic variable nameS!debugging, and full RMS indexed, sequential, and relative
I/O operations.

3-15

VAX BASIC can be used as if it were either an interpreter or a compiler. A fast
RUN command and support for direct execution of unnumbered statements
(immediate mode) gives you the feel of an interpreter. However, this product
can also be used in compilation mode, where it generates object modules like
the other VAX compilers. In either case, the VAX BASIC system generates
optimized VAX native-mode instructions that have extremely fast execution
times.

Features of VAX BASIC
• BASIC programming support environment
• Structured programming constructs in the language
• Labels
• Conditional compilation and compile-time directives
• Alphanumeric labels on statements

• Full support for the VAX Language-Sensitive Editor and the VAX Symbolic
Debugger
• Program segmentation
• User-defined data types

Who Uses VAX BASIC?
• Students, teachers, and administrators
• .Third-party application development houses
• Financial institutions
• General-purpose data processing departments

3-16 • VAX Programming Languages

General Characteristics
The VAX BASIC system generates inline VAX instructions in both its RUN and its
compilation modes. The code produced takes advantage ofVAXNMS capabilities, including:
• Direct calls to operating system service routines, even in immediate mode
• rransparent use of DECnet communications software
• Direct calls to the Common Run-Time Library and standard system utilities,
including VAX SORTIMERGE
• Direct calls to separately compiled native mode procedures written in any
language that conforms to the VAXprocedure-calling standard
• Program sizes up to 1 billion bytes are allowed
• All modules are position-independ~nt (PIC) and can be run as fully reentrant
code
The code generated by the VAX BASIC system uses the standard VMS traceback
facility for determining the source of run-time errors. If a fatal program error
should occur, an English message is printed identifying the module and line
number where the error occurred. The English text, the traceback, and the
integrated BASIC HELP utility provide a powerful program debugging
environment.
Object modules produced by the VAX BASIC system can be linked with object
modules produced by other language processors including the BLISS, COBOL,
FORTRAN, PASCAL, and MACRO processors.

Structured Programming
Structured programming constructs add most of the features of a block structured language (such as PASCAL) to the BASIC language to allow complex programs to be written without recourse to GOSVBS or obscure programming
techniques. This makes programs easier to write and maintain.
Figure 3-3 illustrates a data structure defined by the RECORD statement, successive retrievals by the use of a GET statement, and iteration controlled by a
WHILE ... NEXT statement block. Also, note the use of named constants and
labels.
100

,TITLE 'VAX BASIC demo pro'ram'
ISBTTL 'Declarations'

OPTION TYPE = EXPLICIT
ON ERROR GOTO Error_handler

! Require declaration of all
! varia_bles

3-17
RECORD Employee_rec
VARIANT
CASE
STRING Whole_name' 36
CASE
STRING Last_name' 20
STRING First_name' 12
STRING Middle_initials
END VARIANT
DECIMAL(7.2) Rate
END RECORD Employee_rec

! What an eMPloyee's file entry
! looks like

! The eMPloyees whole naMe

Another view of his naMe

MAP (REC) Employee_rec Employee
DECLARE STRING File_name.
DECIMAL(IO.2) Total_rate.
BYTE
End_flU
DECLARE BYTE CONSTANT
True' -I.
False = 0
DECLARE LONG CONSTANT
EnLof-file

! Pay

rate

&
&

"PAGE
%SBTTL

~Main

File_name

code'

= 'EMPLOYEE'

Total_fate = 0
End_flag = False

OPEN File_"ame AS FILE #1. SEQUENTIAL. ACCESS READ. MAP REC. DEFAULTNAM ".DAT"
WHILE NOT End_fla~
GET #1
Total_rate = Total_rate + EmploYee::Rate

NEXT
GOTD PrograM_end

"PAGE
%SBTTL 'Error_handler'
Error_handler:

SELECT ERR
CASE E"Lof_file
End_fIa:!! = True
RESUME
CASE ELSE
ON ERROR GO BACK
END SELECT
"PAGE
%SBTTL 'Print result and clean up'
Pro5lrafrl_end:
PRINT 'Total

rate: $'; Total_rate

CLOSE #1
END

Figure 3-3 • Sample Structured VAX BASIC Program

3-18 • VAX Programming Languages

The SUB and FUNCTION constructs in the VAX BASIC language have
structured END and EXIT statements. In addition, this language allows the use
of statement modifiers that allow conditional or repetitive execution of the
statement without requiring you to construct unnecessary loops or blocks. Any
nondeclarative statement in the VAX BASIC language can have one or more
statement modifiers. The BASIC statement modifiers include FOR, IF, UNLESS,
UNTIL, and WHILE constructs. Each of the statements in Figure 3-4 illustrates
the use of a statement modifier:
100

A( I)=A( I)+1

FOR 1=1 TO 100

200

PRINT SUMMARY DATA

300

PRINT HOUSE.PAYMENT

UNTIL

OPTION.! AND (REPDRT="MONTHLY")

400

GET #1

WHILE EMPLOYEE.NUMBER<76000

500

GOSUB 12300

UNLESS ERRDR.FLAG

600

PRINT"NORMAL EXIT"

RATE< 123.45

TDTAL)1000 UNLESS ERRORS)O

Figure 3-4 • Statement Modifiers

• VAX Bliss-32
VAX Bliss-32 is a high-level systems implementation language. The Bliss-32 language supports development of modular software according to structured programming concepts by providing an advanced set of language features. It
provides access to most of the hardware features of the VAX systems to facilitate
programming of time-critical and hardware dependent applications.

Features of VAX Bliss-32
Bliss-32 is specifically designed for the development of:
• Many parts of operating systems
• Compilers
• Runtime system components
• Database file systems
• Communications software

• VAX utilities

3-19

What is VAXBliss-32 Used For?
• Base operating system design and engineering
• Compiler devdopment
• Database management systems engineering
• Cross-compiler devdopment
• Hardware-dependent applications
The Bliss-32 compiler operating translates source programs into rdocatable
object modules that can be linked for execution. Bliss-32 compiled code is optimized for execution efficiency.
The following features of Bliss-32 are machine independent. Collectivdy, this
set of features is known as ·Common Bliss" and can be used to devdop transportable programs that will run on VAX, DECsystem-lO, DECSYSTEM-20, and
PDP-II systems.
• Modules are compiled separatdy for modularity and. convenient devdopment. Object modules are rdocatable and can be linked with other object
modul~s.

• The Bliss-32 language provides expressions for describing the actions to be
performed and declarations for allocating, describing, and initializing data,
and for defining macros and literals.
• The operators provide a set of operations for integer arithmetic, for comparison, maximization, and minimization of signed integer, unsigned integer, and
address values, and for Boolean operations.
• Fidd references allow values to be retrieved from or assigned to any contigu~
ous fidd from 1 to 32 bits located anywhere in the VAXvirtual address space.
• Character sequence functions provide for efficient runtime manipulation of
character data. Operations include moving, concatenating, comparing and
translating character sequences, as wdl as searching for particular characters
or substrings of characters.

The VAX Bliss-32 Compiler
The VAX Bliss-32 compiler performs a number of optimizations. These include
common subexpression elimination, removal ofloop invariants, constant folding, block register allocation, peephole replacement, test instruction elimination, jump vs. branch instruction resolution, branch chaining, and
cross-jumping.

3-20 • VAX Programming Languages

The VAX Bliss-32 compiler optionally produces source text and generated code
in a format closely resembling a VAX assembly listing. Other options allow you
to control the degree of optimization, suppress production of object code,
determine types and formats of output listings, generate traceback information,
and specify the types of information to be listed at the terminal.
Library and Require Files
The Bliss-32 language provides two methods for including commonly usedtext
into Bliss programs at compile time. These involve use of either Library @es or
Require @es:
• Library Files - These are special @es created by the compiler in a. previous
library compilation and are invoked by the LIBRARY declaration in the Bliss
source program.
• Require Files - These are source (text) @esinvokedviatheREQUIREdeclaration in the Bliss source program.
Because Library files are precompiled, lexical processing and declaration
parsing and checking need not be repeated each time these @es are included in
a compilation; their use results in a considerable reduction in total compilation

time.
The contents of Require files must be fully processed each time the @e is used in
a compilation. Hence using Require @es will, in general, be less efficient than
using Library @es. However, since these @es operate under a less stringent set
of syntactical rules, their use may be warranted in situations in which a higher
level of flexibility is desired.
Macros
The VAX Bliss-32 language provides an extensive macro-building facility,
allowing frequently used groups of declarations or expressions to be expressed
in an abbreviated way. Macros are defined via MACRO declarations and are
accessed by simple call statements. They are fully expanded at compile time.
The Bliss-32 language allows parameters to be specified in the macro definition,
thus allowing each block of text to be specialized by the actual parameters
passed to it. Various types of MACRO definitions give the programmer very flexible and powerful capabilities.

3-21

Debugging
The VAX Bliss-32 compiler produces a list of error messages showing the source
program line on which the error occurred followed by a description of the
error. If the error is recoverable, then the compiler will generate a warning diagnostic and continue with the compilation process. If the error is serious enough
to invalidate the compiler's internal representation of the module, then an error
diagnostic is generated, and processing ceases following the syntax checking no object module is produced.

ilansportability Features
The VAX Bliss-32 language is designed to facilitate transportability; that is, the
writing of programs that can be executed on architecturally different machines
with little or no modification. The VAX Bliss-16 language, discussed later in this
chapter, is a high-level implementation language for the development of systems software for use on PDP-ll systems. Several language features enhance
transportability:
• The high-level language constructs may be transferred from one machine to
another with little or no alteration.
• Machine-specific functions can be separated from the common, mainline
code via modularization, macros, and Library and Require files.
• Machine-specific characteristics can to be passed to Bliss data structures with
the use of parameters.

3-22 • VAX Programming Languages

The following program shows how the VAX Bliss-32 language can call
VAXNMS system services and the VAX Common RunTime Procedure Library
to print the current time on SYS$OUTPUT.
T!ME_OF_OAY
15:58:34

VAX-Ii Bliss-3Z V4.1-74G

15:57:08

BLISS$:[FAIMANlEXAMPLE.BLI;4

ZG-Oet-1984
Pa-!te

26-0et-1884
0001
0002
0003
0004
0005
0006
0007
0008
0009
0010
0011
0012
0013
0014
0015
0016
0017
0018
0018
0020
0021
0022
0023

(ll

MODULE time_of_day (main=print_time)
BEGIN

FORWARD ROUT! NE
print_time : NOVALUE;
LIBRARY 'SYS$LIBRARY:STARLET';
OWN
timestr : BLOCK[23, BYTE],
t.,IECTOR[Z, LONG] INITIAL (23, tirnestr.) f
timedese : BLDCK[8. BYTEl PRESET (
[dsc$w_length ] = 23,

atimenow

Cdsc$b_dtype .J

dsc$f{_dtype_

[dsc$b_class ]
[dsc$a_pointer

= tifllestr);

dsc$I-Lclass_

EXTERNAL ROUTINE
lib$put_output

ROUTINE prin!_time

ADDRESSING_MODE (GENERAL);
NOVALUE

!++

This routine calls the $ASCTIM

SYsteM

service to get the

date and
0024

tiMe as an ASCII strin9, and then calls the RTL routine

L1B$PUT _OUTPUT
0025
0028
0027
0028 2
0028 2
0030 2
0031

to write that string to SYS$OUTPUT.
1--

BEGIN
$asctim (timbuf=atiMenow);
lib$put_output (tiMedesc)

END;

3-23
.TITLE

TIME_OF_DAY

.PSECT

$OWNS.NOEXE.2

00000 TIMESTR:.BLKB
23
00017
.BLKB
1
00018 ATIMENOW:
.LONG
23
00000000' 0001C
.ADDRESS TIMESTR
0017 00020 TIMEDESC:
.WORD
23
01 OE 00022
• BYTE
14. 1
00000000' 00024
.ADDRESS TIMESTR
00000017

.EXTRN

LIB$PUT_OUTPUT. SYS$ASCTIM

.PSECT

$CODE$.NOWRT.2

0000 00000 PRINT_TIME:
.WORD
Save nothingCLRQ
-(SP)
7E 7C 00002
PUSHAB ATIMENOW
0000' CF SF 00004
CLRL
-(SP)
7E 04 00008
OOOOOOOOG 00
04 FB OOOOA
CALLS "4. SYS$ASCTI M'
'IME_DF_DAY
Page 2
2S-0ct-1S84 15:58:34
VAX-II Bli55-32 V4.1-74S
BLISS$:[FAIMANJEXAMPLE.BLI;4 (1)
26-0ct-1984 15:57:08
·OOOO.OOOOG

0000' CF
01

·Ro~tine

Size:

29 bytes,

0032
,. ,:.. 0033

1
0

END
ELUDOM

SF 00011
FB 00015
04 0001C

PUSHAB
CALLS
RET

Routin. Bas.:

$CODE$ + 0000

TIMEDESC
"1. LIB$PUT_DUTPUT

End of Module

PSECT SUMMARY

'tcCUUE$ 'zs'

NOVEC l WRT., flD .NOEXE .NOSHR.
NIWEC.NIlWR-T. RO. EXE.NOSHR.

REL.
REL.

CON.NOPIC.ALIGN(2)
CON .NOPI C .ALIGN (Z')

Library Statistics

SYMbols
Fi~~

,~t~$COlfMON:',~SYSLIB1STARLET. L32 P

0030
0031

Attributes
"S()101111$

0021
0029

Pl'ocessinlf

Total

Loaded

Percent

9776

TiMe

581

00,01.0

3-24 • VAX Programming Languages
COMMAND QUALIFIERS
BLISS/LIST EXAMPLE
Size,
29 code + 40 data bytes
Run TiMe,
00,02.4
Elapsed TiMe,
00,03.0
; Lines/CPU Min,
831
LeKeMes/CPU-Min, 11394
MeMOry Used:

35 pafes

COMPilation COMPlete

Figure 3-5 • Sample VAX Bliss-32 Program Listing

• VAXC
VAX C fully supports all of the language features of c, as described in The C
Programming Language* by B. Kernighan and D. Ritchie. VAX C provides pro-

gram flow control constructs for logical and efficient program structuring,and
a rich assortment of operators. and. common run-time routines ()Qly those
UNIX routines that cannot be. reasonably emulated under VAXlVMS are
omitted.) VAX C even includes language extensions developed since the
Kernighan and Ritchie book was published, including the structure assignment
feature.

Features of VAX C
VAX C provides:

• Awell-developed set of "structured" control flow operators
• Large set of mathematical and logical operators
• Data typing and conversions
• Consistent data declarations and data references
• Compiler produCes very efficient optimized VAX code
• C language extensions

• Extended compiler features; listing and cross-referenced storage map, for
example, which provide capabilities beyond the UNIX level
• Full VAX Language-Sensitive Editor and VAXC support

* "The C Programming Language', B. Kernighan and D. Ritchie, Prentice-Hall, Englewood Cliffs, N.].,1978.

3-25

Who Uses VAX C?
• Those implementing systems and applications-C is a medium level language
• Those familiar with a Unix environment
• Those wishing to transport applications to and from compatible C
environments

VAX C is more than just a faithful implementation of the C programming language. It is a very powerful implementation with an impressive collection of
features and, as important, VAX C is an integrated VAXlVMS language product,
which means that you have available all the services and program development
aids that the VAXlVMS system provides.

The Language
VAX C is a versatile programming language that combines many of the features
of a high-level language with the generality of MACRO, the VAX assembly language. Features include:
Program Control Flow - C uses simple, appropriate English for performing
conditional loops (WHILE, FOR, 00), simple decisions (IF - ELSE), and multicase decisions (SWITCH); and for escaping loops or multicase decisions
(BREAK, G01O).

Data Types - Because C was designed to be a powerful, lean generalist among
languages, it uses directly only the fundamental data types commonly represented by computers: integers of various, fixed sizes, and single and
double-precision floating point numbers. VAX C also provides for user-defined,
or enumerated, scalars (ENUM values) and aggregates (STRUCT or UNION).
ENUM data-types are defined by writing the type name followed by an ordered
list of identifiers that are the constants of that type.
Runtime Support - In order to retain its flexibility of application, the C language does not directly support many functions usually attributed to high-level
languages; for example, 110 or common math routines. But most implementations of C include a common set of run-time support routines for accomplishing
those tasks. VAX C includes most of the non UNIX specific runtime support
offered in the Bell Laboratories version (even many of the UNIX specific routines have been emulated).

3-26 • VAX Programming Languages

Unique To VAX C - New keywords for sharing data among program modules
are offered by VAX C to augment the capability of the standard keyword for
passing arguments, EXTERN. The new keywords - GLOBALDEF,
GLOBALREF, and global value, which allow VAX C programs to define and reference global symbols offer an alternative method for dealing with external
variables and values. They provide, in addition to enhanced data-sharing
among C program modules, a convenient and efficient way for a C function to
communicate with MACRO programs, with VAX!VMS system services and data
structures, and with other high-level languages that support global symbol definition, such as VAX PUr.
VAX C also provides an additional keyword, NOSHARE, that allows you to specify the shareability of data with VMS shared images built with C code.
.
C has an extremely powerful compiler that generates sharable,
position-independent, VAX object code directly from C source programs (that
is, no separate assembly step) a techniques such as excess of 3000 source statements per minute. In the process, the compiler can perform global and local
optimization, for example,by doing global flow analysis, assigning automatic
variables to register temporaries, and removing invariant computations from
loops. The compiler also does peephole optimizations on the generated
machine code. The result: VAX C produces faster and smaller programs.
The VAX C compiler will produce an annotated listing with line numbers and,
optionally, an inline listing of generated machine code, expanded macros, storage allocation map, cross-reference listing of variable usage, expanded CDD
records, translated "DEC/Shell" include file specifications, and compilation
statistics.

Compatibility Across Implementations
Although creation of an ANSI standard for the C languagei$ now underWllY, no
national or international standards for the C language exist. The C Programming
Language, however, is generally regarded as the definitive document, along with
technical notices subsequently published by the American Telephone and Telegraph Company.
Certain incompatibilities among implementations do exist however, especially
in machine-specific library routines. To aid creating portable programs, VAX C
provides predefined constants (VAX, VMS, and VAX C). These can be used, for
example, in conditional compilation to decide whether to compile source code
that may not be portable. The VAX C compiler command, CC, also has an
optional feature that detects several nonportable program constructions and
issues warning messages.

3-27

UNIX - VAXlVMS Coexistence - The C programming language was originally
developed at Bell Laboratories for creating the UNIX operating system, and it
has become the language of choice for many applications developed on that
system. As an aid to migrating programs from UNIX systems to VAXIVMS, the
VAX C run-time library includes many of the UNIX-specific UNIXIC routines,
emulated to run under VMS.
int value = -21
Main!)
{

printf( :The absolute vall,1e of Xd is '%,d\n" ,value ,absolute(value»;
}

absolute(X)
int X;
{

if (X > 0) return X;
else return ..:(X);
}

Figure 3-6 • Sample VAX C Program

• VAXCOBOL
VAX COBOL is a high-performance implementation of COBOL. It is based on
American National Standard Programming Language COBOL, X3.231974, the
industry wide accepted standard for COBOL. Most features planned for the
next COBOL standard, based on the specifications in the Draft Proposed
Revised X3.23 American National Standard Programming Language COBOL,
are also included.
VAX COBOL also supports an embedded Data Manipulation Language (DML)
interface to VAX DBMS, Digital's CODASYL compliant Database Management
System. Also, it allows access to common record definitions stored in the VAX
Common Data Dictionary. VAX COBOL's support of features in the next ANSI
COBOL standard, of the VAXInformation Architecture, and of other
Digital-defined extensions to COBOL makes possible a wider range of COBOL
applications on the VAX.

3-28 • VAX Programming Languages

Features of VAX COBOL
VAX COBOL:

• Supports ANSI COBOL and VAX shtgle and double floating point and address
datil

types

• Supports contained and CALL statement facilities .
• Supports an interface to VAX DBMS, Data Manipulation Language (DML) .
• Provides for the creation of form and reports on selected terminals with the
screen handling extension to the ACCEPT and DISPLAY statement
• Provides full report writing capabilities
• Provides complete sequential, relative, and indexed 110
• Contains many features from the next proposed COBOL standard
• Full Language-Sensitive Editor Support

Who Uses VAX COBOL?
• Most widely used language for general data processing
• Banks and other financial institutions
• Many commercial applications, including:

.,.-- Payroll
. - Accounts Receivable
-

Inventory Control

Object mOdules produced by the compiler can be linked with object modules
produced by other VAX language processors.

Stnictured Programming
VAX COBOL adds some of the features of traditional structured programming
languages (such as B\SCAL and PllI ) to the VAX COBOL compiler. This facility
makes programs easier to develOp, understand, and mamtain. It reduces program development and maintenance costs. The structured programming facilities supported by VAX COBOL include the EVALUATE statement, scope
delimited statements, and the inline PERFORM statement.
The EVALUi\TEstatement in a CASE -like statement is found in modern programming languages and allows the selection of statements to be executed,
which are dependent on the state of program variables. Scope delimited statements simplify COBOL coding that previously required additional GO 10 statements and procedure names. The inline PERFORM statement reduces program
complexity by putting logic of the PERFORM inline.

3-29

The following program example illustrates the use of the structured. programming facilities in VAX COBOL _
INITIALIZE-STATE.

PERFORM VARYING I FROM 1 BY 1 UNTIL 1>12
MOVE 0 TO MONTHLY-RETRIEVE-TRANSACTIONS(I)
MOVE 0 TO MONTHLY-UPOATE-TRANSACTIONS(I)
END-PERFORM
TRANSACTION-LOOP.

MOVE MONTH-INDEX TO I.
EVALUATE TRANSACTION-TYPE
WHEN "RETRIEVE"
WHEN "retrieve"

READ TRANS-FILE AT END
MOVE "EDF" TO TRANS-EOF-SWITCH
END-READ
IF TRANS-EOF-SWITCH NOT· "EOF"
THEN
ADO 1 TO MONTHLY-RETRIEVE-TRANSACTION (I)
END-IF
WHEN "UPDATE"
WHEN

up date"

ADD 1 TO MONTHLY-RETRIEVE-TRANSACTIONS(I)
WHEN OTHER
DISPLAY TRANSACTION-TYPE "is an invalid transaction"

ADD 1 TO TRANS-ERROR-CNT
END-EVALUATE.
GO TO TRANSACTION-LOOP.

Figure 3-7 • Use a/VAX COBOL Structured Programming Techniques
The example illustrates the use of the in1ine PERFORM statement whose scope
is delimited. by END-PERFORM. The in1ine PERFORM loop initializes monthly
transaction counts in preparation for the subsequent transaction analysis. The
EVALUATE statement performs the transaction analysis and illustrates the typical use of this statement: a set of actions to be executed, dependent on the state
of a program variable (for example, TRANSACTION-lYPE). For the cases not
specifically mentioned, the WHEN OTIffiR imperative statement sequence is executed which, in this example, does exception reporting and a count of the transaction errors. The scope delimiters are END-PERFORM, END-READ, END-IF ,
and END-EVALUATE. These delimiters help to organize the program and to
make the program more understandable and maintainable.

3-30 • VAX Programming Languages
Data Types
VAX COBOL supports the data types specified in the ANSI COBOL Standard.
VAX COBOL also supports, as extensions, the packed decimal (COMP 3), floating point (COMP 1), double floating point (COMP 2), and address (POINTER)

data types.
The following is a summary of the data types supported by VAX COBOL:
• NUmeric DISPLAY data
- '1hilling overpunch sign
- Leading overpunch sign
- '1hilling separate sign
- Leading separate sign
- Unsigned
- Numeric edited
• Numeric COMPUTPJIONAL data
- \Xbrd fixed binary
- Longword fixed binary
- Quadword fixed binary
• Packed decimal data (COMPUTATIONAL -3)
- Unsigned packed decimal
- Signed packed decimal
• Floating-point data
- FJIoating (CQMPUTATIONAL-I)
~ DJIoating (COMPUTPJIONAL -2)
.i~ Alphanumeric DISPLAY data

~ Alphatiumeric
.-: Alphabetic
c.... Alphanuniefic edited

• .Address data
- IUinter

• VAX DmOL
VAX DIBOL (Digital Interactive Business Oriented Language) is a high-level,

procedural language designed specifically for interactive data processing in the
business environment. It takes full advantage of the VMS system's facilities.

3-31

VAX DIBOL is based on the DIBOL Standards Organization's DIBOL -83 definition of the language. VAX DIBOL is highly compatible with DIBOL -83 implementation on other operating systems.
VAX DIBOL consists of a DIBOL compiler, a sharable runtime library, a program
debugging aid called the DIBOL Debugging Technique (DDT), and a set of
utility programs that facilitate data handling, data storing, and interprogram
communication.
Features of VAX mBOL

• VAX DIBOL 's ease of use, extensive functionality, and concise syntax make it
an easy to learn language, which can be used to develop commercial application programs quickly and efficiently
• VAX DIBOL 's debugging facility, DDT, makes debugging applications under
development easy and straight forward
• VAX DIBOL is highly compatible across the following PDP -11 operating
systems:
CTS300

RSTSIE
RSX -11M -PLUS
MicroRSX
• Migrating DIBOL -83 programs to VAXNMS from any PDP -11 version of
DIBOL -83 requires minimal effort and expense.

Who Uses VAX DIBOL?
Users of VAX DIBOL include:
• OEM s and end users to create business applications quickly and efficiently in
the following areas:
Manufacturing
Aviation
General business and operations for cable TV companies
Medical, dental, and legal billing systems
General,business and control for retail operations
Accounting

VAX DIBOL provides efficient terminal handling and efficient access to the VAX
Record Management Services (RMS ), VMS System Services and Run-Time
Library (RTL ). VAX DIBOL conforms to the VAX calling standard, allowing
DIBOL programs to call or be called by routines written in other languages.

3-32 • VAX Programming Languages

DIBOL Language Statements
A. DIBOL statement has one or more elements.. The first element. is 'an
English-language verb that commands an action to be performed; The remaining elements are either k,eywords or arguments.
• Keywords modify or supplement the action of the verb.
• Arguments specify the objects of the action. They can consist of symbOlic
data names, references to' statement labels, arithmetic expressions, or relational expressions.
DIBOL statements fall into the following functional groups:
• Compiler directive'
• Compiler declaration
• Data declaration
• Data manipulation
• Control
• Interprogram communication
• Input/Output
Program Structure
,
A VAX DIBOL program consists of two major divisions - a data division and a
procedure division. The data division contains the data declaration statements.
These define data characteristics and identify of the data used by the program.
The procedure division contains all of the program statements that implement
the actions or tasks to be performed. The .TITLE compiler directive, for example, places headings on a DIBOL program listing to provide clearer program
docUmentation. The PROC' statement ~parates 'the data division statements
from the procedure division statements. The BEGIN and END statements provide a means of "blocking" statements so that a group or blOck of statements
can be used whenever a single statement is legal (IF-THEN_ELSE or
DO-UNTIL). END Citn,~ be used at the physical end of the: program, in effect
forming a block of statements whose beginning is the PROC~atement.
'
i"
,.
~'"

DATA TYPES - VAX DIBOL allows progriuDdatato be stored ihnumeric (decimal) form, such as numbers used for calculation, or in alphanumeric (alpha)
fottn, such'as names and addresses.

3·33

SUBROUTINE LIDRARIES - VAX DIEOL 's external subroutine capability
allows you to develop subroutines to perform special-purpose functions without having to code the routine into each program. The subroutines can be
user-developed or taken from a VAX DIDOL external subroutine library.
VAX DIDOL includes three external subroutine libraries.
• The Universal External Subroutine Library (USEL ) includes subroutines that
are available and that perform the same functions on all operating systems on
which DIBOL -83 exists.
• The Operating System Specific Library (OSSL ) includes subroutines that are
available and perform similar functions on one or more of the DIDOL -83
systems.
• The Run-Time Subroutine Library (RTSL ) includes subroutines that are
available only in VAX DIBOL and provide functions unique to VAX .

UTIliTIES - VAX DIDOL utilities include the DIDOL Debugging Technique
(DDT ), a Message Manage utility (DBLMSGMGR ),and a status utility
(DBLSTATUS) .
• DDT (DIDOL Debugging Technique) - is a program debugging aid that
allows you to examine and/or change program data at run-time, to set
breakpoints at various places in the program, and to examine the flow of execution throughout the program.
• DBLMSGMGR (DIBOL Message Manager) - stores and retrieves messages
for DIBOL programs that use the SEND and RECV statements. Messages can
be sent to programs that are running concurrently with the sending program
or to programs that run subsequently. The sending program designates the
name of the program that is to receive the message and optionally, th.eterminal number on which the receiver will be running. The receiver retrieves the
message by executing a RECV statement.
• DBLSThTIJS (DIDOL Message Status) - allows you to examine and optionally delete any messages currently being held by the Message Manager.
Operating Procedures
After a DIDOL source program is created and edited, it is compiled by the
DIDOL compiler. The DIDOL compiler generates binary operation codes that
are linked into an image. They are then interpreted and executed at run time by
.
the DIDOL RTL interpreter.
When executable programs are run, the operation codes are executed by the
DIDOL run-time library interpreter, and the program output is produced.

3-34 • VAX Programming Languages

Compilation and the DmOL Compiler
The DIBOL compiler reads DIBOL source files and produces linkable object
files.

In addition to producing object files, the compiler detects and reports syntax
errors, and can produce a listing file that contains:
• A listing of the source program
• A table of variable names used in the program (symbol table)
• A table oflabel names used in the program (label table)
• A report of the number and type of errors that were encountered during
compilation
• The error listing
• A cross-reference listing

Contents of the Listing File
The listing file consists of:
• The program listing
• The symbol table
• The label table
• The cross-reference listing

THE PROGRAM LISTING - The program listing consists of the original
source code with line numbers prefixed to each DIBOL statement, with the
exception of certain compiler directives, continuation lines, blank lines or commentlines.
Line numbers are used in the symbol table, the label table, and the
cross-reference listing to identify the location of variable names and label
names. Line numbers are also useful in debugging (DDT) and error trapping at
run-time.
For each error detected during compilation, an error message appears in the
line-numbered listing. Each message appears immediately after the line in
which the error is detected.

THE SYMBOL TABLE - The symbol table contains descriptive information on
each variable in the source code. The table consists of information on the name
(NAME) of data fields used by the program, the data type (1YPE ) of the field,
the number of data elements in the field (DIMENSION), and the number of
characters (SIZE) required to store the field.

3-35

THE LABEL TABLE - The label table contains descriptive information on
each label name and external subroutine name in the source code. The table
consists of the name (NAME) of each label that is used by the program and
the line number (LINE) of each label definition.
THE ERROR USTING - This report contains a list of the type and number of
errors that were detected during compilation.
THE CROSS-REFERENCE USI'ING - If the CROSSJlliFERENCE option is
selected, five additional tables are generated.
• The symbol cross-reference table
• The COMMON cross-reference table
• The label cross-reference table
• The external subroutine reference table
• The external symbol table

• VAXDSM
VAX DSM (Digital Standard MUMPS) is a multiuser data management and language processing system. The DSM language is a high-level, interpretive language well suited for the processing of variable-length string data. It conforms
to the American National Standard MUMPS specification Xl Ll-1977. In addition, it provides a number of extensions.

Features of VAX DSM
• Highly interpretive, procedural language
• Requires no compilation

• DSM precompiler optimjzes execution of routines

• Part of the Digital common language environment
• Provides system and library utilities, written in the DSM language

Who Uses VAX DSM?
Users of VAX DSM include:
• Medical Institutions
• Banks and Brokerage firms
• Manufacturing facilities
• Any organization that has a need for a high-performance, data management
system.

3-36 • VAX Programming Languages

Interpretive processing of the language means that each line of a DSM routine is
executed as it is entered. Routines written in the DSM language do not have to
be compiled or linked, making it easier to write, debug, edit, and run a job in
one interactive session.
As DSM program lines are entered, the DSM interpreter examines and analyzes
each DSM statement and executes the specified operation. It performs error
checking during the routine execution and reports all errors at the terminal.
This reduces problem-solving time, the computer time required to check the
routine, and more importantly, the time required to check the routine, and most
importantly, the time required to obtain a final running application.
The DSM language has many capabilities, but its basic orientation is procedural.
The language is directed primarily toward th~ processing of variable-length
string data, making interactive database systems easier to implement and
maintain.
Data Management

The DSM language allows you to reference data symbolically through variables.
A variable can contain either a numeric value or an alphanumeric string.
The VAX DSM system utilizes local and global variables. Local variables are
defined solely forthe current user (or process). Local variables are not intended
for permanent storage, but only for temporary use during the life of a process.
Global variables, or simply globals, are stored ohdisk. Globals are referenced
syrnbolically using names similar to those of local variables, the only difference
being the circumflex preceding the first character in the variable name. Subscripted globals form a system of arrays stored on disk, the data of which forms
a common database that can be made available to one or more users in the
system.
Global arrays are sparse arrays; that is, the system dynamically adds nodes to
the array as a user stores data in them, and deletes nodes as a user deletes them.
Thus you never have to preallocate space for globals through dimensioning, nor
do they have to explicitly recover disk space when they delete data.

VAX DSM provides a high performance multiway tree structure for the implementation of global variables handled by a component referred to as the Global
Module. This Global Module is implemented as an integral part of the VAX
DSM product. Alternatively, you can specify individual globals for storage in
VAX RMS ISAM files. Specifying the default and individual globals list is done at
the time the structure is created or any time the structure is not active. Subsequent data storage happens transparently at the program leveL If you choose,
VAXRMS ISAM can be selected as the default and individual globals specified
will be directed to the Global Module.

3-37

Globals residing in VAX RMS ISAM files can be accessed by DECnet and other
VAXlVMS languages. Globals maintained by the Global Module are accessible
by VAX DSM only. VAX DSM provides the necessary utilities and 10 language
elements needed to transfer data stored in a global structure.
The Global Module provides high throughput due to caching of disk blocks.

In general, global arrays are treated syntactically in the DSM language just as
local arrays. To create a global array, the SET command is issued. To access and
manipulate its contents, any number of commands and functions in the DSM
language set are used. To delete a global node, the KILL command is issued. To
delete the entire global array, its root node is killed.
This arrangement eliminates the need to be concerned with the physical structure of files when designing a database application (as is the case with some
database systems). Using globals, you need be concerned only with the logical
relationship between elements of a database.

The PRECOMPILER
The VAX DSM system provides a language PRECOMPILER to optimize the execution of DSM routines in an application environment. The PRECOMPILER is a
component of the DSM interpreter that processes all DSM program lines into a
more efficient, intermediate format, called a precompiled format, in order to
expedite subsequent interpretation.
When you store.a routine, the system places both the source and precompiled
versions in the DSM routine directory. For a given routine version, the precompilation procedure occurs only once. When you execute a routine from the
directory, the VAX DSM system automatically loads the precompiled version.
Because the system saves both routine versions, you can always load, edit, and
test DSM routines interactively. The precompilation procedure is repeated if a
routine is edited or updated.
The VAX DSM PRECOMPILER transforms DSM program lines into precompiled format with the following optimizations:
• It strips comments.
• It checks syntax.
• It sets up an internal table for line labels used to optimize Gom statements
and 00 statements that transfer control to other routine lines.
• It evaluates constants and transforms numbers into an internal representation
(that is, packed decimal or longword).

• It converts arithmetic statements into "Reverse Iblish Notation."
• It restricts the evaluation of a series of postconditionaIs to the occurrence of
the first false condition. To do this, the PRECOMPILER generates codes that
specify the appropriate offset to a given instruction.

3-38 • VAX Programming Languages

Procedure Cans
The VAX DSM system allows you to access services that are not part of the DSM
language through a Digital-implemented extension to Standard MUMPS, called
the $ZCALL function. Through $ZCALL, you can call VMS system services, routines in the VAX Common Run-Time library, or routines written in other languages directly from DSM application routines. For example, the DSM language
does not include a square root function. The function is in the Digital RUh-Time
Library, and can be called through the procedure calling mechanism.

110 Options
The VAX DSM system provides a subset of the Input/Output (VO) options of
the VMS operating system. Each of these options can be accessed through commands in the DSM language set. You can access any VAX!VMS-supported device
through commands ih the DSMlanguage set.
The VAX DSM system provides an interface to VMS I/O handlers according to
device type. Terminal I/O and communication through mailboxes is handled by
the VMS Queue I/O service, whereas I/O to all other devices is performed
through VAX RMS. This allows you to access RMS sequential, relative, and
indexed files,besides, global variable files they access DECnet software.

Shared Memory Areas
The VAX DSM system supports a high degree of code and data sharing through
the use of VMS memory sections. Mapping a set of precompiled DSM routines
in a virtual memory section improves the performance of a DSM application
because the system does not have to access DSM routines stored· on disk.
Instead, it can execute the routines directly from virtual memory.
VMS memory sections can be either private or shared. If shared, they are called
global sections. Global sections can be created dynamically byaprocess or they
can be permanently present in the system. Permanent global sections are generally created from routines to which a number of users reqWre access, When a
group of routines or an applicationi~ installed in a global sectioh,all users share
the same copy of precompiled DSM routines. At ruh time, a copy of this set of
routines is mapped into the virtual address space of requesting process.

The DSM Job Controller
The DSM Job Controller is a separate process that manages interlock requests
by multiple DSM user processes. It also allows system wide control over the
running of DSM applications, providing functions stich as enabling and disabling joutnaling.
Communication between a VAX DSM process and the DSMJobController takes
place through mailboxes.

3-39

The VAX DSM system provides you with the option to use or to bypass the DSM
Job Controller at DSM image activation. \Xbrk that does not affect a common
database - typically program development - can bypass the job controller.
Whenever you and another user are running a DSM application, interlocking
.
requires the use of the DSM Job Controller.

JoumaIing
Journaling is a means of keeping a record on secondary storage (disk or magnetic tape) of transactions that alter the database (for example, global variable
SETs and KILLs). VAX DSM journaling is handled by a separate process communicating with DSM users through mailboxes.
VAX DSM provides a number of journaling options to meet the needs of a system running multiple applications. Depending on the options selected, there
can be one or more journal processes. One journal process can be run for each
group in the system, for a number of groups in the system, or for the entire
system.

System and Library Utilities
VAX DSM includes a number of utility routines written in the DSM language.
These routines help you develop and maintain applications, and help the system manager control the running of DSM applications.
The utilities are divided into two categories - library and system utilities.
Library utilities perform general services in three categories: procedures affecting routines, globals, and miscellaneous operations, such as numeric conversion. System utilities perform services in the areas of journaling and job control
and other maintenance operations and system information.
Generally, the system and library utilities are accessed through a menu-driven
utility package. Most utilities in the package at:e interactive. Most utilities also
provide extensive online documentation that explains-how to use them.

• VAX FORTRAN
VAX FORTRAN language specifications are based on American National
Standard FORTRAN X3.9·1978 (commonly called FORTRAN-77). The VAX
FORTRAN compiler supports this standa~d at the full-IangJIage level. Also, it
provides full support for many industry-standard FORTRAN features based on
FORTRAN-66, the previous ANSI standard: The qualifier IN0F77 will select the
FORTRAN-66 behavior where the two standards conflict.

3-40 • VAX Programming Languages

The VAX FORTRAN compiler:
• Produces highly optimized VAX object code
• Makes use of the VAX floating point and character string instructions
• Produces shareable code and the compiler is shareable

Features of VAX FORTRAN
• Support for all VAX RMS @e formats
• Many I/O extensions
• Efficient character data handling
• INCLUDE statement

• External function and procedure calls
• Shareable programs
• Thorough optimization
• Record structure and Common Data Dictionary support

Who Uses VAX FORTRAN?
• Scientific users
• Technical users
• Educational users
• Realtime application writers.

Language Characteristics

CAllING EXTERNAL FUNCTIONS AND PROCEDURES - FORTRAN programs can call subroutines and functions written in other VAX native-mode languages and system services. Special operators exist for passing argument values
directly, by reference, or by descriptor. A special operator also exists for
obtaining the argument values used by the system services procedures.
SHARED PROGRAMS - The FORTRAN language can be used to create shareable images, which can be used by any program written in a native programming language.

3-41

DIAGNOSTIC MESSAGES - Diagnostic messages are generated when an error
or potential error is detected_ Errors detected during compilation are reported
by the compiler, and include source program errors, such as misspelled variable
names, and missing punctuation marks_
Source program diagnostic messages are classified according to severity: F
(Fatal), E (Error), or W (W-irning)_ F-class messages indicate errors that must be
corrected before compilation can be completed_ Object code is not produced_
E-class messages indicate that an error was detected that is likely to produce
incorrect results; however, an object file is generated_ W -class messages are produced when the compiler detects acceptable but nonstandard syntax; or when
it corrects a syntactically incorrect statement_ The message indicates the existence of possible trouble in executing the program_
The VAX FORTRAN compiler optionally produces diagnostic messages for VAX
FORTRAN extensions to ANSI FORTRAN- This Hagger can check both syntax and source form extensions_

DEBUGGING FORTRAN PRCXJRAMS - The VAX FORTRAN language provides facilities to aid the debugging of programs written in native mode_ It
accomplishes this via a program known as the interactive symbolic debugger_
The debugger can be linked with a native program image to control image execution during development_ It can be used interactively or can be controlled
from a command procedure file_ The debugging language is similar to the VMS
command language_ Expressions and data references are similar to. those of the
source language used to create the image being debugged.
Debugging commands include the ability to start and interrupt program execution; to step through instruction sequences; to display source statements; to call
routines, to set break or trace points; to set default modes; to define symbols;
and to deposit, examine, or evaluate virtual memory locations.

COMPILER OPERATIONS AND OPTIMIZATIONS - The VAX FORTRAN
compiler accepts sources written in the FORTRAN language and produces an
object file which must be linked prior to execution. The compiler generates
VAX native machine language code. It will also generate an optional
cross~reference listing.
During compilation, the compiler performs many code optimizations. The
optimizations are designed to produce an object program that executes faster
than an equivalent nonoptimized program. Also, the optimizations are
designed to reduce the size of the object program.

3,42 • VAX Programming Languages

The VAX FORTRAN compiler performs the following optimizations:
• Constant folding - constant expressions are evaluated at compile-time.
• Compile-time constant conversion..
• Compilectime evaluation of constant subscript expressions in array
calculations. .
.
• Constant pooling - only a single copy of a constant is allocated storage in the
compiled pt:O'gram. Constants that can be used as immediate mode operands
are not allocated storage. For example, logical, integer, and small floating-point constants are generated as immediate mode or short literal operands wherever possible.
• In-line expansion of statement functions.
;, Argument list merging - If two function or subroutine references have the
. 'same arguments, a single copy of the argument list is generated.
.

• Branch instruction optimizations for aritbmetidogical IF statements.
• Elimination of unreachable code - An optional warning message is issued to
mark unreachable statementS in the source program listing.
• Recognition and replacement of <;~mmon subexpresslons.
• Removal of invariant computations from loops.

• .Local register assignment' ~ Frequendy referenced variables are retairied
(when possible)iri registers to redUCe the number of load and store
instructions.
• Assignment.of frequently usedvariables and expressions to registers across
loops.
'
• ~rderin~exl:'r~;}>eval~aclonto minimize the amount of temporary regIsters r~wred. . '.. . . . . . .
• .Dclayingnegatioolnor to eliminate
• Flow-&okan op~tionS. .

illtarY complement oper~tions.
,

• Strength Redtictioll -' MUltiply operations used in array indexing are
t:OOuced to adds.. Efficient Auto Increment and A'Uto.Decrement address
moqesare qsed wherever.possible..

• JumplBranch instruction resolution,..:.. .The Branch instruction is used wher, ever posSible to elimiriate unnecesSaty]ump instructions. This reduces code
SIZe.

• Peephole optimizations - The code is examined on an operation-by-operation basis to replace sequences of operations with shorter and
faster equivalent operations.

3-43

When debugging FORTRAN programs, you can disable optimizations that
would remove not-referenced statement labels, FORMAT statement labels,
and immediately referenced labels. This ensures that all statement labels are
available to the debugger.

• VAX LISP
For over 20 years, LISP has been one of the fundamental tools used in Artificial
Intelligence (AI) research. The LISP ("LIS"t "P"rocessing) programming language is based on a paper, published in 1958 by John McCarthy, dealing with
non-numeric computation. It differs from the majority of higher-level programming languages in that LISP programs do not use numeric computation as a
basis for program execution, (although it does support facilities for numeric
computation) .
LISP is particularly useful for the manipulation of symbolic data. Symbols can
be thought of as words; lists of symbols are then equivalent to sentences or
statements. Because LISP's symbolic processing and knowledge representation
capabilities can be easily used to represent human thought patterns and associations, the LISP programming language has become an essential tool for Artificial Intelligence researchers as they attempt to make computers simulate human
behavior and thought.
LISP is also a great general-purpose language used for in a wide variety of applications. Any imaginable type of program be wrirten in LISP; entire operating
systems have been written in LISP.
Features of VAX LISP
VAX LISP, an implementation of Common LISP, is an extremely important dialect of LISP. VAX LISP provides you with:
• Common LISP compliance
• Rich set of data types and functions
• VMS integration
• Fully interactive interpreter
• Compiler
• Dynamic linking
• Lexically scoped v~iables
• LISP-sensitive editor
• Program debugging facilities
• LISP program-formatting utility

3-44 • VAX Programming Languages

• COMMON LISP COMPUANCE
Common USP is rapidly becoming the de facto staridard for the USP programming language. Major corporations and government agencies are moving
quickly to standardize on this dialect.

• VMS INTEGRtU'ION
VAX USP can be integrated with VMS. There is no need foryou to abandon or
convert software written in other VAX languages. Programs written in VAX USP
can call non-USP routines that conform to the VMS calling standard. USP programs can access RMS, DATI\TRlEVE, VAX DBMS and VAX RdbIVMS, VMS utili:
ties and VMS system services.·It can also access your software that conforms to
the calling standard.
• LEXICALLY SCOPED VARIABLES
The VAX USP compiler and the interpreter both generate code which exeCutes
identically. Earlier implementations of USP frequently included compilers
whose semantics differed .from those of the interpreter.
• LISP EDITOR
VAX USP provides its own language-sensitive editor with multiple· window
capabilities. Since the editor is written in USP, it is readily extensible. You can
define new editor functions in .Lisp and bind them to keyboard keys.
• DEBUGGING FACILITIES
A full set of USP debugging utilities are included. These utilities ate integrated
by a common command interface. The USP debugger allows; for example,
examination of the. state of a running program, including the stack, variables
and functions. A stepper allows you to step through the execution of a program, one line at a time. The trace utility allows the automatic display of function calls and returns during program exe<;ution.

Who Uses VAX LISP?
VAX USP is used in the artificial-intelligence market place by:
• The research community - Investigators of human intelligence
• OEM's and software· houses - Creating attificial intelligence applications for
sale to end usets
• Industry and government - Using the technology for internal applications

3-45

Using VAX LISP
This section provides a general introduction to the use of VAX LISP. The following topics are covered:
• Invoking LISP
• Using command levels
• Controlling input
• Creating programs
• INVOKING LISP
You invoke an interactive VAX LISP session by typing the DCL command LISP.
When it is executed, a message identifying the VAX LISP system appears and the
LISP prompt is displayed. To exit, enter (EXIT) and you will be returned to the
DCL command level.
• USING COMMAND LEVELS
VAX LISP gives you various time saving and ease-of-use facilities. One of the
most important of these, the top level read-eval-print loop, provides the basic
means to write and execute programs. In addition, VAX LISP also offers a break
loop, and debugger and stepper facilities. When any of these facilities is
invoked by means of a function call, an error, or some other event, it establishes
a "command level." A command level represents a point of interaction between
you and the program and is assigned a number. The highest numbered levels
represent the current level of interaction between you and the program, while
the lower-numbered levels represent interactions that have been temporarily
suspended. Nothing prevents the same facility from being invoked more than
once. There can be multiple command levels representing the same facility. For
example:
Lisp) (breaK)

break 1> (+ *CQunter* 1)
Fatal e r ro r

in function SYSTEM::ZEVAL (ai'naled wit~ ERROR),

Symbol has no value: *COUNTER*
Control StacK DebuSSer
Frame #7: <EVAL (describe *counter*»

DEBUG Z> (BREAK)
BREAK 3> (describe *COUNTER*)

3-46 • VAX Programming Languages
Fatal error in function SYSTEM::%EVAL (si.naled with ERROR),
SYMbol has n~Q value: c*COUNTER*
Control Stack Debu •• er
FraMe #19: (EVAL (describe *counter*»
Oebu!f 4> . . . .

In this example, you invoke a break loop and make an attempt to use the special
variable *counter*, which has no value, causing the debugger to be invoked.
Then you can invoke another break loop and accidentally make the same mistake again;·causing another debugger leVel to be invoked.

• CONTROLLING INPUT
When using VAX LISP, expressions are entered one line at a time. Once you
move to a new line, you caIinot go back to the previous line. However, you can
recover an input expression or an output value by using one of ten unique variables (see Common LISP: mE LANGUAGE for a detailed description of each):
The following example illustrates the use of the plus sign ( +) variable that is
bound to the expression most recently.evaluated:
Li..sP> (ccdr 'Cab c)··

(II C)

(~DR

lisp)

(QUOTE (AIIC»)
•

lbu can use the <DELETE> key and several control characters on your tenninal keyboard to control input. The <DELETE> key allows you to delete characters that are to the left of the cursor on the current line of input..

• CREATING PROGRAMS
The most common way of creating a LISP program is as a source file with a text
editor. The program is loaded into the LISP environment by means of the LISP
LOAD function.

3-47

Although you can compose source programs with any text editor, the VAX
LISP Editor provides facilities that help you enter and edit LISP source code_
For example, the editor helps you balance parentheses and maintain proper
indentation_ Furthermore, this editor, being integrated into the LISP environment, can be extended to fit your personal editing style, and can also be
used to evaluate code without leaving the editor_ You can go back and forth
between the editor and the read-eval-print loop at will.
Another way to create LISP programs is to define them using the interpreter in
an interactive LISP session_ If you define functions with DEFUN and macros
with DEFMACRO, the definitions immediately become part of the interpreted
LISP environment_ You can then invoke your defined functions and macros_
However, since these definitions are not in a pertnanent text @e, your work is
stored only temporarily and disappears when you exit VAX LISP, unless you use
the editor to write the function definition out to a @e_ Entering programs by
means of the interpreter is most useful for experimenting with smaIl functions
and macros_
The following definition of the FAClORIAL function is an example ofa LISP
program_ It can be written in the following format in a @e or in an interactive
LISP session:
(defun factorial (n)
(if

«= n 1)
(* n (factorial

(- n 1»»)

(defun) indicates this example is a function definition_ (factorial) is the name of
the function_ (n) is the argument list; that is, (factorial) takes one argument, n_
When (factorial) is caIled, the code following the argument list is evaluated and
the last result computed is returned as the value of the function_

3-48 • VAX Programming Languages

·VAXPASCAL
VAX PASCAL is.a multipass, optimizing cpmpilerthat is a powerful superset of
the PASCAL language as defined by Jenset) and Wirth in PASCAL User Manual
and Report (1974), VAX B\SCAL accepts programs that are compatible with
either the ANSI/IEEE 770X).97 standard or the ISO standardmIS 7185) ..
PASCAL's block structUred nature, flexible data types and English"like statem,ents result in. significant ease-of~use benefits. These benefits include ease of
program generation and ease of reading, modifying, and maintaining programs.
VAX PASCAL offers the incremental capability of Ct(!ating a productivity environmentin which many programmers can work simultaneously, and relatively
independently, on the same project.

Features ofVAX PASCAL
Standard B\SCAL provides a modular, systematic approach to· computerized
problem solving. Major features of the language are:
• INTEGER, REAL, CHAR, BOOLEAN, enumerated, and subrange data types
• User-defined data types

• ARRAY, RECORD, SET, and FILE structured data types
• Constant identifier definition
• FOR, REPEAT, and WHILE loop control statements
• CASE and IF-THEN-ELSE conditional statements
• BEGIN...END compound statement

• G01D statement
•. GET, PUT, READ, WRITE, READLN, and WRITELN 110 procedures

Who Uses VAX PASCAL
Users of VAX B\SCAL include:
• Educational institutions for training
• Industry
• System's engineers
• Writers of business applications

3-49

The VAX PASCAL language takes advantage of the VAX hardware floating
point, character instruction sets, and virtual memory capabilities of the VMS
operating system. Features common to other languages of the VMS operating system are available through the VAX PASCAL language including:
• VAX symbolic debugger support
• Separate compilation of modules
• Standard call interface to routines written in other languages
• Access to VMS system services
• Access to all RMS file organizations
• Access to CDD data declarations
• VAX Language-Sensitive Editor Support
At compile time, options available to the process include:
• Run-time checks for illegal assignment to set and subrange variables, illegal
array and string subscripts, illegal case selectors, integer overflow, and illegal
pointers
• Cross-reference listing of identifiers
• Source program listing
• Machine code listing
In addition to the features mentioned above, the VAX .mSCAL language incorporates the following extensions to standard PASCAL, some of which are common inPASCAL implementations:
• Lexical
Uppercase and lowercase letters are treated identically except in character and stting constants
New reserved words: MODULE, OTIIERWISE, VALUE, REM, a%REF,
%DESCR, %J;MMED, %INCLUDE, and %SIDESCR
The exponentiation operator, ,'*
Concatenation operator+
Hexadecimal and octal constants
DOUBLE constants

$ and (underscore) characters in identifiers

3-50 • VAX Programming Languages

• Predefined data types

DOUBLESINGLE
QUADRUPLE
VARYING character strings
UNSIGNED
• Predeclared routin~s

110 (OPEN, CLOSE,- RESET, REWRITE, EOF, ECJW, STATUS, ... )
Arithmetic (ABS, SQR, SIN, COS, ... )
Ordinal (PRED, SUCC)

Boolean (ODD,UNDEFINED)
'1hmsfer (CHR,DBLE,INT,ORD, ... )
Dynamic allocation (ADDRESS, NEW, DISPOSE)
Character string manipulation (INDEX,LENGTH, SUBSTR, PAD, ... )
Unsigned (UAND, UNOT, UOR, UXOR)
Allocation size (SIZE,NEXT;BITSIZE,BITNEXT)
Miscellaneous (CARD, CLOCK, DATE, EXPO, HALT, ... )
• Other extensions
READ (or READLN) of user-defined ordinal type
READ (or READLN) of string

WRITE (or WRITELN) ofuser-defined scalar type
WRITE (or WRITELN) of any data using binary hexadecimal or octal
format
%INCLUDE directive
VALUE initialization

OTHERWISE clause in CASE statement
External procedure and function declarations
Conformant array parameters
Optional attribute specification on types, variables, routines, imd compilation units

3-51

• Separate compilation
A MODULE capability for combining procedures, functions, and other
declarations for compilation apart from the main program
ENVIRONMENT and INHERIT attributes to control separate and independent compilation

External variable, procedure and function declarations
The OPEN, CLOSE and FIND procedures extend the VO capabilities of the.9\$CAL language_ The OPEN procedure can contain file attributes that define the
creation or subsequent processing of the file. A FIND procedure is another
extension to the language for direct access to sequential files of fixed length
records. The standard Vo procedures of GET,PUT, READ; WRITE, READLN
and WRlTELN are also available in the VAX B\SCAL language.
The extended parameter specifications %DESCR, %IMMED, and %STDESCR
are added to the Btscallanguage to denote the method of argument passing
when calling a system service, procedure, or function in other VAX Languages.
[IOENT

('l~Ol'l]

PROGRAM Setddir (OUTPUTI;

This

chan.e the default .. directory for the process.

pro~raM

calls the RMS procedure $SETODIR to

TYPE
Word __ Inte~er = [WORD] 0 •• 65535;
VAR

Di r __ Stat·us·., INTEGER;

FUNCTI ON S.YS$SETOD I R (
New_O! r
,[CLASS_S]· PACKED ARRAY [1. •• u: INTEGER] ,OF CHAR.;
Old_D!r_Len :WDrLIn.te~.r,= '%IMMED Or.
Old_Dir
, VARYING [lim2] OF CHAR ,= %IMMED 01
INTEGER; EXTERN;
5EGIN

Main

pro~r.m

Oi r_Status ,= SYS$SETODIR (. [COURSE.PROG. PAS]' I;
IF NOT ODD (Dir_Status)
THEN
WRITELN (·trror in SYS$SETDDIR call. '1;

Figur~ 3~ 11 • Sample VAX PASCAL Program Listing

3-52 • VAX Programming Languages

. VAXPLII
VAX PUI is an extended implementation of the General Purpose Subset
(20.74-1981, "Subset G") of ANSI PLII, 20.53-1976. PLII was designed to be
useful in scientific, commercial, and system programming, especially on small
and medium-sized computer systems. The goals of the design of Subset G were
to include features that are easy to learn, easily portable from one computer
system to another, and to exclude seldom used features that increase runtime
complexity.

Features of VAX PLII
VAX PLII provides:
• The VAX PLII compiletime preprocessor allows language extension and conditional compilation.
• Control constructs, including DO loops, IF-THEN ELSE, BEGIN-END,
LEAVE, SELECT-WREN-OTHERWISE, and CALL statements add power to
program controL

• Full PLII features include AUIDMKITC initializations, AREA (user allocation),
OFFSET, scalar assignment to arrays, the REFER structure, the ENTRY statement, and the LIKE attribute.
• A full complement of VAX data types.
• Block structuring of code reduces the cost of program development and
support.
• Access to the Common Data Dictionary.

• Full Support for the VAX Symbolic Debugger and Language-Sensitive Editor.

Who Uses VAX PLII
• The general-purpose market - has a wide range of features that appeal to a
general audience.
• Commercial applications writers - because of its data manipulation and
structuring capabilities; an alternative to COBOL.
• Educational market - frequendy taught at the university level.
• Implementation language - for commercial and scientific applications.
• System programming - current standards enforce portability.

VAX extensions to Subset G provide additional language features that allows
you to take advantage of the facilities of the VAXNMS operating system and its
components.

3-53

Extensions provided in the VAX PLII language include selected features of the
full PLII language that were excluded from subset because of their implementation cost on computers with restricted memory and/or address space.
You can either restrict their programs to Subset G - compatibility with other
implementations of the Subset G - or they can take advantage of the full PLII
features and VAX extensions in programming applications.

Applications

DATA PROCESSING - Data processing applications can take advantage of the
extensive character handling functions and data structuring capabilities of the
PLII language. By declaring variables within a structure, the program can easily
refer to entire records or to fields within records by referencing the name of the
structure or the name of a variable within it.
In addition, the VAX PLII language provides extended access to the features of
VAX Record Management Services (RMS). By specification of ENVIRONMENT
options or special options supplied for input!output statements, PLII programs
can dynamically specify RMS optimization parameters and values, spool a file to
a printer or batch job queue, and set or change the protection on a file.
The VAX PLII language supports all RMS (Record Management Services) file
organizations, including sequential, relative, and indexed sequential. It also permits block-mode input/output operations. Using PLII statements, a program
can read, write, delete, and update records. Using built-in file handling functions provided by the VAX PLII language, a program can call RMS file handling
services to forward space or backward space a file or volume, to increase the
allocation of a disk file, or to obtain information about the properties of a file.
VAX PLII also supports the VAX Common Data Dictionary, allowing record
descriptions to be stored in and retrieved from the CDD.

SCIENTIFIC - Scientific applications can use the PLlIarray-handling capabilities to define arrays ofup to eight dimensions. Common arithmetic and trigonometric functions are defined within the language. The VAX PUI language
supports all of the VAX hardware's floating-point data types.

SYSTEM PROGRAMMING - System programming applications can use PLII
language features to allocate storage dynamically, process linked lists and
queues, and perform a wide range of bit string functions and operations.
In addition, VAX extensions to the language provide a simple means to refer to
VMS system global symbols and data structures. VAX PL/I programs can take
advantage of the VAX linker's allocation of storage by defining variables either as
read-only or as global symbols.

3-54 • VAX Programming Languages

Full access to all of the VAXlVMS operating system's services and procedures is
possible through VAX PLII extensions to support the VAX Calling Standard.
Procedures written in the PLiIlanguage can call and be called by procedures
written in any other native mode language.

Error and Condition Handling
VAX PLII compiler generates information in the object module of a PLII procedure, so that when an error occurs at run time, the VAX condition handling
facility can report the error and provide a module traceback.
Within thePLII language, extensive condition handling capabilities are availablevia the ON statement, which allows a program to define the action to take in
the event of hardware arithmetic exceptions and errors that occur during @e
processing.
VAX extensions to the ON statement permit the specification of condition handlers for any specific hardware or software condition that can occur.

Debugging Facilities
The PLII compiler generates useful diagnostics that signal syntactical errors and
language violations. Most compiler messages are two or three lines long and
explain on how to correct the indicated error.
The VAX Symbolic Debugger supports symbolic, source line debugging ofPLII
programs. You can set breakpoints in PLII programs, examine and change variables, examine program source code, and monitor the calls and function references that occur.

Libraries
The VAX PLII language is fully compatible with the VAXRuntime Library and
provides additional runtime procedures for language support.
Source @e library support is provided by the %INCLUDE statement, which
allows a program, specified at compile time, an external @e from which source
statements are to be read. Included @es can also be collected in VMS text @e
libraries. The VAX PLII compiler searches specified libraries for the names of
the modules included.

Perfonnance
The VAX PLII compiler is a sharable, VMS image that can be run on any
supported VAXNMS configuration. It produces optimized, sharable, VMS
object code that is runtime compatible with other VAX languages_
You control the degree of optimization performed by the compiler at compile
time, by qualifiers on the PLII command. '
The VAX PL/I Runtime Library is a sharable image, allowing for efficient linking
of PLII programs and better utilization of system resources.

3-55
~gramming Example
lbe following program example obtains data about state flowers from a data
ile, STATEDATA.DAT and makes use of an INCLUDE @e, ST~.TXT. The
lotes keyed to the sample program appear in the figure bdow.
1* METRIC CONVERSION PROGRAM *1
CONVERT, PROCEDURE;
DECLARE (INVALUE,DUTVALUE) FIXED DECIMAL (10,2)
,
(INUNIT;DUTUNIT) CHARACTER(2);
'DECLARE UNITS (6,Z') CHARACTER (2) STATIC INTERNAL «1»,

INITIAL ( 'in','CM','cM','in','ft','",
'ft' ,'Mi '",'kill' ,'khl' ,Mi'
DECLARt:: FACTORS (6) FIXED DECIttAL, (10,2) STATIC «2»
INITIAL (2,54,0,39,0,30,3,28,1,61,0.62);
DECLARE INDEX FIXED 81NARY;
"ON ENDPACE (SYSPRINT);
INDEX = 1;
DD WHILE (INDEX
-=0);
PUT SKIP LIST ('Enter conversion Mode,');
PUT SKIP;
PUT SKIP LIST
( '1 - inches ,to ·ce.n,:ti,Meters ');
('2 - c.e'ntiflleters to.·~rich·es/)-;
PUT SKIP LIST
(,'3 " fee·t :t.o" "Mete"r.s· I,}.;
PUT SKIP LIST
('4 - Meters to feet');
PUT SKIP LIST
('5 - Miles to kilOMeters');
PUT SKIP LIST
PUT SKIP LIST
('6 - kilOMeters 1.'0' !IIi"les');
('0 - .)(i t ');
PUT SK IP LIST
PUT SKIP;
PUT SKIP LIST ('Mode 3
~);
GET LIST <INDEX) ;«3>'>
IF INDEX'=
THEN DO;
IF· (I.NDEX· > O).& INDEX (, 7)·,THEN·DO; <'(4»
PUT'SKIP'LIST' ('Enter value to convert,
);
iOEJ LIST ..HNVALUEH.'
OUTVALUE·',INVALUE, * FACTORS( INDEX); «5»
INUNIT = UIlIITS<II\IDEK.l H
OUTUNIT = UNITS (INDEX ,2);
PUT SKI,P LIST ·(INVALUE., INUNIT.
,
, = ' OUTVALUE, OUTUNIT) «6»
END;
ELSE PUT SKIP LIST( 'Invalid code - retry'H
END;
RETURN;
END;

«1»

Unit ·sto·res l.he -abbr-eviatian- for the Measurement un4-t.

«2»

Factors stores t~e con~er5iDn factor ,that will be u~ed to convert
frOM each specified unit to the desired unit.

«3}}

Read in the conversion code.

«4}}

Ch'eck

io 's'ee \~~at. -8 valUe ,code was, ~pecj.f'ie"~~

«5}} PerforM i~e , c~nv~ii~~ri4
f, •
.'
~;

«6» Print out"U'. reslilt's.

Figure 3-12 • A sample PUI Program Listing

3-56 .' VAX Pmgramming Languages
Ii

VAXRPGll
RPG (ReportPrograin Generator) isa powerful, business-oriented language
specifically oriented tOward generating a, wide variety of simple and complex
business reports. RPG is.a' pa.rtially nonprocedural language, and is therefore '
not sllited to all business, applications. However;' ~here It's appropriate, RPG
can significandyincrease your productivity and greadr improve tum-around
timefor generation and file maintenance application development cycles.
RPG II is an enhanced version of RPG, which was devdoped by International
Business Machines Corporation in the early 196Os: RPG IIincorporates a wide
variety of additional features not present in the originalRPG, and provides atra
advantages in simplicity, ease-of-use, and power. RPGU has become a popular
andwiddy used business application language. It is the primary language for
many small business users.
'
The VAX implementation ofRPG II has been extended and enhanced to operate
within the context of the VAX architecture, and to take advantage of the special
features and capabilities of that architecture.

Features of VAX RPG
VAX RPG II provides: '

• Support of industry standard RF(; II specifications '
• CALL extensions on thetalculation specification
• VAX RPG II editor is tailored to the language structure
• , Integration into tht;VAXCommon Language Environment Including:
~ Use of RMS,for file processing (includingc,sequential,rdative,indexed
.(single and multikey) files)
-

Full integration with the VAX DEBUGGER

• 'Automatic record matching and merging operations for multifile processing
• Multilevd control break handling
• Record identification codes
~ Tableand array processing

• Fidd editing features
• Compile and runtime perforinand: coniparable to VAX COBOL
• Can call other languages that conform to the VAX calling starldard

3-57

Who Uses VAX RPG ll?
Users of VAX RPG II include:
• Software houses for commercial application development
• Newspaper/publishing for generation of mailing labels
• Data processing departments in large organizations for report generation
• Small businesses for multipurpose computing
. • Health care industry for administrative purposes

VAX RPG II runs under the VMS and MicroVMS operating systems. A compiler
and editor are integral parts of the RPG II package. VAX RPG II runtime support
is provided with the base operating system. Therefore, VAX RPG II programs
can run on any VMS or MicroVMS operating system.
The VAX RPG II compiler, using an RPG II source program as input, produces
an object module. That module is input to the VAX Linker, which produces an
executable image. The VAX RPG II compiler optionally produces these development and debugging aids:
• Source listing with embedded diagnostics indicating the line and column of
any source code error
• Machine language code listings
• Cross-reference listing
Language Characteristics and Functions

RPG II is a language processor that accepts and interprets seven different types
of fixed-format specifications. RPG II is a partially nonprocedural language; all
specification types, except calculation specifications, describe data to be
processed rather than processing steps. For this reason, RPG II is best suited to
handle applications that require relatively simple field processing. RPG II also
provides a comprehensive set of sophisticated functions best utilized for these
straight-forward applications.
The general rule for determining whether RPG II should be considered as the
development language for an application is quite simple: the less complicated
the field handling required in the application, the more suitable RPG II is for
that application. RPG II greatly enhances your productivity in such cases.

RPG II is .easy to learn and use because little program logic is required. A single
source statement completely defines a file's structure; .similarly, input and output statements require only a few lines of code. Output records are always made
up of previously defined or edited fields or constants; you need only specify the
desired field name in the output specification, and RPG II performs all necessary
field transfer automatically.

3-58 • VAX Programming Languages

A VAX RPG II program is composed of a set of user-defined specifications of
input data, output formats, and necessary calculation steps. You can define
seven types of specifications; eath is listed and briefly described bdow.
• Control specification - Defines control information .such as collating
sequence, forms positioning· information, decimal separator character and
currency character.
• File specification - Identifies data file parameters including file name, record
size, file organization, and access mode. VAX RPG II supports sequential,
direct, and indexed file organization through the VAX Record Management
Services (RMS). VAX RPG II enhances the flexibility of standard RPG II by not
requiring a primary file in every program. Using RMS, VAX RPG II provides
file sharing with automatic record locking for relative and indexed files.
• Extension specification - Provides descriptions of tables, arrays,and record
address files.
• Line counter specification - Specifies the number of available print lines for
printer output files, thus defining page size.
• Input specification - Identifies record types and other control information
rdevant to input data files; specifies field location, fidd names, data formats,
and control-Ievd information for individual data fidds in an input file. VAX
RPG II supporrs data files with these formats:
Alphanumeric
Overpunched numeric
Packed decimal numeric
Wlrd-binary numeric
Longword-binary numeric
• Calculation specification - Destribes the specific calculation operations to
be performed on the data, and specifies the order in which they are to be
performed. Calculation specifications provide RPG II with its only truly pro'
cedural component. VAX RPG II supports almost all standard RPG IIoperation codes, and also provides several other operation codes for calling
routines written in other langaages, for obtaining the services provided by a
the Run-Tnne Library, and for invoking VMS system services.

• Output specification- Describes the formats of output files and printed
reports, including fidds, output fiddediring operation; forms spacing, and
constant information (such as report titles and headings). VAX RPG II extends
services normally provided by RPG IIwith the ddete option, which allows a
program to ddete records from direct and indexed ·files.

3-59

The VAX RPG II Editor
The VAX RPG II Editor is a full-screen, keypad editor specifically tailored to the
development and maintenance of RPG II code. The following features of the
editor make it a particularly valuable tool.
• Overstrike mode keeps entries in their proper columns; this is important feature because RPG II is position oriented
• A ruler displayed along the top of the editing area helps you locate and keep
track of column positions and field locations
• The editor automatically sets tabs according to the type of specification being
edited
• Extensive on-line help is provided
The VAX RPG II Editor's help facility is a particularly valuable productivity tool.
The editor supports a dual-window layout in which the edited code appears on
the lower half of the screen, and various types of help information appear on the
top half. Help information may consist of:
• A keypad diagram, showing the location of editing functions keys
• Help information for a particular editing key or editing function
• Column headings for the particular RPG II specification being edited - these
will be changed automatically when you begin to create or edit a different
type of specification. You invoke any of the help functions by simply pressing
the HELP key.
Other productivity features provided by the VAX RPG II Editor include
st1"iqg-searching capabilities.
• The VAX RPG II editor also provides the COMPILE command that allows you
to compile programs being edited and to review and correct compilation
errors without ever leaving the editing environment.

3-60 • VAX Programming Languages
IP

FIN
FoUT
E
liN
I
C
C
C
C
C
C
C
C
C
C
C
88
oDUT

F
F

12BO
BO
DATA

TAPE
DISK
16 80

TAPE

11280 DATA2
EXTRN'LIB$TRA_EBC_ASC'
CALL TRANS
PARMD
DATA2
PARMD
DATA2
MoVEADATA2
DATA
Z-ADDI
I
20
TAG
EXCPT
ADD
COMP 16
8888
GDTD LOOP

TRANS

LOOP

DATA .J

OOBO

Figure 3-13 • Typical RPG II Program Showing a CALL Statement
FRPGVEN
FMAILER
FMAILER
IRPGVEN
I

I
OMAIlER
0
0
0
0
0
0

275
F
50
F
IBFL IBol
01

LPRINTER
4 53 NAME
104 143 STREET
144 165 CITY
174 175 STATE
176 1800ZIP

01
NAME

o 1
o I

01
STREET

CITY
STATE

22
24
31

01
ZIP

Figure 3-14 • A TypicalRPGII Program Used to Generate Mailing Labels

Chapter 4 • VMS Services

• Chapter Overview
The VMS operating system provides you with a number of important services,
each of which has a unique role in streamlining the program development
effort. VMS services are: the Digital Command Language (OCL), VAX Record
Management System (RMS), the VAX Runtime Library (RTL), and VMS System
Services.
The command language (OCL) provides a consistent interface with which you
can access the VMS operating system. Many options exist to provide detailed
levels of control where needed. VAX RMS, the RTL, and VMS System Service
facilities help reduce application design time by taking many of the specific data
management, peripheral interfacing, and networking elements out of the application program. These four VMS Services are covered in this chapter.
Topics include:
• The Digital Command Language (OCL)

• VAX Record Management Services (RMS)
• The VMS Runtime Library (RTL)
• The VMS System Services

4-2 • VMS Services

This chapter introduces you to VMS Services.
Complementing Ihe operating system are four layers
of services essential for basic system operation and
program development. These are called the VMS
services and include

VMS Record Management Services (RMS)

VMS Runtime Library (RTl)

The Digital Command language (DCl)

System Services

Figure 4-1 • Overview o/Chapter4

4-3

• VMS Record Management Services (RMS)
The VAX RMS facility is the standard Digital software for data management services and provides an interface at the application-program level to record/file
management functions.

RMS is a powerful collection of routines that provide application programmers
with a device-independent method for the extensive storage, retrieval, and
modification of data. Complex file manipulation is easily achieved through RMS
facilities. You may select from several file organizations and file access techniques - each of which is suited to a particular application. These can range
from the simplest sequential search of a sequentially organized file to a sophisticated keyed access of an indexed file based on several alternate key fields. RMS
supports sequential, relative, and multikey indexed-sequential file
organizations.
For information about the use of RMS services in a VAXcluster system, see
Chapter 5, VAXcluster Software, of the VMS System Software Handbook.

Files
A file is a collection of related information whose requirements are established
by the nature of application programs needing the information. A company
might maintain information regarding an employee in one file, and product
information in another.
Each record in a file is subdivided into discrete pieces of information known as
data fields. You define the number, location within the record, and logical interpretation of each. It is necessary,therefore, to embed the relationship of records
andfields into an application program. When a program is written using RMS,
you don not have to be aware of such logical relationships.· Programs either
build records and pass them to RMS for storage in a file or issue requests for
records while RMS performs the necessary operations to retrieve the records
from a file.
The purpose of RMS, then, is to ensure thatevery record written into a file can
subsequently be retrieved and passed to a requesting program as a single logical
unit of data. The structure, or organization, of a file establishes the manner in
which RMS stores and retrieves records. The way a program requests the storage or retrieval of records is known as the access mode. Legal access modes
depend on the file organization.

RMS Provides Three Record-Access Modes
The various methods of rettieving and storing records in a file are called access
modes. A different access mode can be used to process records within the file
each time it is opened. A program can also change access mode during the
processing of a file, by a procedure known as a dynamic access.

4-4 • VMS Services
RMS provides three record· access modes: .
• Sequential
• Random
• Record's file address (RFA)
• SEQUENTIAL ACCESS MODE
S~quential access mode ~an b~ us~ with anyRMS file. Sequential access means
that records are retrieved or written in a particular sequence. The organization
of d,1efile establishes this sequence.
• RANDOM ACCESS MODE
In random access mode, the program, rather than the organization of the file,
establishes the order in which records are processed. Each program request for
access to a record operates· independently of the prevIous record accessed.
Associated with each request in random mode is an identification of the particular record of interest. Successive requests in random mode can identify and
access records anywhere in the file.
.
• RECORD'S FILE ADDRESS (RFA) ACCESS MODE
Record's file address (RFA) access mode can be used with any file organization
as long as the file resides on a disk device. This access mode is further limited to
retrieval operations only. Like random access mode, however, RFA access allows
a specific record to be identified for retrieval.

As the name suggests, every record within a file has a unique address. The
actual format of this address depends on the organization of the file. In all
instances, however, only RMS can interpret this format.
.
The most important feature of RFAaccess is that the address (RFA) of any
record remains constant while the record exists in the file. After every successful read or write operation, RMS returns the RFA of the subject record to
the program. The program can then Save this RFA to use again to retrieve the
same record. RFAs can be saved and used at any later time.
• DYNAMIC ACCESS
DynamiC access is riot strictly an access mode. Rather, it is the capability to
switch from one access mode to another while pro~essing a file. The only limitation is that the file organization must support the access mode selected.

4-5

As an example, dynamic access can be used effectively immediately following a random or RFA access mode operation. When a program accesses a
record in one of these modes, RMS establishes a new current position in the
file. Programs can then switch to sequential access mode. By using the randomly accessed record (rather than the beginning of the file) as the starting
point, programs can retrieve succeeding records in the sequence established
by the file's organization.

RMS File Attributes
The most important attribute of any RMS file is its organization. A file for use in
a particular application can be tailored by making the proper selection of this
and other attributes. RMS file organization is sequential, relative, or indexed. In
addition to file organization, you can choose from among the following
attributes:
• Storage medium where the file resides
• File name and protection specification of the file
• Format of records
• Size of a particular storage structure, known as the bucket, within relative and
indexed files
• Definition of keys for ind~ed files

• SIDRAGE MEDIA
Selection ofa storage medium on which'RMS builds a file-is related tathe organ"
ization for the file_ ~rmanentSequential files can be created on disk devices or
ANSI magnetic tape volumes_ 'fransient files can be written on devices such as
lineprinters and terminals. Unlike sequential files, relative and indexed files can
reside only on disk devices.
• FILE SPECIFICATION
'The, ~e assigned to a neW file enables RMS to' futd the file on the storage
medium. RMS allows a protection specification to b~ assigned to a file at the
time it is created.
'
When a file is created, you must provide the.format and maximum size specification for the records the file will contain. The specified format establishes how
each record appears physically in the file on a storage medium. The size specification allows RMSto verify that records WJ;itten into the flledo not exceed the
length specified,when
file was <:teated. '
,- ,
--

the

4-6 • VMS Services

• RMS RECORD FORMATS
RMS fonnats include:
• FiXed
• Variable:with-fix<:<i-control (VFC)
• Stream

Program Operations on RMS Files
After a file has been created, a program can access the file and store and retrieve
~m.

When a program accesses the file as a logical structure (for example, a sequential, relative; or indexed file}, it uses record 110 operations such as add, update,
read and delete record. The organization of the file detennines the types of
record operations pennitted.
IT the record accessing capabilities of RMS are not used, programs can access
the file as an array of virtual blocks. To proCess a file at this level, programs use a
type of access known as block 110.
• FILE PROCESSING
At the file level, before beginning record processing, a program can:
• Create a file
• Open an existing file
• Modify file attributes
• Extend a file
• Close a file
• Delete a file
Once a program has opened a file for the first time, it has access to the {uuque
internal ID for the file. IT the program intends to operi the file subsequendy, it
can use that internal ID to open the file and avoid any directory search. .

• FILE ORGANIZATION AND SHARING
With the exception of magnetic tape files, which cannot be shared, every RMS
file can he shared by any number of programS that are reading,but not writing,
the file. Sequential files ()n disk can be accesSed by a single writer or shared by
multiple readers. Relative and indexed files, however, can be shared bymultiple
readers and multiple writers. A program can read or write records in a relative
or indexed file while other programs are similarly reading or writing records in
the file. Thus, the information in such files can be changing while programs are
accessing them.

4-7

• PROGRAM SHARING
A file's organization establishes whether it can be shared for reading with a single writer or for multiple readers and writers. A program specifies whether such
sharing actually occurs at runtime. You control the sharing of a file through
information the program provides RMS when it opens the file. First, a program
must declare what operations (that is, read, write, delete, update) it intends to
perform on the file. Second, a program must specify whether other programs
can read the file or both read and write the file concurrently with the first
program.
The combination of these two types of information allows RMS to determine if
more than one program can access a file at the same time. Whenever a program's sharing information is compatible with the corresponding information
another program provides, both programs can access the file concurrently.

• RECORD LOCKING
RMS can lock records to control operations to a relative or indexed file that
more than one record stream within a process, or more than one process, can
access simultaneously. The purpose of this facility is to ensure that a program
can add, delete, or modify a record in a file without another program simultaneously accessing the same record.
When a program opens an indexed or relative file with the declared intention of
writing or updating records, RMS locks any record accessed by the program.
This locking prevents another program from accessing that record until the
program releases it. The lock remains in effect until the program accesses
another record. RMS then unlocks the first record and locks the second. The
first record is then available for access by another concurrently executing
program.
A program can also select a manual unlocking mode, in which all records
accessed by the program remain locked until they are explicitly unlocked by
calls to RMS. Additionally, a program may request that no record locking be
done.

4-8 • VMS Services

~RECORD 110 PROCESSING
The organiz-ation ofa file, defined when the file is created, determines the types
of operations that the program can perform on records; Depending on file
organization; Record Management SelVices permits a program to'pertotm the
following record operations:

• Get a reCord-RMs returns an existing reCo~dWithin the file to the program
• Put a record - RMS adds a new record that the program constructs to the
file. The new record cannot replace an already existing record
~ Find a record -

RMS locates an existing record in the file. It does not return
the record to the program, but establishes a new current position in the file

• Ddete a record - RMS removes an existing reCord from the file. The ddete
record operation is not valid for sequential file organiZationS .
• Update a record - The program modifies the contents of a record read from
, the file. RMS writes the modified recordinto the file, replacing the old record.
The update record operation is generally not valid for sequential file organizations, except for precise reP,lace~~t,of records in those with fixed-length
records.

RMS Utilities
The RMS procedures are complimented by a File Definition Language (FDL)
and a number of utilities designed especially for RMS file creation and maintenance. They are called directly through DCL, and. include:
• CONVERT
• CONVERTIRECLAIM

• EDITIFDL

• CREATFJFDL
• ANALl'ZIYRMSJILE

The File Definition Language is a special purpose language used to describe file
organizations for data files. These specifications are then used by the RMS utilities and library routines to create data files and other data structures.

4-9

UsingRMS
RMS is a powerful tool for handling input/output tasks. Whether you simply
need to have a program read input lines from a terminal, or need full writesharing capability with record locking - allowing multiple processes to access
and update records in the same files simultaneously - RMS can simplify and
handle the task. Of course, more complex operations may require a number of
parameters and allow specification of many more; neverthdess, all of the basic
RMS services use one of two control structures as input for their operation. The
File Access Block (FAB) contains only fidds rdeVsnt to file operations, such as
the creation of a new file or opening an existing one. The Record Access Block
(RAB) contains parameters necessary to perform record operations, such as
record retrieval and update, on records within a file. The following table illustrates this division.

Thble 4·1 • Comparison of RAB and FAB Parameters For Record
Operations
Category

MactoName

Service

File Processing
(FAB=address)

. $CREATE

Creates and opens Ii new file

$OPEN

Opens an existing file and initiates
file processing

$CWSE

Terminates file processing and
closes the file
...

$CONNECT

Associates and connects. Ii RAB to
the file .

$GET

Retrieves a record from a file

Record Processing
(RAB = address)

$PUT

Writes a new record to a file

$UPDATE

Rewrites an existing record in
a: file
.

4-10. VMS Services

The brief<program listing that follows, with comments, demonstrates the
ease and 'simplicity of using RMS to achieve an liD ~peration. Several different
runs of the program. follow. It reads a sequential file containing ASCn text
.and uses a Runtime Library routine to print the text on yoUr terminal.
1 Buffer .blkb
2 Buff~deSc,

100

;allocate a JOO byt? buffe~

3
4
5
6 My._fab.
7
8 My_rab.
9
10
11
12 Start:
13
14
15
.18
17 ".
18

.lons

·9
Buffer

;addr ••• of buffer

'fAll

FMN=<!IIIf"ILE>

;File ~ac.cess bTock

SRAB

FAIl=My_fab,"
UIlF=Buffe r ,USZ=100

;Record access· blocK

,word

$OPEN
IlLBC

FAB,,'My_fab
RO ,C·lo.e fi Ie

;open the 1i 1e
;exit· on . eP"rOf

SCONNECT
BLIlC

RAIl=.MY _ rab

;CDnne~t

R9'Exi~

ieJl~~

;!tet the fi r$t re-·cord
;exit on errOf

;d~~crtptnr fer buffer
ile,nsth. will b:e set, at. runtiMe

for "record operations

on errDf.

19
20 Get..::.record:
21
"GET

22
23

BLBC

RAB=MY':rab
RO,Exit

MO..,W

MY~rab"+

PUSHAIl

28
27

CALLS
IlRB

rabSw_fsZ,Buff_desc
;store lensth .of record in
desc

..'" Butf_de,sc

;push de-script.or address for

output.

-1,C'LIBSPUT_OUTpUT ;print the record
'Get_ reco rd

recQ rd
28 EXIT.
29
30
31
32
33

;and close the

'CLOSE

fil~'

RET
Start

.end

Figure4-2 • ASample Program Using RMS

4-11

• The Digital Command Language (DCL)
A single command language, the Digital Command Language (OCL), provides
you, as a user of a VAX!VMS system, with an extensive set of commands for:
• Interactive program development_
• Device and data file manipulation.
• Interactive and batch program execution and control
• Operational control.
Commands exist for program development and execution, for resource allocation, environmental control, job control, file maintenance, utilities, and operational control.
• Program development and execution commands include commands to
invoke each.compiler, the assembler, the editor, and the linker, as.wellas to
run any prelinked program.
..
• Resource allocation commands include the ability to allocate and deallocate
devices and mount and dismount volumes_
• Environmental commands include assign and deassign logical names and set
and show parameters such as job status, terminal type, and default directory.
,. Job control commands include the ability to continue and stop execution, a
GOlOcommand to transfer control, and IF and ON commands to specify
error handling.
DeL also includes co~ands to login and logout, to~ubmit batch jobs, to send

messages to the operator, a.nd to prompt you for input. File maintenance com'rr).ahds inclUde appe11dtofiles, copy, create, and delete files, list directories, miiiaIize volumes, print and type files, and rename files.
Topics ,coyered in this section include:
• :Command procedures

• Tetnllnal furict1o~ keys"
. Command Format
OCL cOmnlands ate composed of English )Vords. AriYfi.l~nanle can,be givena
logical name for mnemonic reference.. COmnland p~etetS can ,De supplied
on the same line asthe connmmd v~rb. Missfugparanieters willheprompted.
forby the VMSromrhaD.dfuteIpreter: Tomakeiteasiet to learn theVMSsyst~,
'an extensiVe HElP facility giVes guidance on the\lse 'ofcomrnlUidsafidthe
meaning of system messages.
n"
. .

4-12 • VMS Services

Typical VMS commands a~ brief,because of the <;xtensive uSe. of defaults. You
also can define additional conimands and use them just as the system-defined
commands are used.;Aill command verbs and qualifiers can be abbreViated to
' .'
the shortest unique form.
File specifications can be as simple as the user-given name of the file, only, or as
complex as a full specification of network node, device (including type, controller, and unit), directory; file name, file type, and version n~ber: Logi~ar nam~s
can be defined for complex file specifications so that repetitive ijpingcan be
avoided.

Command Procedures

A ~otrlliland'procedufe is a fileiliat contains a list ofDcL conimaiJ.ds. When
you execUt~ a' cOlnmand procedure, the DCLcommand interpreter reads the
file. and executes the commands in it.
'.
.'

ConimaiJ.d procedun:s can he used 'to automate a sequence of commands that
. y<itl. usefrequendy. Foiexample,' if you always issue a DIREClORY command
after you move to a subdirectory, you can write a sirUple command procedure to
issue the SET DEFAULT and DIRECIORY commands for you as illustrated in
the following example.
$ SET DEFAULT [SMITHiACCOUNTSl
$ DIRECTORY·

Instead of issuing each'command, you could greildy simplify the operation and
reduce the number of keystrokes by using a command procedure (named
GO~IR.COM) that would be executed when you type:
$ @GO_DIR

Thiscornmarid' tells the .DeL 'co~rri~rid interpreter' to reael the file
GO,..DIRCOM and to execute the rorriIbands in the file. Therefore, the command interpl-etet setS your default diktoryto[SMITII.ACCOUNTS] and issues
the directory command.
. .
.
'. . '
" .
You can write complex command procedures that re~ble pto~~ written
in high-level programming languages. In this sense, a command procedure proVides "i method of Writing programs in the Digital Coimruind L~\lag':r'. :.
You can, for example, revise GO~IR.COM to alloW you to move to an,y dir~
tory and obtain a list of the files in the directory and obUrlna list of the fifes in
the directory:
$.INQ!JlRE DIR_N:I;\ME "Oirec:tp.ry
$SETD~F~UL, T~DliLNAME i . "

naMjl:.

$' DIREC'rORY'OIR_NAME'

When you: e:xeCll:te GO~IR.COM, the INQl!1Rl:3 ~llUI).and prompts for a
.directory name, the SET DEFAULTcommand movesygu to the directory"and
die DrREC10RY command lists the file names.'
"

4-13

• FORMATTING COMMAND PROCEDURES
Use a text editor (or the OCL command CREATE) to create and format a command procedure. When you name the command procedure, use the default file
type COM. IT you use this default file type, y~u do not have to include a file type
when you execute the procedure with the "@" command.
Command procedures contain OCL commands that you want the DCL command interpreter to execute and data lines that are used by these commands.
Commands must begin with a dollar sign ($). You can start the command string
immediately after the dollar sign, or you can place one or more spaces or tabs
before the command sting to make it easier to read.
Data lines, unlike commands, do not begin with a dollar sign. Data lines are
used as input data for commands (or images.) Data lines are used by the most
recently issued command; these lines are 'not processed by the DCL interpreter.
.The following example illustrates CQmmand lines in a command procedure.
$ MAIL
SEND
THOMAS
MY MEMO

Do YOU have a few Minutes to talK about the ideas
I presented in MY MeMO?
$

SHOW USERS THOMAS

In the preceding example, the first line is a command and must start with a
dollar sign. The next lines are data lines that are ~ by the MAIL utility; these
lines must not start with a dollar sign; Note that data lines must correspond to
the way the image (invoked by thecolI1lIllli1d) expects the data. Therefore, the
data lines provide a MAIL cominand(SEND), a recipient (maMAS), a subject
(MY MEMO) and the text of of the mail message. When the command interpreter finds a new line that begins with a dollar sign, the MAIL utility is
terminated.
.

For more information on the Digital Command Language, see Chapter 2 of the

VMs System Software Handbook.

• The VMS Runtime Library.
The VMS Runtime Library is a set of language-independent procedures that
establish a common runtime environment for application programs written in
any VAX language in the Common Language Environment. Because the R1L
adheres to the VAX calling standard, procedures can be called from programs
written in VAX languages that also follow the calling standard. Therefore, application programs can be composed of modules written in many different languages, including the VAX assembly language.

4-14 • VMS Services

Features of the Runtime Library
The VMS RTL provides the following features and capabilities.
• RTL procedures perform a Wide range of general-utility operations; you can
call an RTL procedure instead of writing code to perform the same operation.
• The results of a particular procedure are the same, no matter what language
calls it.
• RTL procedures use VMS Record Management Services for file 1/0.
• Library procedures can be updated Without revising programs that call its
shared modules.

Organization of the Runtime Library
The VMS Runtime Library contains several facilities. These facilities are groups
of procedures that perform related operations. The VMS library facilities are
listed in Table 4-2.

Thble 4·2 • VMS Runtime Library Facilities
Facility

Description

LIB$
MTH$
SMG$
STR$
OTS$
BAS$
COB$
FOR$
PAS$
PLI$
RPG$

General purpose procedures
Mathematics procedures
Screen management procedures
String manipulation procedures
Language-independent support procedures
BASIC-specific support procedures
COBOL-specific support procedures
FORTRAN-specific support procedures
Pascal-specific support procedures
PLII-specific support procedures
RPG-specific support procedures

These facilities are divided into general-purpose and language-support facili·
ties. General-purpose procedures are intended to be called explicitly to perform common procedures, while language-support procedures are intended to
be called implicitly by language compilers and compiled code. Language-support procedures are further divided into language-specific and language-independent support procedures.

4-15

General Purpose

Language-Specific Support
Procedures
• Compiled code support
• File processing
• Format processing

Language-Independent
Support Procedures

(Common to more than one
native-mode language)

OTS$

• Error processing
• 1/0 processi ng

BAS$
COB$
FOR$
PU$
Language Support

Figure 4-3 • General-Purpose and Language-Support RTL Procedures

Functional Listing of VMS RTL Procedures
These facilities can be categorized by function as listed in Table 4-3.

Thble 4·3 • Functional Grouping of VMS RTL Facilities
Function

RTL Facility

General Utility Procedures

LIB$
S1R$
OTS$

Mathematical Procedures

MTH$
OTS$

Process-wide Resource
Allocation Procedures

LIB$
S1R$
OTS$

Signaling and Condition
Handling Procedures

LIB$

Special Application Procedures

LIB$

4"16 • VMS Services

GENERAL PURPOSE PROCEDURES - In most cases, application programs
call these procedures using explicit CALL statements or function references.

GENERAL UTIUIY (UB$) - General utility procedures provide a wide range
of functions for your convenience.
• Common vo procedures - These procedures perform such functions as
getting records from the current input device (Lffi$GETJNPUT) and sending
them to the output device (Lffi$PULOUTPUT), executing DCL commands
from a running program (LIB$SPAWN), getting the command line from a foreign command (Lffi$GELFOREIGN), and copying strings to and from the
process's common storage area
(LIB$PUT_COMMON,
Lffi$GET_COMMON). VO control procedures are also available to customize
printer output and translate logical names.
• Terminal independent screen procedures - These procedures provide a
high-level language interface to the video terminal. They send text to the
screen, move the cursor to the desired position, erase text from the screen,
and manipulate the screen buffer.
• Data type conversion procedures - These procedures perform conversions
between one VAX data type and another (for example, text to D-floating and
decimal to binary).
• Variable bit field instruction procedures - LIB$INSV inserts and extend variable bit fields. Lffi$FFS searches a bit field for the first set bit.
• Ferformance measurement procedures - These procedures provide a facility
for timing, counting Vo operations, and counting page faults.
• Date/time utility procedures - These procedures return the system date or
time in several forms.
• CRC procedures - Lffi$CRC and Lffi$CRC_TABLE permit you to calculate
the cyclic or redundancy check for a data stream
• Multiple precision arithmetic procedures - Lffi$ADDX and Lffi$SUBX add
and subtract signed two's-complement integers of arbitraty length.
Runtime Library procedures also permit the high-level language programs to
use the following VAX hardware instructions:
• Extended multiply and modulus arithmetic - EMUL, EDIV, EMOD
• Evaluate polynomials - POLYF, POLYD, POLYG, POLYH
• Insert and remove queue entry - INSQHI, INSQTI, REMQHI, REMQTI

4-17

MATHEMATICAL FUNCTIONS (MTH$) - The mathematical library consists of over 200 standard procedures to perform common mathematical
functions. These functions include:

• Floating-point mathematical functions: trigonometric, logarithmic, and
square root
• Complex functions: absolute values, conjugation, trigonometric, arithmetic,
exponentiation, return imaginary part of complex number, return real part of
complex number, make complex from floating-point, .logarithmic, and
square root.
• Exponentiation on floating-point, word, longword, and complex data
• Randomnumber generator
• Processor-defined mathematical procedures: includes both the intrinsic and
basic external functions defined in ANSI FORTRAN.
They include routines that perform conversions between floating-point and
integer data and a large number of miscellane()us data types
RESOURCE ALLOCATION PROCEDURES (LIB$, STR$, OTS$)- The
Resource Allocation Section includes all procedures that allow allo~ation of
process-wide resources. Such resources include the following:

• VIrtual memory - one procedure to allocate and one to deallocate arbitrarily
sized blocks of process virtual memory
• Logical unit numbers - allow logical numbers to be allocatedin,a modular
manner
• Event flags - same as logical unit numbers

In most cases, the resource allocation procedures should used to allocate process-wide resources in order for all library, DIGITAL, and customer-wrirten pro.
cedures tei work together properly within a process.
SIGNALING AND CONDITION HANDLING 'The VMS condition handling
facility is a collection of library procedures and system services that provides a
unified and standardized mechanism for handling errors internally in the operating system, the Runtime Library, and application programs. In some cases,
the mechanism is also used to communicate errors across these interfaces. In
particular, all error messages are printed using this mechanism. When an error
condition is signaled, the process stack is scanned in reverse order. Establishing
a handler provides you with control over fix-up, reporting, and flow of control
on errors. It provides the system and library messages in order to give a more
suitable application-oriented user interface.

4-18 • VMS Services

LANGUAGE-INDEPENDENT SUPPORT (OTS$) - The language support
libraries support the code generated inline by compilers. As such, most of
the procedures are called implicitly as a consequence of a language con,
struct you specified, rather than being called explicitly with a CALL statement. Those language support procedures that are independent of
higher-level languages use the facility prefix OTS$. They include:
• Language-independ~nt initialization and termination
• Error and exception-condition pro,cessing procedures
• Data type conversion

LANGUAGE-SPECIFIC SUPPORT - Each of the language-specific support
libraries is generally composed of:
• I/O processing procedures
• File processing procedures
• Compiled-code support procedures
• Compatibility procedures
• System procedures

STRING PROCESSING (SIR$) - The string processing procedures allocate
and deallocate dynamic strings. They also perform a wide variety of string
manipulation functions, such as comparing, locating a character, concatenating,
extracting a substring, performing arithmetic operations on decimal strings,
and translating ASCII to EBCDIC code.

SCREEN MANAGEMENT PROCEDURES (SMG$) - The Screen Management facility allows application programs to be coded without regard to physical devices performingI/O. Instead of writing directly to a physical screen, your
program writes to a virtual display. Similarly, user programs perform input from
a virtual keyboard instead of a physical keyboard.
The screen managemt;nt facility provides two important services:terminal independt;nce and composition aids.

4-19

TERMINAL INDEPENDENCE - The screen management procedures provide
terminal independence by allowing commonly needed screen functions to be
performed without concern for the type of terminal being used. All operations
are performed by calling a procedure that converts the caller's terminal-independent request (for example, scroll a part of the screen) into the
appropriate sequence of code needed to perform that action. If the terminal
being used does not support the requested operation in the hardware, the
screen management procedures emulate the action in software.
COMPOSITION AIDS - The screen management procedures simplify the composition of complex images on a terminal screen. For example, if an application
program was directed to solicit your input from one part of the screen, display
results to another, and maintain a status display in another, procedures from the
Screen Management Facility enable code for each of these operations to be
written independently of the other.

SYSTEM PROCEDURES - VAX programs written in the higher-level languages
can call the operating system directly. However, since some languages cannot
easily pass arguments in the form that system services require, and some languages use data types that system services cannot properly handle (that is,
dynamic strings), some LIB$routines have been provided to handle the input
and output arguments correctly.

• VMS System Services
VMS System Services are procedures provided by the VMS operating system.
These procedures
• Control resources available to processes.
• Provide for communication among processes .
• ~rform basic operating system functions (I/O coordination, for example.)

VMS system services are available for general use by logged-in users or can be
called by an application program. For example, the operating system creates
your process with the Create Process system service ($CREPRC) when you log
in. $CREPRC can also be called from an application program to create a subprocess to perform certain functions for that program.

4-20 • VMS Services

System services are divided into 11 functional groups. 1able 4-4 lists each
.
group of services andthegerierid functionofthat group. -

Table 44 ~ The F~ncU~ Gl"()Uping of VMS System Seivices Serviee Gl;Oup

Function

Security

Security systemservicesprovlde varioUs mechanisms to enhance and control system security.'

Event-Flag

Event-flag services clear, set, and read event flags and can
,place a process in await state pending the setting of those

& g s . · -"

Process-execution can be interrupted by events for the
execution of d~ignated subroutines. These software
interrupts are called Asynchronous System 'fraps (ASTs).
AST system services are provided so that aprocess can·
control the handling of these interrupts.
Logical Names

LOgical name Services provide a generalized technique for
maintafuingand accessing Character string logical mime
- and equivalence name p~~ -,'

Input/Output

110 system services bypass VAX Record Management Services (RMS) and perform input and output operations
.
directly at the device driver level.
110 system services include:
* Perform logical, physical, and virtual input/output
operations.'
* Format output lines converting iJinary-numeric values
to Ascn strings and substitute variable; data in Ascn
strings.
* Perform nctwork oIJ~rations. *,Queue messages to system i>roceSses.

Process-Control
Tuner andTune-Conversion

Process-control system services allow you to create,
delete, and control the execution of processes.

'ftmer seivices schedule program eVents for a particular
time of the (4y, or after a specmed intet;Val of time h~
elapsed. Thetime-<:onversion st;rVicesallow you obtain
and forinat binary time values for use With the timer
services.
(continued on next page)

4-21

Table 4-4 • The FUIldional Grouping of VMS System Services (Cont.)
Service Group

Function

ConditionHandling

Condition handlers are procedures that can be designated to receive control when a hardware or software
exception/condition occur. Condition-handling selVices
designate condition handlers for special purposes.

MemoryManagement

Memory-management services give you control over an
application program's virtual address space.
These services:
* Allow an image to increase or decrease the amount of
virtual memory available.
* Control the paging and swapping of virtual memory.
* Create and access files that contain sharable code and
data.
Change-Mode
Change-mode services changes the access mode of a process. These services are used priIruirily by the operating
system.

Lock-

Lock-management services make it possible for
co-operating processes to synchronize their access to
shared resources.

Management

Calling System Services
At runtime, anapplication program calls a system setvice and passes control of
the process to it. Upon execution of the system setvice, the setvices returns control to the program and also returns a condition value. The program then analyzes the condition value, and determines the success of failure of the system
service call, and alters program execution flowas required.

• VMS SYS1EM SERVICES AND SYS1EM INTEGRfIY

Many system mtes are available and suitable for application programs, but
the use of some setvices muSt be restricted to protect the performance of the
system and the integrity of your process.
The creation of permanent mllilbOxes, for example, requires the use of system-dynamicmemory. Therefore, the unrestricted use of permanent mailboxes
could decrease the amount of memory available to other system users. Thus, the
uSe oHhis system setvice is controlled by the assignment of a specific user
privilege.

4-22 • VMS Services

The system manager grants the use of privileges to use these protected system services and controls that privilege through the use of User Authoriza~
tion File (UAP). This file contains a specific list of user privileges and
resource quotas.
When you log in, the privileges and quotas you have been assigned are associated with the process created on your behalf. These privileges and quotas are
applied to every image that the process executes.
A privilege list is checked when an image in your process issues a call to a protected system service. If you have been granted the specific privilege required,
the image is allowed to execute the system service. If not, a condition value
indicating the privilege violation is returned.

VMS Security System Services
The VMS Security System Services provide the system manager or the application programmer with many security-based resources of the VMS operating system. These resources allow you to protect and and fine tune the security of your
computing environment.
These services include facilities to
• Create and maintain a rights database ..
• Create and translate access-control entries.
• Modify a process-rights list.
• Check access protection.
• Provide a security-erase pattern for disks.
• Control access to magnetic tapes.

VMS Event-flag System Services
Event flags are maintained by the VMS operating system for general programming use. Programs can use event flags to perform a variety of signaling functions. The VMS event-flag system services clelJ,l', set and read event flags. They
can also place a process in a wait state pending the setting of an event flag or
flags.
Event flags can also be used by morethan one process as long as the cooperating processes are in the same group. Thus, if you have developed an application
that requires the concurrentex~cution of several processes, you can use event
flags to establish communication among them and to synchronize their activity.

4-23
• EVENT-FLAG NUMBERS AND EVENT-FLAG CLUSTERS
Each event flag has a unique decimal number; event-flag arguments in
system-service calls refer to these numbers. For example, if you specify event
flag 1 in a call to the $QIO system service, then event flag number 1 is set when
the VO completes.
Groups of event flags are manipulated by organizing them into event-flag "clusters." Each "cluster" is made up of 32 flags.
There are two types of "clusters," local event-flag clusters and common
event-flag "clusters."
• Local event-flag "clusters" can only be used internally by a single process.
Local "clusters" are automatically available to each process.
• A common event-flag cluster can be shared cooperating processes in the same
group. Before a process can refer to a common event-flag cluster, it must
explicitly associate with the cluster.
Some system services set event flags to indicate the completion or the occurrence of an event; the calling program can test the flag.
AST (Asynchronous System 1.i-ap) Services
Some system services allow a process to request that it be interrupted when a
particular event occurs. Sine the interrupt occurs asynchronously (out of
sequence) with respect to the process's execution, the interrupt mechanism is
called an asynchronous system trap (AST). The trap provides a transfer of controlto a user-specified procedure that handles the event.
Thesystem services that use the AST mechanism accept the address of an AST
service routine as an argument. That is, the routine to be given control when the
trap occurs.
The following list of services use ASTs.
• Declare AST ($DCLAST)
• Enqueue Lock Request ($ENQ)
• Get Devicel\blume Information ($GETDVI)
• Get JoblProcess Information ($GETJPI)
• Get System-Wide Information ($GETSYI)
• Queue I/O Request ($QIO)
• Set Timer ($SETIMR)
• Set Power Recovery AST ($SETPRA)
• Update Section File on Disk ($UPDSEC)

4-24 • VMS Services
For example, if you call the Set Timer ($SETIMR) service, you can specify the
address of aroutine to be executed when a time interval expires or at a particular time of day. The service schedules the execution of the routine and
returns; the program image continues executing. When the requested time
event occurs, the system "delivers" an AST by interrupting the process and
calling the specified routine.

Logical Name Services
The VMS logical name services provide a technique for manipulating and substituting character string names. Logical names are commonly used to specify
devices or files for input or output operations. You can use logical names to
communicate information between processes by creating. a logical name in a
logical name table that is accessable by another proCess.
The VMS operating system services establish logical names for general application purposes. The system also performs special logical name translation procedures for names associated with I/O services and with services that can deal with
facilities located in shared (multiport) memory.

Input/Output System Services
When writing application programs, there are two basic input/OUtput services
available to the application developer, VAX Record Management Services (RMS)
and VMS I/O system services. VAX RMS provides a set of routines for general
purpose, device-independent functions such as data storage, retrieval, and
modification.
The 1/0 system services permit you to use the I/O resources of the operating
system directly, in a device-dependent manner. 1/0 services also provide some
specialized functions not available in VAX RMS. Using I/O services requires
more knowledge on your part than if you used VAX RMS. However, using these
services result in more efficient input/output operations.
Process-Control Services
When you log into the system, the system creates a process for the execution of
program images. You can create another process to execute an image by issuing
the RUN or SB\WN command using any of the qualifiers that pertain to process
creation. You can also write a program that creates another process to execute a
particular image.

4·25

Process control services allow you to create processes and to control a process or group of processes. They allow you to
• Create subprocesses and detached processes.
• Control the execution of a process.
• Facilitate control and communication between processes.
• Control the hibernation or suspension of a process.
• Control image·exit and exit handlers.
• Control process deletion.

VMS TIDIer and TIDle-Conversion System Services
Many applications require the scheduling of program activities based on clock
time. Under VAX/VMS; an image can schedule events for a specific time of day
or after a specified rime interval.
\OU can use VMS timer services to schedule, convert,.or cancel events. For
~ample, you may use the time services to
... -- Schedule thesetting of an event flag or the queuing of an AST for the current
. process, or cancel a pending request that has not yet been honored.
• Schedule a wake-up request for a hibernating process, or cancel a pending
wake-up request that has not yet been honored.
The timer services requh-e you to specify the time in a 64-bit format. To work
with the time in different formats, you can use time conversion services to

• Obtain the curi'entdate and time in an ASCII string or in system format.
• <:,:onvert an ASCU string into the system-time format.
• Convert a syst~m.time value into an ASCII string.
r

Convert the time from system format into integer values.

VMS Condition"Handiing System Services
A condition handler is a procedure given control by the operating system when
an exception occurs. An exception is an event, detected by the hardware or
software, and that interrupts the execution of an image. Examples of excep·
tions include arithmetic overflow and reselVed opcode or operand faults.

If you det~mine that a program needs to be informed of particular exceptions,
you can write and specify a condition handler. This condition handler, which
receives control when any exception occurs, can test for specific exceptions.

4-26 • VMS Services

VMS Memory-Management SyStemSei'vices
The VAXlVMSmemory.management routines map and control the relationship
between physical memory and a process's virtual address space. These activities
are, for the nwst part,trilnsparent to you as a. user $d to your programs. However, a program can be run more efficiently by allowing it to explicitly control its
use of virtual memory,

VMS Lock'Management System Services
.
The.VMS lock-management sYstem seMces allow cooperating processes-to
synchronize their·access to shared resources. This is accoinplished by providing
a common data area in whiCh processes can lock a specified resource by name.
All processes that access the resources must use the VMS lock -management services to be ~ective.
..
Thelock-management services provide.a queuing mechanism that allows
processes to with in a queue until a particular resource is available.

Chapter 5 • VMS Program Development Utilities

• Chapter Overview
Besides the services discussed in Chapter 4, VMS also provides you with many
powerful program development utilities, such as text editors, debugging facilities, program module linkers and many other sophisticated tools that can be
used in every facet of the program development life cycle. This chapter gives
you a overview of many of our more important program development utilities.
VMS text editors gives you the ability to create high-level source code programs
quickly and efficiently. The DSR text-formatting utility extends basic editor
capabilities into a highly sophisticated text processing system.

Program debugging, high-speed sorting and merging of data, and the linking of
object modules into executable images are a few of the major functions these
utilities perform.
Products covered in this chapter include
;. The vAXlVMs Symbolic Debugger Utility.
• The VMS SORTIMERGE Utility.
• The VMS LINKER Utility_
• The VMS LIBRARIAN Utility.
• Other VMS program development utilities.
• VAXTPU (Text processing utility)

• The EDT text editor
• The DSR Text Formatting Utility

5-2 • VMS Program Development Utilities

This chapter introduces you to the VMS program development utilities. These utilities include· text-editing and
formatting tools, a powerful symbofic debugger, and
many mOre utility programs designed specifically for the
application and systems programmei"

EDT

VMS Program
Development Utilities

VAX/VMS
e\
'YlnbOlic Debugg

Figure 5-1 • Overoiew Of Chapter 5

5-3

• The VAXJVMS Symbolic Debugger
The VAXNMS Symbolic Debugger is a powerful and flexible tool used to find
errors in source code programs_
The VAXNMS Symbolic Debugger
• Is interactive. You can execute Debugger commands from your terminal and
see their effects immediately.
• Is symbolic. You can refer to program locations by the symbols you used for
them in your program.
• Supports many languages. You use the Debugger in the language of your
source program. If your application is written in more than one language, you
can change from one language to another within the course of a debugging
seSSIon.
• Permits a variety of data forms and types for entry and display.
• Allows you to select and display your program's language statements.
• Has a screen mode that provides multiple windows for screen-oriented
debugging.
• Has a debugger-defined keypad key definitions for your terminal's numeric
keypad.
• Gives online help.
• Supports the VAXLanguage-Sensitive Editor

The VAXlVMS Symbolic Debugger Is Interactive
When using the VAXNMS Symbolic Debugger, you run the program to be
debugged interactively, at your terminal under Debugger control. When the
program starts to execute, VAXNMS Symbolic Debugger gains control before
the program and prompts for VAXNMS Symbolic Debugger commands. These
commands are entered to control the execution of your program by interrupting that execution at specific intervals. This momentary pause allows you to
enter more VAXNMS-Symbolic-Debugger commands and to gather additional
information about the current state of your program.

The VAXlVMS Symbolic Debugger Utility Is Symbolic
With the VAXNMS Symbolic Debugger, you can reference program locations
to by symbolic names. For example, if you wish to interrupt the execution of
your program at routine BILL, the SET BREAK BILL command will look up the
address for the symbol BILL and stop when the PC hits that address.
Likewise, EXAMINE X will look up the address of the symbol X and display the
contents of that address. You don't need to know where X or BILL are in memory, the Debugger knows for you.

5-4 • VMS Program Development Utilities

The VAXlVMS Symbolic Debugger Is Multilingual
The Debugger is a multilingual debugger, supporting many VAX languages.
These include:

VAX Ada
VAX BASIC
VAX COBOL
VAX MACRO
VAXPLII

VAX BLISS
VAXC
VAX FORTRAN
VAX PASCAL
VAX RPG II

The VAXlVMS Symbolic Debugger is strictly an object program debugger,
debugging programs at run time, after they have been compiled and linked. It is
used to debug only compiled languages - not interpreted ones.
Being multilingual means that the Debugger understands the following characteristics of each supported language.
• How symbol names are composed in the language. It knows how identifiers
are formed and how compound names are constructed. For example, it
accepts A(2)-B as valid PLII syntax and A[2].B as valid PASCAL syntax.
• How language expressions are interpreted. It knows what operators are
allowed and what their syntax and semantics are.
• How and when type conversions' are done in the language. This is part of
understanding how to interpret expressions and is needed to do assignments
properly.
• How values are displayed in the language. Forexample, how enumeration
type values are displayed in PASCAL and how numeric values are displayed in
COBOL.
• How the language scope rules work. It knows how to look up a symbol name
in a specified scope according to language rules.

5-5

• VMS DEBUGGER FEATURES AND COMMANDS
The VAXlVMS Symbolic Debugger command language defines the capabilities
of this debugger and constitutes the user interface. The following is a brief
synopsis outlining the main features and commands of VAXlVMS Symbolic
Debugger.
• The EXAMINE command retrieves and displays the contents of a specified
program location. The location is typically a variable and the display is
formatted according to the variable's type.
• The DEPOSIT command stores a new value into a specified location, again
usually a variable.
• The EVALUATE command permits expressions in the language to be evaluated and the results displayed;
• The SET WATCH command causes the program to stop when a specified data
location is altered.
• The ST.EI> command stops the program when the next instruction or the next
source line is reached.
.
• USER-INTERFACE FEATURES OF TIIE VMS DEBUGGER UTILI1Y
These features are
• Screen Mode - The debugger uses the full terminal screen for,output. The
screen can be diviQed into multiple windowslwhich can be scrolled up and
down as well as right and left. These windows may £ontainprogram source
code, debugger output, or machine register values •..•
• Keypad Input - With the debugger, you can use the numeric keypad to enter .
commands. The VAXlVMS Symbolic Debugger provIdes a default keypad
layout, hut you candefine your own keypad bindings or alter the default
bindings.'
.
• Improved Support For E~ting Languages - The debugger now understanclsall data types and language specific operators for e,ach language.
• Aggregate Output - The debugger allows whole arrays and records to be
examifled with a.single command.
• .User-defined Commands - The debugget'sDEFINElCOMMANnfeature,
together with improvements to debugger command files.and the VAXlVMS
Symbolic Debugger command language, enable you to define your own
debugger commands.
• Symbol Thble Query,- The debugger's SHOw SYMBOLcommand allOws you
to query the debugger about the symbols in his program.

5-6 • VMS Program Development Utilities

• Improved Symbolization -The debugger's SYMBOLlZEcommand takesJlln,
aMress andtells you what opject is at .that address.
• Improved Breakpoint Facility - The debugger's capabilities for breaking,
tracing, and stepping havebeeri gready expanded.
• SffiWN and ATTACH Commands -, The debugger_supports the ability to
SffiWN a new subproceSs much the same as is done in DeL. Then u~ing the
ATtACH command, you'can'move to any Debugger. subprocess he has'
spawned or jump around between debugging sesS!()fls.
• Expandable MeihorylOOl-Thede})ugger'sALLOCATEcommahd allows
you to allocate more space for the debugger's symbol table so you can set
more (or all) modules,in your program..
'
• Is fully supported by the VAX Language-Sensitive Editor:

• VAX SORTIMERGE
The VAX SORTIMERGE utility may be run interactively, as a batch job, or called
from.a VAX language program.
The SORT utility allows you to reorder data from one to ten input files into a
single output file in a sequence based upon user-specified key' fields within the
input data records. If you does not wish to physically reorder the input,' SORT
can be used to extract key information and store the sorted information as a
permanent file. That file can then be used to access the original input file in the
order of the key information in the sorted file.
SORT provides four sortlngtechruques:

• Record sort produces a reordered data file by moving th~ entire contents of
each record during the sort. A record sort can be used with any acceptable
VMS input device and can process any valid RMS(Record Management Ser\!ices) formatted file.

• Tag sort produces a reordered data file bymoVlngonly the record keys and
Record FileAddress~s (RFAs)duiingthesort.SQRT then randomlyreaccesses the input file. to create ,a resequenced output file according to those
record keys. The tag sort method may conserve temporary storage; hut can _
accept only input files residing on disk.

5-7

• Address sort produces an address file without reordering the input file. The
address file contains RFAs (Record's File Addresses), a pointer to each
record's location in a file that can later be used as an index to read the
database in the desired sequence. Any number of address files can be created
for the same database. A customer master file, for example, can be referenced
by customer-number index or sales territory index for different reports.
Address sort is the fastest of the four sorting methods.
• Index sort produces an address file containing the key field of ea~bdata
record and a pointer to its location in the input file_ The index file can be used
to randomly access data from the original file in the desired sequence.
The MERGE utility permits you to merge data from two to ten similarly sorted
input files. It merges the data according to key field(s), defined by you, and
gener~tes a single output file. All input files to be merged must be' a proper
..
subset of the equivalent SORT key fields.
The following example illustrates the sorting of a sales record file by cust~me~ .
last name. The name .ofthe initial file is SALES.DAT. Each record contains six
fields: date ofsale, depaitment code, salesperson, accouritnumber, customer
name, and amQlU).i ohak. The numerical ranges listedbeJ.ow th~s€t'of records
indicate the position arid size of each informationfieldwith~ the record.
You can now rearrange the sales record in file SALES.DAT according to any of
the file's information fields. For instance, to sort the file in alphabetic order. of
.customer's last name, you would type the followin~ cO~atld sequen~e: .
$

SORT/KEY_=(POSITION:Z!hSIZE:30) SALES.OAT IlILLING.LISI!®

In this command sequence, you are defining the SORT key to be the customer's
last name and the output file to be BILLING_US.
\OU may now obtain a listing of the sorted data file by using either the 1YPE or
PRINT commands .
. $TYPE .. BILl;ING. LISIW'

To perform the MERGEftinction,·the MERGE utility expects preSorted 9ata
files upon which to operate~ In the following example, MERGE is operating
upon two presorted (by alphabetic ordei-) sruesdatafiles,SIDREl.FILand·
SIDRE2Jo1L.
To m~rge the two data files, you must type the following cOITummd sequence:
$ MERGE/KEY= (POSIUON=29 .SIZE=30 )STOREI. FIL .STORE2.FIL. CENTR .FILIW

You have indicated· in the above command sequence that the files are to be .
merged via the alphabetic-order of the customer's last name. You can examine
the output file via the PRINT or 1YPE commands .
.. TYPE: CENTR.FILIW

5-8 • VMS Program Development Utilities

SORTIMERGEASA SET OF CALLABLE SUBROUTINES - SORT and
MERGE can be used asa set of callable subroutines from any VAX language.
This subroutine package provides two functional interfaces to choose from:
afileI/o interface and a record I10interface.
.

• VAX Lirlker
Before a source-language program can be run on VAXlVMS, it must be assembled or compiled by a language processor and then linked. The language
processor~ translate user-written source programs into object modules. The
VAX Linker binds these object modules into an image that can be executed by
the VAX system.
Not all computer systems use a linker; in some, the work of the linker is
assumedbyth~language processors and what is called a loader. But the linker

offers you greater flexibility in choosing and mixing languages, and simplifies
and extends the modem approach of modular programming.

INPUT TO THE LINKER - There are two basic forms of input processed by
the linker: object modules and sharable images. They are introduced to the
linkel' as part of the input files specified in theUNK command. The linker will
accept one or more of the following kinds of input files:
• Object file
• sharable itnage file
• Symbol table file
• Library file
• Options file
The object file can contain one or more object modules. This file has file-type
OBJ. It is the fundamental input to the linker and at least one object file must be
specified with any LINK command.
The sharable .imagefile is the product of a previous linking operation, but one
which is by itself not executable. It can serve only as input to another linking
operation. The sharable image file can only be specified in the options file and is
indicated thereby the Isharablequalifier.

5-9

The symbol table file is also a product of a previous linking operation_ It may
be specified when linking so that the linker can use the symbol values to
resolve undefined symbols in other object modules. A symbol table file has
the file type STB.
There are two kinds of hbrary files: object and sharable image. Of these there
are both system libraries (maintained by VMS) and user Libraries (created by
the OCL command, LIBRARY). Library files are used by the linker either to
resolve undefined symbols, or as a source for particular object modules.
The options file is not really input to,the linker, in the same sense the other files
mentioned are input; rather, it is a toolfor managing the linking operation and
for simplifying the use of complex and often-repeated linker operations. (This
is, in a way, analogous to the use ofDCL command procedures for complex or
commonly used command sequences.) A linker options file can contain one or
more input file specifications, including qualifiers or special linker options that
cannot be specified inthe OCL LINK i:om~d line.
OUTPUT OF THE UNKER - The linker will generate one of three typeS of
images: executable, sharable, or system, and an optional image map and/or
symbol table.
The most common output of the linker is the executable image. It is the end
product of program development. It has the file type EXE and can be run by the
OCL command, RUN. '

A sharable image, on the other hand, is nptinten<;ied to be executed directly. It
must be linked with one or more object mpdules to produce an, executable
image. It contains an image header, one or more image sections, and a symbol
table that defines universal symbols in the sharable image.
A system image is one that ,does not run under the control of the operating
system, but is intended to run standalone on a VAX. VAXlVMS is a system image.

If the /SYMBOL1i\BLE qualifier is specified, the linker will generate a symbol
table file that can serve as input to a subsequent linking operation.
ACIION OF THE UNKER - In the process of creating an image the linker

performs three major taskS:
• Resolution of symbolic references
• Allocation of virtual memory
• Image initialization

5-10 • VMS Program Development Utilities
The following sections describe these processes in some detail.

RESOLUTION OF SYMBOLIC REFERENCES - A symbol is a name associated with a program location or a value. Any reference to a symbol, other than
the definitive reference, must be resolved. For example:

JMP SYMBOLl

(JUMP

to where?)

,(Add what to what?)
Somewhere, SYMBOL 1 must be defined as a location of an instruction ot the
beginning of a subroutine. Similarly, SYMBOL A and SYMBOL B must have had
values assigned to them.
References to local symbols (that IS, symbols defined and used entirely within
the module) are resolved by the language processor, but references to global
symbols (those that can be referred to by modules other than the defining module) and universal symbols (those referenced outside of a sharable image) must
be resolved by the linker.
Since universal symbols are in fact global symbols that are available to modules
outside of a sharable image, the process whereby the linker resolves global and
universal symbols is the same. During its first pass through the linking operation, the linker records each symbol reference and definition in a global symbol
table. When the linker seeks to resolve a symbol reference, it first searches modules named in the command line (sometimes with /INCLUDE), then user libraries, and finally system default libraries.

MEMORY ALLOCATION - By the end of its first pass, the linker has
processed all the input modules and library modules needed to resolve undefined symbols, and knows how large the final image will be, but it still needs to
organize the image and allocate virtual memory.
The linker organizes the image on three levels: cluster, image section, and program section.
Clusters are determined in three ways:
• The default cluster (generated by the linker)
• User-defined clusters (generated by the CLUSTERS' option)
• sharable image clusters (one for each sharable image)

5-11

Image sections are created by gathering program sections (psects) with similar attributes_ Those attributes include the ability to write, execute and
share, in addition to position-independence, and protected vector_
Program sections and their attributes are determined by the language and,
optionally, by yourself, either through directives to the language processor (for
example, _PSECT in MACRO) or by the PSECLATTR option in the linker
options file_
The linker processes each cluster, one at a time - with the exception of
non-based, or position-independent, sharable images, which are allocated virtual memory by the image activator at runtime_ In processing all other clusters,
the linker organizes the psects within each cluster into image sections_ Then the
clusters are assigned virtual address space and the image section descriptor
(ISD) of each image section is updated to include the starting vittual address of
the image section_

IMA GE INITIAUZATION - After resolving references and allocating memory,
the linker fills in the actual contents of the image_ Primarily, initialization consists of copying all data and code into a single image; but the linker performs
two other functions at this stage: it computes values that depend on externally
defined fidds, and it insetts these values into the referencing location_

FIX-UP IMAGE SECTION - After it has initialized the image, the linker will
generate a special image section, called the fix-up image section. This image
section contains the code that makes otherwise position-dependent sharable
images position independent.
The general addressing mode is used to reference routines and data contained
ina sharable image. The linker converts general addressing mode directives into
longword-deferred addressing mode, with indirection going through the fix-up
image section. Failure to use general addressing mode when referencing a
sharable image will elicit a warning message.
All DIGITI\L VAX high-le-ve1languages generate position-independent code_

SHARABLE IMAGES - An important benefit of the linker is that it allows the
use of sharable im~ges. An effective application of sharable images can hdp to
conserve valuable resources in the your operating environment_ For example,
physical memory requirements would be reduced if global sections (one for
each image section of a sharable image) used commonly among processes could
be resident in memory and mapped into their address space_ Thus the same
physical pages satisfy a number of processes, reducing duplication. So, too, you
can con'serve disk storage and reduce paging 110, when sharing replaces
duplication.
..
.

5-12 • VMS Program Development Utilities

One of the reasons modular programming is so attractive is that a commonly
used routine or function can be developed or modified once, then incorporated into any number of programs. The use of sharable images carries this
efficient practice a step further. The modules that make up a sharable image
are linked only. once, so the overhead of resolving undefined symbols
(within the image) and generating image sections - the bulk of the linker's
work - is incurred only once, facilitating another level of modular hierarchy, Furthermore, since a position-independent sharable image is allocated
to virtual memory by the image activator at runtime, the code it includes can
be fJlodified and updated without having to relink every program that uses
that image.
THE LINK COMMAND - The linker is run by the DeL command:
$ LINK

[/CoMMand-qualifier ••• ] file-spec [/file-qualifier.i.].t.

At least one input file must be specified. There can be multiple command qualifiers,multiple file specifications, and multiple qualifiers for each file specified .

• The VAX Text Processing Utility (VAXTPU)
VAXTPU is a high-performance programmable text processing utility available
in VMS. VAXTPU is a tool designed to aid application and system programmers
in the development of text processing interfaces. The utility includes a compiler, an interpreter, a high-level procedural language, and two editing interfaces written in VAXTPU.

VAXTPU Interfaces
You can tailor one of the existing VAXTPU editing interfaces to suit your editing
style or you can write your own editing interface with VAXTPU. You can use
VAXTPU to design an intelligent editor for a specific environment. The editor or
other application that you layer on top of VAXTPU becomes the interface
between you and VAXTPU. You must use one of the existing VAXTPU interfaces
or create your own interface in order to access VAXTPU.

5-13

You can think of VAXTPU as a base on which text processing interfaces can
be layered. The two editing interfaces included in .the VAXTPU kit, the
Extensible VAX Editor (EVE) and the VAXTPU EDT Keypad Emulator, are
good examples of interfaces that are written in VAXTPU and layered on
VAXTPU. See Figure 5-2.
EDT
EVE

Keypad EMulatqr

Interface

1--------------------:
VAXTPU
1--------------------1
Figure 5-2 • VAX1PU As a Base for EVE and the EDT Keypad Emulator
You can write extensions for the two in-terf3ces1;llat are shipped with vA.XTi>u
or you can write a completely separateipterface for V~U. See Figure5c3.
User-written
Extension

Use r, ... "" r'~ t't"e"~'

EVE

Keypad EMulator

Interface

Interface"

E)(tensiDn,~

EDT.
User-written
Interface

+- ............................................................... ..; ............ -- ... ::::'_ ......... ,.. ..................... ,;,. -- ,,:,,+

VAl<TPU
+--------~--~--~---~------------~---------------+

Figure 5-3 • VAXTPU As a Basefot Use~·writlen Inter/aces·
Extensions to an existing interface can be ifnpleI)lented w¢h a. VAXTPU. command file (VAXTPUsource code) or with a VAXrPU section file (compiled
VAXTPU code in binary form). Because a VAXrPU section file is already compiled, start-up time for your interface will beshorte1'when.using a section file as
opposed to a command f i l e . · ·
.
The only way to implement an interface thatis entite1y user-written is)Vi.th;t
section file_

The EVE Interface
The Extensible VAX Editor (EVE) is a new editing interface that is easy to learn
and fast to use. Users with little or no experience with text editors can quickly
learn to perform basic editin.g tasks with the EVE interface. The most common
editing functions are accessed by pressing a single key on the EVE keypad.

5-14 • VMS Program Development Utilities

EVE is also a powerful and efficient editor for experienced users of text editors.
The more advanced editing functions are accessible by entering colIllhi:tnds on
the EVE command line. Many of the special featutesofvAxTPu (such astm.iltipIe windows) are available with EVE commands: Read the User's Guid~ to EVE
to learn more about the EVE interface.

The EDT Keypad-Emulator Interface
For those EDT users who do not want to learn anew interface for basic editing
tasks, the VAXTPU EDT Keypad Emulator provides all of the functions of the
EDT keypad and binds these functions. to the same keys that EDT uses. The
EDT Keypad Emulator also provides EDT users with a limited set of the EDT
line mode commands that can be entered after the asterisk that appears when
you press CpuiZ.
TheEDT :Keypad Emulator provides access to advanced VAXTPU functions on
the VAXTPU command line. To access'the VAXTPU command line, press PFln.
When you see the prompt, "vAxTPu command: », you can enter VAXTPU commands or statements and VAXTPU will execute them. Read the VAXTPU EDT
Keypad Emulator Quick Reference Guide for more information on this
interface.

Special Features
VAXTPU provides the following special features beside the features normally
associated with a screen-oriented editor:
• Multiple buffers
• Multiple windowing
• Multiple subprocesses within VAXTPU and at DCL level
• Text processing in hatch mode
,; .Insert or overstriKe text entry
• Free or bound cursormotion
• Learn sequences
• Pattern matdllng
• Key definition
• Procedural language
• Callable interface

If you use the EVE interface to VAXTPU, many of the special features of
VAXTPU are easily accessible with a single EVE command. If you use the EDT
Keypad Emulator interface, you must include a user-written extension to the
interface to have easy access to these special features.

5-15

Hardware and Tenninals That VAXTPU Supports
Because VAXTPU does not use a work file, but does all of its work in memory,
you may have to adjust some system parameters or divide files into smaller segments if the files you want to work with are very large_
VAXTPU supports screen-oriented editing on all DIGITAL video display terminals, except the VT52. One of the major goals in the design ofVAXTPU was fast
performance for screen-oriented editing. Optimum screen-oriented editing
performance occurs when running VAXTPU from VT220 and VT100 terminals. Some Digital video display terminals have hardware behavior that does
not allow optimum VAXTPU performance.
Although you cannot use the VAXTPU screen-oriented features on the VT52
series of terminals, on hardcopy terminals, or on foreign terminals, you can run
VAXTPU on these terminals if you use a line mode style of editing.

The VAXTPU Language
VAXTPU is a high-level procedural programming language that allows you to
perform powerful text processing tasks. The VAXTPU language can be viewed
as the most basic component of VAXTPU. In order to access the features of
VAXTPU, write a program in the VAXTPU language and then use the VAXTPU
utility to compile and execute the program. A program written in VAXTPU can
be as simple as a single VAXTPU statement, or as complex as the section file that
creates the EVE interface.
The VAXTPU language is blockCstructured and is easy to learn and use. VAXTPU
language features include Boolean operators, error interception statements,
looping, case, and conditio11al statements, and an extensive set of data types.
Comments are indicated with a single comment character, so that you can document your procedures internally. There are also capabilities for debugging
procedures with user'written debugging programs.

VAXTPU Data Types
The VAXTPU language has an extensive set of data types. Data types are used to
interpret the meaning of the contents of a variable, Unlike many languages, the
VAXTPU language has no declarative statement to enforce which data type must
be assigned to a variable. Variables in VAXTPU assume a data type when they are
used in an assignment statement.
The following statement assigns astring data type to the variable this-var:

this_var := 'This can b~ a string o~ y~ur choice.'
The following statement assigns a WINDOW data type to the variable x. The
window occupies 15 lines on the screen, starting at line 1 and the status line is
OFF (not displayed);

X := CREATE_WINDOW (1, 15. OFF)

5-16 • VMS Program Development Utilities

Many of the VAXTPU data types (for example, LEARN and PATTERN) are different than data types usually found in programming languages. Following is a
list ofVAXTPU data types;
• NULL - The initial state of a variable after it has been compiled, or added to
the VAXTPU symbol table.
•. STRING - A string constant.
• INTEGER - An integer constant.
• BUFFER - A collection of text records. The CREATE BUFFER procedure
returns this data rype as its result.
• WINDOW - A Window data type is a subdivision of the screen. The CREATE
WINDOW procedure returns this data type as its result.
• MARKER -A position within a buffer, tied to the character that resides at that
buffer position. The MARK procedure returns this data rype as its result.
• RANGE - All of the text that occurs between and including two markers. The
CREATE RANGE procedure returns this data type as its result.
• PATTERN - A collection of pattern expressions. The pattern operators and
the pattern built-in procedures return a pattern as a result.
• PROGRAM - A collection of VAXTPUexecutable statements. The COMPILE
procedure returns this data type as its result.
• PROCESS - A VMS subprocess. The CREATE PROCESS procedure returns
this data type as its result.
• LEARN - A collection of VAXTPU keystrokes. The LEARN. END procedure
returns this data rype as its result.

VAXTPU Language Statements
VAXTPU language statements include the following;
• An assignment statement (;) .
• Procedure statements (PROCEDURE-ENDPROCEDURE)
• Repetitive statements (LOOP-EXITIF-ENDLOOP)
• Conditional statements (IF-THEN-ELSE-ENDIF)
• Case statements (CASE-ENDCASE)
• Error statements (ON ERROR-ENDON ERROR)

5-17

VAXTPU Built-in Procedures
The VAXTPU language has many built-in procedures that perform functions
such as, screen management, key definition, text manipulation, and program
execution.
You can use built-in procedures, for example, to create an editing interface
with multiple windows. Multiple windows allow you to see parts of different
files (or different parts of the same file) on your screen at the same time. The
CREATEWINDOW procedure allows you to create and alter the number, position, and size of the windows on the screen. Since you can also create multiple
buffers and associate them with windows on the screen, you can edit multiple
files concurrently with VAXTPU.

VAXTPU allows you to run more than one process concurrently. You can use
built-in procedures to create multiple processes. The CREATEPROCESS built-in
procedure allows you to create a subprocess and attach a buffer to it for storing
the output of the subprocess. In one process you can compile a large program,
sending any error messages to a message file, while you continue to develop a
program in another process. Limitations on subprocess activity are the same as
the limitations for VAXNMS subprocesses.
You can use the DEFINEKEY procedure to bind a VAXTPU program to a particular key, or key combination. This allows you to control the actions that are
taken when a key is pressed. You can use the SAVE built-in to keep your key
definitions from session to session.
You can use the UNDEFINEKEY procedure tO,remove a key binding. The following example is a built-in procedure that removes the association between
the key sequence CTRL/Z and the code that it previously executed:

UNDEFINE_KEY (CTRL_Z_KEYI
You can use built-in procedures as statements within a VAXTPU procedure, or
as commands from either the EVE interface or the EDT Keypad Emulator interface. See the interface manuals for a description of how to enter VAXTPU proce'
dures or commands.

VAXTPU User-written Procedures
You can write your own procedures that combine VAXTPU language statements
with calls to VAXTPU built-in procedures. After you compile a procedure, you
can save it and call it when you need it.
The body of a procedure can contain zero or more VAXTPU statements. Statements are separated by semicolons. VAXTPU procedures can return values.
Procedures can be recursive.

5-18 • VMS Program Development Utilities

Example 5-1 is a sample procedure that uses VAXTPU language statements
(PROCEDURE - ENDPROCEDURE) and built-in procedures (SET and
MOVLVERTICAL) to slow down the action of the up arrow key:
!
!

This procedure. slows down the speed
Dfthe UP arrDW key while scrollirig

SET (AUTO_REPEAT, OFF);
MOVE_VERTICAL (-111
SET (AUTO_REPEAT, ONl;
END PROCEDURE

Example 5-1 • Sample User-written Procedure
Invoking VAXTPU
To invoke VAXTPU at OCL level, simply type EDITIVAXTPU, followed by the
name of your 6le. For example:
$

EDIT/VAXTPU text_file. lis

This command opens the 6le texLfile.lis for editing. Note that you can specify
only one input 6le on the command line. You can include additional61es from
within VAXTPU later in your editing session.
When you invoke VAXTPU with the preceding command, you are placed in a
default editing interface (unless you specify INOSECTION). The default editing
interface for VAXTPU is EVE. \lGe suggest that you create a symbol like the following so that you can invoke EVE with a command that suggests the interface
.
being used:
$ EVE:==EDIT/VAXTPU
If you want to invoke VAXTPU with the EDT I\:eypad Emulator rather than EVE
as your editing interface, enter the following command after the system
prompt:
$

EDIT IVA.XTPU/SECTION=EDTSECINI .GBL

Instead of typing such a long command line, you can create a DCLsymbollike
the following to invoke VAXTPU with the EDT Keypad Emulator interface:
$

EOTEM :== EDIT/VAXipU/SECTION=EOTSECIN1~GBL

Then you can simply type EDTEM at DCLlevel to invoke VAXTPU with.the EDT
Keypad Emulator interface..The terminal screen will look exactly as it does
when you use EDT, except for the two lines reserved at the bottom of the screen
for error and informational messages from VAXTPU.

5·19

EDITIVAXTPU Command Qualifiers
You can add qualifiers to the DCL command EDITNAXTPU. VAXTPU qualifiers
control such items as recovery and initialization files. Qualifiers to the
EDITNAXTPU are listed in Table 5-1.

Thble 5·1 • Qualifiers to the DCL command EDIT/TPU
Qualifier

Default

I[NO]COMMAND
I[NO]SECTION
I[NO]DlSPLAY

INOCOMMAND
ISECTION = EVESECINI

I[NO]OUTPUT
I[NOlJOURNAL
I[NO]RECOVER
I[NO]READ_ONLY

!DISPLAY
IOUTPUT
IJOURNAL
INORECOVER
INOREAD_ONLY

Initialization Files
You can use two kinds of initialization files to create or customize a VAXTPU
interface: command files and section files.

A command file is a VAXTPU source code file that has a file type VAXTPU
It is used with the VAXTPU qualifier ICOMMANDfile-spec. By default,
no command file is read when you invoke VAXTPU. ¥ou must specify
ICOMMANDfile-spec if you want to include a command file.
A section file is a compiled VAXTPU file. It is a binary file that has a GBL file
type. It is used with the VAXTPU qualifier ISECTION6Ie-spec. By default,. the
section file that creates the EVE interfaceisread when you invoke VAXTPU. You
must specify a different section file (for example, ISECTIONmysectionfile) or
INOSECTION if you do not want to use the EVE interface. Note that when you
specify INOSECTION, there is no interface to VAXTPU. Even the RETURN and
DELETE keys are not defined. INOSECTION is used in the process of creating
your own section 6Ie.
¥ou can use either a command 6Ie or a section 6Ie to customize or extend an
existing interface. A command file is generally used for minor customization of
an interface. A section file is used to customize or extend an interface when the
customization is lengthy or complex because start -up time is faster with a section file.
To create an interface that is not layered on top of one of the existing interfaces,
use a section file.

5-20 • VMS Program Development Utilities

Copies of both the command file and the section file for EVE and the EDT
Keypad Emulator are in SYS$SHARE. \1Ce included the command files on-line
so that you can read the VAXTPU source code to see how VAXTPU was used to
create the two different editing interfaces. The VAXTPU source file for EVE is
SYS$SHARE:EvESECINI.TPU. The compiled binary section file for EVE is
SYS$SHARE:EVESECINI.GBL. The VAXTPU source file for the EDT Keypad
Emulator is SYS$SHARE:EDTSECINI.TPU. The compiled binary section file for
the EDT Keypad Emulator is SYS$SHARE:EDTSECINI.GBL. H you cannot find
these files on your system, ·see your system manager.

Leaving a VAXTPU Editing Session
When you want to leave a VAXTPU editing session, you can either QUIT or
EXIT. H you QUIT the EVE or the EDT Keypad Emulator editing interfaces, the
work that you have done will not be saved. H you EXIT from these interfaces,
the current buffer will be written to a disk (if it was modified) and you will be
queried about writing other modified buffers to a disk.

• The EDT Editor
EDT, the Digital standard editor, lets you enter and manipulate text and programs. With its extensive HELP facility, the EDT editor is designed to be learned
by novices. In· addition, it provides many capabilities that will appeal to
advanced users.

WHAT EDT DOES - EDT is>a interactive text editor that provides:
• Both line and character editing facilities
• Screen editing using the keypad on VT100 or moo series video terminals
• The ability to work on multiple files simultaneously
• A journaling facility that protects against loss of edits due to system crashes

• An extensive HELP facility
• A default start ~up command file, which allows a choice of editing options to
be set automatically
•. A window into a file (on VT100 and VT200 terminals only) that lets you view
changes in buffer contents immediately
• Sharable installation for many users

5-21

BUFFERS - All editing with EDT is done using buffers. A buffer is a part of
EDT's memory. When you begin editing, the input file is read into the MAIN
buffer, and when editing is complete, the MAIN buffer is written onto the disk
as a file. Thus, editing in the MAIN buffer is like editing a file directly.

SDlRT UP FILE - When you invoke EDT, the editor checks to see if you created a start-up file. Editing options, such as SET MODE CHANGE and DEFINE
KEY, can be inserted in the start-up file. These options take effect automatically
when an editing session begins.

HELP FAGUTIES - The HELP facilities on EDT are extensive. You can get
help on general EDT operations by typing HELP. IT help is needed while in
keypad mode, pressing the help key displays information that is specific to
keypad editing. The help infortnation is tree-structured, so that more specific
help can be obtained on a general topic. ,
REDEFINING KEYPAD KEYS - You can redefine any of the keypad keys and,
most of the control (CTRL) keys on VT100 or Vr200terminats_ With this fea~
ture, a series of commands.can be ~ssigned to a key_EQT thenperfortns these
commands when the key is pressed. - -

THE SET AND SHOW COMMANDS 7 The SET cOmrrland; with ~- variety 6f
qualifiers, affects EDT's editiDg capabilities. SET controlS screen- parameters
such as line Width. SET alSO lets you detertnine the appearance of text, such as
changing the window size to less that 22 lines. The SHOW command pro~ides
infortnationon the. current state of the editor, such as tepninalparameters, definitions of keypad -keys, and the names of buffe~s in use durlflg an editing
session:
JOURNAL PROCESSING: Journal proceSsing pr6tectS your work against system crashes. During an editiDg seSsion, EDT saves all the input from'a terminal
in a journal file. After a system crash arid restart, you can retrieve and execute
commands in this saved file with the /RECOVER option. In this way, an editing
session can be recovered to nearly the time of the crash.

EDT MODES OF OPERATION -With EDT there is a choice of keypad or line
mode editing. They allow you to
• Display a range of lines.
• Find; substitute, insert, and delete text.
• Move, copy, and renumber lines.
• Copy text into a buffer and write it on files.
• Define the functiqns of keys.

5~22

• VMS Program Development Utilities

Keypad editing is available on VT100 and V12oo-series terminals. ,The group of
keys at the right of the keyboard is used to enter keypad functions.
Keypad editing is powerful and versatile, yet it is easy to learn and use. In
keypad editing, the active buffer is displayed on the screen as you edit. There is
a variety of editing functions available, each of which requires that only one or
two keypad keys be pressed to perform a function. You enter commands,
inserts text, and performs CONTROLfunctions fromthekeyhoara.

• Document~Eormatting Utility (DSR)
Designing and producing printed materials can be simplified through the use of
the Digital Standard RUNOFF (DSR) utility.DSR reduces the time needed to "
prepare a document by allowing both textual corrections and formatting,
changes to be executed in the same pass over the@e.Aridsincetext,changes do
not affect the basic. design, documents can be updated without extensive
retyping.
The input to DSR is a file containing the text of the document and ,the DSR
instructions. The output@e is th~ prinHeady doCument. After the program has
been run; the original @e remlrlns available for further editing. '
Formatting instructions consist of commands and flags. Command iines a~ sig- .
naled by a command flag, usually a period, in position one and can contain one
or more commands and text. Within the text are special characters - called
flags :-, that specify character enhancements such. as underlined text orbcildface Ptaracters.
.
FIIliNG AND JUSTIFYING - DSR ~ommands can set left and right margins,
sO that you can enter text without concern for line width or variable spacing

between words. The DSR program can fill and justify the text when it is rim.
Filling is the successive addition of words to, a line until one more word would
exceed the right margin. DSRjustifies the line by adding enough spaces between
Y/ords to expand the ,line to the right: ~~rgin, .

5-23

DSR DEFAULT MODES - When an input file is processed by the Digital
Standard RUNOFF utility, certain default actions are performed that do not
depend upon command or flag entries for their execution. These actions are
similar to those performed during the preparation of a manually typed
document.

DSR default modes provide
• A standard page size, 70 characters x 58 lines.
• Sequential page numbering.
• Right margin of70 characters, left margin o.
• Single spacing.
• Automatic tab settings for every eight print positions.
• Automatic filling and justifying is turned on.

PAGE FORMATTING - The page formatting commands control the appearance of each page for output. For example, there are page formatting commands to enable or suspend page numbering, produce and format titles and
subtitles, or force the printer to advance to a new page.
Another page formatting command allows a conditional page advance, based
on the number of lines left on the page. This capability can be used to guarantee
that text which should appear on a single page (for example, tables and lists)
will not be broken up.
For example:
LAYOUT 2,5

The 2 indicates page titles will be flush right on odd pages, flush left on even
pages; pages will be numbered at center bottom with 4 blank lines after the
body of the text.

TITLE FORMATTING - Title formatting commands provide page, title, and
subtitle information for all pages. Such actions as placing only the chapter heading on the first page of a chapter and printing any subtitles are provided for by
.
the title formatting commands.

5-24 • VMS Program Development Utilities

SUBJECT-MATTER FORMATTING - Subject-matter formatting includes
commands for managing the design and appearance of text, such as making a
ragged right margin, indenting a paragraph, skipping a number of lines, centering a·line of text, underlining, hyphenating, and overstriking. Parts of the text
can be formatted differently from one another, and commands can be combined. For example, you can have lists justified or having them with ragged
margins.

Table 5-2 • Selected Examples ofDSR Subject-Matter Formatting
Commands
Command
Sequence

Resuh

.LM5.RM58

Set the left margin at space 5 and the right margin
at space 58

.NF

Disables filling: causes a new line in the input file to
produce a new line in tbe output file

.N]

Disables justifying; lines are ragged right .

.BR

CaUses a break: current line is output without oeing
fill~d or justified

.Sor.sK2

Skips two blank lines

.PG

Causes a .BR then starts the next page

.TP25

Tests the current page to deterinine if thete is a minimum of 25 lines remaining. This is done so certain
segments of text (i.e., paragraphs, or listings) can be
kept together and not create "widows at the beginning of a page.

.center

Centers subsequent line of text between the left and
right margin.

.TS 3,7,19,15,26...

Sets up to 32 new tap stops to override the default
tab stop values

.P4,2,3

FormaU; paragraphs in which: first word is ind~ted
4 spaces; there are 2 blank lines between
paragraphs; there must be at least 3 lines remaining
on the page for the paragraph to be started on the
current page.

5-25

GRAPHIC, US[, AND NOTE FORMATTING - It often becomes necessary to
accommodate graphics, lists, and tables, or to allow for special notes to be
inserted. Footnotes also have to be prepared in such a way as to fit on the
appropriate pages of the final document.

Table 5·3 • DSR Graphic:, List,and Note Formatting Examples
Command

Result

.FIG 24

Leaves 24 lines for a figure to be inserted

.FIGDEF30

Leaves 30 lines, including at the top of the next
page, for a figure

.UST 1, "*"

Sets up a list with 1 blank line between items and
an asterisk marking each item

.LE
.DLE "(",LL,")"

Identifies the start of an dement
Establishes a user-specified display format for lisrs:
in this case, sequential, lowercase letters will be
enclosed in parentheses.

These commands provide a properly numbered and formatted outline. The
tight column indicates their output if these three header levds appear in chapter 14 of a publication.
.HL 1 Plays

14.1 Plays

.HL 2 King Lear

14.1.1 King Lear

.HL 3 1i-agic Flaw

14.1.r.'I1i-agic Flaw

5-26 • VMS Program Development Utilities

MISCEUANEOUSFORMATTING - Several useful DSR commands help you
to add comments. (not printed to the output file) to the source file, to gather
externally located files into the input, to exert conditional control, and to set or
display time and date.

Thble 5-4· Miscellaneous Formatting Commands
Command

Example

.IF complete

Processes the line following only if the qualifier
IVARIANT:CQMPLETE was given on the
command line.

!appendixC

DSR ignores comments

.ELSE complete

Marks the end of the line to process because of the

IF, and starts the alternative
.ENDIF complete

Marks the end of a group of conditionally
processed lines using the variant "complete"

FLAGS - Flags are special characters (for example, an ampersand) that perform
specific operations (for example, underlining). The specified operation is
invoked when a character is recognized as a flag by DSR. Certain special characters initially are recognized by default.
INDEX AND TABLE OF CONTENTS - DSRhas powerful facilities for creating
indexes and tables of contents easily. The IDC program generates tables of
contents.

Thble 5·5 • DSR Flag, Index, and Thble of Contents Commands
Flag, Index, and Thble of Contents Commands
fix#some#space

The SPACE flag (#) fixes one nonexpandable space
whenever it occurs

R..&D

The ACCEPT flag (_) prevents DSR from interpreting the ampersand in R&D as an underline flag

.x Satire

Creates an index entry for Satire. DSR gives it the
current page number

.ENTRY Parody>See
Satire

Provides a cross reference to the index using the
subindex flag

5·27

RUNNING THE DSR PROGRAM ·DSR is initialized by entering the follow·
ing command:

RUNOFF filespec@W
After processing the file, DSR terminates.

Table 5-6 • DSR Run Commands
$RUNOFF MYBOOK

Processes MYBOOKRNO and produces
MYBOOKMEM as output

Various qualifiers can be placed on the command line. Examples are:
IFORMSIZE = 55

Sets page to 55 lines rather than the default of60
lines

IPAGES=3-l:3-16,
4-1:4-16"

Prints only pages 3-1 through 3-16 and 4-1 through
4-16

/DEBUG: echo

'li-aces the operation of any DSR commands defined
by a parameter by echoing each execution in the
output file

/OUTPUT:TI:

Directs output to the terminal

• Other Program Development Utilities
Some of the other major program development utilities available toyou are:
• The Command Definition Utility
• The Object Analyzer Utility
• The Message Utility
• The Exchange Utility

The Command Definition Utility (CDU)
The VMS Command Definition Utility (CDU) creates, deletes, or changes command definitions in a command table. As input, the CDU accepts a command
table andlor a file that contains command definitions. The CDU processes this
input to create anewcommand table. The new table can be either executable
code or an object module.
The CDU provides a way of defining command line syntax. The commandtable
is used by theCLI (command line interpreter) to parse commands. TheCLIis
caIIable from the VAX Common Language Environment.

5-28 • VMS Program Development Utilities

The OBJECT Analyzer Utility.
The object module analysis utility checks an object module (or a concatenated
@e containing several object modules) to see if it is in the correct format for
input to the linker. It is a diagnostic tool for writers of compilers or assemblers
that generate VAX object code. The program, invoked by the DIGfD\L Command Language (DCL) command ANALYZE/OBJECT, can analyze the entire
module or only specified types of records. It checks the record type, contents,
and sequence of each object module record it examines. The program creates
an output file containing a record-by-record analysis of the object module,
including identification of any errors in the module.

The MESSAGE Utility
The MESSAGE utility allows you to construct informational, warning, or error
messages in standard VAXlVMS format. First, using a text editor, you create a
source @e that specifies the information used in messages, message codes, and
message symbols. The MESSAGE command can then be used to compile the
source@e.

The EXCHANGE Utility (EXCHANGE).
The VMS Utility EXCHANGE allows you to transfer files between foreign
volumes and VAXlVMS native volumes. It appropriately converts the @e format
when transferring @es between different structured volumes. EXCHANGE recognizes all Files-II volumes of VAXlVMS devices, as well as all DOS-II formatted volumes on nine-track magnetic tape devices.
EXCHANGE also recognizes several foreign file structures and supports most
operations that are useful for each volume structure. It allows you to initialize
and manipulate functions of the foreign volumes, for example.
You can use the EXCHANGE Utility to
• Locate bad blocks on volumes.
• List directories of volumes.
• 'liansfer @es to and from volumes .
• Delete @es and compress volumes for block-addressable devices (such as

RT-ll disks.)
The EXCHANGE Utility employs defaults to ensure volume formats and @e
structures are compatible with the type of operation you want to perform.

Chapter 6 • VAX Program Migration
and Cross-Development Tools

• Overview
One important benefit inherent in VAXlVMS systems is Digital's commitment to
software compatibility among the entire family of VAX processors and, in many
cases, other Digital systems as well. As a VAXlVMS user, you can migrate, or
move, many existing applications from one system to another and even develop
application programs on a VAX that will be executed on other Digital target
systems. These capabilities are realized through the use of the VAXELN Toolkit,
VAX-ll RSX, and the MicroIbwer/Pascal-VMS Toolkit.
• Realtime and other statically defined systems can be developed on a VAX!
VMS system with the VAXELN Toolkit and thenrun on a target VAX ptpcessor
without VMS present.
.
.
• Migration and cross development of many applications to and from the
RSX-ll family of operating systems is accomplished with the optional program development product VAX-II RSX.
• MicroIbwerlPascal is a modular executive and software developmc::nt tool
that runs under VMS and is used to develop PDP-ll (Q-Bus)~based
microcomputer applications.
...

6-2 • VAX Program Migration and Cross-Development Tools

This chapter introduces you to 3 VAXI
VMS. optional software products thaI
provide for the migration and cross
development 01 application programs
between the VMS operating system
and ottier Digital operating systems.

VAX-11.RSX

The VAXELN Toolkit

MicroPower/Pascal-VMS
VAX-11 RSX simulates the RSX-11M/11MPLUS operating system environment by
providing

The VAXELN Toolkit supports the development of stand-alone, statically defined
software systems. VAXELN applications

• PDP-11 users with a familiar user interface
tothe VMS operating system.
• Many RSX-11 and VMS program development utilities and other facilities for writing
RSX-11 programs that will execute in VMS
compatibility mode or under the RSX-11
operating system.
• An Applications Migration Executive
(AME) that provides a means of executing
most nonpriviledged RSX-11 programs on
VMS.

• Are developed under VMS with VAXELN
Toolkit components and VMS program
development facilities, used for standard
VMS program development.
• Applications runs on the entire line of VAX
processors without the VMS operating
system present.
• Are typically, although not necessarily,
used to develop realtime applications.

Figure 6-1 • Overview Of Chapter 6

6·3

• VAXELN Toolkit Overview
The VAXELN Toolkit is an optional VAX software product for the development
of dedicated, realtime VAXELN systems that run on VAX and MicroVAX computers. The toolkit runs on any VAX processor running the VMS or MicroVMS
operating system. This syStem is call the host system. Once you have finished
building the application, called the VAXELN system, it runs directly on a target
VAX processor without any operating system present.
Typical VAXELN applications run on individual processors used for "dedicated" or otherwise predetermined functions and that are not needed simultaneously for general computing, program development, or other uses for which
a general operating system, VMS for example, is more appropriate. Examples of
situations requiring dedicated applications are industrial automation, workstations designed for a particular profession, Ethernet server nerworks, or robots.
VAXELN is especially suited to, although not limited to, creating realtime applications. These software programs are used by a processor operating in an environment where response to external events is critical. Such applications include
the typical scientific and industrial data processing situations in which the computer's operation has to be precisely synchronized with machines and special
input/output devices.
The VAXELN toolkit simplifies the design and implementation of such applications by offering high-level implementation languages (Pascal and C), a conceptually simple and small kernel executive (which manages resources, processes,
and data), and pregenerated optionally included service programs and device
drivers (which implement a file system, nerwork communication facilities, and
IJOdevice handling).
VAXELN provides multitasking in Pascal or C programs. Therefore, you can
write a program made up of several concurrently executing parts. Besides mu1titasking, mu1tiprogramming is also supported, This means that entire pro·
grams, including multitasking programs, can be scheduled concurrently on the
same cpu. (Multiprogramming is different from multiprocessing. Multiprocessing programs literally execute in parallel, on different processors on the same
bus. Mu1tiprocessing is not available through VAXELN.)

VAXELN Systems
A VAXELN system is a set of programs executing on VAX hardware, along with
standard code and data that manage the program's execution. VAXELN systems
can run on individual VAX or MicroVAX computers or, with nerworking software provided in the Toolkit, they can be connected in an Ethetnet local area
nerwork (LAN) This nerwork may include VAXNMS nodes or any other nodes
using the DIGIThL Nerwork Architecture DECnet services and protocols.

6-4 • VAX Program Migration and Cross-Development Tools

Since DECnet is supported by all of DIGITAL's operating systems, VAXELN
applications cancommunicate with programs running on processors anywhere
in a DEenet network. This makes it easy to distribute an application's programs
among seve~al network nodes, and changing the network location of a program
typically reqUires no changes to the program code.
The hardware configuration for a VAXELN system also incl,-\des optional
peripheral devices, such as disks and tertninals, and communic.ation hardware
to support the executiop of the programs on various nodes in a LAN.. Besides,
the configuration may fucludespecial hardware you h~ve designed or acquired,
such as custom device interfaces.
The programs executing in a VAXELNsystem.are of two kinds:
• Your programs. These can include USer-written device drivers or resource services, as wdl as typical computational progiams.
• Programs (services and drivers) supplied by DIGITAL. Examples are the Network Service, the File Service, and drivers for the standard supported peripheral devices.
.
You can develop VAXELN systems entirely in a high-level language, including
the handling of devices, exceptions, timeouts, and power failures. The recommended languages are VAXELN Pascal or the VAX C programming language.
VAXELN .Pascal is a compatible superset of ISO-standard Pascal. Any program
Written in ISO-standard Pascal<;an be compiled by the VAXELN Pascal compiler
and executed as part of.a VA.X:a-N system. VAXELN Pascal is supported by a.
highly optimizing compiler that generates position-independent, native-mode
code. It is the primary implementatkmlanguage of the VAXELN Toolkit it~.
VAXELN also supplies you with a set of C runthneJibrary functions that
provides you witl1 the capability to write Cprograms running under
VAXELN. The VAXELN CRuntime library contains a compatibles~bset of
theVi\XIVMS C RUI).timelibrarya~dthe typiClll UNIX*runtime environ. ...
ment. ~~ al~pr6vides Jls;~ess toall VAXELNfeatures,
Many C programs originally written for VAXlVMS or UNIX will run in a
VAXELN system with only minor modifications. However, theVAXELN C runtime library does not support all VAX C or UNIX-emulation functions;

*UNIX is a 1l:ademark of AT&T.

6-5

You develop a VAXELN system by writing new programs in VAXELN Pascal or
VAX C. Programs can also contain existing subroutines written in other VAX
languages, provided that they do not call VAXlVMS services or language-specific
runtime routines calling VMS services. Then, with simple VAXNMS commands,
you combine the programs with each other, with any of the standard services
and drivers you want, and with the VAXELN kernel to form an executable system. If you are programming for a set of computers linked by a network, you
simply prepare a VAXELN system for each connected machine, or node.
Once a VAXELN system has been prepared, the system image is ready to be
booted on a target processor. A VAXELN system can be booted from a disk,
from a TU58 tape cartridge, from a diskette, or, if the host system has the
optional DECnet-VAX license and Ethernet hardware, by down-line loading the
system into the target computer. VAXELN system images also are suitable for
placement in read-only memories (ROMs) and booting from them. However,
the ROM-blasting equipment and software are not part of the Toolkit and must
be acquired separately.
After booting or downline loading a VAXELN system image onto each target
machine in your local area network, you have a completely defined VAXELN
application. The typical structure of such a network-based application consists
of:
• A VAX processor running the VAXNMS or MicroVMS operating system that
serves asthe host development system. This processor is used to develop and
build each VAXELN system. It also contains the VAXELN debugger, which
can remotely access one or more VAXELN target system nodes at the same
time for debugging purposes.
• On~ or more target machines connected by the Ethernet to the VAX processor serving as the host development system and to each of the other target
machines. Each target machine is a node in the network and contains its own
running VAXELN system.

Toolkit Components
Along with other software modules, you receive the following program development utilities (VAXlVMS program images) in the VAXELN Toolkit.
• TheVAXELN Pascal compiler.
.. The VAXELN debugger.
• The VAXELN system builder.

6-6 • VAX Program Migration and Cross-Development Tools
Application programs are written with the aid of the usual VMS text editors and
other utilities and are compiled with the VAXELN Pascal compiler or the VAX C
compiler (acquired with a separate license), as appropriate to the development
language in use. The compiled code is linked to special runtime libraries also
supplied with the Toolkit, using the standard VMS linker.
The runtime libraries provide special support for VAXELN Pascal and VAX
C va operations, the standard Pascal routines such as SIN, the standard C routines commonly associated with UNIX such as printf, and certain procedures
used in system programming. The libraries are provided both in object-library
and shareable-image forms in the Toolkit. In the latter case, only those shareable images containing code called by application programs are included in the
finished VAXELN system, resulting in a finished system with a minimal amount
of unused code, while maintaining maximum ease of use in program
development.
The VAXELN Pascal compiler can also be used for VMS programming. The
compiler generates the same Debugger Symbol Table (DST) information as
used by the VAX Symbolic Debugger. It is, therefore, possible to use that debugger to debugVAXELN Pascal programs running under VMS.
The VAxELN debugger is used to debug the programs in a developed,
executing VAXELN system. It can be used to debug a VAXELN system "locally"
using the target computer's console terminal,or, if you have the optional
DECnet-VAX license and Ethernet hardware, it can be used remotely to debug
VAXELN systems running on Ethernet nodes from your terminal on a VAX/VMS
node.
In the remote case, you can examine and manipulate variables and other items
by their declared names (symbolic debugging) and can examine lines of source
code in the program being debugged. The remote debugger can display the
states of all VAXELN processes and jobs in the local area network, and it can
dynamically change your "session scope" from one process or node to another.
In either case, when using the Debugger, you can evaluate expressions, execute a large set of debugger commands in the same general syntaxasused in
the VAX debugger, define new debugger commands and variables for usein
a debugging session, and debug kernelcmode code.
The VAXELN System Builder combines program images, theVAXELN kernel
image, and run-time routines to produce an image of the finished VAXELN
system.
Also included in the Toolkit are a number of program images ready for inclusion in your VAXELN system (additional information is given later in this
document).

6-7

The VAXELN File Service supports 1/0 operations from VAXELN programs
to file-storage devices, as well as remote file access to and from other DECnet
nodes. 1/0 requests from your programs are interpreted by the File Service
and performed by the appropriate device driver program. The File Service
and the Toolkit's disk driver programs use the DIGITAL Data Access Protocol (DAP), Version 7.0, for all low-level 110 operations with consumer programs and remote requests. Any user-written device drivers can be
combined with the File Service and programming tools are supplied in the
Toolkit for this purpose.
In a network application involving several VAXELN nodes, only one needs to
provide the File Service (and disk or tape hardware and driver) for use by all the
others. That is, the node can act as a file server for the others.
The VAXELN Network Service provides completely transparent network communication between VAXELN nodes in a local area network and between VAXELN nodes and other DECnet nodes. VAXELN provides the capability to restrict
node access to a specified list of users and for a program to determine the identity of a user issuing a network request through an optional service called the
Authorization Service (explain~d later in this document).

In network applications, each VAXELN node runs its own VAXELN system, and
each system is built including the Network Service. Given such a configuration,
the network locations of VAXELN application programs are completely invisible to each other; that is, a program can communicate with a program on
another node using precisely the same statements as if both programs were on
the same node. Internode communication is transparent.
The VAXELN kernel is included in every VAXELN system. It manages the system's processes and data, providing the controlled sharing of the system's
resources. The operations of the kernel are reflected in VAXELN programs by
special procedure calls, almost all of which are predeclared in the language. (A
few kernel procedures are not predeclared, although their calling interfaces are
documented. and are provided in declarations that you can include explicitly.
These procedures are low-level routines and are typically of no use to general
programming.) For C programming, these kernel procedures are contained in a
include module.
High-performance device drivers are supplied for the commonly used UNIBUS
(VAX) and Q-22 bit (MicroVAX) devices. All are implemented in VAXELN
Pascal and are supplied both in source form and in image (binary) form. The
driver sources can be used as templates for user-written drivers. (Refer to the
Optional Hardware section of this document for the list of devices supported
by drivers.)
A variety of other programming aids are supplied, such as template device drivers, declarations of Data Access Protocol (DAP) interfaces, and declarations of
exception arguments.

6-8 • VAX Program Migration and Cross-Development Tools

The Toolkit is delivered with complete user documentation, including reference manuals forthe VAXELN Pascal language and the VAXELN C runtime
library.

• VAX-l1RSX
VAX-II RSX is an emulator for RSX -11 operating system family and executes on
all VMS and MicroVMS systems. It runs in compatibility mode on processors
that support a PDP-II instruction set subset in hardware or microcode and it
also runs on certain processors without this support by providing its own so&c
ware emulation of the same PDP-ll instruction set subset. It provides special
capabilities that enable PDP-ll users to develop programs for execution in any
of the following environments:
• VAXlVMScompatibility mode
• MicroVAX rIlMicroVMS (sofrware-emulated compatibility mode)
• VAXstation II1MicroVMS (sofrware-emulated compatibility mode)
• RSX-llM-PLUS
• RSX-llM
• RSX-llS

• Micro/RSX
• PlOS

VAX-ll RSX also allows for the migration of many existing RSX-11 applications
to VAXlVMS and MicroVMS.

6-9

Program Development Capabilities
The program development facilities provided by VAX-II RSX consist of
• The PDP-ll Instruction Set Emulator (CEM$EMU~R) which emulates
the PDP-ll machine instruction set and allows RSX-U tasks to run on
MicroVAX 11 and VAXstation II processors that do not contain the compatibility mode hardware.
• The MCR command line interpreter (CLI). This CLI emulates the RSX-ll
MCR CLI so that you can interact with a familiar user interface. MCR also provides access to many of the native VAXlVMS and MicroVMS program development facilities.
• The RSX-ll Application Migration Executive (AME) that emulates the
RSX-l1 Executive services.
• The Indirect Command File Processor (ICM) that allows RSX-ll indirect
command files to be executed on VAXlVMS and MicroVMS.
• The DCL command back translator (BACKTRANS) that allows RSX-ll utilities to be invoked through the use of the DCL command interface.
• A subset of the RSX-11 program development utilities and libraries.
• A subset of the RMS-ll Version 2.0 program development utilities and
libraries.
The following RSX-ll program development utilities are available to users of
VAX-ll RSX:
• BRU - Backup and Restore Utility
• CRF - Cross Reference Processor
• DMP - File Dump Utility
• DSC - Disk Save and Compress Utility Program
• ED! - Line Text Editor
• FLX- File 1i-ansfer Utility Program

• LBR - Librarian Utility Program
• MAC - PDP-ll MACRO-ll Assembler
• PAT - Object Module Patch Utility
• PIP - Ihipheral Interchange Program
• SLP - Source Language Input Program
• TKB - 'Thsk Builder
• ZAP - 'ThskIFile Patch Program

6-10 • VAX Program Migration and Cross-Development Tools
The following RSX-ll program development libraries and components are
available to VAX" l1RSX users:
• FCSRES.STB- FileControl Services symboltable
• FCSRES.TSK - File COhtrol Services resident library
• ODT.OBJ - On-Line Debugging Tool object module
• QIOSYM.MSG- StandardRSX-ll QIO error messages
• RSXMAC.SML - Standard RSX-l1 macros
• SYSLIB.OLB - System object library (non-ANSI version)
• VMLIB.OLB - VIrtual memory subroutine library
The following RMS-ll program developmentutilities are available to VAX-ll
RSXusers:
• BCK - File Backup Utility
• CNV - File Conversion Utility
• DEF - File Definition Utility
• DES - File Design Utility
• DSP - File Display Utility
• IFL - Index File Load Utility
• RST - File Restore Utility
The following RMS-ll program development libraries and components are
available to VAX-II RSX users:
• RMSLIB.OLB - RMS-ll object library
• RMSMAC.MLB - RMS-ll macrolibraty
• RMSll.ODL - Prototype disk-based overlay descriptor
• RMSllS.ODL - Minimum-size partial-function overlay descriptor
• RMSllX.ODL - Minimum-size full-function overlay descriptor
• RMS12S.0DL - Medium-size partial-function overlay descriptor
• RMS12X.ODL - Medium-size full-function overlay descriptOr
• DAPllX.ODL - Full-function including remote support overlay descriptor
• RSMDES.IDX - Help file for the RMS DES utility

6-11
The following utility for file transfer to and from Micro/RSX systems is available to VAX-ll RSX users:
• MFr - Micro/RSX File lhnsfer Utility

General Access
When using VAX-II RSX, you can gain access to the system through the normal
VMS LOGINOUT procedure. You can request MCR as your command line interpreter (CLI) or have it specified as the default CLI in your User Authorization
File. You can also use the VMS CLI, DeL. Under DCL, however, not all of the
RSX and RMS program development utilities are directly available. Some of the
utilities are available through DCL commands (LffiRARY/RSXll, for example,)
but for some other utilities, you must explicitly request the utility to execute by
typing RUN SYS$SYSTEM:utility-name or MCR utility-name.
VAX-11 RSX indirect command files may be executed from either MCR or DCL
but must contain only indirect directives and MCR commands.
On VMS and MicroVMS it is only possible to switch from one CLI to another by
logging out of the current CLI and then logging in again using the new CLI or
by using the DCL or MCR SPAWN command. This differs from RSX-llM and
RSX-llM-PLUS.
Disk and 'Thpe Volumes
In addition to a native disk file structure, VMS and MicroVMS also provide a
disk file structure (called Files-11 Structure Levell) that is compatible with
RSX -11. This provides for easy cross migration of code and data. Both file structures are available to programs running in either compatibility or native mode.
VAX-II RSX supports general access to magnetic tape volumes. Thpes created
on an RSX-11 system byBRU, DSC, FLX, PIP, andRMSBCK can also all be read
on VAX-II RSX by corresponding utilities. Similarly, it is possible to create tapes
on VAX-II RSX to be read on an RSX-11 system.

6-12 • VAX Program Migration and Cross-Development Tools
Intersystem Facilities
VAX-11 RSX includes support for the Micro/RSX Data Terminal Emulator
(DTE) and File 1l:ansfer Program (MFf). Two-way file transfer capabilities to
and from Micro/RSX systems are provided by the MFT utility supplied with
VAX-II RSX that executes on the VMS or MicroVMS system and the DTE utility
that executes on the Micro/RSX system. Files of any type or size can be transferred from one system to the other in this manner. However, the file transfer
process can only be initiated from the Micro/RSX system. The Micro/RSX user
connects to the VMS or MicroVMS host system via a serial terminal line using
the Micro/RSX Data Terminal Emulator (DTE) utility. The Micro/RSX user can
then log into the host system as though the user's terminal wereditectly connected to the host.

DECner is not available to RSX programs executing under VAX-II RSX with one
exception: applications written to use RMS-ll Version 2.0 will have full access
toDECnet.

Compatibility
This product is an emulator of the RSX-11 family of operating systems. Specifically, this product is designed to emulate:
• RSX-11M-PLUS \ersion 3.0

• Micro/RSX \ersion 3.0
• RSX-IIM and RSX-IIS Version 4.2

As of Version 2.0, VAX-11 RSX now supports:
• Memory Resident Overlays
• Cluster Libraries
• FCSRES
• Search lists consisting of only devices and rooted ditectories
• VAXcluster SYSCOMMON (common system disk)

MeR Compatibility
The following RSX-11 MCR commands are suppotted:
ALLOCATE
DEALLOCAJ'E
HELP
RUN

ASN
DEBUG
INIT
TIME

BYE
DMOUNT
MOUNT
UFD

CANCEL
EDT
RESUME

6-13
The following VMS DeL commands are also available from the MCR CLI:

APPEND
CONTINUE
CREATE
CREATElNAMLTABLE
DEFINE
DEPOSIT
DIREC10RY
EXAMINE
MAIL
PRINT
RENAME
SEARCH
SHOW
SPAWN
SUBMIT

ATTACH
COPY
CREATEIDIREC10RY
DEASSIGN
DELETE
DIFFERENCES
DUMP
LOGOUT
MERGE
PURGE
RUNOFF
SET
SORT
S10P
1YPE

The installation procedure provides the option to install an MCR help library
that contains help text on both the RSX MCR and DCL commands, part of the
MCRCLI.

Indirect Command File Compatibility
All indirect command file directives and functions are supported to some
extent except .FORM, .WAIT, and .xQT. Most RSX-ll indirect command files can
be executed successfully on VAX-II RSX.
The following system generations and network generations are specifically
supported:
• RSX-11M-PLUS ~rsion 3.0
• RSX -11M Version 42
• RSX-11S Version 4.2
• DECnet-11M-PLUS Version 3.0
• DECnet-11MVersion 4.2
• DECnet-11S, Version 42

Note
MicroVAX II and VAXstation II are NOT recommended for RSX11 system generations or DECnet network generations due to the
performance characteristics of the PDP-II instruction-set emulator
on these processors.

6-14 • VAX Program Migration and Cross-Development Tools

General Areas of incOmpatibility
Every effort has been made to make ,the functions VAX-ll RSX Sllpports as
compatible as possible with the RSX-11'envii-onment. However, certain areas of
incompatibility do exist in this product and may continue to exist in future versions. The few areas of incompatibility mentioned in th~ vatioul! sections are
not guaranteed to be all inclusive. '
,
'
Other areas where incompatibilities exist incluqe:
• No support for supervisor mode libraries"
• No support for I-and-D space separation
• There are several differences between RMS-11 and VAX RMS

Compatibility with Other Derivatives of RSX-11
P/OS support is limited to the P/OS directiVeS which are identical to RSX~ 11MPLUS directives and are listed in the table above.
No compatibility is expressed or otherwise implied with any other versions of
the ~X-11 family of.operating systems or related operating syst~s, except
where specifically n o t e d . '
Optional Software
The following optional software products require VAX-II RSX as a prerequisite
for being generated or run on VMS and MicroVMS sYlitems.
ALL-IN-1 Office Menu VIA (Form Editor Application only)
CORAL 66NAX to RSX Cross Compiler
DECnet-11M (network generation only)
DECnet-11M-PLUS (network generation only)
DECne.:-llS (network generation only)
FORTRANIVNAXtoRSX ..
MicroIbwerlPascal-VMS
PDP-ll DATATRIEVElVAX
PDP-II FORTRAN-77 DEBUGNAX to RSX
PDP-ll FORTRAN-77NAXt6RSX
PLXY-11NAX

Professional Host <;:ommunications
Professional Host Tool Kit
Professional Host Tool Kit BASIC-PLUS-2
Professional Host Tool Kit COBOL-8f
Professional Host Tool J(it DIBOL
Professional Host Tool Kit FORTRAN-77
Professional Host TO<ll Kit FORTRA.N-77 DEBUG

6-15

Professional Host Tool Kit Pascal
Professional Real Time Interface Library
RSX-llM (system generation only)
RSX-llM-PLUS (system generation only)
RSX-llS (system generation only)
RTEM-ll
VAX CORAL 66

• MicroPowerlPascal-VMS: Modular Executive and
Microcomputer Software Development Toolset
MicroFbwerlPascal-VMS is a VAXlVMS optional program development product. MicroFbwer/Pascal is a modular executive and software development
package for PDP-ll (Q-bus) based microcomputer applications. It includes
software components needed to create, build and debug/test concurrent realtime application software running stand-alone on a target runtime microcomputer system.
MicroFbwerlPascal-VMS supports application software development using two
distinct hardware environments:
• Host VAXlVMS development system
• Target PDP-ll (Q-bus only) runtime system for the microcomputer
application
The application software is. created and linked with the appropriate MicroFbwerlPascalruntime software components on the VMS host development system. When the application software is ready for debugging/testing, it is
transported to the target runtime system. The application software can then be
executed on the target runtime system. If a serial line is connected between the
host development system and the console port of the target runtime system, the
execution of the application software in the target can be controlled and
tracked from the host with the help of the debugging tools provided in MicroFbwerlPascal-VMS.

6-16 • VAX Program Migration and Cross-Development Tools

The separation of the host development system from the target runtime sys'
tern allows you to make use of a high-performance VAXlVMS host development system and test the application software in the target runtime
environment. The MicroPowerlPascal"VMS Software Package includes the
following components:
• MicroPowerlPascal-VMS Installation/\erification command procedures
• Host-Development System Software components
Extended. Pascal compiler
Symbolic deb\lgger
MicroPowerlPascal-VMS Utilities
MPBUlLD Application Building Command Proce.dure
• MicroPowerlPascal target Runtime System Software
• Modular ~~time executive
• Thrget runtime device handlers
• RT~ 11 companble file system

·.Tuner services (clock process)
• Pascal Object Tune System (OTS) for target
• MACRO-II source libraries
An extended version of Pascal is provided as the system implementation language suitable for most user applications. The extensionS in the language enable
the user to wtiterealtime applications entirely in Pascal; hoWever, MAC:RO-ll
can also be used as the implementation language for sections of code.

Several components of MicroPowerlPascal-VMS. (such as the MicroPower/Blscal-VMS Utilities and the MicrolbwerlPascaI~VMS Pascal Compiler) run under
VAX-llRSX.
.
. .

Chapter 7 • Language and Tool Integration in the VAX!VMS
Software Devdopment Environment

• Overview
There are many approaches to developing software products; this chapter gives
you an overview of how many of our teams develop software at Digital. Specifically, it shows you how VAXJVMS languages, tools, and VMS services and program development utilities are integrated to create a consistent software
development environment.
'\Dur method of developing software may be different. Maybe y:ou use only a
few of the steps and techniques discussed in this chapter. You may have been
looking for ways to enhance the productivity of your department. The products
discussed in this chapter might help you achieve that goal.
IT you're interested in using a highly productive, environment of softwareaevelopment tools, then welcome to the VAXIVMS Software Development
Environment.
Topics in this chapter include
• An outline of the product development life cycle used within Digital.

• An example of how we use VAX languages, tools, and VMS Services and Program development utilities in vanous stages of the software life cycle.

7-2 • Language and Tool Integration in the VAXIVMS
Software Development Environment

THIS CHAPTER:
Provides you with

_.::= a specific example of

P~h~a:!se:!.,.::O~_ _ _ _ _~_ _ _ _ _ _ _ _ _ _ _ _J..,.

Phase I
Phase II
Phase III
Phase IV

how a shop of seven
developers creates a
hypothetical software
system usingVAXNMS
products in the five
phas.es oUhe program

..i;.
~~

r!J:::

"!I'd ......

~,~

'""'~

~'~I~ I?~;!!;~~j=,~ ~ ~~~opment
--~.

vAxM.Is

.... groodto_u_'"
.... _

~f'Ian

.....

life

~::::i~t~~~

\I!'!~~_..jhbh

1-1: The Pl'ogrn Develop.ent Lite Cycle

r-l1i....'-L.l:.l=-J.:.-:.Jt~;;;-~;~;;-;~;~;-i-;~;;;-;;~;~;;;;;;·-----·----------------+

t-------------------------------------------:-----------------+

I Phase 0:

" lit Requinunts dacu.ent
I
lit PreU_inary Eunct.ional,specification
I
1 Risk. Analysis
,1\ Prototype or 'breadboard- (nut-iles) I
I
14 PreU.inny testing strategy
I
I
'Iechninl analYSis
I
+... ':"-------:---------~-~-----------------.,.--------------- -------+
Phnlt'l:
Design ·Docu.ent
DUign
,A: final fUnctional speeificatiC!n
,. Pinal Developnnt thn
, (P'roject schedule)
I !est specification
Identifies deliverables
,
1* "Ear~y product" code
I
generated in each
1------------------------------------------------------------ +
phase of the life
I Phafie 2:
I Code .oduln
I
cyc;le and the products I I.pl.-entation
D.ebug lodules
,
I
I~ Updated project docu.ents
I
from the VAXNMS
lit In,enedhte working versions of the
I
I
Environment used to.
,
I .yste. tBaselevels}
.
I
produce those outputs: I
lIser docu ••nh
I
"'
1* Unit tnts
I
Perforunce testing
,
I
Syste. testing
(
,
lit Pinal test Modules
I
,II Field test Kit
,
1* Writ.e a .aintenance doculent.

·1 Business' and

I'.

'**

'*
'*'*

+------------------+-----------------------------------------+

I fhase 3:
I Qualification

1* Custo.er Environeent test
'II Pinal Product (Sw/Doc) Kit

+------------------+-----------------------------------------+
I Phase 4:
1* Archive Copies of Sources _, Doculents

I Production,
I Maintenance_'

1* fix bugs, when reported
1* Enhance the product, if justified

I Evolution

+------------------+---------,..-------------------------------+

Phase 0:
Requiruents and
Analysis

Phase I:
Dnign

Phase a:
Ilpleeenta\ion

Phase 3:
-QualifiCI\ion

Phase 4:
Support

----- -------,,-------- -------- \
+---------------------------------------------------------------------+

I 8usine,s and I Prelil.
,Design
I technical
I
1 Risk
I. Andysil
I

I Detail
I Design
I
1

I l.plelenI htion
I
I

ltesting 1 P'roduction,
'-Ind
I Maintenance,
IVerUi- I and
1cation I Evolution

."',. ...................... _.... _------_ .... _------------------------------------------+
\

------------------------------V-------------------------------------

The Progul Devi/loplent Life CyCle

Figure 7-1· Overview a/Chapter 7

Provides you with
a detailed description
of each phase in the
program development
life cycle, as we
define it a Digital.

7-3

• Introduction
\Xe are going to look at a specific example of how the VAX languages, VAX tools,
VMS selVices, and program devdopment utilities can be collectivdy applied to
solving program devdopment problems. First, let's review the program devdopment life cycle and take a close look at each phase of that life cycle. \Xe will
review the output a programming department might produce in each of those
phases, and the VAX languages, tools, and program devdopment utilities that
can be used.

The Program Development Life Cycle
~ you can see bdow, we have chosen to define the program devdopmentlife

cycle in terms of five phases. Some of these are further divided into more specific areas. These may vary from company to company. The general concept,
however, is valid in the design of any software system.
Phase O.

Phase I.

Phase 2.

Phase 3.

Phase 4.

Desifn

IMPleMentation

Qualification

Support

ReClui reMents and

Analysis
\I

+----------------------------------------------_._---------------------+
Business and
Technical
Risk

PreliM.
: Design

Detail

IIllP!eMen- ITestinf

: Design :" tatian

Analysis

Productiont
land
: Maintenancet
:Verifi- : and
Ication 1 Evolution

+------------------------------------------~---------- ----------------+
\ _______________________ c _________________

"C ________________________ /

7-4 - Language and Tool Integration in the VAX/VMS
Software Development Environment

Thble 7-1 shows us some of the typical output generated in each phase_
Table 7-1- The Program Development Life Cycle

Life Cycle Phase

Phase Deliverables

PhaseO:
Business' and
Risk Analysis

* Requirements document
* Preliminary Functional specification

Phase 1:
Design .

Phase 2:
Implementation

* Prototype or "breadboard" (somciimes}

* Prcli1nirulry testing strategy
* Technical analysis
* Business Plan
* Design Document
* Final functional specificat19P
* Final Development Plan (Project schedule)
* rest specification
.* "Early product" code
* Code modules

* Debug modules
* Updated project documents
* Intermediate working versions of the system
(Baselevets)
" User documents
* Unit tests
* ltrformance Testing
* System Testing
* Final Test Modules
* Fieldlest Kit
* Write a maintenance document

Phase 3:
Qualification
Phase 4:
Production,
Maintenancc-&
Evolution

* Customer Environment Test
* Final Product (Sw/Doc) Kit
* \blume reproduction of final product
* Archive Copies of Sources _& Documents
* Fix bugs, when reported
* Enhance the product, if justified

7-5

These deliverables can be categorized as documents, programs, tests, and
files. We use combinations of software tools to specifically managedeliverable in each <!ategory. For example, we can use the Language Sensitive Editor
to call up templates for documents (as well as programming languages),
DEC/CMS to track changes in documents, the VAXTPU editor to actually
make changes, DSR to format chapters of each document, and DEC/MMS to
actually control the construction of one or more documents.
A brief description of each Engineering Phase is given below. A detailed explanation of how VAXlVMS tools, languages, and core development utilitieS can be
used during a phase to produce the required output is found in the second
section of this chapter, beginning under the subhead, "Here's a Specific
Example".
• PHASE 0: BUSINESS AND RISK ANALYSIS
Project definition is the first phase in the product development life cycle. During this phase a team of technical and product management peOple defines business opportunities, product objectives, and technical options. The cost versus
benefit of the project is analyzed. At the completiori of this phase, the project
team has defined project goals and· has written a requirements documents, a
business plan, 'and perhaps a preliminary functional specification document.
The technical team also makes sUre that they ~ be aqle to confirm correct
,
opetation of the potential product.'
During the analysis portion of this phase, the project team is determining tech e .
nicalapproaches needed to build the ,intended product. Often, possible solutionstodifficult technical problems are breadbolll'ded or prototyped to make
sure the implementation -risks.are well. understood. -Prototyping. is. especially
. important in undetstanding the human interface to the software and its ability
to be used. At the end of this stage of development: the system is genetally
defined, and. a business decisidn is made on whethet to attempt.an actual project start.'
• PHASE,}: DESIGN
During this phase, the project team determines precisely what has to be built
and how it will be accomplished. The first step in this phase is.writing the final
Functional Specification and the Development Plan (schedule), and Documentation plan.' When project specifications are complete, d~sign can. then take
place and the software product takes on full-system definition (Note, this chaptet uses "design" in the same context that many organizations use "analysis").
Top-level designs for all forms, data structures, program modules, file formats,
and human interfaces are made based on the items listed in the functional specification. Once completed, the design gives the project technical definition.

7-6 • Language and Tool Integration in the VAXIVMS
Software Development Environment

A Design Specification and a Test Plan, generated during this phase, serve as
a basis for acceptance of the design. A design document makes it possible to
keep the design specifications in one location, accessible hyallprogrammers, As the project design evolves, ,so does ,the design document.
• PHASE 2: IMPLEMENTATION
The implementation phase of the program development life cycle is mo~ often
associated with building sour~ code modules, then compiling, 'linking; and
executing, the resulting images, Often, the system is implemented in a s~riesof
stages or baselevels in which each baselev'el,adds more and more of the
functionality. However, because program development is an evolutionary process, many other steps also occur concurrehdy.'
,
,

required

During the implementation phase, user documentation and the test generation
also run at full speed. The tests defined in the requirements doctunent must be

created and run to complete ensure a correctly operating implementation.
Unforeseen problems in implementing design requirements might mean that
specifications and designs require rework. If this is the case, then the effects of
changes in,xequirements or designs'must be reflected accurately in both the
programs being written and the user dOCUmentation set. At successful completion of this phase, the project should have a software system ,that works. '
The project team must analyze the structure and performance of the software in
this Phase, in addition to passing functional tests without errors. During this
phase, design, code, and documentation reviews are held frequently. Other
groups can be given copies of the software to determine how well the program
works under controlled conditions. ferformance analysis ensures the system
will meet certain customer-environment requirements.
• 'PHASE 3: QUALIFICATION
During this phase, the software is 'in use in selected customer environments.
The technical team stays in close contact with external test sites, making sure
any needed corrections are reflected in the version of the software and!or documentation to be shipped to our general customer base. In later stages of this test
period, the sources and documentation are frozen, and final copies of the books
and distribution media are prepared.

7-7

• PHASE 4: VOLUME PRODUCTION, MAIN1ENANCE AND
EVOLUTION
In this phase, master copies of the documentation and the software are handed
to a high-volume production group for replication and distribution to Digital
Software Specialists (support groups) as well as customers with support contacts in effect. Copies of the master kit are archived, in case of physical disasters.
A post-mortem review is held on the overall project development cycle just
completed;
Mer the product has been shipped, a process of maintenance and evolution
begins. Should there be errors in the software or documentation, bug fixes and
updateswilI be made. Enhancements to support new operating system or hardware releases may be planned. Suggestions arrive from customers using the new
product. In fact, because a software system is frequently evolving, this phase
becomes an information-gathering activity which could initiate Phase 0 for the
next version of the software.
Figure 7-2 lists VAXIVMS program development products. Each product can
play an important part in the program'development life cycle. The specific features and benefits of each of these products have already been explained in
earlier chapters of this handbook.

7-8 • Language and Tool Integration in the VAX/VMS

Software Development Environment

VMS CORE SERVICES
1. The VMS .Operating System

2. VMS Services'
,- The DigitalCommand language (DCl)
~ The VMS Runtime Library (RTL)
- VMS system services'
- The VAX Record Management Services
(RMS)

3. The VMS Program Development Utmties
- The VAXIVMS Symbolic Debugger
- Sort/Merge .
.
- The VAX Linker
- The VAX Librarian
- VAXTPU text processing utility
,- DSR text-formatting utility
'- Mail
.
VAX OPTIONAL PROGRAM
DEVELOPMENT PRODI:JCTS·

4. VAX Languages
- VAX Ada
- VAX Api
-VAX BAsiC
- VAX BLISS
- VAXC
- VAX COBOL
- VAX CORAL
- VAX DIBOL
- VAX DSM
- VAX FORTRAN
- VAX LISP
- VAX PASCAL
- VAX PLiI
- VAX RPGII
- Other VAX Languages

5. VAX Software Productivity Tools

,~~'~
6.10

- VAX DEC/Code Management. System
(CMS)
- VAX DEC/Module Management System
(MMS)
- VAX Language-Sensitive Editor
- VAX. Performance and Coverage
Analyzer (PCA)
- VAX DEC/Shell
- VAX DEClTest Manager
- VAX Graphical Kernel System (GKS)

6. Related Program Development Products
6.1 VAX CDD
6.7 VAX FMS
6.2 VAX DBMS
6.S DECnet Communications
6.3 VAX Datatrieve
Products
6.4 VAX RdblVMS (ELN)
6.9 VAXELN
6.5 VAX ACMS
6.10 VAX-II RSX
6.6 VAX TDMS
6.11 MicroPower/Pascal-VMS

Figure 7-2 • The VMS operating system, VAX Languages, VAX Tools, Program
Development Utilities, and Related VAX Software Products

7-9

Table 7·2 • VAXlVMS Products Used In The Software Development
Life Cycle
Life Cycle Phase

Deliverables Generated
During The Phase

VAXlVMS Service or
Product Used

Phase 0
Business and
Risk Analysis

* Requirements document
* Preliminary Functional

"text editor(s) and DSR
text-formatting utility
* Mail utility
* Language Sensitive
Editor (document
templates)
*DEClMMS
* DEC Test Manager
*DEC/CMS

Specification

* Business Plan
* Prototype or
"breadboard"
(sometimes)
" Preliminary testing
strategy
* Technical analysis
Phase 1
Design

;, Design Document
* Final Functional
Specification
* Final Development Plan
(schedule)
" Test specification
" "Early Product" code

* System Services
" Common Run Tune
Library
" Record Management
Services
* VAXlPU Editor and DSR
text-formatting utility
* Mail utiliry
* Language Sensitive
Editor (document
templates)
* Common Data
Dictionary (CDD)
* FMS (Forms Management) or VAX TDMS
*DEC/CMS
"DECIMMS
;, DEC/Shell or OCL
;, Language Compilers
(continued on next page)

7-10 • Language and ToolIntegration in the VAX/VMS
Software Development Environment

'Thble 7·2 • VAXlVMS Products Used In The Product Development
Life Cycle (Cont.)

Life Cycle P~ . Deliverables Generated
During The Phase

VAXlVMS Service or

Product Used

Phase 2 .
Implementation

* Code modules
;* Debug modules
* Final Test Modules
* Intermediate working
version of the System·.
(Baselevels)
* Unit Tests
* User documents
* Updated project
documents
* ~rformance Tests
* System Tests
* Field test kit
* Maintenance Document

* System Services
* Common Run TIme
Library
* Common Data
Dictionary (CDD)
* FMS (Forms Management) or VAX TDMS
* Record Management
SelVices
* VAXTPU Editor and DSR
text-formatting utility
* Mail utility
* Debugger
* Linker
* Language Sensitive
Editor
* DECITest Manager
* ~rformance and Coverage Analyzer (PCA)
* DEC/Shell or DCL
*DEClCMS
*DEC/MMS
* Language Compilers

Phase 3
Qualification

* Use in a customer
environment
* Final Prod~ct Kit

* Debugger
* text editors
* DECITest Manager
* ~rformance and
Coverage Analyzer
* Language Compilers
* Language Sensitive
Editor

(SWlDoc)

Phase 4
Production,
Maintenance,
and Evolution

* Archive a copy of

* All selVices and products

the master kit
* Fix bugs, when reported
* Enhance the product, if
justified

listed above

7-11

• Here's a Specific Example
The rest of this chapter is an example of how you might use VAXlVMS tools and
languages in your department to produce software. We will follow the development of a hypothetical software system through each phase of the program
development life cycle (defined earlier in this chapter).
Keep in mind the purpose of this example. It gives you the opportunity to see
how we use VAXlVMSproducts to develop software at Digital. It has also been
provided to emphasizes the unique ability of our products to help you maintain
and control the base of knowledge that must be managed if you are to program
productively.
Your Department
Figure 7-3 introduces you to your department - six programmers and a documentation specialist; all are working on a VAX processor running the VMS operating system (selVices and program development utilities included), multiple
VAX languages, and productivity tools installed. Note that these software products are organized vertically along the left side of Figure 7-3.

ream member 1 is the Project Leader for the software system your department
is about to begin work on. Members 2 and 3 are senior programmers, while 4, 5, .
and 6 are junior programmers. Team member 7 is the writer/documentation
specialist.
Member 3 is a FORTRAN programmer and Member 4 has prior experience
with COBOL. The rest of your department uses VAX C. kmay, therefore, be
necessary to write the software system in severallanguag¢s 1£ programmers 3
and 1are to be as productive as possible. The VA]{ Common Language Architecture, as we will see later, makes it possible for a single application to be written using more than one VAX language.
.. ..
Once again, in Figure 7-3, at the top of the column titled, VAXlVMSProgram
Development Environment, you will p.otethereare a number of VMS selVices
running across the entire figure, below all the programmers. These SeMces DCL, RMS, R:rL, and VMs system se1Vi.ces - are provided by the VMS operating system and are always present pn the system. (For more on these se1Vi.ces, ..
see Chapter 4 of this handbook.) ..
The. first VMS seMce ·(a horizofit~ bar directly below the assignment boxes)
represents the command language interpreter used by all programmers.
Programmer I,because she comes from It Upix: environment, is using the VAX
DEClShellcommitfid language interpreter in conjun¢tiOri with OCL.

':"

YOU

PROJECT
LEADER

Sl~

SENIOR
SENIOR
JUNIOR
JUNIOR
PROGRAMMER PROGRAMMER PROGRAMMER PROGRAMMER

'" "

" ".g-8"
li! ....
~if

PHASE'
ASSIGNMENT

tr1~

.,::! ...~

~. c'

VAX
PROGRAM

'-':{;;,~~
~::::

VMS
CORE
SOFTWARE
PRODUCTS

VMS
OPERATING
SYSTEM:
:

"',

RMS,
SYS" SEA., _
VAXTPU,

:-::::::::::;:::::;:;:::;:::;::::;j;:.;.....

'.
,

IIE~D~T~"__'_;:'::-l-___,~~_~____~__________________~l

LDSR

::
' { • DEBUGGER
VMS'
' . LINKER::
PROGRAM"
", LIBRARIAN
DEVE, LOPMENT'
UTlLITIES

::::.:...... .

I'.~O~T,~HE~R~~VM:S~~
_ _~~~_ _ _ _ _ _~~~_~_ _ _~_______~_ _ _~_ _~
L
UTILITIES '
Figure 7-3 • A Model Program Development Department

::! ::!
li! ~.

Ss..
...

VAX C
VAX
LANGUAGES

VAX COBOL
VAX FORTRAN
VAX
LANGUAGESENSITIVE
EDITOR
I

VAX DEC/TEST
MANAGER

VAX
PROGRAM
DEVELOPMENT
PRODUCTS

VAX
PRODUCTIVITY
TOOLS

VAX
PERFORMANCE
AND COVERAGE
ANALYZER (PCA)

VAX DEC/CMS
(Code
Management
System)

VAX DEC/MMS
(Module
Management
System)
I

':"
\;:;

Figure 7-3 (Cant.) • A Model Program Development Department

7-14 • Language and Tool Integration in the VAX!VMS
Software Development Environment

Getting Started·
Figures 7-4 through Figure 7-8 show us your programming staff in each phase
of the program development life cycle. These figures illustrate project assignments, the work flow of each assignment, and VAXlVMS products used to
accomplish those assignments. For example, Figure 7-4 illustrates the flow of
work in Phase 0 of the life cycle, Business and Risk Analysis.

The general layout of these figures is important to undersrand before you continue reading. They serve as the basis for the discussion of work done in each
phase.
You will note that below each team member's picture in Figures 7-4 through
Figure 7-8 is a block containing his/her assignment for that particular phase. In
Figure 7-4, for example, under programmer 1's picture is the assignment: project requirements.
Directly below that assignment block is the first step ill a sequence of steps she
must perform to successfully complete the assignment. Again, ill Figure 7-4, we
see that the first step in writing the requirements document is to create text files
(DSR source-input ".RNO" files) ill which to write and store the document.
The names of the primary VAXlVMS products used to complete a step are
located in the column titled, the VAXlVMS Program Development Environment. (Located at the left side of the figure.) Thus, ill Figure 7-4, programmer 1
has used VAXTPU or the VAX Language-Sensitive Editor (with appropriate
template files), to create and store text ill a DSR input file. (Note the VAXTPU
editor is used to create the DSR illput ".RNO" files and the DSR text-formatting
utility is used to produce" .MEM" output files.)
Defining and Analyzing the Software System with VAX!vMS
Now that you understand the format of these figures, we can continue with our
example.
The definition and analysis of a new software system is one of the most important parts of a software system's development. nurii:Igph~e 0, you must make
many important decisions that will affect subsequent phases of the life cycle.
Therefore, itis of prime importan~ethat illputJrom all the programmers and
support personnel be quantified and organized illto outp4t that is accessible to
everyone involved in the project. Doing it right the first time minimizes. the
amount of fine tuning necessary later in the life cycle. .
.
As you can see ill Figure 7-4, you ~d your staff are about to begill. Not all the
staff members are illvolved ~ the new project. (Notice that team meml:>ers 4, 5,
6, and 7 are still working on a previous project.) Assignment~ for this phase are
listed below the staff member.
.

7·15

Defining and Analyzing the Software System with VAXlVMS
Now that you understand the format of these figures, we can continue with our
example.
The definition and analysis of a new software system is one of the most important parts of a software system's devdopment. During phase 0, you must make
many important decisions that will affect subsequent phases of the life cycle.
Therefore, it is of prime importance that input from all the programmers and
support personnd be quantified and organized into output that is accessible to
everyone involved in the project. Doing it right the first time minimizes the
amount of fine tuning necessary later in the life cycle.
As you can see in Figure 7-4, you and your staff are about to begin. Not all the
staff members are involved in the new project. (Notice that team members 4, 5,
6, and 7 are still working on a previous project.) Assignments for this phase are
listed bdow the staff member.

YOU (THE BOSS)

PHASE 0

';--J

.....

PROJECT
lEADER

SENIOR
PROGRAMMER

JUNIOR
PROGRAMMER

TRAINEE

~3 ~4

DOCUMENTATION
SPECIALIST

'"
~t
~~

~ ~

nll><>

t:;'"

~ !i

... !:>...

.g-~
~ I<...

DCl

~~
tTl~

PHASE
ASSIGNMENT
VAX
PROGRAM
DEVELOPMENT
ENVIRONMENT

Project
Requirements

Project
Functional
Specification

Breadboard
or
Prototype

The rest of your staff is still
assigned to projects unrelated to
this application system,

<l
a''" C'...
;>t
;>t

;>t

~ ;0'

~ "'"
......
~
"-

VAXTPU
EDT
DSR
(text
editor,
and textformatting
utility)

Figure 7-4 • Phase 0 - Defining and Analyzing the Software System

PROJECT REQUIRMENTS

DEC/CMS
(Code
Management
System)

{to build
document)

INPUT
DEC/MMS
(Module
Management
System)

DEC/MMS BUILDS
THE APPLICATION
PROGRAM, PROJECT
DOCUMENTATION, AND
THE USER DOC SET
FROM CMS LIBRARIES
OUTPUT

PHASE 0
PROJECT DOCUMENTATION

-- - --

_ .. _--- ---

--- - - - - - - - -

Figure 7-4 (Cant.) • Phase 0 - Defining and Analyzing the Software System

)J
....

7-18 • Language and Tool Integration in the VAXIVMS
Software Development Environment

You and your three senior programmers will generate the project requirements, preliminary functional specmcation,and analyze difficult technical
problems. The output of each of these assignments represents a single section in the project documentation. Programmer 1 will generate the requirements document, you and Programmer 2 will write the preliminary
functional specification. Programmer 3 will begin to work on the technical
problems associated with the overall project.
It is important to note that each of these assignments, even though only one
person is ultimatdy responsible for its completion, is really a team project. All
team members generate input that must be incorporated into each other's documents. A number of VAXlVMS tools are available to hdp you better manage
these paperwork aspects of the project - the DEC/Code Management System
(CMS), the VAXTPU text editor, the DSR text-formatting utility, the VMS MAIL
utility, and DECIModule Management System (MMS) and the VAX Language
Sensitive Editor.
\bu and each programmer create your documents with the VAXTPU editor or
Language Sensitive Editor (using document-related templates specific to DSR
and the type of document(s) to be produced) and DSR text-formatting facility.
Each document then becomes a require file for a DSR document. As they are
created, these files are stored in one or more CMS libraries. Then, once you have
determined how to put the document together, DEClMMS can build or rebuild
the versions you require with a single command.
CMS hdps track the reasons, the time and date, and the initiator for modifications to the documentation. A number of intermediate stages of the document
can be established. By consulting these, each person involved in creating the
document can see exactly what the most current version of the document looks
like, or, if necessaty, reconstruct past versions of the document. This control
enables those you choose to see how the document has evolved; who changed
what, when, and why.
The Requirements document, the Preliminary Functional Specification, and
Project Plan document can be part of the same CMS documentation hbrary or
each can be stored in its own CMS library. DEClMMS can be used to build each
document (or all of the documents, in one operation, if so desired). MMS can
build a document by fetching files from one or more CMS libraries. Once a
document has been cOlnpleted and approved, you can issue commands to
DEC/CMS to "freeze" a particulat version of the document under a CMS-class
name you specify. You also have the ability to make the now-frozen version of a
doCument read-only, ie. unalterable by project members.

7-19
One of the things often done in this phase is rapid prototyping of target system
capabilities. The power of the Language Sensitive Editor and the various VAX
language implementations - VAX Ada or VAX BASIC, for example, can be beneficial in this phase. The symbolic debugger works with the VAX languages to
enable you to see actual source code in a window on your terminal-while you
are debugging code running in another window. VAX DATATRIEVE can help
with report generation during design. VAX COBOL has powerful
screen-handling and report-writing capabilities. The Shell and the Digital Command Language (DCL) have powerful utility programs which are also very helpful in prototyping some types of applications.
Data structures, file formats, and forms are frequently prototyped in this phase.
Many projects use the Common Data Dictionary to hold the definitions of
major data structures. The dictionary saves this information in a language-independent form, and a valid declaration can be extracted by many of
the VAX languages. This allows you to define a record structure, and access data
using it, from programs written in BASIC, COBOL, DATATRlEVE, FORTRAN,
ffiSCAL, or other languages-yet only a single declaration exists (in the dictionary). When building a system, DEC/MMS. is capable of checking declarations
stored in the Common Data Dictionary (CDD), and recompiling program modules which depend on records whose structure has been altered. Similarly, MMS
can check forms libraries to make sure that programs which depend on forms
are recompiled, if need be.
Designing the Software System with VAXlVMS
After the requirements for a software system are defined, you next start the
actual design of the system. As you will note in Figure 7 -5, more members of
your staff have become involved in the process. During this phase, further work
may be done to clarify the specification and the project plan, in addition to
writing a design document for the project. Programmer 4 writes test specifications, and the documentation specialist starts on the user-documentation plan.
All participate in design reviews.
With the VAX Language Sensitive Editor, you can create alld then use templates
for documentation formats and specifications. This eliminates the need to
retype boiler-plated sections of your document and promotes consistency
throughout your documentation - particularly when multiple team members
are involved.

PHASE I

ITEMS ON LINE FROM PRIOR PHASES

~
•

YOU

PROJECT

SENIOR

':~:

JUNIOR

'ii':

" '"
~l
~~

~~
~

IP~

PHASE
ASSIGNMENTS

~- ~

VAX
PROGRAM
DEVELOPMENT
ENVIRONMENT

~ s-

~1t

IbOC_PLN_R~

VAXTPU
EDT
DSR

VAX LANGUAGESENSITIVE EDITOR
VAX LANGUAGES
VMS DEBUGGER
VMS PROGRAM
DEVELOPMENT
UTILITIES
(LINKER)

Figure 7-5 • Phase 1 - Designing the Software System with VAXIVMS

design
document

test
specifications

documentation
plan

DEC/CMS
(Code
Management
System)

DEC/CMS libraries
stored from prior phases

PROTOTYPED
APPLICATION
SYSTEM
CODE

INPUT
DEC/MMS
(Module
Management
System)

DEC/MMS BUILDS
THE APPLICATION
PROGRAM, PROJECT
DOCUMENTATION, AND
THE USER DOC SET
FROM CMS LIBRARIES

OUTPUT

POINTERS TO CODE

PHASE I
PROJECT DOCUMENTATION

~
Figure 7-5 (Cant.) • Phase 1 - Designing the Software System with VAX/VMS

7-22 • Language and Tool Integration in the VAXIVMS
Software Development Environment

Above the pictures of your programmers in Figure 7-5 (not found in Figure
7-4) are "Items Online From Prior Phases". For example, a representation
of Phase 1 project documentation is there. This means the time-stamped
documentation you developed in Phase 1 is online, and accessible to everyone in your department.
Any project documentation developed in this phase (the design and documentation plans) or necessary corrections to Phase 1 documentation (after all, this
can be an evolutionary process) will be incorporated into Phase 1 project documentation . and become Phase 2 project documentation when Phase 2 is
finished.
(See Chapter 1 for a general overview of all these tools.)

Implementing the Software System With VAXlVMS
During the implementation phase (see Figure 7-6), you are making coordinated
use of many VMS tools. All the personnel in your department are now fully
involved in implementation of the software system. The design phase has been
completed, and during this time, code is written to build a product to the given
specifications.

7-23

PHASE II

ITEMS ON LINE FROM PRIOR PHASES

PHASE I
PROJECT
DOCUMENTATION

PHASE I
SOURCE CODE

~
~t'

';::j:,;,s

YOU

~Pf

PROJECT

.. SENIOR
.PR.

Jtiij.
MMER
...
.
C~

tJ.,

.~ ~

.g-§l
~

~~
t'rl~

PHASE
ASSIGNMENTS

;,s

'" ....o'
:;t.
~ ~.

VAX
PROGRAM
DEVELOPMENT
ENVIRONMENT

t:i s..

.... '"

VAXTPU
EDT
DSR

Figure 7-6· Phase 2 - Implementing the Software System With VAX/VMS

bEC/CMS
(Code
Management
System)

---------

-------------+1

I""'"~ I
DOCUMENTATION
LIBRARIES
(ClS1)

CODE
LIBRARIES
(ClS1)

Phase II
Source Code

Di;c/MMS
<Module ..•
Management
System)

. Pl)ase II
User Documentation Set

Phase II
Project Documentation

OUTPUT

~
Figure 7-6 (Cont.) • Phase 2 - Implementing the Software System With
VAX/VMS

7-26 • Language and Tool Integration in the VAX/VMS

Software Development Environment

Assignments for this phase are as follows - programmer 1,2,3, and 4 each
have to write a module of code, as outlined in the project document. Programmers 5 and 6, under your supervision, will start to write tests (These
will be incorporated into the DEC/Test Manager.) They will also develop an
online help facility. The writing of user documentation is in full swing during this phase_
Some of the most valuable tools used during this phase are the VAX language
compilers. These high-quality compilers all meet or exceed industry standards
and all have been designed as part of the VAX Common Language Architecture
(discussed in Chapter 1).
Often implementation is done in several stages or baselevels. Each base level
adds more of the specified features you are building into the software system.
Sometimes, several programmers work on the same module. Source code
changes can be easily controlled using the Reserve and Merge features of VAX
DEc/CMS.
The integrated use of various VAX language compilers, the VAX Language
Sensitive Editor, and the VAX Symbolic Debugger makes the
edit-compile-link-debug process much more efficient. The VAX Performance
and Coverage Analyzer finds performance bottlenecks in the emerging code
and ensures sufficient test coverage. Programmers can perform test procedures
quickly using the VAX DEC/Test Manager.
• VMS SERVICES IN THE IMPLEMENTATION PHASE
Operating system services and program development utilities are used extensively during the implementation phase. These features are the VMS system services, the VAX Runtime Library (RTL) , VAX Record Management Services
(RMS), and the VAX program development utilities (including the powerful VAX
Debugger).
VMS offers YQur programmers System Services and Run Time Library procedures that can be called by the software module they are writing. The Run
Time Library has procedures which include screen management,
terminal-independent 110, virtual memory management, and parsing routines,
in addition to the language and mathematics support procedures one expects.
VAX Record Management Services (RMS) makes @e access consistent and efficient, independent of which language you are programming in. Access to @es
can be limited thrQugh the use of VMS Access Control Lists (ACLs). The
powerful V.AX SORT utility allows you to order @es quickly and efficiently. This
combination of System Services, Run Time Library utility procedures, and @e
handling procedures allows your programmers (and your design and code
reviews) to. concentrate on routines that are unique to their project.

7-27

Programmers sometimes use the Digital Command Language (DeL) to write
tests, run tests; and prototype simple concepts_ If a programmer is accustomed
to a UNIX® -style environment, then VAX DEC/Shell provides them with a
Bourne Shell with which to interface to VMS, and to many UNIX-style utilities
(including pipes). The VAX DEC/Shell can be used as a script language for
prototyping.

• USING TIlE VAX LANGUAGE SENSITIVE EDTIOR DURING
IMPLEMENTATION
The VAX Language-Sensitive Editor is a high-performance, screen-oriented
editor with multiple windows and buffers for program devdopment.
Highlights of the VAX Language Sensitive Editor are listed bdow..
• The VAX Language Sensitive Editor lets you code, edit, compile, review, and
correct compilation errors within a single editing session. In review mode,
compilation errors are displayed in one window of the editor with the corresponding source code presented in the second window.
• The VAX Language Sensitive Editor gives you DeL-like line-mode commands
and a keypad layout .that makes it easy for users familiar with VAXTPU to
quickly become familiar with the VAX Language Sensitive Editor.
• The Language Sensitive Editor is fully integrated with VAX languages that
have been designed to the common language architecture. The ~tor has a
set of templates for the major constructs in each language. I"orexample, you.
can insert an IF statement in your favorite language into a source file by simply
typing IF and then a <CTRLIE> (for expand). A complete IF-tHEN-ELSE
block will then appearat the cursor. Now, just fill in the temp4te.
• The VAX Language Sensitive Editor also provides online language-oriented
hdp. For example, if you are editing a FORTRAN program and can't quite
remember how to spell that OPEN-statement keyword, you can request
online hdp for FORTRAN'and the OPEN statement. You can then deterome
the valid options, and insert them into your program without ever leaving the
, editor. .
.
• You can tailor· the editor to your own environment. You can provide thedefinition of a language, a memo header, or other textual templates to the editot:.
You can also change of add ddIDitions of the supported language and,tlli:refore,conform to a specifiedp~ogrIDmniDg convention:
. ,
.

®UNIX is.a registered trade mark of AT&T Bell Laboratories.

7-28 • Language and TootIntegration in the VAX!VMS

Software Development Environment

• USING VAX DEBUGGER IN TIlEIMPLEMENThTIONPHASE
The VAX Debugger is a powerful program development utility. It is designed to
work in cooperation with the other program development productivity tools
(VAX: Language Sensitive Editor, VAX DEC/'lfst Manager, and many of the VAX
languag~),

The VMS program debugging facility (DEBUGGER) is a powerful and flexible
tool that allows programmers to find errors in source code programs.
The DEBUGGER
• Is interactive. \bu can execute debugger commands from your terminal anel
see their effects immediately..

• Is symbolic. You can refer to program locations by the symbols you used for
them in your program.
• Supports many languages.~ You use th~debugger in the langqage of your
source program. If your application is written in more than one language, you
car;. change from one language to another in the course of a· debugging
session.

• R!rmits a variety of data forms and types for entty and display.
• Allows you to select and display your program's language statements.
• Has a screen mode that. provides multiple wfudows for screen-oriented
debugging.
• Has a debugger-defined keypad key definitions for your terminal's nUmeric
keypad.
• Gives online help.
.

. :

In DEBUGGER screen mode, you Can divide a terminal screen into several different windows and specify what you want to see in each window. For example,
• Create a window into the source file you are debugging.
•. Creat~'a window to track the change in specific variables through the debug
session.
Typically, one of those windows. is a source.. display. When DEBUGGER
encounterS Ii break po~, watch point, orex~tion condition, it 'displays. the
line of source code in whiCh that event oecurs(lllld several above and below it)
in the source window.
DEBUGGER also allow you scroll through information on the screen. You can
use the the terminal's arrow keys to move forward or backward through a window to revi~ information that has appeared in that space.

7-29

You can invoke the VAX Language Sensitive Editor from the Debugger. When
doing so, the cursor will be positioned on the current source code, unless you
specify differently, in edit mode. After you have corrected the error to the
source code, you can return to the DEBUGGER where you left off.
• USING DEc/CMS AND DEClMMS 10GETIIER 10 MANAGE
CHANGE DURING IMPLEMEN11\TION
Programmers use DEC/CMS(Code Management System) and DEC/MMS
(Module Management System) to manage the continually evolving software
system in this phase. With code stored in CMS libraries, programmers now have
a complete audit trail of every addition and change to the software system since
the first source code file was· included in the CMS library. Freezing baselevels
and then recreating those modules, while the code is still evolving, is essential to
reaching goals within time and budget.
Programmers use DECIModule Management System (MMS) to build and perfonn consistency checks on the system, DEC/MMS works in conjunction with
DEc/CMS (Code Management System). When building the system, DEC/MMS
only builds the parts of the system changed sinCe the last tinie it was built. MMS,
because it is integrated with the VMS operating system itself, builds your system
reliably using a minimum of CPU time. Keeping the MMS description file in a
CMS library allows it to evolve with the system too.
DEC/MMS, used with DEC/CMS, keeps all progranuilers working on the same
system without "version skew". Multiple versions of the software system can be
enhanced at the same time and are available to all programmers. Since it is so
easy to rebuild your system'(all you do is use a single MMS command) you can
always have an up-to-date version of your system available..
• USING RELATED VAX SOFTWARE PRQDUCTS IN
IMPLEMENTATION PHASE
DECnet-VAX software products allow you to connect multiple VAX systems
together and, therefore, increase your productivity_ Communication with
projects on other machines is possible with the VMS MAIL and PHONE utilities.
Files may be shared even though you are accessing them remotely, over a .
DECnet link. Testing software indifferent machine environments is made easier
by the SET HOST command, which allows you to log in to a remote system over
DECnet.
.
CONFIGURATION MANAGEMENT IN THE IMPLEMENTATION
PHASE WITH VAXIVMS - Because the implementation of a real software system is much more complex than the example presented here, you can quickly
see that managing this complexity in a "real" program development life cycle
can quickly become a challenge.

.7-30 • Language and Tool Integration in the VAXIVMS
Software DevekJpment Environment

Configuration Management of your system can't be automatically done on
VMS, but with careful planning and a solid program development meth9dology,you can use VMS tools to manage your software system's' configuration.
To do this, you will need to identifyall dfyour "configuration items" and put
them, or references to them, in a eMS library or libraries. MMS "description
files", descriptions of yotft up-to-date system, will need to be' written with ~are
and then updated as development' contim.les. You need, to. define where your
" tests are to be placed, where your documents are to be built,andthenyou can
use DEClMMS to martagethe configuration of your systein.

"The Development Plan, described in the Design Phase, is yourfrrst impq~t
step to managing this complexity.If you have a viable Development Plan, then
you can separate the implementation of specific features of your software sysintd discrete stages or baselevels.

tem

By using baselevels, you can build each new level of your system v.;ithout
r~building those you have.a1ready finished. This allows you to build each level

in in~ements, i.e. in discrete stages. You only have to manage the new features

of the next baselevel while the vAx management tools are taking care of the rest
of the system.
'
When a baselevel is reached, all the documentation and Source modules, the
MMS description file, the test cases, and the benchmark files are placed into
a eMS "class·, to identify precisely the content of each haselevel. The eMS
"dass" is then made read-only so that it cannot be changed inadvertently.
'fhe'MMS description file identifies the relationships between the modules
and can be set up so specific test ~ases are run when a module changes. The
eMS history file provides ,an audit trail of changes to the system. This adds
,traceability to your development process.
',

7-31

USING DEClMMS m DEVELOP TIMELY PROGRAM EXAMPLES IN
USER MANUALS - Your project may need to guarantee the accuracy of all program examples, output, or error messages included in the documentation set_
What the users find in the documentation should be the same as the program
example output or error messages they see on their terminals_ You can eliminate
the many hours spent revising such examples when programmers revise a program and forget to tell the writer, or the writer makes changes to an example to
improve its readability or style.
Using DEClMMS, we
• Extend the description file, ~aking the tested system (a null file used only for
its time of creation time-stamp) depend on all the system components_ The
actions to build the tested system are running DEC!fest Manager with all the
examples, and updating the time stamp file.
.
• Make the finished book depend on all the text files of the book and on the
examples produced by the testing. The actions to build the book include
running DSR The DSR source file has .REQUIRE statements to pull in the
examples (ie. test files).
You may need to process the test results before they can be put in the book. For
instance, you may want to enclose the example between .LITERAL and .END
UTERAL statements so DSR will not try to change the format. Or you might
want to discard a portion of the test output keeping only enough to demonstrate one point. That is easy too. Just write a small program in whatever language is convenient, and add a step to the description file which in~okes the
program. You might need to write several such small programs, hut the effort
will be repaid by the timeyou have made two or three drafts of each book
You can use this technique even if you do not have DEC/'kst Manager:. Simply
invoke your program with redirected input and output You should checl<: that
the results are reasonable, either by looking at them, or by having additional
programs validate the output.

Testing and Verifying the Software System with VAXlVMS
In order for the implementation phase to be completed, systemwide testing;
debugging, and in-house testing of the software must be completed. The soft:
ware system is considered a releasable product only when you are assured that it
has been thoroughly tested and works well for users under a variety of conditions_ Tests and syst~-builds should be integrated to make you as productive
as possible in this phase. Figure 7-7 helps you to understand this.

7-32 • Language and Tool Integration in the VAX/VMS

Software Development Envir.onment

Your programming staff's assignments are listed in the phase assignment row.
Programmers 1 and2 will continue to test and debug the software system: Programmers 3 and 4 have been assigned the task of building additional test<s for
the system. Many new problem areas in the system have been identified and
now require testing; Programmers 5 and 6 will continue to test and write text
for the online hdp facility. The.documentation specialist must incorporate
review comments into various manuals and prepare the documentation set for
Fidd Test wease. Fidd Test is the business of Phase 3; the intent is to make sure
that a software product which has been thoroughly tested in-house can perform
successfully in actual customer environments. H the software performs correctly, and the documentation is both accurate and hdpful, then the product
becomes a candidate for volume reproduction'and sale to the general customer
base.
Elements generated in Phase 2 are noW online for reference or furtherdevdopment (column 2).

7-33

PHASE III

ITEMS ON LINE FROM PRIOR PHASES

~
•

PHASE II SOURCE CODE
SENIOR

"~':

JUNIOR
PROGRAMMER

USER DOCUMENTATION

JUNIOR
PROGRAMMER

TRAINEE

DOCUMENTATION
SPECIALIST

~t'

~;::

~I><>

§~

'" '"
~~
'" "'~~
~ R.
~~

-lit
~~

DCl

'" !;.

I' s..~:

WRITE NEW TESTS,
TEST AND DEBUG

-'"

~
ONLINE HELP

I ·,

_ _ _-L.._ _--,

-.. '

•

REVIEW PCA
"AH

c==J
L=::J

I L=::J

PCA data will help you
determine what ·chaoges L - - - - - " 7
to the source code·
HELP
must be made, or w.. hat
LIBRARIES
new tests must be
(ClS1)
wntten

Figure 7-7· Phase 3 - Testing and Verifying the Software System with
VAX/VMS

TeSt Spec.

PROTOTYPE
CODE
MOD 1.C
MOD 2.C

HELP.RNH

~
~
VOL. 1

oJJ

DEC/CMS

PROjECT DOCUMENTATION
LlE\RAFlI.ES (CLS 1)

USER-DOCUMENTATION
SET LIBRARIES
(CLS 1)

SOURCE CODE
LlBFlARIES
(CLS1)

Phase III
Source Code

DECIMMS

DEC/MMS BUILDS
THE APPLICATION
PROGRAM, PROJECT
DOCUMENTATION, AND
.THEUSER DOC SET
FROM CMS I..IBRARIES

Phase III

Figure 7-7 (Cant) • Phase 3 -c- Testingand Verifying the Software System with
VAXIVMS

7-36 • Language and Tool Integration in the VAXIVMS

Software Development Environment

The VAXlVMS tools used in this phase are listed, vertically, along the left side
of the figure. We have already discussed the uses of many of these tools. They
all continue to be used for the same functions as in previous phases (for
ex;ample, the DEC/Test Manager still js used to manage regression-testing
even though the nature of those tests have changed). The VAX Performance
and Coverage Analyzer is extremely beneficial in analyzing how extensively
.
your systems' tests cover your entire system.

• USING TIIE VAX PERFORMANCE AND COVERAGE ANALY2ER
(PeA) 10 TEST AND VERIFY YOUR SOFIWARE SYSTEM
The VAX Performance and Coverage Analyzer uses VAXlVMS AST (asynchronous system traps) seMcesto sample the execution of events thai: occur in your
program at runtime. It then writes data regarding those ev.ents to a file. You can
then use the analyzer·portion of the· Performance and Coverage Analyzer to
format the data into diff~t types of output.
Analyzing the performl!l1ce of a program is done interactively. You can experiment with a number of different parameters until you find the information you
reatIy want. The VAX Performance and Coverage Analyzer provides performance coverage (PC) histograms, information on page-faults, system service calls
and 110 calls.
In the Performance and Coverage Analyzer's (PCA) .test-coverage analysis
mode, you can ask· for breakpoints on every routine, statement, or path in a
. program. Then, after progranlexecution, a command will show you how many
of those routines or statements were actually executed during tite execution of
the program. A project using the DECITest Manager can put PCA commands
into its DEC/'Iest Manager prologues and get coverage analysis while running
tests for validity of the product. The user can also ask for coverage while reviewing tests in theDEC/1est Manager.
.

• USING TIIE DEC(TEST MANAGER IN TIIE TESTING PHASE
When finishing a specific module, programmers will need to test then- code.
This testing is done over the entire implementation phase (and during the rest
of the life cyde).DE<::ffest Manager proVides for a single test system for the
entire project. It gives you the ability to select a subset of tests for checking only
part of a system and also can help you efficiendy review the results of those tests.

7·37

DEC/Test Manager
• Runs a collection of tests on your software system.
• Compares the output of each test it runs to output that are known to be
correct.
• Provides a set of commands that automatically helps your project members
execute a set of tests.
• Helps you quickly look at the results of those tests .
. Many times, when testing for a certain condition or feature, your programmers
may want to run one specific test with a combination of tests. With the
DECITest Manager, it is simple to collect those specific tests for a run, run them,
and review their results.
)bu can keep your test cases and benchmark @es in a CMS library so that those
tests can evolve with the system too. When you make a change to a system, you
add a test case(s) to test the change. You also re-run the other testcase(s) in your
test system to verify the change has not "broken" anything else.
When a bug is fixed, you create a test·case to demonstrate the bug and capture
the correct output Running these tests at a later date ensures that the bug stays
fixed.

Maintaining the Software System With VAXlVMS
From many programmer's point of view, the program development life cycle is
complete once the first four phases of the software system life cycle are completed. But you know much of the work (as much as 45 percent of it) on the
software system doesn't even start until you enter Phase4-volume production,
sale to customers, and maintenance of the product in the field.
Quite often, once a large project is completed, programmers who have done
most of the original design and coding work are put on other projects or seek
new career opportunities. Replacing key personnel is never an easy task. When
key programmers leave, they take a piece of your department. Therefore, to
maintain your department's high productivity level, you must maintain continuity in the skill level of all programmers. Doing this insutes that whomever
you hire to replace these programmers is not going to spend a year getting 'up
to speed" on the system and learning the software system. The DECIMMS
description @es, stored in a CMS library, contain .the infonhation or how to
build (or rebuild) the system as it currently exists, and how it existed at different
points in the project's history.

7-38 • Language and Tool Integration in the VAXIVMS

Software Development Environment

By using the VAXlVMS products outlined in this handbook, all your code, doc:
uments,'teSts, and test resultij have been stored in eMS libraries for easy retrieval
and reference. A new team member can easily use these hbraries to detennine
the' 'who; what, when and ,why' of all Wbrkdone for the first release of the
software syst~.

7-39

ITEMS ON LINE FROM PRIOR PHASES ..........,.,.,.~\,.,.,.,.,.

PHASE IV

USER
DOCUMENTATION
SET

~
~t

l'~
YOU

PROJECT
LEADER

SENIOR
PROGRAMMER

SENIOR

PR_.~~MMER

!;~

JUNIOR
JUNIOR
PROGRAMMER PROGRAMMER

TRAINEE

DOCUMENTATION
SPECIALIST

"~~'"

'" ~

~§'

..
'" ..§.

~ "-

'"~ ~
tr]~
~

i:l

~§'

~ ::; .

PHASE
ASSIGNMENTS

•

5S
~

Figure 7-8 • Phase 4 - Maintaining the Software System With VAX/VMS

1 Test Spec.

.1 Design Spec.
DEC/CMS

(Code

I Doc. Plan
I Require.

PROTOTYPI
CODE
MOD1.C

~
~
VOL. 1

D oJ

MOD 2.C

1 MOD 3.FOR
MOD 4.COB

Proj. Spec

--,-,-

Management
SY$tem)

HELP
LIBRARIES
(ClSl)

USER·DOCUMENTATION
SET LIBRARIES
(ClSl)

--. ,PROJECT DOCUMENTATION'
LIBRARIES (ClS 1)

INPUT
DEC/MMS
(Module
Management
Sy.stem)

LIBRARIES
(ClS 1)

____ VOL. 1

DEC/MMS REBUilDS
-----..'
~=-::...=:=--""
THE APPLICATION
.
PROGRAM, PROJECT
DOCUMENTATION, AND _____
.
THE USER DOC SET
~
-:- VOL. 2
FRO

MCMSLlBRARIE~~"
OUTPUT . '

~.:.
~

. .

;=0£
VOL. 3!!'=
iiii·-..

r~ I:llv:l

LJLJLJ

{j88
+G8G

Figure 7·8 (Cont.) • Phase 4 - Maintaining the Software System With
VAXIVMS

742 • Language and Tool Integration in the VAXIVMS
Software Development Environment

Let's take a brieflook (Figure 7-8) at your development department in Phase
4 of the software life cycle. The software system is now six-months old and in
use at several hundred 10cations~Already, you have requests to change one
of the software modules to add functionality not included in the first release
due to lack of time you had to spend on the project, cost constraints, or lack
of support from a related software system.
Often, development cycle$ are kept short deliberately. In this case, th~ initial
release will perform the basic functions required. It is expected' that after
release, customers will request functions that were not included. These features
are candidates for subsequent releases so that the system can evolve towards a
closer match with the customer's needs than would be possible if an attempt
was made to put everything in the initial release. This leads to Phase 0 for the
next version of the product, if it appears economically or strat~ically justifiable.
lOu can see that programmers' 1, 2, and 3 are working on the next software
system. We should mention here that you have recently brought programmer 4
into the department. Although he is not familiar with the software or your
department, he is able to b~ productive. He has a full history and audit trail of
the project's code alld internal documentation and can match it to the project.
The VAX Language-Sensitive Editor helps him with language templates and
walks him through the code. The DEClMMS description file describes the system for him. The tools have made it possiblefor him to pick up where the last
programmer 4 had left off.
Programmers 4, 5, and 6 will continue to make minor bug-fixes and general
housekeeping on the first release. The documentation specialist has to revise the
documentation set in much the same manner and issue change pages with the
software upgrade releases.
This software system may evolve over the next five or six years, maybe longer,
before it is replaced or retired. Therefore, it is essential that all records of
changes to project documentation, source code, and user documentation be
tracked over that entire period of time. R!rsonnel may come andgo, but an
audit trail of the whole evolution must be available.

• Conclusion
This chapter has shown you how a software development project can us~
Digital's VMS Productivity Enviromnent to your advantage.
The importance of developing software from an engineerillg perspective cannot
be minimized. Our VAX languages, VAX tools and and VMS program development utilities are designed to make you and your development staff software
eJlgineers. Our products will allow you to build a software system in a single
integrated enviromnent with the industry's best engineered products.