OpenVMS VMS72_UPDATE-V0200 Alpha V7.2 UPDATE ECO Summary
TITLE: OpenVMS VMS72_UPDATE-V0200 Alpha V7.2 UPDATE ECO Summary
Modification Date: 05-JUN-2000
Modification Type: Documentation Update:
Installation of this kit over itself might cause
a SYS-F-ACCVIO, access violation error. If this
occurs, update the system with the latest version
of the PCSI kit and install this UPDATE kit again.
NOTE: An OpenVMS saveset or PCSI installation file is stored
on the Internet in a self-expanding compressed file.
For OpenVMS savesets, the name of the compressed saveset
file will be kit_name.a-dcx_vaxexe for OpenVMS VAX or
kit_name.a-dcx_axpexe for OpenVMS Alpha. Once the OpenVMS
saveset is copied to your system, expand the compressed
saveset by typing RUN kitname.dcx_vaxexe or kitname.dcx_alpexe.
For PCSI files, once the PCSI file is copied to your system,
rename the PCSI file to kitname-dcx_axpexe.pcsi, then it can
be expanded by typing RUN kitname-dcx_axpexe.pcsi. The resultant
file will be the PCSI installation file which can be used to install
the ECO.
Copyright (c) Compaq Computer Corporation 1999, 2000. All rights reserved.
******************** NOTE *******************
* *
* This kit does *NOT* upgrade the operating *
* system from V7.2 to V7.2-1. *
* *
************************************************
OP/SYS: OpenVMS Alpha
COMPONENTS: APB.EXE CLUE$SDA.EXE
CONVSHR.EXE CONVSHR.EXE
DCL.EXE DEBUG_APB.EXE
DEC$BASRTL.EXE ERRFMT.EXE
EXCEPTION.EXE EXEC_INIT.EXE
F11BXQP.EXE F11CACP.EXE
F11DACP.EXE FC$SDA.EXE
GCU.EXE IOGEN$FIBRE_CONFIG.EXE
IO_ROUTINES.EXE IO_ROUTINES_MON.EXE
LOGICAL_NAMES.EXE MESSAGE_ROUTINES.EXE
MOUNTSHR.EXE MTAAACP.EXE
MULTIPATH.EXE MULTIPATH_MON.EXE
PCSI$MAIN.EXE PCSI$SHR.EXE
PROCESS_MANAGEMENT.EXE PROCESS_MANAGEMENT_MON.EXE
RMS.EXE SDA$SHARE.EXE
SDA.EXE SDA_DEBUG.EXE
SECURESHRP.EXE SECURITY_MON.EXE
SHADOW_SERVER.EXE SHOW.EXE
SVRSYSTEM_MIB.EXE SYS$BASE_IMAGE.EXE
SYS$CPU_ROUTINES_0C05.EXE SYS$CPU_ROUTINES_0C08.EXE
SYS$CPU_ROUTINES_0F05.EXE SYS$CPU_ROUTINES_1105.EXE
SYS$CPU_ROUTINES_1605.EXE SYS$CPU_ROUTINES_1A05.EXE
SYS$CPU_ROUTINES_1B02.EXE SYS$CPU_ROUTINES_1B05.EXE
SYS$CPU_ROUTINES_2005.EXE SYS$CPU_ROUTINES_2208.EXE
SYS$DKDRIVER.EXE SYS$DQDRIVER.EXE
SYS$DUDRIVER.EXE SYS$EIBTDRIVER.EXE
SYS$EIDRIVER.EXE SYS$ERDRIVER.EXE
SYS$EW1000A.EXE SYS$EWBTDRIVER.EXE
SYS$EWDRIVER_DE500BA.EXE SYS$FGEDRIVER.EXE
SYS$FWBTDRIVER.EXE SYS$FXDRIVER.EXE
SYS$IIDRIVER.EXE SYS$IPC_SERVICES.EXE
SYS$LAN.EXE SYS$LAN_ATM.EXE
SYS$LAN_CSMACD.EXE SYS$LAN_FDDI.EXE
SYS$LAN_TR.EXE SYS$LTDRIVER.EXE
SYS$MCDRIVER.EXE SYS$PBDRIVER.EXE
SYS$PGADRIVER.EXE SYS$PIDRIVER.EXE
SYS$PJDRIVER.EXE SYS$PKCDRIVER.EXE
SYS$PKEDRIVER.EXE SYS$PKJDRIVER.EXE
SYS$PKQDRIVER.EXE SYS$PKSDRIVER.EXE
SYS$PKTDRIVER.EXE SYS$PKWDRIVER.EXE
SYS$PKZDRIVER.EXE SYS$PUDRIVER.EXE
SYS$SCS.EXE SYS$SHDRIVER.EXE
SYS$SMDRIVER SYS$TRANSACTION_SERVICES.EXE
SYS$TUDRIVER.EXE SYS$VCC.EXE
SYS$VCC_MON.EXE SYS$VCC_MON.EXE
SYSBOOT.EXE SYSGEN.EXE
SYSINIT.EXE SYSMSG.EXE
SYSTEM_PRIMITIVES.EXE SYSTEM_PRIMITIVES_MIN.EXE
SYSTEM_SYNCHRONIZATION.EXE SYSTEM_SYNCHRONIZATION_MIN.EXE
SYSTEM_SYNCHRONIZATION_UNI.EXE VMOUNT.EXE
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VMS72_UPDATE-V0200
DEC-AXPVMS-VMS72_UPDATE-V0200--4.PCSI
ECO Kits Superseded by This ECO Kit: VMS72_UPDATE-V0100
VMS72_HARDWARE-V0100
VMS72_F11X-V0200
VMS72_F11X-V0100
VMS72_MEM_CHAN-V0100
VMS72_PORTS-V0100
ECO Kit Approximate Size: 83,856 Blocks
Kit Applies To: OpenVMS Alpha V7.2
System/Cluster Reboot Necessary: Yes
Rolling Re-boot Supported: Yes
Installation Rating: INSTALL_1
1 - To be installed on all systems running
the listed version(s) of OpenVMS.
Kit Dependencies:
The following remedial kit(s) must be installed BEFORE
installation of this kit:
None
In order to receive full Fibre Channel functionality in a
mixed-version or mixed-architecture OpenVMS Cluster system,
the following remedial kits or their supersedant kits should
also be installed:
Architecture Version Kit
------------ ------- ---
Alpha V7.1-2 DEC-AXPVMS-VMS712_DRIVER-V0100--4.PCSI
7.1 ALPDRIV11_071
V6.2 ALPDRIV21_062
VAX V7.2 VAXDRIV01_072
V7.1 VAXDRIV05_071
V6.2 VAXDRIV07_062
Remedial Kits Needed for OpenVMS Cluster Compatibility with
Version 6.2, 7.1, 7.1-2, and 7.2.
The following remedial kits must be applied to your systems
running OpenVMS Versions 6.2 and 7.1 prior to introducing an
OpenVMS Version 7.2 system into the cluster. If you are
using Fibre Channel, the version specific kits listed above
are also required.
The following table indicates the facility affected, the name of
the file, the location of the file, and the location of the
documentation.
For locations listed as being on the World Wide Web (WWW),
download the specified kit by accessing the following
Internet site:
http://www.service.digital.com/html/patch_public.html
FACILITY FILE NAME LOCATION DOCUMENTATION
_________ ___________ ________ _____________
OpenVMS ALPCLUSIO01_062 Alpha V7.2 Version 7.2
CLUSTER VAXCLUSIO01_062 CD#2 Release
VAX 7.2 CD Notes,
Section
4.14.1.2
MONITOR ALPMONT01_062 WWW Version 7.2
(Alpha 6.2) Release
ALPMONT02_071 Notes,
(Alpha 7.1) Section
VAXMONT01_062 4.11.1.1
(VAX 6.2)
VAXMONT02_071
(VAX 7.1)
MOUNT ALPMOUN05_062 WWW Version 7.2
(Alpha 6.2) Release
ALPMOUN07_071 Notes,
(Alpha 7.1) Section
VAXMOUN04_062 4.12.1.2
(VAX 6.2)
VAXMOUN04_071
(VAX 7.1)
VOLUME ALPSHAD08_062 WWW Version 7.1
SHADOWING (Alpha 6.2) Release
ALPSHAD05_071 Notes,
(Alpha 7.1) Section
VAXSHAD08_062 4.15.1.2 and
(VAX 6.2) Version 7.1
VAXSHAD05_071 New Features,
(VAX 7.1) Section 3.11.10
ECO KIT SUMMARY:
An ECO kit exists for OpenVMS Alpha V7.2. This kit addresses the following
problems:
Problems Addressed in VMS72_UPDATE-V0200:
o Certain non-privileged programming errors and certain command
errors within specific non-privileged DCL commands can trigger
an OpenVMS system service exception and a resulting system
crash.
The bugcheck is "SSRVEXCEPT, Unexpected system service
exception", and the crash itself can be identified by locating
a reference to the EXE$NAM_TO_PCB routine and the
PROCESS_MANAGEMENT module in the contents of the stack present
at the time of the system crash, and specifically by looking
in a stack frame prior to the failing stack frame in the
system crashdump. The user or the application that has issued
the errant DCL command or the errant system service call can
also be determined from the contents of the system crashdump.
This problem has been identified in all OpenVMS V7.2 systems
with the VMS72_UPDATE-V0100 and/or VMS72_HARDWARE-V0100 ECO
kit(s) installed. No other OpenVMS Alpha releases or ECO kits
are affected, nor is OpenVMS VAX affected. If you are unsure
if you have installed the VMS72_UPDATE-V0100 and/or
VMS72_HARDWARE-V0100 ECO kit(s), the following command will
produce a list of the OpenVMS kits installed on your system:
PRODUCT SHOW PRODUCT VMS/FULL
NOTE:
If you have already installed the VMS72_HARDWARE-V0100 and/or
VMS72_UPDATE-V0100 kit(s), you can install the VMS72_SYS-V0100
remedial kit to obtain this fix. You do not need to install
this VMS72_UPDATE-V0200 remedial kit for this fix only.
Images Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
- [SYS$LDR]PROCESS_MANAGEMENT_MON.STB
New Functionality Addressed in VMS72_HARDWARE-V0100:
o This kit provides new support for the following new Alpha
systems and hardware options:
+ Support for Compaq AlphaServers GS60, GS140, and DS20
+ New Fibre Channel storage interconnect
+ Gigabit Ethernet, a new high bandwidth standard in Ethernet
technology
+ Memory Channel Version 2.0
+ OpenVMS Galaxy configurations on Compaq AlphaServers GS60
and GS140 systems
o With the introduction of this kit, support is provided for the
new Compaq AlphaServers GS60, GS140, and the DS20. The
AlphaServers include the 21264 processor (EV6) technology.
o The Fibre Channeladapter, the KGPSA-BC, is supported on OpenVMS
Alpha Version 7.2 with this kit. OpenVMS Alpha Version 7.2
with this kit provides support for Fibre Channel as a shared
OpenVMS Cluster storage interconnect. Fibre Channel is a new
ANSI standard network and storage interconnect that offers many
advantages over other interconnects, including high speed
transmission, 100 megabytes per second, and long interconnect
distances, up to 500 meters per link.
Multiple paths to Fibre Channel storage are supported. A
multi-Fibre Channel configuration provides failover from one
path to a device to another path to the same device. Multiple
paths to the same device increase the availability of that
device for I/O operations. Multiple paths also offer higher
aggregate performance.
+ Fibre Channel disks can be MSCP served to other nodes in a
mixed-version or mixed-architecture OpenVMS Cluster system,
provided the correct Fibre Channel remedial kit is installed
on each node. The following list gives the required minimum
kit revision for Alpha and VAX cluster nodes:
* Alpha systems
- Version 6.2: ALPDRIV21_062
- Version 7.1: ALPDRIV11_071
- Version 7.1-2: DEC-AXPVMS-VMS712_DRIVER-V0100-4.PCSI
* VAX systems
- Version 6.2: VAXDRIV07_062
- Version 7.1: VAXDRIV05_071
- Version 7.2: VAXDRIV01_072
+ OpenVMS supports Fibre Channel on the following AlphaServer
models at initial release:
* AlphaServer 800
* AlphaServer 1200
* AlphaServer 4000, 4100
* AlphaServer 8200, 8400
Note that the GS60, the GS140, and the DS20 are not initially
supported. Support for these models is expected soon. For
the most up-to-date list, refer to the OpenVMS Cluster
Software SPD.
+ Specific installations instructions for Fibre Channel support
are included below. The recommended procedure is given
first, followed by another procedure if you have already
installed one or more Fibre Channel hardware adapters
(KGPSA(s)).
+ For detailed Fibre Channel configuration support, including
configuration requirements and restrictions, refer to the
updated Fibre Channel and Multipath chapters of Guidelines
for OpenVMS Cluster Configurations in this kit. The file
name is FC_MULTIPATH_CH.PS. To extract the file from the
kit, execute the following comand:
PRODUCT EXTRACT FILE VMS72_HARDWARE /SELECT=FC_MULTIPATH_CH.PS
/SOURCE=(file destination)
This file will also be located in the SYS$HELP directory after
installation.
These chapters are also available on the World Wide Web at the
following address:
http://www.openvms.digital.com/
Refer to the OpenVMS Cluster Software SPD for the most
up-to-date Fibre Channel support information.
o OpenVMS Alpha Version 7.2 together with this kit provide run-time
support for the DIGITAL PCI-to-Gigabit Ethernet adapter (DEGPA).
The DEGPA incorporates a new technology that transfers data at a
rate of one gigabit per second-ten times the rate of a Fast
Ethernet adapter. Gigabit Ethernet technology addresses congestion
experienced at the backbone and server levels by today's networks.
The DEGPA is supported on single systems and as a cluster
interconnect. The nodes in a Gigabit Ethernet OpenVMS Cluster
system are connected to a Gigabit Ethernet switch. If there are
only two nodes, they can be connected point-to-point so that no
switch is needed. For more information about Gigabit Ethernet
support, see OpenVMS Version 7.2 New Features.
+ Attempts to add a Gigabit Ethernet node to an OpenVMS Cluster
over a Gigabit Ethernet switch will fail if the switch does
not support autonegotiation. The DEGPA enables autonegotia-
tion by default, but not all Gigabit Ethernet switches support
autonegotiation. The Gigaswitch made by Cabletron does
not. Furthermore, the messages that are displayed may be
misleading. For example, if the node is being added via
CLUSTER_CONFIG.COM and the option to install a local page
and swap disk is selected, the problem may look like a
disk-serving problem. The node running CLUSTER_CONFIG.COM
displays the message "waiting for to boot," while
the booting node displays "waiting to tune system." The list
of available disks is never displayed because of a missing
network path. The network path is missing because of the
autonegotiation mismatch between the DEGPA and the switch.
To avoid this problem:
* Perform a conversational boot when first booting the
node into the cluster.
* Set the new node's SYSGEN LAN_FLAGS parameter to a
value of 32 to disable autonegotiation on the DEGPA.
o MEMORY CHANNEL Version 2.0 is supported on OpenVMS Version 7.2.
The final qualification of MEMORY CHANNEL Version 2.0 hardware
was completed on systems running OpenVMS Version 7.2 and this kit.
For that reason, this kit is recommended for MEMORY CHANNEL Version
2.0 hardware support.
MEMORY CHANNEL Version 2.0 provides the following new capabilities:
+ Support for a new adapter (CCMAB-AA) and a new hub (CCMHB-AA)
+ Support for simultaneous communication between four
sender-receiver pairs
+ Support for longer cables for a radial topology up to 3 km
* Copper cables (3 sizes) up to a 10-m (32.8 ft) topology
* Fiber-optic cables up to a 3-km topology Fiber-optic
cables up to 30 meters are available from Compaq.
Fiber-optic cables up to 3 kilometers are available
from other vendors.
Note that you can configure a computer in an OpenVMS Cluster
system with both a MEMORY CHANNEL Version 1.5 hub and a MEMORY
CHANNEL Version 2.0 hub. However, the version number of the
adapter and the cables must match the hub's version number for
MEMORY CHANNEL to function properly.
For more information about MEMORY CHANNEL, refer to Guidelines
for OpenVMS Cluster Configurations for OpenVMS Version 7.2.
o This kit provides support for OpenVMS Galaxy configurations on
AlphaServer GS60 and GS140 systems. Customers can run three
instances of OpenVMS on AlphaServer GS140 systems or two instances
on AlphaServer GS60 systems.
To create an OpenVMS Galaxy environment on AlphaServer GS60 and
GS140 systems, install this kit and download the latest version
of the V5.4-xx console firmware from the following location:
http://ftp.digital.com/pub/Digital/Alpha/firmware
/interim/gs60gs140/gs140.html
To install the console firmware, follow the procedures described
in the OpenVMS Alpha Galaxy Guide. The latest version of this
guide is available at:
http://www.openvms.digital.com:81/
For more information about how to create and manage an OpenVMS
Galaxy computing environment, refer to the OpenVMS Alpha Galaxy
Guide.
Known Restrictions:
o If you have an AlphaServer GS140 and are running OpenVMS Version
7.2, you must install this kit prior to installing the KN7CG-AB
6/525 MHz (EV6) CPU modules.
o AlphaServer GS60/GS140 configurations with more than a single
I/O Port Module, KFTHA-AA or KFTIA-AA, might experience system
crashes.
When upgrading OpenVMS Galaxy and non-Galaxy AlphaServer
8200/8400 configurations with multiple I/O Port Modules to
GS60/GS140 systems, customers must install one minimum revision
B02 KN7CG-AB 6/525 (EV6) CPU (E2063-DA/DB rev D01) module as
described in Compaq Action Blitz # TD 2632.
For complete details about this restriction and its solution, refer
to Compaq Action Blitz # TD 2632.
o On Compaq AlphaServer DS20 systems, you cannot use the following
system routines to perform I/O tribyte reads and writes:
+ IOC$READ_PCI_CONFIG
+ IOC$WRITE_PCI_CONFIG
+ IOC$READ_IO
+ IOC$WRITE_IO
If a device driver calls any of these system routines with a length
of three, you must use one of the following methods instead,
depending on your I/O cards characteristics:
+ For IOC$READ_IO and IOC$READ_PCI_CONFIG:
- Use a longword read, and mask out the byte.
- Do a combination of word and byte reads, and append the
data.
+ For IOC$WRITE_IO and IOC$WRITE_PCI_CONFIG:
- Read a longword, modify the tribyte, and rewrite the
longword.
Note that AlphaServer 8200/8400 and GS60/140 systems with Alpha
21264 CPUs support tribyte reads and writes.
o This note applies to Compaq AlphaServer DS20 systems. When device
drivers call the IOC$CRAM_CMD, IOC$READ_IO, and IOC$WRITE_IO system
routines with the IOC$K_WORD or IOC$K_WORD_LANED parameters, the
I/O address must be on a natural, word-aligned boundary. (In other
words, the I/O address must be an even number). If the I/O address
is an odd number, these system routines return SS$_BADPARAM.
Problems Addressed in VMS72_HARDWARE-V0100:
o There have been various crashes on systems with more than
1 Gbyte of memory (excluding 4100, 4000, and 1200 systems).
The crashes occur because the driver thinks the DMA window
covers its transmit or receive buffer. The device either
transmits bad data, causing an I/O machine check, or corrupts
memory on the system when a buffer is above 1 gigabyte.
Image(s) Affected: [SYS$LDR]SYS$EW1000A.EXE
o On a cable pull, the system potentially could crash, reporting
an invalid exception (INVEXCEPTN, Exception while above ASTDEL).
Image(s) Affected: [SYS$LDR]SYS$PKWDRIVER.EXE
o On a cable pull, the system potentially could crash, reporting
an invalid exception (INVEXCEPTN, Exception while above ASTDEL).
Image(s) Affected: [SYS$LDR]SYS$PKWDRIVER.EXE
o If the internal connector on a KZPCA is used, the drives
connected on this SCSI bus are not seen. If the
corresponding external connector is used, the drives are
seen.
Image(s) Affected: [SYS$LDR]SYS$PKWDRIVER.EXE
o A manually connected device might end up on the wrong DDB
chain. This could happen if existing device letters are
used for a different device driver. Load_driver will
allocate the UCB of the size supplied by the specified
driver. It will then link this UCB to the existing DDB
with the same device letters. The DPT pointer of this
DDB, however, will point to a different DPT.
This behavior did not previously cause a problem.
However, with the introduction of the displayable path,
the displayable path offset specified in one DPT might be
totally incompatible with another. This potentially
leads to a system crash. To avoid this, IOGEN-CONNECT
now compares DPT pointers in DDB and in LDDB. If they
are different, then IOGEN will fail to connect this
device.
This fix also creates a new error message:
SYSTEM-E-WRONGDRV wrong device driver for device
Following is the HELP/MESSAGE text for this message
Facility: SYSTEM, System Services
Explanation: This message can occur if user issues SYSMAN
IO CONNECT command and specifies device letters
that are already used on the system and belong
to ifferent device driver.
User Action: Use diffferent device letters.
Image(s) Affected:
- [SYSLIB]IOGEN$SHARE.EXE
- [SYSMSG]SYSMSG.EXE
o The execution throttle limits the number of simultaneous
I/O commands sent to each device by the Qlogic chip. It
should have been but was not set to the quantities defined
by the EEROMCONFIG utility. The hardware default appears
to have been 3 rather than the more appropriate EEROMCONFIG
default of 16. This fix provides approximately 50% improvement
in the number of I/O's /sec when 15 simultaneous streams read
2-block transfers from a disk on an HSZ.
Image(s) Affected: [SYS$LDR]SYS$PKQDRIVER.EXE
o IOGEN could configure a remote path in a multipath device
set even though the MPDEV_REMOTE SYSGEN parameter was
off.
Image(s) Affected:
- [SYS$LDR]IO_ROUTINES.EXE
- [SYS$LDR]IO_ROUTINES_MON.EXE
- [SYS$LDR]EXEC_INIT.EXE
- [SYSLIB]IOGEN$SHARE.EXE
- [SYSLIB]LIB.MLB
- [SYSLIB]LIB.L32
- [SYSLIB]LIB.REQ
- [SYSLIB]SYS$LIB_C.TLB
o Fix the SHOW command to display MntVerifyTmout only if
the valid bit is cleared on the current as opposed to the
primary path. Previously, if the primary path had never
been mounted, SHOW will display MntVerifyTimeout even
though the device is successfully mounted on the other
path and functions properly.
Image(s) Affected: [SYSEXE]SHOW.EXE
o Register R3 is not preserved on a call from IOGEN$INIT_UNIT
and IOC$UNIT_INIT, resulting in R3 corruption.
This problem was seen when a TL6 V7.2 system failed to
boot with a KDM70.
Image(s) Affected: [SYS$LDR]SYS$PUDRIVER.EXE
Problems Addressed in VMS72_UPDATE-V0100:
o System crash while executing Fast I/O if a call to
SYS$CREATE_BUFOBJ from SYSFASTIO returns error
%SYSTEM-F-INSFSPTS
Image(s) Affected:
- [SYS$LDR]IO_ROUTINES.EXE
- [SYS$LDR]IO_ROUTINES_MON.EXE
o Process hang in RWAST state during image or process rundown.
The process has user defined virtual regions. There is also
direct I/O outstanding for this process.
This can occur if the system is running Oracle7 or Oracle8
and MULTINET.
Image(s) Affected:
- [SYS$LDR]SYSTEM_PRIMITIVES.EXE
- [SYS$LDR]SYSTEM_PRIMITIVES_MIN.EXE
o Random INCONSTATE bugchecks at offset SYS$VCC+08BB4 with
condition code 213C = %SYSTEM-F-CVTUNGRANT, cannot
convert an ungranted lock, in R0.
Image(s) Affected:
- [SYS$LDR]SYS$VCC.EXE
- [SYS$LDR]SYS$VCC_MON.EXE
o System crash during heavy RMS and $BRKTHR usage
Image(s) Affected:
- [SYS$LDR]IO_ROUTINES.EXE
- [SYS$LDR]IO_ROUTINES_MON.EXE
o Privileged images are unable to create logical names.
Image(s) Affected:
- [SYS$LDR]LOGICAL_NAMES.EXE
- [SYS$LDR]LOGICAL_NAMES.STB
o Heavy $GETQUI use could induce a nonfatal SSRVEXCEPT
bugcheck at EXE$GETQUI_CONTEXT_FIND_C+00018. This causes
the user's process to go away.
It has also induced a fatal DOUBLDEALO bugcheck at
EXE$DEALLOCATE_C+00114, when trying to deallocate a P1
context packet (in R0) that has already been deallocated.
Image(s) Affected: [SYS$LDR]MESSAGE_ROUTINES.EXE
o ASTEN item code for $GETJPI does not work for processes
other than the current process
Image(s) Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
- [SYS$LDR]PROCESS_MANAGEMENT_MON.STB
o System ACCVIO in $SETPRN.
Image(s) Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
- [SYS$LDR]PROCESS_MANAGEMENT_MON.STB
o For an ISO9660 formatted CD, if the directory name in a
directory command is in lower case, the command fails
with a directory not found error. If the directory name
is in upper case, the command is successful.
Image(s) Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
- [SYS$LDR]PROCESS_MANAGEMENT_MON.STB
o Calling the SYS$SETPRN system service providing only the
process name parameter may cause the system to crash.
Image(s) Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
- [SYS$LDR]PROCESS_MANAGEMENT_MON.STB
o Processes running LOGINOUT can enter a non-terminating
loop.
A system crash occurs due to an access violation in
SYSGETJPI.
Image(s) Affected:
- [SYS$LDR]PROCESS_MANAGEMENT.EXE
- [SYS$LDR]PROCESS_MANAGEMENT.STB
- [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE
- [SYS$LDR]PROCESS_MANAGEMENT_MON.STB
- [SYSEXE]PROCESS_MANAGEMENT_MON.STB
o P1 pages locked by routine PGFIPLHI are being unlocked by
other programs. This results in a PGFIPLHI system crash.
Image(s) Affected: [SYS$LDR]SECURITY_MON.EXE
o MSCPCLASS, Fatal error detected by MSCP class driver.
This problem has been seen after HSC failures.
Image(s) Affected:
- [SYS$LDR]SYS$DUDRIVER.EXE
- [SYS$LDR]SYS$TUDRIVER.EXE
o When Shadowset members are removed from the set after the
MSCP server has lost connections to the local MSCP
device, SHADDETINCON crashes.
Image(s) Affected: [SYS$LDR]DUDRIVER.EXE
o If an MSCP server has a non-zero allocation crash, the
system can crash with an INCONSTATE bugcheck at
SYS$DUDRIVER+0D038.
Image(s) Affected: [SYS$LDR]DUDRIVER.EXE
o In a single node cluster, when user I/O is active to the
quorum disk and Mount Verification occurs. Quorum is
lost and the system hangs.
Image(s) Affected: [SYS$LDR]SYS$DKDRIVER.EXE
o Duplicate Units seen from some SCSI disks in 3 node SCSI
clusters.
Image(s) Affected: [SYS$LDR]SYS$DKDRIVER.EXE
o INVEXCEPTN system crash. The bugcheck type is
INVEXCEPTN, exception while above ASTDEL
Image(s) Affected: [SYS$LDR]SYS$DKDRIVER.EXE
o INVEXCEPTN System crash due to memory corruption. In
this particular case a driver image was overwritten by
some user data.
Image(s) Affected: [SYS$LDR]SYS$DKDRIVER.EXE
o A system may crash with an "INVEXCEPTN above ASTDEL",
access violation, when using HSZTERM, the HSZxxx
configuration tool.
Image(s) Affected: [SYS$LDR]SYS$DKDRIVER.EXE
o System crashes with INVEXCEPTN due to attempt to deallocate
a buffer twice.
Image(s) Affected: [SYS$LDR]SYS$PKSDRIVER.EXE
o An 895 LVD adapter is being qualified by the Server
Group. This adapter will also use PKWDRIVER and there
has been a request to differentiate between the 895 LVD
adapter and the 896 LVD adapter, which will be released
later.
Image(s) Affected: [SYS$LDR]SYS$PKWDRIVER.EXE
o When DECnet-IV starts on a DEMFA (FX) device, it attempts
to set FDDI characteristics for the FDDI ring. The
request to the driver fails so DECnet does not complete
the startup successfully. Therefore, DECnet is not
usable on the device.
Image(s) Affected: [SYS$LDR]SYS$FXDRIVER.EXE
o Reduce the number of map registers needed by the DE425
driver so that two adapters can be configured on an
AlphaServer 2100.
Image(s) Affected: [SYS$LDR]SYS$ERDRIVER.EXE
o The following corruption is a LAN packet causes a system
to crash with an "INVEXCEPTN, Exception while above
ASTDEL". The PC related to the crash is:
SYS$LAN_CSMACD_NPRO+05F80: LDL R26,#X0238(R5)
Image(s) Affected:
- [SYS$LDR]SYS$LAN.EXE
- [SYS$LDR]SYS$LAN_TR.EXE
- [SYS$LDR]SYS$LAN_FDDI.EXE
- [SYS$LDR]SYS$LAN_CSMACD.EXE
- [SYS$LDR]SYS$LAN_ATM.EXE
o When using an HSG80 with 104 DGA devices, an attempt to
configure those devices results in an SSRVEXCEPT crash.
Image(s) Affected: [SYSLIB]IOGEN$FIBRE_CONFIG.EXE
o In the output to CLUE SCSI/SUMMARY, LUNs (Logical Unit
Number) that require more than two digits to represent
are printed as "**" instead of the correct designation
Image(s) Affected: [SYSLIB]CLUE$SDA.EXE
o MOUNT/SYSTEM fails with a %MOUNT-F-IVBUFLEN error when
attempting to MOUNT an ISO9660 CDrom which has a volume
label of more than 27 characters.
Image(s) Affected:
- [SYSLIB]MOUNTSHR.EXE
- [SYSEXE]VMOUNT.EXE
o Add the following switch and options to the MOUNT
command:
/POLICY=REQUIRE_MEMBERS
This switch forces all specified members to be available
for MOUNT to occur. It is used in disaster-tolerant
configurations where another site may have a more recent
disk that is not available. In effect, this will force
more human decision making.
/POLICY=VERIFY_LABELS
This requires that all copy targets must have the label
'SCRATCH_DISK' or they will not be added to the set. The
volume must be ODS2 and have a valid file structure. It
forces users to use alternate volume labels. One of the
biggest causes of adding the wrong disk to a shadow set
is mis-typed commands. This gives users a way to be sure
that they only add "scratch" disks to shadow sets, making
it less likely that they will lose data.
This is similar to the /CONFIRM, except that it can also
be used in command procedures without immediate operator
intervention. It is also similar to the /NOCOPY command,
except that it allows copies to occur, as long as the
label is 'scratch'.
Image(s) Affected:
- [SYSLIB]MOUNTSHR.EXE
- [SYSEXE]VMOUNT.EXE
- [SYSMSG]SYSMSG.EXE
o This fix corrects %MOUNT-F-VOLALRMNT errors that are
received when MOUNTing multiple CDs privately
Image(s) Affected:
- [SYSLIB]MOUNTSHR.EXE
- [SYSEXE]VMOUNT.EXE
o As part of OpenVMS V7.2, the CONVERT utility was modified
to eliminate a previous design constraint in which the
output file would temporarily become vulnerable to user
access during the exchange of the file between CONVERT
and the SORT32 utility. This would occur during the FAST
load processing of the secondary keys of the file. (For
more details see Section 3.21 of the V7.2 New Features
manual)
As part of this modification, some changes were added to
read records from the newly created output file while
processing alternate keys. In the case of an indexed
file with fixed-length records, it turns out that the
logic for determining if both key and record compression
were disabled for the primary key was flawed and can lead
to a record length being incorrectly calculated. This
can result in the overwriting of internal structures
contiguous to a temporary convert buffer and cause
various errors, ranging from sort errors (SORT_ON) to
user-mode access violations.
In order for this problem to occur, the indexed file must
have ALL four of the following characteristics:
+ FIXED length record format
+ More than 2 keys
+ Primary key of type STRING
+ Primary key must have either key or record
compression (or both) enabled
Image(s) Affected: [SYSLIB]CONVSHR.EXE
o An invalid exception crash occurs when rebooting a
Rawhide Galaxy system with a KFPSA installed.
Image(s) Affected: [SYS$LDR]SYS$CPU_ROUTINES_1605.EXE
o MC$INTERRUPT immediately clears the LCSR interrupt flag
bits so that subsequent interrupts will be seen. The
problem is that this means the DEVICE_ATTENTION error log
entries are always clear.
Also, community state was being written to the PDT
instead of DMP.
Image(s) Affected: [SYS$LDR]SYS$MCDRIVER.EXE
o A system crash can occur because of a zero status IOSB/
IOST in an IO to SHDRIVER. Crashes result from application code
not being able to handle the zero status.
Image(s) Affected:
- [SYS$LDR]SYS$SHDRIVER.EXE
- [SYSEXE]SHADOW_SERVER.EXE
o SHADDETINCON crashes in SHD_LOCK SHLK$MERGE_SIGNAL routine.
Image(s) Affected:
- [SYS$LDR]SYS$SHDRIVER.EXE
- [SYSEXE]SHADOW_SERVER.EXE
o Names passed to the F11C/D ACP are rejected with an
SS$_NOSUCHFILE error when passed (via RMS) to the
processor. These names were previously accepted by the
F11C/D ACP processor.
Image(s) Affected:
- [SYSEXE]F11CACP.EXE
- [SYSEXE]F11DACP.EXE
o When two processes are competing to dismount a volume,
one process may be just a bit faster than the other and
delete the VCB and other structures before the second
process has time to finish up its processing. This
results in a UNXSIGNAL/ACCVIO.
Image(s) Affected: [SYS$LDR]F11BXQP.EXE
o A device reporting a read error (SS$_PARITY) during read
write processing in the XQP will attempt to record the
bad blocks and FID in the BADLOG.SYS file. When the
internal close operation occurs (on BADLOG) the system
XQPERR bugchecks when it finds that the process's dirty
buffers have not been writing out.
Image(s) Affected: [SYS$LDR]F11BXQP.EXE
o In a BVS (bound volume set), where the first member of
the set is being simultaneoulsly mounted (parallel), the
VCB may not yet be available. In this case, the system
will get a UNXSIGNAL/ACCVIO.
Image(s) Affected: [SYS$LDR]F11BXQP.EXE
o When a process is dismounting a device, at one point, it
may have to wait while getting rid of the extent cache
(by calling serial_cache). At the latter portion of the
dismount operation, the process also owns the IO database
mutex. The system deadlocks because the process that
owns the mutex is waiting for the serial cache, but the
process that owns the serial cache is waiting for the IO
database mutex.
Image(s) Affected: [SYS$LDR]F11BXQP.EXE
o A 'no such file' error can occur if a process touches a
file header marked as a primary header, but the FCB in
memory indicates that this is still an extension header.
This problem is observed in at least two ways.
+ A file appears normal on one node, but shows as 'no
such file' from another node.
+ BACKUP or DUMP /HEADER will encounter a read
attributes error of NOSUCHFILE when an attempt is
made to read a file header in which the FCB for the
old header is still in memory.
Image(s) Affected: [SYS$LDR]F11BXQP.EXE
o If any send or receive failures were reported by the
Ethernet LAN driver, a LATCP SHOW LINK/COUNTER command
would display incorrect values in other LAN counter
fields.
Image(s) Affected: [SYS$LDR]SYS$LTDRIVER.EXE
o The IPC system service does not support the special event
flag EFN$C_ENF. IPC had not been updated to support this
new EFN and thus is inconsistent with the rest of our
system services. This flag is used to avoid event flag 0
conflicts in multi-threaded applications.
Image(s) Affected: [SYS$LDR]SYS$IPC_SERVICES.EXE
o Unprivileged users cannot manipulate tape devices.
Image(s) Affected: [SYSEXE]MTAAACP.EXE
o The CHP$M_DEFPRIV option has no affect on results.
Image(s) Affected: [SYSLIB]SECURESHRP.EXE
o It is possible to install a page or swap file with an
invalid file header. For example, when the system crashes
in the middle of the creation of the file. When the
system later attempts to write to the file the system
crashes with either a VBNMAPFAIL bugcheck (if trying to
write to the pagefile) or an OUTSWPERR bugcheck (if
trying a swap operation).
Image(s) Affected:
- [SYSEXE]SYSGEN.EXE
- [SYSEXE]SYSINIT.EXE
o ACMS SI, RDb SQL and/or DECdtm $ADD_BRANCH(W) calls fail
with an IPC-E-BCKTRNSFAIL bugcheck. This occurs on
platforms running V7.1 and DECnet Plus where a
distributed transaction was being initiated.
Image(s) Affected: [SYS$LDR]SYS$TRANSACTION_SERVICES.EXE
o A SSRVEXCEPT (ACCVIO) in SYS$TRANSACTION_SERVICES occurs
when an RDB recovery process is killed after it has been
identified as stalling the system.
Image(s) Affected: [SYS$LDR]SYS$TRANSACTION_SERVICES.EXE
o Fix to SYS$FILESCAN to prevent return of SYSTEM-F-ACCVIO
error
If the input buffer descriptor (mandatory first argument)
passed to SYS$FILESCAN contains both a zero length and a
zero buffer pointer, a probe results in a fatal system
error (SYSTEM-F-ACCVIO) being returned to the caller.
The process is not terminated since the probe allows the
actual access violation to be avoided; instead the ACCVIO
fatal error is returned to the application for it to
handle.
For this problem to occur the mandatory first argument in
the call to SYS$FILESCAN must contain a descriptor with
both a zero length and a zero pointer to the string to be
searched for the file specification. In other words, it
is not passing any file specification. It is not only
doing a no-op call to SYS$FILESCAN but not allocating a
valid buffer for its null request -- which should make it
a rarity.
This problem is specific to Alpha and was introduced in
Alpha V7.1. The fix is included in the next release
after OpenVMS Alpha V7.2.
Image(s) Affected: [SYS$LDR]RMS.EXE
o With multiple kernel threads enabled, applications which
use the C runtime library routine getenv may fail due to
the stack of the calling thread being corrupted. This
usually presents itself as random access violations. The
bad address is always a process identification (PID) of
one of the kernel threads in the process.
Applications which use getenv may also hang with all
threads in the HIB state. The initial kernel thread will
have user mode ASTs disabled.
Image(s) Affected: [SYSEXE]DCL.EXE
o Allow F$GETDVI to return the correct string for its item
code MT3_DENSITY.
Image(s) Affected: [SYSEXE]DCL.EXE
o Under some conditions, a traceback list from a fatal
error in a DEC BASIC program would indicate some
incorrect line numbers. This DEC$BASRTL.EXE fixes the
stack correctly before displaying the traceback, so that
the line numbers are correct. Note that an updated
TRACE.EXE may also be required to correct all of the line
numbers.
This also fixes an I/O error recovery problem where
certain I/O failures would report the wrong error code.
Image(s) Affected: [SYSLIB]DEC$BASRTL.EXE
o When there are multiple patch kits that ship the same
image or file and the patch kits are installed out of
order, POLYCENTER Software Installation utility can
ACCVIO when trying to resolve file conflict.
Image(s) Affected:
- [SYSEXE]PCSI$MAIN.EXE
- [SYSLIB]PCSI$SHR.EXE
- [SYSUPD]PCSI$CREATE_ACCOUNT.COM
- [SYSUPD]PCSI$CREATE_NETWORK_OBJECT.COM
- [SYSUPD]PCSI$CREATE_RIGHTS_IDENTIFIER.COM
- [SYSUPD]PCSI$DELETE_ACCOUNT.COM
- [SYSUPD]PCSI$DELETE_NETWORK_OBJECT.COM
- [SYSUPD]PCSI$DELETE_RIGHTS_IDENTIFIER.COM
- [SYSUPD]PCSI$EXTRACT_TLB.COM
- [SYSUPD]PCSI$REGISTER_PRODUCT.COM
Problems Addressed in VMS72_F11X-V0200:
o Since the VMS72_F11X-V0100 kit only checks to see if the
VMS72_UPDATE-V0100 kit has been installed, the installation
fails if only the VMS72_HARDWARE-V0100 kit is installed. Since
the VMS72_HARDWARE-V0100 kit includes the VMS72_UPDATE-V0100 kit,
the installation should also check to see if the
VMS72_HARDWARE-V0100 kit is installed and continue the installation
if it has been.
This kit corrects this problem by checking for both the
VMS72_UPDATE-V0100 and VMS72_HARDWARE-V0100 kits.
There are no functional changes in this kit. If you have
installed the VMS72_F11X-V0100 kit, you do not need to install
this kit.
Problems Addressed in VMS72_F11X-V0100:
o An XQPERR bugcheck in LOCKERS can occur when the retry limit
on the F11B$x lock is reached.
This problem can occur when the owner of the $x lock is
running at a high process process priority and a number of
processes that are in a clustered system are also trying to
validate this lock, but at a lower process priority.
Image(s) Affected - [SYS$LDR]F11BXQP.EXE
o After releasing the current process's IPL/Fork lock, a
system can crash with an SPLACQERR bugcheck
Image(s) Affected - [SYS$LDR]F11BXQP.EXE
o A directory file becomes "corrupt" and DUMP/DIRECTORY
displays a block similar to the following:
Virtual block number 3574 (00000DF6), 512 (0200) bytes
0000 Directory Entry:
0000 Size: 508
0002 Version limit: 32767
0004 Type: 0 (FID)
0005 Name count: 24
0006 Name: COSLR1201_01_JUPICC2.LIS
001E Version: 7859 FID: (40993,5,0)
0026 Version: 7858 FID: (40990,1,0)
002E Version: 7857 FID: (40988,3,0)
...
01E6 Version: 7802 FID: (40455,1,0)
01EE Version: 7801 FID: (40454,1,0)
01F6 Version: 32767 FID: (16744447,65535,0)
01FE End of records (-1)
The directory shuffle code creates the above erroneous
directory entry for the following reasons:
1. So that a new directory buffer will have a valid
structure (this allows VALIDATE_DIRBLK to write
the block to disk); and
2. The entry will be spotted as incorrect (via VERIFY)
if the system crashes in the middle of this shuffle.
After the directory block (with the erroneous directory entry)
is written to disk, the bad entry is removed. A subsequent
call to READ_BLOCK assumes that the block comes from the
buffer cache and not from disk. Under heavy load, this
assumption may not be true as the directory block may have
been kicked out of the cache.
Image(s) Affected - [SYS$LDR]F11BXQP.EXE
o XQP DELETE code accepts an FCB (File Control Block) off the
limbo queue if not IO$V_DELETE. This prevents the
invalidation of VIOC cache blocks as the result of a RENAME
operation. This causes a large amount of XQP (FCB) and VIOC
(CFCB) non-paged pool usage as well as XQPERR bugchecks.
Image(s) Affected - [SYS$LDR]F11BXQP.EXE
o Under the following circumstances,
1. A directory with multiple headers (e.g., from a large ACL)
is deleted on one node (A) in a cluster; and
2. the directory had been previously accessed on another node
(B) in the cluster,
The files created with the previously deleted headers in step
1 would show up on node B with the error:
%SYSTEM-F-NOSUCHFILE, no such file.
Image(s) Affected - [SYS$LDR]F11BXQP.EXE
Problems Addressed in VMS72_MEM_CHAN-V0100:
o Hub Timeout Errors, Memory Channel Port Re-initialization, Virtual
Circuit Closure
Customers who install or upgrade to V7.1-2 or later versions of
OpenVMS ALPHA may experience Hub Timeout errors, Memory Channel port
re-initialization and virtual circuit closure on Memory Channel 1.0
or 1.5 devices. This problem is not seen on Memory Channel 2.0
devices. In some cases the memory channel adapter has been set
offline and the customer must reboot to re-enable it.
Image(s) Affected:
- [SYS$LDR]SYS$MCDRIVER.EXE
o Heart Beat Timeout causes a CPUSPINWAIT system crash
CPUSPINWAIT system crashes may occur if Memory Channel 1.x adapters
experience hardware errors while Heartbeat Timeout is enabled.
Image(s) Affected:
- [SYS$LDR]SYS$MCDRIVER.EXE
Problems Addressed in the VMS72_PORTS-V0100 Kit:
o FAST_PATH RSPID=0 and "stale" CDRP in SCS$GL_RDT, SYS$DUDRIVER
INVEXCEPTN
The cluster-related problems that can occur are:
1. SYS$SCS FAST_PATH RSPID = 0: "STALE READ/WRITE DATA-CORRUPTION"
or SYS$DUDRIVER cancel-related INVEXCEPTN bugcheck
Incorrect SYS$SCS FAST_PATH Response-ID (RSPID) handling
results in:
1) RSPID=0 and
2) a "stale" CDRP in the Response-Descriptor-Table
(SCS$GL_RDT) index-0
RDT-scans on DU-connection-failover or DU-I/O "CANCELing" will
attempt to process the "stale" CDRP, with either of the
following results:
- SYS$DUDRIVER/DUTU$CANCEL (or DUTU$END_CANCEL) INVEXCEPTN
bugchecks or
- DATA-CORRUPTION due to re-issuing MSCP-I/O on "stale" CDRP
2. SCAN_RDT STALE-CDRP "RSPID" verification to avoid potential
DATA-CORRUPTION from "STALE" CDRPs
If an SCS system application (DUDRIVER) fails to de-allocate an
"RSPID", a "stale" CDRP pointer will be left in the RDT. A
check is added for "stale" CDRPs on RDT-scans, to avoid data
corruption due to unintended reprocessing of a recycled CDRP.
Images(s) affected:
- [SYS$LDR]SYS$SCS.EXE
INSTALLATION NOTES:
If you are planning to use Fibre Channel, see the FIBRE CHANNEL
INSTALLATION INSTRUCTIONS: section below for Fibre Channel specific
Installation Instructions.
Install this kit with the PCSI utility by logging into the SYSTEM
account, and typing the following at the DCL prompt:
PRODUCT INSTALL VMS72_UPDATE /SOURCE=[location of Kit]
The kit location may be a tape drive, CD, or a disk directory that
contains the kit.
Additional help on installing PCSI kits can be found by typing
HELP PRODUCT INSTALL at the system prompt
The images in this kit will not take effect until the system is
rebooted.
If you have other nodes in your OpenVMS cluster, they must also be
rebooted in order to make use of the new image(s). If it is not
possible or convenient to reboot the entire cluster at this time, a
rolling re-boot may be performed.
It is strongly recommended that a backup of the system disk is done
prior to installing the kit.
FIBRE CHANNEL INSTALLATION INSTRUCTIONS:
The Fibre Channel remedial kits listed earlier are required to
support Fibre Channel in a mixed version or mixed architecture
OpenVMS Cluster system. Compaq recommends that you install these
remedial kits before installing the KGPSA hardware, according to
the following directions:
1. Install the required remedial kit on each node that will
receive MSCP service of an FC disk. If the remedial kit
allows "rolling upgrades," then it can be installed on
each affected node, one at a time.
If it is not possible to install the required remedial kit
on a node that receives MSCP service of an FC disk, then
that node must refrain from accessing (for example, do not
Initialize, or Mount) the FC disk until the remedial kit
is installed.
2. Install this hardware kit on the Version 7.2 system disk
of each node that will have a KGPSA adapter installed.
Rolling upgrades are allowed.
3. Install the KGPSA adapter(s).
________________________ Note ________________________
The KGPSA and the S3 Trio 64V+ Video Card (PB2GA-JC/JD)
must be installed on different PCI buses. On the
AlphaServer 800, the integral S3 Trio must be disabled
when the KGPSA is installed.
______________________________________________________
4. If an FC system disk is desired, then perform an image backup
from the non-FC system disk to the target FC system disk.
INSTALLING THIS KIT WITH A KGPSA ADAPTER IS INSTALLED:
If a node has a KGPSA adapter installed and it has a Version 7.2
system disk but does not have this kit installed then the node can
only be booted if:
o The system disk is not FC.
o The system parameter SYSTEM_CHECK is set to 1
Use the following steps to install Version 7.2 and this hardware
kit on a node that already has a KGPSA installed:
o Do a conversational boot of the Version 7.2 installation CD
(that is, B -flags 0,1).
o At the SYSBOOT prompt, set SYSTEM_CHECK=1, then CONTINUE.
o Create or update a non-FC system disk to Version 7.2
o Boot the new system disk with SYSTEM_CHECK=1.
o Install this hardware kit.
o Shutdown the system.
o Do a conversational boot of the system.
o At the SYSBOOT prompt, set SYSTEM_CHECK=0, then CONTINUE.
o After the system has booted, if an FC system disk is desired,
then perform an image backup from the non-FC system disk to the
target FC system disk.
***** NOTE *****
Compaq strongly recommends that the system disk that this kit
is being installed on be backed up before installing this kit.
If you do not have a current backup of the system disk, you should
abort the installation.
All trademarks are the property of their respective owners.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
dec-axpvms-vms72_update-v0200--4.README
dec-axpvms-vms72_update-v0200--4.CHKSUM
dec-axpvms-vms72_update-v0200--4.pcsi-dcx_axpexe
vms72_update-v0200.CVRLET_TXT
|