Re: VARLEN dds field in RPG-IV -- RPG400-L

G Armour wrote:

Have a *PF with the following:
    A            SSKEYFLDS  16000A         VARLEN(200)
Using v5r1 RPG-IV, a somewhat novice programmer attempted to MOVEL data to this field and write the record without explicitly manipulating, or making any reference to, the 2-byte field-length prefix. Well, she didn't know that it was VARLEN. Program compiles and program runs with no run-time errors reported. However, DSPPFM shows the field does not have the value MOVEL'd to it, and the field-length prefix value is binary zero. The RPG-IV reference does point out that the old-style MOVE, MOVEL, etc. will not set this field-length prefix, but that EVAL does.
One of my colleagues was surprised that the compiler didn't flag this at least 
as a
warning.  I offered that I wasn't sure how the compiler would have a good way of
knowing; although it apparently knows enough to handle the field-length prefix 
value
when EVAL is used to update the field.  Or how about an error at run-time?  I
speculated that there might be a backward-compatibility issue with RPG-III's
handling of it (for better or worse), but couldn't say for sure.
Is there a way for the compiler to issue at least a warning whenever MOVEx is 
used
to set a VARLEN field?

I think this is largely a case of "working as designed".

To summarise the rules: When using varying length variables within the traditional fixed-form calcs (not the expression calcs), a varying length variable works the same as a fixed length field defined with the current length. That is, if the current length of a char varying field is 10 (regardless of the declared maximum length), then the operation works the same as is the field were fixed length 10 chars.

Of course, if the current length is 0, then there's not really an analogue in the fixed length case. But we're not going to make any change to the compiler that might possibly regress users, and so that behavior ain't gonna change.

Why this way? The rules for char result on the old fixed-form calcs get in the way of meaningful rules for varying length variables. For example, for many fixed-form opcodes, char results are generally unpadded and right adjusted. Just how exactly do you right-adjust a value in a varying length result? We settled on the current rules for fixed-form calcs since you get the results you generally expect in the expression calcs anyways, and we wanted to keep the rules consistent for all fixed-form calcs.

Regarding a warning (sev 10) message, I can't think of any warning that would specifically warn about this situation. The compiler generally can't know that a varying length variable never gets its length set.

Cheers! Hans