RE: Max length of a VARYING field

From: Peter Dow (ML)

If IBM automatically determines the size of the prefix, and provides a
BIF to give us the size of the prefix, you should be able to code your
programs so they are future compatible. And it wouldn't break backwards
compatiblity because none of your older programs would be able to
specify a VARYING field with a size that causes the compiler to choose a
4-byte prefix.

Unless the change was to a database field and you're just recompiling an
older program that uses that database. Then Joe's compiler option
ALLOWBIGVARYING(*NO) would kick in, the compile would fail and you'd
know there was a problem.

Yeah, this is the basic idea for the ALLOWBIGVARYING keyword. Scott wants
to be able to pass a large VARYING and a small VARYING to the same procedure
and not have to worry about it. In essence, he wants to treat all VARYING
fields as large, even if they aren't (that's what he would have to do in
order to make his procedure work -- all VARYING fields would have to have
the same prefix size, and thus all would have to be large).

Me, I think I'd rather have the compiler tell me I have a prototype mismatch
if I try to pass a small VARYING to a procedure that wants a large VARYING,
and maybe allow the STATIC keyword to auto-copy between them. I certainly
wouldn't want to pass different sized VARYING fields (even with the same
prefix size!) to a procedure if they were updateable -- without a length
parameter, you're just begging for trouble there, since the VARYING field
doesn't actually carry a maximum length, it's just a compiler artifact.

So I think having different VARYING types just like different Integer types
and requiring parameter matches on the prototype is just fine, using STATIC
to auto-copy when necessary. That doesn't exactly match Scott's requirement
of being able to specify his width, but I just have a hard time justifying a
48-bit pointer for a 2KB field.

Joe