RE: RGZPFM with ALWCANCEL(*YES)

And to be clear, the default is RBDACCPTH(*YES). The help text comes off rather murky to me. It says, "Access paths will be rebuilt synchronously at the end of the reorganize operation." To my brain, the end of the operation would be doing it asynchronously--the definition of synchronous is in part "occurring at the same time". But the *NO option is really what Dan wants. But I wouldn't end the reorganize only 1 minute ahead. I would give it five minutes or so. Even with the access paths being maintained during the reorganize, there still could be some clean up to the process.

Thanks,
Michael Quigley
Computer Services
www.TheWay.org



Thanks,
Michael Quigley
Computer Services
www.TheWay.org

-----Original Message-----
message: 2
date: Fri, 17 Oct 2025 22:54:02 +0000 (UTC)
from: Mark Waterbury via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx>
subject: Re: RGZPFM with ALWCANCEL(*YES)

Hi, Dan,
The answer appears to be in the help text for the command.? Prompt
RGZPFM, press F1, then F2 for Extended help.??
It appears to depend on what you specify for RBDACCPTH.
Hope that helps,
Mark S. Waterbury
On Friday, October 17, 2025 at 06:26:59 PM EDT, Dan Bale via MIDRANGE-L
<midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

If RGZPFM with ALWCANCEL(*YES) is used on a file for which there are a lot
of logical access paths/indexes, are the access paths/indexes updated on the
fly, or are they ignored until the physical file reorg is completed?? The reason
for asking is that if we need to cancel the reorg submitted with
ALWCANCEL(*YES), will the job still need to spend time updating the access
paths/indexes?? So, if we're given until 9:000am when the file must
absolutely be available, can we cancel the job at 8:59am with the expectation
that the file and its indexes will be ready and available to use?