Re: Varying fields as parameters on procedure calls.

Don’t think so Charles.

Remember that when using CONST you are still passing by reference. So it is always a pointer that is passed (i.e. 16 bytes).

When passing a varying by value then no matter how the data originated (fixed field, literal, constant, varying field, etc. etc.) it will always be passed at the fixed length. It has to be since the called routine has no idea of the origin of the data (i.e. it has not way of knowing it was originally an n byte literal).

On reflection I have to assume that the reason the whole value has to be supplied is that unlike CONST parms a VALUE parm can be changed by the called routine. So if a (say) 10 char value was moved to the passed parm when the origin was a 4 char literal that could cause a really nasty mess!


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Apr 13, 2015, at 9:26 AM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

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.

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