Trouble stopping DECdns when shutting down DECnet-Plus

[Galen Tackett]

I am running DECnet-Plus on OpenVMS Alpha V7.3-2. This system is configured as a DECdns server. It is the only DECnet-Plus system on our network. The other systems all run DECnet Phase IV. (The server setup is in anticipation of other systems possibly migrating to DECnet-Plus some day.)

When I shut down DECnet it gets as far as:

%NET$SHUTDOWN-I-SHUTENTITY, Shutting down DNS CLERK
%NET$SHUTDOWN-I-SHUTENTITY, Shutting down DECdns

Then it just sits and waits forever (apparently). If I ctrl/c it goes ahead and apparently finishes the shutdown, but I see that there's still a DNS$Server process on the system. An ordinary STOP/ID gets rid of it.

How can I get it to shut down cleanly and automatically?

(I recall having this problem way back in the early days of DECnet Phase V but can't recall anything else about it.)

[Ian Miller.]

could the DECdns server be trying to talk to another with a long timeout? How long did you leave it?

[Galen Tackett]

Ian,

I left it overnight once.

Perhaps it is waiting for some other server with a very long timeout. If so this must be default behavior as I have made virtually no changes to DECdns.

Is there a way I can find out for certain?

Thanks,

Galen

[Ian Miller.]

Yuo could look for active network conections with ncl show nsp port and ncl show osi transport port

You could start a trace of directory activity (MCR CDI$TRACE) then do the shutdown

[Ian Miller.]

just a thought "ncl show session control naming search path" is DECdns listed first?

[Lokesh_2]

Hi,

Do SET VERIFY before giving net$shutdown command and see where it hangs. Also, you can do reply/enable to see any opcom message appearing.

HTH,
Thanks & regards,
Lokesh

[Galen Tackett]

Ian,

Yes, DECdns is listed first in the naming path.

The trace reveals that DECnet is repeatedly trying to look up its the address of this node itself. Here's a transcript (typed by hand, so bear with me :-) below. I have substituted "meta-names" for everything except ARDA. The other components of the full name might be considered sensitive.

BTW, this system is not clustered (VAXCLUSTER is set to 0).

[DECnet/CDI Request nnn]
Checking syntax of "NSname:.FOO.BAR.BAZ.ARDA"
[kkk] Syntax check requested
[kkk] DECdns: NSname:.FOO.BAR.BAZ.ARDA"
[kkk] valid syntax

[DECnet/CDI Request nnn+1]
==nnn+1=== DECnet/CDI lookup request for "Nsname:.FOO.BAR.BAZ.ARDA" ===
-nnn+1- first, look up node "Nsname:.FOO.BAR.BAZ.ARDA" ---

[kkk+1] lookup kkk+1: "NSname:FOO.BAR.BAZ.ARDA"
Full name: NSname:FOO.BAR.BAZ.ARDA
Synonym name: ARDA
WARNING!! Failed to translate SYS$CLUSTER_NODE_FULLNAME. Status: 1BC
Alias name :
Synonym alias name :

[kkk+1] -- Entry found in cache --
[kkk+1] Fullname: NSname:FOO.BAR.BAZ.ARDA
[kkk+1] Synonym: ARDA
[kkk+1] Towerset length: 165

- nnn+1 - next, lookup synonym "ARDA" towerset ---

[kkk+2] lookup kkk+2: "ARDA"
Full name:NSname:FOO.BAR.BAZ.ARDA
Synonym name: ARDA
WARNING!! Failed to translate SYS$CLUSTER_NODE_FULLNAME. Status: 1BC
Alias name :
Synonym alias name :

[kkk+2] -- Entry found in cache --
[kkk+2] Synonym: ARDA
[kkk+2] Towerset length: 165

CDI request nnn+1 complete, returning to Session
with lookup status "CDI operation successful"

------ End of transcript -----

By the timestamps less than one second has elapsed while these messages were logged. There follows a delay of 1 minute, and then the whole process repeats with nnn and kkk incrementing accordingly. This just keeps on repeating every minute.

[Galen Tackett]

Oops. I see that I dropped the leading "." in the full names. Just a typo that was propagated by cut/paste. :-)

[Galen Tackett]

Ian,

Just wondering if you saw my last couple of postings here.

If I read the trace correctly, my system (ARDA) is repeatedly doing DECdns lookups of its own name, once per minute. Do you have any idea why this might be happening?

Thanks,

Galen

[Ian Miller.]

Galen, I saw your postings but don't know what's going on. I hope somebody else does :-)

[Galen Tackett]

On a different DECnet Plus system the problem has cropped up again where SYS$CLUSTER_NODE_FULLNAME is not being defined. Does anyone know where this logical name is supposed to get defined??

It sure doesn't happen when my system reboots, or if I manually start DECnet.

[Galen Tackett]

I just answered part of my question.

SYS$CLUSTER_NODE_FULLNAME gets defined (when it does) by SYS$STARTUP:NET$STARTUP.COM.

It's a little unclear to me so far just how that script is supposed to work. It looks to see if the node is clustered (mine isn't) before defining the logical, but I haven't quite figured out the rest of it yet.

:-) So how do I award myself a few points? :-)

[Bill Hall]

Galen,

This shutdown problem sounded familiar, but its been awhile since we've run V7.3-2. I just checked the release notes for DECnet Plus ECO AXP_DNVOSIECO03-V732 at http://www1.itrc.hp.com/service/patch/patchDetail.do?patchid=AXP_DNVOSIECO03-V732&sel={openvms:alpha:7.3-2,}&BC=main|search|.

The problem as I recalled and documented in the release notes was that the DNS server was shutdown before the DNS clerk was shutdown. The clerk kept asking for name resolution against a non-existent server and shutdown hangs. The shutdown order had to be reversed in NET$SHUTDOWN.

Bill

[Galen Tackett]

Bill,

I think my problem is a completely different one that shows a similar symptom, which is SYS$CLUSTER_NODE_FULLNAME not being defined.

In my case I've changed the address of a remote node. Until I define SYS$CLUSTER_NODE_FULLNAME it gets stuck trying to resolve the remote node's name

I should probably have begun a new topic since the actual problem is a bit different. Maybe I'll do that later today.

[Bill Hall]

Galen,

I'm confused. Why do you think you should have SYS$CLUSTER_NODE_FULLNAME defined if you don't have VAXCLUSTER set? Did you configure an alias for this node? I'd suggest getting the latest DECnet ECO installed if it is not already and then running NET$CONFIGURE and verify all of your naming and cluster alias configurations. I would also run DECNET_REGISTER and verify the towers and naming information is correct for the node in question.

Bill

[Galen Tackett]

Most recent replies belong in a separate topic