[MI400] RSLVSP to QTEMP: why new MCH3601 on V5R2?

[Gene_Gaunt@xxxxxxxxxxxxxxx]

Why was V5R2 changed such that RSLVSP to a full QTEMP internal library name
now fails with MCH3601 (pointer not set)?

I test the following MI code (on level 30; or in *system state* on level
40+), and observe instruction 3's RSLVSP works okay on V5R1 and prior
releases; but, instruction 3's RSLVSP now fails on V5R2 with MCH3601:

DCL DD     DATA       AUTO CHAR(96) BDRY(16);
DCL DD     *          DEF(DATA) POS(1) BIN(4) INIT(96);
DCL SPCPTR ?DATA      AUTO INIT(DATA);
DCL DD     NAME       AUTO CHAR(34);
DCL SYSPTR ?OBJECT    AUTO;
DCL SYSPTR ?QTEMP     BASPCO POS(H"41");

MATPR    ?DATA, ?QTEMP;
CPYBLAP  NAME, DATA(H"2A":32), X"00";
RSLVSP   ?OBJECT, NAME, *, *,
BRK      "LOOK";
PEND;

Why was SLIC changed to trigger MCH3601?

By the way, MCH3601 (pointer not set) is a different issue than MCH3401
(cannot resolve to object).  MCH3401 occurs when the RSLVSP operand 2
contains a bad object name.  This new MCH3601 is a mystery to me.  Why
should pointer settings matter on *input* to RSLVSP in V5R2?

I know, I know, some will holler "why do you want to resolve a pointer to
QTEMP, why not just fetch the pointer from BASPCO".  Because when my MI
program finds a pointer to an object that resides in a context, I want to
backtrack and materialize the context containing the object.  So I use
MATPTR or MATSOBJ to get the full 32-byte context type/subtype/name from
the pointer, then RSLVSP to it to get the context pointer.  In V5R1 and
prior, this worked fine if the context was QTEMP.   Yep, even if it was
another job's QTEMP.

Does someone know an alternative method to get the containing context
pointer from a pointer?