OpenVMS Version 7.1 Release Notes

On OpenVMS Alpha systems, there is an additional restriction when kernel threads is enabled in a multithreaded environment. In this environment, callable mail should be used only in the initial thread.

5.15 Mathematics (MTH$) Run-Time Library

The following sections contain release notes pertaining to the Run-Time Mathematics Library (MTH$).

5.15.1 Problems and Restrictions

This section describes known MTH$ problems and restrictions.

5.15.1.1 Linking Images to Run on Previous OpenVMS VAX Versions (VAX Only)

V6.1

This version of OpenVMS VAX provides updated versions of the Mathematics Run-Time Library (RTL) images MTHRTL.EXE, UVMTHRTL.EXE, and VMTHRTL.EXE that contain new entry points in support of DEC Fortran Version 6.0. (UVMTHRTL.EXE is an alternate form of MTHRTL.EXE; references to MTHRTL.EXE in the following paragraphs also apply to UVMTHRTL.EXE.)

Due to the large number of entry points added to MTHRTL.EXE, that image's transfer vector was extended and its global section match identifier incremented. This means that images linked against the new version of MTHRTL.EXE will not run on a system running a previous version of OpenVMS VAX, unless that system has also installed DEC Fortran Version 6.0. In addition, images linked against the new MTHRTL.EXE cannot be translated to run on OpenVMS Alpha using DECmigrate.

To link an image so that it will run on a previous version of OpenVMS VAX, create a directory that contains saved copies of the .EXE and .OLB files from the SYS$LIBRARY directory of the earliest version you wish to support, and define the logical name SYS$LIBRARY to point to that directory before linking. Because OpenVMS VAX also defines a system logical name MTHRTL to refer to either MTHRTL.EXE or UVMTHRTL.EXE, you must also define MTHRTL as a logical name in the process or job table to point to the copy in the directory of older images. For example:

$ DEFINE/USER SYS$LIBRARY disk:[OLD_SYSLIB]
$ DEFINE/USER MTHRTL SYS$LIBRARY:MTHRTL.EXE
$ LINK ...

Images to be translated using DECmigrate should be linked against the SYS$LIBRARY files of OpenVMS VAX Version 5.5-2 or earlier.

5.16 POLYCENTER Software Installation Utility

The release notes in this section pertain to the POLYCENTER Software Installation utility. Also see Section 4.16 for notes about this utility that are of interest to system managers.

5.16.1 Problems and Restrictions

This section describes known problems and restrictions with using the POLYCENTER Software Installation utility to create software kits. Problems and restrictions of interest to system managers are described in Section 4.16.2.

5.16.1.1 Generation Option of File Statement

V7.1

The generation option of the file statement does not work correctly on product removal.

For example, the product description files for products TEST1 and TEST2 are as follows:

product DEC VAXVMS TEST1 V1.0 full ; 
    file [SYSEXE]TEST.EXE generation 1 ; 
end product ; 
 
product DEC VAXVMS TEST2 V1.0 full ; 
    file [SYSEXE]TEST.EXE generation 2 ; 
end product ;

Installing product TEST1 followed by product TEST2 works correctly. Generation 2 of file TEST.EXE replaces generation 1 of file TEST.EXE. However, if you remove product TEST2, generation 1 of file TEST.EXE is not restored; generation 2 of the file is left on the system.

One workaround is to use an execute install...remove statement sequence in product TEST2. The command procedure invoked during the execute install portion of the statement saves any previous version of the file. Later the execute remove portion of the statement restores the saved version of the file.

Digital expects to correct this problem in a future release.

5.16.1.2 Multiple Execute Remove Statements

V6.1

There is a problem with the execute remove statement where only the first one executes during a remove operation. However, all of the execute install statements execute during an install operation.

Digital expects to correct this problem in a future release.

5.17 Privileged Interfaces and Data Structures (Alpha Only)

V7.1

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.

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.

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, see the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications.

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

5.18 Record Management Services (RMS)

This section contains release notes pertaining to RMS.

5.18.1 Changes and Enhancements

The following note describes a change that affects RMS.

5.18.1.1 RMS Performance Optimization With VIOC Cache (Alpha Only)

V7.1

OpenVMS Alpha Version 7.1 enables RMS to use a feature of the VIOC cache that eliminates unnecessary RMS thread switches. During disk reads from Files-11 devices, RMS now avoids a thread switch if the read request is immediately satisfied from the VIOC cache.

This functionality increases the number of RMS operations that complete without stalling. Some RMS operations that always stalled previously now may never stall.

Applications might be affected by two changes in behavior:

