FAQ

High‑speed Apply Engine is a component distributed with several BMC solutions (including BMC AMI Log Master for Db2) that rapidly applies database changes to Db2 (z/OS) with flexible, configurable processing.

It accepts SQL statements (including those generated by Log Master or any standard SQL generator) and logical log files created by BMC AMI Log Master for Db2.

Yes, High‑speed Apply Engine can process SQL input as static SQL for Db2 mainframe target. For more information, see Static SQL processing. In addition, BMC AMI Log Master can generate a template file that can be used to efficiently process SQL input as static. For more information, see Template file TYPE. 

Yes, you can include apply requests in Db2 recovery processes to undo incorrect transactions or redo correct ones after a Db2 recovery, leveraging restart and configuration controls.

An apply request is the batch job or command that starts and runs the High‑speed Apply Engine. It can include job‑level details and override selected configuration parameters.

The workflow includes the following main steps:

• Create the input.
• Define configuration files.
• Create and run the apply request.
• (Optional) configure restart processing.

The Using section includes the high‑level task flow and links to task topics and references.

Configuration files define target database information, performance and processing options, and conflict resolution rules. You can reference multiple configuration files in one apply request and override selected values inside the apply request.

For all parameters, sections, defaults, and usage, and links to quick references by name and by section, see Command and syntax reference.

Yes, especially for Db2 on mainframe targets. You can separate concerns such as conflict rules, database‑specific information, and temporary storage options, and include multiple configuration files via DD statements referenced by the apply request.

For information about parameter sections, ordering flexibility, and defaults, see Command and syntax reference.

Add the required Restart parameters to your configuration (or specify them in the apply request), including setting RestartType to New/Restart or Restart, create a restart table, and rerun the apply request with the correct restart ID after a failure.

The restart table stores progress and state information for the apply request. On restart, the engine uses that information to resume at the failure point instead of reprocessing completed work.

You can let High‑speed Apply Engine generate a restart ID automatically or you can specify one. For information about handling initial runs, successful completion, and restarts after failure, see Restart and recovery, Restarting an apply request, Specifying and using restart parameters, and Restart parameters.

Yes, don't change the number or sequence of records between an initial run and a restart. Restart processing relies on record positions and order.

Yes, configure Agent parameters such as InitialAgents and MaxAgents to enable multi‑threaded execution. The engine dynamically uses only the number of agents required by the workload.

Use InitialAgents to define the starting number of agents and MaxAgents to cap parallelism. Consider available Db2 threads/connections and workload distribution. The engine increases agents dynamically up to MaxAgents.

Define conflict rules using AnyConflict and statement‑specific sections (InsertConflict, UpdateConflict, DeleteConflict, DDLConflict). Rules specify Code and Action pairs and can defer processing.

They control how deferred conflicts are written and managed, including file naming models, single‑file versus multi‑file behavior, and storage settings.

Use conflict rules with defer actions such as Defer, DeferStatement, or DeferUR, and configure ConflictFile parameters (for example FileNameModel and SingleFile) to capture deferred SQL or units of recovery.

Make sure that APF authorization for load libraries, sufficient Db2 threads (typically at least two or more than the number of agents), proper catalog placement, LPAR co‑location, and other environmental requirements documented for Db2 mainframe environments.

Yes, High‑speed Apply Engine supports LOADPLUS SQLAPPLY load actions. Make sure that the required subsystem access and libraries are available when High-speed Apply Engine is invoked by LOADPLUS.

It is installed automatically with several BMC solutions (including Log Master, Recovery Management, LOADPLUS, and Database Administration) and can also be installed separately by using the BMC Installation System.

Yes, the High‑speed Apply Engine home page provides access to Getting started, Using, Command and syntax, PDFs, videos, and support resources.