On 17-Oct-2016 11:29 -0500, Ken Sims wrote:
On Mon, 17 Oct 2016 08:19:46 -0500, "Paul Nelson" wrote:
You'll expose yourself to level checks by deleting the LF's. Better
to remove the LF members first, then add them back after the reorg.
While the exposure is there, the circumstances that would result in
that condition [i.e. a LVLCHK issue] should be rare; the Remove Member
(RMVM) does eliminate the possible effect. The /normal/ effect of a
restore or create of the LF, over the unchanged PF(s), should be that
the Record Format (RCDFMT) Level Identifier (LvlId) remains the same as
when the file was created in the past; there are exceptions, though as I
recall, mostly due to past defects with the way that the level-hash had
been improperly generated in a prior request to create.
Perhaps even better is to just change the access path maintenance.
Note that I did *not* use this with RGZPFM, so I can't guarantee
that it will work as desired. Perhaps Chuck or someone can speak to
that.
The potential for benefit doing that for the Reorganize Physical File
Member (RGZPFM) request does exist, but for a different reason than for
a data-load scenario.
Notably, the first thing the RGZPFM ALWCANCEL(*NO) effects, is just
that, the invalidation of all access paths. That action is the origin
for the effects described by the help text for that parameter; that if
the job requesting the reorg is ended, then all access paths will be
rebuilt, despite the physical data having never changed during the request.
I used it when clearing and reloading files, and it decreased the
run time dramatically for files with a lot of records and a fair
number of logical files.
For the reorg, the benefit comes not from eliminating maintenance
during the writing of the records, but from taking what would be a
serial rebuild of access paths [in the reorg requester job], and instead
having made them run in parallel and/or just in a specific Work
Management (WM) setup other than the requesting job of the reorg; i.e.
run the work to rebuild the access paths *after* the reorg completes, in
an order that is chosen by the app and db owners, and with WM
appropriate to the task for whatever level of parallelism.
I retired back in July, so I no longer have access to my actual
code. A real retirement, not a move into consulting or contract work,
so I also don't have access to a system to try this.
FWiW: look into using pub400.com, even if just to /fiddle/ around
every once in awhile, or to confirm scripted actions when suggesting
something to perform.
Basically it involves the following steps:
1. Build a list of all of the associated logical files with their
access path maintenance information.
2. For any of those logical files whose access path maintenance is
not already *REBLD: CHGLF MAINT(*REBLD).
Noting of course, that Unique keyed Logical Files can not have their
Maintenance changed to be *REBLD by the reorg feature. They would need
to have their maintenance performed during the load, if either the
member or file was not removed.
3. Run the desired processing. In this case, RGZPFM.
In a data-load scenario, the PF should first be modified to the known
minimum size with the allocation activated, so as to additionally
prevent any requirement for growth/allocations during run-time; i.e. the
allocations are done up-front rather than periodically during, and as a
side-effect, of the data-load.
4. For any of those logical files whose access path maintenance was
changed, change it back to the original value: CHGLF MAINT(*IMMED)
or CHGLF MAINT(*DLY).
5. For any of those logical files whose access path maintenance is
now *IMMED, force the access path to be rebuilt with OPNDBF as
described by Chuck.
IIRC, there maybe something more to the final phase (steps 4&5
above); that perhaps Allocate Object (ALCOBJ) is required first, to
prevent the asynchronous QDBSRV## (runpty-52) jobs from starting the
rebuild.? Having prevented the system-job background rebuilds, then the
Open running in the desired WM effects the rebuild of the access path
for the Logical File Member (LFM) that it had allocated.?
midrange.com
