Considerations for Db2 on mainframe targets

Operational considerations for mainframe Db2

When you use High-speed Apply Engine, consider these constraints and recommendations:

• Authorization requirements

  The following libraries must be APF authorized:

  • High-speed Apply load libraries

  • Any libraries that you reference in the apply request (in the STEPLIB DD statements)

  Also, the user ID that submits the apply request must have the appropriate authorizations to run the request. For more information, see DB2 authorizations.

• Operating system requirements

  If the input source for the apply request is a data set, the data set must be present in the ICF catalog of the operating system.

  High-speed Apply Engine must be installed on the same operating system logical partition (LPAR) as the target Db2 subsystem.

• Db2 thread requirements

  The target Db2 subsystem must have enough threads available to process the apply request. Ensure that at least two threads are available, or as many threads as the initial number of agents that High-speed Apply Engine specifies. For more information about setting the initial number of agents, see InitialAgents. For more information about the maximum number of agents, see MaxAgents.

• Restart table considerations

  A new installation of High-speed Apply creates a new restart table. High-speed Apply does not migrate restart tables from previous versions. If you have an earlier version of High-speed Apply Engine installed, any restarts must be completed on the original version before switching to a new version.

  The restart table for an apply request must reside on the same Db2 subsystem as the target tables.

• LOADPLUS requirements

  If High-speed Apply Engine is called by the LOADPLUS for DB2 product, then High-speed Apply Engine must be installed on the same Db2 subsystem as LOADPLUS, and must be available through the STEPLIB, JOBLIB, or LINKLIST when LOADPLUS is executed.

Static SQL processing

To maximize performance, the High-speed Apply Engine processes SQL statements statically as much as possible, within limits set by your configuration parameters.

As it processes apply requests, High-speed Apply Engine takes the following actions:

• Generates plans or packages dynamically

• Issues Db2 BIND commands to bind the plans or packages

• Executes the statements as static SQL using the bound plans or packages. (For Db2 LUW targets on UNIX or Windows, High-speed Apply Engine binds only packages.)

If it cannot process an SQL statement statically, High-speed Apply Engine processes it with dynamic SQL or by using EXECUTE IMMEDIATE. You can configure an apply request to dynamically allocate Db2 plans or packages by specifying parameters in the [Bind] section of the configuration file.

Depending on limits that are set by the parameters in the [BindTuning] section, High-speed Apply Engine prepares and executes SQL statements dynamically as it builds database request modules (DBRMs). High-speed Apply Engine switches to static execution after the bind action occurs.

Database access for mainframe Db2

To run an apply request, the High-speed Apply Engine updates the target tables through Db2. The database can continue to run while High-speed Apply Engine performs its updates, so you can update the target tables while they are online.

The access method for Db2 is the Call Attach Facility (CAF). Because High-speed Apply Engine uses multiple connections to the database, the target Db2 subsystem must have enough threads available for the apply request (for more information, see Operational considerations for mainframe DB2). 

Db2 authorizations

To execute SQL or logical log input, the user ID that runs the High-speed Apply Engine must have the following Db2 authorizations:

• EXECUTE privilege for the plan that High-speed Apply Engine uses to access its own restart tables and the catalog (see PublicPlan).

• EXECUTE privilege for the restart package.

• Appropriate table privileges such as INSERT, UPDATE, or DELETE for the target tables (the specific privileges depend on the actions that the apply request performs)

• Appropriate privileges to bind or administer plans, packages, and collections

  High-speed Apply Engine provides several methods to grant these privileges. Some techniques avoid granting bind privileges to the user ID that runs High-speed Apply Engine. For more information, see Db2 authorizations for plans, packages, and collections.

Db2 data type support

The High-speed Apply Engine supports the same SQL data types and data type conversions as Db2.

For more information about compatible data types, consult the appropriate Db2 documentation.

DBCS support

The High-speed Apply Engine supports double-byte characters in logical log input and SQL input. High-speed Apply Engine can read logical log files that are created by BMC AMI Log Master for Db2, or an application program that conforms to the published format.

For more information about the logical log format, see the section about logical logs in the BMC AMI Log Master for Db2 technical documentation. 

Sort work data sets 

The High-speed Apply Engine sorts logical log input (subject to your control).

Under normal circumstances, you do not have to specify any sort parameters or sort work data sets. For more information, see Sort. If you want to specify sort work data sets for performance reasons or because of procedures in your environment, the DD names of sort work data sets must adhere to the following convention:

SW01WKyy

The variable yy represents the sequence number of a sort work data set. It ranges from one up to the maximum number of sort work data sets that High-speed Apply Engine requires. You can specify an exact number of data sets by using the WORKNUM parameter. For more information, see WORKNUM.