Making the CAF language interface (DSNALI) available

Before you can invoke the call attachment facility (CAF), you must first make DSNALI available.

About this task

Part of CAF is a Db2 load module, DSNALI, which is also known as the CAF language interface. DSNALI has the alias names DSNHLI2 and DSNWLI2. The module has five entry points: DSNALI, DSNHLI, DSNHLI2, DSNWLI, and DSNWLI2. These entry points serve the following functions:

  • Entry point DSNALI handles explicit Db2 connection service requests.
  • DSNHLI and DSNHLI2 handle SQL calls. Use DSNHLI if your application program link-edits DSNALI. Use DSNHLI2 if your application program loads DSNALI.
  • DSNWLI and DSNWLI2 handle IFI calls. Use DSNWLI if your application program link-edits DSNALI. Use DSNWLI2 if your application program loads DSNALI.

Procedure

To make DSNALI available:

  1. Decide which of the following methods you want to use to make DSNALI available:
    • Explicitly issuing LOAD requests when your program runs.

      By explicitly loading the DSNALI module, you beneficially isolate the maintenance of your application from future IBM® maintenance to the language interface. If the language interface changes, the change will probably not affect your load module.

    • Including the DSNALI module in your load module when you link-edit your program.

      If you do not need explicit calls to DSNALI for CAF functions, link-editing DSNALI into your load module has some advantages. When you include DSNALI during the link-edit, you do not need to code a dummy DSNHLI entry point in your program or specify the precompiler option ATTACH. Module DSNALI contains an entry point for DSNHLI, which is identical to DSNHLI2, and an entry point DSNWLI, which is identical to DSNWLI2.

      A disadvantage to link-editing DSNALI into your load module is that any IBM maintenance to DSNALI requires a new link-edit of your load module.

    Alternatively, if using explicit connections via CALL DSNALI, you can link-edit your program with DSNULI, the Universal Language Interface.

  2. Depending on the method that you chose in step 1, perform one of the following actions:
    • If you want to explicitly issue LOAD requests when your program runs:
      In your program, issue z/OS® LOAD service requests for entry points DSNALI and DSNHLI2. If you use IFI services, you must also load DSNWLI2. The entry point addresses that LOAD returns are saved for later use with the CALL macro. Indicate to Db2 which entry point to use in one of the following two ways:
      • Specify the precompiler option ATTACH(CAF).
        This option causes Db2 to generate calls that specify entry point DSNHLI2.
        Restriction: You cannot use this option if your application is written in Fortran.
      • Code a dummy entry point named DSNHLI within your load module.

        If you do not specify the precompiler option ATTACH, the Db2 precompiler generates calls to entry point DSNHLI for each SQL request. The precompiler does not know about and is independent of the different Db2 attachment facilities. When the calls generated by the Db2 precompiler pass control to DSNHLI, your code that corresponds to the dummy entry point must preserve the option list that was passed in R1 and specify the same option list when it calls DSNHLI2.

    • If you want to include the DSNALI module in your load module when you link-edit your program:

      Include DSNALI in your load module during a link-edit step. The module must be in a load module library, which is included either in the SYSLIB concatenation or another INCLUDE library that is defined in the linkage editor JCL. Because all language interface modules contain an entry point declaration for DSNHLI, the linkage editor JCL must contain an INCLUDE linkage editor control statement for DSNALI; for example, INCLUDE SYSLIB(DSNALI). By coding these options, you avoid inadvertently picking up the wrong language interface module.