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



There seems to some confusion about parameter passing. There are three ways
to pass a value to a procedure.

Blank - By Reference
CONST - Constant
VALUE - By Value

By reference means the operating system pass a pointer to the procedure.
Everything in that field or structure can be changed.

By CONST means that the operating system passes the value exactly the way
that by reference works(A pointer to value) but the compiler try's to make
sure that you do not change the value. Unfortunately, it is pretty easy to
do that.

By VALUE means that the run time makes a copy of the value and then either
pushes the value of the copy onto the stack or passes a pointer to the
value. You can change the value but it means nothing because you are
changing the copy which is discarded.

Generally as a rule you always want to pass by VALUE except when the value
is large and then you are going to drop back to CONST. As Mark said, you
could simply pass the fields you need by VALUE or the whole structure by
CONST.

I would say I would lean toward passing only what is needed.

On Fri, Apr 12, 2019 at 9:28 AM Mark Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Greg,

If your routine only needs to use perhaps a half-dozen or so fields in the
data structure, it might be better to just define that procedure with those
parameters and just pass only those needed.

This makes it more apparent what the purpose of that routine is, and in
the future, if you need to access another value from that data structure,
you just add another parameter. Those parameters can each be defined as
"value" for "read-only" or normal, meaning the procedure can change any of
those values. This also serves to document which values might be changed
by that procedure.


HTH,
Mark S. Waterbury



On Friday, April 12, 2019, 12:07:19 PM EDT, Greg Wilburn <
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

Jon,
Thanks! Got it. This is my option #2 (in the post I was typing as you
sent this). I agree 100% about the readability.

Vern,
The PLIST1 is already defined in all programs that would call this new
procedure. I also have it defined in my new procedure.

In this case, I do not see ever changing any other subfield in the
original DS.

The DS contains all the necessary information for shipping a package
(defined by our 3rd Party software), including a "Shipping Method" field
The new procedure is using that same information to determine (using the
same 3rd Party software application) whether the "Shipping Method" should
be changed based on the "Least Cost Carrier".
(there are predefined parameters in their software)

So the "Shipping Method" will either be changed, or left alone based on
the cost to ship that specific package to a specific location.

Thanks to all! What a great help! Take the next two days off (lol)

Greg


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of
Jon Paris
Sent: Friday, April 12, 2019 12:04 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: [EXT] Re: Advice passing a large parameter

Solution 2 makes it obvious which field changed and prevents accidental
changes.

Solution 1 tells you nothing about whether values changed or not. In other
words in tracing a bug unrelated to the value you _intend_ to change you'd
still have to study the code in the procedure to see if it changed anything.

Now ask yourself which one is the best choice from a maintenance and
readability perspective?

I know which I would choose. Even if there was more than value involved.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Apr 12, 2019, at 11:32 AM, Greg Wilburn <
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

So my understanding is this...

Option 1:
dcl-pi *n;
inPlist1 likeds(plist1);
end-pi;

VERSUS

Option 2:
dcl-pi *n char(20);
inPlist1 likeds(plist1) CONST;
end-pi;

In #1 I can simply change ANY of the fields In #2 I simply have to
return the value (changed or not in the logic of my program)

Which is "best"?
Greg


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf
Of Vernon Hamberg
Sent: Friday, April 12, 2019 11:47 AM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: [EXT] Re: Advice passing a large parameter

Greg

If you want to change only one element of the DS, it might be better to
pass that subfield to a stand-alone parameter with the same declaration.
The rest of the DS is then untouched.

If you use CONST on the parameter and pass the DS, you can't change the
subfield - you can't change anything in the DS - there are probably ways,
see an article by Ted Holt that I will not cite, to see how to shoot
yourself in both feet!

You can also pass the DS and be sure nothing else in it is changed -
this allows for future change.

Hope that makes sense - quick response a snowy (i.e., flaky!) morning.

Vern

On 4/12/2019 10:13 AM, Greg Wilburn wrote:
So I'm confused...
The value that may or may not change (or return) is CHAR(20).
Everything else would remain unchanged.

Should I use CONST or not?
Do I need to define the DS as TEMPLATE?

dcl-pi *n;
inPlist1 likeds(plist1);
end-pi;

dcl-ds plist1 extname('PLIST1DS') template;
end-ds;


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf
Of DeLong, Eric
Sent: Friday, April 12, 2019 11:02 AM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: [EXT] Re: Advice passing a large parameter

I agree with David’s assessment. By default, RPG passes parameters by
reference, meaning that a pointer is passed from the caller’s scope, so
that the called program can access the callers storage directly.

