HP OpenVMS Systems Documentation

V7.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 Chapter 7.

6.21.3 Per-Thread Security Impacts Privileged Code and Device Drivers

V7.2

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:

 #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:

• If a device driver creates a new IRP by duplicating an existing IRP and submits both the original and the duplicate IRPs for I/O postprocessing by calling IOC_STD$SIMREQCOM or IOC_STD$DIRPOST1 the device driver must call NSA_STD$REFERENCE_PSB sometime after duplicating the IRP, but before submitting it for I/O postprocessing.
• If a device driver creates a new IRP by duplicating an existing IRP and does not put the address of some procedure descriptor into the IRP$L_PID cell in either the copy or the original IRP, and the device driver submits both the original and the duplicate IRPs for I/O postprocessing by calling IOC_STD$REQCOM, COM_STD$POST, COM_STD$POST_NOCNT, or IOC_STD$POST_IRP, the device driver must call NSA_STD$REFERENCE_PSB sometime after duplicating the IRP but before submitting it for I/O postprocessing.
  Device drivers that perform these steps are also likely to put the address of some procedure descriptor into IRP$L_PID. Therefore, most device drivers that duplicate IRPs should be able to function correctly on OpenVMS 7.2 without making source changes, relinking, or recompiling.

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.

6.22 Record Management Services (RMS)

This section contains release notes pertaining to RMS.

6.22.1 Potential CONVERT-I-SEQ Error on CONVERT/NOSORT with Collated Key

V7.3

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.

6.22.2 Circular Directory Path Detection (Alpha Only)

V7.2

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.

6.22.3 Directory Cache Limits Removed

V7.2

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.

6.23 Run-Time Library (LIB$)---LIB$FIND_IMAGE_SYMBOL Signals Warning for Modules with Compilation Errors

V7.1

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.

6.24 Screen Management (SMG$) Facility Documentation

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:

V7.2

• The following statement should be added to the Condition Values Returned section of routine SMG$DELETE_VIRTUAL_DISPLAY:
  "Any condition value returned by the $DELPRC system service."
• The description of routine SMG$GET_TERM_DATA contains an error in the Arguments section for the capability-data argument. The correction is as follows:

  access:	write-only
  mechanism:	by reference, array reference

• The description of routine SMG$READ_LOCATOR contains an error in the Arguments section for both the row-number and the column-number arguments. The "access:" for both arguments is write only.
• The description of routine SMG$SET_OUT_OF_BAND_ASTS contains an error in the Arguments section for the AST-argument argument. The symbolic names in the Data Structure diagram are incorrect. The symbolic names in the paragraph under this diagram are correct. The correct and incorrect symbolic names are as follows:

  Incorrect	Correct
  SMG$L_PASTEBOARD_ID	SMG$L_PBD_ID
  SMG$L_ARG	SMG$L_USER_ARG
  SMG$B_CHARACTER	SMG$B_CHAR

V7.1

• In the documentation for the SMG$READ_COMPOSED_LINE routine, the following text should be appended to the description of the flags argument:
  "The terminal characteristic /LINE_EDITING should be set for your terminal for these flags to work as expected. /LINE_EDITING is the default."
• The description of routine SMG$SET_KEYPAD_MODE should contain this note:

  Note Changing the keypad mode changes the physical terminal setting. This is a global change for all virtual keyboards, not just the virtual keyboard specified by the keyboard-id argument.

V7.3

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.

6.26 SORT32 (SORT/MERGE/CONVERT)

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.

6.26.1 SORT32 with /WORK_FILES=2 or Higher---Restriction

V7.3

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:

• Redefine SYS$SCRATCH instead of SORTWORKS logicals.
• Use /WORK_FILES=1.
• Use unique file names for SORTWORK logicals.
• With CONVERT, use SYS$SHARE:CONVSHR_OLD.EXE.

V7.3

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.

6.26.3 SORT32 and VFC Format Files (Restriction)

V7.3

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.

6.26.4 SORT32 and /STATISTICS Working-Set Display

V7.3

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.

6.27 System Services

The following sections contain release notes pertaining to system services.

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

6.27.1 Performance API - $GETRMI

V7.3

The $GETRMI system service does not require the CMKRNL privilege as is currently documented.

6.27.2 $PERSONA System Services: Flags Ignored (Alpha Only)

V7.2

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 6-2 and Table 6-3 show the values for the flags argument that are ignored in OpenVMS Version 7.2.

For more information about the $PERSONA system services, refer to the OpenVMS System Services Reference Manual: GETUTC--Z.

6.27.3 $PERSONA System Services: Default Privilege Change (Alpha Only)

V7.2

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 unchanged.

6.27.4 $PERSONA System Services: Audit Record Change (Alpha Only)

V7.2

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.

6.27.5 Linking SECURESHR Images to Run on Older Versions

V7.0

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:

$FORMAT_ACL
$PARSE_ACL
$FORMAT_AUDIT
$DELETE_INTRUSION
$SCAN_INTRUSION
$SHOW_INTRUSION
$ADD_PROXY
$DELETE_PROXY
$DISPLAY_PROXY
$VERIFY_PROXY

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.

6.27.6 $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.

6.27.7 $PERSONA Restrictions Removed (Alpha Only)

V7.2

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.

• I/O can now be in progress when you switch personae (using $PERSONA_ASSUME).
• You can now safely use personae in a multiprocess job tree. Previously the $PERSONA services modified the Job Information Block (JIB), which is shared by all processes in the job tree. In OpenVMS Version 7.2, the user name and account cells are moved from the JIB to the Persona Block (PSB).
• Interaction between a thread manager (for example, the thread manager incorporated within the POSIX Threads Library) and the security subsystem enables the automatic switching of profiles as threads scheduled for execution.

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.