RE: Weird error involving a *USRQ in QTEMP

Do you have message IDs? Job logs? Anything we can sink our teeth

into

here? "Could not resolve to message" or "could not resolve to user

queue?"

What instruction was being executed? What were the parameters
specifications? What were the parameter values?

About the only other things I can tell you about the QUSCRTUQ call is
that (as I said earlier) it's created explicitly in QTEMP, it's FIFO,
message length 132, initial 64 messages, increment 64 messages, public
*EXCLUDE (as if that made any difference for a *USRQ created in QTEMP),
REPLACE(*NO), *USER domain, *NO pointers.

OK. But I wasn't asking about QUSCRTUQ. More about DEQ, et cetera. Do you
have a wrapper around the DEQ instruction that does RSLVSP followed by DEQ?
Or do you resolve the SP beforehand and then later (perhaps much later)
dequeue the message? Do you know if any messages were retrieved already?
Is it possible that a CLRLIB or other action wiped out your hard work of
QUSCRTUQ? Is a wait time involved?

But mostly, what were those error message IDs? The one on the DEQ and the
one for which there was no help text available...


Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Open 24 hours. Lifeguard on duty 8AM to 8PM. Drowning absolutely
prohibited."
-- Swimming pool suggestions posted at Plantation Bay Resort,
Phillipines