× 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.



Hi Albert

Jon Paris might know enough about the code to be able to say - I certainly don't.

My guess is that it is a wash - it's a memset operation at the end of things, and in either case there needs to be a way to know how many bytes at the memory address need to be changed - that's part of the substring operation or it's the length part of a varying, or it's the length of a fixed.

So I'm all for simpler code, cuz I think the underlying stuff is just not all that different.

Now a test might be, write 2 programs - each uses one of the techniques. Do a DMPOBJ on each and walk the bytes to see what's different - at least you'd have some sense of number of bytes. Of take it into SST, where you can see the low-level, almost assembly code - disassemble there.

Too much fun!!
Vern

On 5/21/2012 4:28 PM, Albert York wrote:
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.