Weird error involving a *USRQ in QTEMP

First of all, thanks to all those who came up with ideas for my "enhanced SAVCHGOBJ"; what I ended up doing was using an *OUTFILE from the SAVCHGOBJ to direct two RPG Cycle programs: one does a SAVLIB on all libraries that returned a CPF3745 on the SAVCHGOBJ, and the other, since many of the libraries have corresponding IFS directories, attempts to save those directories. Finally, after running both Cycle programs, it does hard-coded saves of two other IFS directories. All saves except the last of the two hard-coded ones are ENDOPT(*LEAVE).

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