Re: Another Question about variable length fields

Vern (for when you get back -- hope you had a good one!)

After some testing, it seems that the system creates the AUX SID
"lazily"; that is, it doesn't create it until you put data that's longer
than the allocated length in some variable-length field.

So, I'm guessing your file doesn't have any fields containing data
longer than the allocated length.

--Dave

Vern Hamberg wrote:

Dave

Tried that - but the text AUX SID was not present. This is a table with
variable length fields.

Oh well, another day - after vacation!!

Happy Thanksgiving!
Vern

Dave McKenzie wrote:

You can use SST to dump the auxiliary area as follows:

1. Use DMPOBJ to dump the physical file.
2. Find the DATA SPACE (*QDDS) in the listing and get its address
3. Use SST to dump the Data space (MI object, type 0B), using the
address from DMPOBJ
4. Scan the SST dump for 'AUX SID' (at the end of the listing)

--Dave

Vern Hamberg wrote:

Hi James

I seem to remember that the auxiliary space for variable-length data
that exceeds the allocation is not reused. So even if you update a VL
field with a shorter value but still greater than allocation, it uses
more of the auxiliary area. If you reduce it to less than allocation,
then it returns to the main area, yet the auxiliary area is not cleared
of the old data. Now this was in 2001 or so, and I don't remember
anymore how to walk through SST to see the auxiliary area. Anyone have
the magic locations?

CPYF did not seem to clear it, either - only RGZPFM.

Vern

James H. H. Lampert wrote:

John Allen wrote:

I then updated the file so that the new file with the new variable length
field has data truncated to minimum length (stripped off trailing blanks)

Just for grins, try a RGZPFM on it. The space you squeezed out of the
records may still be inflating the heap size.

--
JHHL