RE: Use of VARYING fields

This has turned into a brilliant thread and I thank all the contributers.

I have been living in complete ignorance and did not know anything about how such data would be stored in a PF.

After having read up, I have a couple of questions. If you don't care about space saving, can't you just code the maximum and allocated length as the same?
How is space saved? I mean, if the allocated length is 0 and all the rows are in the overflow space, where is this space?

-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Vern Hamberg
Envoyé : jeudi 10 septembre 2009 15:34
À : RPG programming on the IBM i / System i
Objet : Re: Use of VARYING fields

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/rz
ajq/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

--
This is the RPG programming on the IBM i / System i
(RPG400-L) mailing list To post a message email:
RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.