Re: New IBM idea - Named Parameters at Program and Procedure Calls

P.S.: @Birgitta

I knew it is a good idea - I already created a similar one in December:

https://ideas.ibm.com/ideas/IBMI-I-4733

As your idea already has more votes, I hope IBM merges both.

Am 27.02.2026 um 16:36 schrieb Daniel Gross <daniel@xxxxxxxx>:

Some thoughts about that idea.

Many modern languages have adopted the idea of "named parameters" - e.g. Swift, Ruby, Python, C#. But also al lot of older languages know that kind of using "keyword" parameters or "named" parameters - e.g. SQL, Ada, Smalltalk, Objective C. So this is not a new idea - it's only new for RPG. And it's a good idea, because to makes parameter passing safer and much easier to read.

procedure(123:'ABC':*omit:*omit:rtncode);

This is short and quite nice. And if you are writing the code, it's absolutely clear, what each parameter is for. RDi and Code4i help a lot in writing it. But if you read the code, you need to inspect the code in detail, to find out what each parameter is.

procedure(name=>'ABC':count=>123:result=>rtncode);

This looks "exotic" first - but you can see instantly, what every parameter means. You don't need *OMIT (if you don't like) as it is implicit. The sequence of the parameters doesn't matter anymore. Even when the procedure gets those parameters "sorted" into the DCL-PI parameter fields.

So from the "called" procedure side, both calls will look exactly the same - it's just another form to make that call.

@Luca Giammattei:

Yes - we would have to think about "internal" (variable) names of the parameters (from the DCL-PI) and "external" (keyword) names (from the DCL-PR). But type checking and everything would work perfectly nice.

@Helga Bichel:

Using a variable string parameter is a good option, but also unsafe. You would need a very stable library of functions to assemble those strings or even use JSON or XML. But even then the compiler has no chance to find wrong calls, misspelled parameter names at compile time - all that can only be checked at the worst time - at runtime.

Don't get me wrong - I have some procedures that accept JSON parameter strings for variable information. It's quite easy to do with SQL - but I also have a lot of checks to do, to make sure that the "syntax" of my parameter strings are correct.

Finally:

I think it's a great idea to have that option - especially for procedures with many parameters - and if IIRC Birgitta wrote that this should be an additional option - so it wouldn't harm those who think, that they don't want that. Like linear main procedures - it's a modern option - but you can still *INLR = *ON to end your "traditional" (cycle) main procedures.

Kind regards,
Daniel

Am 27.02.2026 um 16:02 schrieb Peter Dow <petercdow@xxxxxxxxx>:

I don't think Birgitta was advocating replacing the current method of passing parameters, more like providing another method.

One advantage of the new method is that if a new parameter is added, it would not affect other programs using the same named-parameter method.

On 2/27/2026 6:52 AM, Luca Giammattei wrote:

Il 27/02/2026 08:44, Birgitta Hauser ha scritto:

I have added a new IBM idea, to allow specifying Parameter Names (and
assigning the parameter values) at program/procedure calls (in the same way
as you can do it with SQL Stored Procedures, UDFs and UDTFs)
https://ideas.ibm.com/ideas/IBMI-I-4826

Please LIKE if you think it would be helpful/useful

Interesting idea, although one of the things I've always loved about our compiler's parameter management style is that it doesn't care about their names; what really matters is their nature and order. So I don't see it as easy to implement in contexts with legacy code or even a mix of legacy and free. Perhaps it should be limited to the fully free language, and even here I'm not sure. I wouldn't want to be constrained by the parameter name rather than its nature, even though today, when everyone programs with advanced tools like VS Code or RDi (right?), managing these aspects is much simpler.

What if the parameters are also used to pass messages from one program to another? Nothing would change, right?
I'm thinking of the case where pgm1 calls pgm2, passing it two parameters: one containing data to be used within pgm2's processing and the other as a sort of return code for the outcome of the processing.

something like
foopgm(parm1:rtncode);
if rtncode=*blanks;
//successful execution
elseif rtncode <> *blanks;
//something went wrong, let's log the error
endif;

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