Some asynchronous RMS operations that used to return RMS$_PENDING, an alternate success, now return RMS$_NORMAL.
Applications that request FAB/RAB$V_SYNCSTS on an asynchronous call might receive RMS$_SYNCH, an alternate success, on operations that never returned this status before. When RMS$_SYNCH is returned, the user's AST completion routine is not called. There is no change in user completion AST behavior for synchronous RMS calls or for asynchronous calls that do not set FAB/RAB$V_SYNCSTS.

If these changes in behavior are a problem for your application, you can execute the following command to disable VIOC caching for the affected files:

$ SET FILE/DATA_CHECK=READ filespec

5.18.2 Documentation Changes and Corrections

The following note contains a correction to the OpenVMS Record Management Services Reference Manual.

5.18.2.1 OpenVMS Record Management Services Reference Manual

V7.1

Section 6.1 of the OpenVMS Record Management Services Reference Manual incorrectly states that a maximum multibuffer count of 255 can be specified for the RAB$B_MBF field. The actual maximum multibuffer count allowed is 127. This maximum has never changed.

5.19 Run-Time Library (LIB$)

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

5.19.1 Problems and Restrictions

This section describes known LIB$ RTL problems and restrictions.

5.19.1.1 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 in conjunction with LIB$FIND_IMAGE_SYMBOL should probably handle this as a special case.

To allow LIB$FIND_IMAGE_SYMBOL to continue execution after signalling 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.20 Screen Management (SMG$) Facility

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

5.20.1 Documentation Changes and Corrections

The following note describes several minor corrections to the OpenVMS RTL Screen Management (SMG$) Manual.

5.20.1.1 OpenVMS RTL Screen Management (SMG$) Manual

V7.1

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:

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 in order 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.

5.21 Shared Linkage Sections

This section contains release notes pertaining to shared linkage sections.

5.21.1 Problems and Restrictions

This section describes a restriction on using libraries installed with shared linkage.

5.21.1.1 Interdependencies Between Images (Alpha Only)

V6.1

On OpenVMS Alpha systems, if you want to use an alternate version of any library installed with shareable linkage, you must use alternate (noninstalled) versions of all the libraries that call that library. The libraries that can be installed with shared linkage are LIBOTS, LIBRTL, CMA$TIS_SHR, DPML$SHR, and DECC$SHR.

The dependencies are in the order listed.

For example, if you issue the command:

$ DEFINE DPML$SHR SYS$LIBRARY:DPML$SHR.EXE;

then you must also issue the following command:

$ DEFINE LIBOTS SYS$LIBRARY:LIBOTS.EXE;

Failure to redefine all calling libraries may result in access violations.

5.22 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.22.1 Problems and Restrictions

This section describes problems and restrictions related to system services.

5.22.1.1 SYS$AVOID_PREEMPT and SYS$SETUP_AVOID_PREEMPT Prototype Definitions

V7.1

The new system services SYS$AVOID_PREEMPT and SYS$SETUP_AVOID_PREEMPT were inadvertently omitted from the system service prototype definitions. Consequently, the compile-time definitions for these services are not included in STARLET.H for C or in macro definitions for other languages.

For this release, you must manually create the prototype definitions. Each service takes one integer parameter, ENABLE, which is 1 to enable and 0 to disable. For example, the C prototypes are defined as follows:

   int sys$avoid_preempt(int enable); 
   int sys$setup_avoid_preempt(int enable);

Other languages should have equivalent definitions.

The prototypes for these services will be included in the next release. Note that the link-time definitions for these services are included correctly in Version 7.1.

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

5.22.1.3 $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.22.2 Documentation Changes and Corrections

The notes in this section describe changes and corrections to the OpenVMS System Services Reference Manual.

5.22.2.1 OpenVMS System Services Reference Manual

V7.1

In the description of the $CRMPSC_GDZRO_64 system service, the format section erroneously cites the SYS$CRMPSC_GPFILE_64 system service. This reference to SYS$CRMPSC_GPFILE_64 should be replaced with $CRMPSC_GDZRO_64. The argument list is correct.

5.23 X/Open Transport Interface (XTI)

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

5.23.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 supports the DECnet for OpenVMS (Phase IV), DECnet-Plus for OpenVMS (Phase V), and TCP/IP transports. See Section 5.23.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.

Architecture

XTI is supported by front end and back end code. Front end code provides access to the standard interface routines. Back end code provides the interface from the front end code to the selected networking transport.

The supporting image files are as follows:

XTI front end code SYS$SHARE:XTI$XTILIB.EXE

TCP/IP XTI back end code SYS$SHARE:XTI$IPSHR.EXE

