Using the Product in a DB2 Environment › Background DB2 Catalog Extraction › Synchronous Data Gatherer › Harvester Exits

Harvester Exits

The Synchronous Data Gatherer uses Harvester exits to collect data from DB2. Each exit has an arbitrary name that bears no relationship to its purpose. Currently, DB2 has three exits defined. They are DB2E1, DB2E2, and DB2E3.

• DB2E1 harvests data from most SQL calls to DB2 with the major exception being COMMIT.
• DB2E2 harvests data from COMMIT calls only.
• DB2E3 combines the DB2E1 and DB2E2 into a single exit for managing purposes.

Exits are started by calling a command processor specifying the name of the target DB2 subsystem and the name of the exit to start. The command processor can be called when the server starts or when a monitor session discovers processing in a DB2 address space. Once started, an exit is active until a stop command is issued or the server is shut down. If more than one server has active exits, any exit that is shared by multiple servers will remain active until the last server has issued a stop command for that exit.

In order to start the harvesting process when a monitor session discovers processing in DB2, CA Mainframe Application Tuner must know the name of the exit. The exit name is supplied in the TUNSSP00 member with the DB2HVEXT command. Any start command issued by the monitoring session will specify this exit.

Exits can also be started when the server is started. A command in the TUNSSP00 member can be used to list the DB2 subsystems to which the start command should be issued. There is a command for each exit currently defined for DB2.

DB2HVEXT

Exit name.

Specify the name of the exit to be used when a Harvester is started during a monitor session.

The following are valid values:

• DB2E1 — harvest non-COMMIT SQL calls to DB2
  (see also DB2HVSE1 below)
• DB2E2 — harvest only COMMIT calls to DB2
  (see also DB2HVSE2 below)
• DB2E3 — harvest both COMMIT and other SQL calls to DB2
  (see also DB2HVSE3 below)

Recommendation:

• Use the default parameter, DB2E3, to collect the most complete data.
• When using the default, you should also review DB2HVSE3 to define the DB2 subsystems where you would like CA Mainframe Application Tuner to implant the DB2 Harvester during startup processing.

The default is DB2HVEXT=DB2E3.

DB2HVSE1

Plant DB2 Harvester exit DB2E1 at server start.

Use this parameter to avoid losing some data related to the first call to DB2. This parameter allows the Server initialization process to implement the Harvester exit during startup.

Specify a list up to 12 DB2 subsystems that a Harvester START command can issue for the DB2E1 exit.

The format is DB2HVSE1=ssid,ssid,ssid,...

This parameter should only be used when DB2HVEXT=DB2E1 is specified.

There is no default.

DB2HVSE2

Plant DB2 Harvester exit DB2E2 at server start.

Use this parameter to avoid losing some data related to the first call to DB2. This parameter allows the Server initialization process to implement the Harvester exit during startup.

Specify a list up to 12 DB2 subsystems that a Harvester START command can issue for the DB2E2 exit.

The format is DB2HVSE2=ssid,ssid,ssid,...

This parameter should only be used when DB2HVEXT=DB2E2 is specified.

There is no default.

DB2HVSE3

Plant DB2 Harvester exit DB2E3 at server start.

Use this parameter to avoid losing some data related to the first call to DB2. This parameter allows the Server initialization process to implement the Harvester exit during startup.

Specify a list up to 12 DB2 subsystems that a Harvester START command can issue for the DB2E3 exit

The format is DB2HVSE3=ssid,ssid,ssid,...

This parameter should only be used when DB2HVEXT=DB2E3 is specified.
Note: DB2HVEXT=DB2E3 is the default.

There is no default.

Using DB2E1 and DB2E2 together as opposed to DB2E3, allows the flexibility of stopping one exit without affecting the other. For example, in a transaction environment such as CICS, COMMITs are generated by the DB2 subsystem when a transaction reaches a synchronization point. This situation can generate more information than is useful. To fix this problem, the COMMIT exit can be stopped or not started without affecting the harvesting of other SQL calls.