Re: Max length of a VARYING field

Scott Klement wrote:

Gosh, if IBM changes the prefix from a 2-byte field to a 4-byte field, I sure hope they provide a different data type, so that we have VARYING and BIGVARYING or VARYING4 or something like that.
...
If they say something like "fields less than 64k use 2 bytes, fields greater than 64k use 4 bytes" then I think we'll lose some advantages as well. It might be nice to have a subproecedure that today accepts a field that's 1k long as a parameter, but next year, it might need to be increased to 100k. I'd hate to have to recompile every single caller because the prefix size changed from 2 bytes to 4 bytes. I'd like to be able to force the prefix size to 4 bytes, even for small fields!

Scott, and everyone, don't worry. Compatibility would not be broken. We don't even break compatibility for things like CCSID(*CHAR:*JOBRUN) where the default behaviour is clearly wrong; we certainly wouldn't break compatibility for something like this.

Any definitions that simply have the VARYING keyword would continue to have a 2 byte prefix and get a compile-time diagnostic if the length is too long. And conversely, a varying definition of any size could be explicitly defined to have a 4 byte prefix.

It will probably be like this, allowing you to be explicit about the 2 byte prefix if you want.
VARYING(2)
VARYING(4)
VARYING (another way to specify "VARYING(2)")