From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM"  5-MAY-1993 13:55:27.09
To:	EVERHART
CC:	
Subj:	Re: Need help debugging detached processes (REQUEST)

From: jeh@cmkrnl.com
X-Newsgroups: comp.os.vms
Subject: Re: Need help debugging detached processes (REQUEST)
Message-Id: <1993May4.132948.1941@cmkrnl.com>
Date: 4 May 93 13:29:48 PDT
Distribution: usa
Organization: Kernel Mode Systems, San Diego, CA
Lines: 54
To: Info-VAX@kl.sri.com
X-Gateway-Source-Info: USENET

In article <1993Apr30.002641.11139@borland.com>, johnh@borland.com 
(John Haskey) writes:
> 	I'm looking for pointers on debugging detached server processes.
> References to TFM or otherwise are welcomed.  Thanks for your time.

Others have given good responses (DBG$INPUT and ...OUTPUT logicals, 
DECwindows interface) which I won't repeat here.  

I highly recommend the new Motif-based debugger, if you are running on 
VAXstations.  It comes with VAXset V11.  

Personally, I always design my servers so that they won't mind simply being
RUN from a terminal... then I avoid having to set up another terminal with 
at least G:RWLP access, etc.  

Finally, something I stumbled on after YEARS, and I'm sure is old hat to many,
but *I* like it:  

It is trivial to set breakpoints on procedure entry points, but setting them on
lines buried deep inside a procedure requires mucking through the source
display to find what the line number is this time. (Under the new Motif
debugger you just click on a little dot next to the displayed source line --
but you still have to grub through the source to find it.) 

I define a set of global variables such as

	volatile unsigned long	Event_startup = 0,
				Event_login = 0,
				Event_network_error = 0;
				Event_network_error_strange = 0;

and then increment them at appropriate spots -- eg in the network error handler
routine, 

	Event_network_error++;

and then at the point where I determine that the error isn't one I'm prepared
to deal with, 

	Event_network_error_strange++;

Now, if I want to debug the code for one of those events, I just set a
watchpoint on the associated counter!  

This is better than LIB$SIGNAL(SS$_DEBUG), because this way I can easily 
choose which events are "interesting" on this debugging session.  And, the
cost of an increment-long here or there is so low that there's no need to
take these out of the "production" code.  

	--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com  Uucp: uunet!cmkrnl!jeh  CIS: 74140,2055