Re: Another Question about variable length fields

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

Dave

Not really back but only in a virtual sense!

I'll check the data - I thought I had some that was longer than the 
allocation, but the fields were defined as only 10 bytes - maybe it 
keeps things that short in the main space - that'd be an interesting 
optimization.

Vern

Dave McKenzie wrote:
> 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
> > > > >   
> > > > >           
>
>
>
>
>
>