Justa note of thanks

["Jon Paris" <Jon.Paris@xxxxxxxxxxxxxx>]

 >> Do you think that is something we should do in RPG on all but the
smallest of fields (flags, indicators, or code fields) on a more routine
basis.  I think we have traditionally thought of using Varying only on big
text descriptions fields, and such.

OK - now I see what you are getting at.

No - I don't think that we should change everything - but we should consider
it as an option more often than we do.  I suspect the reason most PC
languages use Varying is that (like C) they rarely have a notion of a fixed
length character field.  The only time I can recall that notion in a PC
language (other than COBOL) was in some of the business basic dialects.

Would I change name and address to varying?  Probably not.  Why?  Because
most every time I use it I will be "printing" a multi-line block.  If on the
other hand I decided to change my addressing method to always concatenate
City, State/Province, Zip/Post Code into a single line, then I would give
serious thought to changing those.

It is the ultimate usage of the field that governs the choice for me.  If I
tend to use it in fixed output positions and rarely concatenate it with
anything else - I would keep it fixed.  If I frequently use it in
concatenation operations (web pages etc.) then varying is a good choice even
for relatively small fields.

As to DASD - yes you can save space but there is some overhead whenever the
actual content exceeds to "in record" size.  Don't forget as well that while
you save DASD there is some CPU cost (although most of us have plenty of
that to spare most times) since the database has to "stretch" the field out
to its full size before handing it over to the program.

Don't forget that it is not an absolute decision that has to be made.  You
can keep it as fixed on DASD and load it into a varying length field for
handling within the program if that is worthwhile.  If this becomes a
frequent happening, then change the DB at that time.

Jon Paris
Partner400