From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 31-AUG-1989 19:06
To:	MRGATE::"ARISIA::EVERHART"
Subj:	One way to run from one LAT terminal and debug from another.

Message-Id:  <8908312303.AA07558@crdgw1.ge.com>
Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Thu, 31 AUG 89 13:17:58 PDT
Received: from INDYVAX.IUPUI.EDU by KL.SRI.COM with TCP; Thu, 31 Aug 89 13:04:14 PDT
Date: Thu, 31 Aug 89 15:06 EST
From: "James A. Harvey" <IJAH400@INDYVAX.IUPUI.EDU>
Subject: One way to run from one LAT terminal and debug from another.
To: mspecial@zeus.unl.edu, info-vax@kl.sri.COM
X-Vms-To: IN%"<mspecial@zeus.unl.edu>"

In message <3268@zeus.unl.edu>, Dave Caplinger (mspecial@zeus.unl.edu) writes:
>I've been poring over the DEBUG manual for the last couple days trying to
>figure this out, and I could really use some help if anyone would be kind
>enought to offer it! :-)
>
>Basically, I would like to run a program on one terminal while debugging
>it on another. (I have SMG calls, exception handlers, exit handlers, etc
>in my program, so I can't just RUN/DEBUG it on one terminal.)  The DEBUG
>manual says that in this situation you can debug from another terminal
>provided that your system manager is cooperative (and he is :-), but I
>can't get it to work. :-)
>
>I've followed the instructions in the DEBUG manual, but I cannot allocate
>another terminal that I am logged into.  (I can allocate the terminal that
>I'm using currently, but I'm not sure that helps at all.) I'm beginning to
>wonder: are the instructions in the DEBUG manual geared towards hard-wired
>terminals?

Yup, they sure are.  Recently we also got rid of most of our hardwired
lines.  We have a couple left in the machine room but as in your case we
don't want to use them for debugging.  For debugging from LAT sessions I use
the following method.  It's handy for quick and dirty work but if you want
to setup something permanent you might want to define a permanent LAT port
(I've tried that, as described in a previous posting by Steve Ingersoll, but
I can't figure out how to connect from the server to the port).  I've used
the method described below on a VAX 8800 under VMS 5.1-1, DEBUG version
5.0-00 MP using a DECserver 200 (V2.0 BL29, LAT 5.1, ROM BL20).  I'm not
sure if it will work with older software versions or other terminal server
hardware (or older firmware revision levels).  I seem to remember something
similar to this *not* working back in our VMS 4.7 days but I still had a
hardwired line available then so I did not pursue the matter...

1.	Compile and link your program /DEBUG.

2.	Connect to the system using the terminal server (on a new session).
	Login on SYSTEM.

	Note the controlling terminal's device name.  Set the terminal up as
	follows:

	SET TERMINAL LTAnnnn:/PERMANENT/NOTYPE_AHEAD/NOHANGUP/DEVICE=whatever

	(I use VT102 for "whatever" because I use the Kermit terminal
	emulator.  It's no fun being in the debugger in line mode :-).

	Set the device protection or ownership so the job where you are
	running the debugger will be able to access the debugging terminal
	device.  For example:

	SET PROTECTION/DEVICE/OWNER=[username] LTAnnnn:

	(Geez, tell me why there's no SET DEVICE/OWNER command).  You can
	skip the setting ownership step if your debugging something running
	under SYSTEM of course.

	You can omit the /NOTYPE_AHEAD if you are careful and don't connect
	to or send input to the debugging session until you are sure that
	DEBUG is in control of the LTAnnnn: device (otherwise VMS will run
	LOGINOUT on it and DEBUG won't be able to access it).

3.	Logout of the SYSTEM job.  Because the LAT device was set /NOHANGUP,
	the LAT session will not become disconnected.  Because it's set
	/NOTYPE_AHEAD, VMS won't be trying to run LOGINOUT on it when it
	sees unsolicited input on the line.  This LAT session will be the
	one you use for controlling DEBUG.  Type the break character to
	get back to the DECserver prompt.

4.	Connect back to your other session and setup the debugging logicals:

	DEFINE DBG$INPUT LTAnnnn:
	DEFINE DBG$OUTPUT LTAnnnn:

	Note if you're doing something tricky like debugging a detached job
	(a print symbiont for example) you would use DEFINE/GROUP here.
	Remember to put the ":" on the device name, otherwise DEBUG won't
	find it.

5.	Run your program.  The LAT session where you left the LTAnnnn
	terminal set /NOHANGUP will pop up with the %DEBUG-I-INITIAL
	message when you connect to it.  You can then do your debugging.
	Note whenever reconnecting to the debugging session you can always
	repaint the screen (if you're using DEBUG in fullscreen mode of
	course) by typing CTRL/W.  You don't really have to allocate the
	terminal here, since you own it (see step 2) but you can if you
	want to.

6.	When you are finished debugging, exit the debugger by typing CTRL/Z,
	log back into SYSTEM on yet another session, and set the LTAnnnn:
	terminal device /PERMANENT/HANGUP.  The LAT debugging terminal now
	goes offline.  Then connect back into the debugging session one last
	time.  This will cause the terminal to hangup, blowing away anything
	else VMS remembers about the LTAnnnn: device (including the rest of
	the permanent characteristics and the fact that you owned it), and
	the LAT session.  You'll be back at the DECserver prompt.

7.	Don't forget to DEASSIGN the logicals you defined in step 4.
	Otherwise you'll get errors from DEBUG the next time you use it
	because the DBG$INPUT and DBG$OUTPUT device no longer exists.

Hope this helps.  If you have problems with it drop me a line...

- Jim Harvey, Senior Analyst/Programmer, IUPUI Computing Svcs. (DEC Systems)
Internet: ijah400@indyvax.iupui.edu   UUCP: ...{uunet, ?}!iuvax!ivax!ijah400
BITNET: ijah400@indyvax   AT&T: (317) 274-0747                   Disclaimer:
Opinions expressed here are my own and not necessarily those of my employer.


