Document revision date: 19 July 1999
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS Version 7.2 Release Notes

Previous Contents Index

5.19 Privileged Interfaces and Data Structures (Alpha Only)

This section contains release notes concerning privileged code and data structures.

5.19.1 Changes and Enhancements

The following sections describe changes that affect privileged code. Per-Thread Security and Backward Compatibility


The security information previously stored in several data structures has moved to a new Persona Security Block (PSB) data structure, making the relevant fields in those structures obsolete in OpenVMS Version 7.2. The affected structures include the Access Rights Block (ARB), Process Control Block (PCB), Process Header Descriptor (PHD), Job Information Block (JIB), and Process Control (CTL) region fields.

Table 5-1 shows the obsolete data cells and where the information in those cells has moved.

For single persona execution within a process, the obsolete data cells1 are maintained for backward compatibility. The cells are not maintained while a process is executing with multiple user-level personae (because any code checking the old cells would likely make the wrong security decision).


A process is created with a single user-mode security profile known as the natural persona. Backward compatibility based on the current value of the new SYSGEN parameter ARB_SUPPORT, which defines the level of backward compatibility between the obsolete cells and the new PSB data structure, is maintained while the process remains in this user-mode persona state. (See the OpenVMS System Management Utilities Reference Manual for information about the ARB_SUPPORT parameter.)

Backward compatibility is not supported when multiple user-mode persona exist. Multiple user-mode persona are created using the $PERSONA_CREATE system service.

Backward compatibility of the obsolete data cells might not be maintained in future releases of OpenVMS. Writers of privileged code are encouraged to search for the obsolete symbols in their code and make the necessary modifications to remove the code's dependence on the obsolete cells, and to get the information from the new locations.

