It may happen that you want to change the trace setting while tracing interactively. This seems easy, just issue the trace command with the appropriate option and there you go with the new option !
This is true, but there are cases where you may have problems anyway. Suppose you have TRACE ?R active. You reach a statement that gives you problems, and you would like to have a more complete tracing of the statement (for example, you would like the Intermediate tracing). So, you issue the TRACE I command. Unfortunately, it is now too late to re-execute the statement as REXX will immediately continue with the next statement, as you can see in next figure :
» testexec 7 *-* a=10 >>> "10" +++ Interactive trace. TRACE OFF to end debug, ENTER to continue. +++ » 8 *-* b=5 >>> "5" » 9 *-* c=7 >>> "7" » 10 *-* d=4 >>> "4" » 11 *-* e=((c-b)**d)//10 /* this one gives problems */ >>> "6" » trace i 12 *-* say e >V> "6" 6 Ready; T=0.01/0.02 14:38:50
Fortunately, while writing this course and thus re-reading the complete command syntax, your instructors learned another feature of REXX.
If you enter call trace 'i' instead of trace i, REXX will again pause at the statement and enable you to re-execute it (=) with the new tracing option in effect. Look at next figure and see the difference :
» testexec 7 *-* a=10 >>> "10" +++ Interactive trace. TRACE OFF to end debug, ENTER to continue. +++ » 8 *-* b=5 >>> "5" » 9 *-* c=7 >>> "7" » 10 *-* d=4 >>> "4" » 11 *-* e=((c-b)**d)//10 /* this one gives problems */ >>> "6" » call trace i » = 11 *-* e=((c-b)**d)//10 /* this one gives problems */ >V> "7" >V> "5" >O> "2" >V> "4" >O> "16" >L> "10" >O> "6" » 12 *-* say e >V> "6" 6 Ready; T=0.01/0.03 14:39:04
We were now able to re-trace statement 11 with the complete information.
has not this problem. A TRACE command
entered during interactive tracing will not execute immediately next
statement. So, on OS/2, trace and call trace have
the same result.
Everybody knows that many broken things can be repaired by just giving it a kick. VM isn't different. You can give your virtual machine a kick via an attention interrupt (we'll explain a bit later how you can do it).
As CP is the owner of your terminal, it is CP that decides how an attention interrupt is handled. Let's first look at the normal behavior :
CP presents the first(footnote) attention interrupt to CMS and expects CMS to issue a console read (VM READ status). If CMS doesn't do that, a second attention interrupt places you in CP READ.
If however, CMS places the terminal in a VM READ status, it means you have the honor to talk directly to CMS's terminal input handler. So you can issue any immediate command, such as HI, HX, HT. Only immediate commands are not stacked and are thus of use to 'step-in' into an execution loop.
| The VM READ status issued after an attention interrupt is not the same status as the VM READ issued by a VM program prompt (e.g. parse pull, or REXX interactive trace). |
It is possible however that CMS does not react that way, due to one of following reasons:
In those cases, if you issue another attention interrupt, CP places the terminal in a CP READ status. Then, there is not much you can do to recover your CMS. You can try to give CMS another chance by entering the CP command BEGIN, but in most cases, you will need to kill CMS via an IPL CMS.
Let's come back to the case where CMS issues the VM READ status.
If you had a looping procedure (REXX or EXEC2), then a TS (to start the tracing) or a HI (to halt the interpreter) can be used. If it was not a procedure but another type of program that ran, then only HX (halt execution) will be useful.
What we have just explained is the default behavior for an attention interrupt. This behavior can be changed. As a novice user can be confused by the fact that its terminal comes in a CP READ status (for example, when hitting PA1 or due to a second attention interrupt), it is possible to inhibit this situation by issuing the CP SET CONCEAL ON command. Then, the attention interrupt will not result in a CP READ and the PA1 key has no effect anymore.
If you are running in so-called line-mode (you see RUNNING in the status area of your screen), then, to issue an attention interrupt,
If you are running in full-screen (e.g. XEDIT, ISPF, ...), and your keyboard is locked(footnote), then, to issue an attention interrupt,
It is probably a good moment to locate the ATTN and RESET keys. With all the different terminal- and keyboard- emulators, it may be different for everybody. Review the Help of you emulator program to find out where the key is located. And verify this, as it is possible to change the key definitions.
On 3x79, the ATTN key is the upper-leftmost key, while the RESET key is on bottom row under the left-shift key. Many screen emulators will therefore try to use the keys on the same locations, so that the ESC key is used as the attention key, and the Left-Ctrl keys is the reset key.
To end this lesson, a few tips that you may find most useful.
You may have encountered a procedure that continued to ask you the same question with apparently no way out ? A classic reaction is to issue the #CP IPL CMS to break out of this loop. But there is a much nicer solution:
| When in VM READ due to a programmed read (e.g. parse pull) you can still enter immediate commands provided you prefix them with a #-sign, so, #HI or #TS. |
Suppose you want to start the tracing of your procedure at a VM READ prompt issued by a parse pull, like here:
Say 'Please Answer Yes or No' parse upper external YesOrNo if abbrev('YES',YesOrNo,1) then ...
If you enter the #TS command at the moment the system reaches the VM READ status, then CMS will perform two things:
but, the variable YesOrNo is now a null-string, so your procedure will not be able to continue correctly.
Of course, we have also an easy solution for this problem. After you issued the #TS command the interactive tracing is activated and so, you get again a VM READ status, from the interactive trace this time. So, you can issue the statement:
YesOrNo='YES'
to set the variable to a new value.
You learned that you can activate the interactive tracing while your procedure is running by issuing the immediate TS command.
But, after a while, you may have seen enough, and you want to disable the tracing again.
A first solution that comes to mind is to issue the TRACE OFF command. But this is not the best choice here. Indeed, it becomes impossible to turn tracing on again.
If you remember that REXX continuously looks at CMS's external trace bit, then you understand that the first TS has turned the bit ON and REXX tracing has started. The subsequent TRACE OFF stops the tracing, but the trace bit remains ON ! A later TS will thus not change the trace status bit, and REXX will not know that it has to trace again.
As you are good students, you promise now to end interactive tracing with #TE (or by address command 'SET EXECTRAC OFF' for those who love keystrokes). The TE effectively turns the trace bit OFF.
Sometimes, when you trace a procedure, you discover that it has a big logic error and that it is meaningless to run or trace it further. You want to stop it and return to XEDIT to correct the errors.
How can you do that ?
Well, again this is rather simple. While in interactive trace, you are allowed to enter any valid instruction, so, you can also enter the exit statement. It will be executed immediately and take you out of the procedure.
But this may not be safe. There may, for example, remain several records in the stack, and CMS will try to execute these... So, it is far better to issue the combination 'DESBUF';exit in order to flush the stack buffer too.
Even better is to issue the command call exit, provided you have a good exit routine in your procedure that does the necessary cleanup (clearing the stack, closing files, etc.). We already have seen examples of exit routines.
This concludes the lesson on REXX Tracing. It is time now to put some of the things into practice via the exercises.
After writing this text, and testing it out, we discovered that there is a difference in behavior between the ATTN command and the ATTN-key on the keyboard. The ATTN command indeed presents the first interrupt to CMS. With the ATTN-Key, the first interrupt is however presented to CP and only the second one is presented to CMS.
Anyway, just remember to use an attention interrupt to reach a VM READ state.
Back to text
This is the most standard behavior of 3270 applications, i.e.
you enter a command, the 3270 locks
the keyboard to prevent you to enter anything else until the command
ends and only then updates the screen and unlocks the keyboard.
Back to text