On Thu, Mar 10, 2016 at 8:49 AM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:
Personally, I wouldn't worry about rather or not the file ended up deleted
records or not.
I agree with you, in most cases. Basically, if a shop has IBM i
hardware with an appropriate level of storage for their business and
is using SQL, then most likely deleted records are not a big deal. And
the more they use SQL, the less arrival sequence is likely to matter,
and the more they can switch to reusing deleted records, if space is
an issue.
I'd also stick with the SQL delete vs. the CLRPFM. As mentioned in my
other post, the SQL delete will clear the file even with Pseudo-closed
cursors open to it. CLRPFM on the other hand won't.
Well, I'm at a shop that is still only dabbling in SQL. (And I still
don't know what "pseudo-closed" means.) We don't generally reuse
deleted records here, so a file that is very active, but which stays
below the clearing threshold, will grow uncontrollably if all we have
is SQL deletion.
Yes, it's possible to set up periodic deleted record clean-up as a
separate process. But I still think it's nice to be able to really
clear something immediately if that is indeed your intention.
If SQL isn't going to provide a truncate facility, then I feel there
ought to be more sophisticated determination of when to implicitly
clear a file. Like maybe if the total (active plus deleted) records is
over a certain threshold, then attempt to clear. (If this is already
the case and my testing just didn't hit it, then the threshold is too
high.)
John Y.
As an Amazon Associate we earn from qualifying purchases.