Re: RSLVSP to QTEMP: why new MCH3601 on V5R2?

I observe MATCTX behaves differently on V5R2, too.   MATCTX of the machine
context (that is, MATCTX with null operand 2), in V5R1 and prior, would
include the internal QTEMP library pointers in the materialization
receiver.   But in V5R2, a MATCTX of the machine context no longer includes
the internal QTEMP library pointers in the materialization receiver.

I see the machine context is at constant address: x'0000-00000D-000000' on
each RISC machine.  In System Service Tools, one can count the machine
context entries this way: "display/alter/dump --> dump to printer -->
machine interface object --> 4.permanent context --> find object by address
--> x'0000-00000D-000000' --> 3.Context details".  The result spooled file
includes names of all internal QTEMP libraries, even on V5R2.   But now it
doesn't balance with a MATCTX receiver on V5R2.  It always did in V5R1 and
prior.

So I conclude the internal QTEMP libraries are still same object
architecture in machine context on V5R2 as before; however, IBM has now
blocked MATCTX and RSLVSP from coughing up QTEMP pointers.

Why?  If I can use simple CL break message handling programs to peak into
another job's QTEMP library, then what is so blazingly bad with using QTEMP
pointers in MI?