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

Conference noted::dtss

Title:	DTSS_NOTE

Moderator:	TUXEDO::BARYIAMES

Created:	Mon Jul 31 1989
Last Modified:	Thu May 29 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	624
Total number of notes:	2671

624.0. "DTSS User Buffer Unavailable during startup" by CHR27::YEUNG (im2bz2p,ru?) Tue May 27 1997 22:53

Two VAX 4000/96, 64MB
VAX/VMS V6.2, DECnet V6.3+ECO06, DNS ECO2070

Both VAX systems are DNS servers, DTSS servers/time providers, and
BIND name resolvers.  One has the master replica of all DECdns directories.
The other has the readonly replica.
Both systems are tuned identically.

If the customer reboots the system that has the DECdns readonly replica,
DTSS is hung during startup.  MC NCL SHOW DTSS ALL also gets hung.
ANA/SYS SHOW LAN /COUNT shows DTSS (DNAME) to have 32 User Buffer Unavailable.
While this is going on, DNS skulks does not work.
After about 10 minutes, the SHOW DTSS ALL command returns with the
results and DTSS/DNS seems to work perfectly from then on.

The other VAX that has the master DNS replica does not have this problem.
What would cause DTSS to get so many User Buffer Unavailable and hang
during startup and how do you fix it?

Thanks

Tim

T.R Title User Personal
Name Date Lines

624.1 TWICK::PETTENGILL mulp Thu May 29 1997 02:51 27

T.R	Title	User	Personal Name	Date	Lines
624.1		TWICK::PETTENGILL	mulp	`Thu May 29 1997 02:51`	27
	The user buffer unavailable is just a symptom. DTSS uses DECdns to read the global directory to get the global time servers. If DECdns is just starting up and not fully operational, then DTSS is probably going to "hang" with a single threak stalled inside the DNS rtl directory lookup code. There are a lot of rtl calls that appear to be too infrequently used and often time very complex that don't get aggressively designed to support multithreaded use. One example would be a protected rtl which executes in exec mode and does network calls; the "correct way is to do all calls asynchronously, even in a routine that doesn't return until the results are returned, and then wait in user mode for the network I/O to complete. The reason that is desirable is that this allows a user mode AST to run while the exec mode library routine is executing. However, this turns a simple straight line module into an obscure one, and when the logic is already complicated for the straight line code, few people can comprehend the result of allowing it to be interrupted. Now what might be happening is that you are running into a DNS design bug which is really obscure. Something about the server trying to lookup its own addresses and the code that connects to the server tried to lookup its address which then connects to the server and needs to lookup its address, and so on. Take a look in the sys$manager:DNS$CHFAIL.LOG and see what it says right after the system has booted up. My guess it that you'll see some lookup errors in there that have timestamps that correspond to when DTSS is trying to startup.

The user buffer unavailable is just a symptom.  DTSS uses DECdns to read
the global directory to get the global time servers.  If DECdns is just
starting up and not fully operational, then DTSS is probably going to
"hang" with a single threak stalled inside the DNS rtl directory lookup code.

There are a lot of rtl calls that appear to be too infrequently used and
often time very complex that don't get aggressively designed to support
multithreaded use.  One example would be a protected rtl which executes
in exec mode and does network calls; the "correct way is to do all calls
asynchronously, even in a routine that doesn't return until the results are
returned, and then wait in user mode for the network I/O to complete.  The
reason that is desirable is that this allows a user mode AST to run while
the exec mode library routine is executing.  However, this turns a simple
straight line module into an obscure one, and when the logic is already
complicated for the straight line code, few people can comprehend the
result of allowing it to be interrupted.

Now what might be happening is that you are running into a DNS design bug
which is really obscure.  Something about the server trying to lookup its
own addresses and the code that connects to the server tried to lookup its
address which then connects to the server and needs to lookup its address,
and so on.

Take a look in the sys$manager:DNS$CHFAIL.LOG and see what it says right
after the system has booted up.  My guess it that you'll see some lookup
errors in there that have timestamps that correspond to when DTSS is
trying to startup.