IBM Power Ideas Portal


This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


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:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Add a new idea Subscribe
Status Future consideration
Workspace IBM i
Categories Languages - RPG
Created by Guest
Created on Feb 21, 2022

RELATED IDEAS

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

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.