One of the statements in the CONACC mentioned something about records being updated... theoretically, *CURCMT would use the 'old' data already in the file instead of whatever the user's updating now, and would merrily roll along.
Are any of the files currently (!) being updated? With some weird locks? Why would you be able to access just up to a certain point?
Any strange data in the files at the records it stalled at (or plus or minus a few records)?
Are the files small enough you could clone them all and run the query over the copies? Just for fun?
Paul E Musselman
PaulMmn@xxxxxxxxxxxxx
-----Original Message-----
From: Musselman, Paul
Sent: Thursday, February 15, 2018 11:54 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: Query "stopped" in its tracks, still "running"
"I learn from my mistakes and can repeat them exactly!" (:
Paul E Musselman
PaulMmn@xxxxxxxxxxxxx
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan
Sent: Wednesday, February 14, 2018 3:20 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Query "stopped" in its tracks, still "running"
Good find. The RUNSQL command has a Concurrent Access parameter, so I
specified CONACC(*CURCMT), but I am getting the same results. In fact, the
job I submitted a few minutes ago, using this new parameter, is "stuck" on
the exact same I/O numbers as yesterday. Weird.
- Dan
On Wed, Feb 14, 2018 at 11:50 AM, Rob Berendt <rob@xxxxxxxxx> wrote:
Is this applicable?
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/db2/rbafzskiplocked.htm
midrange.com
