Re: QADBIFLD - Size?

On 11 Oct 2012 06:11, rob@xxxxxxxxx wrote:

<<SNIP>>
You will not be able to do a RGZPFM on this file itself due to
Allow write operation . . . . . . . . . . . : No

That is not a restriction for RGZPFM ALWCANCEL(*NO); i.e. the old-style reorganize does not use a 'write' method. Long ago [when the old-style reorganize was the only implementation] the RGZPFM was prevented only due to both the restrictive authority [i.e. only a user with *ALLOBJ authority would be able to perform the request on all but one of the *DBXREF PF] and that those files are effectively _always_ open by the QDBSRVXR and QDBSRVXR2 system jobs such that even in a restricted state no other job would be able to obtain the exclusive lock necessary to perform the reorganize request.

The OS database did [over my objections] change to enable the Reorganize Physical File Member request against the System Database Cross-Reference files. However that was to be used only in extreme emergencies when very few active rows\records exist; i.e. solely to reclaim an abnormally large number\percentage of deleted records.... and only in restricted state. I am unsure if initially the capability had at least been restricted to only restricted state, but surely made no attempt to prevent a request that could possibly take many hours more than a reclaim of the *DBXREF data. And at least in its original implementation, if the reorganize request was canceled, the likely effect was deletion of the file being reorganized and all of its dependent logical [VIEW; including system and library-specific SQL catalog] files for which the recovery might be a complete PITA depending on the individual customer requirements\desires. Had the implementation changed to effect the RGZPFM within the job which normally would maintain the open file [I know not, or perhaps just recall not], then probably the latter negative effects would no longer be a potential issue, but the former negative effect of an excessively long request would probably remain as a potential issue.

<<SNIP>>
The way to fix that is to bring your system down into a restricted
state and run:
RCLSTG SELECT(*DBXREF)

That is AFaIK still the recommended method to effect the reset and refresh of the data in all [except the RDB user-maintained] of the *DBXREF physical files. On most systems, that reclaim request would complete much quicker, even if possibly not more efficiently, than the _discouraged_ reorganize request of any of those files using RGZPFM ALWCANCEL(*NO). Limited-time repeated requests using ALWCANCEL(*YES) and ENDRQS [via SysRqs-2], if supported, likely would be best effected in periods when little non-QTEMP database file delete\create was active [in both the *SYSBAS and any particular independent ASP] where the action is deemed necessary\valuable.