OpenVMS] VAXMOUN04_062 (VAX V6.2 MOUNT) ECO Summary
TITLE: OpenVMS] VAXMOUN04_062 (VAX V6.2 MOUNT) ECO Summary
Modification Date: 07-JUL-1999
Modification Type: Updated Kit: Supersedes VAXMOUN03_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 VAX
COMPONENT: MOUNT
MOUNTSHR
VMOUNT
DCLTABLES (updated with a new MOUNT.CLD))
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXMOUN04_062
ECO Kits Superseded by This ECO Kit: VAXMOUN03_062
VAXMOUN02_062
VAXMOUN01_062 (Never Released)
ECO Kit Approximate Size: 630
Kit Applies To: OpenVMS VAX V6.2
System/Cluster Reboot Necessary: Yes
Rolling Reboot Supported: Yes
Installation Rating: INSTALL_3 - To be installed on all systems running
the listed versions of OpenVMS which
are experiencing the problems described.
Kit Dependencies:
The following remedial kit(s) must be installed BEFORE
installation of this kit:
VAXCLUSIO01_062
In order to receive all the corrections listed in this
kit, the following remedial kits should also be installed:
VAXSYSA02_062
VAXINIT01_062
VAXBACK03_062
VAXMTAA03_062
VAXDISM02_062
ECO KIT SUMMARY:
An ECO kit exists for MOUNT.EXE on OpenVMS VAX V6.2. This kit addresses
the following problems:
Problems Addressed in the VAXMOUN04_062 Kit:
o A new fix was provided in the previous kit which checks to
determine if the disk that is being MOUNTed was 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 (for example, 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. If this condition
was detected, then a fatal MOUNT-F-FILESTRUCT error was
reported and the MOUNT was aborted.
It has been determined that a number of systems are running
with disks which are in this condition. While there may be
data that is inaccessible on the disk, the usefulness of the
disk should be left to the discretion of the system manager.
Therefore, this change makes this condition issue the following
warning message rather than a fatal error:
%MOUNT-W-INCONSIZE, inconsistent number of blocks reported,
some data may not be accessible
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.
Images Affected:
- [SYSLIB]MOUNTSHR.EXE
- [SYSEXE]VMOUNT.EXE
o Previously, a fix was included to address 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 systems unable
to MOUNT multiple CDROMS have been attributed to this problem.
Due to the problems that it caused, the original fix has been
removed. 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
Problems Addressed in the VAXMOUN03_062 Kit:
o SCB and VCB Volume Lock Name mismatch at mount time
Mount Verification fails incorrectly with a "wrong volume" error if
the device is mounted /NOWRITE. This failure also occurs when
former shadow set members are MOUNTed without /OVERRIDE=SHADOW,
which causes the device to be mounted write-locked.
o MOUN$_IVLOCKID error when MOUNTing volume
When MOUNTing a volume (usually immediately after the volume has
been dismounted), the error MOUN$_IVLOCKID is returned. However, if
the command is simply retried, then the MOUNT succeeds.
This change allows MOUNT to automatically retry on the IVLOCKID
error, just as it does with many other errors.
o MOUNT/SYSTEM CDROMs with long labels
MOUNT/SYSTEM fails with an %MOUNT-F-IVBUFLEN error when an attempt
is made to MOUNT an ISO 9660 CDROM with a volume label of more than
27 characters. The ISO 9660 specification allows volume labels of
32 characters.
o Add REQUIRE_MEMBERS and VERIFY_LABELS switches to MOUNT command
A MOUNT/POLICY=(REQUIRE_MEMBERS,VERIFY_LABELS) switch was added to
the MOUNT command. This change is an enhancement, not a fix.
The following switch and options were added to MOUNT:
1. /POLICY=REQUIRE_MEMBERS - force all specified members to be
available for MOUNT to occur.
The /POLICY=REQUIRE_MEMBERS option is used in disaster-tolerant
configurations where another site may have a more recent disk
that is not available. In effect, this option will force more
human decision making.
2. /POLICY=VERIFY_LABELS - all copy targets must have label
"SCRATCH_DISK" or they will not be added to the set
The volume must be ODS2 and have a valid file structure.
The new option will force users to use alternate volume labels.
One of the biggest causes of "a wrong disk being added to a
shadow set" is mistyped commands. If users are given a way to
be sure that they only added "scratch" disks to shadow sets,
then they will be less likely to lose data.
This option is similar to /CONFIRM, except that it can be used
in command procedures as well, without immediate operator
intervention. It is also similar to the /NOCOPY command, except
it allows copies to occur, as long as the label is "scratch".
NOTE: Related to the above two qualifiers, the following new error
messages were added to MOUNT. However, these messages will
not display correctly until an updated SYSMSG.EXE has been
installed on your system. Although MOUNT will still operate
correctly, it will report these errors as:
%NONAME-F-NOMSG, Message number 00728xxx
The message numbers and their corresponding messages are as
follows:
007283C4 is "NOTALLMEM, one or more specified members not
available for mounting"
007283CC is "BADPOLICY, invalid syntax on /POLICY"
A TIMA kit with a new SYSMSG.EXE will be available at a
future date.
o Corrupted DATA_POINTER variable put on stack (for MME)
The stack receives a corrupted DATA_POINTER variable since the
LOAD_MSG_DSCDEV macro declares a local variable DEV_SIZE as long.
Previously, the GETDVI system service wrote the devnam size to the
DEV_SIZE variable.
o /SCRATCH initializes tapes incorrectly (for MME)
Tapes are not correctly initialized when using the /SCRATCH
qualifier with a Media Management Extension (MME) application.
Although the tape is rewound, the HDR1 information is not being
reset/rewritten properly. As a result, HDR1 items such as FILESEQNO
may not be correct. Subsequent tapes are also not initialized.
o MailBox Read synch - crash during host-based RAID unbinds (for MME)
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.
The problem may occur in several different code areas of the
operating system. In order to eliminate all known instances of this
problem, the following remedial kits (or their supersedants) will
also need to be installed:
VAXSYSA02_062
VAXINIT01_062
VAXBACK03_062
VAXMTAA03_062
VAXDISM02_062
o Synchronization problem in MME_ACTION and MME_ALLOC
A process using MME could potentially "miss" the VOL1 label on a
tape. Also, a process could "hang" trying to send a message to the
MME process.
o MME cannot mount shadow sets with media manager running
$MOUNT DSAn/SHAD=$n$ddcu (shadow set), with a media manager running,
causes a "no such device error" and then mount fails.
o MME passed a fatal error for shadow set
MME (MME_MNTREQ) broke the RAID BIND command with shadow sets.
MME passes a fatal error to Host-Based Shadowing or Host-Based Raid
on a MOUNT request, if the shadow set virtual unit has not been
created.
o Dismounting raidsets crashes system (for MME)
A media management application can crash the system with an invalid
exception bugcheck. The reason for the crash is due to an access
violation. The crashing image is [SYSLIB]MMESHR.EXE.
Problems Addressed in the VAXMOUN02_062 Kit:
o MOUNT96 errors
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 the VAXMOUN01_062 Kit:
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.
o When using MME with MOUNT, and an error is encountered, an
EXEC mode exception will occur.
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).
NOTE: After the installation, any process that attempts to do a MOUNT
will fail unless a the following command is issued:
$ SET COMMAND/TABLE=SYS$LIBRARY:DCLTABLES.EXE
Otherwise the user should log out and then log back in.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
vaxmoun04_062.README
vaxmoun04_062.CHKSUM
vaxmoun04_062.CVRLET_TXT
vaxmoun04_062.a-dcx_vaxexe
vaxmoun04_062.CVRLET_TXT
|
