Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
VAXMSCP03_062 VAX V6.2 TMSCP/MSCP ECO Summary
Copyright (c) Digital Equipment Corporation 1997, 1998. All rights reserved.
OP/SYS: DIGITAL OpenVMS VAX
COMPONENT: TMSCP.EXE
MSCP.EXE
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXMSCP03_062
ECO Kits Superseded by This ECO Kit: VAXMSCP02_062
VAXMSCP01_062
VAXMSCP01_070
ECO Kit Approximate Size: 144 Blocks
Kit Applies To: OpenVMS VAX V6.2
System/Cluster Reboot Necessary: Yes
Installation Rating: 2 - To be installed on all systems running
the listed version(s) of OpenVMS and
using the following feature(s):
Systems that MSCP serve tapes and disks
NOTE: The following remedial kit(s) must be installed BEFORE
installation of this kit:
VAXCLUSIO01_062
ECO KIT SUMMARY:
An ECO kit exists for TMSCP and MSCP on OpenVMS VAX V6.2. This kit
addresses the following problems:
Problems addressed in VAXMSCP03_062
o The VAXMSCP02_062 remedial kit required that the VAXCLUSIO01_062
kit be installed. If the user tried to install the VAXMSCP02_062
kit on a system that had both the VAXCLUSIO01_062 and OpenVMS
VAX Y2K remedial kits installed, the VAXMSCP02_062 kit did not
recognize that the VAXCLUSIO01_062 kit had been installed. This
caused the VAXMSCP02_062 installation to fail.
There are no new ECO problem corrections in this kit. If you
have installed the VAXMSCP02_062 remedial kit, you do not need
to install the VAXMSCP03_062 remedial kit.
Problems addressed in VAXMSCP02_062
o If a customer upgraded their system to V6.2 from V6.1, the
KITINSTAL.COM procedure, in kits that require the VAXCLUSIO01
remedial kit to be installed first, did not properly verify
that the VAXCLUSIO01_062 remedial kit had been installed.
Problems addressed in VAXMSCP01_062
o TMSCP does not restore R2 properly before using the register
as an MSCP message. This misuse manifests either in a
corrupted TMSCP$ERR_TBL which causes devices to be inaccessible,
or the system will crash. The outcome depends on the value in
R2.
This misuse is manifested as either a corrupted TMSCP$ERR_TBL,
which is the cause of the devices not being accessible, or as a
system crash, depending on the value in R2.
o The client process hangs when it attempts to mount a tape device
that is online to another host. Mount issues a packack for the
device. The client then issues an ONLINE command. During
TMSCP/ONLINE processing, if the server finds an HQB address in
the UQB$L_ONLINE_HQB field, it returns SUCCESS status with an
ALONL subcode even though the HQB is not for the requesting host.
When the client processes the successful ONLINE end message, it
issues a GUS. The server returns a unit-available for this
command which causes the client TUDRIVER to reissue an ONLINE
which starts the process all over again. It stays in this
loop forever.
o An INVEXCEPTN system crash may occur when TMSCP does not get a
message buffer during configuration when a connection to
MSCP$TAPE is broken.
o An inconsistent transfer count occurs when a forced error on a
drive is encountered. A drive directly attached (or HSx
served) reports a different transfer count than the same drive
served via the MSCP server.
Code that attempts to determine the LBN of a forced error
block by looking at the byte count in the IOST/IOSB will
arrive at different values on the same drive when directly
accessed or MSCP served.
Problems addressed in VAXMSCP01_070 for V6.2
o The problem occurs when ERASE commands with history logging are
issued on MSCP clients for large numbers of blocks to MSCP
devices served by an OpenVMS MSCP server. On an Alpha server,
an "Illegal Command" entry will be posted in the system error
log and the command will be aborted. Typically, if the
affected device is part of a shadow set, the set will enter
mount verification and the I/O request will eventually fail
with a "Fatal Controller Error". On a VAX server, no immediate
problem is noticed but the possibility of corrupting a shadow
set exists should there be a failure during the execution of
the ERASE command and a mini-merge is performed when the set
becomes available.
o A satellite node will not boot after a preferpath/forcepath
command is issued on the server.
o Word instructions are used to reference a byte field.
RELATED ARTICLES:
Detailed articles describing the problems listed above may exist in
the OPENVMS database. To view these articles, open the appropriate
product database and perform a query using either of the following
search strings: 'VAXMSCP03_062' or 'VAXMSCP'.
ECO KIT ORDERING INSTRUCTIONS:
If after an evaluation you wish to obtain this kit, request it
electronically using the appropriate Advanced Electronic Services
(AES) Service Tool. If you are not familiar with how to request
kits electronically, open the DIA, WIS or DSNLINK database and
review the article entitled:
[AES] How To Electronically Request ECO Kits Using Service Tools
INSTALLATION NOTES:
The images in this kit will not take effect until the system is
rebooted.
If you have other nodes in your VMS 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.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| MSCP.EXE |%X884D0DBB| X-65A1 | 7-MAY-1997 |
| | | 08:26:11.41 |
+----------------------------+----------+-----------------+--------------+
| TMSCP.EXE |%X91B1535A| X-33B2 | 7-MAY-1997 |
| | | 08:26:31.95 |
+----------------------------+----------+-----------------+--------------+
|
