Skip to Main Content
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.

Status Not under consideration
Workspace IBM i
Categories Languages - RPG
Created by Guest
Created on Feb 13, 2017

Provide namespace for exports

As IBM increasingly embraces open source, and third party libraries, it is important to be able to distinguish between like named procedures from different libraries. Please provide a way to namespace service program imports and exports to improve resolution of conflicts. Given that service programs today do not enforce any sort of namespacing, it is important for backwards compatibility to be able to explicitly assign a namespace to a specific service program or module in a program that uses it, and to be able to explicitly specify which service program or module to search for a given export. This is even more important due to the prevalence of certain third party libraries which are open source, and may be different depending on where it is coming from. For example, a commonly used third party library is CGIDEV. This library is available from Easy400, but is also frequently embedded in other third party libraries, sometimes with modifications specific to that library. The lack of namespacing forces the developer to jump through many hoops when using certain procedures from two libraries containing incompatible versions of CGIDEV. CGIDEV is not the only library where I have come across this problem.


Use Case:

See description.


Idea priority Medium
  • Guest
    Reply
    |
    Apr 24, 2020

    IBM does not intend to provide a solution to this request at this time, so it is being closed.

    However, there is another RFE 92592 with a somewhat-similar requirement for a namespace feature within a single ILE RPG module. That RFE has been accepted. The title of the RFE is "Prefix or Qualified Keyword for Exports and/or Prototypes".
    http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=92592

  • Guest
    Reply
    |
    Aug 29, 2017

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

    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/

    Dawn May - CAAC Program Manager

  • Guest
    Reply
    |
    Aug 25, 2017

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

  • Guest
    Reply
    |
    Jul 24, 2017

    A potential syntax could be something like:
    dcl-ns code Srvpgm([library/]name) Prototypes([library/]name);

    It could also be namespaced on the /copy directive to namespace any declarations:
    /copy [library/][sourcefile,]member namespace

    A procedure name would then be something like:
    [code::]procedureName(...);

    Then you could write

    dcl-ns rm rpgmap/rmsrvpgm;

    rm::map(...);

    Or for those who want a longer namespace:

    dcl-ns RPGMap rpgmap/rmsrvpgm;

    RPGMap::map(...);

    RDi code completion routines could then recognize namespaces defined in a source and offer to complete them with :: and then include a list of available procedures in the namespace. The outline could even group prototypes by namespace. If using /copy directive, it would have to be determined how the namespace of nested /copy declarations would be affected.

  • Guest
    Reply
    |
    May 9, 2017

    I would like to add some suggestions for this:

    Enhance the Binder Language as follows:

    1. on the STRPGMEXP command, add a new PREFIX keyword that would allow for either PREFIX(*MODULE) or PREFIX(*SRVPGM) or both. This would concatenate the name of the *MODULE or *SRVPGM to the start of each exported procdure name or data element name,.

    For examople, from CGUDEV2, if I specified:

    STRPGMEXP PGMLVL(*CURRRENT) PREFIX(*SRVPGM)

    This would result in procedure names such as:

    CGISRVPGM2_ADDMSG
    CGISRVPGM2_CFGMSGS
    etc.

    If I specified:

    STRPGMEXP PGMLVL(*CURRRENT) PREFIX(*MODULE)

    This would result in procedure names such as:

    XXXUSRSPC_CRTUSRSPC
    XXXUSRSPC_RTVUSRSPCPTR

    and if I specify:

    STRPGMEXP PGMLVL(*CURRRENT) PREFIX(*MODULE *SRVPGM)

    This would result in procedure names such as:

    CGISRVPGM2_ XXXUSRSPC_CRTUSRSPC
    CGISRVPGM2_ XXXUSRSPC_RTVUSRSPCPTR

    where the hierarchy would always be: service program name first, then module name, then procedure or data element name.



    Also, for further flexibility, the binder source EXPORT command should be expanded with a new keyword, for example "AS" to work as follows:

    EXPORT SYMBOL(ISDEBUG) AS(MY_ASDEBUG)
    or
    EXPORT SYMBOL(DOCMD) AS(COMMANDS_DOCMD)

    This would give the developer total control over the names exported from any given version of any service program created.

  • Guest
    Reply
    |
    Feb 14, 2017

    If I can assign a namespace to v1 of a service program, and a different namespace to v2 of the same service program that lives in a different location, then namespaces can be used to solve the problems I am seeing. Your method of resolving to service programs with incompatible exports will also work, but there is no guarantee that the developer of v2 will change the signature. In any case, a new namespace would solve the problem. Namespaces would have to be able to fully qualify an export by service program and library for this to work.

  • Guest
    Reply
    |
    Feb 14, 2017

    If I can assign a namespace to v1 of a service program, and a different namespace to v2 of the same service program that lives in a different location, then namespaces can be used to solve the problems I am seeing. Your method of resolving to service programs with incompatible exports will also work, but there is no guarantee that the developer of v2 will change the signature. In any case, a new namespace would solve the problem. Namespaces would have to be able to fully qualify an export by service program and library for this to work.

  • Guest
    Reply
    |
    Feb 14, 2017

    I would also like to have namespaces for procedures (or rather all exported symbols) but the problem you are describing is not really related to namespaces but rather to different versions of the same serviceprogram. Using binder language and giving the service program the correct signatures could help here (or be at least 50% of the solution).

    Lets assume we have service program binarytree in version 1.2 with the signatures "bintree1.2", "bintree1.1" and "bintree1.0" (as version 1.2 is compatible with 1.1 and 1.0) and the same service program but with some incompatible exports and thus removing all previous signatures and giving it the signature "bintree2.0".

    Now if both service programs are in the library list the bound program should take the appropriate service program with the correct signature and not fail on the first one because of the right name but the wrong signature (don't know if that is the case atm).