DECnet XTI back end code SYS$SHARE:XTI$DNETSHR.EXE

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

Documentation about XTI is not included in the OpenVMS documentation set. You can order documentation directly from X/Open Company Limited. If you have access to the Internet, you can get more information about X/Open Company Limited (including their publications) by browsing the following URL:

http://www.xopen.co.uk/

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

USA: East Coast
X/Open Company Limited
3141 Fairview Park Drive
Falls Church
VA 22042-4501
U.S.A.
Tel: +1 (703) 876 0044
Fax: +1 (703) 876 0050
USA: West Coast
X/Open Company Limited
1010 El Camino Real
Suite 380
Menlo Park, CA 94025
U.S.A.
Tel: +1 (415) 323 7992
Fax: +1 (415) 323 8204
United Kingdom:
X/Open Company Limited
Apex Plaza
Forbury Road
Reading
Berks RG1 1AX
U.K.
Tel: +44 1734 508311
Fax: +44 1734 500110
Japan:
X/Open Company Limited
Karufuru-Kanda Bldg, 9F
1-2-1 Kanda Suda-cho
Chiyoda-Ku
Tokyo 101
Japan
Tel: +81 3 3251 8321
Fax: +81 3 3251 8376

5.23.2 Problems and Restrictions

V6.2

The following restrictions apply to XTI on OpenVMS systems:

Nonblocking I/O is unsupported for DECnet for OpenVMS.
DECnet for OpenVMS (Phase IV) does not fit the model for nonblocking I/O. Attempts to open or switch an XTI file descriptor to nonblocking I/O (O_NONBLOCK) will fail.
Connectionless I/O is unsupported for DECnet for OpenVMS.
DECnet for OpenVMS (Phase IV) does not fit the model of connectionless I/O. Therefore, only connection-oriented connections are supported.
Disabled ASTs cause problems.
The XTI back end code uses ASTs for asynchronous delivery of events from the transports. If ASTs are disabled (sys$setast(0)), the XTI back end code will not operate correctly until the ASTs are enabled again.
XTI file descriptors are not compatible with C Run-Time Library file descriptors.

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

Chapter 6
Device Support on OpenVMS Systems

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.

6.1 Recompiling and Relinking OpenVMS Device Drivers

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

6.1.1 Alpha and VAX SCSI Device Drivers

V7.1

All OpenVMS Alpha and OpenVMS VAX SCSI device drivers from OpenVMS Version 7.0 and earlier must be recompiled and relinked to run correctly on OpenVMS Version 7.1.

You must recompile and relink these drivers because OpenVMS Version 7.1 includes changes to the data structures used by OpenVMS Alpha and OpenVMS VAX SCSI device drivers. No source changes are required by these data structure changes.

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

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

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.

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

6.2 Changed Behavior of IO$_SKIPFILE Function

V7.1

The performance of the IO$_SKIPFILE function has been 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 a new 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 OpenVMS Version 7.1 New Features Manual and OpenVMS I/O User's Reference Manual.

The MTAACP and Backup utilities are compatible with the new behavior and have been modified to use the new IO$M_ALLOWFAST modifier. The behavior of MTAACP and Backup are unchanged when ANSI-formated tapes are used. They may behave differently when non-ANSI standard tapes are used. Other tape applications should be examined to determine whether they are compatible with the new semantics. If an application is compatible, or if it can be made compatible, the application should be modified to use the IO$M_ALLOWFAST modifier with the IO$_SKIPFILE function. If you have an application that is compatible with the new semantics, but it cannot be modified to use the IO$M_ALLOWFAST modifier, refer to the documentation in SYS$ETC:MKSET.TXT.

6.3 ISA_CONFIG.DAT Unsupported in Future Release (Alpha Only)

V7.1

Support for using the SYS$MANAGER:ISA_CONFIG.DAT file to configure ISA devices will be discontinued in a future release of OpenVMS Alpha. If you use this file, you should convert to using the ISACFG utility from the console, and the new file-based autoconfiguration method for loading device drivers (as described in the OpenVMS Version 7.1 New Features Manual).

6.4 Required Change in ISA_CONFIG.DAT on AlphaStation 200/400

V7.1

Customers configuring ISA devices on AlphaStation 200/400 Family systems must change their SYS$MANAGER:ISA_CONFIG.DAT file, so that the node information for each device appears at the end of each device description block.

Warning
For upgrades from OpenVMS Version 6.2 or 7.0 systems, this change must be made before starting the upgrade procedure.

