Varying length fields can save space in your tables. IBM's guideline is
to set the allocated length so that 90-95% of the rows have data within
the allocated length. Default on allocated length is 0, which puts all
the data into what is called an auxiliary space - this means that it
takes 2 read operations, most of the time, to get what takes 1 read
operation with fixed length. But if the allocated length is as above,
most of the time you'll have only 1 read operation. Search the following
PDF for "Tips for using VARCHAR and VARGRAPHIC data types in databases"
- this is the section heading in the "Performance and Query
Optimization" manual at InfoCenter -
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzajq/rzajq.pdf
Here is a quote from the "Database Programming" manual that speaks to this -
You can use the DDS VARLEN keyword to define a character field as
variable length. You can define this field as:
- Variable-length with no allocated length. This allows the field to be
stored using only the number of bytes equal to the data (plus two bytes
per field for the length value and a few overhead bytes per record).
However, performance might be affected because all data is stored in the
variable portion of the file, which requires two disk read operations to
retrieve.
- Variable-length with an allocated length equal to the most likely
size of the data. This allows most field data to be stored in the fixed
portion of the file and minimizes unused storage allocations common with
fixed-length field definitions. Only one read operation is required to
retrieve field data with a length less than the allocated field length.
Field data with a length greater than the allocated length is stored in
the variable portion of the file and requires two read operations to
retrieve the data.
I also do not recommend defining short fields as varying - don't
remember the length, but I'd not make anything 20 or less into a varying
length.
One advantage of varying length variables in RPGLE is that you don't
have to use the %trim built-in function. You do have to know that if you
set a varying length variable to the value of a fixed length variable,
without using the trim on the fixed length one, then the varying one is
set to the length of the fixed one. As an example, say you have a field
CHAR200V defined as 200 A varying - and a field CHAR50F defined as 50 A
fixed.
eval char50f = 'aaaaaaaaaabbbbbbbbbb'
That is 20 characters long, and there are 30 trailing blanks.
eval char200v = char50f
Then char200v will be assigned a length of 50 (first 2 bytes carry the
length). You probably don't want this.
eval char200v = %trim(char50f)
Now char200v has a length of 20. This is what you want. Probably.
This is an issue only when assigning the value of fixed-length to
varying-length - it's all in the ILE RPG Reference, by the way.
David FOXWELL wrote:
Hi,
I was asked why use this kind of variable. A part from tidying up the code when concatenating text fields, I wasn't sure. The problem is that our data dictionary is used in all our RPG sources and all zones are supposed to be declared like a field in the dictionary.
Are there other advantages?
Thanks
midrange.com
