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 Functionality already exists
Workspace IBM i
Categories Db2 for i
Created by Guest
Created on May 22, 2025

RELATED IDEAS

Change of name and library of SQL package in a Embedded SQL program

Our programs are compiled on a central build server which is integrated in a CI/CD pipeline. Created objects will be saved and restored on different production systems.

We have a ILE Cobol embedded SQL program which can also be used to access a remote IBM i database via SQL Connect statement. When connecting and executing SQL statements via the embedded SQL program the system creates automatically the SQL package on the remote system with library and object name which was specified at compile time in command CRTSQLCBLI and parameter SQLPKG.

At compile time we use the default values RDB(*LOCAL) and SQLPKG(*OBJLIB/*OBJ) because at this point we don't know the target system and also not the target sql package library/object name of our customers systems.

Because we have no source code on our production system we are not able to compile the embedded SQL program again to set the target library and name for the SQL package.

Therefore we need a function to change the target SQL package location on a embedded SQL program (or module within an ILE program) without recompile.

Alternatively we need an option to access the remote system via embedded SQL without the need of an SQL package like it is already an option when using ODBC access.

Idea priority Medium
  • Guest
    Jul 3, 2025
    An embedded SQL program can have an associated SQL package on multiple systems. The package name to use for all packages for all systems is determined at precompile time. Changing the name, with potentially different names for different systems, is not technically possible. The database team has no plan to make changes to how packages are established.

    However, we believe an alternate solution exists, which is described here.

    The existing solution that we recommend is to use three-part names in your embedded SQL program. By including the RDB name in the SQL statement, the statement will be directed to that system to run. One way to do this is to use dynamic SQL to construct your statement "on the fly" for the target system. A more general solution is to create an SQL alias that references the remote system and use this alias name within your statement. You can use CREATE OR REPLACE ALIAS to change the system the alias is associated with prior to running the statement that uses the alias.

    For example, in a package maybe you connect to a system and then run the following statement

    CONNECT TO rmtsys1;
    UPDATE applib.sales SET balance = balance - :payment WHERE account = :acct

    Using a 3-part alias the change might look like this:

    CREATE OR REPLACE ALIAS mylib.sales FOR rmtsys1.applib.sales;
    UPDATE mylib.sales SET balance = balance - :payment WHERE account = :acct

    The Update statement was modified to reference the alias instead of the actual table. When the update statement is run, the alias is used to identify the table. Since it references a table on RMTSYS1, the update is sent to that system to be run.

    To change to run on a different system:

    CREATE OR REPLACE ALIAS mylib.sales FOR rmtsys2.applib.sales;
    UPDATE mylib.sales SET balance = balance - :payment WHERE account = :acct

    Observe that only the ALIAS definition needed to change. The update statement is identical to what was used for RMTSYS1. Now, the update is sent to RMTSYS2 to be run.

    The create alias statement can be run using dynamic SQL, so you can flexibly select what system to use. The statements that reference the alias can be static or dynamic SQL.


    Db2 for i development team
    IBM Power Systems Development
    1 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.