Do MACRO TRACE messages trigger message traps in general ?
VM:Operator r3.1 running in z/VM 7.3 environment
This is what we've learned regarding MACRO TRACE messages generated by tracing a MACRO running on the VM:Operator server, and why they do not trigger message traps in general.
Using the SYSLOG as an example:
<<< snip >>>
13:40:10 OPERATOR 0007 +++ Thread switch occurred; now running thread 8 +++
13:40:10 OPERATOR 0007 3 *-* arg opt
13:40:10 OPERATOR 0007 >>> "PART1 *1 TESTING"
13:40:10 OPERATOR 0007 4 *-* if opt = ''
13:40:10 OPERATOR 0007 >>> "0"
13:40:10 OPERATOR 0007 6 *-* else
13:40:10 OPERATOR 0007 *-* msg = 'with parm 'opt
13:40:10 OPERATOR 0007 >>> "with parm PART1 *1 TESTING"
13:40:10 OPERATOR 0007 7 *-* 'CP MSG PART1 PTST ACTIVATED 'msg
13:40:10 OPERATOR 0007 >>> "CP MSG PART1 PTST ACTIVATED with parm PART1 *1 TESTING"
13:40:10 OPERATOR 0007 8 *-* exit
13:40:10 PART1 P*1 TESTING
<<< snip >>>
The short answer is that MACRO runs on VM:Operator under process control.
The messages associated with and generated by the running MACRO don’t have a “message class” designation, but rather are marked in the “message class” location with the process number (PCB) associated with the running macro (in YELLOW) … unlike your test message to trigger the MACRO to run that does have a standard “message class” associated with it (in PURPLE). Because the MACRO messages have the internal PCB identifier instead of a standard “message class”, they are not considered in message processing routines.