From:	SMTP%"diewald@virrus.zko.dec.com" 14-JUN-1993 17:58:14.19
To:	EVERHART
CC:	
Subj:	Re: Debug on the remote node

X-Newsgroups: comp.os.vms
From: diewald@virrus.zko.dec.com (Jeff Diewald)
Subject: Re: Debug on the remote node
Message-ID: <1993Jun14.142141.19126@nntpd.lkg.dec.com>
Lines: 54
Sender: usenet@nntpd.lkg.dec.com (USENET News System)
Reply-To: diewald@virrus.zko.dec.com (Jeff Diewald)
Organization: Digital Equipment Corporation
Date: Mon, 14 Jun 1993 14:21:41 GMT
To: Info-VAX@KL.SRI.COM
X-Gateway-Source-Info: USENET


In article <1659@abb-sc.abb-sc.COM>, rly@abb-sc.abb-sc.com (RAYMOND YANG) writes:
|>Can someone help me to solve the following problem:
|>I am doing a task-to-task communication over the network with two C programs
|>on difference nodes communicate with each other. When one program, VAXCLIENT,
|>runs, it excutes the command file, SERV.COM on the other node.  SERV.COM actual
|>excutes the C program, VAXSERVER, on the same node (remote node).  Two C 
|>programs pass the data to each other. 
|>My question is: how can I debug the remote C program? (assuming that I can 
|>physcially reach the consoles on both nodes at same time , and doing the debug 
|>at for both programs). In fact, I made a debug version for the VAXSERVER.exe, 
|>and run the VAXCLINT.EXE at client side. However, I didn't see anything coming
|>out at the other console, which was what I expected, but found the message that 
|>that VAXSERVER.EXE was activated in the NETSERVER.LOG file.

VMS Debug will not let you debug a program on another node.  That is, you can't
say RUN/DEBUG FOO::DISK$:[BAR]FUM.EXE.  This is also true for the Debugger
RUN command in the DECset V11 and VMS 6.0 debuggers.  This does not mean you
can't debug this kind of configuration.  It just takes two debuggers.

You can use the usual mechanisms to debug the client.  That's the first
Debugger.

Since you have access to the other node, you should be able to use the usual
tricks to debug the server process on the server process' node.  You can 
RUN/DEBUG VAXSERVER, with the appropriate DBG$INPUT and DBG$OUTPUT logicals.
That's the second debugger.  

Or - you can start the server up /NODEBUG.  Then, presuming you have the 
DECset V11 or VMS V6.0 Debugger, you fire up a "kept" debugger with 
DBG$PROCESS set to "MULTIPROCESS."  See the chapter on Debugging Multiprocess 
programs. (Chapter 10 in the 6.0 documentation.)  You can also get on-line help 
for this as well.  

From in the kept debugger, which must be in the same job tree as the VAXSERVER
program, issue a CONNECT command, with the process-id of the VAXSERVER process.
This will effectively do a control-Y/Debug of the server process.  Voila!  You
now have a debugger hooked to your server.  You can now do all of the usual
Debugger magic.

(If you don't have the DECset V11 or VMS V6.0 Debugger, you can still do this.
Set the DBG$PROCESS logical to "MULTIPROCESS."  RUN/DEBUG some toy program
you don't care about.  Get to the initial breakpoint.  Now issue a connect to
the SERVER process.  By making the server process into your current process,
you can debug it, ignoring the toy program process completely.)

Since you'll want to be able to do source level debugging, remember that the
SET SOURCE command will allow you to use node names.  You can SET SOURCE back
to the other machine, where your sources exist.

-------------------------------------------------------------------------------
	Jeff Diewald			EASYNET:   VIRRUS::DIEWALD
	Debug group			INTERNET:  diewald@virrus.zko.dec.com
	Digital Equipment Corp.