Support MC Press - Visit Our Sponsors

 

Forums Sponsor

POPULAR FORUMS Unable to create java virtual machine on V7R1 (698 views) RUNRMTCMD to Windows Server 2008 R2 (556 views) Fixed header table plugins (537 views) AIRLIB Objects Work on V7R1? (509 views) PDF Colors and Fonts - Do these changes apply only to Paragraphs? (425 views) CL to monitor job queue and release jobs (425 views) Password-Protect PDF in the IFS (320 views) CL to monitor job queue and release jobs (303 views) Print Bar Graph from RPG (176 views) QR Barcode Printing using RPG and DDS - tech tip (116 views) Forums

 

 

Search Sponsor

Search

Are you in a quandary because DB2 Web Query can't use *libl to find your stored procedure's synonym? Yes, it can!

In a previous Tech Tip, "Use a Stored Procedure as Your Data Source in DB2 Web Query for i," I discussed using a stored procedure as the data source in DB2 Web Query for i. Using a stored procedure as your data source offers many benefits to you as a developer: 

• You can keep your business logic in one stored procedure that can return a result set to many DB2 Web Queries instead of duplicating the business logic in multiple Web queries.
• If your stored procedure is written in SQL (or embedded SQL in RPG), it can make use of user-defined functions or SQL views you have already created.
• If your shop has power users who were accustomed to creating their own Query/400 reports, you can develop stored procedures that include your business logic, create synonyms over them, and then let your power users build DB2 Web Queries over the stored procedure's synonyms. No more worries that different users are calculating and reporting numbers differently in different queries!
• If you have the need, your stored procedures can include an auditing function via an insert to an audit table to log the user/date/time of a DB2 Web Query report that selected sensitive data.

These are just a few benefits of creating a synonym over a stored procedure to feed data to DB2 Web Query. There is one minor drawback, however.  

If you have created synonyms over table files, you most likely checked the "One-part name" box on the Create Synonym screen, as shown in Figure 1.

Figure 1: Note the "One-part name" option on the Create Synonym screen. (Click images to enlarge.)

DB2 Web Query uses one-part naming to search the library list to find the appropriate data set. If you are unsure what this means, Gene Cobb's article, "Making Better Use of DB2 Web Query with *LIBL," explains the process.  

At the current time, synonyms built over stored procedures can only be defined with two-part naming. This results in a synonym with the stored procedure's library name hard-coded, as shown in Figure 2.

Figure 2: The synonym created over stored procedure STOREDPROC has library name ACORC hard-coded in the definition.

If like most shops, you avoid hard-coding library names, there is a workaround. For each stored procedure, create a "wrapper." The wrapper simply receives the input parameters and calls the original stored procedure, using the library list to locate it. The original stored procedure builds your result set and returns it.

To implement this technique, first create a library (in our example, SPLIB) that will contain nothing but the stored procedure wrappers. 

Then, set up a naming convention to logically group the original stored procedures and their wrappers together.

Next, create and test your original stored procedure to confirm it is working properly (see the previous Tech Tip, "Use a Stored Procedure as Your Data Source in DB2 Web Query for i," for help creating and testing your original stored procedure).

Then, create the stored procedure wrapper. The wrapper for the stored procedure STOREDPROC was created using the SQL command shown here:

CREATE PROCEDURE SPLIB/STOREDPROW                       

 (IN state CHAR ( 2),                                   

  IN location CHAR ( 3),                                

  IN contract CHAR ( 9),                                

  IN speriod CHAR( 6),                                    

  IN eperiod CHAR( 6))                                     

LANGUAGE sql                                            

SPECIFIC STOREDPROW                                      

NOT DETERMINISTIC                                       

READS SQL data                                           

begin call                                              

 STOREDPROC(state, location, contract, speriod, eperiod);

end

Finally, create the synonym over the stored procedure wrapper. There is no need to create a synonym over the original stored procedure, just the wrapper.

You can then build DB2 Web Query(s) using the wrapper synonym as your data source.

Please note: for this technique to work, you must remember two things:

• Create the stored procedure for the wrapper with the *SYS naming convention.
• In your original stored procedure, make sure to declare the cursor as "with return to client." (See subroutine @open_cursor in the code examples shown in the previous Tech Tip "Use a Stored Procedure as Your Data Source in DB2 Web Query for i.") This will insure that the result set is passed all the way back from the original stored procedure to DB2 Web Query.