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" 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%"" 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.