Let's make a quick trip back to six years ago.
Written by Scott Forstie
In 2007, with the tireless editorial help from Skip Marchesani, I wrote an all-inclusive article entitled "Procedures, and Functions, and Catalogs! Oh My!". The fine folks at MC Press published the article in February 2008.
This article has served its intended purpose, providing customers and IBMers alike a resource to bridge the gap between the SQL Reference and the successful deployment and maintenance of SQL routines with DB2 for i. Even though I lack a DeLorean time machine, I feel compelled to return to this article and provide a few updates.
The fuel driving this need to return to an article of the past is the DB2 for i product improvement delivered with IBM i 7.1 Technology Refresh 5 (TR5). In DB2 PTF Group SF99701 Level 18, DB2 for i added implicit routine catalog management when procedures and function executable objects were operated upon using any of these IBM i CL commands (or their API counterparts) or any service that relies upon these services:
- Rename Object (RNMOBJ)
- Move Object (RNMOBJ)
- Create Duplicate Object (CRTDUPOBJ)
Effect of System Commands—Updated
When the original article was published, two companion documents were included, breaking down the effect system commands have upon SQL catalogs when routine executes were the objects affected by the system command. I've updated the tables to reflect the changed behavior, with the updated cells highlighted in yellow.
Refer to this table for details on how system commands impact SQL procedures and functions.
Refer to this table for details on how system commands impact external procedures and functions.
A Glimpse of the Improved Behavior
When copying, moving and renaming executables associated with SQL or external routines, DB2 for i attempts to keep the database catalogs in sync with the executable. These updates are immediately made to the catalogs, but don't stop there. The signature marking information contained within the executable is also updated. This extra step is necessary to accommodate for Save/Restore operations.
Any SQL statements contained the procedure or function are unaffected by the system command processing. For example, consider this SQL statement:
/* Insert new employee into table */
INSERT INTO EMPLOYEE ( EMPNO, FIRSTNME, MIDINIT, LASTNAME, WORKDEPT, HIREDATE, EDLEVEL )
VALUES ( P_EMPNO, P_FIRSTNME, P_MIDINIT, P_LASTNAME, V_DEPTNO, DATE ( V_CREATE_TS ), P_EDLEVEL ) ;
As a static SQL statement containing a table reference that is not schema-qualified, the EMPLOYEE table will be schema-qualified when the procedure is built, using the Default RDB Collection (DFTRDBCOL) setting.
When the executable is moved, renamed, or duplicated, the SQL application statements within the procedure executable are left unchanged. That means that the INSERT statement above will expect to find EMPLOYEE within the same schema (library).
If your goal is to clone an existing library that has both routines and database tables, my suggestion is to use the Generate SQL feature within System i Navigator. The generate option can be launched at the schema level, and you can un-check the "Schema qualify names for objects" and check the "OR REPLACE" clause. The generated script would be devoid of table qualification within statements like the INSERT statement example above. When the generated script is executed, it will use the current schema as the new default RDB collection. Read more about this concept here: Qualified name option added to Generate SQL.
As the original article explained, the SQL7909 warning is returned when a routine is created and DB2 for i is unable to update the internals of the executable with the routine signature detail.
Over time, the SQL7909 warning has been extended to keep pace with the automatic catalog management of routines. The change can be most easily understood by reviewing the changes, which are highlighted below.
SQL7909 reason codes:
Reason code is &4. Reason codes and their meanings are:
1 -- The external program did not exist when the CREATE, ALTER, COMMENT,
LABEL, or DROP statement was issued.
2 -- The external program library is QSYS.
3 -- The external program was not an ILE *PGM or *SRVPGM.
4 -- The program object for the corresponding routine or variable was in
use by another job.
5 -- The SQL associated space in the program was in use by another job.
6 -- The SQL associated space in the program could not be expanded.
7 -- The external program was compiled in a release prior to V4R4M0.
8 -- The SQL associated space in the external program already contains the
maximum number of routine definitions.
9 -- The external program is not in the same Independent ASP (IASP) as the routine
Reason 9 is self-explanatory, and Reason 1 indicates that this warning might be returned on any of the following SQL statements:
COMMENT ON PROCEDURE/FUNCTION/ROUTINE
LABEL ON PROCEDURE/FUNCTION/ROUTINE
Memo to Users (MTU)
Whenever existing behavior is changed, we carefully consider the potential impact to IBM i clients. When we enhanced the catalog management, we anticipated that we could potentially disrupt operations for some customers who had a dependency upon the catalog not changing when executable objects were moved or renamed.
We constructed an optional switch as a remediation mechanism and documented the details in the Memo to Users document. The control is provided via the QIBM_SQL_NO_CATALOG_UPDATE environment variable. Follow the link to the MTU to see the full details.
A Helpful Hand
With Technology Refresh 6 and DB2 PTF Group SF99701 Level 21, DB2 for i supplied a utility procedure to make it easy for customers to assess SQL routine catalog entries between two machines. When a High Availability (HA) or Disaster Recovery (DR) solution is being used, the production and backup machines are generally meant to be identical. When SQL routines are being used, it's critical to also have identical QSYS2/SYSROUTINE, SYSRTNDEP, and SYSPARMS catalog detail.
The original article explained how this tool could be established. With IBM i 7.1 and TR6, the tool exists within the SYSTOOLS schema, where DB2 for i ships tools and examples.
SYSTOOLS/CHECK_SYSROUTINE() is explained in detail in the IBM i Technology Updates wiki: CHECK_SYSROUTINE() procedure added to SYSTOOLS and within this TechTip: "Keep DB2 Routines in Synch Across Systems."
I'm nearly out of time spent revisiting this article. I'll proceed to rev up the flux capacitor and return to the present time. Thanks for reading this brief update, and if by chance you've never seen Back to the Future, you need to add it to your queue.