Re: Weird error involving a *USRQ in QTEMP (PRIVATE REPLY)

Hi, James:
* >>>---> private reply, off-list <---<<<*

Certain software products from certain vendors think it is perfectly acceptable to issue:

CLRLIB QTEMP

at various points during their processing. So, although you may have created this *USRQ in QTEMP, there is no guarantee that it will still be there, when you are ready to use it ...

Is this happening in an interactive job? Or "batch"? Or what, exactly? What other vendor software does this customer have installed?

You might need to consider creating a data area *CHAR 10 that contains "QTEMP " but where, for these special cases, at certain customer sites, you can substitute the name of some other permanent library, e.g. by changing the contents of this data area ... :-o

Hope that helps?

Mark

> On 5/12/2010 12:09 PM, James H. H. Lampert wrote:

...(snip)...
But on to the problem du jour:

We have a customer who is experiencing a problem that I've never seen
before: he is getting a "Could not resolve to" message on a *USRQ that
we explicitly create in QTEMP when the application is launched. So far
as I can determine, all of our references to the *USRQ are fully qualified.

There is no sign that the program that creates the *USRQ is out-of-date,
and even if it were so far out-of-date that it didn't create it, it
wouldn't reference it, or call anything that referenced it, either.

And to top it all off, at the end of the list of error messages he sent
us, there's a "Help not defined for . . . command" message, referring to
a command for which help is most certainly defined.

At this point, I'm stumped. I'm waiting to find out whether it's
isolated or ongoing, specific to a single user or happens to everybody,
and what's in QTEMP after the failure.


--
JHHL