INZPFM is an interesting command. I didn't know it existed. And the idea that one could initialize with deleted records seems odd.
It almost seems to be too specialized of a command to be part of the operating system. (This is just me musing.)
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, March 29, 2012 3:12 AM
Subject: Re: How to re-org an empty file
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].
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l