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.

- deploy trigger
unqualified objects are checked on existence but are left unqualified.

- save file
- restore file (and trigger)
- when an operation is executed on the file which fires a trigger and the unqualified objects can not be found in the library list, the operation fails.