Re: Overloading RPG Subprocedures

Yeah, I had thought about passing a pointer to some big variable and then,
based on the return code, you could move that to the appropriate DS. Or,
just overlap the DS's onto the big variable.

That, I thought, was more flexible but might be considered kludgy.

I did, however, setup something like that when processing data returned
from some vendor where it was header/detail/summary record types all in one
transaction. A 2048 char variable with multiple DS's overlaid on it. Byte
1 told you which record type it was.

Kind of an RPG-II flashback, huh? Sometimes, the old techniques come in
handy though.

Roger Harman
COMMON Certified Application Developer - ILE RPG on IBM i on Power



-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Brad
Stone
Sent: Monday, January 15, 2024 2:55 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Overloading RPG Subprocedures

Nah, that would just make it more clunky. In the future there will be more
DS's that can be returned (like refunds, credits, etc.)

I thought about passing a pointer..and since on the returning end I'll know
which DS to point to but that may get messy too.
something like this:

rc = getData('10' : dataDS@ : 'PO'); <--- or the last parm could be
INVOCE,
REFUND, etc.

Thanks for the suggestions!

On Mon, Jan 15, 2024 at 4:29 PM Roger Harman <roger.harman@xxxxxxxxxxx>
wrote:

Brad,

What about passing both DS's to the procedure. The return code can tell
you which was populated.

rc = getData('10' : thisInvoiceDS : thisPurchaseOrderDS);
rc = -1 - fail
rc = 1 - Invoice
rc = 2 - PO

Roger Harman
COMMON Certified Application Developer - ILE RPG on IBM i on Power




-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Brad
Stone
Sent: Monday, January 15, 2024 5:02 AM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Overloading RPG Subprocedures

That's what I was thinking too, Scott (as mentioned in my last email).

I just have a couple very similar subprocedures where the only real
difference is the path of the call to a web API and one output

parameter...

What I really would like in actuality is the ability to return a

different

DS depending on what is passed in.

Just playing around during these cold slow days. :)

On Sun, Jan 14, 2024 at 10:56 PM Scott Klement <

rpg400-l@xxxxxxxxxxxxxxxx>

wrote:

Brad,

This seems like an unusual use case, why would you want a routine where
the caller doesn't need to distinguish between a PO and an invoice?

That said, the code you provided should work. Are you having problems?

-SK

On 1/14/2024 4:11 PM, Brad Stone wrote:

So, I decided to start digging into this. It looks pretty cool.

Thanks

for

the examples online (Scott!)

I have yet to find any examples with more than one parameter, so here

is

my

question....

Can you overload with multiple parameters where one or two are

different?

Like this to retrieve an invoice or PO:

dcl-pr getInvoice int(10);
In_ID char(128) const;
Out_Invoice likeds(invoiceDS) options(*exact);
end-pr;

dcl-pr getPO int(10);
In_ID char(128) const;
Out_PO likeds(poDS) options(*exact);
end-pr;

dcl-pr getData int(10) Overload(getInvoice:getPO);

So you could do something like:

dcl-ds thisInvoiceDS like(invoiceDS) end-ds;
dcl-ds thisPODS like(poDS) end-ds;
dcl-s rc int(10);

rc = getData('10':thisInvoiceDS);
rc = getData('10':thisPurchaseOrderDS);

From what I'm reading this should work.

Blizzards are fun. Downtime = exploring time. :)


Bradley V. Stone
www.bvstools.com
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail, or any

Cloud

Provider!

--
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@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

--
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@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
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@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
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@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
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@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.