Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
ALPDDTM06_062 Alpha V6.2 DECdtm ECO Summary
*OpenVMS] ALPDDTM06_062 Alpha V6.2 DECdtm ECO Summary
New Kit Date: 20-NOV-2002
Modification Date: Not Applicable
Modification Type: NEW KIT
Copyright (c) Compaq Computer Corporation 2002. All rights reserved.
PRODUCT: OpenVMS Alpha
COMPONENT: DEC Distributed Transaction Manager (DECdtm)
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: ALPDDTM06_062
ECO Kits Superseded by This ECO Kit: ALPDDTM05_062
ECO Kit Approximate Size: 1908 Blocks
Kit Applies To: OpenVMS Alpha V6.2
System/Cluster Reboot Necessary: No
Rolling Re-boot Supported: Information Not Available
Installation Rating: INSTALL_1
1 - To be installed by all customers.
Kit Dependencies:
The following remedial kit(s) must be installed BEFORE
installation of this kit:
None
In order to receive all the corrections listed in this
kit, the following remedial kits should also be installed:
None
ECO KIT SUMMARY:
An ECO kit exists for DEC Distributed Transaction Manager (DECdtm)
on OpenVMS Alpha V6.2. This kit addresses the
following problems:
PROBLEMS ADDRESSED IN ALPDDTM06_062 KIT
o If the user had installed the ALPDDTM04_062 ECO kit, the
images in the ALPDDTM05_062 ECO kit would not install. The
user would see the following error message for all DDTM
images:
Applying [IMAGE_NAME] will result in a regression in the
bugfix level while maintaining the same level of layered
product functionality.
Note that if you successfully installed the ALPDDTM05_062 ECO
kit, you do nto need to install this ALPDDTM06_062 kit.
Images Affected:[SYSLIB]DTI$SHARE.EXE
[SYS$LDR]SYS$IPC_SERVICES.EXE
[SYS$LDR]SYS$TRANSACTION_SERVICES.EXE
PROBLEMS ADDRESSED IN ALPDDTM05_062 KIT
o The system can crash with SSRVEXCEPT in TPSERV.EXE. The
failing instruction is INSQUEL.
Crashdump Summary:
------------------
Crash Time: 20-AUG-1998 01:07:16.89
Bugcheck Type: CSLBUG, CSL has detected an
invalid condition
Node: KKBH01 (Clustered)
CPU Type: AlphaServer 8400 Model 5/300
VMS Version: V6.2-1H3
Current Process: TP_SERVER
Current Image: DSA2982:[SYSO.SYSCOMMON.]
[SYSEXE]TPSERV.EXE;5
Failing PC: 00000000 00023210
Failing PS: 20000000 00000001
Module: TPSERV
Offset: 00023210
Images Affected:[SYSEXE]TPSERV.EXE
o The TP_SERVER process can loop consuming CPU cycles.
Images Affected:[SYSEXE]TPSERV.EXE
PROBLEMS ADDRESSED IN ALPDDTM04_062 KIT:
o The image SYS$IPC_SERVICES.EXE should have been included in the
ALPDDTM03_062 remedial kit. It was not. Customers who
installed the ALPDDTM03_062 kit did not get all the problem
corrections listed in the documentation.
PROBLEMS ADDRESSED IN ALPDDTM03_062 KIT:
o An RDB/ACMS application was ported from OpenVMS VAX V6.2 to
OpenVMS Alpha V6.2. When the full user load was on the nodes,
they imtermittently crash about once a day due to nonpaged pool
corruption of 128 byte packets.
o System bootup cannot start TP_SERVER. Manually starting it
with DECDTM$STARTUP failed with STR-F-ERRFREDYN.
Two failure scenarios were present:
1. If the DECdtm journal file did not exist, the TP_SERVER
process crashed with a STR-F-ERRFREDYN error. The OPCOM
message, normally generated when the journal file is not
present, appeared normal:
$ @sys$startup:decdtm$startup
%%%%%%%%%%% OPCOM 16-SEP-1997 10:00:25.06 %%%%%%%%%%%
Message from user SYSTEM on K
Warning: DECdtm log file not found (SYS$JOURNAL:
SYSTEM$K.LM$JOURNAL)
%RMS-E-FNF, file not found
TP server process waiting
However, there was no TP_SERVER process. The
TP_SERVER_ERROR.LOG contained (slightly edited due to
space constraints here):
%STR-F-ERRFREDYN, error freeing dynamic string when
returned to LIB$FREE_VM %TRACE-F-TRACEBACK, symbolic stack
dump follows
Image Name Module Name Routine Name Line Number
TPSERV DTIS_ENVIRONMEN DTI$CHECK_ENVIR 400
TPSERV LM_SERVER MAIN 599
2. If the DECdtm journal file did exist, TP_SERVER stack
dumped into the TP_SERVER_ERROR.LOG with STR-F-ERRFREDYN,
but no process dump was generated. In this instance, no
OPCOM message relative to "file not found" would be
generated (because the journal file did exist). The
TP_SERVER_ERROR.LOG contained (again, slightly editted):
Image Name Module Name Routine Name Line Number
TPSERV DTIS_ENVIRONMEN DTI_TRNLNM 1106
TPSERV DTIS_ENVIRONMEN DTI$CHECK_ENVIR 418
TPSERV LM_SERVER MAIN 599
Regarding the use of string descriptors in the module
DTIS_ENVIRONMEN, dynamic string descriptors were being used for
calls to system services ($GETMSG, $FAO, and $TRLNM) that
expected fixed length string descriptors. In addition, the
lengths of the strings were being manipulated by the TPSERV
code, which is strongly cautioned against in the OpenVMS
documentation that discusses the various types of string
datatypes. When STR$FREE1_DX was called to free the memory
consumed by the string, the illegal manipulation that had been
done in the TPSERV code, caused STR$FREE1_DX to fail.
o Nonpaged pool expands constantly, filling with hundreds of
thousands of DDTM_NDCB structures until it reaches maximum and
the machine hangs or crashes. This problem has only been seen
on ALPHAs.
PROBLEMS ADDRESSED IN ALPDDTM03_070 KIT FOR OPENVMS V6.2, V6.2-1H1,
V6.2-1H2, V6.2-1H3 ONLY:
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 ALPDDTM02_070 KIT FOR OPENVMS V6.2-1H1 ONLY:
o The ALPDDTM01_070 remedial kit did not install on systems
running OpenVMS Alpha V6.2-1H1, as it should have.
PROBLEMS ADDRESSED IN ALPDDTM01_070 KIT FOR OPENVMS V6.2, V6.2-1H1
ONLY:
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 this problem.
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 ALPDDTM02_062 KIT FOR OPENVMS V6.2, V6.2-1H1
ONLY:
o DECdtm was corrupting RM Log IDs when it wrote 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 sender node
crashes shortly afterwards.
o During a block transfer, the receiver node crashes with an
ACCVIO failure.
PROBLEMS ADDRESSED IN ALPDDTM01_062 KIT FOR OPENVMS V6.2, V6.2-1H1
ONLY:
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.
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 s
earch strings: 'ALPDDTM06_062' or 'ALPDDTM'.
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:
Install this kit with the VMSINSTAL utility by logging into the
SYSTEM account, and typing the following at the DCL prompt:
@SYS$UPDATE:VMSINSTAL ALPDDTM06_062 [location of the saveset]
The saveset location may be a tape drive, CD, or a disk directory
that contains the kit saveset.
No reboot is necessary after successful installation of the kit.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| DTI$SHARE.EXE | EFAED50B | ALPHA X61Q-Z2A | 21-MAY-2002 |
| | | 10:16:37.77 |
+----------------------------+----------+-----------------+--------------+
| SYS$IPC_SERVICES.EXE | 5DB1C11C | X-3 | 10-JAN-1997 |
| | | 12:30:47.38 |
+----------------------------+----------+-----------------+--------------+
| SYS$TRANSACTION_SERVICES.EXE| 6937B40D| X-3 | 21-MAY-2002 |
| | | 10:16:50.93 |
+----------------------------+----------+-----------------+--------------+
| TPSERV.EXE | DB79342C | A-15 | 21-MAY-2002 |
| | | 10:16:55.04 |
+----------------------------+----------+-----------------+--------------+
|
