SQL Myths 1/100

When the FOLLOWING SQL Create Procedure statement is executed, DB2 for i generates a C program object into the specified library (TESTLIB). The generated C program object gets called whenever an application invokes the TestProc stored procedure.

CREATE PROCEDURE devlib/testproc

(IN ordnum integer, IN ordtype char(1), IN ordweight decimal(5,2))

LANGUAGE SQL

BEGIN
DECLARE ratecalc DECIMAL(5,2);
IF ordtype='I' THEN

SET ratecalc = ordweight * 5.50;

INSERT INTO wwshipments VALUES(ordnum, ordweight, ratecalc);

ELSE

SET ratecalc = ordweight * 1.75;

INSERT INTO shipments VALUES(ordnum, ordweight, ratecalc);

END IF;

END

Normally, WE would use system commands like Create Duplicate Object (CRTDUPOBJ) or Copy Library (CPYLIB) to move a program object from a development library to a test or production library. While these system commands complete successfully with the *PGM and *SRVPGM object that DB2 generates for SQL procedure and functions, these commands did not fully work. The commands don't fully work because they did not update the DB2 catalog objects in QSYS2 that are used to keep track of all the stored procedures and functions on a system.

Walking through a scenario will help you understand the limitation of some system commands. Suppose a developer decides that the TestProc procedure is ready for more extensive testing, so he executes the following CRTDUPOBJ command:

CRTDUPOBJ OBJ(testproc) FROMLIB(devlib) OBJTYPE(*PGM) TOLIB(testlib)

This command successfully creates a copy of the C program object into the testlib library.

The developer now runs the SQL test script in Figure 2 to run some tests against the TestProc stored procedure. However, both CALL statements fail with an Object Not Found error (SQL0204). This is due to the fact that the DB2 catalog objects were not updated by the CRTDUPOBJ command. Thus, DB2 only knows about the stored procedure object in the devlib library.



SET PATH testlib;

CALL testproc(101, 'I', 3.50);

CALL testproc(102, 'D', 0.25);

Prior to the recently delivered enhancements, a developer's only solution was to delete the program object in testlib and then execute the SQL statement in Figure 1 after changing the library name from devlib to testlib. The new IBM i 7.1 support eliminates this object management headache by enhancing the following commands to always update the DB2 catalogs when the *PGM or *SRVPGM object was generated by DB2.



CRTDUPOBJ
CPYLIB
RNMOBJ (Rename Object)
MOVOBJ (Move Object)



The system restore commands have always had the ability to update the DB2 catalog objects when a DB2-generated procedure or function object was restored onto the system. Now, the rest of the system commands that move or change objects have the same intelligence to update the DB2 catalog.