|
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:
pass that subfield to a stand-alone parameter with the same declaration.
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
The rest of the DS is then untouched.subfield - you can't change anything in the DS - there are probably ways,
If you use CONST on the parameter and pass the DS, you can't change the
see an article by Ted Holt that I will not cite, to see how to shoot
yourself in both feet!
this allows for future change.
You can also pass the DS and be sure nothing else in it is changed -
Everything else would remain unchanged.
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).
reference, meaning that a pointer is passed from the caller’s scope, so
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
that the called program can access the callers storage directly.
parties. Since no data is actually being moved, the size of the parameter
The size and format of the address space is agreed upon by both
data is irrelevant to the performance question.
also includes large “return values” which are also passed by value. IBM
Passing by value is the expensive option you should try to avoid. This
gave us RTNPARM option to resolve that issue, but it’s not the default
behavior, so just be aware.
with initialization of constant value storage in caller.
Passing with CONST option performs well despite some small overhead
rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:
-Eric DeLong
On Apr 12, 2019, at 9:18 AM, David Gibbs via RPG400-L <
as const, I'm pretty sure it will be passed by reference, so there will be
CAUTION: EXTERNAL EMAIL
********************************************************************
*
*
On 4/12/2019 9:11 AM, Greg Wilburn wrote:I'm pretty sure this is the best way to do it. If you define the parm
1. Just define the DS the same and pass it in (it could be
CONST)
no additional storage allocated.
already happening.
3. Define the PI as pointer and pass the addressNo need to do this, as mentioned above, that's essentially what's
business!
david
--
IBM i on Power Systems: For when you can't afford to be out of
Diabetes Association's Tour de Cure to raise money for diabetes research,
I'm riding 615 miles (Yes, you read that right) in the American
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=
.
donation map ...
You can see where my donations come from by visiting my interactive
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).
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=
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
.
questions.
Please contact support@xxxxxxxxxxxx for any subscription related
https://archive.midrange.com/rpg400-l.--
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
questions.
Please contact support@xxxxxxxxxxxx for any subscription related
https://archive.midrange.com/rpg400-l.
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
questions.
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
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 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.