MACRO TRACE Messages

Products

• VM:Operator

Issue/Introduction

Do MACRO TRACE messages trigger message traps in general ?

Environment

VM:Operator r3.1 running in z/VM 7.3 environment

Resolution

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.