RE: Max length of a VARYING field

From: Barbara Morris

If the prefix size changed from one release to the next, there would be
chaos even if all RPG programs were recompiled.

That's why I think basing the index size on the maximum field size makes so
much sense. Right now, the maximum field size is 64KB, so the index only
needs to be two bytes long. Even if you were to change the maximum size and
allow someone to define a longer field, then all fields defined up until now
would STILL only require two bytes, because they by definition couldn't be
greater than 64KB. Only NEW fields longer than 64KB would require the
longer prefix! Thus, inherent backward compatibility AND an extendable
architecture.

There's no way IBM would make a
change that would cause programmers to have locate and recode all the
places that were interfacing with varying fields.

Right, which is why you can't just make the prefix magically be some larger
size. But as I pointed out, all existing definitions wouldn't change,
because all old fields would still have the 2-byte prefix.

(Aside: where did the 48-bit prefix come from? That's 6 bytes; did I
miss something?)

Well, originally Bob Cozzi had suggested 2, 4 and 8 byte prefixes. When I
originally was toying with the *MAXnnxB notation I decided to stop at six
bytes rather than eight because I just can't conceive of a use for fields
greater than a hundred terabytes.

I was chastised for that, but I stick by it <grin>.

Personally, I have a hard time with fields greater than a gigabyte, so 32
bits is fine for me, but I included the concept for argument's sake.
Obviously, this would require changing RPG to support fields of that size
and I really don't see that coming anytime soon, but I just wanted to make
sure that any discussion wasn't self-limiting.

Joe