Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
ALPMSCP01_071 Alpha V7.1 TMSCP/MSCP ECO Summary
Copyright (c) Compaq Computer Corporation 1998. All rights reserved.
OP/SYS: OpenVMS Alpha
COMPONENT: TMSCP.EXE
MSCP.EXE
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: ALPMSCP01_071
ECO Kits Superseded by This ECO Kit: None
ECO Kit Approximate Size: 342 Blocks
Kit Applies To: OpenVMS Alpha V7.1 through V7.1-1H2
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: In order to receive the full fixes listed in this kit,
the following remedial kits also need to be installed:
None
ECO KIT SUMMARY:
An ECO kit exists for TMSCP and MSCP on OpenVMS Alpha V7.1 through V7.1-1H2.
This kit addresses the following problems:
o Unexpected end messages are logged on client nodes for GUS and
AVAILABLE commands. A Cache Data Lost error is detected in the
tape subsystem due to a hardware-related problem. A GUS end
message is returned to the client with an end message status of
08 (data error). This status is set up in the SEND_END routine
in TMSCP. Since this is not a valid status for a GUS, the client
TUDRIVER rejects the invalid status, logs an error and then calls
TU$RE_SYNCH which breaks the connection.
For the same Cache Data Lost error, if an AVAILABLE command is
issued, the controller should return CDL until the host clears
the condition in the controller. TUDRIVER in the server, upon
receipt of an end message for AVAILABLE which indicates CDL,
will then issue another AVAILABLE with the clear cache data
lost modifier set in the packet. The only status that is
checked on the receipt of this end message is for PRESE which
will return SS$_DATALOST. Anything else returns SS$_DATALOST.
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 is
encountered on a drive. A drive directly attached (or HSx
served) reports a different transfer count from 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.
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: 'ALPMSCP01_071' or 'ALPMSCP'.
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:
In order for the corrections in this kit to take effect, the system must
be rebooted. If the system is a member of a VMScluster, the entire
cluster should be rebooted.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| MSCP.EXE | EE919DBA | X-3 | 2-MAY-1997 |
| | | 22:23:49.43 |
+----------------------------+----------+-----------------+--------------+
| TMSCP.EXE | 22642967 | X-3 | 2-MAY-1997 |
| | | 22:24:44.12 |
+----------------------------+----------+-----------------+--------------+
|
