CAF (Call Attach Facility)

Typically, a control program is created to handle the establishment and termination of the DB2 connection. It is the CAF module shown in Figure 18.30. Although this module is not required, it is recommended so that you can eliminate the repetitious coding of the tedious tasks associated with connecting, disconnecting, opening, and closing.

CAF programs must be link-edited with the CAF language interface module, DSNALI .

Thread Creation and Use

Two distinct methods for the creation of a CAF thread can be followed. In the first, shown in Figure 18.31, the application program explicitly requests a thread by using the CAF OPEN call. The application uses the CLOSE call to explicitly terminate the thread. Explicit creation of CAF threads is particularly useful for online TSO CAF programs.

As I mentioned in the TSO section, an online TSO/DB2 program can tie up a thread for a long time when the DSN command is used to attach to DB2. When users of this type of application spend time thinking about their next action, or leave their terminal in the middle of the application, a program using the TSO attach consumes an active thread.

If the program instead uses CAF to create a thread, each time the user presses Enter, the thread is terminated before the next screen appears. Although this use of DB2 resources is more effective because a thread is not consumed when no activity occurs, it is also less efficient because the overhead of thread termination and creation is added to each user action. Online TSO applications are not known for their speed, though, so fewer dormant threads in return for a slower response time might not be a bad trade-off.

The second method of thread creation is shown in Figure 18.32. This figure shows the implicit creation and termination of CAF threads. If the OPEN and CLOSE calls are not used, a thread is created when the first SQL statement is issued.

Benefits and Drawbacks of CAF

Before deciding to use CAF, you should consider all the ramifications of this decision. If used properly, CAF can enhance the performance and resource utilization of a DB2 application. If used improperly, CAF can cause problems.

One benefit of using CAF is that it provides explicit control of thread creation. In addition, CAF is more efficient than DSN because of the elimination of overhead required by the TSO TMP, IKJEFT01 (or IKJEFT1B ). Another benefit is that a program designed to use CAF can run when DB2 is down. It cannot access DB2 resources, but it can perform other tasks. This capability can be useful when the DB2 processing is optional, parameter driven, or contingent on other parts of the program.

CAF has its drawbacks too, though. For example, CAF requires more complex error handling procedures. DSN automatically formats error messages for connection failures, but CAF returns only a return code and a reason code. Another drawback is that DSN handles the connection automatically, but CAF requires the program to handle the connection. These drawbacks can be eliminated, however, if you modify the CAF interface module used at your site. Note that by modifying the CAF module your shop must support logic that otherwise is provided with DB2 (and supported by IBM).

Vendor Tools

Some vendor tools provide an interface to the Call Attach Facility. They are generally used to enable DB2 batch programs to run without the TSO TMP. By simply link-editing your DB2 program with the vendor-supplied language interface module, you can run DB2 batch programs as MVS batch programs instead of TSO batch programs. Although these tools do not usually provide the same level of flexibility as true CAF (for example, control over thread creation and termination), they are useful for eliminating the need for TSO in batch, thereby reducing overhead.

Sample CAF Code

You can use several sample CAF programs provided with DB2 as models for the development of your own CAF applications. These programs follow: