I never heard of it either, but it's sitting on our V5R1 system and trust me
we don't have any specialized utilities beyond those that I have written.
Jerry C. Adams
IBM i Programmer/Analyst
Anyone who sees and paints a sky green and pastures blue ought to be
sterilized. - Adolf Hitler
--
A&K Wholesale
Murfreesboro, TN
615-867-5070
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Therrien
Sent: Thursday, March 29, 2012 9:08 AM
To: Midrange Systems Technical Discussion
Subject: RE: How to re-org an empty file
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.)
Paul Therrien
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, March 29, 2012 3:12 AM
To: midrange-l@xxxxxxxxxxxx
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].
Regards, Chuck
--
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,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
--
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,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
