|
Customer Question: Is it reasonable to think about having a server attachment at z/OS UNIX written in C or C++ attaching to DB2 using RRSAF or Call Attach instead of some Language Environment service or ODBC?
Answer:
Ported SQL applications come in several flavors:
- ODBC (Open Database Connectivity) or CLI (Call Level Interface) applications.
These applications are very common in the Unix/NT world. They use dynamic SQL, which doesn't perform as well as static SQL. They often run with the end user's SQL privileges, which is not what most large customers want. However, these applications have these same attributes on Unix or NT, so in many cases customers understand these things and are willing to run the ported applications as is.
-
Embedded SQL applications.
This is the more traditional "mainframe" approach to application development. Embedded SQL applications have better performance, due to static SQL processing. They can be written to use the program author's SQL privileges, instead of the end user's privileges. This is the way that existing IMS, CICS, etc., applications work.
While this approach isn't nearly as common in the NT or Unix world, you do find applications written in this fashion. When we encounter these applications, we use either CAF (Call Attach Facility) or RRSAF (Recoverable Resource Manager Services Attachment Facility) to interface between these applications and DB2. (Actually, that is also what the ODBC driver does behind the scenes).
We want people to use RRSAF to connect C or C++ programs to DB2 from the OS/390 UNIX System Services environment, because:
- DB2 has selected RRSAF as its strategic interface for S/390 UNIX and batch applications. Future enhancements will be made to RRSAF rather than Call Attach.
- RRSAF already has several technical advantages over Call Attach:
- support for 2-phase commit
- thread reuse
- end user control over accounting intervals
- Java applications
JDBC (Java Database Connectivity) is dynamic SQL, so it is similar to ODBC. We currently use our JDBC driver to support Java applications. We have an SQLJ driver to support static SQL as well. The SQLJ Part 0 support will be made available for DB2 for OS/390 via DB2 APAR PQ19814. We expect to have an APARFIX version of PQ19814 available by November 1998.
Customer Question: What about an application that has pthreads? Is DB2 threadsafe?
Answer:
Our ODBC driver was not threadsafe, but this was fixed with an APAR in 1997. Prior to the APAR, DB2 was not threadsafe because we were storing ODBC runtime information in a C global storage pool, and we did not use any type of serialization for this storage (e.g., pthread mutex support). With our APAR, we have corrected all this.
Our embedded SQL support (both static and dynamic SQL) has always been threadsafe, because we didn't use any global storage that was managed by C or LE. Instead, our global storage was obtained via GETMAIN and managed by COMPARE_AND_SWAP. With this support, each pthread can establish its own independent connection to DB2.
If you use Call Attach (CAF), a given DB2 connection must be created, accessed, and destroyed from exactly one pthread. In other words, a given connection cannot be accessed by multiple pthreads.
If you use RRS Attach (RRSAF), you can do all the things that Call Attach supports. Additionally, with APAR PQ09901 you can "move" a given DB2 connection from one pthread to another (CLI issues some special RRS calls). No changes to the CLI application are required in order to use the multi-context support. This support is enabled via a CLI Initialization file setting.
Note that for pthreads in an OS/390 UNIX application, there is no difference in static SQL support or authorization compared to any other environment, such as CICS or IMS.
|
