Allow a BIF that checks to see if a parameter is passed

IBM believes that the solution for the Idea described is available with PTFs provided at the same time as the Spring 2023 Technology Refresh.

Two new built-in functions are added:

- %PASSED(parameter_name) returns *ON if the parameter was passed and *OMIT was not passed

- %OMITTED(parameter_name) returns *ON if *OMIT was passed as the parameter

For documentation on this enhancement, see
- What's new since 7.5: https://www.ibm.com/docs/en/ssw_ibm_i_75/rzasl/rpgrelv7r5post.htm
- What's new since 7.4: https://www.ibm.com/docs/en/ssw_ibm_i_74/rzasl/rpgrelv7r4post.htm

For information about the PTFs you need for this enhancement, see https://www.ibm.com/support/pages/node/6982093

- IBM Power Systems Development

After reading all the comments, I now agree that %PASSED should only be true if a parameter was passed and not omitted.

If %OMITTED is also added, it would be true the parameter was passed as *OMIT.

So, as Doug suggests, there are three possibilities:

• An actual value is passed for the parameter. %PASSED TRUE, %OMITTED FALSE.

• *OMIT is passed for the parameter. %PASSED FALSE, %OMITTED TRUE.

• Nothing is passed for the parameter. %PASSED FALSE, %OMITTED FALSE.

There is no possibility for the fourth case of %PASSED TRUE, %OMITTED TRUE.

For 99% of the time, 99+, a simple check of %PASSED is all that's necessary.

For the occasions when you actually want to know that *OMIT was passed, a simple check of %OMITTED is all that's necessary.

- Barbara Morris, IBM, RPG compiler development

The idea is asking for a BIF that checks if an actual argument is passed.

• No parm passed - %passed returns FALSE

• *OMIT passed - %passed returns FALSE

• Actual argument passed - %passed returns TRUE.

So, %passed should be sufficient to tell me that an actual value was passed, rather than no pass or *OMIT.

If there are indeed three logical entities:

• Nothing passed - %omitted is FALSE, %passed is FALSE

• *OMIT passed - %omitted is TRUE, %passed is FALSE

• Actual data passed - %omitted is FALSE, %passed is TRUE

• %omitted is TRUE, %passed is TRUE - meaning that *OMIT and actual data were both passed, is obviously a logical fallacy, so it makes no sense to me to have %passed return TRUE if *OMIT was passed.

Regardless of the solution eventually offered, it will be much better than what we have now.

I agree that %passed by itself is not sufficient for parameters that can be omitted.

if %passed(myparm) and not %omitted(myparm);
... process the parameter

- Barbara Morris, IBM, RPG compiler development

"%Parm() and %ParmNum() already give us all the functionality required ..."

No they don't. They do not tell you if a parm was passed as *Omit. And to determine that you have to test the %Addr of the parameter against *Null. This is far from intuitive. I'm not convinced that the suggested option in this IDEA (%Passed) is sufficient either. Logically, the omission of a parameter, submission but with *Omit, and the passing of a value can be three distinct logical entities.

The CAAC has reviewed this requirement and recommends that IBM view this as a “nice to have” low priority feature. This will simplify the process of checking for parameters, but implement only if it is easy enough to do.

Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.

For more information about CAAC, see www.common.org/caac

Nancy Uthke-Schmucki - CAAC Program Manager

IBM will use this request as input to planning but no commitment is made or implied. This request will be updated in the future if IBM implements it. IBM will use votes and comments from others in the community to help prioritize this request.

The CEAC has reviewed this requirement and recommends that IBM view this as a MEDIUM priority requirement that should be addressed.

Background: The COMMON Europe Advisory Council (CEAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CEAC has a crucial role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community and has therefore reviewed your RFE.

To find out how CEAC help to shape the future of IBM i, see CEAC @ ibm.biz/BdYSYj and the article "The Five Hottest IBM i RFEs Of The Quarter" at ibm.biz/BdYSZT

Therese Eaton – CEAC Program Manager, IBM

At first glance, I was skeptical, but this would make checking parms consistent whether they were defined with *NOPASS, *OMIT, or both. This would be some nice syntactic sugar on my RPG-O's.

%Parm() and %ParmNum() already give us all the functionality required to determine if a parm was passed in or not. Not sure why this request was even created. What use-case would this request solve? I do not see the value here...what am I missing?

if %Parm(theParmVariable);
// use TheParmVariable
endif;


I couldn't agree more. A simplified interface of a built-in named something like %PARM that does both those options. Then we'd only have to also check for blanks or zeros.