For example, prior to OpenVMS Version 7.1, the following device description block:

        [AUA0] 
         NAME=AU 
         NODE=3 
         DRIVER=SYS$MSBDRIVER 
         IRQ=9 
         DMA=(0,1) 
         PORT=(388:4,530:8)

would be changed as follows:

        [AUA0] 
         NAME=AU 
         DRIVER=SYS$MSBDRIVER 
         IRQ=9 
         DMA=(0,1) 
         PORT=(388:4,530:8) 
         NODE=3

Customers using SYS$MANAGER:ISA_CONFIG.DAT files should read Section 6.3.

6.5 Naming Serial Line Devices on Alpha Systems

V7.1

OpenVMS has changed the way it handles the second serial port on the following Alpha systems:

AlphaStation 200, 400, 500 and 600 families
AlphaServer 1000, 2000, 2100, and 4100 families

If one of these systems is booted with the console environment variable set to graphics, the name of the serial line (COM1) will be different from that in previous releases. The COM1 device is called TTB0 instead of OPA1. In this case, the COM1 device is controlled by SYS$YSDRIVER instead of SYS$OPDRIVER.

If the console is set to serial, the COM1 device is called OPA0.

6.6 Errors After a Reset on Some Wide SCSI Adapters (Alpha)

V7.1

In OpenVMS Alpha Version 7.1, wide SCSI disk drives connected to QLogic adapters such as KFTIA fast wide differential ports, KZPDA, KZPSM, and the AlphaStation 600 and AlphaServer 4100 embedded SCSI ports may encounter the problem described in this section.

An error such as SS$_CTLERR occasionally occurs following a bus reset on the QLogic drives. This error occurs only if a SCSI INQUIRY command is sent to the device immediately after the reset.

These errors are not likely to occur under normal circumstances because OpenVMS rarely follows a reset immediately by an INQUIRY command. The errors are most likely to be seen when running SYSMAN IO AUTOCONFIGURE immediately after a reset, or when issuing certain HSZTERM commands after an HSZ reset. If a wide device on any of the above adapters appears to be generating multiple errors after such a reset, the condition may be resolved by using any SCSI command other than INQUIRY. For example, this could be done by mounting the device or by running SYS$ETC:SCSI_INFO against it.

6.7 Memory Holes on AlphaServer 4100 Systems

V7.1

Physical memory holes might exist on AlphaServer 4100 systems. As illustrated in Figure 6-1, there are three different sizes of memory daughter card pairs: 512 MB, 256 MB, and 128 MB. In accordance with AlphaServer 4100 systems configuration rules, memory card pairs must be arranged in descending order of size.

The AlphaServer 4100 hardware reads the first set of memory daughter cards and assumes that any memory card pairs that follow are the same size. Memory holes occur because memory card pairs following the first set of cards read by the hardware might not be the same size. As shown in Figure 6-1, the hole at 3000.0000 must be dealt with by OpenVMS. The hole at 4800.0000 is at the top of the address space and can be ignored by OpenVMS.

Note
Previous versions of OpenVMS Alpha did not efficiently support systems with physical memory holes and ultimately led to an inefficient use of system memory. The memory management data structures in OpenVMS Alpha Version 7.1 have been slightly modified to recognize the memory holes. As a result, inefficiencies in previous versions of the OpenVMS Alpha operating system have been eliminated.

Figure 6-1 Example Memory Diagram

Note that this configuration impacts the algorithm used to determine whether a driver needs to use map registers. In releases prior to OpenVMS Alpha Version 7.1, device drivers do the following:

Call IOC$NODE_DATA with key IOC$K_DIRECT_DMA_SIZE to obtain the size of the direct DMA window (in megabytes). This is usually 1 GB.
Convert the size returned from IOC$NODE_DATA to pages and compare the size with mmg$gl_memsize, which contains the number of pages in physical memory.
If mmg$gl_memsize is greater than the size returned from IOC$NODE_DATA, use map registers; otherwise, use the direct DMA window.

  6481P008.HTM
  OSSG Documentation
  11-DEC-1996 07:52:30.47

Legal

	XTI front end code	SYS$SHARE:XTI$XTILIB.EXE
	TCP/IP XTI back end code	SYS$SHARE:XTI$IPSHR.EXE
	DECnet XTI back end code	SYS$SHARE:XTI$DNETSHR.EXE
	XTI C programming include file	SYS$LIBRARY:XTI.H

OpenVMS Version 7.1 Release Notes

5.18.2 Documentation Changes and Corrections

5.21 Shared Linkage Sections

5.23.2 Problems and Restrictions

Chapter 6Device Support on OpenVMS Systems

Chapter 6
Device Support on OpenVMS Systems