Re: simple problem with string handling

I understand that the processing (stand-alone) varying fields is not a bug - my post probably didn't say that clearly enough, although I tried a little. At the same time, there's no reason not to report it as such in the context of a data structure subfield, in order to see if something can be done. Perhaps the treatment of varying could be adjusted when in a data structure, because of the side effect described. And maybe submit a request for enhancement, as well - the behavior ends up strange in this admittedly-limited context. But we might just do more of this in the future, as we adopt varying more.

JMHO
Vern

On 2/23/2013 9:11 AM, Ken Sims wrote:

On Sat, 23 Feb 2013 06:54:54 -0600, Vernon Hamberg
<vhamberg@xxxxxxxxxxxxxxx> wrote:

Oooh! This is choice.

I suggest either reporting it as a bug or submit an RFE at
http://www.ibm.com/developerworks/rfe

I understand that varying variables on their own do not change what we
see after the length contained in the first 2 or 4 bytes. This could
get messy, although I agree that it is no reason to avoid varying-length
variables.

It's not a bug. In RPG, since the beginning it's been part of the
specification for varying fields that everything beyond the defined
length is unknown. If a program is coded in such a way as to care
what's there, the bug is in the user's code, not in the compiler.

If it were an enhancement to force that undefined area to always be
blanks, it would need to be controllable via an H-spec or an EVAL
extender or something. I would definitely NOT want that to be the
default. If code were generated to force that to always be blanks, a
lot of the performance benefits of varying length fields would go
away.

Ken
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.