Limited supportBMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support.BMC recommends upgrading to the latest version of the product. To see documentation for that version, see High-speed Apply Engine 13.1.

Creating conflict resolution rules


You can add conflict resolution rules to the configuration to respond to SQL codes that occur during an apply request. Use the procedures in this section to help you define rules that are appropriate for your environment and your input data.

The following figure shows the relationships described in this procedure.

GUID-8B52B924-3262-443A-BBB5-5B94443D8939-low.png

Before you begin

For more information about the parameters mentioned in these procedures, see Command-and-syntax-reference. For more information about the valid SQL code types and action types, see Conflict-resolution.

This procedure contains the following basic activities:

  • To define the actual conflict resolution rules, define sets of Code and Action parameters in the conflict sections. The following conflict sections are based on the type of SQL statement that generates a conflict:
    • [AnyConflict]
    • [InsertConflict]
    • [UpdateConflict]
    • [DeleteConflict]
    • [DDLConflict]
  • (optional) You can define general processing options for all conflict resolutions rules in the [Conflict] section. (If you do not explicitly define the parameters in this section, High-speed Apply Engine uses default values.)
  • (optional) If any of your conflict resolution rules specify an Action parameter with a value of Defer, DeferStatement, or DeferUR, you can define parameters for the conflict file (or files) where High-speed Apply Engine writes the deferred output. (If you do not explicitly define the parameters in this section, High-speed Apply Engine uses default values.)

To define conflict resolution rules

  1. To define conflict resolution rules, add your desired conflict section (or sections) to the configuration file:
    • The [AnyConflict] section describes how High-speed Apply Engine handles conflicts for any SQL statement type in the apply request.
    • The other conflict sections specify how High-speed Apply Engine handles conflicts for their respective statement types. The values you specify in these sections override the values in the [AnyConflict] section. The other conflict sections include:
      • [InsertConflict]
      • [UpdateConflict]
      • [DeleteConflict]
      • [DDLConflict]
  2. Specify a Code parameter to define a conflict type (for example, NoRows).Code parameters define the conflict that High-speed Apply Engine responds to. The SQL code that you specify must be valid for the target database. For more information about the supported code values, see Codes-for-conflict-resolution-SQL-codes.
  3. Specify one or more Actions for the Code you specified in Step 2.Action parameters define the response of High-speed Apply Engine when an SQL statement encounters the SQL code or message number defined by a Code parameter. The actions that you specify must be valid in the order that they appear in the configuration file. Some Code values have default actions associated with them. For more information about the valid actions and the default actions for each code, see Actions for conflict resolution.
  4. Repeat Step 2 and Step 3 to create as many conflict resolution rules as you need in a single conflict section.
  5. Repeat Step 2 and Step 4 to create as many conflict sections as you need to process the apply request.
  6. Save the configuration file.

To define the [Conflict] section

The [Conflict] section contains general processing options for conflict resolution. For more information, see Conflict-parameters. This section is optional. If you do not include the [Conflict] section, the High-speed Apply Engine uses the default values for the parameters in the following steps:

  1. Create or edit a configuration file as described in Creating or editing a configuration file.
  2. Add the [Conflict] section to the configuration file.
  3. Specify the RetryLimit parameter to indicate how High-speed Apply Engine keeps track of the retry attempts that are defined by the RetryValue parameter, as follows:
    • Time indicates that High-speed Apply Engine retries the conflict resolution rules as many times as necessary until it reaches the number of seconds that is specified by the RetryValue parameter.
    • Count indicates that High-speed Apply Engine retries the conflict resolution rules until it reaches the number of attempts that is specified by the RetryValue parameter. Count is the default value.
  4. Specify the RetryValue parameter to define a number of seconds or a number of attempts for the apply request.The default RetryValue is five. If you specify RetryLimit as Time, consider specifying a larger RetryValue.
  5. Specify the RetryFail parameter to indicate the action that High-speed Apply Engine takes after all retry attempts do not resolve the conflict.The valid values for RetryFail are as follows:
    • Abort rolls back the current unit of work before ending apply processing. Abort is the default value.
    • Defer writes the SQL statement that generated the conflict type to the conflict file. Processing continues with the next unprocessed statement.
    • Skip skips the SQL statement that generated the conflict. Processing continues with the next unprocessed statement.
    • Terminate commits the current unit of work before ending apply processing.
  6. Specify the MaxFailedRetries parameter to indicate the maximum number of failed retries the High-speed Apply Engine allows. The default value is 5.
  7. Specify the MaxRetryFail parameter to indicate what action the High-speed Apply Engine takes when MaxFailedRetries is exceeded. The default value is Abort.
  8. Save the configuration file.

To define the [ConflictFile] section for output to file

If any of your conflict resolution rules specify an action of Defer, DeferStatement, or DeferUR, you can define parameters for the conflict file (or files) where the High-speed Apply Engine writes the deferred output. (This section is optional, High-speed Apply Engine uses default values if you do not explicitly define the parameters in this section.) To specify that deferred-conflict output be written to a file, proceed with the following steps:

  1. Add the [ConflictFile] section name to the configuration file.The [ConflictFile] section contains file name and allocation information for the deferred conflict files. For more information, see ConflictFile-parameters.
  2. Specify the FileNameModel parameter that High-speed Apply Engine uses to name the conflict files.The FileNameModel parameter accepts variables and text constants that High-speed Apply Engine uses to dynamically create a name for one or more conflict files. The model that you specify must resolve to a unique name for each file that High-speed Apply Engine creates. For more information about this parameter, see FileNameModel.
  3. Specify the SingleFile parameter to indicate whether High-speed Apply Engine creates one conflict file for an apply request or a conflict file for each active agent:

    • Yes creates a single deferred-conflict file for the entire apply request.
    • No creates a deferred-conflict file for each agent that processes the apply request.

    For more information about the SingleFile parameter, see SingleFile.

  4. For DB2 mainframe targets only, specify the DISP parameter and allocation parameters for the conflict files:

    1. Specify the DISP parameter to indicate the disposition for the conflict files:
      • OLD if the data is not shared.
      • SHR if the data set exists and is shared.
      • NEW (default) if the data set is new. High-speed Apply Engine creates a new data set each time it processes the apply request.
    2. Specify the allocation parameters for the conflict files:
    • If you want to use DFSMS to manage your data sets, you can specify the DATACLAS, STORCLAS, or MGMTCLAS parameters to define the data set allocation requirements for the conflict files.
    • If you have already created a conflict file, you can use the LIKE parameter to define the data set allocation for additional conflict files.
    • Otherwise, you can specify the UNIT and VOLSER parameters to define the data set allocation requirements for the conflict files.
  5. Save the configuration file.

If you receive error messages about the object names specified in any of the conflict resolution sections, check the configuration file for the following common problems:

  • Verify that the [ConflictFile] parameters create appropriate file names, and that the files can be allocated as defined.
  • Verify that the conflict resolution rules can be performed in the order that you specified them. For example, if an Abort action is specified before a DeferStatement action, the DeferStatement action will never be reached.

Related topic

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*