Library /sys$common/syshlp/dbg$uihelp.hlb DEBUGUI, compile  *Conan The Librarian (sorry for the slow response - running on an old VAX)

  To bring a program under debugger control and take full advantage of
  symbolic debugging, you must first compile and link the program as
  explained here.

  You can use the debugger with programs written in any of the source
  languages listed in the topic Debugger Support for Languages.  The
  following example shows how to compile and link a C program named
  EIGHTQUEENS before using the debugger.  The compiler and linker are
  invoked from DCL level ($).  The program's source code is in the file
  EIGHTQUEENS.C.

  On VAX systems, you explicitly identify linker options files in your
  LINK command:

    $ CC/DEBUG/NOOPTIMIZE EIGHTQUEENS
    $ LINK/DEBUG EIGHTQUEENS,OPTIONS_FILE/OPTIONS

  On AXP systems, you do not identify linker options files:

    $ CC/DEBUG/NOOPTIMIZE EIGHTQUEENS
    $ LINK/DEBUG EIGHTQUEENS

  The /DEBUG and /NOOPTIMIZE qualifiers are compiler command defaults for
  some languages.  These qualifiers are used in the example for emphasis.
  (For more information about compiling and linking that is specific to a
  particular language, see the documentation furnished with that
  language.)

  The /DEBUG qualifier on the compiler command (CC in this case) directs
  the compiler to write the symbol information associated with
  EIGHTQUEENS.C into the object module, EIGHTQUEENS.OBJ, in addition to
  the code and data for the program.  This symbol information lets you
  use the names of variables, routines, and other symbols declared in
  EIGHTQUEENS.C when using the debugger.  If your program's source code
  is in several files, you must compile each file whose symbols you want
  to reference with the /DEBUG qualifier.

  Some compilers optimize the object code to reduce the size of the
  program or to make it run faster.  In such cases you should compile
  your program with the /NOOPTIMIZE command qualifier (or equivalent)
  when preparing for debugging.  Otherwise, the contents of some program
  locations might be inconsistent with what you would expect from viewing
  the source code.  For example, some optimization techniques eliminate
  certain variables so that you no longer have access to them while
  debugging.  (After the program has been debugged, you will probably
  want to recompile it without the /NOOPTIMIZE qualifier to take
  advantage of optimization.)

  The /DEBUG qualifier on the LINK command directs the linker to include
  all symbol information that is contained in EIGHTQUEENS.OBJ in the
  executable image.  The qualifier also causes the image activator to
  start the debugger at run time if you start the debugger by running a
  program, using the following DCL command syntax:

    $ DEBUG/KEEP

  If your program has several object modules, you need to specify those
  modules in the LINK command (for most languages).

  On VAX processors, the /OPTIONS qualifier indicates that OPTIONS_FILE
  is a linker options file.  In the OpenVMS VAX example, the file
  specifies a run-time library to be linked with the program.

  Even if you compile and link an image with the /DEBUG command
  qualifier, you can execute that image normally without it being under
  debugger control.  To do so, use the /NODEBUG qualifier on the DCL RUN
  command.  For example:

    $ RUN/NODEBUG EIGHTQUEENS

  This is convenient for checking your program after you think it is
  error free.  Note that the data required by the debugger occupies space
  within the executable image.  So, when you think your program is
  correct, you might want to link your program again without the /DEBUG
  qualifier.  This creates an image with only traceback data in the debug
  symbol table, which uses less disk space.