RE: Clear entire field vs substring

I don't know a lot about the details, but it seems to me the logic you need to implement to determine the length of the data in the variable and then clear just those bytes is more involved at the bits and bytes level then just letting the program clear the full variable.
... my 2 cents


Paul Therrien

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Albert York
Sent: Monday, May 21, 2012 4:29 PM
To: RPG programming on the IBM i / System i
Subject: Re: Clear entire field vs substring

Thanks Vern

Assuming there is a reason I have to clear the data before starting,

which is faster:

workfield = *blanks

or

%substr(workfield:1:len) = *blanks

I am not looking for an alternate solution, I am just curious which would be faster. I was hoping that someone would know enough about the code that gets generated to answer the question.

Thanks,

Albert.



On Mon, May 21, 2012 at 2:05 PM, Monnier, Gary <Gary.Monnier@xxxxxxxxx> wrote:

Hi Vern,

Glad to see you are noticing your literary side.  You're a poet and
didn't know it. :)

As far as I can tell Albert didn't say how he is using workfield.

I took it that Albert already understood that workfiled = %trimr(Newdata); essentially set and padded workfield.  He's a pretty smart guy.  He asked which one is better.  Better, I suspect, depends upon how workfield is being utilized.

I do know there is a philosophy of not clearing a work field but reusing what you need starting with position 1 and using the data length to substring the work field.  IBM does this sort of thing when it sends the length of data along with the data.  Look at the database server Exit point QIBM_QZDA_SQL2 format ZDAQ0200.  IBM passes in the SQL statement text length and SQL Statement.  If the statement is 100 long one time and 10 the next time positions 11 through 100 in the SQL statement passed in the second time are not necessarily blank or null filled.  The SQL statement text length + 1 is most likely a null and the remaining positions hold the contents of previous SQL statements.  At V5R4 an SQL statement can be 2,097,152 bytes long.  In this case, setting and padding 2MB gets costly.

I suppose setting and padding a variable with a length of 2000 could also get expensive in a program that processes a large amount of data.

Which is better?  I guess the situation dictates the answer.

Gary Monnier


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Monday, May 21, 2012 12:54 PM
To: RPG programming on the IBM i / System i
Subject: Re: Clear entire field vs substring

Man, this is a lot of work when the system will help you so much! As has been said in this thread - oooh! that rhymes! - an EVAL basically does a set and pad, probably - Chuck's reply suggests this. I mean, Albert is not extracting values from the middle of the workfield, is he?

An = is an implied EVAL - NOT a MOVE.

Hey, I love to get complicated, too - but I'm learning!!

Regards
Vern

If workfield is varying-length, the system knows

On 5/21/2012 2:33 PM, Monnier, Gary wrote:

Albert,

Can you use the length of Newdata to set the values you extract from workfield?  That way you don't have to clear it at all.

For example...

len = %len(%trimr(Newdata));

fullfield = %subst(workfield:1:len)

x = len - 3;
partialfld = %subst(workfield:4:x)



Gary Monnier


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Albert York
Sent: Monday, May 21, 2012 12:10 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Clear entire field vs substring

I have a work field that is 2000 bytes (to allow for the longest possible string value). The length of the data being moved to it varies and can be quite short. I have to clear the work field before I move the data.

  Which is better:

  workfield = *blanks


  len = %len(%trimr(Newdata));
  %substr(workfield:1:len) = *blanks;

  Thanks,

  Albert
--
This is the RPG programming on the IBM i / System i (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.