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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
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.
The ability to maintain a consistent signature for a service program is available through the use of the binder source. The
binder source also allows a developer to control the order of the exports from a service program, so that new exports can
be added to the end of the export list. Adding new exports to the end of the list makes it possible to avoid having to
rebuild all programs bound to the service program. Only programs that need to use the new exports would need to be rebuilt.
When EXPORT(*ALL) is used during the creation of a service program, the signature is a hash of the names of all of the exports.
If the signature of the service program has changed after it is created again, that indicates that the exports have changed.
The name of an export may have changed, or a procedure or data export may have been added or removed. The signature
will not change if the exports are exactly the same. The Retrieve Binder Source (RTVBNDSRC) command can be used to create the binder
source for an existing service program. The RTVBNDSRC command output could also be compared for 2 different versions of a
service program that have different signatures, to determine what has changed in the export list.
Binder source already solves this problem. Support for previous signatures works well so long as you add all new procedures to the end of the binder export list. The only time you should need to rebind a program that uses the service program is when it needs to access newly added procedures. If you assign a signature at creation time via a parameter you will start to get problems with bound programs that match the signature but were bound against a different procedure table as Jon pointed out. Binder source is also a good place to put high level documentation for the service program.
The following RFE may be a solution fo this problem to.
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=119688
The following RFE may be a solution fo this problem to.
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=119688
I don't see how this can work as specified. I have already entered this comment once in detail but it has "disappeared" so this is a short summary.
When *ALL is specified the binder assigns slot numbers (which is how the caller links to the procedure) is alphabetical order of procedure name. So if we originally have procedures a and d - a is in slot 1 and d in slot 2. Any caller of d just has the 2 stored. Now add procedure b and recreate the SP. Slot assignments are now a=1, b=2, and d=3. No signature violation because you forced the signature to match. But the caller of d is actually going to be connected with b! The results might be interesting but will not be correct!
Binder source is not hard to maintain and you just add new routines to the end of the list. The alternative (and one that many use) is to rebind everything when an SP is rebuilt. This is the approach that some change management tools take.
To make this approach work would require the binder to store the sequenced list in the SP and to add any procedures encountered not found in the current list to the end of the new list - just as one does manually.