RE: Weird error involving a *USRQ in QTEMP

Do you have a wrapper around the DEQ instruction that does RSLVSP
followed by DEQ?

I don't even know whether the error is happening in a dequeue
operation.
It could be happening in the enqueue operation.

It won't be that message on an ENQ operation. Worst case, ENQ would give
you a message about referencing storage that you don't own. I assumed DEQ
because I misread your phrase: 'never seen before: he is getting a "Could
not resolve to" message on a *USRQ'

From MI, I am resolving a system pointer to the queue, in the QTEMP
context, immediately after it is created, and as long as the system
pointer I already have for QTEMP is good (and there's at present no
reason not to assume so, as it's used elsewhere, and is BASPCO
POS(65)),
the system pointer to the *USRQ should be good. And I am indeed
enqueueing with an MI ENQ statement.

When you next visit the source to this program, it may behoove you to add
some error handling around that RSLVSP instruction. Fail, yes, but first
tell the user where you are within the program and what you were trying to
do.

_DEQ_Msg_Prefix_T d_msg_prefix;
_SYSPTR queue;
char bar[132];
. . .
queue = rslvsp(_Usrq, "FOO", "QTEMP", _AUTH_ALL);
. . .
#pragma cancel_handler(cancelHandler, 0)
. . .
while (deqi(&d_msg_prefix, bar, queue)) {
<here, the dequeued message is processed>
}
#pragma disable_handler

Yes, that mirrors the way I have done it. I don't see the ENQ you referred
to (I do see DEQ), but anyway I expect issues with resolve. My money's on
either CLRLIB or due to the user gaining access to control the objects in
QTEMP. (E.g. WRKOBJ QTEMP/*ALL followed by option 4 against the idx.)

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"If living conditions don't stop improving in this country, we're going to
run out of humble beginnings for our great men."
-- Russell P. Askue