Document revision date: 9 May 2001

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.

Table 6-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 6-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: 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.

This chapter contains release notes pertaining to OpenVMS device support on Alpha and VAX systems. Where appropriate, section headings indicate whether specific notes contain Alpha-specific or VAX-specific information.

7.1 Recompiling and Relinking OpenVMS Device Drivers

The following sections contain release notes pertaining to recompiling and relinking OpenVMS device drivers.

7.1.1 Possible Per-Threads Security Impacts Alpha Device Drivers

V7.2

Refer to Section 6.21.3 for information about how possible per-thread security impacts OpenVMS Alpha device drivers.

7.1.2 Alpha and VAX SCSI Device Drivers

V7.3

OpenVMS Engineering recommends that all OpenVMS Alpha SCSI device drivers from previous versions of OpenVMS must be recompiled and relinked to run correctly on OpenVMS Version 7.3.

If you have an OpenVMS Alpha SCSI driver that you are upgrading from a version prior to OpenVMS Alpha 7.0, see Section 7.1.3.

Note that for OpenVMS Version 7.1 all OpenVMS Alpha and VAX SCSI device drivers required recompiling and relinking. OpenVMS VAX device drivers that were recompiled and relinked to run on OpenVMS Version 7.1 will run correctly on OpenVMS Version 7.3.

7.1.3 OpenVMS Alpha Device Drivers

V7.1

Device drivers 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. (Note that Alpha SCSI drivers, however, must be recompiled and relinked as described in Section 7.1.2.)

Device drivers 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, device drivers from releases prior to OpenVMS Alpha Version 7.0 may also 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 customer-written drivers, see the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications.

7.2 Restriction: Parallel SCSI Support for Logical Unit Numbers

V7.2

OpenVMS supports up to eight Logical Unit Numbers (LUNs) per target ID on a parallel SCSI bus.

The SCSI-2 standard is limited to eight LUNs, but the SCSI-3 standard recently increased to 64 LUNs. The HSZ80 is the only supported device that implements more than eight LUNs (it supports 32 LUNs per target ID). This feature cannot be used in the current release of OpenVMS. LUN values on OpenVMS must be in the range 0-7.

This restriction does not apply to Fibre Channel.

7.3 Selective Autoconfiguration Unsupported in Some SCSI Configurations

V7.2

OpenVMS Alpha provides SYSMAN commands that allow system managers to specify which devices will be autoconfigured. This can be specified permanently, so that it is applied at each system boot or for the duration of a manual autoconfiguration command, using the following qualifiers:

SYSMAN> IO SET/EXCLUDE=(device_name) SYSMAN> IO AUTOCONFIGURE/EXCLUDE=(device_name) and/or /SELECT=(device_name)

These commands cannot be used selectively to autoconfigure SCSI device names that include a port allocation class or device names that have an HSZ allocation class. The commands also cannot be used for Fibre Channel devices. This restriction applies to class-driver devices only (DK, MK, DG). Selective autoconfiguration can be used for all SCSI and Fibre Channel port-driver devices (PK, PG, and FG).

This restriction also applies to OpenVMS Version 7.1 systems that use port allocation classes.

7.4 Changes to the IO$_DIAGNOSE Function

The following sections contain IO$_DIAGNOSE changes.

7.4.1 Change to S2DGB$L_32PHSTMO and S2DGB$L_64PHSTMO

V7.3

The legal values for S2DGB$L_32PHSTMO and S2DGB$L_64PHSTMO are now 0 to 65,535 [about 18 hours]. Previously the values were 0 to 300 [5 minutes].

7.4.2 IO$_DIAGNOSE Behavior Changes

V7.3

Appendix B of the OpenVMS I/O User's Reference Manual for Version 7.2 formerly stated that the following values are ignored when S2DGB$V_TAGGED_REQ is 1:

S2DGV$L_32PHSTMO
S2DGV$L_64PHSTMO
S2DGV$L_32DSCTMO
S2DGV$L_64DSCTMO
S2DGB$L_DISCPRIV

Although not documented at the time, the PAD counts, S2DGV$L_32PADCNT and S2DGV$L_64PADCNT were included in this group.

The implementation inadvertently conditionalized on the port's ability to handle command queuing instead of S2DGB$V_TAGGED_REQ.

The code has now been changed to conditionalize on S2DGB$V_TAGGED_REQ. The PAD counts are still included in this group.

The documentation also stated that ports that do not support tagged command queuing always behave as if S2DGB$V_TAGGED_REQ is 0. This applies to the tagged queuing behavior of the ports. S2DGB$V_TAGGED_REQ still controls whether the parameters previously mentioned are ignored, even on ports that do not support tagged command queuing.

The reason these values are ignored when tagged command queuing is in use is that they can affect other commands to the logical unit until the IO$_DIAGNOSE command completes. (The timeout values are used as defaults for all commands to the logical unit for the duration of the command.)

The OpenVMS I/O User's Reference Manual for Version 7.3 has been updated to reflect these changes and corrections.

7.5 Changed Behavior of IO$_SKIPFILE Function

V7.2

The performance of the IO$_SKIPFILE function was significantly improved in OpenVMS Version 7.1 for certain SCSI tape drives. The new IO$_SKIPFILE implementation functions correctly with all built-in OpenVMS tape functions such as INIT, MOUNT, BACKUP, and COPY when tapes are formatted according to the ANSI Standard X3.27-1987. This is the default tape standard for OpenVMS.

Higher performance for the IO$_SKIPFILE function is requested with the modifier (IO$M_ALLOWFAST). When the IO$M_ALLOWFAST modifier is used, IO$_SKIPFILE stops at the end of data rather than at double filemarks. For more information about the IO$M_ALLOWFAST modifier, refer to the OpenVMS I/O User's Reference Manual.

