Re: Filled up the DASD! Now can't run a specific query...

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.