CAF (Call Attach Facility)

 <  Day Day Up  >  

The next "door to DB2" is provided by the CAF, or Call Attach Facility. CAF differs from the previous attach mechanisms in that it does not provide teleprocessing services. CAF is used to manage connections between DB2 and batch and online TSO application programs, without the overhead of the TSO terminal monitor program.

CAF programs can be executed as one of the following:

  • An MVS batch job

  • A started task

  • A TSO batch job

  • An online TSO application

CAF is used to control a program's connection to DB2, as shown in Figure 18.30. The DB2 program communicates to DB2 through the CAF language interface, DSNALI . The primary benefit of using CAF is that the application can control the connection with CAF calls. Five CAF calls are used to control the connection:

Figure 18.30. The Call Attach Facility.

graphics/18fig30.gif


CONNECT

Establishes a connection between the program's MVS address space and DB2

DISCONNECT

Eliminates the connection between the MVS address space and DB2

OPEN

Establishes a thread for the program to communicate with DB2

CLOSE

Terminates the thread

TRANSLATE

Provides the program with DB2 error message information, placing it in the SQLCA


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.

Figure 18.31. Explicit CAF thread creation.

graphics/18fig31.gif


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.

Figure 18.32. Implicit CAF thread creation.

graphics/18fig32.gif


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:

DSN8CA

Assembler interface to CAF

DSN8SPM

CAF connection manager for ISPF

DSN8SP3

PL/I program that interfaces with CAF

DSN8SC2

COBOL program that interfaces with CAF


 <  Day Day Up  >  


DB2 Developers Guide
DB2 Developers Guide (5th Edition)
ISBN: 0672326132
EAN: 2147483647
Year: 2004
Pages: 388

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net