|
HP OpenVMS Systems Documentation |
|
OpenVMS Programming Concepts Manual
1.6.4 Using OpenVMS Utility RoutinesOpenVMS 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.
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 subset1 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.
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:
The Compaq DECwindows Motif for OpenVMS programming libraries provided include:
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.
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.
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.
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.
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:
RMS promotes safe and efficient file sharing by providing multiple
access modes, automatic record locking when applicable, and optional
buffer sharing by multiple processes.
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:
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.
Part 1
This part describes the creation, communication, and control of
processes. It also describes symmetric multiprocessing (SMP), and the
synchronizing of data access, programming operations, and access to
resources.
|
| 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) |
The execution context of a process defines a process to the system and includes the following:
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:
A process executes in one of the following modes:
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.
| 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.
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;
}
|
| Previous | Next | Contents | Index |