I am curious as to how one uses an A99V field in reports. From what I've seen, the first two characters of a variable length field contains the length of the data in the field, then the actual data value, so for example, an A10V field might have a value of "05ITALY". How would you display this in a report? Would you always have to edit out the first two characters? How is this practical? Why would the default behaviour of WebFOCUS 7.6 change from previous versions to generate metadata for VARCHAR fields as A99V, when it seems to me that most people would want to use most of those VARCHAR fields as normal, fixed length fields in reports.

This message has been edited. Last edited by: Kerry,

If it is defined as an A99V, when you print/sum the field it will display only the value of the field and not the length. However, if you are editing or substringing the field you have to allow for the extra characters and a SQL passthru may handle the field differently. I'm with you, I don't know why anyone would want it in WebFocus. ADD
ENGINE DB2 SET VARCHAR OFF to the server profile
and recreate your synonyms.

Francis,

It's the first 6 characters that show the length of the field. In the source master file the field is identified as A99V, in a holdfile it is also A99V for usage, but A99W for actual (don't know why the W). Tabling off a hold file will account for the length bytes, you won't see them in the report.

Variable length fields are the correct modern way of doing strings.

Unfortunately wf does not lend itself well to implementing this without a total rewrite of its tried and tested architecture. Hence we also stick with the ENGINE XXX SET VARCHAR OFF.

Dont completely write them off they have their uses such as returning variable length strings from user functions.

The FOCUS architectire requires that records (instances of a given segment) have uniform length. As a result, varchar (AnV) fields must be padded out to their maximal length, obviating the potential savings in storage. (Procrustes rules!)

OTOH, the internal architecture of XFOCUS does provide for storing variable-length records, which allows varchar fields potentially to be stored in truncated form. (But that potential savings ain't necessarily implemented)

Thanks everyone for your input.

I had an issue with -READ off a HOLD file containing A99V fields and dismissed them as a bad idea. I should have realized that a TABLE, DEFINE, COMPUTE would read/output the fields normally.