Skip to Main Content
IBM Power Ideas Portal

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Post your ideas

Start by posting ideas and requests to this portal to enhance a Power product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas and add comments to ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The Power teams will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notification on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.


Specific link you will want to bookmark for future use

IBM Unified Ideas Portal - https://ideas.ibm.com/ - Use this site to create or search for existing Ideas across all IBM products that are outside of Power, and track all of your personal interactions with all Ideas.

Status Future consideration
Workspace IBM i
Categories Languages - RPG
Created by Guest
Created on Feb 21, 2022

Allow duplicate CTL-OPT keywords.

In the RFE
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=153870
I raised an idea of overriding the values of the control specification using /SET.
Barbara Morris asked me to raise it in a separate RFE. This is hereby done.

Getting creative I could imagine /SET to overload other control specification keywords specified
in the data structure RPGLEHSPEC or a copy file.

For example
/SET DFTACTGRP(*NO)
/SET ACTGRP(*NEW)
/SET BNDDIR('QC2LE':'MYLIB')

This would cause ACTGRP(*NEW) to be used instead of the default ACTGRP(*CALLER)
specified in data structure RPGLEHSPEC or a copy file. It would give you the possibility
to modify your default specifications with new options and have them implemented
when you compile the program the next time. For example EXPROPTS(*ALWBLANKNUM)

Of course these compile time keywords should be specified in the beginning of the source and /RESET is not relevant here.


Use Case:

Barbara Morris suggests that a new keyword ALWDUPKW(*YES or *NO) could be implemented.
If it was *YES, then the compiler would allow any H spec keyword to be specified more than once, and it would just take the last setting.

This is also a solution.

Of course this should override the normal behaviour of not copying the contents of the data structure RPGLEHSPEC when control options are specified in the source. If ALWDUPKW(*YES) is found then RPGLEHSPEC should always be copied.


Idea priority Medium
  • Guest
    Feb 28, 2022

    Hi Paul. thanks for continuing the discussion!

    We will continue to consider whether it is necessary to have a new keyword and/or a new command parameter.

    It is possible that for a new release, we could change to simply allow duplicate keywords, and document this change in the Memo to Users. But we could not make such a change with a PTF. If we did decide to make this change in a TR-timed PTF, we might just add an environment variable to allow it for the PTF versions.

  • Guest
    Feb 27, 2022

    @Barbara I'm not following on your comment "we might also consider a new command parameter for duplicate-ctl-opt keywords that could have the default changed with CHGCMDFT" ? Personally I would by default make the source the master (the source is the best documentation) instead of a value specified by the individual CRT command (where the correct value is often forgotten as there's no place to "document" it). One of the seldom exceptions on this is the target release and/or debug level.

    I just hope IBM is not cluttering things with a lot of extra/different commands to keep things "compatible".

  • Guest
    Feb 24, 2022

    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.

    If this feature is implemented, it would only be to have an option to allow H spec keywords to be specified more than once, using the latest value. For keywords like the OPTION keyword, the last setting for any one option would be in effect. For example, if the source had OPTION(*XREF:*NODEBUGIO) OPTION(*NOXREF), then the second OPTION keyword would only affect the XREF option. It would not affect the DEBUGIO option.

    If implemented, this feature would not affect how the RPGLEHSPEC data area is used. The compiler would continue to only retrieve the RPGLEHSPEC data area if there is no H spec or CTL-OPT in the source.

  • Guest
    Feb 24, 2022

    @Paul, I wish that it had always been allowed to have duplicate H-spec keywords. But some shops may not want programmers to override the keywords in some standard copy file. So I don't think we can just relax the rule and allow duplicates without a new keyword. However, if we added a new keyword such as ALWDUPKW, we might also consider a new command parameter for duplicate-ctl-opt keywords that could have the default changed with CHGCMDDFT.

  • Guest
    Feb 24, 2022

    @Peter... why would you need a new /SET directive, what's wrong with Ctl-Opt ? Just allow it to be repeated multiple times if you need the flexibility to have options spread over multiple statements.

    @Barbara... why a new keyword ALWDUPKW, just take the last option specified (sounds the only logical choice for me) and generate a warning in the compiler listing if a duplicate option is present.

  • Guest
    Feb 24, 2022

    Well, my idea was that in case the RPGLEHSPEC data area was copied then I didn't need the copy file.
    Right now I have to remember to modify both objects - the data area and the copy file - to keep them identical.

    On the other hand - If I didn't mention the data area then I think you wouldn't implement it.
    Now you have the possibility to decline it :-)

  • Guest
    Feb 22, 2022

    Peder, I don't agree with the suggestion to always copy the RPGLEHSPEC data area if ALWDUPKW is encountered. I would not want to encourage any new or continued use of the data area.

    If source were being changed to add the ALWDUPKW keyword, it could also be changed to add a copy file with the keywords in the RPGLEHSPEC.