Re: reorg not finishing

On 17-Oct-2016 07:34 -0500, Jim Oberholtzer wrote:

On 17-Oct-2016 07:31 -0500, Maassel, John R. wrote:

There is a reorg job on our dev box (i 7.2) that's been running
for 5 days. It's been on the IDX- stage on one index for almost 4
days. This is a rather large file, containing a billion records
and 11 access paths. It's stuck on #4.

[…] concerned about record locks with normal production starting.

FYI only; the Reorganize Physical File Member (RGZPFM) with ALWCANCEL(*NO) works with an exclusive access to all of the data without any need to reveal any access to records, thus the DB processing need not hold any record locks; either all the data is *unavailable*, or all of the data is *available*. Only the keyed access paths that have not yet rebuilt would be likely to impact normal ops; e.g. if an application opens (as keyed) one of the keyed LF not yet rebuilt, then that job will initiate the access path rebuild in the Work Management (WM) setup of that application-job, rather than within a job that specifically intends to effect that rebuild using appropriate WM setup that might better maximize access to both the CPU and memory to get the work done before the apps try to reference the data via that index. I do not recall the effect if the still-building access path can never complete (due to some problem), and the app might open that LF as keyed; i.e. if exhibited as a timeout, or instead an indefinite wait [giving the appearance of a hang]. But of course, if the AccPth rebuild issue is data-related, then anybody's guess as to how an application might perform, irrespective the access path situation, if perhaps encountering whatever navigational issue that the impaired-accpth-rebuild might have encountered -- again, if a data issue vs a WM-related issue.