|
|
 |
OpenVMS ALPMOUN07_071
|
TITLE: OpenVMS ALPMOUN07_071
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.pcsi-dcx_axpexe, then it can
be expanded by typing RUN kitname.pcsi-dcx_axpexe. The resultant
file will be the PCSI installation file which can be used to install
the ECO.
*OpenVMS] ALPMOUN07_071 Alpha V7.1* MOUNT ECO Summary
Copyright (c) Compaq Computer Corporation 1998, 1999. All rights reserved.
Modification Date: 16-JUN-1999
Modification Type: Updated Kit: Supersedes ALPMOUN06_071
PRODUCT: OpenVMS Alpha
COMPONENT: MOUNT
MOUNTSHR
VMOUNT
DCLTABLES (updated with a new MOUNT.CLD))
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: ALPMOUN07_071
ECO Kits Superseded by This ECO Kit: ALPMOUN06_071
ALPMOUN05_071
ALPMOUN04_071
ALPMOUN03_071
ALPMOUN02_071
ALPMOUN01_071
ECO Kit Approximate Size: 882 Blocks
Kit Applies To: OpenVMS Alpha V7.1, V7.1-1H1, V7.1-1H2
System/Cluster Reboot Necessary: No
Installation Rating: INSTALL_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_071
ALPBACK04_071
ALPDISM01_071
ALPINIT01_071
ALPMTAA01_071
ECO KIT SUMMARY:
An ECO kit exists for MOUNT on OpenVMS Alpha V7.1 through V7.1-1H2.
This kit addresses the following problems:
Problems Addressed in the ALPMOUN07_071 Kit:
o A new check which was provided in the ALPMOUN06_071 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 ALPMSGF01_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
o Initializing a tape with the /MEDIA_FORMAT or /DENSITY
qualifier is not always handled properly, resulting in
a tape being written in a different mode than intended.
Images Affected: [SYSLIB]MOUNTSHR.EXE, [SYSEXE]VMOUNT.EXE
Problems Addressed in the ALPMOUN06_071 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 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 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 ALPMOUN05_071 Kit:
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:
ALPSYSA02_071
ALPBACK03_071
ALPDISM01_071
ALPINIT01_071
ALPMTAA01_071
Problems Addressed in the ALPMOUN04_071 Kit:
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 the ALPMOUN03_071 Kit:
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 the ALPMOUN02_071 Kit:
o Wrong image was placed in the ALPMOUN01_071 kit. This kit
fixes that problem.
Problems Addressed in the ALPMOUN01_071 Kit:
o If a DCL 'MOUNT DSAxxx/SHAD' is performed by a process that
does not have BYPASS or READALL privileges, the MOUNT will fail
if the DSAxxx did not previously exist. If the command is
immediately repeated by the same process, it will be
successful.
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.
|
Files on this server are as follows:
|
»alpmoun07_071.README
»alpmoun07_071.CHKSUM
»alpmoun07_071.CVRLET_TXT
»alpmoun07_071.a-dcx_axpexe
»alpmoun07_071.CVRLET_TXT
|
