Binding DB2 with Java JDBC and COBOL embedded SQL

Note: Before you begin, it is important to be familiar with the DB2® for z/OS® package creation for SQLJ programs. For additional details, see the following information about writing and preparing Java™ programs that access DB2 for z/OS databases:

The topic about "Programming for Java" in http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.java/db2z_java.htm
The topic about "Preparing and running JDBC and SQLJ programs" in DB2 Application Programming Guide and Reference for Java.
The topic "Binding an application" in DB2 Application Programming and SQL Guide and in http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.apsg/db2z_bindplanpanel.htm

As input, the JDBC driver of z/OS supports application package collections or a plan name. Embedded SQL in IBM® Enterprise COBOL routines typically use a bound DB2 plan as input. Packages provide more flexibility by minimizing full application rebuilds when only one SQL source file is updated. Therefore, a best practice for the hybrid mixture of COBOL and Java JDBC sharing a local RRSAF attachment is to use a package list passed to the JDBC driver through the JDBC property db2.jcc.pkList. These JDBC properties can be passed on the Java command line using -Dprop_name=value. When many properties are involved, you can use the special JDBC property -Ddb2.jcc.PropertiesFile=pathname of the file, where the PropertiesFile contains the list of desired jcc.db2.* system properties. You can also use JDBC APIs to set properties; for more information, refer to DB2 Application Programming Guide and Reference for Java.

For the commands necessary to build SQLJ packages for Java programs containing SQLJ, see Commands for SQLJ program preparation.

There is considerable flexibility when binding with existing packages and DBRM members, or both. To bind a COBOL program containing embedded SQL, which has been preprocessed or co-processed to produce DBRM member XMPCOBJX (for instance, COBOL extended with Java JDBC), you can use --.

Figure 1. Example: JDBC-only case

//BINDCOBX JOB (1),'name' 
//             NOTIFY=&SYSUID,                       
//             MSGCLASS=X,                             
//             CLASS=A,                                
//             REGION=0M,                              
//             TIME=120                                
//BINDEXE  EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT)   
//DBRMLIB  DD DSN=SUIMGJB.DBRMLIB.DATA,DISP=SHR         
//SYSTSPRT DD SYSOUT=*                                 
//SYSPRINT DD SYSOUT=*                                
//SYSUDUMP DD SYSOUT=*                                
//SYSOUT   DD SYSOUT=*                                
//REPORT   DD SYSOUT=*                                
//SYSIN    DD *                                       
//SYSTSIN DD *                                        
 DSN SYSTEM(DSN9)                                     
  BIND PACKAGE(XMPCOBJX) MEMBER(XMPCOBJX) -             
  ACT(REP) ISO(CS) CURRENTDATA(YES) ENCODING(EBCDIC)  
/*

Using the example in Figure 1, you now have a new COBOL collection named XMPCOBJX.*. This can be passed to z/OS Batch Runtime as the system property db2.jcc.pkList, which can be appended to the default JDBC-provided NULLID collection. On the Java command line, for example, this would be seen as follows:

-Ddb2.jcc.pkList=NULLID.*,XMPCOBJX.*

You should also grant package privileges, according to the specific security standards that are in place at your installation. Using the example in Figure 1, you would specify the following statement, where authid can be either a user ID or secondary ID, such as a RACF® (SAF) group name.

GRANT EXECUTE ON PACKAGE XMPCOBJX.* TO authid