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 (

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 ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - 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
Created by Guest
Created on May 7, 2018

Set Service Program signature via the CRTSRVPGM command

Today, the signature is set by one of the following methods:
1. From the STRPGMEXP SIGNATURE statement of the QSRVSRC source
2. Automatically generated during service program creation if no QSRVSRC is specified or SIGNATURE is *GEN

When using method 2, every time the service program is recreated, all dependent service programs and programs must be updated to the new signature or a exception is thrown.

This request is to enable setting the Service program signature from the CRTSRVPGM command.

Use Case:

Let say we have a service program that we don't want to maintain a QSRVSRC source because we want to EXPORT *ALL.
Each time we re-build the service program, the service program is created with new signature, even though its construct is the same, nothing has changed in term of the exports.

A good example is the OpenSSL service program.
While re-building it over and over again to make it compatible to the ILE environment, each time we built it, all other programs and service programs must have been re-updated.
This makes it very uncomfortable since the OpenSSL lib still had the exact same exports.

Idea priority Medium
  • Guest
    Mar 31, 2020

    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.

  • Guest
    May 21, 2019

    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.

  • Guest
    May 9, 2018

    The following RFE may be a solution fo this problem to.

  • Guest
    May 9, 2018

    The following RFE may be a solution fo this problem to.

  • Guest
    May 8, 2018

    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.