×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 03 Jul 2012 09:44, Dave wrote:
I need to take care of all the *QRYDFN on the system that use a file
I've modified.
I got the list by querying the output of DSPPGMREF on all the
objects on the system. All the QRY have the field WHSPKG = 'Q'
I copied all the QRY I found to my development library, and then
using WRKQRY, I used option 2 + save to get them to use the new file
format. I copied them all back to the original libraries then I ran :
DSPPGMREF PGM(*ALLUSR/*ALL) OUTPUT(*OUTFILE) OBJTYPE(*QRYDFN)
OUTFILE(mylib/QRYDFN)
I'm only seeing one of the many QRY I modified in this outfile.
What am I missing or how should I have done this?
From the described steps\activity performed, there would seem to be a
problem somewhere. However all of the activity was not very explicitly
described; difficult to determine if what is missing is usage or an
apparent defect.
What is being used to review, to see, the row data written to the
output file for the DSPPGMREF request? Is there some omit\select logic,
a query request, possibly causing an issue for what rows were displayed?
What "copy" feature was utilized to effect having "copied them all
back to the original libraries" after 2=Change+Save: WRKQRY 3=Copy [with
replace=yes, knowing the original still exists] or CRTDUPOBJ after
DLTQRY of the original, or something else? Are any of the missing row
data representing query definitions in libraries that are not part of
*ALLUSR; e.g. in a library name starting with a 'Q'? If copied via the
Work with Queries option 3=Copy, I suppose there could be a defect in
that feature for how the queries are created [differently than when
saved, and perhaps only when using replace=Yes], although I thought that
feature just used the CRTDUPOBJ after an effective DLTQRY.
The following CALL request may be effective in correcting the
condition of [presumably] missing information; i.e. recovery for a
presumed defect for 2=Change+Save or whatever "copy" feature having
failed to properly add or save the file reference\where-used OIR data
for the *QRYDFN object:
http://www-01.ibm.com/support/docview.wss?uid=nas3a7aab5b4c4a56c9d8625753d00631146
"... CALL PGM(QSYS/QQUIWHOI) PARM('LIBNAME') ..." <-- or '*ALL'
If that program invocation corrects the problem for missing OIR data
[for *QRYDFN objects in library LIBNAME; or *ALL libraries], then review
how to recreate the problem to determine if the saved queries not
getting updated {and thus} or are the replaced query definitions losing
their OIR data, and report the outcome as defect to your service provider.
FWiW there is also a IBM i 7.1 APAR SE52035 for missing data in
DSPPGMREF for *QRYDFN objects; though for specific columns, nothing
implied about missing rows:
http://www-01.ibm.com/support/docview.wss?uid=nas2c1f97bb7cf52434386257a01003caa8c
Regards, Chuck
midrange.com
