HP OpenVMS Alpha Version 7.3--2 Release Notes

During the testing of HP supported SCSI disk drives on configurations
with DWZZAs and long differential SCSI buses, two drives, RZ25M and
RZ26N, were found to have bus phase problems. For this reason, do not
use these drives in configurations where the differential bus length
connecting DWZZAs equals or exceeds 20 meters.

This recommendation applies only to the RZ25M and RZ26N drives. All
other disk drives that are listed as supported in the OpenVMS SPD can
be used in configurations to the full bus lengths of the SCSI-2
specification.

If you install RZ26L or RZ28 disks on a multihost SCSI bus in an
OpenVMS Cluster, the disk's minimum firmware revision is 442.

The following sections describe a procedure that you can use to update
the firmware on some RZ26L and RZ28 drives. This procedure can only be
used with drives that are directly connected to a SCSI adapter on a
host system. Drives that are attached through an intelligent controller
(such as an HSZ40 or KZPSC) cannot be updated using this procedure.
Refer to the intelligent controller's documentation to determine
whether an alternative firmware update procedure exists.

Important
Note

Only certain RZ26L and RZ28 firmware revisions can be safely upgraded
to firmware revision level 442. Refer to Section 6.16.3.1 to determine if
your disks are capable of being upgraded to firmware revision level
442. If your disk is capable of supporting firmware revision level 442,
use the RZTOOLS utility that is described in Section 6.16.3.2 to update
the disk's firmware.

Only the combinations of disk drives and firmware revision levels
listed in Table 6-4 are capable of being upgraded safely to
firmware revision level 442. Performing the update procedure on any
other combination can permanently damage the disk.

If you determine that your disk requires revision level 442 firmware
and it is capable of being upgraded safely, use the following procedure
to update the firmware. (See Table 6-4 for the file name of the
disk you are upgrading.)

$ RZTOOLS_ALPHA :== $SYS$ETC:RZTOOLS_ALPHA
$ RZTOOLS_ALPHA DKB500 /LOAD=SYS$ETC:filename.FUP
Read in 262144 bytes.
Current FW version - X440C
Upgrading to - DEC0
Loading code ......
New code has been sent to the drive.

All OpenVMS Alpha SCSI device drivers from previous versions of OpenVMS
must be recompiled and relinked to run correctly on OpenVMS Version
7.3-1 or higher.

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

Note that for OpenVMS Version 7.1 all OpenVMS 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 or higher.

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

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 higher. For more details about OpenVMS Alpha
Version 7.0 changes that may require source changes to customer-written
drivers, refer to the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications.

As of OpenVMS Version 7.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.

Alpha hardware platforms that support PCI, EISA, and ISA buses deliver
I/O device interrupts at different IPLs, either 20 or 21. The IPL at
which device interrupts are delivered can change if you move the device
from one platform to another. This is a problem if the driver declares
its device IPL to be 20, and then that driver is executed on a machine
that delivers I/O device interrupts at IPL 21.

The simplest solution to this problem is for PCI, EISA, and ISA device
drivers to use IPL 21. This works correctly on platforms that deliver
I/O device interrupts at IPL 20 and on platforms that deliver I/O
device interrupts at IPL 21.

A future release of OpenVMS Alpha may provide a platform-independent
mechanism for drivers to determine the device IPL dynamically.

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

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.

Once a product is retired, HP does not accept or act on problem reports
posted against the product. However, for those interested in doing
their own development and support, the source code for many former
products is available as freeware from the following sources:

On the freeware CD-ROM that ships with the
OpenVMS operating system. The freeware CD-ROM also
includes internal tools such as SDL, NMAIL, MAILWATCH, and popular
Internet programs. For instructions about mounting the
CD-ROM, see Section 3.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 Writing OpenVMS Alpha
Device Drivers in C).

