Document revision date: 30 March 2001

OpenVMS programs can access some OpenVMS utilities through callable interfaces. Utility routines enable programs to invoke the utility, execute utility-specific functions, and exit the utility, returning to the program. Table 1-7 lists the OpenVMS utility routines.

Table 1-7 OpenVMS Utility Routines

Routine	Utility/Facility
ACL$	Access control list editor (ACL editor)
CLI$	Command Definition Utility (CDU)
CONV$	Convert and Convert/Reclaim utilities (CONVERT and CONVERT/RECLAIM)
DCX$	Data Compression/Expansion facility (DCX)
EDT$	EDT editor
FDL$	File Definition Language utility (FDL)
LBR$	Librarian utility (LIBRARIAN)
LGI$	LOGINOUT routines
MAIL$	Mail utility (MAIL)
NCS$	National Character Set utility (NCS)
PSM$	Print Symbiont Modification facility (PSM)
SMB$	Symbiont/Job-Controller Interface facility (SMB)
SOR$	Sort/Merge utility (SORT/MERGE)
TPU$	DEC Text Processing Utility (DECTPU)

You can use an optional, portable library of user-callable routines to perform high-performance sorting on OpenVMS Alpha systems. The high-performance sort supports a subset¹ of the functionality present on the OpenVMS Sort/Merge utility, using the callable interface to the SOR$ routine. The high-performance sort/merge provides better performance for most sort and merge operations.

1.7 Programming User Interfaces

User interfaces to the OpenVMS VAX and OpenVMS Alpha operating systems include the DCL interface and the optional Compaq DECwindows Motif for OpenVMS graphical user interface. Another user interface is through electronic forms.

You can use DCL commands to invoke program development software (compilers, editors, linkers) and to run and control execution of programs. You can use DCL command procedures to perform repetitious operations in software development.

The Command Definition utility (CDU) enables application developers to create DCL-level commands with a syntax similar to OpenVMS DCL commands. Using CDU, the developer can create applications with user interfaces similar to those of operating system applications. The Message utility permits an application developer to create application messages to supplement the system messages supplied by the OpenVMS operating system.

The Compaq DECwindows Motif for OpenVMS software provides a consistent user interface for developing software applications and includes an extensive set of programming libraries and tools. Compaq DECwindows Motif for OpenVMS supports both the OSF/Motif standards-based graphical user interface and the X user interface (XUI) in a single run-time and development environment. Compaq DECwindows Motif for OpenVMS for OpenVMS Alpha requires a DECwindows X11 display server (device driver and fonts) that supports the portable compiled format (PCF), permitting use of vendor-independent fonts.

An applications programmer can use the following Compaq DECwindows Motif for OpenVMS software to construct a graphical user interface:

• A user interface toolkit composed of graphical user interface objects (widgets and gadgets); widgets provide advanced programming capabilities that permit users to create graphic applications; gadgets, similar to widgets, require less memory to create labels, buttons, and separators
• A user interface language to describe visual aspects of objects (menus, labels, forms) and to specify changes resulting from user interaction
• The OSF/Motif Window Manager, which allows users to customize the interface

The Compaq DECwindows Motif for OpenVMS programming libraries provided include:

• Standard X Window System libraries such as Xlib and the intrinsics
• Libraries needed to support the current base of XUI applications
• OSF/Motif toolkit support for developing applications using the Motif user interface style
• Digital libraries that give users capabilities beyond the standards

Also included in the Compaq DECwindows Motif for OpenVMS environment are DEClinks services for creating, managing, and traversing informational links between different application-specific data. DEClinks services, with the DEClinks Manager application, help organize information into a hyperinformation environment. DEClinks Developer's Tools provide a development environment for creating, modifying, and maintaining hyperapplications.

1.8 Developing Real-Time Applications

The VAXELN Toolkit is a set of tools that can be used on VAX systems running OpenVMS to develop efficient real-time applications (for example, real-time applications for process control, simulation, or high-speed data acquisition). VAXELN real-time applications are run on rtVAX computers. The VAXELN real-time operating environment optimizes dedicated real-time systems for predictability and fast response time. VAXELN transparently supports open standards such as IEEE 1003.1 and IEEE 1003.1b (previously 1003.4). VAXELN operates in TCP/IP and DECnet local and wide area networks.

1.9 Optional Compaq Software Development Tools

Compaq supplies optional software development tools for the OpenVMS environment, such as DECset. DECset is a set of tools that supports software coding, testing, and maintenance of applications and data. These tools can be used individually or as part of the optional Compaq software development environment.

