Re: Service Programs & Copy Source

Hi Greg,

yes - everyone faces those questions sometime sooner or later. Here some ideas, that worked for us quite well.

1. "Name-Spaces"

Yes, we "bundle" all procedures in "Name-Spaces" - even as RPG doesn't support them. Thinking about your Amazon API procedures, I would (re-)name them to something like:

amzGetXyz(...)
amzPutXyz(...)

All those prototypes would be in one header file per service program. If you only have one service program, it could be named "AMAZON_H". If you later split everything in multiple header files, use would still use "AMAZON_H" but put the prototypes of AMZSRV1 into "AMAZON1_H" and those of AMZSRV2 into "AMAZON2_H". Both of those prototypes header are then included in "AMAZON_H" so that nobody has to worry about.

2. Selective prototypes

If you don't want every program to include all prototypes, you can surround them with

/if defined(AMAZON_INCLUDE_XYZ_APIs)
...
/endif

And then use this in your programs:

/define AMAZON_INCLUDE_XYZ_APIs
/include AMAZON_H

3. Re-Naming procedures in service programs

If you want you can rename the exported procedures quite easily. As the binding to a service program procedures doesn't only uses the name of the exported procedure at compile time.

If the program object is running, the procedures are only referenced by the "slot number" and the service program. This means if you have an exported procedure named "getAmazoneXyz" today, which is used by 2 programs, you can simply rename it to "amzGetXyz" and the compiled programs still work, as long as the signature of the service program and the position of the export is still the same, and the parameters haven't changed.

If you want to re-compile one of the old programs, you would have to re-name the procedure calls in the source - but only if you want to re-compile.

4. URL changes

I would simply define some constants with the URLs in the AMAZON_H include:

/define #AMZ_XYZ_ENDPOINT 'https://.....';

You already wrote, that a change of the URL most probably is also a change in the API - so I wouldn't think too much about a super-flexible solution.

I hope this helps you a little.

Kind regards,
Daniel

Am 16.10.2025 um 16:40 schrieb Greg Wilburn <gwilburn@xxxxxxxxxxxxxxxxxxxxxxx>:

Thanks for the input - those are great points... I have some of the constants in a table already (along with the credentials, tokens, etc.)
But if the URL changes, it's likely the version changes, so I end up changing the service pgm anyway using UPDSRVPGM

I'm more concerned with things like a procedure called getAccessToken(). I have that same proc name in several APIs.
(YES, I should have created these with a prefix - I do that now, but didn't 10 years ago).
I also have a lot of "template" fields and structures defined that are rather large.

Keep in mind that these are for our internal use.



-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Brad Stone
Sent: Thursday, October 16, 2025 10:06 AM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Service Programs & Copy Source

I personally would add them the the existing /copy source, and make a
new/additional signature in the service program with the binder language so
old programs will use the old signature until recompiled.

As for your constants, etc like endpoints, other values, I used to make
them constants in source but remember if they change it will require a
recompile of everything. So instead I make "control files" with a name and
value and make a simple getControlValue() function that does a simple SQL
on the control file to get the value... like this:

endpoint = getControlValue('AMAZON_BASE_URL');

This way if anything changes it's a simple file update. I used to use data
areas before that and that turned into a headache with so many contants
that could change in the future for some functions with Google, Microsoft,
UPS, etc.

Greg Wilburn
Director of IT
301.895.3792 ext. 1231
--
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.