HP OpenVMS Systems Documentation
OpenVMS Version 7.3 Release Notes
6.21.2 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 may 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
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 references 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:
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.3.
This section contains release notes pertaining to RMS.
This potential change in behavior is restricted to a CONVERT command that specifies both the /NOSORT qualifier and a collated key type on one of the keys in the output file.
The /NOSORT qualifier on a convert command indicates that the primary key is already in sorted order in the input file and directs the convert utility not to sort it. Prior to OpenVMS Version 7.3, the convert utility had a defect that caused it to always sort the input file if some key specified for the output file had a collated key type regardless of whether /NOSORT was specified. As of OpenVMS Version 7.3, the convert utility has been fixed to appropriately obey the /NOSORT qualifier on the command line, even if one of the keys in the output file is a collated key.
This means that a convert operation that previously succeeded as a
side-effect of the collated key defect may now produce %CONVERT-I-SEQ
messages if the input file is not already in sorted order by the
primary key and /NOSORT is specified on the command line. The /NOSORT
qualifier should not be used if the input file is not already in sorted
order by the primary key.
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.
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.
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.
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:
6.25 Soft Affinity---Soft Affinity Disabled (Alpha Only)
In OpenVMS Version 7.2, soft affinity was enabled for some SMP systems
--- the AlphaServer 4100 Series and the AlphaServer 2100 Series.
However, because of unanticipated hardware behavior, soft affinity for
these SMP systems has now been disabled. The $SET_IMPLICIT_AFFINITY
system service will return the SS$_UNSUPPORTED error status. The DCL
command SET PROCESS/AFFINITY=SOFT will result in the
%SYSTEM-E-UNSUPPORTED error message.
The following sections contain release notes pertaining to the use of
SORT32. SORT32 (SORTSHR.EXE) is used by SORT, MERGE, CONVERT, Compaq
COBOL, and Oracle Rdb.
SORT32 does not support /WORK_FILES=2 or higher if the SORT work files have been redefined to point to a common directory whose owner UIC does not match the process UIC. Note that /WORK_FILES=2 is the default for uses of SORT32 from SORT, MERGE, CONVERT, Compaq COBOL, and Oracle Rdb.
The workarounds are as follows:
6.26.2 SORT32 Work File Directories---Restriction
SORT32 work files must be redirected to directories that allow
multiple-file versions that can handle the number of requested work
files. This restriction also exists in Hypersort.
If you use the /PROCESS=TAG for VFC format input files, SORT32
initializes the fixed control area to 0 for VFC format output files.
Use /PROCESS_RECORD to work around this problem.
SORT32 overflows the working-set display in the /STATISTICS output for
any working set that is 1,000,000 pages or larger. This is also a known
problem with Hypersort.
The following sections contain release notes pertaining to system services.
All system services are documented in the OpenVMS System Services Reference Manual.
The $GETRMI system service does not require the CMKRNL privilege as is
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.
For more information about the $PERSONA system services, refer to the
OpenVMS System Services Reference Manual: GETUTC--Z.
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 behavior 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 equivalent 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
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.
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
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.
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.