1.10 Managing Data

The basic OpenVMS tool for transparent, intuitive management of data is the Record Management Services (RMS) subsystem. RMS is a collection of routines that gives programmers a device-independent method for storing, retrieving, and modifying data for their application. RMS also provides extensive protection and reliability features to ensure data integrity.

RMS is a higher level interface to the file system and OpenVMS I/O subsystem. It is used by all products that run on OpenVMS VAX and OpenVMS Alpha for file and record operations. A subset of RMS services permit network file operations that are generally transparent to the user.

On OpenVMS Alpha systems, RMS supports I/O operations to and from 64-bit addressable space.

1.10.1 RMS Files and Records

RMS supports a variety of file organizations, record formats, and record-access modes. RMS supports sequential, relative, and indexed disk file organizations, and fixed- and variable-length records. It supports a number of record-access modes: sequential, by key value, by relative record number, or by record file address. RMS is designed primarily for mass storage devices (disks and tapes), but also supports unit-record devices such as terminals or printers.

RMS routines assist user programs in processing and managing files and their contents. RMS routines perform these services for application programs:

• Creating new files, accessing existing files, extending disk space for files, closing files, and obtaining file characteristics
• Getting, locating, inserting, updating, and deleting records in files

RMS promotes safe and efficient file sharing by providing multiple access modes, automatic record locking when applicable, and optional buffer sharing by multiple processes.

1.10.2 RMS Utilities

RMS file utilities allow users to analyze the internal structure of an RMS file and to determine the most appropriate set of parameters to tune an RMS file. RMS utilities can also be used to create, efficiently load, and reclaim space in an RMS file.

RMS file maintenance utilities include the following:

• Analyze/RMS_File utility
• File Definition Language utilities (Create/FDL and Edit/FDL)
• Convert and Convert/Reclaim utilities

The Analyze/RMS_File utility allows the programmer to analyze the internal structure of an OpenVMS RMS file and generate a report on its structure and use, as well as interactively explore the file's structure. The utility can generate an FDL file from an RMS file for use with the Edit/FDL utility to optimize the data file.

File Definition Language (FDL) is a special-purpose language for specifying file characteristics; it is useful with higher level languages or for ensuring that files are properly tuned. FDL makes use of RMS control blocks: the file access block (FAB), the record access block (RAB), and the extended attribute block (XAB).

The Edit/FDL utility creates a new FDL file according to user specifications. The Create/FDL utility uses the specifications of an existing FDL file to create a new empty data file.

You can use the Convert utility to copy records from one file to another, while changing the record format and file organization, and to append records to an existing file. The Convert/Reclaim utility reclaims empty bucket space in an indexed file to allow new records to be written to it.

This chapter describes process creation and the different types of processes. It also describes kernel threads and the kernel threads process structure. This chapter contains the following sections:

Section 2.1 defines a process and describes the two types of processes.

Section 2.2 describes the execution context of a process.

Section 2.3 describes the modes of execution of a process.

Section 2.4 describes the creation of a subprocess.

Section 2.5 describes the creation of a detached process.

Section 2.6 describes the creation and use of process quota lists (PQLs).

Section 2.7 describes debugging within a subprocess and a detached process.

Section 2.8 describes kernel threads and the parts that make up the kernel threads process.

2.1 Process Types

A process is the environment in which an image executes. Two types of processes can be created with the operating system: spawned subprocesses or detached processes.

A spawned subprocess is dependent on the process that created it (its parent), and receives a portion of its parent process's resource quotas. The system deletes the spawned subprocess when the parent process exits.

A detached process is independent of the process that created it. The process the system creates when you log in is, for example, a detached process. If you want a created process to continue after the parent exits, or not to share resources with the parent, use a detached process.

Table 2-1 compares the characteristics of subprocesses and detached processes.

Table 2-1 Characteristics of Subprocesses and Detached Processes

Characteristic	Subprocess	Detached Process
Privileges	Received from creating process	Specified by creating process
Quotas and limits	Shared with creating process	Specified by creating process, but not shared with creating process
User authorization file	Used for information not given by creating process	Used for most information not given by creating process
User identification code	Received from creating process	Specified by creating process
Restrictions	Exist as long as creating process exists	None
How created	SYS$CREPRC, or LIB$SPAWN from another process	SYS$CREPRC from another process
When deleted	At image exit, or when creating process exits. Note that if you use SYS$CREPRC in place of LIB$SPAWN, the context of the parent process is not propogated into the subprocess.	At image exit. Note that a LIB$SPAWN routine can fail in a detached process because it is dependent upon and requires the presence of a command language interpreter (CLI).
Command language interpreter (CLI) present	Usually not if created with SYS$CREPRC; usually yes if spawned	Usually not (though interactive user processes have CLI present, and they are created with SYS$CREPRC)

2.2 Execution Context of a Process

The execution context of a process defines a process to the system and includes the following:

• Image that the process is executing
• Input and output streams for the image executing in the process
• Disk and directory defaults for the process
• System resource quotas and user privileges available to the process

When the system creates a detached process as the result of a login, it uses the system user authorization file (SYSUAF.DAT) to determine the process's execution context.

For example, the following occurs when you log in to the system:

1. The process created for you executes the image LOGINOUT.
2. The terminal you are using is established as the input, output, and error stream device for images that the process executes.
3. Your disk and directory defaults are taken from the user authorization file.
4. The resource quotas and privileges you have been granted by the system manager are associated with the created process.
5. A command language interpreter (CLI) is mapped into the created process.

A process executes in one of the following modes:

• Interactive---Receives input from a record-oriented device, such as a terminal or mailbox
• Batch---Is created by the job controller and is not interactive
• Network---Is created by the network ancillary control program (ACP)
• Other---Is not running in any of the other modes (for example, a spawned subprocess where input is received from a command procedure)

You can create a subprocess using either the LIB$SPAWN run-time library routines, the SYS$CREPRC system service, or the C system () call. A subprocess created with LIB$SPAWN is called a spawned subprocess.

Table 2-2 lists the context values provided by LIB$SPAWN, SYS$CREPRC, and the C system () call for a subprocess when you are using the default values in the routine calls.

Table 2-2 Comparison of LIB$SPAWN, SYS$CREPRC, and C system : ( ,) Call Context Values

Context	LIB$SPAWN	SYS$CREPRC	C system ()
DCL	Yes	No 1	Yes
Default device and directory	Parent's	Parent's	Parent's
Symbols	Parent's	No	Parent's
Logical names	Parent's 2	No 2	Parent's 2
Privileges	Parent's	Parent's	Parent's
Priority	Parent's	0	Parent's

The LIB$SPAWN routine enables you to create a subprocess and to set some context options for the new subprocess. LIB$SPAWN creates a subprocess with the same priority as the parent process (generally priority 4). The format for LIB$SPAWN is:

LIB$SPAWN ([command_string],[input_file],
,[output_file],[flags],[process-name],[process_id],[completion_status]
,[completion_efn],[completion_astadr],[completion_astarg],[prompt],[cli])

For complete information on using each argument, refer to the LIB$SPAWN routine in OpenVMS RTL Library (LIB$) Manual.

Specifying a Command String

Use the command_string argument to specify a single DCL command to execute once the subprocess is initiated. You can also use this argument to execute a command procedure that, in turn, executes several DCL commands (@command_procedure_name).

Redefining SYS$INPUT and SYS$OUTPUT

Use the input_file and output_file arguments to specify alternate input and output devices for SYS$INPUT and SYS$OUTPUT. Using alternate values for SYS$INPUT and SYS$OUTPUT can be particularly useful when you are synchronizing processes that are executing concurrently.

Passing Parent Process Context Information to the Subprocess

Use the flags argument to specify which characteristics of the parent process are to be passed on to the subprocess. With this argument, you can reduce the time required to create a subprocess by passing only a part of the parent's context. You can also specify whether the parent process should continue to execute (execute concurrently) or wait until the subprocess has completed execution (execute in line).

After the Subprocess Completes Execution

Use the completion_status, completion_efn, and completion_astadr arguments to specify the action to be taken when the subprocess completes execution (send a completion status, set a local event flag, or invoke an AST procedure). For more information about event flags and ASTs, refer to Chapter 8.

The LIB$SPAWN routine and SPAWN command do not return a completion status code of 0 from a subprocess command procedure.

The LIB$SPAWN routine can fail in a detached process as well, because it is dependent upon and requires the presence of a command language interpreter (CLI), such as DCL. Without a CLI present in the current process, this call fails with a "NOCLI, no CLI present to perform function" error. Note that a detached process typically does not have a CLI present.

You can use SYS$CREPRC in place of LIB$SPAWN; though with SYS$CREPRC the context of the parent process (symbols and logical names) is not propogated into the subprocess.

When using LIB$SPAWN asynchronously (with CLI$M_NOWAIT), you have to synchronize completion. For if the parent process should exit, all subprocesses exit, potentially resulting in an unexpected series of failures of all subprocesses of the exiting parent process.

Specifying an Alternate Prompt String

Use the prompt argument to specify a prompt string for the subprocess.

Specifying an Alternate Command Language Interpreter

Use the cli argument to specify a command language interpreter for the subprocess. To create a detached process with a cli, you must either specify LOGINOUT as the target image, or use calls from images that are running in an "interactive", "batch", or "other" mode process.

Examples of Creating Subprocesses

The following examples create a subprocess that executes the commands in the COMMANDS.COM command procedure, which must be a command procedure on the current default device in the current default directory. The created subprocess inherits symbols, logical names (including SYS$INPUT and SYS$OUTPUT), keypad definitions, and other context information from the parent. The subprocess executes while the parent process hibernates.

! Declare status and library routine INTEGER STATUS, LIB$SPAWN STATUS = LIB$SPAWN ('@COMMANDS')

The equivalent C code follows:

#include <descrip.h> #include <lib$routines.h> #include <ssdef.h> #include <stsdef.h> main() { int RetStat; $DESCRIPTOR( CmdDsc, "@COMMANDS" ); RetStat = lib$spawn( &CmdDsc ); if (!$VMS_STATUS_SUCCESS( RetStat )) return RetStat; return SS$_NORMAL; }

The following Fortran program segment creates a subprocess that does not inherit the parent's symbols, logical names, or keypad definitions. The subprocess reads and executes the commands in the COMMANDS.COM command procedure. (The CLI$symbols are defined either in the $CLIDEF module of the system object or in shareable image library. See Chapter 26 for more information.)

! Mask for LIB$SPAWN INTEGER MASK EXTERNAL CLI$M_NOCLISYM, 2 CLI$M_NOLOGNAM, 2 CLI$M_NOKEYPAD ! Declare status and library routine INTEGER STATUS, LIB$SPAWN ! Set mask and call LIB$SPAWN MASK = %LOC(CLI$M_NOCLISYM) .OR. 2 %LOC(CLI$M_NOLOGNAM) .OR. 2 %LOC(CLI$M_NOKEYPAD) STATUS = LIB$SPAWN ('@COMMANDS.COM', 2 ,, 2 MASK)

The equivalent C program follows:

#include <clidef.h> #include <descrip.h> #include <lib$routines.h> #include <ssdef.h> #include <stsdef.h> main() { int RetStat; int FlagsMask = CLI$M_NOCLISYM | CLI$M_NOLOGNAM | CLI$M_NOKEYPAD; $DESCRIPTOR( CmdDsc, "@COMMANDS.COM" ); RetStat = lib$spawn( &CmdDsc, 0, 0, &FlagsMask ); if (!$VMS_STATUS_SUCCESS( RetStat )) return RetStat; return SS$_NORMAL; }

The following Fortran program segment creates a subprocess to execute the image $DISK1:[USER.MATH]CALC.EXE. CALC, reads data from DATA84.IN, and writes the results to DATA84.RPT. The subprocess executes concurrently. (CLI$M_NOWAIT is defined in the $CLIDEF module of the system object or shareable image library; see Chapter 26.)

! Mask for LIB$SPAWN EXTERNAL CLI$M_NOWAIT ! Declare status and library routine INTEGER STATUS, LIB$SPAWN STATUS = LIB$SPAWN ('RUN $DISK1:[USER.MATH]CALC', ! Image 2 'DATA84.IN', ! Input 2 'DATA84.RPT', ! Output 2 %LOC(CLI$M_NOWAIT)) ! Concurrent

The C version of the example follows:

#include <clidef.h> #include <descrip.h> #include <lib$routines.h> #include <ssdef.h> #include <stsdef.h> main() { int RetStat; int FlagsMask = CLI$M_NOWAIT; $DESCRIPTOR( CmdDsc, "RUN $DISK1:[USER.MATH]CALC" ); $DESCRIPTOR( InpDsc, "DATA84.IN" ); $DESCRIPTOR( OutDsc, "DATA84.RPT" ); RetStat = lib$spawn( &CmdDsc, &InpDsc, &OutDsc, &FlagsMask ); if (!$VMS_STATUS_SUCCESS( RetStat )) return RetStat; return SS$_NORMAL; }

	privacy and legal statement
5841PRO_003.HTML