In OpenVMS Version 7.2, SKIPFILE support is implemented through a standard DCL interface, making the old SYS$ETC:MKSET.TXT and SYS$ETC:MKSET.EXE files obsolete. Refer to the OpenVMS I/O User's Reference Manual for details about using the DCL interface.

7.6 CRCTX Routines Enhanced (Alpha Only)

V7.1-2

The system routines that you can use to manage the Counted Resource Context Block (CRCTX) data structure have been improved. The following routines now set and check the status (CRCTX$V_ITEM_VALID) of the CRCTX data structure:

• IOC$DEALLOC_CRCTX
• IOC$ALLOC_CNT_RES
• IOC$DEALLOC_CNT_RES
• IOC$LOAD_MAP

These routines have changed as follows:

If you call IOC$DEALLOC_CRCTX with a valid CRCTX status (CRCTX$V_ITEM_VALID set to 1), the service returns a bad status. If the SYSBOOT parameter SYSTEM_CHECK is set, the system will crash. This prevents users from deallocating a CRCTX when they have valid resources that have not been deallocated.

You must call IOC$ALLOC_CNT_RES with an invalid CRCTX status (CRCTX$V_ITEM_VALID set to 0). If you call this routine with a valid status, OpenVMS assumes that you will lose the resources mapped by this CRCTX. OpenVMS does not allocate new resources and returns a bad status. If SYSTEM_CHECK is set, the system will crash. IOC$ALLOC_CNT_RES sets the valid bit before it returns.

IOC$DEALLOC_CNT_RES must be called with a valid CRCTX (CRCTX$V_ITEM_VALID set to 1). If you call IOC$DEALLOC_CNT_RES with an invalid CRCTX, OpenVMS assumes that the other parameters are not valid, and returns a bad status. If SYSTEM_CHECK is set, the system will crash. IOC$DEALLOC_CNT_RES clears the valid bit before it returns.

IOC$LOAD_MAP must be called with a valid CRCTX. If it is called with an invalid CRCTX (CRCTX$V_ITEM_VALID set to 0), it assumes that the other parameters are also invalid, and returns a bad status. If the SYSBOOT parameter SYSTEM_CHECK is set, the system will crash.

These improvements indicate to device support and privileged-code application developers whether they need to deallocate scatter gather registers, which are treated by OpenVMS as generic resources. If the CRCTX$V_ITEM_VALID bit is set, IOC$DEALLOC_CNT_RES still needs to be called.

7.7 Device Driver MON Version Handling (Alpha Only)

V7.3

As of OpenVMS V7.3, when SYSTEM_CHECK is enabled, device driver images with names of the form SYS$nnDRIVER_MON.EXE will be automatically loaded by the system loader. If a corresponding _MON version does not exist, the system will use the default image name: SYS$nnDRIVER.EXE.

7.8 New Values for Length Parameter in System Routines (Alpha Only)

V7.1-2

The following system routines called by OpenVMS Alpha device drivers have new values for the length parameter:

IOC$READ_PCI_CONFIG
IOC$WRITE_PCI_CONFIG
IOC$READ_IO
IOC$WRITE_IO

The two new length values (IOC$K_BYTE and IOC$K_WORD) allow byte and word data to be passed in right-aligned fashion. Table 7-1 shows the accepted values for the length parameter.

Table 7-1 Values for Length Parameter

Value (hex)	Keyword
1	IOC$K_BYTE_LANED
2	IOC$K_WORD_LANED
4	IOC$K_LONGWORD
8	IOC$K_QUADWORD
100	IOC$K_BYTE
200	IOC$K_WORD

IOC$K_BYTE_LANED and IOC$K_WORD_LANED lane bytes in the following way:

IOC$K_BYTE_LANED (1) Byte-Laned Byte

Depending on bits <1:0> of the address, the byte resides in a longword in one of the following lanes:

+---+---+---+---+ | | | | X | bits <1:0> = 0 +---+---+---+---+ +---+---+---+---+ | | | X | | bits <1:0> = 1 +---+---+---+---+ +---+---+---+---+ | | X | | | bits <1:0> = 2 +---+---+---+---+ +---+---+---+---+ | X | | | | bits <1:0> = 3 +---+---+---+---+

The driver must use the low 2 bits of the address to select the correct byte.

IOC$K_WORD_LANED (2) Byte-Laned Word

Depending on bits <1:0> of the address, the word resides in a longword in one of the following locations.

+---+---+---+---+ | | | XXXXX | bits <1:0> = 0 +---+---+---+---+ +---+---+---+---+ | | XXXXX | | bits <1:0> = 1 +---+---+---+---+ +---+---+---+---+ | XXXXX | | | bits <1:0> = 2 +---+---+---+---+

The driver must use the low 2 bits of the address to select the correct word.

However, if IOC$K_BYTE and IOC$K_WORD are used, the data is always right-aligned:

IOC$K_BYTE (hex 100) Right-Aligned Byte

The byte is always in the right-most lane:

+---+---+---+---+ | | | | X | bits <1:0> = 0,1,2,3 +---+---+---+---+

Note that the high-order byte contains unpredictable data and must be masked to operate correctly.

IOC$K_WORD (hex 200) Right-Aligned Word

The word is always in the right-most lane:

+---+---+---+---+ | | | XXXXX | bits <1:0> = 0,1,2 +---+---+---+---+

Note that the high-order word contains unpredictable data and must be masked to operate correctly.

By using the new values for the length parameter, programmers who write device drivers no longer have to put data into the correct lanes before writes and after reads.

	privacy and legal statement
6637PRO_010.HTML