× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.