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).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
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
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
IBM has received the requirement and is evaluating it. IBM will provide a response after evaluation is complete.
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.
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.
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.
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.
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).