OpenVMS ALPDDTM03_070 Alpha V6.1 - V7.0 DECdtm ECO Summary
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.
Copyright (c) Digital Equipment Corporation 1995, 1997. All rights reserved.
PRODUCT: OpenVMS Alpha
COMPONENT: DEC Distributed Transaction Manager (DECdtm)
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: ALPDDTM03_070
ECO Kits Superseded by This ECO Kit: ALPDDTM02_070
ALPDDTM01_070
ALPDDTM02_062
ALPDDTM01_062
AXPDDTM01_061 (AXPDDTM)
ECO Kit Approximate Size: 5562 Blocks
Saveset A: 198 Blocks
Saveset B: 1710 Blocks
Saveset C: 1710 Blocks
Saveset D: 1944 Blocks
Kit Applies To: OpenVMS Alpha V6.1, V6.1-1H1, V6.1-1H2,
V6.2, V6.2-1H1, V6.2-1H2, V6.2-1H3,
V7.0
System/Cluster Reboot Necessary: Yes
Installation Rating: 3 - To be installed on all systems running
the listed versions of OpenVMS which
are experiencing the problems described.
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 DECdtm on OpenVMS Alpha V6.1 through V7.0. This
kit addresses the following problems:
Problems addressed in the ALPDDTM03_070 kit for OpenVMS Alpha
V6.2, V6.2-1H1, V6.2-1H2, and V6.2-1H3:
o The actions of a transaction log open and a transaction log close
can conflict causing the system to crash with a DDTMBUG bugcheck.
o Non-paged pool may fill with LMTRCBs. This only happens when
distributed transactions are being used inside a cluster.
o System crash from user mode if $END_TRANS is called in the
sub-process of process where $START_TRANS was called.
Problems addressed in the ALPDDTM02_070 kit for OpenVMS Alpha
V6.2-1H1:
o The ALPDDTM01_070 remedial kit did not install on systems
running OpenVMS Alpha V6.2-1H1, as it should have.
Problems addressed in the ALPDDTM01_070 kit for OpenVMS Alpha V6.1,
V6.1-1H1, V6.1-1H2, V6.2, V6.2-1H1 and V7.0:
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 ALPDDTM01_070 kit for OpenVMS Alpha V7.0:
o SYS$TRANSACTION_SERVICES causes memory leaks.
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, an access violation (ACCVIO) crash will occur.
o Problems with SCS Block transfer RETRIES occur during recovery from
SCS failures.
o Data corruptions during large-buffer transfers in the CTM SSI test.
o After trying and failing to send a message to an unreachable
node in a VMScluster, a crash occurs with an ACCVIO, soon after
returning 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 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.
o Upon being notified by SCS that a remote node is no longer
reachable, the SCA transport tries to clean up its structures.
In traversing its PARTNER queue of TPBTX structures, it crashes
with an INCONSTATE.
Problems addressed in the ALPDDTM01_070 kit for OpenVMS Alpha V6.1,
V6.1-1H1, V6.1-1H2, V6.2, V6.2-1H1:
o When a new transaction is about to be started, the system,
already operating under a heavy transaction load, crashes with
the contents of the kernel stack invalid.
Problems addressed in the ALPDDTM02_062 kit for OpenVMS Alpha V6.1,
V6.1-1H1, V6.1-1H2, V6.2 and V6.2-1H1:
o DECdtm corrupts RM Log IDs when it writes them to the
log. The values written to the TM (Transaction Manager)
log were different from those found in the transaction
data structures.
o SYS$TRANSACTION_SERVICES causes memory leaks.
o After a transient SCS failure, and as the two communicating
machines attempt to recover from it, one (or often both) of
those machines crashes with an access violation. The crash
may occur, depending on the exact timing of the failure with
respect to the messaging activity at the time, at a number of
accesses to the structures that SCA maintains.
o When an attempt to initiate a new SCS block transfer fails
because the target node is unreachable, the sending node
crashes shortly afterwards.
o During a block transfer, the receiver node crashes with an
ACCVIO failure.
Problems addressed in the ALPDDTM01_062 kit for OpenVMS Alpha V6.1,
V6.1-1H1, and V6.1-1H2:
o The actions of a transaction log open and a transaction log close
can conflict causing the system to crash with a DDTMBUG bugcheck.
Problems addressed in the ALPDDTM01_062 kit for OpenVMS Alpha V6.2 and
V6.2-1H1:
o With the loss of a virtual circuit connection established between
two cluster nodes, there is the potential for a restarting message
transfer to result in a machine crash.
Problems addressed in the AXPDDTM01_061 kit for OpenVMS Alpha V6.1,
V6.1-1H1, and V6.1-1H2:
o If an attempt is made to rundown the queue manager on a given
node and the node crashes with an access violation within
SYS$IPC_SERVICES, the crash may have resulted from a queue manager
attempting to link to another node at the time of rundown.
o If two machines within a cluster are known to be communicating
with each other using block transfers, it is possible that one of
the machines may crash as a result of the loss of the virtual
circuit connection between the two machines. The resulting crash
is an INCONSTATE bugcheck with SYS$IPC_SERVICES.
o Distributed transactions being executed within a cluster may
stall. If the DECdtm transaction log on a node within the
cluster becomes filled with PREPARED records which are not
forgotten, the distributed transactions being executed on that
node can stall. The customer can verify the state of all the
transaction logs on the nodes within the cluster using the LMCP
Utility commands DUMP/ACTIVE SYSTEM$ and SHOW
LOG/CURRENT on the affected node.
o The queue manager will appear to hang because of the queue
manager process becoming compute bound. Examination of the
process using a SHOW PROCESS/CONTINUOUS command will show
execution PCs within the system space. These addresses
correspond to code within SYS$IPC_SERVICES.EXE.
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.
Files on this server are as follows:
alpddtm03_070.README
alpddtm03_070.CHKSUM
alpddtm03_070.CVRLET_TXT
alpddtm03_070.a-dcx_axpexe
alpddtm03_070.b-dcx_axpexe
alpddtm03_070.c-dcx_axpexe
alpddtm03_070.d-dcx_axpexe
|
