|
|
 |
OpenVMS VAXMOUN05_071 OpenVMS VAX V7.1 MOUNT ECO Summary
|
TITLE: OpenVMS VAXMOUN05_071 OpenVMS VAX V7.1 MOUNT ECO Summary
Modification Date: 16-SEP-1999
Modification Type: Fixed readme file on ftp site.
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.
*OpenVMS] VAXMOUN05_071 OpenVMS VAX V7.1 MOUNT ECO Summary
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: VAXMOUN05_071
ECO Kits Superseded by This ECO Kit: VAXMOUN04_071
VAXMOUN03_071
VAXMOUN02_071
VAXMOUN01_071
ECO Kit Approximate Size: 630 Blocks
Kit Applies To: OpenVMS VAX V7.1
System/Cluster Reboot Necessary: Yes
Rolling reboot supported: Yes
Installation Rating: 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:
None
In order to receive all the corrections listed in this
kit, the following remedial kits should also be installed:
VAXSYSA02_071
VAXMTAA01_071
VAXDISM01_071
VAXINIT01_071
VAXBACK03_071
ECO KIT SUMMARY:
An ECO kit exists for MOUNT on OpenVMS VAX V7.1. This kit addresses
the following problems:
Problems Addressed in the VAXMOUN05_071 ECO Kit:
o A new check which was provided in the previous kit determines
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. If this condition is detected,
then a fatal MOUNT-F-FILESTRUCT error is reported and the
MOUNT is aborted.
It has been determined that a number of systems 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, the change makes this condition
a warning message only:
%MOUNT-W-INCONSIZE, inconsistent number of blocks reported,
some data may not be accessible
NOTE:
Since the warning message text, which is in SYSMSG.EXE,
will be used by many facilities, SYSMSG.EXE will be
issued in a separate kit named VAXMSGF01_071. If this
MSGFIL 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
o A change was previously made to fix a problem where 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
Problems Addressed in the VAXMOUN04_071 ECO 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_071
VAXMTAA01_071
VAXINIT01_071
VAXDISM01_071
VAXBACK03_071
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 VAXMOUN03_071 ECO Kit:
o If the target disk of a shadow copy was 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 since the actual error was a WRONGVU error.
o A device could be mounted /NOSHARE on one system and as the
member of a shadow system disk on another system. These
actions could result in Disk Corruption. No "Alloc. lock ID"
is setup on the booting system.
o A MOUNT of a former shadow set member fails 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 An occasional MOUNT-F-NOTQUEUED error occurs when attempting a
"generic" shadow mount (i.e. $MOUNT DSA/SHAD=$4$dua24:
tst24). The cause of the problem was that the $ENQW error
status was not properly filtered into DEVBUSY errors.
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". Hence, reproducing the problem with /NOASSIST
previously gave a more accurate error status. Consequently, a
change was made to have status output to OPCOM so that
MOUNT/ASSIST will provide better status information.
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 causes MOUNT to retry the MOUNT for two
minutes before reporting the error to the user and OPCOM. This
time is wasted under many circumstances, since 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
result appeared to be successful. However, it really failed.
The end result varies from member copies that never happen ("0%
copies") to system crashes.
o When using MME with MOUNT and an error is encountered, an EXEC
mode exception will occur.
o Since the MOUNT96 change, some customers have been concerned
about the extended period of time that MOUNT attempts retries.
When one or more members of a shadowset are offline/unavailable
for mounting, a mount of that shadowset takes approximately two
minutes to complete. This wait 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 the VAXMOUN02_071 ECO Kit:
o An incorrect image was placed in the VAXMOUN01_071 ECO kit.
This kit contains the correct image.
Problems Addressed in the VAXMOUN01_071 ECO Kit:
o A MOUNT/SHARE may be allowed for a device that is already
mounted. This occurs because an error regarding the device
status is not relayed to SS$_DEVMOUNT in ACQUIRE_DEVICE.
INSTALLATION NOTES:
The images in this kit will not take effect until the system is
rebooted. If there are other nodes in the VMScluster, 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.
All trademarks are the property of their respective owners.
|
Files on this server are as follows:
|
»vaxmoun05_071.README
»vaxmoun05_071.CHKSUM
»vaxmoun05_071.CVRLET_TXT
»vaxmoun05_071.a-dcx_vaxexe
»vaxmoun05_071.CVRLET_TXT
|
