From: MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 28-MAY-1992 22:32:05.93 To: info-vax@kl.sri.com CC: Subj: Re: Debugger I/O Redirection in article <35186@unix.SRI.COM>, jeuck@unix.SRI.COM (Philip Jeuck) says: > > I know there must be a way to do this and I did RTFM with no success > so I turn to the infinite wisdom of the net :-). > > I have a process that does graphics and I want to use the debugger on > it. I know how to define debugger input and output and have done it > many times to another terminal line that wasn't logged in (I have the > required priviledges). But on the system I am currently using the > only other "terminal" is a VT1300. I can reroute I/O to a DECTerm > window (FTAn:) but since this window has run loginout I get interplay > with the CLI (every other line goes to the debugger so every command > take at least to two returns). I can't seem to create a DECTerm > window without a login. I've also fooled with SET WINDOW but I don't > seem to get a window or I am not able to direct debug I/O to it. I > don't know if it makes a difference but I have DECW$DISPLAY set to a > null string so the debugger fires up in the terminal window when I > run it in a DECTerm window. > > Thanks for the help in advance. > Here's a messy solution, but it works... You'll need SHARE privilige (in the process being debugged). Log in elsewhere; define the names accordingly. Do a wait 1:0:0 (in DCL) to make it stop reading the terminal. ^C or ^Y when done. I've created a command file which looks up my terminal name and makes group logical assignments, and then waits. As a matter of fact, what I'm debugging is a whole bunch of detached processes, so right before I wait, I start them up (or try, anyways...). If you forget, or you debug for longer than an hour, here's what you do: Put the Jolt down. Type wait 1:0:0 at _every_ prompt until the debugger doesn't complain about it; you might precede it with a SHOW STACK command to get the debugger to go off and do something so that DCL can sneak in a prompt. It is annoying as everything to have DCL grab lines and complain. Be aware that a ^C or ^Y will be trapped by the DCL process, not the debugger. If you "accidentally" GO, you're pretty well hosed. If you have a back door, you can make some kind of "secret knock" result in LIB$SIGNAL(SS$_DEBUG). I did that too; it's kinda neat. You can regain control of the debugger (or get it the first time) by doing that. You can also use that as your "never happen" code, so that you can poke around and find out how your impossible situation came to be. Use some kind of macro capability if you have it. sas -- Steve Suttles Internet: steve@dbaccess.com Dr. DCL is IN! CROSS ACCESS Corporation UUCP: {uunet,mips}!troi!steve Yo speako TECO! 2900 Gordon Ave, Suite 100 fax: (408) 735-0328 Talk data to me! Santa Clara, CA 95051-0718 vox: (408) 735-7545 HA! It's under 4 lines NOW!