• Subject: RE: VARLEN field... what good are they?
  • From: "Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Mon, 17 May 1999 08:15:50 -0500

Simon,

Could you give me an example of how I am supposed to code this in the DDS?
I used the following:

A character field with a max length of 31000 bytes.  Minimum length of 256
bytes.

Everything I tried either truncated the data or made a fixed length of
31000.  

>From what I understood is that the max length goes in the field length
paramenter.  Then, you specify on the VARLEN keyword what the minimum length
is.  This didn't work for me and my file grew in size.

Bradley V. Stone
Taylor Corporation - OASIS Programmer/Analyst   
bvstone@taylorcorp.com


> -----Original Message-----
> From: Simon Coulter [SMTP:shc@flybynight.com.au]
> Sent: Saturday, May 15, 1999 2:27 AM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: VARLEN field... what good are they?
> 
> OE
> Hello Brad,
> 
> Exactly how did you specify the VARLEN keyword?  You should specify an
> allocated length for the 
> normally expected amount of data and let the unusual excess spill over
> into the overflow area.  
> It is usually bad practice to let VARLEN default to zero.
> 
> VARLEN fields on the AS/400 are implemented as a fixed length in the
> record (which may be zero) 
> and an overflow area to contain the excess.  The advantage is reduced
> total size of the file at 
> the expense of some performance.  I am surprised that your file actually
> grew although the 
> recompile of the PF may have caused different disk allocations to occur.
> 
> There is a certain amount of overhead involved with VARLEN fields:
> 
> 1/ The 2-byte binary length of data.  This is part of the record format
> and exists for each 
> VARLEN field.
> 
> 2/ The information linking the field to the data in the shadow area.  This
> takes 25 bytes of 
> data in the overflow area and exists for each overflowed field.
> 
> 3/ The overflow area is managed sequentially and if an update to the
> VARLEN field increases its 
> current overflow allocation an additional allocation is made with
> additional linkage 
> information.
> 
> It is really good practice to reorganise VARLEN files because the overflow
> area is rearranged 
> to minimize the number of linkage sections.
> 
> I would suggest that you have a lot of data in the overflow area probably
> due to a poorly 
> chosen allocation value thus may records now have at least 27 bytes more
> data than they did 
> previously.
> 
> Regards,
> Simon Coulter.
> 
> «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
> «» FlyByNight Software         AS/400 Technical Specialists       «»
> «» Eclipse the competition - run your business on an IBM AS/400.  «»
> «»                                                                «»
> «» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
> «» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
> «»                                                                «»
> «» Windoze should not be open at Warp speed.                      «»
> «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
> //--- forwarded letter
> -------------------------------------------------------
> > X-Mailer: Internet Mail Service (5.5.2448.0)
> > Date: Fri, 14 May 99 12:59:13 -0500
> > From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com>
> > To: "'MIDRANGE-L@midrange.com'" <MIDRANGE-L@midrange.com>
> > Reply-To: MIDRANGE-L@midrange.com
> > Subject: VARLEN field... what good are they?
> 
> > 
> > I was playing around with the VARLEN keyfield today.  I have a field in
> a
> > file that can be a max of 31000 bytes.  I thought "hey, the VARLEN field
> > will save some space."
> > 
> > This field contains text, and the length is varying.  No telling what
> will
> > go in there.
> > 
> > Anyhow, I changed the DDS.  The file size actually grew about 3k after
> the
> > change.  
> > 
> > So, my question is, what good does the VARLEN keyword do in a case where
> I
> > have a field that could be anywhere from 1byte to 31k?  Is this just not
> the
> > best place for it?
> > 
> > Bradley V. Stone
> > Taylor Corporation - OASIS Programmer/Analyst       
> > bvstone@taylorcorp.com
> > 
> > 
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> david@midrange.com
> > +---
> > 
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.