Effects of distributed data on program preparation
In a distributed data environment, several items affect precompile and bind options that are used for DRDA access and package resolution.
The following table lists the z/OS® precompiler options that are relevant to preparing a package that is to be run using DRDA access.
| z/OS precompiler options | Usage |
|---|---|
| CONNECT | Use CONNECT(2) to allow your application program to make updates at more than one DBMS. |
| SQL | Use SQL(ALL) for binding a package to a non-z/OS server; otherwise, use SQL(DB2®). |
Usually, binding a package to run at a remote location is like binding a package to run at your local DB2 subsystem. Binding a plan to run the package is like binding any other plan. The following table gives you guidelines for which z/OS bind options to choose when binding a package and planning to run using DRDA access.
| z/OS bind options | Usage |
|---|---|
| DEFER(PREPARE) | For dynamic SQL, use DEFER(PREPARE) to send PREPARE and EXECUTE statements together over the network to improve performance. |
| SQLERROR | Use SQLERROR(CONTINUE) to create a package even if the bind process finds SQL errors. |
| SQLRULES | Use SQLRULES(DB2) for more flexibility in coding your applications, particularly for LOB data, and to improve performance. |
JDBC, SQLJ, and ODBC use different methods for binding packages that involve less preparation for accessing a z/OS server.
The CURRENT PACKAGE PATH special register provides a benefit for applications that use DRDA from a z/OS requester. The package collection ID is resolved at the server. Applications on the server can take advantage of the list of collections, and network traffic is minimal.
SET CURRENT PACKAGE PATH = SCHEMA1, SCHEMA2, SCHEMA3, SCHEMA4, SCHEMA5;