[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference movies::decdtm-vms

Title:DECDTM-VMS
Notice:DECdtm Conference. 260.* for docs & kits. Digital Confidential
Moderator:MOVIES::PLAYFORD
Created:Fri Aug 12 1988
Last Modified:Fri May 30 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:353
Total number of notes:1278

351.0. "SYSTEM-F-DUPLNAM" by MUCTEC::JOCHEN () Tue Apr 08 1997 08:54

Hello,

	is there anybody who has experienced the below listed error
	message before?

	I do have a customer running 2PC Transactions through Rdb and
	RMS. The customer is using a FE machine which does do the
	explicit Start transaction, maintains a RMS file and does
	do an Database update on a BE machine through remote Rdb using
	explicit 2PC. Usually this does work quite well for over 2 years
	now. Some times (up to now about 5 to 6 times) the customer has
	got the following error message.

%RDB-F-SYS_REQUEST_CAL, error from system services request, called from 100001
-RDB-E-DECDTMERR, DECdtm system service call error
-SYSTEM-F-DUPLNAM, duplicate name

	To resolve this kind of situation the customer has to reboot
	all nodes which have been part of the 2PC transactions. The FE and
	BE nodes are part of two different clusters. All related machines
	are AXPs running VMS V6.2 and DECNet OSI Phase V.

	Any idea where to look, or what has caused this kind of error?
	Any inputs are appreciated.

Thank you in advance,

	Joachim Stetter
T.RTitleUserPersonal
Name		DateLines
351.1MOVIES::POTTERhttp://www.vmse.edo.dec.com/~potter/Wed Apr 09 1997 10:2610
Joachim,

This is not a problem I'm familiar with.

If this is causing grief to the customer it might be good to make the
machines dump when they are rebooted, and escalate this to the current
DECdtm maintainer.

regards,
//alan
351.2CLOSED links??GIDDAY::YUThu Apr 10 1997 04:5317
    Hi,
    
    One of our customers is having the same problem. When the problem
    occurs, there are some session control ports on the BE which are 
    left behind as a result of broken DECnet links. If he deletes these 
    session control ports using NCL, then the problem disappears. However
    if the BE machine is a DECnet phase IV machine, then there would be a
    lot of links in closed state and there seems to be no way to delete 
    these closed links and the problem persists. These closed links and
    their associated NET devices are owned by the IPCACP process. Any idea
    why IPCACP still assigns to the NET devices after the DECnet logical
    links are disconnected?
    
    Thanks and regards.
    
    Michael