The recently announced Technology Refresh #5 for the IBM i 7.1 release includes an enhancement that makes management of SQL stored procedure and function objects easier.

SQL procedures and functions have been supported by DB2 for i for many releases. This support enables developers to create procedural SQL objects like the example procedure shown in Figure 1. When the SQL Create Procedure statement in Figure 1 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

Figure 1: Example SQL Procedure

Normally, an IBM i developer 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);

Figure 2: TestProc Test Script

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.

This new capability is enabled by loading the IBM i 7.1 Database Group PTF level 19. You can easily verify that the new support is working by running the following SQL Select statement after running one of the enhanced commands.

SELECT routine_schema FROM QSYS2/SYSROUTINES WHERE routine_name='TESTPROC'

This new support means no more mysterious Object Not Found errors for developers working with SQL procedures and functions. Developers can simply just keep using the same system commands that they have in the past for traditional IBM i application programs.