×
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 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
midrange.com
