Multithreaded restrictions and limitations - assure_mimix - 10.0

Assure MIMIX Administrator Reference

Product type
Software
Portfolio
Integrate
Product family
Assure
Product
Assure MIMIX™ Software
Version
10.0
Language
English
Product name
Assure MIMIX
Title
Assure MIMIX Administrator Reference
Copyright
2023
First publish date
1999
ft:lastEdition
2024-05-07
ft:lastPublication
2024-05-07T13:36:02.962500

The following restrictions and limitations for multithreaded database apply processing are not checked by the conversion process. You must manually verify whether these are a concern for your environment prior to using or converting to multithreading:

  • Multithreading requires that the data groups in a resource group and their selection rules (data group entries) are configured so that the database apply process does not hold a lock on file members. The type of lock used is identified in the Lock member during apply field within File and tracking processing options (FEOPT parameter). For the data groups, the value must be Do Not Lock (*NONE), and for selection rules the value must be Default (*DGDFT). If you cannot operate your environment with these values, do not use default values to configure a new data group and do not convert existing resource groups to multithreading. For assistance with alternatives, contact your certified MIMIX representative.

  • The data groups in a resource group cannot specify the value *SYSJRN for Cooperative processing type (COOPJRN) parameter. If this value is specified, the resource group is not eligible for converting to multithreading, and its data groups and associated data group entries must first be converted to using cooperative processing via the user journal for *FILE objects. You can use the Convert Data Group (CVTDG) command or manually convert the data groups and data group entries. For more information, see Converting to default cooperative processing for files.

  • Data groups that use multithreading cannot be configured for keyed replication and cannot have any selection rules (data group entries) configured for keyed replication. Multithreading is not supported for data groups that implement techniques that require keyed replication, such as bi-directional user journal replication, file combining, and file routing.

  • In environments that implement cascading distributions and involve referential constraints, if any data group in the cascade chain is part of a resource group that uses multithreading, all subsequent downstream data groups must also be in multithreaded resource groups.

  • In environments that use MIMIX with IBM’s High Availability Journal Performance IBM i option 42 (journal standby state & journal caching), it is not possible to use the standby state on the target system when multithreading is configured. There are no restrictions with journal caching.

  • Multithreading requires that database apply processing (DBAPYPRC parameter) specify the Commit mode as Immediate (*IMMED). With immediate commit mode, at any time while entries in the commit cycle are being processed, the target node may contain partial data or extra data that would not be available in delayed (*DLY) mode. This can be a concern if you access data on the target node for more than high availability or disaster recovery, For more information about commit modes, see Processing of transactions under commitment control.

  • Multithreaded data groups use commitment control to apply record level changes on the target node. In some cases, such as when errors occur, transactions are rolled back, and some or all of the changes are re-applied by the database apply B job without using commitment control. This may be a concern if you use replicated files on the target system for other purposes.

  • Some record level operations may not be applied when two or more journal entries for the same record occur close to each other on the journal. Only the final entry will be applied. In data groups whose journal definitions specify to use Minimize entry specific data (MINENTDTA) values other than *NONE, the opportunity for multithreading database apply processing to combine multiple journal entries for the same record to a single write, update, or delete operation is reduced.

  • Assure MIMIX IBM MQ resource groups cannot be configured for or converted to use multithreaded database apply processing. The reconstruction data group requires the value 1 for the number of database apply sessions (NBRDBAPY), which is not compatible with multithreading.

  • Data groups that use multithreading cannot specify a recovery window, which is part of the MIMIX CDP feature. (This is checked by the conversion process.)

  • Data groups that use multithreading cannot have database apply user exit programs. (This is checked by the conversion process.)