|
|
 |
*OpenVMS] ALPMOUN05_062 Alpha V6.2 - V6.2-1H3 MOUNT ECO Summary
|
TITLE: *OpenVMS] ALPMOUN05_062 Alpha V6.2 - V6.2-1H3 MOUNT ECO Summary
Modification Date: 29-JUN-1999
Modification Type: Updated Kit: Supersedes ALPMOUN04_062
NOTE: An OpenVMS saveset or PCSI installation file is stored
on the Internet in a self-expanding compressed file.
The name of the compressed file will be kit_name-dcx_vaxexe
for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha.
Once the file is copied to your system, it can be expanded
by typing RUN compressed_file. The resultant file will
be the OpenVMS saveset or PCSI installation file which
can be used to install the ECO.
Copyright (c) Compaq Computer Corporation 1998, 1999. All rights reserved.
PRODUCT: OpenVMS Alpha
COMPONENT: MOUNT
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: ALPMOUN05_062
ECO Kits Superseded by This ECO Kit: ALPMOUN04_062
ALPMOUN03_062
ALPMOUN02_062 (Not released)
ALPMOUN01_062
ECO Kit Approximate Size: 882 Blocks
Kit Applies To: OpenVMS Alpha V6.2, V6.2-1H1, V6.2-1H2, V6.2-1H3
System/Cluster Reboot Necessary: No
Installation Rating: INSTALL_3
3 : To be installed by customers
experiencing the problems corrected.
KIT DEPENDENCIES:
The following remedial kit(s) must be installed BEFORE
installation of this, or any required kit:
None
In order to receive all the corrections listed in this kit,
the following remedial kits should also be installed:
ALPSYSA02_062
ALPBACK02_062
ALPDISM02_062
ALPINIT01_062
ALPMTAA02_062
ECO KIT SUMMARY:
An ECO kit exists for MOUNT on OpenVMS Alpha V6.2 through V6.2-1H3.
This kit addresses the following problems:
Problems Addressed in ALPMOUN05_062:
o The previous version of this kit contained a fix for a
problem in which SWL disks do not come out of mount
verification properly. The fix insured that the
VCB$T_VOLOCKNAM matches the SCB$_VOLOCKNAME of the volume,
even for privately mounted disks. However, if a member of
a shadow set is removed from the set for BACKUPs, then both
the still-mounted shadow set and the privately mounted former
member will have the same VCB$T_VOLOCKNAMs.
This causes a variety of symptoms, including access conflicts
during BACKUPs of the former member and in at least one case,
an XQPERR, Error detected by file system XQP bugcheck at
F11BXQP_PRO+0BE48. In addition, reports of customers unable
to MOUNT multiple CDROMS have been attributed to this problem.
The original fix has been removed to fix these problems. As a
result, the original problem may still occur. If a disk is
write-locked, it will not successfully complete mount
verification. The device will be marked as "wrong volume".
Compaq OpenVMS Engineering continues to research solutions
to this problem.
Images Affected: [SYSLIB]MOUNTSHR.EXE, [SYSEXE]VMOUNT.EXE
o /MEDIA_FORMAT and /DENSITY qualifiers are not always handled
properly, resulting in tapes being written in different modes
than intended.
Images Affected: [SYSLIB]MOUNTSHR.EXE, [SYSEXE]VMOUNT.EXE
o A new check is provided to determine if the disk that is being
MOUNTed is initialized to a size that is larger than the
number of blocks that are now available.
This size discrepancy occurs when a disk is moved from one
controller type to another (e.g., from a local SCSI connection
to an HSJ), without the disk being initialized on the new
controller. As a result, some data may be inaccessible
through the new controller.
It has been determined that a number of customers are running
with disks which are in this condition. While data may be
inaccessible on the disk, the usefulness of the disk should be
left to the discretion of the System Manager. Therefore, if
this condition is detected, a warning message is displayed:
%MOUNT-W-INCONSIZE, inconsistent number of blocks reported,
some data may not be accessible
Note that the warning message text will be shipped in a
separate kit, ALPMSGF04_062, which contains the SYSMSG.EXE
image. If the ALPMSGF04_062 kit has not been installed, then
the following message will be output:
%MOUNT-W-NOMSG, Message number 007290D0
It is recommended that the BACKUP utility be used to move data
from a disk on one controller type to a disk on another
controller type, especially if those controllers report a
different number of blocks available for the same disk type.
Once the data has been moved, the physical disk can be moved
and initialized on the new controller.
Image(s) Affected: [SYSLIB]MOUNTSHR.EXE, [SYSEXE]VMOUNT.EXE
Problems Addressed in ALPMOUN04_062:
o MailBox Read synchronization problem in MME_MBX_COMM
A possible system crash occurs during Host Based RAID Unbinds
with MME code enabled. A mailbox read synchronization problem
causes the crash.
This problem only occurs when a host-based RAID UNBIND command
is done while an MME-based application is running.
This problem may occur in several different code areas of the
operating system. In order to eliminate all instances of this
problem, the following remedial kits (or their supersedants)
will also need to be installed:
o ALPSYSA02_062
o ALPBACK02_062
o ALPDISM02_062
o ALPINIT01_062
o ALPMTAA02_062
Problems Addressed in ALPMOUN03_062:
o If the target disk of a shadow copy has been initialized, such
that the SCB is in a different location than that of the master
node (i.e. INIT/INDEX=END), and the shadow copy has not yet
started, then validation during a second MOUNT of this disk
would fail with an ISAMBR error. However, this error message
was incorrect; the actual error was a WRONGVU error.
Problems Addressed in ALPMOUN02_062:
o There have been a number of reports of "MOUNT-F-ISAMBR" error
messages on MOUNT/SHADOW. Most of them were not reproducible
and most of them were on shadow sets that were already mounted
elsewhere in the cluster. This error message does not give
the user any idea why the MOUNT failed. The failure message
is now clearer.
o A device could be mounted /NOSHARE on one system and as the
member of a shadow system disk on another system. This could
result in Disk Corruption. No "Alloc. lock ID" is setup on
the booting system.
o A MOUNT of a former shadow set member will fail on all nodes
in a cluster, except the first mounting node, with a
"%MOUNT-F-DIFVOLMNT" failure.
o A MOUNT of multiple tape devices with one command will cause
inconsistent "write lock" attributes. For example:
$ mount/write mkb400,mkb500 MKB400,TZ000
%MOUNT-I-MOUNTED, MKB400 mounted on _N24005$MKB400:
%MOUNT-I-MOUNTED, TZ000 mounted on _N24005$MKB500:
$ sho dev mkb
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
MKB400: Mounted alloc 0 MKB400 0 1 1
MKB500: Mounted alloc 0 TZ000 0 1 1
wrtlck
MKB500 should not be "wrtlck".
o MOUNT messages obtained through OPCOM with MOUNT/ASSIST are
often less helpful than the error code returned when /NOASSIST
is specified. For example:
$ MOUNT/ASSIST /OVER=ID mua0:
%MOUNT-I-OPRQST, device _SCSI3$MUA0: contains the wrong volume
%MOUNT-I-OPRQST, Please mount device _SCSI3$MUA0:
MOUNT/NOASSIST /OVER=ID mua0:
%MOUNT-F-NOTLABELMT, tape is not labeled
The "NOTLABELMT" is a more accurate message than "wrong
volume".
o MOUNT/FOREIGN/CLUSTER DUnxx will mount the disk locally, but
fails to mount the device on other nodes in the cluster. The
error message is:
%MOUNT-W-RMTMNTFAIL, _$4$DUA216: failed to mount on node BEAR
-MOUNT-F-CONFQUAL, conflicting qualifiers
o Failure of a tape MOUNT would cause MOUNT to retry the MOUNT
for 2 minutes before reporting the error to the user and
OPCOM. This time is wasted under many circumstances as the
drive status will not change without operator intervention.
o If the /SYSTEM qualifier was not used when adding a member to
an existing shadow set, that was mounted with /SYSTEM, the add
appeared to be successful. It was not. The resulting
behavior ranges from member copies that never happen ("0%
copies") to system crashes.
o Since the MOUNT96 rewrite some customers have had an issue
with the extended period of time MOUNT attempts retries.
When one or more members of a shadowset are
offline/unavailable for mounting, a mount of that shadowset is
observed to take approximately 2 minutes to complete. This
leads to unacceptably long delays in system and application
startup completion.
o Attempting to MOUNT/SYSTEM two ISO-9660 volumes, whose volume
labels are not unique in the first 12 characters, results in
an "another volume of the same label already mounted" error.
Problems Addressed in ALPMOUN01_062:
o If per-disk licensing is used, MOUNT may end up in an infinite
loop if this is the first mount of any shadow set and the
system disk is unit 0.
This problem is corrected in OpenVMS Alpha V7.0.
INSTALLATION NOTES:
The system does not need to be rebooted after this kit is installed.
However, if you have other nodes in your OpenVMS VMScluster, they should
be rebooted or you should install this kit on each system in order to
make use of the new image(s).
|
Files on this server are as follows:
|
»alpmoun05_062.README
»alpmoun05_062.CHKSUM
»alpmoun05_062.CVRLET_TXT
»alpmoun05_062.a-dcx_axpexe
»alpmoun05_062.CVRLET_TXT
|
