Answer to question 14

Let's review some details from the lesson to set things clear :

TS is an immediate command, and only the CMS terminal interrupt handler recognizes immediate commands.  I.e. they can only be entered in line mode (on the so called CMS Ready prompt).

SET EXECTRAC ON on the other hand is an ordinary CMS command that can be issued everywhere (e.g. even from the XEDIT command line).

Apart from that, there is no real difference, they set the same trace bit on.

So, the immediate command TS can't be coded in procedures, the SET EXECTRAC command can.  But why would an exec want to use it as we can use the TRACE statement or function ?

Think a while before continuing to read.

Though you normally won't fine tune tracing of an exec by including a SET EXECTRAC ON/OFF command, there are two occasions where it might be handy:

  1. Your exec wants to trace another, called exec and you don't want to change the called exec.  Look at next very simple example: 
    /* Procedure A */                    | /* Procedure B */
trace "N"                            | /* We want to trace this */
/* ... do much work that would give  | Trace N
       too much trace output ... */  | say 'Hello'
a=10                                 | exit
'SET EXECTRAC ON'
'EXEC B'
b=20
/* ... do other work ... */
exit

    This produces following output: 

       » A
     6 *-* 'EXEC B'
       >>>   "EXEC B"
       +++ "CMS COMMAND B EXEC A1 B CMS"
     1 *-* /* Procedure B */
           /* We want to trace this */
     2 *-* Trace N
       +++Interactive trace.  TRACE OFF to end debug, ENTER to continue.+++
   »
     3 *-* say 'Hello'
       >>>   "Hello"
Hello
   »
     4 *-* exit
       +++Interactive trace.  TRACE OFF to end debug, ENTER to continue.+++
   »
     7 *-* b=20
       >>>   "20"
     8 *-* /* ... do other work ... */
   »
     9 *-* exit

    The SET EXECTRAC ON just before the call to EXEC B activates the tracing (trace bit on), and remark that even the Trace N of procedure B gets overridden !

  2. You are in a subroutine of your exec, and suddenly you realize you'd want to start tracing a higher-level routine (in the same exec or even another exec). 

      /* procedure TT */
  Say 'suppose here are lots of statements you don''t want traced.'
  call subrout1
  a='much imaginary work of main routine'
  ab=a b
  exit
  subrout1:
      Say 'Running happily in subroutine 1'
      Say 'Imagine this SAY represents lots of REXX statements'
      call subrout2
      b='this data from subroutine1'
      b2='king of harts'
      return
  subrout2:
      trace ?r   /* trace as we suspect a bug in this subroutine */
      Say 'Just to confirm subroutine 2 is running'
      c='some stuff from subroutine 2'
      cc=c c
      dd=f g z
      return

    Remember the rule about the scope of REXX's trace: trace setting is local to the subroutine level, and the called procedure inherits the trace setting of the caller.  So there is no REXX way to start tracing the main routine when you are in SUBROUT2.  But, if you set the external trace bit on with SET EXECTRAC ON, REXX will realize after returning from SUBROUT2 that you want to trace interactively and both SUBROUT1 and the main routine will get traced, as can be seen in the console output: 

     » TT
   suppose here are lots of statements you don't want traced.
   Running happily in subroutine 1
   Imagine this SAY represent lots of REXX statements
       18 *-*   Say 'Just to confirm subroutine 2 is running'
          >>>     "Just to confirm subroutine 2 is running"
   Just to confirm subroutine 2 is running
          +++Interactive trace.  TRACE OFF to end debug, ENTER to continue.+++
 »
       19 *-*   c='some stuff from subroutine 2'
          >>>     "some stuff from subroutine 2"
 »
       20 *-*   cc=c c
          >>>     "some stuff from subroutine 2 some stuff from subroutine 2"
 » 'SET EXECTRAC ON'
 »
       21 *-*   dd=f g z
          >>>     "F G Z"
 »
       22 *-*   return
       12 *-*  b='this data from subroutine1'
          >>>    "this data from subroutine1"
          +++ Interactive trace.  TRACE OFF to end debug, ENTER to continue. +++
 »
       13 *-*  b2='king of harts'
          >>>    "king of harts"
 »
       14 *-*  return
        4 *-* a='much imaginary work of main routine'
          >>>   "much imaginary work of main routine"
          +++ Interactive trace.  TRACE OFF to end debug, ENTER to continue. +++
 »
        5 *-* ab=a b
          >>>   "much imaginary work of main routine this data from subroutine1"
 »
        6 *-* exit

In practice:

  1. To trace an exec that is not yet running, you can type TS or SET EXECTRAC ON at the Ready; prompt, resulting in 100% identical results.
    From any fullscreen application (e.g. XEDIT, PROFS,...) TS won't work so you have to type SET EXECTRAC ON.
  2. To trace an exec that is already running (maybe looping) you have no real choice anymore: on a line mode screen you could type SET EXECTRAC ON, but that will get queued until the exec ends and so is of no use here ; only TS will be helpful. 
    If you are in full-screen mode, you first have to go to line mode by generating an attention interrupt (see lesson 2) and then proceed as above.
  3. To trace an exec that placed you in VM READ, you have only one solution left, namely #TS.

If you still are confused, please review the text of the lesson.

Use the backward navigation button to return to the lesson text.