The POSIX 1003.4a, Draft 4 (or "d4") interface of the Compaq POSIX
Threads Library (formerly named DECthreads) is slated for retirement in
a future release. Applications that were written using the POSIX
1003.4a, Draft 4 interface should be migrated to the new POSIX 1003.1c
standard (or "pthread") interface provided by the POSIX Threads
Library. A compatibility mode for the Draft 4 POSIX 1003.4a interface
has been provided in this release to help ease migration. This
compatibility mode will be removed in a future release.

As products are retired and the operating system evolves, certain
OpenVMS manuals are archived. Archived manuals are no longer maintained
and are not part of the OpenVMS documentation set. However, they are
available on the OpenVMS Documentation CD-ROM and the
following web site:

The Alpha Architecture Reference Manual, Third Edition (AARM)
describes strict rules for using interlocked memory instructions. The
Alpha 21264 (EV6) processor and all future Alpha processors are
more stringent than their predecessors in their requirement that these
rules be followed. As a result, code that has worked in the past,
despite noncompliance, could fail when executed on systems featuring
the 21264 processor and its successors. Occurrences of these
noncompliant code sequences are believed to be rare. Note that
the 21264 processor is not supported on versions prior to OpenVMS Alpha
Version 7.1-2.

Noncompliant code can result in a loss of synchronization between
processors when interprocessor locks are used, or can result in an
infinite loop when an interlocked sequence always fails. Such behavior
has occurred in some code sequences in programs compiled on
old versions of the BLISS compiler, some versions of the MACRO--32
compiler and the MACRO--64 assembler, and in some HP C and C++ programs.

The affected code sequences use LDx_L/STx_C instructions, either
directly in assembly language sources or in code generated by a
compiler. Applications most likely to use interlocked instructions are
complex, multithreaded applications or device drivers using highly
optimized, hand-crafted locking and synchronization techniques.

OpenVMS recommends that code that will run on the 21264 processor be
checked for these sequences. Particular attention should be paid to any
code that does interprocess locking, multithreading, or interprocessor
communication.

The SRM_CHECK tool has been developed to analyze Alpha executables for
noncompliant code sequences. The tool detects sequences that may fail,
reports any errors, and displays the machine code of the failing
sequence.

The SRM_CHECK tool can be found in the following location on the
OpenVMS Alpha Version 7.3-2 Operating System CD-ROM:

SYS$SYSTEM:SRM_CHECK.EXE

To run the SRM_CHECK tool, define it as a foreign command (or use the
DCL$PATH mechanism) and invoke it with the name of the image to check.
If a problem is found, the machine code is displayed and some image
information is printed. The following example illustrates how to use
the tool to analyze an image called myimage.exe:

$ define DCL$PATH []
$ srm_check myimage.exe

The tool supports wildcard searches. Use the following command line to
initiate a wildcard search:

$ srm_check [*...]* -log

Use the -log qualifier to generate a list of images that have been
checked. You can use the -output qualifier to write the output to a
data file. For example, the following command directs output to a file
named CHECK.DAT:

$ srm_check 'file' -output check.dat

You can use the output from the tool to find the module that generated
the sequence by looking in the image's MAP file. The addresses shown
correspond directly to the addresses that can be found in the MAP file.

The following example illustrates the output from using the analysis
tool on an image named SYSTEM_SYNCHRONIZATION.EXE:

The address 360C is in the SMPROUT module, which contains the addresses
from 0-47BB. By looking at the machine code output from the module, you
can locate the code and use the listing line number to identify the
corresponding source code. If SMPROUT had a nonzero base, you would
need to subtract the base from the address (360C in this case) to find
the relative address in the listing file.

Note that the tool reports potential violations in its output.
Although SRM_CHECK can normally identify a code section in an image by
the section's attributes, it is possible for OpenVMS images to contain
data sections with those same attributes. As a result, SRM_CHECK may
scan data as if it were code, and occasionally, a block of data may
look like a noncompliant code sequence. This circumstance is rare and
can be detected by examining the MAP and listing files.