Pressing CTRL/Y at DCL level enables you to  interrupt  an  image
     that  is  running  without debugger control, so that you can then
     invoke the debugger with the DCL DEBUG command.

 Format:

       <CTRL/Y>

     Note that you can bring an image under debugger control only  if,
     as  a  minimum, that image was linked with the /TRACEBACK command
     qualifier (/TRACEBACK is a LINK command default).  Also, you  can
     reference  all of the image's symbols while debugging only if its
     modules  were  compiled  and  linked  with  the  /DEBUG   command
     qualifier   (in   that  case,  you  could  use  the  DCL  command
     RUN/NODEBUG to execute the image without the debugger).

     When you press CTRL/Y to interrupt the image's execution, control
     is  passed  to the DCL command interpreter.  If you then type the
     DCL DEBUG command, the interrupted image is brought under control
     of  the  debugger.   The  debugger  sets  its  language dependent
     parameters to the source language of the module  where  execution
     was  interrupted and displays its prompt.  You can then determine
     where execution was suspended by issuing  a  SHOW  CALLS  command
     (and  a  SHOW  PROCESS  command,  in  the  case of a multiprocess
     program).

     When a new debugging session is started, a process is created  to
     run  the  main  debugger  image  (DEBUGSHR.EXE) that controls the
     session.  The main  debugger  process  is  a  subprocess  of  the
     process  that  is running the image to be debugged.  The debugger
     displays its banner when a new session is started.

     Other details about the effect  of  a  CTRL/Y  -  DEBUG  sequence
     depends on the debugging configuration (default or multiprocess),
     which is determined by the current definition of the logical name
     DBG$PROCESS  in  the  process  where  the  interrupted  image was
     executing.

     Do not use CTRL/Y from within a debugging session.  Instead,  use
     CTRL/C  (or  an equivalent CTRL-key sequence established with the
     SET_ABORT_KEY command) This enables you to abort the execution of
     a  debugger  command  or  to  interrupt program execution without
     interrupting the debugging session.

Additional information available:

ExamplesDefault ConfigurationMultiprocess Configuration

     1   $ RUN/NODEBUG TEST_B
             ...
         <CTRL/Y>
          Interrupt
         $ DEBUG

                  VAX DEBUG Version *****

         %DEBUG-I-INITIAL, language is ADA, module set to SWAP
         DBG>

     The  RUN/NODEBUG  command  executes  the  image  TEST_B   without
     debugger  control.   Execution  is  interrupted with CTRL/Y.  The
     DEBUG command then  causes  the  debugger  to  be  invoked.   The
     debugger   displays   its  banner,  sets  the  language-dependent
     parameters to the language (Ada, in  this  case)  of  the  module
     (SWAP)  where execution was interrupted, and displays the prompt.
     This is the default debugging configuration, as indicated by  the
     DBG> prompt.


     2   $ DEFINE/JOB DBG$PROCESS MULTIPROCESS
         $ RUN/NODEBUG PROG2
             ...
         <CTRL/Y>
         Interrupt
         $ DEBUG
                  VAX DEBUG Version *****

         %DEBUG-I-INITIAL, language is FORTRAN, module set to SUB4
         predefined trace on activation at SUB4\%LINE 12 in %PROCESS_NUMBER 1
             12:       K = K + 1
         DBG_1>

     The  DEFINE/JOB  command  establishes  a  multiprocess  debugging
     configuration.   The RUN/NODEBUG command executes the image PROG2
     without debugger control.  The CTRL/Y - DEBUG sequence interrupts
     execution  and  invokes  the  debugger.   The  VAX  DEBUG  banner
     indicates that a new debugging session  has  been  started.   The
     process-specific   prompt  (DBG_1>)  indicates  that  this  is  a
     multiprocess configuration and that  execution  is  suspended  in
     process  1,  which  is  running PROG2.  The activation tracepoint
     identifies the location  where  execution  was  interrupted  (and
     where the debugger took control of the process).

     The default debugging configuration is achieved when  DBG$PROCESS
     is either undefined or has the value DEFAULT.  In this case a new
     default debugging session is started every time  you  invoke  the
     debugger with the CTRL/Y -- DEBUG sequence.

     The  multiprocess  debugging  configuration  is   achieved   when
     DBG$PROCESS  has  the  job-wide definition MULTIPROCESS.  In this
     case, the effect of a CTRL/Y -- DEBUG sequence is as follows:

      o  If a multiprocess debugging session does not already exist in
         the  same  job  tree  as  the process running the interrupted
         image, a new multiprocess debugging session is created.

      o  If a multiprocess debugging session  already  exists  in  the
         same  job  tree,  the  interrupted image and its process come
         under control of that session.  In  this  case  the  debugger
         does not display its banner.

     Note that, within a debugging session, you can  use  the  CONNECT
     command  to  connect  an  image  that is running without debugger
     control in another  process  (of  the  same  job  tree)  to  that
     debugging session.