On 08-Jan-2016 12:45 -0700, Richard Reeve wrote:
I am still confused as to why a reorg (after all indexes were
rebuilt) would cause the backup time to be extended.
One possibility is per an improper inference of the effect\condition
that "all indexes were rebuilt"; between the reorg activity and the
backup, were both Edit Rebuild Access Paths (EDTRBDAP) verified empty
and WRKACTJOB JOB(*SYS) [JOB(*ALL) if non-restricted] reviewed for any
jobs showing status of IDX? Was the history log reviewed for any
"access path built" condition logged, perhaps even up to day(s) later
[there is no rebuild-started condition logged]?
If the maintenance program was overly aggressive and reorganized the
DBXREF files rather than ensuring to omit the files maintained by that
feature from RGZPFM processing, then there could be very perverse
effects; to include a negative perfm impact on the saves.
I expected to see the backup time reduced. What am I missing?
Did the member sizes grow? Did access paths that were previously
invalid become valid? Either causes more storage to be taken [the
latter more objects to be included] and thus more to be dumped [aka
saved] to the media; with compaction or compression, the growth in size
[but not growth in number] can be ameliorated.
Should I delete the journal receivers (or omit them from the
backup)?
For the couple entries added per RGZPFM request per member, probably
there would be no benefit from omitting the receivers. Besides, if the
receivers were not changed, I am unsure if the data from partial
receivers are even saved; i.e. while the *JRNRCV object is saved and
thus appears on the list of objects saved, I expect they are saved
without data so any extra entries in the existing receiver would be
immaterial.
Would an IPL help.
Probably no better than praying would.
What about a RCLSTG?
Nothing good would come from doing that unless there was something
specific with regard to the sub-features performed by RCLSTG [authority
recovery, damage notification, context recovery\assignment, etc.] were
effected and had value. If the save is not failing with damage being
detected and the objects being saved have an owner and public authority,
or users own objects outside of a library, then probably best *not*
perform that request; nothing the RGZPFM would be ameliorated by RCLSTG
*ALL unless there is a functional conundrum with the *DBXREF, and a
condition that was resolved-by vs compounded-by the RCLSTG request.
And if the maintenance program failed to omit the QADB* files in
QSYS, performing that request afterward could compound an even more dire
negative effect than just having reorganized those files.
If I do a RCLSTG, does the system need to be restricted? <<SNIP>>
Yes.
midrange.com
