RPG - options(*autostring) in prototypes

IBM believes that the solution for the Idea described is available for 7.4 and 7.5 with the following PTFs to support OPTIONS(*CONVERT).

7.4:

ILE RPG Compiler, TGTRLS(*CURRENT): 5770WDS SI81749

7.5: << Note that this release number was corrected on 2023-01-06 -- it had been incorrectly stated as "7.3".

ILE RPG Compiler, TGTRLS(*CURRENT): 5770WDS SI81801

TGTRLS(V7R4M0) compiler: 5770WDS SI81819

OPTIONS(*CONVERT) is supported for CHAR, VARCHAR, UCS2, VARUCS2, and POINTER parameters. See https://www.ibm.com/support/pages/node/6827011.

- IBM Power Systems Development

IBM agrees with the Idea and a solution appears to be desirable and feasible. IBM intends to provide a solution. However, IBM's plans may change and no commitment is made that a solution will be provided.

If this Idea is implemented, OPTIONS(*CONVERT) will be supported for CHAR, VARCHAR, UCS2, VARUCS2, and POINTER parameters. See https://www.ibm.com/support/pages/node/6827011.

- IBM Power Systems Development

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 CAAC has reviewed this requirement and recommends that IBM view this as a “nice to have” low priority feature. This would be a further extension to RPG language, to take advantage of more object-oriented principles. If the use of an "any type" parameter, as Barbara suggests, is a better solution, then CAAC would support that.

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

For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/

Nancy Uthke-Schmucki - CAAC Program Manager
The CAAC has reviewed this requirement and recommends that IBM view this as a “nice to have” low priority feature.

Ending for every comment:
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

For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/

Nancy Uthke-Schmucki - CAAC Program Manager

This would be a fantastic addition to the language, opening up many new possibilities and simplifying many others by reducing the number of procedure names to create/remember/use.

All of the original request text refers to %char(), so it would seem like the received parameter was intended to be char or varchar. With descriptors available, either would get the job done without actually converting to a null terminated string. In that vane of thought perhaps the name should not contain "string", using *autochar or *cvtchar or *cvtvarchar instead. Leaving the door open for either or both options being available with the later two.

Barbara's *anytype idea and fully fleshing out the descriptor information would be even better. That option of course requires more players and a change to iOS (snicker) and would have a much higher cost. But the rewards are much greater when you can modify the incoming parameter.

IBM has received the requirement and is evaluating it. IBM will provide a response after evaluation is complete.

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

The discussion in the comments provides good information about alternative solutions.

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 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 CEAC, see http://www.comeur.org/i4a/pages/index.cfm?pageid=3285

Dawn May - CEAC Program Manager

@Barbara:
1) You are right with the CCSID issue, but maybe it could be a option : *autoUTF8 , *autoUCS2 , *autoString. If that is to complicated then I would suggest the null-terminated UTF-8 string solution. this is where the world is moving towards.

2) The "any type" parameter was also my first solution, however my guess was that it would require to much work for IBM to implement, and also not as easy to work with for the developer. However it is a cool feature, that would in fact implement RPG polymorphism, namely - it also works for parsing both input and output parameters. - So I would love to post my initial request, but I like both solutions, and the *auto... is easier to comprehend IMHO.

@JonParis
The idea is that is will use the default exact if you use %char(x). However you are free to parse any formating / procedure call/ expression allowed with char strings:

setVar('date' : date);
setVar('date' : %char(date: *YMD));
setVar('text' : 'Life' + ' is a gift'):
setVar('bonus' : bouns);
setVar('bonus' : %EditC(bouns:'A': *CURSYM));

Passing a parameter as a null-terminated character string would be problematic for string variables with a CCSID other than the job CCSID (type C, or type A with CCSID(*UTF8) for example).

I think it would have to either be a null-terminated UCS-2 string (which would have a 2-byte null-terminator), or a null-terminated UTF-8 string.

Even if the system doesn't fully implement descriptors, it would be possible for RPG to implement its own "any type" parameter, which would have some kind of RPG-only descriptor passed along with the parameter. Having a described parameter would make it much (probably much much) harder to write the procedure to handle an "any type" parameter than the suggested "autostring" parameter, but it would increase the number of cases where it was easy to _call_ the procedure, since it could handle cases where the procedure needed to know the data type, or where the procedure wanted to modify the parameter. Also, it would solve the issues with date formats, CCSIDs etc. But implementing an "any type" parameter for RPG would be a separate RFE.

Interesting idea. I'd prefer that the system fully implement descriptors so that we didn't have to descent to the LCD of using strings - but since that doesn't seem likely to happen this would at least provide some options.

How do you suggest that date formatting etc be handled? With %Char we have a formatting option for dates and times. Also I often have to use %EditC with the 'X' code to preserve leading zeros in things like US zip codes.