× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.