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 Alpha and I64 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.

  On Alpha and I64 systems, you can debug programs that have been linked
  with the /DSF qualifier (and therefore have a separate debug symbol
  file).  The /DSF qualifer to the LINK command directs the linker to
  create a separate .DSF file to contain the symbol information.  This
  allows more flexible debugging options.  Debugging such a program
  requires the following:

  1.  The name of the .DSF file must match the name of the .EXE file
      being debugged.

  2.  You must define DBG$IMAGE_DSF_PATH to point to the directory that
      contains the .DSF file.

  For example:

     $ CC/DEBUG/NOOPTIMIZE TESTPROGRAM
     $ LINK/DSF=TESTDISK:[TESTDIR]TESTPROGRAM.DSF TESTPROGRAM
     $ DEFINE DBG$IMAGE_DSF_PATH TESTDISK:[TESTDIR]
     $ DEBUG/KEEP TESTPROGRAM