Re: Max length of a VARYING field -- RPG400-L

Hi Scott,

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.

Or am I misunderstanding all of this?

*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /

Joe Pluta wrote:

IBM could just size the pointer based on the defined size of the
field, which would currently leave all code backwards compatible,
since by definition all fields must be less than 32K today, and so
use a two-byte pointer.

Scott Klement wrote:
The 2-byte integer that keeps track of the length can actually handle up to 64k, not 32k. We've had the ability to use 64k strings since V4R4 (8 years ago)

As I explained in a previous post, I want the ability to specify the size of the integer. That way I can have a subprocedure that accepts a 10000 byte VARYING CONST string today, and I can upgrade it to handle a 1mb string tomorrow without breaking compatibility.

Whereas, if I can't control the size of the integer, the 10000 byte VARYING would be a prefix of 2 bytes, and the 1mb would use a prefix of 4 bytes, thus breaking backward compatibility, requiring me to recompile everything.

To further clarify: I'm not referring to compatbility with programs written for V5R4 and earlier. I'm referring to the ability to make my V5R5 (or whenever we get the long string support) programs future-compatible. So I can make them 10000 bytes with a 4-byte integer in V5R5, then 6 months later when the business rules change, I can make them 1mb with a 4-byte prefix. I can't do that if IBM picks the prefix size for me.

Next, add a new BIF (%indexsize?) to determine the number of bytes in
the index portion of a varying field. Programmers like you need to
use this new BIF in all new code, and must remember to fix any
existing code when a varying field size is changed.

Yes, I like the idea of a BIF so I don't have to hard-code the size of the prefix. But, I still want the ability to specify the prefix size on the D-spec.

For maximum backwards compatibility, IBM could implement a
*ALLOWBIGVARYING compile flag. This would default to *NO and if you
unknowingly changed a field's buffer size to a value that required a
larger pointer (say through a LIKE define or a /COPY) without
actually changing the *ALLOWBIGVARYING flag on the program, then the
program wouldn't compile.

I don't see the value in this. Since you have to explicitly tell it to change to a different size length prefix, I don't see the point behind this keyword.