Table 5-1 Obsolete Data Cells and New Location of Security Information
Obsolete Data Cell New Location
ARB$L_CLASS PSB$AR_CLASS (Not supported 1)
ARB$L_RIGHTSLIST PSB$AR_RIGHTS (array of rights chains pointers) --- Persona, image, and system rights chains
ARB$Q_PRIV (Working privileges logically OR'd with image privileges) PSB$Q_WORKPRIV, PSB$Q_IMAGE_WORKPRIV
PHD$Q_PRIVMSK PSB$Q_WORKPRIV, PSB$Q_IMAGE_WORKPRIV --- Working privileges logically OR'd with image privileges (PSB)
PHD$R_MAX_CLASS PSB$AR_CLASS (Not supported 1)
PHD$R_MIN_CLASS PSB$AR_CLASS (Not supported 1)

1OpenVMS Version 7.2 does not maintain the structures to support MAC (mandatory access checking) in a level B1 security environment.
2Security information within this cell is not backward compatible because the JIB is shared among all processes in a job tree. Privileged Code Changes at Version 7.0


Privileged-code applications that were recompiled and relinked to run on OpenVMS Alpha Version 7.0 do not require source-code changes and do not have to be recompiled and relinked to run on OpenVMS Alpha Version 7.1 and later.

Privileged-code applications from releases prior to OpenVMS Alpha Version 7.0 that were not recompiled and relinked for OpenVMS Alpha Version 7.0 must be recompiled and relinked to run on OpenVMS Alpha Version 7.1 and later.

OpenVMS Alpha Version 7.0 included significant changes to OpenVMS Alpha privileged interfaces and data structures. As a result of these changes, privileged-code applications from releases prior to OpenVMS Alpha Version 7.0 might require source-code changes to run correctly on OpenVMS Alpha Version 7.0 and later. For more details about OpenVMS Alpha Version 7.0 changes that may require source changes to privileged-code applications, refer to the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications.

For information about recompiling and relinking device drivers, see Chapter 6.

5.19.2 Problems and Restrictions

The following release note describes how per-thread security impacts privileged code and device drivers. Per-Thread Security Impacts Privileged Code and Device Drivers


The method used for attaching a security profile to the I/O Request Packet (IRP) has changed.

In previous versions of OpenVMS, the address of the processwide Access Rights Block (ARB) security structure was copied directly into the IRP. Beginning with OpenVMS Alpha Version 7.2, the address of the new security profile structure (Persona Security Block, or PSB) of the thread making the I/O request is moved into the IRP.

The I/O subsystem maintains its access to the PSB through a reference counter. The I/O subsystem increments this reference counter at IRP creation and decrements the counter at I/O completion. When the counter reaches zero, the PSB is deleted from the system.

Device drivers that created copies of IRPs to facilitate multiple I/O operations per request, and subsequently pass the copied IRPs to the I/O subsystem for postprocessing, must make code changes to account for the extra dereferences to the PSB that result. This is done by calling NSA_STD$REFERENCE_PSB and passing the PSB address located in the copied IRP before I/O postprocessing of the IRP copy. The include file and routine call for NSA_STD$REFERENCE_PSB is as follows:

 #include <security-macros.h> 
 /* Increment REFCNT of PSB that is now shared by both IRPs  */ 
 nsa_std$reference_psb( irp->irp$ar_psb ); 

Device drivers need to make this change under the following conditions:

Failure to call NSA_STD$REFERENCE_PSB in these circumstances will result in corrupt tracking information within the PSB, which can result in system crashes.

If you make code changes in a device driver to call NSA_STD$REFERENCE_PSB, you must recompile and relink the driver to run on OpenVMS Version 7.2.


1 Security information within the JIB (JIB$T_ACCOUNT, the account cell) is not backward compatible because the JIB is shared among all processes in a job tree. Modifying the JIB user-name cell (JIB$T_USERNAME) in a multiprocess job tree can adversely affect other processes in that job tree.

5.20 Record Management Services (RMS)

This section contains release notes pertaining to RMS.

5.20.1 Changes and Enhancements

The following notes describe enhancements to RMS. Ellipsis Processing of [000000...] Now Finds All Files


Prior to OpenVMS Version 7.2, an ellipsis search specification starting with the master file directory (MFD) (that is, [000000...]) would cause RMS, after returning all files in the MFD, to begin ellipsis processing with the first subdirectory whose name sorts alphanumerically after 000000.DIR. Subdirectory trees beginning with directories whose names sort before 000000.DIR would be skipped.

With the introduction of support for Extended File Specifications, which makes the creation of such directory names a more common event, RMS now begins its ellipsis processing of [000000...] with the first directory found, not the first directory that sorts before the MFD itself. Therefore, this search specification can now be used to return all files located on the specified device. Circular Directory Path Detection (Alpha Only)


Circular directory paths result when a SET FILE/ENTER command enters the directory name of a higher-level directory into a lower directory in its subdirectory tree. Prior to Version 7.2, such a directory tree appeared circular to RMS during ellipsis processing (for example, when processing a specification such as [A...]) because RMS did not detect that a directory's directory ID (DID) resulting from a SET FILE/ENTER command had already been encountered higher up in the path.

In earlier releases, an 8-deep directory limit inhibited RMS from looping while following a potentially infinite circle of DIDs. With the introduction of deep directories in OpenVMS Version 7.2, the 8-deep directory limit has been removed. In this release, RMS has been enhanced to detect when a node in the path initiates a circle. Instead of looping, RMS now treats such a node as if it were the lowest element in the current branch of the path. Directory Cache Limits Removed


During most wildcard searches, RMS caches the target directory file in memory to optimize calls to the file system. Prior to this release, the maximum size of a directory file that RMS would cache was 127 blocks; wildcard lookups to larger directories would go directly to the file system.

Beginning with Version 7.2, RMS attempts to cache directories of any size. If memory or other resources are not available to cache the file, wildcard lookups are then directed to the file system.

5.21 Run-Time Library (LIB$)

This section contains release notes pertaining to the Run-Time Library (LIB$).

5.21.1 Problems and Restrictions

This section describes known LIB$ RTL problems and restrictions. LIB$FIND_IMAGE_SYMBOL Signals Warning for Modules with Compilation Errors


LIB$FIND_IMAGE_SYMBOL may signal a warning (LIB$_EOMWARN) to indicate that the image being activated contains modules that had compilation warnings. A condition handler used with LIB$FIND_IMAGE_SYMBOL should probably handle this as a special case.

To allow LIB$FIND_IMAGE_SYMBOL to continue execution after signaling LIB$_EOMWARN, the condition handler should exit with SS$_CONTINUE. For this reason, you may choose not to use LIB$SIG_TO_RET as a condition handler for LIB$FIND_IMAGE_SYMBOL.

5.21.2 Documentation Changes and Corrections

This section describes minor corrections to the LIB$ Run-Time Library documentation. OpenVMS RTL Library (LIB$) Manual


The OpenVMS RTL Library (LIB$) Manual requires the following corrections:

5.22 Screen Management (SMG$) Facility

The following sections contain release notes pertaining to the Screen Management (SMG$) Facility.

5.22.1 Documentation Changes and Corrections

This section describes minor corrections to the SMG$ Run-Time Library documentation. OpenVMS RTL Screen Management (SMG$) Manual

Note the following information that should be added to topics in the reference section at the end of the OpenVMS RTL Screen Management (SMG$) Manual:



5.23 String Manipulation (STR$) Facility

The following sections contain release notes pertaining to the Screen Management (STR$) facility.

5.23.1 Documentation Changes and Corrections

This section describes minor corrections to the STR$ Run-Time Library documentation. OpenVMS RTL String Manipulation (STR$) Manual


The following errors will be corrected in the OpenVMS RTL String Manipulation (STR$) Manual the next time this manual is updated.

5.24 System Services

The following sections contain release notes pertaining to system services.

All system services are documented in the OpenVMS System Services Reference Manual.

5.24.1 Changes and Enhancements

The following section describes a change related to system services. $PERSONA System Services: Flags Ignored (Alpha Only)


The $PERSONA_ASSUME and $PERSONA_CREATE system services were provided in previous versions of OpenVMS. These services contained a flags argument that specified which persona services options were employed when the persona was assumed or created.

In OpenVMS Version 7.2, these flags are ignored.

The flags are ignored in this version of OpenVMS because with per-thread security, the process of impersonation has changed from modifying processwide security structures to modifying individual security profiles within a process. As a result, all the security information within a profile can be modified without affecting jobwide security structures. This eliminates the need for the persona flags to specify selective modification of security structures.

Table 5-2 and Table 5-3 show the values for the flags argument that are ignored in OpenVMS Version 7.2.

Table 5-2 Ignored$PERSONA_ASSUME Flags
Flags Description
IMP$M_ASSUME_SECURITY Assume access rights, UIC, authorized privileges, user name, and security audit flag.
IMP$M_ASSUME_ACCOUNT Assume OpenVMS account.
IMP$M_ASSUME_JOB_WIDE Assume the new persona, even in a multiprocess job.

Table 5-3 Ignored$PERSONA_CREATE Flags
Flags Description
IMP$M_ASSUME_DEFCLASS Create a persona with default classification.

For more information about the $PERSONA system services, refer to the OpenVMS System Services Reference Manual: GETQUI--Z. $PERSONA System Services: Default Privilege Change (Alpha Only)


The default behavior in assigning persona privileges has changed in OpenVMS Alpha Version 7.2. Prior to this release, a persona was created with the authorized privileges from the specified user's UAF record as the default privileges. The user's default privileges would be used only if the IMP$V_ASSUME_DEFPRIV flag was set in the call to $PERSONA_CREATE.

This default behavour is inconsistent with OpenVMS security policy and has been changed for OpenVMS Alpha Version 7.2. The new default behavior builds the persona with privileges as specified in the user's UAF record.

For existing programs to run correctly on OpenVMS Alpha Version 7.2, you may need to modify the user's UAF records so that the default privileges specified are equivilent to authorized privileges.

Two new flags have been added to the $PERSONA_CREATE system service. ISS$V_CREATE_DEFPRIV is equivalent to the IMP$V_ASSUME_DEFPRIV flag of earlier releases and is provided solely for backward compatibility. ISS$V_CREATE_AUTHPRIV is provided to allow the caller to implement the default behavior of earlier versions of OpenVMS; that is, to use the user's authorized privileges as default privileges.

The behavior for $PERSONA_CREATE on OpenVMS VAX Version 7.2 remains unchanged. $PERSONA System Services: Audit Record Change (Alpha Only)


The audit record for persona creation has changed from type Server Login to type Persona Created. A persona is created by calling the $PERSONA_CREATE system service.

5.24.2 Problems and Restrictions

This section describes problems and restrictions related to system services. Linking SECURESHR Images to Run on Older Versions


Some additional entry points have been added to the shareable image dispatch vector. Because of this change, any applications linked against Version 7.0 or later of SECURESHR will not run on a pre-Version 7.0 system. System services that use SECURESHR are the following:

If your program uses any of these system services and you want to create a version that runs on systems prior to Version 7.0, you must link your program on a system running a version of OpenVMS prior to Version 7.0. $SUSPND Behaves Incorrectly in a Cluster Environment

VAX V6.0
Alpha V1.5

When the $SUSPND system service is called and the target process is on a different cluster node than that of the process calling the $SUSPND service, the kernel mode suspend flag (bit 0) is ignored. As a result, any suspend is treated as a supervisor-mode suspend.

5.24.3 Corrections

The following section describes a correction to several system services. $PERSONA Restrictions Removed (Alpha Only)


Previous versions of OpenVMS contained restrictions on the use of the $PERSONA system services ($PERSONA_ASSUME, $PERSONA_CREATE, and $PERSONA_DELETE). With OpenVMS Version 7.2, these restrictions have been removed.

For more information about per-thread security, see the OpenVMS Guide to System Security; for details on the $PERSONA system services, refer to the OpenVMS System Services Reference Manual.

5.25 X/Open Transport Interface (XTI)

The notes in this section describe the X/Open Transport Interface (XTI).

5.25.1 Changes and Enhancements

OpenVMS Version 6.2 and later supports the X/Open Transport Interface (XTI) programming interface. The implementation conforms with the XPG4 X/Open CAE XO/CAE/91/600 (ISBN 1 872630 29 4) X/Open Transport Interface (XTI) specification.

Supported Transports

OpenVMS Version 7.1 and later supports the DECnet for OpenVMS (Phase IV), DECnet-Plus for OpenVMS (Phase V), and TCP/IP Services transports. See Section 5.25.2 for support restrictions.

The transport names used in the t_open routine are 'dnet' for DECnet and either 'ip/udp' or 'ip/tcp' for TCP/IP.

Other transports are available with other networking layered products. Consult individual layered product documentation for information about OpenVMS XTI support.


XTI is supported by frontend and backend code. Frontend code provides access to the standard interface routines. Backend code provides the interface from the frontend code to the selected networking transport.

The supporting image files are as follows:
  XTI C programming include file SYS$LIBRARY:XTI.H

Linking Requirements

After compiling an XTI program, no additional qualifiers are required for linking with XTI.


Documentation about XTI is not included in the OpenVMS documentation set. You can order documentation directly from X/Open Company Limited.

You can also contact X/Open Company Limited at the following locations:

5.25.2 Problems and Restrictions


The following restrictions apply to XTI on OpenVMS systems:

In addition, the 't_info' structure returned from the t_open function reports any additional implementation-specific restrictions for the given transport. (See the XTI documentation for information about the t_open command.)

Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement