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 Not under consideration
Workspace IBM i
Categories Languages - RPG
Created by Guest
Created on Nov 19, 2025

RELATED IDEAS

Allow generic member/file name for /COPY and /INCLUDE compiler directive

Today if we have to include several copy member, we have use one /COPY or /INCLUDE directive per member:

/include qcopysrc,copy01
/include qcopysrc,copy02
/include qcopysrc,copy03

My proposal is, to extend the /COPY and /INCLUDE directive to support generic names for the include member name:

/include qcopysrc,copy*

This would allow to a bunch of copy members with one directive.

As an extension the inclusion of all members in an source file should probaly also be possible:

/include qcopysrc,*all

This would make it easier to split large, monolithic copy files into smaller parts, without sacrificing readability. Of course, this should also be possible in nested copy files, if the compiler command allows this.

It also does not collide with existing code, where no generic names are allowed, and the asterisk character is not allowed today.

This should of course work with the *LIBL in mind - so the compiler should search for matching members in the *LIBL, if the library is not explicitly stated. From the *LIBL every individual copy member should only be included once, even if it exists multiple times in the *LIBL - just like the current behavior with a single copy member.

Example with *LIBL:

/include qcopysrc,copy*

lib1/qcopysrc,copy01 <- this is included
lib2/qcopysrc,copy01 -> ignored bc copy01 was already included 
lib2/qcopysrc,copy02 <- this is included
lib3/qcopysrc,copy01 -> ignored
lib3/qcopysrc,copy02 -> ignored
lib3/qcopysrc,copy03 <- this is included

And of course this should also work with IFS copy files - also in the IFS the asterisk char is reserved and cannot be used in a file name without additional effort (quoting).

Idea priority Medium
  • Guest
    Dec 16, 2025
    Thank you for taking the time to submit your Idea. However, IBM does not intend to provide a solution to this Idea, so it is being closed.

    RPG already supports nested /COPY. As already suggested in an earlier comment, you can split up a large copy member into smaller members and change the large copy member to just have /COPY statements. Programmers can then copy the larger file if they want to copy all the members, or they can copy individual members.

    - IBM Power Systems Development
    Reply
  • Guest
    Dec 16, 2025

    I do not think this idea should be implemented...

    It is widely accepted in the industry that imports should not be generic. Generic imports pollute your code and namespaces, and you may end up with unintended functions and data in your code. Instead, be very specific in your imports and only import the bare minimum.

    Instead you could take advantage of the fact that /COPY and /INCLUDE can be nested. In your case you would split the monolithic copy file into smaller files and change the original file to just include the smaller files. Or you could build copy files by function or scope.

    Best regards,

    Christian Jorgensen, CEAC member

    Reply
  • Guest
    Dec 5, 2025

    excellent idea

    Reply
  • Guest
    Dec 5, 2025

    This is a good idea. It lowers barriers to modular development on the IBM i. Programmers could use this feature to provide an interface to a set of modules and service programs the way Java does with package imports.

    Reply
  • Guest
    Nov 21, 2025 
    /copy coztools/qcpysrc,*all

    This syntax with *ALL has been supported since day 1 of RPG IV.
    I've asked fro generic member support before in other interfaces, and was declined. But I like the idea although today it would be a low (not medium) priority for me. More of a nice to have.

    However, the example you show, I hope is just an example and not considered "clever" to use names like "copyxx" for copy members. 🤔 If you had, for example an manufacturing system with a set of prototypes and put them in MSGWHSE MFFINVTRY MFGPLAN etc. then I get it. /copy prodsrc/qcpysrc,mfg* would be helpful.
    But a very niche market and until the database supports such features (today it does not) then I don't see how RPG would do it without writing their own customer member open handler and I wouldn't expect them to do that. But it would be helpful outside of this "idea".

    Reply
  • Guest
    Nov 19, 2025

    I like the idea of the wild card.


    I do not like the idea of the *all. My fear is everyone will get lazy & put that in their programs, rather than just the copies they need.

    Reply
  • Guest
    Nov 19, 2025

    (added to idea text)

    Reply
  • Guest
    Nov 19, 2025

    (added to idea text)

    Reply

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.