RE: Varying(4) bug ? -- RPG400-L

Paul, as for a guaranted of what the compiler will do for each type of format change, and what it considers a format change, I'll leave that to Barbara and others with internal knowledge. But my experience tells me that the compiler does not consider a change from VARYING(2) to VARYING(4) to be a format change. Indeed, my experience shows that it does not consider unvarying to varying as a format change! (Try it. But in test mode, please.)

I did not mean to suggest that VARYING VALUE OTIONS(*STRING) is more efficient than CONST. Let me explain.

As for efficiency, recall that I said "might want." Performance questions can always be answered by "it depends." But as you have demonstrated yourself, there is no reformatting done in your example case, so you gain some efficiency there. But if it turns out that you need VALUE as I suspect, then you may _consider_ OPTIONS(*STRING).

I believe I misspoke. I believe VALUE causes the data to be passed, rather than its address. And passing of large values is performance unfriendly.

"Paul Nicolay" <Paul.Nicolay@xxxxxxxxxx> wrote:

Dennis,

In the manual it says...

When the keyword CONST is specified, the compiler may copy the
parameter to a

temporary and pass the address of the temporary. Some conditions that
would

cause this are: the passed parameter is an expression or the passed
parameter has a

different format.

... so I expected that Varying and Varying(4) would be a "different
format" (just like for example a short int and int are both integers).

While the Value keyword solves my issue, it is not ideal for
performance and I don't see what difference or efficiency the
Options(*String) brings ?

Isn't it so that when I now pass a Varying(2) of 100 bytes to a
procedure accepting a Varying(2) of 64K with Const parameter that it
does NOT make a temporary copy of the 100 bytes... which is an
advantage I loose with the Value keyword.

Kind regards,

Paul

________________________________
From: rpg400-l-bounces@xxxxxxxxxxxx [rpg400-l-bounces@xxxxxxxxxxxx] on
behalf of Dennis Lovelady [iseries@xxxxxxxxxxxx]
Sent: Wednesday, April 13, 2011 12:36
To: 'RPG programming on the IBM i / System i'
Subject: RE: Varying(4) bug ?

No, but VALUE will. Remember, with CONST, you're just passing an
address.
With value, the variable will be converted if necessary, and the
address of
the converted data is passed.

For efficiency, you might want VALUE OPTIONS(*STRING).

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"I'd like to thank my parents and my mother and father."
-- golfer Greg Norman, accepting an award

I'm introducing Varying(4) into my programs as I need to handle more
data, but I'm experiencing something strange.

I have a procedure that accepts a Varying(4) which is defined with

the

Const keyword. If I now call this procedure, passing a normal
Varying... the first two bytes of the string itself are dumped in
position 3 and 4 of the Varying(4) field ? See dump data below, ie.
the "He" or x'C885' gets into byte 3 and 4 ?

Shouldn't "Const" not solve this issue ?

Example:

H DftActGrp(*No) ActGrp(*Caller)

DMyProc PR 100 Varying(4)
D Var4 100 Varying(4) Const

Ds S 100 Varying

/free
s = 'Hello world.';
s = MyProc(s);

*INLR = *On;
Return;
/end-free
**********************************
* MyProc *
**********************************
PMyProc B Export

DMyProc PI 100 Varying(4)

D Var4 100 Varying(4) Const
**********************************
* Main *
**********************************
/free

// Dump 000CC885 93939640 A6969993 844B0000 - ..Hello world...
Return Var4;
/end-free
P E

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

--
Sent from my Galaxy tablet phone with with K-9 Mail. Please excuse my brevity.