Re: Max length of a VARYING field

Joe Pluta wrote:

In these cases, mySmallVar would default to VARYING(2) and myBigVar would
default to VARYING(4) without any additional code required. For someone who
isn't interested in internals, the keyword would be consistent and nobody
would care. Those requiring compatibility with APIs and such could always
override the VARYING keyword as needed.

This seems to me to be the most flexible compromise: easiest for the new
programmer yet ultimately flexible for the experts.

Hi Joe, I understand your point, and as an RPG programmer, I sort of agree with it. But as an RPG language designer which is what matters here, I have to respectfully disagree with you (and with my programmer-self, and with Buck who made a similar point a couple of days ago). http://archive.midrange.com/rpg400-l/200705/msg00523.html

I still stand by the answer I gave to Buck http://archive.midrange.com/rpg400-l/200705/msg00587.html, which is that RPG is a compiled and strongly-typed language, and RPG programmers have to be specific about the types.

I don't think that having VARYING with no parameter mean something different depending on the length would make things easier for the new programmer in the long run. RPG has allowed this kind of flexibility/simplicity in the past, and it has caused grief for even expert programmers, often with parameter passing, and occasionally with subfield definition. For example, you can define a numeric variable with just the length and decimals; depending on where you code it, it means "P" or "S". Another example is date and time definitions; depending on what is in the H spec, the DATFMT has a different default.

One might argue that we shouldn't force all RPG programmers to enter P or S for numerics and we shouldn't force all RPG programmers to enter DATFMT for all their date fields just because some RPG programmers can't be bothered to learn how RPG works. I would argue that if RPG programmers always had to be specific about their data types, there would be far fewer questions about why PGM1 can't successfully call PGM2 when they both explicitly defined their variable as 5 with 2 decimals.

By requiring RPG programmers to be specific about the size of the varying prefix, we can forestall future problems with parameter passing and subfield definitions. Not requiring them to be specific about the prefix size actually forces them to know more about the details of the data type; they have to know that 65536 is the magic switchover point (not to mention 4294967296 at some possible far future time that would trigger an 8-byte prefix).

The parameter-passing problems are eased to some extent by prototyped parameters, but it is sometimes very confusing for programmers to understand what the compiler is complaining about.