HP OpenVMS Systems Documentation
OpenVMS Version 7.3
$ SHOW MEMORY/FILES/FULL System Memory Resources on 22-MAY-2000 18:47:10.21 Swap File Usage (8KB pages): Index Free Size DISK$ALPHASYS:[SYS48.SYSEXE]SWAPFILE.SYS 1 904 904 Paging File Usage (8KB pages): Index Free Size DISK$ALPHASYS:[SYS48.SYSEXE]PAGEFILE.SYS 254 16888 16888 Total committed paging file usage: 1960
The new Multipath system services provide the capability to return path information and allow you to enable, disable, and switch specific I/O paths to any device.
The concept of multiple I/O paths to storage devices was introduced in OpenVMS Version 7.2-1. It is now possible to select more than one I/O path to a device in the event that the path in use should fail.
To assist in decision making when configuring a system's I/O structure, the following DCL commands were made available to allow you to display I/O path information and change the current settings affecting these paths:
In OpenVMS Version 7.3, the capability to return path information and allow you to enable, disable, and switch specific I/O paths to any device is now implemented in the following new system services:
For additional information, refer to the OpenVMS System Services Reference Manual.
5.8 Multiprocess Debugging (Alpha)
For Version 7.3, debugger support for multiprocess programs has been extensively overhauled. Problems have been corrected and the user interface has been improved.
The multiprocess debugging enhancements include the following features:
Execution of processes (or groups of processes)
Suspension of processes (or groups of processes)
Exiting processes (or groups of processes), with or without exit handler execution
These enhancements make it much easier to debug multiprocess programs.
5.9 Performance Application Programming Interface (API)
The Performance Application Programming Interface (API) provides a documented functional interface---the $GETRMI system service---that allows performance software engineers to access a predefined list of performance data items.
For more information about $GETRMI, refer to the OpenVMS System
5.10 POLYCENTER Software Installation Utility Enhancements
Table 5-1 shows the changes made to the product description language (PDL) for the POLYCENTER Software Installation utility.
|execute upgrade||New statement.|
|execute postinstall||Modified to execute on a reconfigure operation.|
|Refinements made to their conflict detection and resolution algorithms. For example, when a file from the kit contains the same non-zero generation number as the same file already installed, the file from the kit is selected to replace the file on disk. Previously, in this tie situation, the file on disk was retained to resolve the conflict.|
|Obsolete. However, the utility will continue to process these statements in a backward compatible manner to support existing kits that might have used them.|
|upgrade||Enhanced to fully support version range checking.|
The POLYCENTER Software Installation Utility Developer's Guide has been extensively revised for this release. Major improvements include:
OpenVMS Version 7.3 contains new tools for processing dump files. Note that these new-style process dump and process dump analysis tools are not compatible with the old-style process dumps. That is, if you have a problem you want to analyze with the new tools, you must generate a new process dump using the new process dump image.
The following sections describe the new tools.
5.11.1 DCL ANALYZE/PROCESS_DUMP Command
The DCL ANALYZE/PROCESS_DUMP command invokes the OpenVMS debugger to analyze a process dump, giving you access to debugger commands for your analysis. In OpenVMS Version 7.3, most of the old DCL ANALYZE/PROCESS_DUMP qualifiers have no effect. Only the /FULL and /IMAGE qualifiers are still valid. Both these qualifiers are still optional.
/FULL now causes the debugger to execute the debugger SHOW IMAGE, SHOW CALL, and SHOW THREAD/ALL commands after a process dump file has been opened.
/IMAGE has been renamed to /IMAGE_PATH, and is now a directory specification, rather than a file specification. /IMPAGE_PATH specifies a directory in which to look for the debug symbol information files (.DSF or .EXE files, in that order) that belong to the process dump file. The name of the symbol file must be the same as the image name in the process dump file. For example, for MYIMAGE.DMP, the debugger searches for file MYIMAGE.DSF or MYIMAGE.EXE.
Version 7.3 and later debuggers check for dumpfile image specification and DST file link date-time mismatches and issue a warning if one is discovered.
For more information about the DCL ANALYZE/PROCESS_DUMP command, refer
to the OpenVMS DCL Dictionary: A--M.
5.11.2 Debugger ANALYZE/PROCESS_DUMP Command
The debugger has a new command:
This command is available only in the kept debugger. The kept debugger is the image you invoke with the command DEBUG/KEEP, which allows you to run and rerun programs from the same debugging session.
The qualifier /PROCESS_DUMP is required.
For more information, refer to the OpenVMS Debugger Manual.
5.11.3 Debugger SDA Command
The new debugger SDA command invokes the System Dump Analyzer (SDA) to allow you to look at a process dump from within the OpenVMS debugger. For example:
DBG> SDA OpenVMS (TM) Alpha process dump analyzer SDA> .. . . SDA> EXIT DBG>
This allows you to use SDA to analyze a process dump without terminating a debugger session.
For more information, refer to the OpenVMS Debugger Manual.
5.11.4 Analyzing Process Dumps on Different Systems
You can analyze a process dump file on a system different from the one on which it was generated. However, if there is a base image link date/time mismatch between the generating system and analyzing system, you must copy SYS$BASE_IMAGE.EXE from the generating system and point to it with the SDA$READ_DIR logical name. For example:
$ COPY other_node::SYS$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE my_disk$:[my_dir] $ DEFINE/USER SDA$READ_DIR my_disk$:[my_dir],SYS$SYSROOT:[SYS$LDR],SYS$SYSROOT:[SYSLIB] $ ANALYZE/PROCESS_DUMP mycrash.dmp
For threaded process dump analysis on a system different from the one on which it was generated, it may also be necessary to copy and logically point to the generating system's PTHREAD$RTL and PTHREAD$DBGSHR (POSIX Threads Library debug assistant). For example:
$ COPY other_node::SYS$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE my_disk$:[my_dir] $ COPY other_node::SYS$SHARE:PTHREAD$RTL.EXE my_disk$:[my_dir] $ COPY other_node::SYS$SHARE:PTHREAD$DBGSHR.EXE my_disk$:[my_dir] $ DEFINE/USER SDA$READ_DIR my_disk$:[my_dir],SYS$SYSROOT:[SYS$LDR],SYS$SYSROOT:[SYSLIB] $ DEFINE/USER PTHREAD$RTL my_disk$:[my_dir]PTHREAD$RTL.EXE $ DEFINE/USER PTHREAD$DBGSHR my_disk$:[my_dir]PTHREAD$DBGSHR.EXE $ ANALYZE/PROCESS_DUMP mycrash.dmp
You can force a process dump with the DCL command SET PROCESS/DUMP=NOW process-spec. This command causes the contents of the address space occupied by process-spec to be written immediately to the file named image-name.DMP in the current directory (image-name is the same as the file name).
For more information about the DCL SET PROCESS/DUMP command, refer to
the OpenVMS DCL Dictionary: N--Z.
5.11.6 Process Dumps: Security and Diskquota Guidelines
A process dump is either complete or partial. A complete process dump contains all of process space and all process-pertinent data from system space. A partial process dump contains only user-readable data from process space and only those data structures from system space that are not deemed sensitive. Privileged or protected data, such as an encryption key in third-party software, might be considered sensitive.
In general, nonprivileged users should not be able to read complete process dumps, and by default they cannot do so. However, certain situations require nonprivileged users to be able to read complete process dumps. Other situations require enabling a user to create a complete process dump while at the same time preventing that user from being able to read the complete process dump.
By default, process dumps are written to the current default directory
of the user. The user can override this by defining the logical name
SYS$PROCDMP to identify an alternate directory path. Note that the name
of the process dump file is always the same as the name of the main
image at the time the process dump is written, with the file extension
18.104.22.168 Special Rights Identifiers
You can use the new rights identifier IMGDMP$READALL to allow a nonprivileged user to read a complete process dump. You can use the new rights identifier IMGDMP$PROTECT to protect a complete process dump from being read by the user that created the process dump. These rights identifiers are created during the installation of OpenVMS Version 7.3 by the image SYS$SYSTEM:IMGDMP_RIGHTS.EXE, which is also run automatically during system startup to ensure that these rights identifiers exist with the correct values and attributes.
If these rights identifiers have been deleted, you can run SYS$SYSTEM:IMGDMP_RIGHTS.EXE to recreate them. For example:
$ RUN SYS$SYSTEM:IMGDMP_RIGHTS %PROCDUMP-I-CREATED, rights identifier IMGDMP$READALL successfully created %PROCDUMP-I-CREATED, rights identifier IMGDMP$PROTECT successfully created
Note that IMGDMP$READALL has no attributes, but IMGDMP$PROTECT is
created with the RESOURCE attribute.
22.214.171.124 Privileged Users and Process Dumps
For this discussion, a privileged user is one who satisfies one of the following conditions:
Holders of CMKRNL or CMEXEC can write complete process dumps. Holders
of any of the other privileges can read a process dump wherever it has
126.96.36.199 Nonprivileged Users and Process Dumps
To allow a nonprivileged user to write and read complete process dumps, grant the rights identifier IMGDMP$READALL to the user. If the IMGDMP$READALL rights identifier does not exist, run the image SYS$SYSTEM:IMGDMP_RIGHTS.EXE to create it (see Section 188.8.131.52). Then use AUTHORIZE to grant the rights identifier to the user. For example:
$ DEFINE /USER SYSUAF SYS$SYSTEM:SYSUAF.DAT !if necessary $ RUN SYS$SYSTEM:AUTHORIZE UAF> GRANT /IDENTIFIER IMGDMP$READALL <user> UAF> EXIT
Note that the user must log out and log in again to be able to receive
the rights identifier. A nonprivileged user with rights identifier
IMGDMP$READALL can read and write complete process dumps without
184.108.40.206 Protecting Process Dumps
You can allow a nonprivileged user to write a complete process dump and at the same time prevent the user from reading the process dump just written. To do so, perform the following procedure:
$ CREATE /DIRECTORY DKA300:[PROCDUMPS] - /PROTECTION=(S:RWE,O:RWE,G,W) /OWNER_UIC=IMGDMP$PROTECT $ SET SECURITY DKA300:PROCDUMPS.DIR - /ACL=((DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:), - (IDENTIFIER=IMGDMP$PROTECT,ACCESS=READ+WRITE), - (IDENTIFIER=IMGDMP$PROTECT,OPTIONS=DEFAULT, - ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL), - (CREATOR,ACCESS=NONE))
$ DEFINE /SYSTEM /EXECUTIVE_MODE SYS$PROTECTED_PROCDMP DKA300:[PROCDUMPS]
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> DISKQUOTA CREATE /DEVICE=DKA300 ! if necessary SYSMAN> DISKQUOTA ENABLE /DEVICE=DKA300 ! if necessary SYSMAN> DISKQUOTA ADD IMGDMP$PROTECT /DEVICE=DKA300 /PERMQUOTA=10000 SYSMAN> DISKQUOTA REBUILD /DEVICE=DKA300 ! if necessary SYSMAN> EXIT
Do not grant IMGDMP$PROTECT to any user. It is granted and revoked as needed by SYS$SHARE:IMGDMP.EXE from executive mode while writing a process dump. If you grant it permanently to a user, that user has access to all process dumps written to the protected directory.
You can choose to set up additional ACLs on the protected directory to further control which users are allowed to read and write process dumps there.
Note that to take a process dump when the image is installed with
elevated privileges or belongs to a protected subsystem, the user must
hold CMKRNL privilege, and is by definition a privileged user (see
5.12 RMS Locking Enhancements
This section introduces the new Record Management Services (RMS)
enhancements provided in this release.
5.12.1 RMS Locking Performance Enhancements (Alpha)
The following sections describe RMS locking performance enhancements
that are in OpenVMS Alpha Version 7.2-1H1 and in OpenVMS Version 7.3.
220.127.116.11 RMS Global Buffer Read-Mode Locking
In the RMS run-time processing environment, the use of global buffers
can minimize I/O operations for shared files. This release introduces
read-mode bucket locking that minimizes locking for shared access to
global buffers. This new functionality:
This new functionality applies to read operations (using the $GET and $FIND services) for all three file organizations: sequential, relative, and indexed. It also applies to a write operation (using the $PUT service) for the read accesses used for index buckets the first time through an index tree for the write.
You do not need to make changes to existing applications to implement the read-only global bucket locks. However, global buffers must be set on a data file to take advantage of the enhancement. Use the following DCL command, where n is the number of buffers:
$ SET FILE/GLOBAL_BUFFER=n <filename>
For information about specifying the number of buffers, refer to the OpenVMS DCL Dictionary. For general information about using global buffers, refer to the section entitled Using Global Buffers for Shared Files in the Guide to OpenVMS File Applications.
In a mixed cluster environment where there may be high contention for specific buckets, the Alpha nodes that are using read-mode global bucket locking may dominate accesses to write-shared files, thereby preventing timely access by other nodes.
With the new /CONTENTION_POLICY=keyword qualifier to the SET RMS_DEFAULT command, you can specify the level of locking fairness at the process or system level for environments that experience high contention conditions.
For more information about using the
/CONTENTION_POLICY=keyword qualifier, refer to the SET
RMS_DEFAULT section of the OpenVMS DCL Dictionary.
18.104.22.168 No Query Record Locking Option
In previous releases, if a file is opened allowing write sharing, an exclusive record lock is taken out for all record operations (both read and write). Applications may obtain record locking modes other than the exclusive lock (default) by specifying certain options to the RAB$L_ROP field. However, all the options involve some level of record locking. That is, the options require $ENQ or $DEQ system service calls to the Lock Manager.
The user record locking options include the RAB$V_NLK (no lock) query locking option, which requests that RMS take out a lock to probe for status and not hold the lock for synchronization. If the lock is not granted (exclusive lock held) and the read-regardless (RAB$V_RRL) option is not set, the record access fails with an RMS$_RLK status. Otherwise, the record is returned with one of the following statuses:
When only the RAB$V_NLK option is specified, record access can be denied. When both the RAB$V_NLK and RAB$V_RRL options are specified, an application can guarantee the return of any record with a success or alternate success status.
This release introduces the no query record locking option, which allows applications to read records (using $GET or $FIND services) without any consideration of record locking. This option:
This functionality is independent of bucket locks. It applies to both local and global buffers and to all three file organizations (sequential, relative, and indexed).
Three alternate methods for specifying the no query record locking option are outlined in Table 5-2.
Note the following:
|To...||Use This Method...|
|Disable query record locking at the process or system level.||
Enter the following DCL command to request that RMS use no query record
locking for any read operation with both RAB$V_NLK and RAB$V_RRL
options set in the RAB$L_ROP field:
$ SET RMS_DEFAULT/QUERY_LOCK=DISABLE[/SYSTEM]
Keys on RAB$V_NLK and RAB$V_RRL options in existing applications.
|Enable no query record locking on a per-record read operation.||
Set the RAB$V_NQL option in the RAB$W_ROP_2 field.
The RAB$V_NQL option takes precedence over all other record locking options. Use only if the current read ($GET or $FIND) operation is not followed by an $UPDATE or $DELETE call.
|Enable no query record locking at the file level.||
Set the FAB$V_NQL option in the FAB$B_SHR field to request that RMS use
no query locking for the entire period the file is open for any read
record operation with both RAB$V_NLK and RAB$V_RRL options set in the
This option can be used with any combination of the other available FAB$B_SHR sharing options. Keys on RAB$V_NLK and RAB$V_RRL options in applications.
RMS precedence for the no query record locking option is as follows: