Document revision date: 31 July 2002 | |
Previous | Contents | Index |
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.
5.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
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
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. |
The following release notes concern the SORT32 utility. Note that SORT32 is recommended as a workaround for unresolved problems with Hypersort and for functionality not implemented in Hypersort.
SORT32 has been updated for OpenVMS Alpha Version 7.3-1. The new
version of SORT32 is V07-005.
5.25.1 SORT32 and /PROCESS=TAG for VFC Output Files
V7.3-1
SORT32 now supports /PROCESS=TAG for VFC output files on Alpha.
5.25.2 SORT32 and NAM$L_ESA
V7.3-1
SORT32 now properly uses NAM$L_ESA on Alpha.
5.25.3 SORT32 Diagnostic for Key Too Large (Alpha)
V7.3-1
SORT32 now issues a BAD_KEY diagnostic instead of BADLOGIC for key too
large on Alpha, to more closely match Hypersort diagnostic handling on
Alpha.
5.25.4 SORT/STATISTICS Overflow
V7.3-1
SORT32 now supports larger values for SORT/STATISTICS for working set
extent and work file allocation on Alpha. (This new support is in both
SORT32 and Hypersort.)
5.25.5 SORT32 Protection Mask for Sort Work Files
V7.3-1
SORT32 now sets the protection mask for sort work files to
<RWED,RWED> on Alpha. Previously, the protection mask for sort
work files was set to <D,RWED>. This setting could cause the use
of /WORK_FILES=2 (the default) or higher to report a protection
violation, if the sort work files were redefined to point to a common
directory whose owner UIC did not match the process UIC.
5.25.6 SORT/SPECIFICATION and Compound Conditions---Restriction
V7.3-1
SORT32 does not issue a diagnostic for a compound condition in a key specification file not enclosed in parentheses, such as the following:
/Condition=(Name=Test1, TEST=(Field2 EQ "X") AND (Field3 EQ "A")) |
That condition should instead be specified as:
/Condition=(Name=Test1, TEST=((Field2 EQ "X") AND (Field3 EQ "A"))) |
V7.3-1
SORT32 and Hypersort use different sorting and work file algorithms.
Either sort utility may be faster depending on the input file and the
memory/disk/CPU configuration. Make sure that page file quota is at
least three times the working set extent with either SORT32 or
Hypersort.
5.25.8 SORT32 and Hypersort Performance with Variable Length Records
V7.3-1
SORT32 and Hypersort allocate fixed-sized slots for sort work files
based on the longest record length (LRL) information in the file. To
improve sort performance, try to set LRL information in the file as
close as possible to the actual longest record length. Poor initial
performance may be the result of sorting some files produced by C
programs, because the LRL is set higher than needed (to 32767).
5.25.9 SORT32 Work File Directories---Restriction
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.
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 Possible Per-Threads Security Impact on Alpha Device Drivers
V7.2
See Section 5.20.1 for information about how possible per-thread security
impacts OpenVMS Alpha device drivers.
6.1.2 Alpha and VAX SCSI Device Drivers
V7.3-1
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.1.3.
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.
6.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 higher. (Note that Alpha SCSI drivers, however, must be recompiled and relinked as described in Section 6.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 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.
6.2 Parallel SCSI Support for Logical Unit Numbers---Restriction
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.
6.3 Changes to the IO$_DIAGNOSE Function
The following sections contain IO$_DIAGNOSE changes.
6.3.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].
6.4 CRCTX Routines Enhanced
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:
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.
6.5 Device Driver MON Version Handling
V7.3
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.
6.6 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.
For upgrades from OpenVMS Version 6.2 or 7.0 systems, this change must be made before starting the upgrade procedure. |
Table 6-1 shows the changes to the device description block.
Before Version 7.1 | After Version 7.1 |
---|---|
[AUA0] | [AUA0] |
NAME=AU | NAME=AU |
NODE=3 | DRIVE=SYS$MSBDRIVER |
DRIVER=SYS$MSBDRIVER | IRQ=9 |
IRQ=9 | DMA=(0,1) |
DMA=(0,1) | PORT=(388:4,530:8) |
PORT=(388:4.530:8) | NODE=3 |
Customers using SYS$MANAGER:ISA_CONFIG.DAT files should read
Section A.3.
6.7 Memory Holes on AlphaServer 4100 Systems
V7.1
Physical memory holes may 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 may 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.
Previous versions of OpenVMS Alpha did not efficiently support systems with physical memory holes, which ultimately led to an inefficient use of system memory. The memory management data structures in OpenVMS Alpha Version 7.1 and higher 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:
The mmg$gl_memsize global cell does not contain the memory hole. As a result, the system has only 7/8 GB of memory, but according to the algorithm in releases prior to OpenVMS Alpha Version 7.1, it appears that the device can use the direct DMA window. Yet there is 128 MB of memory beyond the 1 GB border, which requires that the drivers use map registers. To eliminate this problem, drivers using the algorithm in releases prior to OpenVMS Alpha Version 7.1 must substitute it with the following algorithm:
int dma_size; int pages; status = IOC$NODE_DATA (crb, IOC$K_DIRECT_DMA_SIZE, &dma_size); /* dma_size contains the number of megabytes. * convert number of megabytes to bytes. */ dma_size = dma_size * (1024 * 1024); /* Convert number of bytes to number of pages by * dividing by number of bytes per page. */ pages = dma_size / MMG$GL_PAGE_SIZE; |
The driver for the Microsoft Windows Sound System ISA sound card (MSB), SYS$MSBDRIVER, has been removed from the OpenVMS Alpha distribution as of Version 7.0. The following files have been removed:
An enhanced version of this driver, called MMOV$MSBDRIVER, is included in Multimedia Services Version 2.0 for OpenVMS Alpha. This layered product also includes support for video capture and playback, an enhanced version of DECsound, and other audio and video applications.
MMOV$MSBDRIVER provides the same $QIO programming interface as
SYS$MSBDRIVER. Compaq recommends that the WAVE Applications Programming
Interface provided by Multimedia Services for OpenVMS be used instead
because it is more flexible and is portable to other platforms.
(Multimedia Services Version 2.0 for OpenVMS is described in SPD
64.24.00.)
6.9 Device IPL Setup for OpenVMS Alpha Drivers
V6.2
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.
6.10 AlphaStation 255: PCI Configuration Restriction
V7.1
The OpenVMS Alpha operating system does not support PCI option cards configured in PCI slot 0 on any AlphaStation 255 series systems.
PCI slot 0 is the lowest physical PCI option slot on AlphaStation 255
series systems. The interrupt signal for this slot is shared with the
built-in Ethernet port. Because the OpenVMS Alpha operating system does
not currently permit PCI devices to share an interrupt line, a PCI
device installed in slot 0 will not function correctly or may cause
errors to occur with the built-in Ethernet port. As a result of this
restriction, AlphaStation 255 series systems support a maximum of two
PCI option cards, configured in slot 1 and slot 2.
6.11 Recommendation for RZ25M and RZ26N Disk Drives (Alpha)
V7.1
During the testing of Compaq 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 may
be used in configurations to the full bus lengths of the SCSI-2
specification.
6.12 SCSI Controller Restriction on AlphaServer 2100 Systems
The Adaptec 1740/1742 SCSI controller (PB2HA--SA) is not supported on AlphaServer 2100 systems having more than 1 gigabyte (GB) of memory. If the controller is connected to such a system, the following message appears on the operator's console:
%PKJDRVR-E- PKX0, Port is going OFFLINE. |
The following sections relate to SCSI firmware support.
6.13.1 Recommended Firmware Support for RZ26N and RZ28M Disks
V6.2-1H3
The minimum firmware revision level recommended for RZ26N and RZ28M disks is Revision 0568.
If the latest firmware revision level is not used with these disks,
multiple problems can occur.
6.13.2 Required Firmware for Multihost Use of RZ26L and RZ28 Disks
V6.2
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.
Only certain RZ26L and RZ28 firmware revisions can be safely upgraded to firmware revision level 442. Refer to Section 6.13.3 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.13.4 to update the disk's firmware. |
Previous | Next | Contents | Index |
privacy and legal statement | ||
6652PRO_010.HTML |