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



Perhaps Bob was talking about how it works when you pass in a literal..

myproc('Hello');

If the parm is defined as CONST VARYING, I know the above generally creates
a temporary variable of size 5 + 2 = 7 and passes that into the parm.

It wouldn't surprise me that VALUE worked the same way.

Note I say generally. Per Barbara's point in this thread
http://archive.midrange.com/rpg400-l/200605/msg00162.html

The compiler will try to reuse temporary variable, so if there's an
existing one bigger, it might reuse that instead of creating a new one.

Charles





On Sun, Apr 12, 2015 at 1:31 AM, Alan Campin <alan0307d@xxxxxxxxx> wrote:

Old article by Bob Cozzi and now I can't find it again. Maybe somebody else
can find it.

I wrote a test program and proved that it sending the whole thing. I passed
a 64K varying string by value a million times and then ran the same thing
passing the string by using *STRING and *TRIM and basically it was 38 times
faster. The *STRING was passing the actual 17 bytes and the by Value was
sending the whole 64K each time so basically I answered my own question. I
know it always passed the whole thing but Cozzi was saying that it only
passed the actual length which made no sense to me.

On Sat, Apr 11, 2015 at 9:47 PM, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
wrote:

Alan,

Can you point to this article you're referring to? I'd like to
understand
what you're referring to.

There's nothing magic about VARYING data types -- they work the same as
any other data type. When you pass by VALUE the variable is copied --
the
whole thing is copied, so if you had 1000A VARYING, it'd copy 1002 bytes
from the caller to the procedure. When passed by reference (i.e. no
VALUE
keyword) than a pointer (16 bytes) is passed instead, and it shares the
same memory as the caller.

Personally, because I often interface with other languages like C, C++,
SQL, etc I would never pass a character string by value. Many languages
don't allow it (or allow it, but make it difficult, for instance in C you
have to use a data structure to pass a a character string by value.) So
I
would avoid passing a string by value... (I only use value for numerics)

The article you're referring to may be referring to something like return
values, maybe? I would like to see it to understand it...

-SK



On 4/10/2015 6:13 PM, Alan Campin wrote:

Just a quick question. I was reading on article on the web and it stated
that if I had a varying fields that what would get passed by VALUE would
be
just the first two digits for the length and the actual length of the
data.

It has always been my understanding if I had field that was 64K varying
and
I passed it as a parameter that the 64K plus two (or four) bytes for the
length is what would be passed even I only had say 10 bytes of data.

Since a statement like InParm = *ALL'*'; is valid even though it would
never be seen by the caller, I don't see any other way it could work
except
to the pass the entire length.

I can pass as *VARSIZE but only if a CONST or by reference or I can pass
as
*STRING with an optional *TRIM which is what I have been doing lately.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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 (AS/400 and iSeries) (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 ...

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.