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



 <snip>
> >>Lastly, it is obvious that no temporary variables are needed when
> Proc1a
> >>calls Proc2. 
> Why is it obvious?  The Proc2 doesn't know or care where the 
> data comes
> from, it will still act the same..

Since the parms match between Proc1a and Proc2, no manipulation would
occur.  Temp variables might be used for the call to Proc1a, but the
same address would be passed straight on into Proc2.

Make sense?
</snip>

Sounds logical enough...but somehow I doubt this is truly the case,
perhaps Barbara or another IBMer can tell us for sure...

It would seem that even though the parameters match. Proc2 can't assume
that the string size (or variable size) hasn't changed since Proc1a
received the value.  So unless the temp variable is always the max size
I don't see why it wouldn't function the same as if the call from Proc1a
were from the Main procedure (in which case the temp variable would HAVE
to be created...)???

<snip>
> 
> >>How about when Proc1b calls Proc2?  Am I going to get a
> >>32768 byte temporary for that call or not? 
> I believe you will get a temporary that is the size of the 
> varying field
> when the proc is called & the same gotchas mentioned above will still
> apply.(not 100% sure on this one though...)

The questions is which size? The size of the current length of the data
in the varying field, or the allocated (ie. max) size of the varying
field?
</snip>
Still just a guess...but I would (dangerous word...) assume the current
length of the varying field.


Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Wilt, Charles
Sent: Friday, May 05, 2006 3:35 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: CONST Parameter passing, varying and *varsize

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Holden Tommy
> Sent: Friday, May 05, 2006 3:39 PM
> To: RPG programming on the AS400 / iSeries
> Subject: RE: CONST Parameter passing, varying and *varsize
> 
> I learned this the hard way recently....
> 
> >>Now say you call:
> >>       Proc1a('This is a Test':14);
> >>       Proc1b('This is a Test');
> 
> >>I'm trying to understand the interactions between varying 
> and *varsize
> >>when the compiler builds the temporary variable due to the CONST.
> 
> >>Is the temporary for the call to Proc1a 32,768 bytes long 
> or only 14? 
> The "temporary" is 14 bytes long, however, since the procedure doesn't
> really know what to expect.  it can (& will even unintentionally LOL)
> access the full 32768a of memory!  Which of course means you can alter
> memory you shouldn't be....(which was HOW I learned the hard way...)

Yep.


> 
> >>How about Proc1b?
>  (not exactly sure on this one...) I would *assume* that since you are
> using a varying Const that the "temp" variable would be the 
> size of the
> string being passed.

It would seem the smart thing to do, but it would be different that how
CONST would work with any other parm without OPTIONS(*VARSIZE)

I could see CONST VARYING OPTIONS(*VARSIZE) working this way.  But does
CONST VARYING work this way by itself.


> 
> >>Any difference when dealing with a string expression using
> fixed-length
> >>or varying strings?
> >>       Proc1a('Fld1 is:' + fld1 : %len('Fld1 is:' + fld1));
> >>      Proc1b('Fld1 is:' + fld1);
> The biggest difference I think you'd see is in performance & really it
> would depend on the size of the variable & many other factors.
> 
> >>Lastly, it is obvious that no temporary variables are needed when
> Proc1a
> >>calls Proc2. 
> Why is it obvious?  The Proc2 doesn't know or care where the 
> data comes
> from, it will still act the same..

Since the parms match between Proc1a and Proc2, no manipulation would
occur.  Temp variables might be used for the call to Proc1a, but the
same address would be passed straight on into Proc2.

Make sense?

> 
> 
> >>How about when Proc1b calls Proc2?  Am I going to get a
> >>32768 byte temporary for that call or not? 
> I believe you will get a temporary that is the size of the 
> varying field
> when the proc is called & the same gotchas mentioned above will still
> apply.(not 100% sure on this one though...)

The questions is which size? The size of the current length of the data
in the varying field, or the allocated (ie. max) size of the varying
field?

Thanks,
Charles Wilt


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.