Skip to Main Content
IBM Z Software


This portal is to open public enhancement requests against IBM Z Software products. 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
Created by Guest
Created on Jan 18, 2017

Use of unqualified objects in SQL-based triggers

When connecting to db2 on our iSeries we are used to using jt400/jdbc
property naming=system, which enables us to use unqualified objects
like tables, stored procedures and such. This brings great flexibility.
When a trigger containing unqualified objects is deployed, the deploying process checks if the referenced objects can be found in the job's
library list. The deploying process automatically qualifies the unqualified
tables and stored procedures in the final trigger-object and therewith
alters the code I have put in the trigger.

I have attached a pdf to demonstrate my case:

Step 1: deploy trigger
After deploying, request the trigger's SQL source through for example
iSeries navigator. As you can see, the trigger-definition refers to an
unqualified table. The deployment process finds table2 in the deploying
job's library list and adds this qualifier to the update command.
Effect of the trigger: updates on table1 also update some record in
table2.

Step 2: copy the table
After copying or restoring the table to another library/environment, request the trigger's SQL source. As you can see, the table qualifier of the table
remains the same and updates are being written to table2 in the
development library, instead of the test library.


Like can be read in IBM's documentation this works as designed.
IMHO IBM does not conform to a principle widely used on the iSeries: library lists. It would be a great enhancement if IBM would also implement this working in (SQL based) triggers.

For example: when developing in a DTAP street the developer creates and alters objects (programs, tables -including triggers-, etc.) in Development level.
Once the developer thinks his or her objects are ready for Test our DTAP-tool copies the objects to the Test environment. However: when tables with triggers are copied we will have to deviate from this procedure and would have to maintain a base of identical trigger-sources for each table for each level of the DTAP street and deploy them, using a library list that contains the right libraries for the level the object is copied to.

Idea priority Medium
  • Guest
    Reply
    |
    Feb 8, 2017

    This is not an RBD/EGL issue, it seems it is mistakenly open for RBD, so reject it.