On 27-Mar-2012 11:17 , Alan Shore wrote:
Adding 1 dummy record, RGZPFM the file, then CLRPFM has reduced the
size to 147,456 bytes

FWiW a more generic desirable means to enable RGZPFM ALWCANCEL(*NO) for a cleared dataspace [so as not to have to deal with triggers, constraints, et al], instead of adding an actual physical row of data which might be _seen_ by whatever else as a real row of data [thus could have negative consequences], is to first issue a request to add a deleted row which will be compressed\removed by the upcoming Reorganize Physical File Member request:

INZPFM RECORDS(*DLT) TOTRCDS(1) /* deleted row enables reorg */

FWiW a DSPFD OUTPUT(*PRINT) taken before various /change/ activity being performed as attempts to /recover/ from a suspect condition, may provide some information that could allow for either a better inference of or a better understanding of, what was the [specific size] issue; e.g. if access path vs dataspace. Also if a database *FILE is suspect for an issue with size, a request to MOVOBJ that *FILE and also its relations\dependents into another library enables restoring those files from backup [and applying journaled changes] or creating them anew from sources [then restoring or copying the data], into the original library. In so doing, the original object(s) remain for further review, which could be valuable to help determine origin(s) for the issue. Having not learned of the origin, recurrence is more likely, as well possibly rote reactionary change actions as /recovery/ becoming the norm; as in suggestions of "try this" and "try that", perhaps eventually "ah, I'll do this or that again; I recall it worked last time".

A dataspace effectively /cleared/ as part of /fast delete/ support _may_ be a side effect of a cleared dataspace which was not reset [rather, was created as empty], and for which similarly the physical-associated index was not reset as would normally be expected with a CLRPFM [instead of SQL DELETE].

Regards, Chuck

This thread ...


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

This mailing list archive is Copyright 1997-2020 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].