The size and format of the address space is agreed upon by both
parties. Since no data is actually being moved, the size of the parameter
data is irrelevant to the performance question.

Passing by value is the expensive option you should try to avoid. This
also includes large “return values” which are also passed by value. IBM
gave us RTNPARM option to resolve that issue, but it’s not the default
behavior, so just be aware.

Passing with CONST option performs well despite some small overhead
with initialization of constant value storage in caller.

-Eric DeLong

On Apr 12, 2019, at 9:18 AM, David Gibbs via RPG400-L <
rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:

CAUTION: EXTERNAL EMAIL

********************************************************************
*
*
On 4/12/2019 9:11 AM, Greg Wilburn wrote:
1. Just define the DS the same and pass it in (it could be
CONST)
I'm pretty sure this is the best way to do it. If you define the parm
as const, I'm pretty sure it will be passed by reference, so there will be
no additional storage allocated.

3. Define the PI as pointer and pass the address
No need to do this, as mentioned above, that's essentially what's
already happening.

david



--
IBM i on Power Systems: For when you can't afford to be out of
business!

I'm riding 615 miles (Yes, you read that right) in the American
Diabetes Association's Tour de Cure to raise money for diabetes research,
education, advocacy, and awareness. You can make a tax-deductible donation
to my ride by visiting
https://urldefense.proofpoint.com/v2/url?u=https-3A__mideml.diabetessucks.net&d=DwICAg&c=kUT9u1ftLjMzSSPm_-knDdNvxOshAnRL8kekFKxW3Wg&r=9Ntyfp-OuZH8yZaiXsb9HlYdW65WTi1eFGJS7ZM5Mok&m=qdWt_AwJqKEXpF4tkqKNpvVqMO67NeiQIF-PRnfw3W4&s=PtvmWvRmSkKH7OarkWfUjwuxfsYtFQC-TuK8DCrd8mo&e=
.

You can see where my donations come from by visiting my interactive
donation map ...
https://urldefense.proofpoint.com/v2/url?u=https-3A__mideml.diabetessucks.net_map&d=DwICAg&c=kUT9u1ftLjMzSSPm_-knDdNvxOshAnRL8kekFKxW3Wg&r=9Ntyfp-OuZH8yZaiXsb9HlYdW65WTi1eFGJS7ZM5Mok&m=qdWt_AwJqKEXpF4tkqKNpvVqMO67NeiQIF-PRnfw3W4&s=vxe2O14Mytl8MzURE3Px_G_JrPY7KDABI2UaQksT_Js&e=
(it's a geeky thing).

I may have diabetes, but diabetes doesn't have me!
--
This is the RPG programming on IBM i (RPG400-L) mailing list To post
a message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.midrange.
c
o
m_mailman_listinfo_rpg400-2Dl&d=DwICAg&c=kUT9u1ftLjMzSSPm_-knDdNvxOs
h
A
nRL8kekFKxW3Wg&r=9Ntyfp-OuZH8yZaiXsb9HlYdW65WTi1eFGJS7ZM5Mok&m=qdWt_
A
w
JqKEXpF4tkqKNpvVqMO67NeiQIF-PRnfw3W4&s=OEYx8_Zrit5YsQO4808wAYmIlTaf4
C _ dtwkWZ_Rk26M&e= or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at

https://urldefense.proofpoint.com/v2/url?u=https-3A__archive.midrange.com_rpg400-2Dl&d=DwICAg&c=kUT9u1ftLjMzSSPm_-knDdNvxOshAnRL8kekFKxW3Wg&r=9Ntyfp-OuZH8yZaiXsb9HlYdW65WTi1eFGJS7ZM5Mok&m=qdWt_AwJqKEXpF4tkqKNpvVqMO67NeiQIF-PRnfw3W4&s=uL7_DXV22_KMdPRw7QEmXXhgyEc5C33CWeQr450yU0w&e=
.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link:
https://urldefense.proofpoint.com/v2/url?u=https-3A__amazon.midrange.
c
om&d=DwICAg&c=kUT9u1ftLjMzSSPm_-knDdNvxOshAnRL8kekFKxW3Wg&r=9Ntyfp-O
u
Z
H8yZaiXsb9HlYdW65WTi1eFGJS7ZM5Mok&m=qdWt_AwJqKEXpF4tkqKNpvVqMO67NeiQ
I F -PRnfw3W4&s=AFxaH8apUaQvKybYCRgRXX4nPnjWMb5MKqMjlJt55Vs&e=
--
This is the RPG programming on IBM i (RPG400-L) mailing list To post
a message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


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.