Re: simple problem with string handling

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.

Vern

On 2/22/2013 6:37 PM, Troy Hyde wrote:

A coworker of mine recently ran into an issue with variable length strings
that is definitely not a big enough deal to convince me to go back to fixed
length strings. However, everyone might want to be aware.

It's also a situation that's pretty specific but I would think not uncommon.

In his program, he had a significant number of fields in a data structure.
This included some variable length strings. He would make a copy of the
data
structure and after some processing, to see if any fields changed, would
compare his data structure to the copy he made earlier.

The program would tell him the data structures were different even if the
individual fields in each of the data structures matched. That's because
when the program initializes the variable length field, it only changes the
data for the used length of the field.

Consider this code:
D originalDS ds qualified
D f1 10a
D f2 9s 0
D f3 256a varying
D copyDS ds likeds(originalDS)

/Free
*inlr = *on;
clear originalDS;
originalDS.f3 = 'Inz';
copyDS = originalDS;
originalDS.f3 = 'My String'; // line 1
originalDS.f3 = 'Inz'; // line 2
if copyDS <> originalDS;
// THIS CODE WILL BE EXECUTED EVEN THOUGH originalDS.f3 does equal
copyDS.f3
endif;
return;
/End-Free

Before line 1 is run, both data structures equal and the f3 portion of both
data structures contains x'0003' followed by 'Inz' and 253 blanks.
When line 1 is run, the binary portion of f3 is changed to x'0009' followed
by 'My String' and 247 blanks.
When line 2 is run, the binary portion of f3 is changed to x'0003' and the
next 3 positions are changed to 'Inz' but the following 6 positions stay
'String' so the f3 portion of the data structure contains x'0003' followed
by 'InzString' followed by 247 blanks.

Although originalDS.f3 DOES match copyDS.f3, originalDS DOES NOT match
copyDS.

Like I said, pretty specific situation and not a reason to stop using the
fields but a reason to change a technique and something to watch for.

The comparison will now need to say something like:
if originalDS.f1 <> copyDS.f1 or originalDS.f2 <> copyDS.f2 or
originalDS.f3 <> copyDS.f3;

Cheers
Troy

-----Original Message-----
From: Scott Klement ; Scott Klement
Sent: Friday, February 22, 2013 3:43 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: simple problem with string handling

IMHO, varying strings are much more elegant to work with. Even if it
doesn't save any CPU cycles, it just makes your code easier to write.

What's the advantage to sticking with fixed-length strings?


On 2/22/2013 1:39 PM, Vernon Hamberg wrote:

To say just a bit more, as I often do - I do recommend, if possible, to
change over to varying-length alpha variables. The benefit can be great.

There is YMMV going on here, of course. It probably doesn't matter much
for one-sies and two-sies. But for repeated concatenations, it can be
tremendous.

So it can be worth it to find places where using varying variables can
be done. One thing to do is use procedures, then add the OPTIONS(*TRIM)
on parameters, if they are CONST or VALUE. And make the parameter varying.

Again, where to do this depends on the situation. And be careful when
mixing fixed and varying, as already mentioned.

HTH
Vern

On 2/22/2013 1:28 PM, Vernon Hamberg wrote:

Agreed - the example was meant to give the basic idea. In the case where
it really mattered, I was building HTML strings - yeah, I know - use
CGIDEV2 with externalized HTML But that was later.

The other caveat that I presented was populating varying fields with
data from fixed fields - very quick gotchas can occur there.

Vern

On 2/22/2013 12:24 PM, DeLong, Eric wrote:

Hmm, just an observation...

I think the NORMAL pattern of use in the case where you're concatenating
a bunch of fields together is:

myString += %trim( theSalutation ) + ' ' +
%trim( theFirstName ) + ' ' +
%trim( theLastName );

Unless the shop standard is to use ONLY varying length values, using
%trim() to strip down your field data PRIOR to append and specifically
embedding blank characters where appropriate ensures that your formatted
string will literally look as you want.

Even this would have issues if theSalutation was blank... The
correction for that is another %trim, unfortunately...

myString += %trim( %trim( theSalutation ) + ' ' +
%trim( theFirstName ) + ' ' +
%trim( theLastName ) );

We NEVER want to ASSUME that blanks in data fields will be consistent...

-Eric DeLong

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Vernon Hamberg
Sent: Friday, February 22, 2013 12:10 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: simple problem with string handling

Hi Booth

I think you'd want that - except for only one blank in 'Mr ' - trailing
blanks in a literal are part of the string, even though it is processed
as a varying length, basically.

Vern

On 2/22/2013 11:37 AM, Booth Martin wrote:

If one wanted "Mr Vernon Hamberg" instead of "MrVernon Hamberg", would
one want:

webDta += "Mr " + varyingLengthVar;

?


On 2/22/2013 10:07 AM, Vernon Hamberg wrote:

Dale

Very cool.

Just as a reminder, when you concatenate varying length values, you
don't need the %trim at all. So you have this -

webDta += varyingLengthVar;

instead of -

webDta += %trim(varyingLengthVar);

It's a wonderful new world of RPG, eh?

Vern

On 2/22/2013 9:09 AM, dale janus wrote:

Varying-length variables will perform better than fixed-length ones,

Vern,

Thanks for the info on varying length being easier than it seems.


I can see future use of varying for creating HTML strings as you
indicated. Right now the few times we need to do it are in CL (which
can
get ugly)


But I will keep your ideas in mind when we get to the rpg stage.

---Dale