Considerations for LF and PF files - 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

In new data groups that use shipped default values, any logical files and physical (source and data) files properly identified for cooperative processing will be processed using default cooperative processing, which occurs primarily through the user journal, unless a known restriction prevents it.

When a data group definition does not meet the requirements for default cooperative processing of files but still meets legacy cooperative processing requirements (listed in Table 16), any PF-DTA or PF38-DTA files properly configured for cooperative processing will be replicated using legacy cooperative processing. All other types of files are processed using system journal replication.

Data groups that currently specify the system journal (*SYSJRN) for the cooperative journal (COOPJRN) must use a conversion process to change from legacy cooperative processing to default cooperative processing. Furthermore, the conversion to default cooperative processing must be performed before the data group can be converted to use multithreaded database apply processing. For more information, see:

Logical file considerations - Consider the following for logical files.

  • Logical files are replicated through the user journal when shipped defaults are used on the commands to create data groups and data group entries. If the data group is configured for journal-centric replication of *FILE objects, logical files are replicated through the user journal. When the data group is configured to support legacy cooperative processing (Cooperative journal (COOPJRN) specifies *SYSJRN), logical files are replicated through the system journal.

  •  It is strongly recommended that logical files reside in the same data group as all of their associated physical files.

Physical file considerations - Consider the following for physical files

  • Physical files (source and data) are replicated through the user journal when shipped defaults are used on the commands to create data groups and data group entries. If the data group is configured for journal-centric replication of *FILE objects, physical files are replicated through the user journal. When the data group is configured to support legacy cooperative processing (Cooperative journal (COOPJRN) specifies *SYSJRN), data files are replicated using legacy cooperative processing if those requirements are met, and source files are replicated through the system journal.

  • Name mapping is not supported for physical files with associated logical files.

  • If a data group definition specifies TYPE(*DB), COOPJRN(*USRJRN), and the data group object entry uses shipped default values, source physical files need to be identified by both data group object entries and data group file entries.

  • If a data group is configured for only user journal replication (TYPE is *DB) and does not meet other configuration requirements for default cooperative processing in Table 16, source physical files should be identified by only data group file entries.

  • If a data group is configured for only system replication (TYPE is *OBJ), any source files should be identified by only data group object entries. Any data group object entries configured for cooperative processing will be replicated through the system journal and should not have any corresponding data group file entries.

  • Physical files with referential constraints require a field in another physical file to be valid. The data group configuration affects how files in a referential constraint network are processed. For more information, see Target constraint management.

Commitment control - This database technique allows multiple updates to one or more files to be considered as a single transaction. MIMIX supports two modes of processing transactions that are part of a commit cycle, immediate and delayed, which are described in Processing of transactions under commitment control.

For files under commitment control, consider the following:

  • If your application dynamically creates database files that are subsequently used in a commitment control environment, the files should be configured to use default cooperative processing.

  • If legacy cooperative processing is used, replication of the create operation may fail if a commit cycle is open when MIMIX tries to save the file. The save operation will be delayed and may fail if the file being saved has uncommitted transactions.