|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.