On 10-Sep-2015 13:13 -0600, Bob Cagle wrote:
<<SNIP>>

Of the info mentioning maintenance filling DASD, no mention of release, nor the current level Cumulative, but mention of TR implies at least v7r1?

This report does a join on two specific PFs - simple report: join
the files, then print the records where the price in one doesn't
match the other. It's been running multiple times a day, every day,
for years.

But now after the DASD issue, the job runs, but isn't doing anything
I can see. It shows as active on WRKACTJOB, but no activity in the
file I/O, call stack, or job log - it just sits there with no
movement.

And the stack is? I would expect likely a CQE query; seemed an all-too-typical symptom [an apparent hang]. A LIC process dump will include the LIC stack; a second dump taken some time later, might expose changes [similar to F5=Refresh might in Work With Job (WRKJOB) for the Program Stack (*PGMSTK)].


I thought I had it tracked down to a damaged join LF. I wasn't able
to pull up this LF using DBU - just got a continual loading message,
but could pull up each of its base PFs. So I recreated the join LF.
No change.

Are there indexes awaiting rebuild or actively rebuilding, showing in Edit Rebuild Access Paths (EDTRBDAP)?


Just now I've tried recreating this report with SQL in the iSeries
Navigator Run SQL Scripts. Same thing - it's just sitting and
spinning. Again, this isn't a fancy report and should only take a
couple of minutes to run on our system with the data we have.

Any ideas on what's going on here? Is there an index that's been
damaged/needs rebuilt?

I should note that as part of recovering space yesterday, I did a
RCLSTG and an IPL. Now not sure if that was a help or a hindrance.

The preferred order [in the original design] is IPL then Reclaim Storage, but that was the effect of starting the system after the crash :-) An IPL after the reclaim was probably just a hindrance; possibly impacting the ability of the System Database Cross Reference to perform any remaining asynchronous work and the ability of any Access Path rebuilds from completing post-crash.


Thanks for any input,


Not sure of relatedness, but if...

Access paths rebuilt as *AFTIPL will run in /poor/ work management; poor, with respect to an active vs dedicated system. An access path that is rebuilding may be eligible for implementing a query, I am not sure. Submitting a job to effect Open Database File (OPNDBF) with the key [access path] of the file, in a job of a chosen work management that gives better priority than the default runpty-52 QDBSRV## jobs; to ensure the typical jobs across the system do not steal CPU from those jobs.


This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].