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.
SQL7909 Warning
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:
-
CREATE PROCEDURE
-
CREATE FUNCTION
-
ALTER PROCEDURE
-
COMMENT ON PROCEDURE/FUNCTION/ROUTINE
-
LABEL ON PROCEDURE/FUNCTION/ROUTINE
-
DROP 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."
"Back in Time"
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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online