DDB (detached debugger) is a utilility to fire up the debugger for a detached
process. DDB is set up as a foreign command:

$ ddb :== $file_path:ddb

It has the following syntax:

$ ddb[/identification=pid][/log=logfile] [process_name]

The process to be debugged is selected via the PID or process name.

DDB works by creating an pseudo (FTAnnn:) and virtual (VTAnnn:) terminal and
linking the two together in the usual way. DDB then sends a kernel mode AST to
the process to be debugged to assign DBG$INPUT and DBG$OUTPUT to be the created
virtual terminal. DDB then transparently copies all the users terminal strokes
to the pseudo terminal. This make it appear to the user that s/he is talking to
the detached process directly.

The configuaration looks like this:

user ---- typing ---> FTAnnn: ----> VTAnnn: ----> detached process + debug
     <--- output ----         <----         <----


When the user has finished debugging the detached process s/he may hit ^\ which
will cause the FTAnnn device to be eventualy hung up. At this point the virtual
terminal disconnects from the physical (nothing physical about it really maybe
logical is a better word for it) terminal. If the user at a later time decides
to reenter debug for this detached process DDB detects that debug has already
been activated and connects a new FTAnnn device to the disconnected virtual
terminal.

There is a small FORTRAN program for you to debug to test it out. Just
@test.com and a process TEST is created at priority 0. Use:
$ @setup.com
$ ddb test
Then wait for the debug prompt to appear.

Please feel free to get in there and hack that code around. Just remember that
even the slightest change to a program of this sort might crash your machine so
don't test it on your production machines. If you make any mods, have any good
ideas, find any bugs or just want my address to send me some dosh *MAIL ME*.

Some problems so far noted:

Some older versions of VMS (older than V5.5 maybe?) had problems were the
FTDRIVER did not like being used with virtual terminals.

You need virtual terminals loaded on the system but you can get away with only
loading the driver at debug time. Setup.com does this.

Hitting return before the process has got its hands on the FTAnnnn: device
causes loginout to be activated. I could set the terminal notype_ahead but then
you don't get to type ahead in debug. I suppose I should not transfer
keystrokes to the FTAnnnn: until I know the debug process has assigned.

The program leaves logical names hanging about in the system table. These maybe
should be gotten rid of by the target process but I am not sure what the best
way of doing this is.

Virtual terminals eventualy try to delete themselves after a certain period of
time has elapsed. This is determined by the sysgen parameter TTY_TIMEOUT
(default is 900s = 15 mins). After this timeout period you can not return to
debug the process.

You can only debug a process that has the same UIC as yourself. The terminal
driver will not allow reattachment unless UICs match regardless of privilege.

Sometimes it takes a long time for the debugger to activate. If the process you 
are debugging dies before it gets into debug (notraceback or quota problems)
you sit in DDB forever. You can get out with ^\.

In order to debug at a level other than assembler instructions the image must
have been compiled and linked /debug. The easiest way of doing this is to
activate the detached process with a CLI and issue a run/nodebug command in the
processes sys$input command file:

$ run/deta/input=cmd_proc.com/out=output_file sys$system:loginout.exe

Where cmd_proc.com contains:

$ run/nodebug image

After posting this file to comp.os.vms I received the following brilliant idea
from Don Stokes (don@zl2tnm.gen.nz):

>A better way is to link the image /DEBUG and flip the debug bit in the
>image header (leaving the symbol table intact).  I kinda wish there were
>separate qualifiers to build a symbol table and set the DEBUG bit.  Then
>run the program in its native environment.  Things change a bit when
>running under DCL.  All the debug bit does is indicate that the debugger
>kicks into life on image startup before passing control to the second
>transfer vector.
>
>Anyway, the following command file will do this for you:
>
>$       on warning then goto abort
>$       open/read/write in 'f$parse(p1, ".EXE")'
>$       read in header
>$       header[%x20*8,1] = 0
>$       write/update/symbol in header
>$ abort:close/nolog in
>$       exit
>
>And yes, I would like you to make your program available....  8-)
>

I only wish I had thought this up myself :-(

*WARNING*

This code is very hacky and as such requires the following warning:

Use at your own risk. If it crashes your machine then thats tough! I accept
*NO* responsibility for it what so ever.

Its kernel, its privileged, its version dependent, its unsupported (by anyone)
and its likely to break if you upgrade the OS/debug something funny (ACP)/stand
in a funny way.

Don't install this image with privileges.

I wrote this code for fun not money but of course I would like to know of any
bugs etc.

                              Neill

neill@macro.demon.co.uk