Re: Max length of a VARYING field

You are right that it's a bit loony to say the field has a maximum length of 10, and that it also has a maximum length of *MAX4GB.

I find it easiest to think of this way: It's the difference between saying that the maximum size of 'A' data types is 65535 bytes and the size of field NAME (data type 'A') is 30 bytes.

This thread ought to be (mostly) captured for posterity in a Wiki, as an example of why abstraction is good (i.e. why do RPG programmers need to know the prefix length when we could have been restricted to using a BIF instead) and how future changes are affected by exposing the interior of a data structure to the outside.

This is no criticism of the Lab. I myself don't come remotely close to being able to roll out changes as impact-free as Toronto does. It's just such a potent learning possibility here before us. Listening to various ideas being bantered about in near real time is a treat, too.

My personal view is basically stylistic. I've been doing RPG since 1978 and my world view is coloured by that. I don't prefer to see a further exposure of the internal compiler storage regime with options(*varying:4) but that's just s style thing. I don't have the slightest rational reason for finding that unpleasant to look at and can't justify my position in the slightest.

I do prefer a different data type altogether ('V' perhaps?) and use a BIF to interrogate the maximum (restriction) length. Keep the current setting as-is. All existing code continues to compile and operate as-is. (My model here is the change-over from 'B' to 'I'.) New code needing the restriction lifted can use the new V data type and the new BIF to fiddle with it. Extend the BIF so that it works with data type 'A' as well and it seems... nicer to my eyes. And if we get to multi-terabyte sized VARCHARS in the future, none of the in-production code needs to change.

Again, strictly opinion, completely unjustifiable.
--buck