RE: Variable length fields

[Vern Hamberg <vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx>]

You would still need to get the data back to the original file, or delete 
the original and rename the new. But because it is writing the records 
anew, it would probably do the garbage collection.

There may be a threshold beyond which the cleanup will take place - I saw 
the non-clean-up behavior on a relatively small file.

My post mentioned RGZPFM vs CPYF, and that one of them did NOT perform 
garbage collection. The other one did - I forget which. I think RGZPFM did 
not clean up the auxiliary space. I was surprised, because RGZPFM has 
always been presented to me as, conceptually, a pair of CPYFs - the first 
to a temporary file, the second back to the original with MBROPT(*REPLACE) 
- or something like that.

Memory fails after even a week, so a test is in order.

Vern

At 11:11 AM 7/1/2004, you wrote:
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx / James H H Lampert
> >
> > Personally, though, I find it hard to believe that the VARLEN space in a
> > file NEVER gets garbage-collected or burped. After all, Java
> > garbage-collects its heap rather frequently, on much less efficient boxes,
> > and what is the VARLEN space but a heap that just happens to reside on a
> > disk, instead of in memory? Then, too, the hard drives of DOS boxes,
> > Win-Doze boxes, (presumably) Linux boxes, and Macintoshes get defragged
> > every day, and what is that, but a variation on garbage collection and
> > file-burping?
>
> I already deleted the message that mentioned that the allocation never goes
> down, regardless of reorg or not.  But I wonder, what if you did a CRTDUPOBJ
> on the file using DATA(*NO), then used CPYF to populate the new file from
> the original.  A test for another day.
>
> db