×
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 10/14/10 8:48 AM, Mark S. Waterbury wrote:
CLRPFM deletes the data space for a physical file member and replaces
it with a new empty one, and invalidates/clears any access paths
(indexes) over this PF. <<SNIP>>
Running an SQL delete will actually delete each row, row by row
<<SNIP>> Also, if the file is defined with REUSEDLT(*NO), you will
have a bunch of deleted records taking up disk space, until you run
a RGZPFM.
<<SNIP>>
Just FWiW...
The member remains the same object, as does the dataspace. That can
be confirmed by DMPOBJ showing the same address of the *MEM and the
*QDDS objects both before and then after the CLRPFM request. The
dataspace object is truncated by a request to clear the PF member; the
individual data segments [those addresses not visible in the dump
object] returned to the system\ASP.
The member.data will have the deleted rows remaining [and thus taking
up disk space, until reorganize PFM] irrespective of the reuse-deleted
attribute setting; except of course, with the capability of the SQL
DELETE to implement using the "clear" feature [Fast Delete support]
which was already noted in a response by Eric DeLong.
Regards, Chuck
This mailing list archive is Copyright 1997-2025 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
