Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
VAXDDTM01_070 VAX V6.1 and V7.0 DECdtm ECO Summary
Copyright (c) Digital Equipment Corporation 1994, 1995. All rights reserved.
Modification Date: 25-JUN-98
Modification Type: Modified Kit: Fixes for VAX V6.2 have been
moved to VAXDDTM01_062
OP/SYS: DIGITAL OpenVMS VAX
COMPONENT: DEC Distributed Transaction Manager
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXDDTM01_070
ECO Kits Superseded by This ECO Kit: VAXDDTM03_061
VAXDDTM02_061 (CSCPAT_1146)
VAXDDTM01_061
ECO Kit Size: Saveset A - 72 Blocks
Saveset B - 558 Blocks
Saveset C - 414 Blocks
Saveset D - 792 Blocks
Cover Letter - 17 Blocks
Total of 5 files - 1853 Blocks
Kit Applies To: OpenVMS VAX V6.1, V7.0
System/Cluster Reboot Necessary: Yes
ECO KIT SUMMARY:
An ECO (patch) kit exists for DECdtm on OpenVMS VAX V6.1 and
V7.0. This kit addresses the following problems:
Problems Addressed in the VAXDDTM01_070 Kit for OpenVMS VAX V6.1:
o After a transient SCS failure, and as the two communicating
machines attempt to recover from it, one or both of the
them will crash with an access violation. The crash
may occur at a number of accesses to the structures that
SCA maintains, depending on the exact timing of the failure
with respect to the messaging activity at the time of the
crash.
Problems Addressed in the VAXDDTM01_070 Kit for OpenVMS VAX V7.0:
o Inside the SEND_DATA_INT routine, if an allocation of a new
CDRP for a new block transfer is attempted and the allocation
operation fails, there is an access violation (ACCVIO) crash.
o Problems occur with SCS Block transfer RETRIES during recovery
from SCS failures.
o Data corruption may occur during large-buffer transfers in the
CTM SSI test.
o After an attempt and failure by the code to send a message to
an unreachable node in a VMScluster, an access violation
(ACCVIO) crash will occur. This happens after the return
from the SEND routine.
o After a node unsuccessfully attempts to start an SCS block
transfer (because its partner node is no longer reachable),
it crashes with an access violation (ACCVIO).
o The definitions of the VCRP and VCIB structures which are
recorded in the IPCDEF.STB symbol table file, are different
from those in the SCSDEF.STB file. They should be the same.
o Upon being notified by SCS that a remote node is no longer
reachable, the SCA transport tries to clean up its structures.
While traversing its PARTNER queue of TPBTX structures, it
crashes with an INCONSTATE bugcheck.
o There was a problem in the way DECdtm wrote Resource Manager
(RM) Log IDs to the Transaction Manager (TM) log. The values
written to the TM log were different from those found in the
transaction data structures. DECdtm was, in other words,
corrupting RM Log IDs when it wrote them to the log. This
problem was fixed for OpenVMS Alpha V6.1 and 6.2.
However, there are customers in possession of older TM logs
(i.e., logs generated by older incorrect versions of the
facility which contain corrupted RM log ID entries. These
customers are experiencing problems when trying to
recover/rollback the transactions recorded in these logs.
The recovery process fails with a SS$_NOSUCHPART error. This
is a workaround for that problem.
Problems Addressed in the VAXDDTM03_061 Kit:
o A DECdtm transaction PREPARED record can be left in a node's
transaction log when both of the following conditions hold:
1. the transaction's parent is in the same cluster and
2. all RMs on the node are voting read-only.
o LMCP assumes that all transaction records written to the
DECdtm transaction log will contain valid transaction
identifiers. The transaction identifiers created by
DECdtm contain a valid timestamp. For non-DECdtm
transaction identifiers, LMCP incorrectly formats the
timestamp.
This problem is corrected in OpenVMS VAX V6.2.
o A PGFLIPLHI crash may occur when the queue manager is
running down. The instruction at which the PGFLIPLHI
crash occurs is in SYS$IPC_SERVICES.
This problem is corrected in OpenVMS VAX V6.2.
Problems Addressed in the VAXDDTM02_061 Kit:
o Correct documentation errors that existed in the VAXDDTM01_061
kit.
o If a node name in a transaction group is identical to the
initial character or characters of a longer node name, a
transaction will fail with one of the following errors:
SS$_CONNECFAIL
%DDTM-E-COMM_FAIL
For example, transactions could fail if a transaction group
contained the following nodes:
BLUE:: and BLUE2::
BLU:: and BLUE2::
BL:: and BLUE2::
B:: and BLUE2::
o The commitment of transactions may suddenly stop for no apparent
reason. The command:
$ MCR LMCP SHOW LOG /CURRENT
shows that there is a stall in progress. If RDB is installed,
the command:
$ RMU/SHOW
on the affected database will show transactions as being "stalled,
waiting to commit". This situation may occur due to a random DECdtm
transaction log file stall.
o Layered Product applications built using constants from OpenVMS
VAX V5.4 may not work correctly. This situation may occur when
a transaction information buffer of 72 or more bytes is
provided to DECdtm. The process default transaction completes
but returns incorrect information.
Problems Addressed in the VAXDDTM01_061 Kit:
o DECdtm does not handle node access control strings (ACS)
correctly on DECnet Phase V systems. This problem occurs even
if node synonyms are being used.
NOTE: Node access control strings are not supported by
DECdtm with Phase V fullnames. However, old and
new applications should continue to work when
synonyms are used.
RELATED ARTICLES:
Detailed articles describing the problems listed above may exist in
the OPENVMS or DECNET-VMS databases. To view these articles, open
the appropriate product database and perform a query using either of
the following search strings: 'VAXDDTM01_070' or 'VAXDDTM'.
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 (Patch) 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 VAXcluster, the
entire cluster must be rebooted.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| Image Information for OpenVMS VAX V6.1: |
+----------------------------+----------+-----------------+--------------+
| DTI$SHARE.EXE |%X0CD11805| DDTM V1.2-K | 27-FEB-1996 |
| | | 09:45:56.67 |
+----------------------------+----------+-----------------+--------------+
| LMCP.EXE |%X9DC58F01| DDTM V1.2-K | 27-FEB-1996 |
| | | 09:52:19.00 |
+----------------------------+----------+-----------------+--------------+
| SYS$IPC_SERVICES.EXE |%X795D6A41| IPC V1.2-K | 27-FEB-1996 |
| | | 09:52:12.96 |
+----------------------------+----------+-----------------+--------------+
| SYS$TRANSACTION_SERVICES.EXE|%XCDCD505E| DDTM V1.2-K | 27-FEB-1996 |
| | | 09:52:21.03 |
+----------------------------+----------+-----------------+--------------+
| TPSERV.EXE |%X82EAEB5C| DDTM V1.2-K | 27-FEB-1996 |
| | | 09:52:44.12 |
+----------------------------+----------+-----------------+--------------+
| Image Information for OpenVMS VAX V7.0: |
+----------------------------+----------+-----------------+--------------+
| DTI$SHARE.EXE |%X296C12BC| V1.3-X035 | 29-FEB-1996 |
| | | 11:02:02.46 |
+----------------------------+----------+-----------------+--------------+
| LMCP.EXE |%XE23E6E2E| V1.3-X035 | 29-FEB-1996 |
| | | 11:06:03.80 |
+----------------------------+----------+-----------------+--------------+
| SYS$IPC_SERVICES.EXE |%XFDBFB220| V1.3-X03E | 29-FEB-1996 |
| | | 11:07:55.97 |
+----------------------------+----------+-----------------+--------------+
| SYS$TRANSACTION_SERVICES.EXE|%X389F52FE| V1.3-X035 | 29-FEB-1996 |
| | | 11:06:12.36 |
+----------------------------+----------+-----------------+--------------+
| TPSERV.EXE |%X66F7D648| V1.3-X035 | 29-FEB-1996 |
| | | 11:06:20.91 |
+----------------------------+----------+-----------------+--------------+
|
