Mimix 9.0.02.00 PDF

Read This First
MIMIX®
Version 9.0 Service Pack 9.0.02.00
MIMIX version 9.0.02.00 includes all relevant changes to earlier level 9.0 service packs, 8.1.24.00, and
earlier levels of version 8.1.
Prerequisites:
• The minimum level required for the IBM i operating system is IBM i 7.1.
• Upgrades to MIMIX version 9.0 require version 9.0 license keys and are supported from any MIMIX
version 8.1 service pack (8.1.01.00 or higher).
• MIMIX portal application version 9.0.02.00 is the minimum version required to manage MIMIX
9.0.02.00 instances and later.
• MIMIX portal application version 9.0.02.00 requires VSP version 3.2.02.00 or higher.
Supported installation processes

This document supports:
• Installing or upgrading the product, its portal application, and VSP on systems running IBM i using
the MIMIX Installation wizard for IBM i. The wizard is recommended and supports standard and
custom install options.
• Pre- and post-install instructions for installing the product using native user interface command
processes. Actual install instructions can be found in the Using License Manager book.
To see requirements for using the wizard, click the More Info link from the wizard’s Welcome panel.
Note: The MIMIX portal application requires VSP 3.2, which is installed by the MIMIX Installation
Wizard. The first time you install VSP version 3.2 on a system, you must also upgrade portal
applications for any other products to a level compatible with VSP 3.2. If you cannot upgrade a
product’s portal application, you may need to install a separate VSP server. For more
information, see “VSP 3.2 compatibility with product portal applications” on page 2.
Action required
This document provides service pack installation instructions for all supported installation media.
Required Document Section
“Before installing the service pack” on page 6
“Installing the service pack on IBM Power Systems” on page 10
“After installing the service pack instructions” on page 13
Important changes
Before you install this service pack, you should be aware that it includes changes that may affect the
behavior of your MIMIX and VSP environments. Check the Before Installing and After Installing sections
for potential configuration changes.
To see a list of the behavior changes and enhancements included, see “Features in MIMIX version 9.0”
on page 4.
MIMIX and Vision Solutions are registered trademarks and iOptimize, MIMIX Availability, MIMIX Enterprise, MIMIX Global, and
MIMIX Professional are trademarks of Vision Solutions, Inc. Syncsort is a registered trademark of Syncsort Incorporated. AIX,
AS/400, DB2, eServer, i5/OS, IBM, iSeries, OS/400, Power, PowerHA System i, and WebSphere are trademarks of International
Business Machines Corporation. All other trademarks are the property of their respective owners.
9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 1

To see a list of fixes included with this service pack, see “Fixes included in service pack 9.0.02.00” on
page 18.
VSP 3.2 compatibility with product portal applications

VSP version 3.2 and the MIMIX 9.0 portal application are required to access instances running on MIMIX
version 9.0. VSP 3.2 is included with this service pack. If you use default options in the installation
wizard for the product, the wizard also automatically installs or upgrades VSP and deploys the product
portal application on all systems in the installation.
The first time VSP version 3.2 is installed on a system, you must upgrade any other portal applications
on the same system to a level that is compatible with VSP version 3.2. Table 1 lists compatible portal
applications. Portal applications that cannot be upgraded to meet the compatibility requirements with
VSP 3.2 will require maintaining an additional VSP server that remains at version 3.0 or 3.1.
VSP and portal applications for MIMIX and iOptimize can be upgraded without having to upgrade their
associated products on the IBM i platform.
Note: Product portal applications can connect to and manage multiple instances of their products.
The product instances to which some of the product portal applications connect may be at
different versions. For example, a MIMIX 9.0 portal application can be used to connect to and
manage MIMIX 9.0 and MIMIX 8.1 instances. For more information, see the VSP User’s
Guide.
Action required:
• Ensure that all product portal applications are at a compatible version for the version of VSP included
with this service pack. See Table 1. You can use a product’s installation wizard and select the “portal
application” option to upgrade a portal application.
• Customers who cannot upgrade to VSP 3.2 (and compatible versions of portal applications) will not
be able manage product instances at compatible levels from VSP.
• If all deployed portal applications cannot be updated to a version compatible with VSP 3.2, then you
may need to maintain multiple VSP servers. The older VSP server must be used to support the older
portal applications. The older VSP server may not be able to connect to or properly manage product
instances running versions that are compatible with VSP 3.2 and its related portal application.
• If you use VSP on a Windows server, be aware of the following:
– A VSP server on a Windows platform that does not support 64-bit applications cannot be
upgraded to VSP 3.2. If you are using the MIMIX or iOptimize portal applications on this server,
install VSP 3.2 and its compatible portal applications on a supported Windows platform.
– If you are using MIMIX or iOptimize portal applications with VSP on a Windows server and also
have either the Double-Take for AIX 5.0 or the MIMIX for AIX 5.1 portal application installed, you
must maintain two VSP servers. You need a VSP 3.2 server to support MIMIX 9.0 or iOptimize
9.0 and an older server to support the AIX portal application. The Double-Take for AIX 5.0 portal
application is supported only on VSP 3.0. The MIMIX for AIX 5.1 portal application is supported
only on VSP 3.1 and is the replacement for the earlier Double-Take for AIX portal application.
– The MIMIX for AIX 5.2 portal application is only supported on VSP 3.2 and replaces the earlier
Double-Take for AIX portal application.
– For more information about requirements for installing VSP 3.2 on a Windows server, see the
More Info document for the VSP 3.2 & Portal Application Installation Wizard for Windows®.

Table 1. Compatibility of supported product portal applications and VSP.
Product VSP server VSP server VSP server

Portal Application version 3.2 version 3.1 version 3.0
MIMIX 9.0
MIMIX 8.1 8.1.11.00 and higher Only 8.1.01.00 through 8.1.10.00
8.1.10.00 and earlier
iOptimize 9.0
iOptimize 8.1 8.1.11.00 and higher Only 8.1.01.00 through 8.1.10.00
8.1.10.00 and earlier
MIMIX for AIX 5.2
MIMIX for AIX 5.1
Double-Take for AIX 5.0
VSP supports the indicated versions of AIX portal applications only on AIX or Windows platforms.

Features in MIMIX version 9.0
The following is a cumulative list of all behavior changes and enhancements released in version 9.0,
since inception. The list is sorted alphabetically.
Enhancements and Behavior Changes

Application groups required for new default data groups . . . . . . . . . . . . . . . . . . . . .31
Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Audit recovery actions now automatically submitted . . . . . . . . . . . . . . . . . . . . .44
Auditing best practices improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Auditing improvements for permissions and masks (RCAC) . . . . . . . . . . . . . . .48
Auditing improvements for temporal tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Auditing policy changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Audits with differences no longer considered action required . . . . . . . . . . . . . . .45
Automatic recoveries for File Member Record Counts (#MBRRCDCNT) audit .40
Changes to audit status check in the conditions that end switch . . . . . . . . . . . .46
Changes to Ending an audit and Ended status . . . . . . . . . . . . . . . . . . . . . . . . . .46
Changes to priority-based auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Changes to subscription events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Optionally override auditing policies when submitting manually . . . . . . . . . . . . .43
Changes to automatic job restart and cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Changes to automatic recovery reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Failed audit recoveries included in replication error counts . . . . . . . . . . . . . . . .38
Recovery status added for file, IFS tracking, and object tracking activities . . . .37
CHKMMXRCV checks whether receiver can be deleted . . . . . . . . . . . . . . . . . . . . .63
Configuration changes to support best practices and multithreading . . . . . . . . . . . .30
Application groups required for new default data groups . . . . . . . . . . . . . . . . . .31
Defaults changed for data groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
New default and changes to Target constraint management (DBAPYPRC) . . .34
New default for Commit mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
New default for Cooperative journal (COOPJRN) . . . . . . . . . . . . . . . . . . . . . . . .33
New default for Lock member during apply (FEOPT) . . . . . . . . . . . . . . . . . . . . .34
New default for Number of DB apply sessions (NBRDBAPY) . . . . . . . . . . . . . .33
Selection Rule (data group entry) changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Converting selection rules between include and exclude . . . . . . . . . . . . . . . . . . . . .64
Ignoring attribute differences in distributed environments . . . . . . . . . . . . . . . . . . . .56
Improved support for spooled files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Auditing and comparing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Configuration changes for replicating spooled files . . . . . . . . . . . . . . . . . . . . . .52
Libraries (#OBJATR) audit now supports auditing of spooled files . . . . . . . . . . .54
Replication of spooled files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Spooled file problem detection and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Java 8 supported for product install wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Journal analysis improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Changes to unplanned switch SWTUNPLAN procedure . . . . . . . . . . . . . . . . . .61
Journal Analysis interface changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Policy changes due to unplanned application group switch . . . . . . . . . . . . . . . .62
Replication prevented following unplanned application group switch . . . . . . . . .61
Minimum supported O/S version is now V7R1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Mobile support-VSP interfaces responsive on smaller devices . . . . . . . . . . . . . . . .19

Multi-object selection for manual corrections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Multithreaded database apply processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Configuration changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Conversion between single-threaded and multithreaded . . . . . . . . . . . . . . . . . .27
Copy data group (CPYDGDFN) changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Database apply sessions configurable for single-threaded or multithreaded . . .32
Delete Application Group dialog, Delete Resource Group dialog changes . . . .36
Multithreading configured indicators in VSP . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Operation and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Outfile and Retrieve command changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Subscription event changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
New Replication Environment portlet on redesigned Summary Page . . . . . . . . . . .19
Object Correction Activity window improvements . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Automatic recoveries from audits now included . . . . . . . . . . . . . . . . . . . . . . . . .37
Failed recoveries also reported in Data Group Details and Activities portlet . . .37
Manual recovery actions added for failed recoveries . . . . . . . . . . . . . . . . . . . . .37
Object Status Send Process status now provided in additional status interfaces . . .65
Obsolete functionality removed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
Product portal application compatibility with VSP 3.2 . . . . . . . . . . . . . . . . . . . . . . . . .2
Replicating jobs associated with *JOBQ objects . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Configuration changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
Replicated job indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Switch procedure changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
VSP supports enhanced DDM authentication method on IBM i . . . . . . . . . . . . . . . .63
To see a list of fixes included with this service pack, see “Fixes included in service pack 9.0.02.00” on
page 18.
Superseded
This service pack includes the contents of the following superseded service packs. If you do not already
have the following service packs installed, their contents are also installed when you install service pack
9.0.02.00. To see highlights and additional fixes for a superseded service pack, click on the link.
There are no superseded service packs.
9.0.01.00 - Highlights and fixes

Installation Instructions
Before installing the service pack
If you run iOptimize™ on systems or LPARs in your MIMIX installation, we strongly recommend that you
upgrade iOptimize at the same time as your MIMIX upgrade. Refer to Table 1 on page 3 for compatibility
requirements.
Note: MIMIX and iOptimize service pack cycles are coordinated for concurrent release. When there are
no fixes for iOptimize for a service pack, there will be no iOptimize product download posted for
that release level. iOptimize service packs will continue to be numbered to correspond with the
MIMIX service pack releases.
Step 1 through Step 9 identify areas that may require modifications to your MIMIX environment before
you install the service pack.
1. It is strongly recommended that you apply the latest IBM PTFs associated with IBM i releases as
they pertain to your environment. The Check IBM PTF (CHKIBMPTF) command is available as a
downloadable stream file from Knowledgebase article 45894. It is also included in License Manager
when the service pack is installed. You only need to download the separate stream file if you want to
check the latest PTFs before installing. Instructions for downloading and using the command are
also included in the article. The knowledgebase article lists all of the recommended PTFs for each
IBM i release for which Syncsort supports products and replaces the recommended PTF list
previously available from Support Central. The article and command are updated regularly with the
latest information.
The CHKIBMPTF command runs on a single system and checks it for the Syncsort-recommended
PTFs. Run the command on all systems where you have installed or plan to install a supported
version of MIMIX, iOptimize, or iTERA. The command generates two QPRINT outputs. One output
file lists the status of only the PTFs that require attention or corrective action. The other output file
lists all the recommended PTFs and their status on the system. You can use the release-specific
PTF list in the knowledgebase article to link to PTF cover letters for additional details about a PTF.
• To check PTFs before installing the service pack, download the command from the
knowledgebase article and follow the instructions in the article to run the command.
• To check PTFs after installing the service pack, use the command LAKEVIEW/CHKIBMPTF.
Resolve any issues found.
2. When upgrading from MIMIX version 8.1 to version 9.0, several old and seldom used functions are
removed. For most of these functions, MIMIX automatically changes the configuration so that the
new version operates without the need for any manual changes. However, if the MIMIX installation is
configured to use any of the functions listed in Table 1, manual configuration changes are required
before the installation can be upgraded to version 9.0.
The CHKDLTFCN tool is available for checking the MIMIX 8.1 installation configuration to determine
whether changes are needed prior to upgrading. The tool is available as a command in service
packs 8.1.21.00 and higher. The tool and instructions for using it are also available as a
downloadable stream file available in Knowledgebase article 52230.
For each item listed in Table 1 that is found in the configuration, a diagnostic message is issued that
identifies the item and the required corrective action to take prior to performing the upgrade.
At the end of processing, if no deleted functions are found in the installation, message LVI0902 is
issued. If any of the deleted functions are found, message LVE3817 is issued, as well as a message
for each deleted item found in the configuration.
IMPORTANT: Any identified obsolete functions found in the installation must be addressed prior to
installing MIMIX version 9.0. The tool is also run automatically as part of the upgrade process and

will fail the upgrade if any of the obsolete configuration elements still exist.
Table 1. Deleted functionality checked by the CHKDLTFCN tool.
Item checked Description Message ID issued if

found in installation
SNA/OPTI Checks whether the installation has an SNA LVE3812

or OPTI transfer definition.
Data area polling Checks the installation for Data Area Poller LVE3813
entries.
File alias naming Checks installation for file alias naming LVE3814
entries.
SM517A/SM900A Checks for hardware switch types of LVE3815

SM571A and SM900A.
MCDISABLEDG Checks extended policy MCDISABLEDG for LVE3816

values of zero.
3. Move any user-created objects or programs in libraries LAKEVIEW, MIMIXQGPL, or VSI001LIB or

in the IFS location /visionsolutions/http/vsisvr to a different location before installing this
service pack. Any user-created objects or programs, including programs created as part of MIMIX
Model Switch Framework, in these locations will be deleted during the installation process. Job
descriptions, such as the job description used by the MIMIX Port job, can continue to be placed into
the MIMIXQGPL library.
4. Ensure that only user-created objects or programs related to a product installation exist within the
product’s installation library or a data library. Examples of related objects for MIMIX products include
user-created step programs, user exit programs, and programs created as part of a MIMIX Model
Switch Framework implementation.
5. If you run other products that use the same journals on the same systems as MIMIX, such as
MIMIX® Share™, iOptimize™, or MIMIX® Director™, there may be considerations for journal receiver
management. For details, see “Interaction with other products that manage receivers” in the MIMIX
Administrator Reference book.
6. Certain types of information must not be replicated. Check and change your configuration if
necessary so that the following information is not replicated:
Table 2. Data to exclude from MIMIX replication
Data Category Type Do Not Replicate
Application Temporary objects or files You may not need to replicate temporary files, work
Environment files, and temporary objects, including DLOs and
stream files. Evaluate how your applications use such
files to determine if they need to be replicated.
System Libraries IBM-supplied libraries, files, and other objects for

Environment System i, which typically begin with the prefix Q.
User profiles System user profiles, such as QSYSOPR and

QSECOFR

Table 2. Data to exclude from MIMIX replication (Continued)
MIMIX Libraries LAKEVIEW

Environment (and contents) MIMIXQGPL
MIMIX product installation libraries
MIMIX data libraries - for example, mimix_0 and
mimix_1.
MXIWIZ*
#MXJRN* (MIMIX journal libraries)
VSI001LIB
Note: MIMIX is the default name for the MIMIX installation
library -- the library in which MIMIX Enterprise or
MIMIX Professional is installed. MIMIX data libraries
are associated with a MIMIX installation library and
have names in the format installation-library-
name_x, where x is a letter or number.
IFS directories /LakeviewTech

(and contents) /VISIONSOLUTIONS
/VisionISOImages
User profiles and LAKEVIEW

corresponding message MIMIXOWN
queues MIMIXCLU
iOptimize If iOptimize is installed on the same system or in the same partition as MIMIX, do not
Environment replicate the following:
Libraries IOPT
(and contents) IOPT71
IOPTSPLARC
IOPTOBJARC
Note: IOPT is the default name for the iOptimize
installation library -- the library in which iOptimize is
installed. iOptimize data libraries are associated with
an iOptimize installation library and begin with the
default name.
Authorization lists IOAUTLST72

IOAUTLST71
User profiles IOPTOWNER

and corresponding message ITIDGUI
queues VSI001LIB
Device description VSINSVRT
IFS directories /VISIONSOLUTIONS

(and contents) /VisionISOImages

Table 2. Data to exclude from MIMIX replication (Continued)
MIMIX Director For MIMIX Director, 8n is the release level. For example, n=1 in release 8.1. If MIMIX
Environment Director is installed on the same system or in the same partition as MIMIX, do not
replicate the following:
Libraries (and contents) ITID8n

IDSPLARC8n
IDOBJARC8n
Authorization lists IDAUTLST8n
User profiles and ITIDOWNER

corresponding message ITIDGUI
queues VSI001LIB
Device description VSINSVRT
IFS directories /VISIONSOLUTIONS

(and contents) /VisionISOImages
7. Library QTEMP cannot be in the system portion of the library list. Use this command to access
options to display and change the list:
WRKSYSVAL SYSVAL(QSYSLIBL)
Note: MIMIX requires other system value settings for operation, and will change some system
values to required values. This may include system values that affect system security and
can occur when MIMIX is started following software installation. For more information, see
the More Info document for the MIMIX Installation Wizard or the MIMIX Administrator
Reference book.
8. Review Technical Alerts, which can be found at Support Central in the Notifications section of the
Support page.
9. If required, perform the following actions, before installing, that are necessary for your environment.
The actions are listed below by service pack. It is necessary to perform any special instructions
provided for 9.0.02.00, as well as the following actions for service packs that are not yet installed.
(You can skip actions for service packs already installed on your systems.)
9.0.01.00
Check for IBM PTFs required for multithreaded database apply processing . . . . . .25
Ensure product portal applications are compatible with VSP when installing . . . . . . .2
Ensure that Java requirements for installing and runtime are met . . . . . . . . . . . . . .66
Ensure that systems are running IBM i 7.1 or higher . . . . . . . . . . . . . . . . . . . . . . . .66
Upgrades to 9.0 may need to address obsolete configuration . . . . . . . . . . . . . . . . .67
IMPORTANT: When preparing to upgrade to version 9.0, do not make changes to your configuration
between when you shut down MIMIX and when you start the upgrade process. Any changes made
between shut down and starting the upgrade will be lost.

Installing the service pack on IBM Power Systems
MIMIX Installation Wizard strongly recommended
The wizard provides a simple method for downloading, distributing, and installing version 9.0 products
on a single IBM Power™ System or on multiple Power Systems simultaneously. The wizard supports a
standard option which streamlines the installation process, and a custom option which provides more
control for more complex environments. The wizard also uses Vision AutoValidate™ to automatically
obtain and apply license keys and installs (or upgrades, when needed) the VSP server and the MIMIX
portal application. If you select to not shut down VSP when upgrading, updates to the server are not
installed and the latest version of the MIMIX portal application is not made available for use.
The MIMIX Installation Wizard does not support installing into a library located on an independent ASP.
To see requirements for using the wizard, click the More Info link from the wizard’s Welcome panel or
access the More Info PDF from Support Central.
If you cannot use the MIMIX Installation Wizard in your environment, do the following:
1. Download the streamfile for the service pack.
2. Use instructions in the Using License Manager book to end the existing MIMIX environment
and to install or upgrade command-based processes from the native user interface.
The native user interface processes do not install or upgrade VSP; however, the “After
Installing” section of this document describes how to update the VSP server.
3. Return to the “After Installing” section of this document for any post-install actions for this
service pack.
For standard upgrades, after the upgrade completes the wizard automatically starts the MIMIXSBS
subsystem and port jobs on the upgraded nodes. Data protection reports are also started if they were not
previously run on an upgraded node. By default, MIMIX is automatically started, but you can specify No
to start MIMIX yourself.
For custom upgrades, default values result in the same behavior after the wizard completes as
described above for standard upgrades. However, if you specify No for the Start MIMIX replication
choice in a custom upgrade, you also have the option to automatically start the MIMIXSBS subsystem
and port jobs on the upgraded nodes. If you specify No to prevent automatically starting these
processes, you must manually start the MIMIXSBS subsystem and port jobs on the upgraded nodes
before manually starting MIMIX.
For new installs, the number of nodes on which you are installing significantly affects wizard activity.
• For a new two-node instance of MIMIX, the wizard partially configures MIMIX, and simplifies startup
so you can complete your configuration using VSP on an IBM i platform. The wizard prompts you for
information it uses to create basic product configuration. The wizard also starts the MIMIXSBS
subsystem, port jobs, data protection reports, and the VSP server on both nodes. By default, MIMIX
is automatically started, but you can specify No to start MIMIX yourself.
• For any other number of nodes, only the software is installed. Configuration and start up activities
must be performed manually when the software installation completes.
Requirements for new two-node installs: You must provide information about both nodes and identify
which node is the primary node. The wizard uses this to create system definitions which define the
nodes (Node 1 and Node 2) to MIMIX and creates a transfer definition for communication between the
nodes. The node identified as the primary node will have its system definition assigned the role of a

network (*NET) node. The other node will have its system definition assigned the role of a management
(*MGT) node. These assignments occur even in environments licensed for multiple management nodes.
The transfer definition is created with the name PRIMARY. You must provide the following:
• MIMIX node (SYSDFN) - The names specified will be used for the system definitions. If values are
displayed, they are from the nodes you logged in to on previous panels in the wizard.
• IP address or host name - The values displayed are from the nodes you logged in to in previous
panels in the wizard. Values can be either a mixed-case host alias name up to 256 characters in
length or a TCP address (nnn.nnn.nnn.nnn).
• Port - Identifies the port number that MIMIX will use to communicate with the node. The default value
is port 50410.
• Primary node - Select which node will be the primary node in the installation. The Primary node
identifies the source for replication activity. The node selected should be where your business runs.
The default is the node identified as Node 1.
To use the wizard do the following:
1. If you haven’t already, download the MIMIX Installation Wizard for this service pack from Support
Central. There is an executable (.exe) file for each product download, which contains the MIMIX
Installation Wizard as well as the actual product update.
2. Run the wizard.
Note: The wizard will instruct you when to end MIMIX. When directed to end MIMIX, perform Step 3
through Step 9.
If you have multiple installations of MIMIX, the first installation updated will update License
Manager. Because of this, you should end MIMIX on all installations before installing.
3. Use the following command on a management system to end replication processes, audits, and
supporting processes for the MIMIX installation:
installation-library/ENDMMX ENDOPT(*CNTRLD)
Note: Based on your environment and the parameters you specified, it may take some time for the
ENDMMX command to complete. Ensure that all your jobs are ended before continuing. For
optimal availability, do not end the remote journal links as part of ending MIMIX.
4. Repeat Step 3 for each additional MIMIX installation.
5. If you are not using MIMIX to schedule audits, ensure that your scheduling mechanism does not start
audits during the installation process.
6. If running iOptimize on any system in your MIMIX installation, specify the iOptimize installation library
name to end iOptimize using the following command:
installation-library/ENDID *ALL
7. If you are using VSP, end the VSP server on the system where it runs. This prevents object locking
issues that can interfere with the install process when subscriptions are used or when VSP users are
logged in.
• If the VSP server runs on an IBM i platform, use the following command:
VSI001LIB/ENDVSISVR
• If the VSP server runs on a Windows platform, from the Windows Start menu, select
All Programs > VSP > Stop Server and click Stop Server.
Note: If the VSP server currently is version 3.1 or 3.0, the Start menus shows “Vision Solutions

Portal” instead of VSP until version 3.2 is installed.
8. End the port jobs on all systems. Use the End Lakeview TCP Server command on each system:
installation_library/ENDSVR HOST(host_name) PORT(port_number)
where host_name is the host name or address and port_number is the port number or alias
defined in the transfer definition for the system on which you are running this command.
9. Ensure that all MIMIX jobs are ended before performing this step. Use the following command
on all systems to end the MIMIX subsystem:
ENDSBS SBS(MIMIXSBS) OPTION(*IMMED)

After installing the service pack instructions
The steps you need to perform after installing vary depending on whether there are special instructions
for this service pack that apply to your environment, whether you used commands or the MIMIX
Installation Wizard to install, and choices you made within the wizard.
Post-install actions for this service pack, all install methods

This section applies regardless of how you installed this service pack and provides links to topics in this
document that describe changes within the service pack that may require modifications to your MIMIX
environment after you install. Even new installations should check this list for potential required actions.
.
After installing, perform any of the following actions that are necessary for your environment. The
instructions are listed by service pack. It is necessary to perform any special instructions provided for
9.0.02.00, as well as the following actions for service packs that were not installed when you started this
process. (You can skip special instructions for service packs previously installed on your system.)
9.0.01.00
Configure *JOBQ objects to replicate jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
Configure attributes to ignore in data distribution environments . . . . . . . . . . . . . . . .56
Review the OBJONTGT policy value and KEEPSPLF parameter setting for all
data group object entries that replicate output queues . . . . . . . . . . . . . . . . .54
Upgrades to 9.0 may need to address obsolete configuration or update
automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
Upgrades to 9.0 may need to convert resource groups to use multithreading or
update automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Upgrades to 9.0 may need to update automation that creates or changes data
groups or configured selection rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
After a new two-node install

Note: For any new install on more than two nodes (or on 1 node only), use the instructions in “After a
wizard new install (3+ nodes) or a command-based install or upgrade” on page 14.
The wizard started the VSP server, the MIMIX subsystem, port jobs, and data protection reports on all
nodes. If you used the default value, the wizard also started MIMIX (STRMMX command). To access
VSP to continue configuring MIMIX, do the following:
1. Check the special instructions above for details of any actions required after installing new
environments.
2. If the installation wizard is still open, click the Launch VSP button on the Summary panel to open a
browser window.
If the wizard is not open, use the following URL in the address bar of your web browser, specifying
the IP address or host name where the VSP server is installed and the configured port. The default
port is 8410.
http://server:port
3. Log in using your IBM i user ID and password.
4. If you are the first person to log in, portal connections and an instance that connects to your new
installation are created. Otherwise, follow the instructions in the Enterprise Status portlet in the Home
folder, to configure portal connections and an instance.
5. If necessary, start MIMIX using the Start MIMIX action from the Nodes portlet on the Summary page.

6. Select the instance. Instructions in the Replication Environment portlet on the Summary page direct
you how to start completing your configuration using the Data Protection Reports portlet on the
Analysis page. For more information, see online help for the Data Protection Reports portlet.
After upgrading an existing installation

If you used the wizard’s standard upgrade option or its default values in the custom upgrade option, the
wizard started the VSP server, the MIMIXSBS subsystem and port jobs on all upgraded nodes, and
MIMIX replication processes (STRMMX command) for the installation. The wizard also started data
protection reports if they had not previously been run on a node. Do the following:
1. As needed, do the following:
a. Make any known configuration changes on any installation that was upgraded. Check the post
install instructions above for details.
b. Update your Runbook. For more information about the Runbook, contact your certified MIMIX
consultant.
browser window to access VSP.
If the wizard is not open, use the following URL in the address bar of your web browser, specifying
the IP address or host name where the VSP server is installed and the configured port. The default
port is 8410.
http://server:port
3. Log in to VSP using your IBM i user ID and password.
4. Check MIMIX status. All supporting processes on all nodes and all replication processes should be
active. Do one of the following:
• From VSP, check status on the Summary page of an instance that connects to the product library
you upgraded.
• From the native user interface, check status on either the Work with Application Groups display,
or the Work with Data Groups display. For more status instructions, see the MIMIX Operations
book.
5. If necessary, start MIMIX using the Start MIMIX action from the Nodes portlet on the Summary page.
6. If you use VSP on a Windows® server, you need to manually update that environment using an
additional wizard and the instructions in “Optional VSP and MIMIX Portal Application on Windows”
on page 17.
After a wizard new install (3+ nodes) or a command-based install or upgrade
Use these instructions if you used the MIMIX Installation Wizard for a new install on 3 or more nodes, on
only 1 node, or if you used commands within the native user interface on IBM i to install or upgrade.
The following steps must be performed after successfully installing on all systems:
1. Use the following command to start the MIMIX subsystem on all systems:
STRSBS SBSD(MIMIXQGPL/MIMIXSBS)
2. If performing a new installation, configure MIMIX from the management system using the “Checklist:
New remote journal (preferred) configuration” in the MIMIX Administrator Reference book.
3. Ensure that your communications servers are started on all systems. Use the command
WRKACTJOB SBS(MIMXSBS) to confirm that jobs have been started by any autostart jobs. If
necessary, start the servers. For example, use the following command for TCP:

installation-library/STRSVR HOST(host_name) PORT(port_number)
where host_name is the host name or address and port_number is the port number or alias
defined in the transfer definition for the system on which you are running this command.
4. On each installation, use the following command on the management system to start all system
managers, journal managers, collector services, application groups, data groups, monitors including
the master monitor, the MXSCHED job, and the MXCOMMD job:
installation-library/STRMMX
5. Repeat Step 3 and Step 4 for each additional MIMIX installation.
6. As needed, do the following:
a. Make any known configuration changes on any installation that was upgraded. Check the special
instructions above for details.
b. Update your Runbook. For more information about the Runbook, contact your certified MIMIX
consultant.
7. Check MIMIX status using the information provided in the MIMIX Operations book. To check status
from VSP, you may need to complete the remaining steps to ensure VSP is up to date first.
8. Use Step 8 through Step 13 to ensure your VSP environment on IBM i is current and active.
• If you used the wizard, default options ensured that VSP was installed at a level compatible with
the latest portal application for the product and started VSP on all nodes. Skip to Step 12 to
access a browser and log in.
• If you used native user interface commands for a new installation or the first upgrade to a version
9.0 service pack, continue with Step 9.
• If you used native user interface commands for an upgrade when VSP version 3.2 was already
installed, skip to Step 10 to make the latest portal application available to the VSP sever.
• If you use VSP on a Windows® server, you need to manually update that environment using an
additional wizard and the instructions in “Optional VSP and MIMIX Portal Application on
Windows” on page 17.
9. Command line install processes (found in the Using License Manager book) do not install or upgrade
the VSP server, and do not make the server aware of the latest portal application. Use either of these
methods to install VSP on systems running IBM i:
• Recommended method - Use the MIMIX Installation Wizard and select the option “MIMIX portal
application only”. This will also install the VSP server as needed to support the portal application.
• Alternate method - If you cannot use the wizard, use the VSP stream file installation method
documented in the Using License Manager book.
10. Make the portal application known to the server using the command:
VSI001LIB/ADDVSIAPP APP(MIMIX)
If the command fails with message VSE100A, you must upgrade the VSP server to a compatible
level before you can use the latest portal application available. Choices for installing are identified
in Step 9.
11. Start the server using the command:
VSI001LIB/STRVSISVR
Note: The default port is 8410. Each instance of the server uses three consecutive ports. If you
cannot use this port, change the port using instructions in the VSP User’s Guide book.

browser window.
If not, use the following URL, specifying the IP address or host name where the VSP server is
installed and the configured port. The default port is 8410.
http://server:port
13. Log in using your IBM i user ID and password.

Optional VSP and MIMIX Portal Application on Windows
This section provides optional instructions for installing VSP and the MIMIX portal application on a
supported Windows® server. Support Central provides an executable (.exe) file for the VSP 3.2 & Portal
Application Installation Wizard for Windows® for each MIMIX service pack. This wizard installs version
3.2 of VSP and the MIMIX portal application on a supported Windows server.
Notes:
• This wizard does not install the MIMIX product on any platform. You must still install the product
updates in this service pack using the service pack installation instructions. For more information,
see “Action required” on page 1.
• The first time you install version 3.2 of VSP on a Windows server, you must upgrade any other portal
applications on the VSP server to a compatible level. For more information, see “VSP 3.2
compatibility with product portal applications” on page 2.
Before installing on Windows

Before running the VSP 3.2 & Portal Application Installation Wizard for Windows, do the following:
1. VSP version 3.2 can only be installed on Windows servers that support 64-bit applications.
Customers who cannot upgrade to VSP version 3.2 also cannot use the MIMIX version 9.0 portal
application, which runs only on VSP version 3.2, and thus cannot use VSP to manage 9.0 instances.
Refer to “VSP 3.2 compatibility with product portal applications” on page 2 for information about
supported VSP configurations.
2. Ensure that your client workstation meets the minimum requirements for using this wizard. The user
who runs this wizard must have administrator privileges for the system on which it is run. Either
Windows® 7, Windows® 8, Windows® 8.1, Windows® 10, Windows® 2008 R2, or Windows Server®
2012 R2 is required. For a complete list of wizard requirements, see the More Info link in the wizard’s
Welcome panel or on the download page in Support Central.
3. To improve performance of the wizard, close other applications before starting the wizard.
Installing on Windows
Default options in this wizard for Windows will shut down the VSP server if necessary. This affects
access to all instances running on the server, including those connecting to other products. Do the
following:
1. Download the VSP 3.2 & Portal Application Installation Wizard for this service pack.
2. Run the wizard.
Installed Location: Version 3.2 of VSP can only be installed on a 64-bit Windows® operating system.
VSP server software and product portal applications are stored on the system in \Program
Files\VisionSolutions\. When the server is upgraded to VSP 3.2, if VSP 3.0 is installed in
\Program Files (x86)\VisionSolutions\, the installation wizard will delete VSP from the (x86)
path up to and including the \VisionSolutions folder.
After installing on Windows

If you used defaults, the wizard started the VSP server. If necessary, start the server. From Windows,
click the Start menu and point to All Programs. Locate and point to VSP, then Click Start Server.
Log in to VSP using your Windows user ID and password.
For more information about using VSP on a Windows server, see the VSP User’s Guide.

MIMIX®
Highlights Version 9.0 Service Pack 9.0.02.00
This service pack includes the contents of superseded MIMIX service packs, and the following
changes.
These icons indicate:
A change that may require action. For example, you may need to modify automation
programs or exit programs or perform other actions before or after installing the service pack.
A change in behavior or a change to the user interface. You should be aware of the change,
but no action may be required.
New function or an enhancement in the indicated software.
Fixes included in service pack 9.0.02.00

This service pack includes all relevant changes to earlier level 9.0 service packs, all relevant
fixes in 8.1.24.00 or earlier levels of version 8.1, and fixes for the following reported problems:
MXHA-27345 Retrying a failed U-MX XP activity entry for a symbolic link (*SYMLNK) completes
successfully.
MXHA-27397 Data group file activities (file entries) for disabled data groups in
multimanagement environments will no longer have status values other than
*ACTIVE.
MXHA-27443 The Audit Schedule portlet no longer shows a Java stack trace.
MXHA-27445 The object apply (OBJAPY) job no longer fails with CPF3806 and CPF3780 when
processing U-MX XP entries for spooled files.
MXHA-27447 The Clear Filter action now works correctly in the Data Protection Report (DPR)
window.
MXHA-27463 CVTRG no longer fails with SQL0104, SQL0204, SQL0501, and LVE351C when
run from an interactive session with certain CCSID and LANGID settings.
MXHA-27468 The Libraries audit (#OBJATR) and CMPOBJA command now set the REPTYPE
field correctly for data groups that perform object-only replication.
VSP
VSP version 3.2.02.00 is included with MIMIX service pack 9.0.02.00.
Fixes for VSP

VSP 3.2.02.00 includes all relevant changes to earlier VSP 3.2 service packs, all relevant fixes in
3.1.14.00 or earlier levels of version 3.1, and fixes for the following:
STR-5473 Instances with special characters in their name now show the correct status in the
navigation area within VSP when using Firefox.

MIMIX®
Highlights Version 9.0 Service Pack 9.0.01.00
This service pack includes the contents of superseded MIMIX service packs, and the following
changes.
These icons indicate:
A change that may require action. For example, you may need to modify automation
programs or exit programs or perform other actions before or after installing the service pack.
A change in behavior or a change to the user interface. You should be aware of the change,
but no action may be required.
New function or an enhancement in the indicated software.
Mobile support - VSP interfaces responsive on smaller

devices
Key interfaces within VSP 3.2 and its supported portal applications are now easier to use on
tablets and mobile devices. Interfaces will now automatically respond to the size of smaller
devices by minimizing space used for actions and menus, changing the positions of portlets from
horizontal to vertical, and within portlets by combining related columns or not displaying lower-
priority columns. PC users will also see this behavior change when the browser window is made
smaller.
(MXHA-11232, STR-5361, VDIR-8824)
Summary page redesigned, new Replication Environment

portlet
VSP users will see a redesigned Summary Page that improves the ability to determine the state
of an instance, perform most daily operations, and take actions to access details and resolve
issues from one location. The page includes a new Replication Environment portlet, a more
condensed view of the Nodes portlet, and a new Data Protection Reports Summary portlet. This
version of the Summary page is available when the selected instance is running MIMIX version
9.0.
9.0.01.00 (included in 9.0.02.00) © 2017, 2018 Vision Solutions, Inc. All rights reserved. 19
These enhancements are not available when viewing an instance running a previous version of MIMIX.
When an earlier instance is selected, the Summary page shows the Application Groups, Data Groups,
and Nodes, Notifications, and DPR Summary portlet portlets.
Replication Environment portlet

The new Replication Environment portlet summarizes the entire replication environment in one portlet
with actions available for accessing details, resolving issues, maintaining configuration, and other
capabilities. This portlet makes it easier to identify what is at risk, what could prevent a switch, and how
long it may take to run a planned switch. Callouts in the picture identify described highlights.
Some columns may not be displayed because of the size of your browser window or the device you are
using.
The Replication Environment portlet is only available for instances running MIMIX 9.0 and higher.
Last Refresh (A) - Identifies the date and time when the displayed information was last refreshed from
the available data.
The displayed information is automatically refreshed every 60 seconds; however some of the available
data may be older than that.
Notifications (B) - When there are new notifications, fields identify the count of new action required,
attention, or informational notifications that exist. The Notifications action, which provides access to the
Notifications window, appears next to count fields when there new notification and is always available
from the global menu. The Notifications window is only accessible from this portlet and provides the
same information previously available from the Notifications portlet.
Application Group/Data Group (C) - In an instance that uses application groups, application groups
are listed by their severity (default). You can select a toggle to view the list of data groups associated
with each application group. When expanded, data in these columns are blank: Backlogs, Correction
Activity, and Audits.
Icons can appear to the right of an application group name or data group to indicate:
• A virtual switch is in progress.
• An unplanned switch occurred.
• Configuration changes are pending.
• Replicated jobs exist on the current source node and must be submitted or removed before the next
switch.
• When displayed on smaller devices or windows, additional icons can appear to identify issues with
audits or procedures when those columns are not displayed due to size.
Data Groups Not in Application Groups (D) - When an instance also has standalone data groups,
they are listed below the application groups.
Note: If the instance has only data groups, the portlet does not have columns for Procedures and
Planned Switch. Also, the Model switch framework field will appear above the toolbar.
Model switch framework (E) - If model switch framework is enabled and used to switch standalone
data groups, its status is displayed.
Processes (F) - The status icon represents the most severe status related to processes.
• For application groups without clustering, this is the most severe status for the node-level processes
(MIMIX collector services, system manager, journal manager, and target journal inspection) for all
nodes in the application group, all data group processes, and replication direction. For an application
group with clustering, this also includes the most severe status of the application resource group,
IBM i CRG objects associated with data resource groups, and nodes associated with data resource
groups. When an application group is expanded, the status of each data group shows its most
severe status for replication processes on the data group's source and target nodes. Data group
replication processes are: remote journal link or database send, object send, container send, and
object retrieve, database apply, object status send, and object apply.
• For a standalone data group, this is the most severe status of replication processes on the source
and target node. Replication processes are: remote journal link or database send, object send,
container send, and object retrieve, database apply, object status send, and object apply.
Backlogs (G) - The Source and Target columns identify the number of journal entries that are
backlogged for database and object replication processes on that node, shown respectively as n | n. For
an application group, each number is a summation of the associated data groups. For a data group,
each number is specific to that data group. When one of the processes has reached its threshold, the
threshold icon is also displayed. A dash ( - ) in both columns of a data group means the data group is
disabled and a dash in one column means the data group is either object only or database only.
Note: Data for backlogs is collected at regular intervals and can be a couple of minutes old when
displayed. To retrieve current backlogs for a specific data group, go to the Data Group Details
and Activities portlet on the Data Groups page and view the DB Statistics and Object Statistics
tabs. The Replication Environment portlet will also be updated with the newer data group
backlogs.
Correction Activity (H) - This column identifies the number of objects that need manual recovery and
the number of objects that are being automatically recovered, shown as n | n. An icon appears next to
the manual recovery count and the count is highlighted when the most severe status is action required
(red) or attention (yellow). The automatic recovery count includes all objects being automatically
corrected, including out-of-synchronization conditions found by audits and replication.
Audits (I) - The icon shown reflects the most severe combined status of the last audit runs and audit
compliance for all audits for all of the data groups in an application group, or for all audits in a data
group.
Procedures (J) - This shows the most severe status of all procedures for an application group.
Planned Switch (K) - These columns help you identify problems that could prevent a planned switch,
identify when the last planned switch was performed, and provide historical data about previous
switches to help you estimate how long a planned switch may take. Three columns are displayed by
default:
• Precheck - Shows a status icon and the date and time of the last run of the planned switch precheck
procedure.
• Last Start - Shows the date of the last run of the planned switch.
• Average - Shows the average duration of planned switch procedure runs that had a status of
Completed (*COMPLETED), Completed with errors (*COMPERR), or Acknowledged completed with
errors (*ACKERR).
A dash ( - ) is displayed in these columns if the precheck procedure or a planned switch has never been
run. Additional columns can be selected from Edit mode for the portlet to display the duration of the
shortest, longest, and last run of a planned switch for the application group.
Actions available from the Replication Environment portlet

Global actions include the ability to start or stop MIMIX, export the data displayed in the portlet, and
access windows for the following: Correction Activity, Notifications, Configuration, Instance Policies,
Policy Summary, Schedule Summary, Message Log, and Model Switch Framework (when enabled).
Toolbar actions for application groups allow you to run procedures for the selected application groups,
including Start, Stop, Precheck, Switch, and Virtual Switch. In an instance that has only standalone data
groups, toolbar actions allow you to start or stop the selected data groups.
Row actions may be dependent on the status of the application group or data group. Data group actions
vary for standalone data groups and data groups in an application group. Resulting windows may be
subset to the selected item.
• For an application group, the list of actions includes: Details, RPO/RTO Analysis, Display Message,
Start, Stop, Run Audits, Correction Activity, Replicated Objects, Procedures, Procedure History,
Precheck, Switch, Virtual Switch, Virtual Switch Activity.
• For a data group, the list of actions includes: Details, Start Resource Group, Stop Resource Group,
Start, Stop, Enable Constraints, Retry AP Maintenance, Run Audits, Correction Activity, Replicated
Objects, Policies, Enable, Disable, Message Log.
Nodes portlet changes

When viewing instances running MIMIX 9.0, you will see the following changes to the Nodes portlet:
The Notifications (Nfy) column has been removed. Access to notifications is now available from the
Replication Environments portlet as a button above the toolbar.
In the portlet’s summary view, which is the default, the status of all managers, services, and monitors is
summarized into one Sts column. When the portlet is maximized, the detailed view continues to show
separate columns for System Managers, Journal Managers, Journal Inspection, Collector Services,
Cluster Services, and Monitors.
Data Protection Reports Summary portlet

The Data Protection Reports Summary portlet on the Summary page identifies how many of the existing
libraries, directories, and folders on a node are protected by showing counts for each protection level.
The Reports for node button allows you to choose which node’s report is displayed. The Report action
opens the Data Protection Report window, which provides the same functionality as the Data Protection
Reports portlet, including the ability to use the Include in Replication wizard. Other available actions
include the ability to run reports, display a report, change the report schedule or policies, display a list of
replicated objects, and access the Replication Configuration window.
(MXHA-11232)
Support for multithreaded database apply jobs

The database apply process (DBAPY) now supports the ability to use a multithreaded job when
processing most record-level transactions for files replicated through the user journal. This improves
performance of the database apply process, simplifies apply session assignment, and eliminates
scenarios where the workload is not balanced among apply sessions. Multithreaded database apply
processing is supported only in configurations that use application groups.
Installations that upgrade to MIMIX 9.0 retain their existing configuration, which uses from one to six
single-threaded database apply sessions. Resource groups can be converted to use multithreaded
database apply processing for each of their data groups. Data groups that do not participate in a
resource group (standalone data groups) continue to use single-threaded apply sessions and must be
associated with a resource group and application group before they can be eligible for conversion to
multithreading.
Default values for creating a data group definition have changed. When using default values, the
resulting data group definition uses multithreading and is associated with an application group. Using
non-default values, you can still create standalone data groups or data groups in resource groups that
use single-threaded apply sessions. Regardless of which method of DB apply processing is configured,
changing data group parameters required for multithreading is not allowed and requires a conversion
process.
Note: Even if you do not convert existing resource groups to multithreading, numerous configuration
changes associated with multithreading are likely to affect future changes to your MIMIX
installation. These changes affect the ability to create new data group definitions and add new
selection rules (data group entries) for existing data groups. See the “Action Required” on
page 67 and “Configuration changes to support best practices and multithreading” on page 30 for
a complete list of changes.
New dialogs from the Replication Configuration window in the MIMIX portal application, as well as new
menu options and the new Convert RG for Multithreading (CVTRG) command, simplify converting the
data groups in one or more resource groups between single-threaded and multithreaded database apply
processing.
Action Required
Before installing or upgrading to MIMIX 9.0, use the CHKIBMPTF command to check for required IBM
PTFs. The list includes IBM PTFs that are critical to support multithreaded database apply processing.
The PTFs critical to multithreading must be applied on all nodes. On some operating system levels, an
IPL may be required to apply the PTFs. See Step 1 of the instructions in “Before installing the service
pack” on page 6 for more information about the CHKIBMPTF command.
Also, after upgrading an installation to MIMIX 9.0, action is required if either one of these scenarios
apply:
• In order to use multithreading in an existing resource group, the resource group must be converted.
See “Conversion to and from multithreaded database apply processing” on page 27 for details.
• Even if you do not plan to convert resource groups to multithreading, you may need to update
automation to prevent failures, especially in environments that do not use application groups. You
may also need to update scripts that create data groups or that add or change selection rules (data
group entries), as well as update any user-created instructions. See the automation impacts in the
Action Required section of “Configuration changes to support best practices and multithreading” on
page 30 to support best practices and multithreading.
(MXHA-22349)
Operational overview of multithreaded database apply processing

All data groups within a resource group must be configured for the same type of database apply
processing: either all multithreaded or all single-threaded.
When a data group has multithreading configured, database apply session A is used solely for journaled
IFS, data area, and data queue objects. Apply session B is used solely for journaled physical and logical
files and has an associated multithreaded job that starts and ends with apply session B. The actual
number of threads allowed is determined by the license for your product. Apply session B performs pre-
apply operations for all transactions to be applied, applies more complex transactions for member and
file operations, and delegates blocks of record-level transactions to be applied by the multithreaded job.
After the threaded job completes a block of transactions, apply session B updates status, counts, and
the last applied sequence number. Apply session B performs error handling for any transactions that
could not be processed by the threaded job, and either retries the operation or submits a recovery
request. The name of the multithreaded job is sdn_DBAPYT, where sdn is the short data group name.
When multithreading is configured, MIMIX ignores the DB apply cache (DBAPYCACHE) and Access
path maintenance (APMNT) policies.
Restrictions and limitations

• Data groups that use multithreading require that the data groups in the resource group and their
selection rules (data group entries) be 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.
• Resource groups and data groups cannot specify to use multithreading as well as the value Use
System Journal (*SYSJRN) for Cooperative processing type (COOPJRN parameter). Data groups
that specify this value and their associated selection rules (data group entries) must first be
converted to using cooperative processing via the user journal before becoming eligible for
conversion to multithreading.
• 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 splitting.
• In environments that implement cascading 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 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). If you access data on the target system, this change may affect your
processing. See “New default for Commit mode (DBAPYPRC)” on page 34 for more information.
• Multithreaded data groups use commitment control to apply record level changes on the target. 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.
• 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.
• MIMIX for 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.
• Data groups that use multithreading cannot have database apply user exit programs.
Configuration requirements are listed in the conversion section.
Status reporting
The status of the multithreaded job is included in the DB Target column on the Data Groups portlet and
on the Work with Data Groups (WRKDG) display.
Detailed status for the multithreaded job can be found in the following locations:
• From VSP, the DB Statistics tab of the Data Group Details and Activities portlet displays the status of
the Multithreaded apply job in the Supporting processes section. Possible statuses for the
multithreaded job are Action Required, Stopped, Stopped due to a virtual switch in progress, and
Active.
• From the native user interface, the multithreaded job (DBAPYT) status appears in the following
views of Display Data Group Status (DSPDGSTS). Possible status values for the job are: -I (inactive,
red), -V (ended due to virtual switch in progress, yellow), -A (active, blue), and -U (unknown, white).
– Merged view: The process DBAPYT appears in the statuses listed horizontally in the Target
Statistics section.
– DB views 1 and 2: The process DBAPYT appears to the left of the Held for other reasons field in
the top half of the display.
– DB view 3: The process DBAPYT appears in the Target system row, above the Database Apply
section.
Starting and ending the multithreaded job

When multithreaded database apply processing is configured, the multithreaded job is automatically
included in requests to start or end the database apply processes that specify either apply session B or
all apply sessions. This affects the Start Data Group dialog, Stop Data Group dialog, Start Data Group
(STRDG) command, End Data Group (ENDDG) command, as well as any other step programs or
commands that invoke the STRDG or ENDDG commands.
From VSP, the Start Multithreaded Apply Job dialog, which starts only apply session B and the
multithreaded job, is available on the DB Statistics tab of the Data Group Details and Activities portlet
when the multithreaded job is inactive.
Conversion to and from multithreaded database apply processing

Conversion between single-threaded and multithreaded database apply processing is supported only at
the resource group and application group levels. All data groups within a resource group must be
configured for the same type of database apply processing.
New dialogs in the Replication Configuration window within VSP, new options on the Work with
Application Groups display and the Work with Data Rsc. Grp. Ent. display, and the Convert RG for
Multithreading (CVTRG) command allow you to:
• Check requirements for multithreading without converting.
• Convert the configuration of data groups associated with one or more resource groups to or from
required values for multithreaded database apply processing.
• Change how long to keep saved configuration data from previous conversion to multithreading,
which allow you to return to the previous single-threaded settings.
Within VSP, the available actions are based on the current configuration of the resource group.
Interfaces for conversions allow you to specify additional choices, such as optionally discarding open
commits or how long to save the pre-conversion configuration data. If you use the menu options for
conversion from the Work with displays, you will see a confirmation panel and after you press Enter, you
will have the ability to specify additional parameters relevant to the type of conversion being performed.
Before performing a conversion to or from multithreading, you must perform a controlled end of all data
groups within the selected resource groups, and all file activity (data group file entries) must have a
status of *ACTIVE or *HLDIGN. Also, the data groups cannot have any open commit activity unless you
explicitly specify to discard any open commits.
When you specify multiple resource groups in these interfaces, each resource group is processed
independently.
When you perform a conversion to or from multithreading, if any data group within a specified resource
group does not meet conversion requirements, the resource group is not converted. If a data group
meets conversion requirements but fails to convert, all configuration changes for other data groups in the
same resource group are reverted. The time needed to perform a conversion depends on the number of
library and file selection rules (data group object and file entries) associated with the selected resource
groups. While this command is running, do not switch the application groups associated with the
resource groups, and do not change the data group definitions or their selection rules (entries).
After a conversion, the data groups must be started specifying to clear pending entries
(CLRPND(*YES)). If the Start Application Group (STRAG) command is used to start replication, it will
automatically perform the clear pending start of the data groups.
Running the audits after conversion is recommended if you specify to discard open commits.
Table 1. Operation and available interfaces with descriptions
Operation and available Description

interfaces
Check multithreading Validates that the data groups in the selected resource groups meet the
requirements: requirements for conversion to multithreaded database apply processing and
• Check Multithreading reports problems that would prevent conversion. Replication processes can be
Eligibility dialog active when this option is used. The following requirements are checked:
• Menu option: 31=Check • The data groups cannot have a database apply user exit program.
for conversion • Each data group must specify Use User Journal for Cooperative processing
• CVTRG type (COOPJRN(*USRJRN)), values other than None (*NONE) for the
OPTION(*CHECK) Node 1 and Node 2 journal definition fields (JRNDFN1, JRNDFN2) a
numeric value for the database Apply sessions (NBRDBAPY), and *NONE for
the Process and Duration elements of Recovery window (RCYWIN). (VSP
interfaces do not support fields for configuring a recovery window.)
• Each data group and all of its library and file selection rules (data group object
and file entries) must specify or resolve to Positional (*POSITION) for the
Replication type field of the File and tracking options (FEOPT).
• Stopped (inactive) data groups are checked for the presence of open commits
and whether they were ended controlled.
• File activities (file entries) must have statuses of *ACTIVE or *HLDIGN.

interfaces
Convert to multithreading: Converts eligible data groups within the specified resource groups from existing
• Convert Resource configuration values to values required for multithreaded database apply
Groups to Multithreaded processing. Resource groups whose data groups are already configured for
dialog multithreading are not processed. Prior to converting, this option verifies the same
• Menu option: requirements as performed by *CHECK, with one difference. The check for open
32=Convert to commit activity is performed on all associated data groups and no open commit
multithreading activity can exist unless you explicitly select the checkbox for Discard open
commit cycles (in VSP) or specify *DISCARD for Open commit handling
• CVTRG
(OPNCMT) in native user interfaces.
OPTION(*CVTTOMT)
After requirements are successfully checked, the conversion process changes the
following in the configuration:
• Journal definitions associated with the data groups are set to *YES for Target
journal inspection (TGTJRNINSP).
• Data group definitions within the resource groups are changed as follows:
- The database Apply sessions (NBRDBAPY) is set to either Low, Medium,
or High (*THDLOW, *THDMED, or *THDHIGH). The value is determined
by evaluating the current configuration and the installed product.
- Journal on target (JRNTGT) is set to Yes (*YES).
- File and tracking options (FEOPT) have these fields set as follows: Lock
member during apply is set to Do Not Lock (*NONE), Apply sessions is set
to Threads are in use (*ALL), Disable and process triggers during apply is
set to Yes. The FEOPT parameter uses separate elements for these
trigger options with values of *YES.
- Database Apply processing options (DBAPYPRC) have these fields set as
follows: Commit mode is set to Immediate (*IMMED), Manage constraints
on target (not displayed in VSP) is set to *YES.
• All configured data group library and file selection rules (object and file entries)
for the converted data groups are changed to set these File and tracking
options (FEOPT):
- Replication type is set to Default (Positional), (*DGDFT)
- Lock member during apply is set to Default (Do Not Lock), (*DGDFT)
- Apply session is set to Any in library selection rules (*DGDFT within object
entries) and to ‘B’ in file selection rules (file entries).
- Disable and process triggers during apply is set to Yes (*DGDFT). The
FEOPT parameter uses separate elements for these trigger options.

interfaces
Convert from Converts data groups configured for multithreading that are within the specified
multithreading: resource groups to configuration values compatible with single-threaded database
• Convert Resource apply processing. Resource groups whose data groups are already configured for
Groups to Single- single-threaded database apply processing are not processed.
threaded dialog When converting from multithreading to single-threading, you can optionally
• Menu option: specify to use configuration data saved by an earlier conversion of the resource
33=Convert to single- group to multithreading. Replication processes must be ended by a controlled
threaded end, and no open commit activity can exist unless you explicitly select the Discard
• CVTRG open commits checkbox in the dialog or specify *DISCARD for Open commit
OPTION(*CVTFRMMT) handling (OPNCMT) on the command. If saved configuration does not exist or is
not used, the affected data group definitions will be changed to these values,
which are compatible with single-threaded database apply processing:
• Database Apply sessions (NBRDBAPY) is set to 6.
• Target constraint management (element of DBAPYPRC) is set to *NO. (This is
not shown in VSP.)
• Lock member during apply (element of FEOPT) is set to Exclusive, Allow Read
(*EXCLRD).
Change expiration on Changes the expiration date for a saved configuration associated with a specified
saved configuration: resource group. The resource group must have had configuration saved by a
• Change Configuration previous conversion to multithreading. If saved configuration does not exist for the
Expiration dialog resource group, a diagnostic message is issued. Replication processes can be
• Menu active when this option is used.
option:34=Change
saved config retention
• CVTRG
OPTION(*CHGEXP)
(MXHA-23668)
Configuration changes to support best practices and multithreading

MIMIX is changed so that an application group must exist before creating a new data group definition
using default values. Default values have changed in new data group definitions for several parameters
that are required for multithreaded database apply processing. Also, after a data group is created, the
type of database processing selected and parameters required for multithreading can only be changed
through a conversion process. Selection rules (data group entries) are changed so that, when
associated with a resource group that uses multithreading, values required for multithreading are
selected. These and other configuration changes support best practices and simplify configuration of
multithreaded database apply processing.
Note: These changes may affect your MIMIX installation even if you do not convert existing resource
groups to multithreaded database apply processing.
Action Required:
If you use automation that creates or changes data groups or their configured selection rules (data group
entries), you may have to update automation.
Automation impacts
• The CRTDGDFN command will fail in environments that do not have application groups with error
message LVE3507. To continue to create data groups not associated with a resource group
(standalone), the automation must be modified to specify non-default values for the command.
• If you have application groups and invoke the CRTDGDFN command using default values, the
resulting data group uses multithreading. You may need to modify automation to add the
RSCGRPAG parameter and provide values for it and the resource group (DTARSCGRP). If
automation attempts to create the data group within an existing resource group, the command will
fail if its values are not compatible with the database apply processing values used by the other data
groups in that resource group.
• Automation that invokes the CRTDGDFN command and expects the resulting data group to have
specific values for these parameters needs to be checked and possibly updated because of changes
to the parameter defaults, behavior changes, or restrictions when multithreaded database apply
processing is configured: DTARSCGRP, COOPJRN, NBRDBAPY, the FEOPT element Lock
member during apply, and the DBAPYPRC elements Commit mode and Target constraint
management.
• Automation that invokes the CHGDGDFN command may need to be modified. In multithreaded data
groups, parameters that are now required values for multithreading can no longer be changed with
this command.
• Automation that invokes any of the following commands for data group object entries and file entries
may need to be checked. Non-default values specified for file entry options (FEOPT parameter) may
not be able to be specified in environments configured for multithreaded database apply processing:
ADDDGOBJE, CHGDGOBJE, CPYDGOBJE, LODDGOBJE, ADDDGFE, CHGDGFE, CPYDGFE,
LODDGFE.
(MXHA-23349)
Defaults changed for data groups

Default values changed for several parameters on the Create Data Group Definition (CRTDGDFN)
command and for corresponding fields in the New Resource Group dialog (which also creates new data
groups). The changes reflect best practices for replication, which includes using application groups and
configuring multithreaded database apply processing.
Also, the Change Data Group Definition (CHGDGDFN) command, the Resource Group Details dialog,
and the Data Group Details dialog will not allow you to change parameters that are required for
multithreading in a data group that is configured for multithreading.
Application groups required for new default data groups

An application group must now exist before a data group can be created using default values.
Implementation details vary between VSP and the native user interface.
From VSP, the following changes in the MIMIX portal application ensure that new data groups created
with default values are always associated with an application group:
• On the Replication Configuration window, the toolbar action to create a new data group has been
removed from the Data Groups pane on Application Groups tab. (Creating a resource group
automatically creates the needed data groups, which has not changed, and allows you to either
accept defaults or specify other values.)
• The New Data Group dialog, can only be accessed from the toolbar on the Data Groups Not in
Application Groups tab of the Replication Configuration window. Values that are not valid for a
standalone data group cannot be selected from this dialog.
From the native user interface, the Create Data Group Definition (CRTDGDFN) command requires that
an application group exist before the command can be used with default values. Under certain
conditions, the command may also create the resource group to which the data group belongs. To
support this behavior, CRTDGDFN has the following changes:
• Data resource group entry (DTARSCGRP).
– The default value changed from *DFT to *DGDFN. The value *DGDFN uses the resource group
whose name matches the first part (name) of the three-part name of the data group definition.
– When a specified name or the value *DGDFN resolves to the name of a resource group that does
not exist and the value specified for RSCGRPAG is an existing application group name or the
value *DFT, which resolves to the name of the only configured application group, the resource
group will be created in that application group.
• Appl. group for resource group (RSCGRPAG).
This new parameter identifies the application group that controls the resource group in which the
data group participates. You can specify a name or use the default value, *DFT, which determines
the application group associated with the resource group identified by the DTARSCGRP parameter
as follows:
– When that resource group exists, *DFT resolves to the name of the application group to which the
resource group is configured, as follows:
– When that resource group does not exist and there is only one application group, *DFT resolves
to the application group name and creates the resource group using the first part of the data
group name.
– When that resource group does not exist and there are multiple application groups in the
configuration, the command will fail.
– When *NONE is specified for the resource group, the value *DFT is ignored and the resulting data
group is not associated with a resource group or application group. Only single-threaded data
groups can be created without a resource group.
Designating the type of database apply processing

Beginning in MIMIX version 9.0, data groups that are part of a resource group have two significantly
different choices for performing database apply processing: single-threaded or multithreaded. This
choice is made during new resource group configuration in VSP, during new data group configuration
from the native user interface, or by converting an existing resource group. In new configuration
interfaces, MIMIX defaults to use multithreaded database apply processing.
Implementation details vary between VSP and the native user interface. Regardless which interface you
use, the choice of multithreading or single-threading effectively means that the database Apply sessions
field (NBRDBAPY parameter) has different possible values based on your choice. Your choice also
determines what values are available in other fields that are required for multithreading.
Note: Once a resource group or data group is created with multithreading configured, its threading level
can be changed if allowed by the product license. If the resource group or data group is created
with single-threading configured, the number of apply sessions (1-6) can be changed. A
conversion process is required to change to or from single-threaded database apply processing,
and to change fields required by multithreading within a multithreaded data group.
From VSP, the New Resource Groups dialog uses these fields:
• Use multithreading for database apply (on General tab).
This field determines whether the resource group and its associated data groups will use
multithreaded or single-threaded database apply processing. The value Yes is the default and
results in multithreading. The value No results in single-threaded processing.
• Multithreading level (on General tab).
Available when Yes is selected in the field above, this field displays the default thread level allowed
for the installed product. Additional thread levels may be available based on the product license.
Possible values are Low, Medium, and High. See the descriptions of *THDLOW, *THDMED, and
*THDHIGH, below, for more detail. In existing resource groups, this field allows you to change the
threading level if allowed by the product license.
• Apply sessions field (on Database tab).
When multithreading is selected, this field displays “Threads are in use” and cannot be changed.
When multithreading is not selected, this field allows you to specify the number of single-threaded
apply sessions that run in parallel.
New default for Number of DB apply sessions (NBRDBAPY)

In the native user interface, NBRDBAPY is the data group parameter where the choice between
multithreaded and single-threaded database apply processing is made.
From the CRTDGDFN command in the native user interface, the default value of the NBRDBAPY
parameter changed from the number 1 to the value *THREADED, and other values were added for
multithreading.
• *THREADED (new default value). The license for the installed product determines the thread level
value to use for multithreaded database apply processing. For MIMIX DR, this resolves to the value
*THDLOW. For MIMIX Professional and MIMIX Enterprise, this resolves to *THDMED.
• *THDLOW. The database apply process uses a low number of threads in the multithreaded job. This
is the only value allowed for MIMIX DR. It is also allowed for MIMIX Professional and MIMIX
Enterprise.
• *THDMED. The database apply process uses a medium number of threads in the multithreaded job.
This value is allowed for MIMIX Professional and MIMIX Enterprise.
• *THDHIGH. The database apply process uses a high number of threads in the multithreaded job.
This value is only allowed for MIMIX Enterprise.
• Numeric values of 1 through 6 identify the number of single-threaded apply sessions to use. When
more than 1 is specified, these jobs run in parallel.
New default for Cooperative journal (COOPJRN)

The default value changed from Default (*DFT) to Use User Journal (*USRJRN) for the Cooperative
processing type field on the New Resource Group and New Data Group dialogs and for the Cooperative
journal (COOPJRN) parameter on the CRTDGDFN command. This ensures that cooperatively
processed operations for journaled objects are performed via user journal replication processes, and
applies to journaled logical files, physical files, data areas, data queues, and journaled IFS objects
identified by selection rules (data group entries) which specify to cooperate with database.
If you plan to use object level name mapping for objects that are replicated solely through the system
journal without any cooperative processing, you must specify the value *SYSJRN.
The previous default value (*DFT) is no longer available in user interfaces but if used in automation, it
resolves to *SYSJRN if the data group type is *OBJONLY. Otherwise, it resolves to *USRJRN.
New default for Lock member during apply (FEOPT)

The Lock member during apply element field on the New Resource Group dialog and element of the
FEOPT parameter on the CRTDGDFN command has had its default value changed. This field specifies
the type of lock used by the database apply process for the data of file members. Its default value has
changed and is dependent on whether multithreading is configured.
• On the New Resource Group dialog, the default value is dependent on what is selected for the Use
multithreaded database apply field on the General tab. When multithreading is selected, this field is
set to Do Not Lock and the value cannot be changed. When multithreading is not selected, the field
can be changed and its default value is Exclusive, Allow Read.
Note: In the New Data Groups dialog, the default value for Lock member during apply field remains
Exclusive, Allow Read because a standalone data group cannot be configured for multithreaded
database apply processing.
• On the CRTDGDFN command, the new default value is *DFT. When *THREADED, *THDLOW,
*THDMED, or *THDHIGH is specified for NBRDBAPY, *DFT resolves to *NONE and the apply
process does not hold a lock on file members. When a number is specified for NBRDBAPY, this
value resolves to *EXCLRD and the apply session holds an *EXCLRD lock on file members. The
previous default was *EXCLRD.
New default for Commit mode (DBAPYPRC)

The Commit mode field on the New Resource Group and New Data Group dialogs and the Commit
mode element on the Database apply processing (DBAPYPRC) parameter on the CRTDGDFN
command specifies how to process journal entries that are under commitment control. In all locations,
the default value is changed from Delay (*DLY) to Immediate (*IMMED). This mode is required for
multithreaded database apply processing, and it is preferred for single-threaded database apply
processing when the environment has long running commitment cycles that are eventually committed.
When immediate apply processing of transactions under commitment control is used, uncommitted data
can exist on the target system at any point prior to the commit cycle being complete. It is possible that
applied entries may be rolled back once all the journal entries in the commit cycle are applied. At any
time while entries in the commit cycle are being processed, the target system may contain partial data or
extra data that would not be available in delayed mode. This can be a concern if you use data on the
target system for more than high availability or disaster recovery, such as for running backups or reports
or for supporting cascading environments. If you cannot have uncommitted data on the target node, you
should not use Immediate commit mode.
New default and other changes to Target constraint management (DBAPYPRC)

Target constraint management is a requirement for data groups that use multithreaded database apply
processing. Data groups that do not use multithreading can no longer configure this capability in a data
group.
• The default value changed from *NO to *DFT for the Target constraint management element of the
Database apply processing (DBAPYPRC) parameter on the CRTDGDFN command. The value *DFT
resolves to *YES when *THREADED, *THDLOW, *THDMED, or *THDHIGH is specified for
NBRDBAPY and resolves to *NO when a number is specified for NBRDBAPY. On the New Resource
Group and New Data Group dialogs, the equivalent Manage constraints on target field is no longer
displayed.
• The only scenario where the target constraint management value can be changed is for a data group
that existed before the upgrade to MIMIX version 9.0 and specified the value *YES. After upgrading,
the value can be changed to *NO, but attempts to change it back to *YES require a conversion to
multithreading.
Selection Rule (data group entry) changes

From VSP, these selection rule dialogs will not allow you to select values other than Default for the
affected options:
• Include Libraries and Objects dialog
• Include File dialog
• Selection Rule Details dialog (for a library or file rule)
• Copy Selection Rule dialog (for a library or file rule)
Also from VSP, when you use the Move Selection Rule dialog (for a library or file rule) and the rule is
being moved from a resource group that uses single-threaded database apply processing to a resource
group that uses multithreaded processing, the affected options will be changed to meet multithreading
requirements. An information message appears in the dialog to inform you.
In the native user interface, dialogs and commands for creating or changing selection rules for libraries
and files (data group object entries and file entries) now check the validity of the values specified for the
file and tracking entry options (FEOPT) that are requirements for multithreaded database apply
processing. If the resource group to which the rule is associated is configured for multithreading, the only
valid value for the following options is Default (*DGDFT): Replication type, Lock member during apply,
Apply sessions, Disable and process triggers during apply (which is two elements in the FEOPT
parameter).
From the native user interface, these commands will fail and issue an error message if you specify a
value other than *DGDFT for the affected options:
• ADDDGOBJE, CHGDGOBJE, CPYDGOBJE, LODDGOBJE
• ADDDGFE, CHGDGFE, CPYDGFE, LODDGFE
Multithreading configured indicators in VSP

When multithreaded database apply processing is configured for one or more resource groups in an
application group, the Replication Configuration window displays an icon next to that application
group and the affected resource groups.
At the top of the Selection Rules window or File Selection Rules window, an icon is displayed next to
the Resource group name if the resource group is configured for multithreading.
When adding selection rules using the Include in Replication wizard and there are existing resource
groups from which you can select, an icon is displayed next to the resource group name if it is
configured for multithreaded database apply processing. If you select to add the rules to a new resource
group or if there are no configured application groups or resource groups, the Multithreading level field
on the wizard's Configure Replication panel allows you to specify whether to use multithreading. The
value you select in this field determines how the resource group and data groups will be configured. You
can select from the multithreading levels available for your product, or you can select None. The
Multithreading level field and the value you selected is also displayed in the wizard's Summary panel.
Copy data group (CPYDGDFN) changes
When using the Copy Data Group definition (CPYDGDFN) command to copy a data group, the
command verifies that the database apply processing configuration (either single-threaded or
multithreaded) is the same between the copied from data group (FROMDGDFN) and the resulting data
group (TODGDFN). The command will not allow you to copy a data group whose settings are not
compatible with those necessary for the resource group (TORSCGRP) in which the copied to data group
will exist.
Delete Application Group dialog, Delete Resource Group dialog changes

From VSP, when multithreaded database apply processing is configured, the Delete Application Group
dialog and the Delete Resource Group dialog do not allow the choice of keeping the related data groups.
This is because the data groups cannot exist as multithreaded without being associated to a resource
group. Instead, users must select a checkbox to confirm that all related configuration, including data
groups and selection rules, for the selected application group or resource group will be deleted.
If you wish to keep the data groups, you must first convert the resource group or application group to
single-threaded database apply processing. Then return to the appropriate Delete dialog and select to
keep the data groups.
Outfile and Retrieve command changes associated with multithreaded

database apply processing
• Outfile MXDGDFN for the WRKDGDFN command will return the value 2 for the NBRDBAPY and
RQSDBAPY fields when multithreaded database apply processing is configured. Fields are added to
return application group name for the associated resource group (RSCGRPAG, with values of
*NONE or user-defined name) and the multithreaded level (DBAPYTHD, with values *NONE,
*THDLOW, *THDMED, or *THDHIGH). Similarly, the RTVDGDFN command will return the value 2
for the NBRDBAPY, and the RTVDGDFN2 command added a parameter to return the multithreaded
level (DBAPYTHD).
• Outfile MXDGSTS for the WRKDG command added the DBAPYTHD field for the status of the
multithreaded job. Possible values are: *NONE, *UNKNOWN, *ACTIVE, *INACTIVE, or
*VRTSWTTST. Similarly, the RTVDGSTS command added the DBAPYTHD parameter.
Subscription event changes for multithreaded database apply processing

The following events are updated and can now be triggered by the status of the multithreaded job.
• Data groups with action required status
• Data groups with a stopped or partially stopped status
• Data group processes with action required status
(MXHA-23688)
Changes to automatic recovery reporting

The following enhancements to automatic recovery reporting are included in this release.
Object Correction Activity window improvements
The Object Correction Activity window is the recommended location to see the current status of
automatic recovery and to perform any manual recovery that is required. Here, an object’s recovery
status reflects a complete view of its detected replication and auditing problems.
Includes automatic recoveries from audits: The Object Correction Activity window now includes
recovery activities associated with differences found by audits as well as those associated with
replication and other processes. Recovery actions for audits that have been submitted to the replication
manager are included on this window. This is in addition to any failed or handled recoveries that were
performed by the audit job itself.
Manual recovery actions added: For recovery actions that failed, the Object Correction Activity
window added actions that you can use to manually recover the affected object. This provides consistent
recovery regardless of which process initially identified the problem. Also, you can use toolbar actions
for manual recovery of multiple objects that require the same recovery action.
Failed recoveries reported to data group details: Regardless of whether an automatic recovery was
initiated by replication or auditing, if the recovery fails, it is also reported on the corresponding replication
activity tab in the Data Group Details and Activities portlet.
For additional information, see “Audit recovery improvements” on page 44.
Recovery status added for file, IFS tracking, and object tracking activities
(entries)
You can now view the most severe status of any recoveries for an object identified in replication
activities (entries) for files, journaled IFS objects, and journaled data areas and data queues in either
user interface.
From VSP, the Correction Activity Recoveries column is added to the following tabs on the Data Group
Details and Activities portlet and related windows accessible from the tabs:
• File Activity tab, Related Files window
• IFS Tracking Activity tab, Related IFS Objects window
• Object Tracking Activity tab
From the native user interface, the Recovery Status (RCYSTS) parameter added to the following
commands allows you to subset the resulting display by a specific recovery status or by all recovery
statuses other than *NONE. The Recovery Status column is added in a new view on the resulting
display. Use F10 (Rcy sts view) to access the view:
• WRKDGFE command, Work with DG File Entries display
• WRKDGIFSTE command, Work with DG IFS Trk. Entries display
• WRKDGOBJTE command, Work with DG Obj. Trk. Entries display
These possible values and how they correlate between interfaces:
Table 2. Recovery statuses for VSP and native user interface
VSP interfaces Native user interfaces
- Not recovered. Manual *FAILED - The most severe status of any recoveries indicates that the
recovery is required. recovery has failed.
Table 2. Recovery statuses for VSP and native user interface
VSP interfaces Native user interfaces
- Waiting for recovery. For *CAPTURING -The most severe status of any recoveries indicates that the
details, use the Object Details recovery is capturing information on the source system.
action. *WAITING - The most severe status of any recoveries indicates that the
recovery is waiting to be processed. Either the database apply process is
ended or has a backlog while a virtual switch is in progress.
- New Recovery. For details, *NEW - The most severe status of any recoveries indicates that the recovery
use the Object Details action. is new and processing has not yet started.
- (dash) - NA *NONE - No recoveries exist for the object or all known recoveries for the
object have been successfully handled.
You can view more information about a recovery using the Object Details action from the Object
Correction Activity window in VSP.
Replication error counts include failed recoveries

Failed audit recoveries are now reported as replication errors along with errors detected by replication
processes. The locations where MIMIX provides counts of objects with replication errors are updated to
include this behavior.
From VSP, counts appear in the Data Groups portlet:
• The count reported in the Replication DB column is the number of objects identified by file activities,
IFS tracking activities, and object tracking activities that have red action required or yellow attention
statuses, which includes activities associated with failed recoveries for audits.
• The count reported in the Replication Obj column also includes object activities associated with
failed audit recoveries.
• The count reported in the Replication Rcy column includes the new and in-progress (capturing or
waiting to process) recoveries submitted to the replication manager by replication processes and
audits.
These counts also roll up to the application group and are included in the new Replication Environment
portlet.
From the native user interface, the DB Error column count on the Work with Data Groups display
(WRKDG command) includes failed recoveries that were submitted to the replication manager (by
replication or audits) for objects identified by file, IFS tracking, and object tracking entries. In detailed
status, count fields are updated in the following views (DSPDGSTS command):
• Merged view - The Database errors/rcy fields now respectively include: the number of database files,
IFS objects, data areas, and data queues with failed recoveries from audits and the number with new
or in-progress recoveries submitted by audits.
• DB Views 1 and 2 - The Fail Rcys field was added to display the number of database files, IFS
objects, data areas, and data queues with failed recoveries.
• DB View 4 - This view added a row that shows the quantities of failed recoveries associated with the
objects identified by file entries, IFS tracking entries, and object tracking entries.
(MXHA-23111)
Multi-object selection available for manual corrections
One or more of the following toolbar actions have been added to several interfaces within VSP to allow
you to select multiple objects for manual recovery: Start Journaling, Release, Synchronize. Affected
interfaces include:
• Object Correction Activity window
• Objects Changed on Target window
• Virtual Switch Activity window
• File Activity, IFS Tracking, and Object Tracking tabs of the Data Group Details and Activities portlet
• Related Files window
(MXHA-26088)
Auditing Enhancements
This version of MIMIX includes numerous changes associated with auditing best practices, recovery
performance, and reporting of issues. These enhancements and additional changes are described
below:
• Changes to auditing best practices
• Adding the ability to perform recoveries for the File Member Record Counts (#MBRRCDCNT) audit
• Separating policy controls for enabling and disabling auditing from options that select comparison
options to perform
• Improving audit performance by changes to scheduling and recovery processing
• Audits with differences are no longer considered action required
• Integrating audit recoveries into the Object Correction Activity window and other interfaces, and
reporting unresolved audit recoveries as replication errors
• Auditing now supports spooled files. See “Audit and compare support for spooled files” on page 54
for details.
• Auditing restrictions for permissions and masks (RCAC) and temporal tables have been removed.
See.“Auditing supported for RCAC permission and masks” on page 48 and “Auditing supported for
temporal tables” on page 48.
Auditing best practices improvements
Terminology changes
The terms used to refer to the method by which an audit selects objects for auditing is clarified:
• All-objects audits is now used to refer to audit runs that select all objects within the name space
defined by the data group’s selection rules (configuration entries). Previously, all-objects audits were
called “scheduled audits” even though they can also be manually invoked, and prioritized audits also
have scheduling criteria.
• Prioritized objects audits refers to audit runs that select replicated objects to audit based on their
priority classification and the eligibility frequency of the priority category. Prioritized objects audits are
allowed to start automatically within a range of time.
These changes affect numerous portal application and native user interfaces, and are most apparent in
those used for scheduling audits: the Audits tab on the Schedule Summary window, Audit Schedule
portlet, and Audit Schedule Details dialog. Keywords and values on the Set MIMIX Schedules
(SETMMXSCD) command are not affected but prompt text and help are updated.
Automatic recoveries for File Member Record Counts (#MBRRCDCNT) audit

The File Member Record Counts (#MBRRCDCNT) audit is now capable of initiating recovery actions for
each member with detected record count differences. This capability requires that the Audit runs
(AUDRUN) and Audit recovery (AUDRCY) policies are enabled and is dependent on automatic
scheduling settings for the File Data (#FILDTA) audit. The dependency on #FILDTA audit scheduling is
as follows:
• An all-objects run of #MBRRCDCNT performs recoveries when the automatic scheduling for all-
objects #FILDTA auditing is disabled. It does not matter if these #MBRRCDCNT audit runs are
submitted automatically or are manually invoked.
• A prioritized-objects run of #MBRRCDCNT performs recoveries when the automatic scheduling for
prioritized #FILDTA auditing is disabled.
• A differences-only run of #MBRRCDCNT (available only from VSP) performs recoveries when the
automatic scheduling is disabled for either type (all-objects or prioritized-objects) of automatically
submitted #FILDTA auditing.
When the compare phase of the #MBRRCDCNT audit completes and its dependencies for recoveries
are met, the audit recovery phase issues a Compare File Data (CMPFILDTA command) request to
compare and repair each file member with detected record count differences.
While the recovery request is in progress, the file object appears in the list on the Objects with Correction
Activity window with a status of In progress. Also, the associated file entry on the Work with DG File
entries display (WRKDGFE command) has one of the following replication statuses: *CMPRPR,
*CMPACT, or *CMPRLS.
If a requested recovery action (CMPFILDTA) fails:
• The object appears as action required (red) on the Objects with Correction Activity window.
• The file activity appears on the File Activity tab of the Data Group Details and Activities portlet with
an action required (red) icon in the Correction Activity column.
• In the native user interface, the Recovery Status view of the Work with DG File entries display shows
the file entry with a *FAILED recovery status.
The overall audit status for the #MBRRCDCNT audit can now include these values: Recovering
(*RCYACT), Successful (*AUTORCVD), and Differences (*NOTRCVD, *DIFFNORCY) in the Audits
portlet or on the Work with Audits display. The updated description of Differences status is included in
“Audits with differences no longer considered action required” on page 45.
Within the audit results, it is now possible to have a difference indicator value *RECOVERED or
*RCYFAILED for the compared member. The difference indicator is displayed in the File Member Record
Counts Audit Results window, the MXCMPRCDC outfile for the CMPRCDCNT command (for audit runs
only), and other interfaces that display audited objects or an object's auditing history.
Priority-based auditing changes

Changes to scheduling criteria for priority-based auditing better distribute the auditing workload. Also,
how File Data (#FILDTA) and File Member Record Counts (#MBRRCDCNT) priority-based audit runs
select objects for auditing has changed.
Scheduling changes: Within the priority-based audit start range, MIMIX now submits a mixture of
audits on each priority check instead of submitting the same audit for all data groups at the same time.
MIMIX will not start another request for the same audit and data group while the previous request is still
running. On each cycle to start audits within the start time range, the next priority-based audit start
request for that audit type is performed for the next eligible data group. This change applies to new and
upgraded installations.
Existing customers will see the following changes in new data groups created after installing MIMIX
version 9.0:
• Prioritized-object auditing is enabled for #MBRRCDCNT audits. The value None (*NONE) is set for
the Unchanged objects frequency and the Audited with no differences frequency.
• Prioritized-object auditing is disabled for #FILDTA audits. The value None (*NONE) is set for the
Unchanged objects frequency and the Audited with no differences frequency so that these
categories are set as expected if you choose to enable prioritized-object auditing.
Object selection changes for priority-based objects: The #FILDTA and #MBRRCDCNT audits no
longer need to evaluate configured selection rules (data group entries) when determining which objects
are eligible for selection. This improves the performance of these audits.
Auditing policy changes

Multiple new policies replace the Audit level (AUDLVL) policy, and values have changed for the Audits to
include for compliance (AUDINCMPL) policy.
Audit level (AUDLVL) policy replaced by Audit runs and Audit Options
New policies in MIMIX 9.0 separate the controls for enabling and disabling the ability to perform audits
from controls that determine the comparison option (previously called audit level) to use for the subset of
audits that support multiple comparison options. These changes make both capabilities more intuitive
and allow you to easily disable auditing while retaining audit comparison options. In previous versions,
both capabilities were performed using the Audit level (AUDLVL) policy, which is no longer available. The
Instance Policies dialog, Data Group Policies dialog, Audits tab of the Policy Summary window and the
Set MIMIX Policies (SETMMXPCY) command are affected. You will also see related changes in other
locations that previously included audit level information.
The new policies can be set for the installation and overridden by a data group level value.
Audit runs (AUDRUN) - This policy determines whether audits are allowed to run when requested and
applies to all auditing requests regardless of whether they are invoked by the automatic scheduler or
manually by user action. Valid values are:
• Enable (*ENABLED) - Auditing requests are allowed to run when requested or scheduled. This is the
shipped default.
• Disable (*DISABLED) - Auditing requests are prevented from running. Use this value when you need
to disable auditing completely, such as when performing a backup from a target system, during
system or network maintenance, or on a test data group.
Audit Options policies: Three audits support multiple comparison options: File Data (#FILDTA),
Directories (#IFSATR), and Folders (#DLOATR). Each of the three audits now have separate audit
options policies for setting the comparison option to use. These policies support the ability to specify
different values to use for all-objects audit requests and for prioritized and differences audit requests. All-
objects audit requests select all objects within the data group’s configured name space for the class of
objects checked by the audit. Prioritized and differences audit requests select objects based on their
object-auditing priority or previous auditing differences. By design, each run of a prioritized or differences
audit may select a unique subset of the objects replicated by the data group that are within the class of
objects checked by that audit.
• File data percentage to audit (FILDTAOPT) - Specifies the percentage of file records to compare in
file members of each physical file (PF) that is selected for auditing by a run of the File Data
(#FILDTA) audit. A value less than 100 percent reduces the quantity of records checked for the files
selected.
Valid values for both elements are:
– 100 - One hundred percent of the records for each file member are compared for the selected
files. This is the most extensive check available and is the shipped default value.
– 20 - Twenty percent of the records for each file member are compared for the selected files. (It will
take 5 audit runs to check all data that existed at the time the first audit started.)
– 5 - Five percent of the records for each file member are compared for the selected files. (It will
take 20 audit runs to check all data that existed at the time the first audit started.)
• Directory audits (IFSAUDOPT) - Specifies whether to compare attributes and data, or only
attributes, of the objects selected for auditing by a run of the Directory (#IFSATR) audit.
Valid values for both elements are:
– Attributes and Data (*ALL) - Attributes and data within the selected IFS objects are compared.
This is the most extensive check available and is the shipped default value.
– Attributes (*ATTRONLY) - Only attributes of the selected IFS objects are compared.
• Folder audits (DLOAUDOPT) - Specifies whether to compare attributes and data, or only attributes,
of the DLO objects selected for auditing by a run of the Folder (#DLOATR) audit.
– Attributes and Data (*ALL) - Attributes and data within the selected DLO objects are compared.
This is the most extensive check available and is the shipped default value.
– Attributes (*ATTRONLY) - Only attributes of the selected DLO objects are compared.
Note: Best practice is to enable auditing and to allow audits that support options to perform the most
extensive checking available in all of the audit option policies. If you use a lower value for an
auditing option policy, consider its effect on how often you need to guarantee data integrity
between source and target systems. Regardless of the option you use for daily operations,
Syncsort strongly recommends running audits using the most extensive checking option before
performing a planned switch to the backup system and before switching back to the production
system to ensure that 100 percent of the data is valid on the target system.
A value that performs less than the most extensive check is a compromise that may reduce the audit’s
effect on system resources, performance, or amount of time needed to run while increasing exposure to
data integrity issues. When choosing values, consider how much data there is to compare, how
frequently the data changes, how long the audit runs, how often you run the audit, and how often you
need to be certain that data is synchronized between source and target systems.
Policy mapping for upgrades: When upgrading to MIMIX 9.0, the AUDLVL policy settings are mapped
to new policies as follows:
Table 3. Policy mappings for upgrades
Previous Policy New Policies
Audit level Audit runs File data per- Directory audits Folder audits
(AUDLVL) (AUDRUN) centage to audit (IFSAUDOPT) (DLOAUDOPT)
(FILDTAOPT)
Disabled Disable 100 Attributes and Data Attributes and Data

(*DISABLED) (*DISABLED) (*ALL) (*ALL)
10 (*LEVEL10) Enable 5 Attributes Attributes

(*ENABLED) (*ATTRONLY) (*ATTRONLY)
20 (*LEVEL20) Enable 20 Attributes and Data Attributes and Data

(*ENABLED) (*ALL) (*ALL)
30 (*LEVEL30) Enable 100 Attributes and Data Attributes and Data

(*ENABLED) (*ALL) (*ALL)
On the Audits tab of the Policy Summary window, the Audit Runs column replaces the Audit level
column, and columns are added for the auditing options. Also, the Audits tab now has two Data Group
columns, located on the left and right sides, so that the data group name can be seen when scrolling
right to access actions.
Audits included for compliance (AUDINCMPL) policy changes

The value Based on Audit Level (*AUDLVL) has been replaced by the new value, Based on Audit
Options (*AUDOPT), which considers any applicable auditing options policies when determining what
audits are evaluated for compliance. The #MBRRCDCNT audit is never evaluated for compliance when
the value of the File data (FILDTAOPT) auditing option in effect is 100.
The value Configured Objects and Audit Options(*BOTH) is updated to include the exception, which is:
the #MBRRCDCNT audit is never evaluated for compliance when the value of the File data
(FILDTAOPT) auditing option in effect is 100.
Optionally override auditing policies when submitting audits manually

MIMIX added the ability to override certain auditing policy values when manually or programmatically
invoking an audit. This is useful when you need to run audits at their highest level of checking and you
do not want to change auditing policies to do so, such as when auditing prior to a planned switch. This
capability is implemented in the Run Audit dialog and Run Audits dialog from VSP and through new
options on the Work with Audits display and a new parameter on the RUNRULE and RUNRULEGRP
commands.
On the dialogs and commands, the Override audit policies field (OVRAUDPCY parameter) specifies
whether this run of the specified audits will override the following auditing policies: Audit runs (AUDRUN)
and Audit options (FILDTAOPT, IFSAUDOPT, and DLOAUDOPT). The policies that can be overridden
are described in “Audit level (AUDLVL) policy replaced by Audit runs and Audit Options” on page 41.
Possible values are:
• No, use current settings (*NONE).
This is the default value. None of the auditing policies are overridden. If auditing is enabled
(AUDRUN policy), the specified audit will be run. If a specified audit has an applicable auditing
options policy, the current settings of that policy are used.
• Yes, run and check attributes and all data (*ALL).
The specified audit will run regardless of whether auditing is enabled or disabled (AUDRUN policy)
and with values that override any applicable auditing options policies. If a specified audit has an
applicable auditing option policy, the audit will run using the highest possible auditing option value
regardless of the policy setting.
Note: Only the File Data (#FILDTA), Directory (#IFSATR), and Folder (#DLOATR) audits have
auditing options policies (FILDTAOPT, IFSAUDOPT, and DLOAUDOPT, respectively).
• Yes, run object existence-only check (not recommended).
If the specified audit is Libraries (#OBJATR), Folders (#DLOATR), File Attributes (#FILATR), File
Member Attributes (#FILATRMBR), or Directories (#IFSATR), the audit will be run regardless of
whether auditing is enabled or disabled, and the audit will only perform an existence check on the
selected objects. No other audits will be run. An existence check is useful to confirm that objects
within the configured name space for an audit exist on both systems.
Note: This value is available only from the dialogs in VSP. An existence check does not compare
object data or attributes and does not ensure data integrity between systems. An existence
check should not be used to determine switch readiness and does not determine auditing
compliance. This choice is not supported for the File Selection Rules (#DGFE), File Data
(#FILDTA), and File Member Record Counts (#MBRRCDCNT) audits.
On the Work with Audits display (WRKAUD), the new option, 39=Run rule with override, will start the
selected audit immediately regardless of whether auditing is enabled (AUDRUN policy) and overrides
any applicable auditing options (FILDTAOPT, IFSAUDOPT, or DLOAUDOPT policies) to perform the
highest possible level of checking. This is equivalent to specifying the following command: RUNRULE
OVRAUDPCY(*ALL).
Audit recovery improvements

Most recovery actions for audits that compare attributes are now submitted to the MIMIX Replication
Manager (MXREPMGR) for processing. This improves performance by allowing multiple recovery
actions for an audit to run in parallel and affects the Folders (#DLOATR), File Attributes (#FILATR), File
Member Attributes (#FILATRMBR), Directories (#IFSATR), and Libraries (#OBJATR) audits. The
duration of an audit's recovery phase now amounts to the time needed to submit recovery actions and
perform recoveries for the few remaining types of problems still handled by the audit job itself. The audit
does not wait for the submitted recoveries to complete before the audit completes and considers the
submitted recoveries as successes towards the overall audit results status.
Audit recovery actions submitted to the replication manager are processed like other automatic recovery
actions submitted by replication processes. The replication manager either performs a synchronization
or submits a U-MX journal entry to the journal used for replication of the affected object.
In the audit results, a difference indicator value of *RCYSBM indicates that the recovery for the object's
detected difference has been submitted to the replication manager for recovery processing.
Because the replication manager is processing recovery actions from audits, you will now see the
affected objects identified in the Object Correction Activity window. If the submitted recovery action fails
or the object cannot be recovered, the object will also be identified on the appropriate tab on the Data
Group Details and Activities portlet. In the native user interface, the failed recovery action is similarly
reported on the appropriate display (Work with DG File Entries, Work with DG Activity Entries, Work with
DG IFS Trk. Entries, or Work with DG Obj. Trk. Entries). From any of these interfaces, you can take
manual recovery actions to synchronize the object the same as if its error had been originally detected
by replication processes.
Also, if the remaining audit recoveries handled by the audit job fail, they are tracked internally and will
also appear in the Object Correction Activity window and the other interfaces identified above.
In the Work with Audited Objects display and Work with Audited Object History displays (WRKAUDOBJ
and WRKAUDOBJH commands), the audited status category *RCVD is updated to include objects with
a summary status of *RCYSBM as well as *RECOVERED.
Note: If the data group is inactive or exceeds its database apply threshold when the audit runs and the
value of the Action for running audits policy (RUNAUDIT) in effect is Compare Recover
(*CMPRPR), any recovery actions for differences detected by the audit are queued for the
replication manager and will be processed after the data group starts or the backlog that
exceeded the threshold is resolved. If the Automatic audit recovery policy (AUDRCY) is disabled,
any objects with differences are reported as failed recoveries on the appropriate interfaces.
Object activities (entries) support new U-MX subtypes

MIMIX object replication processes support two new U-MX subtypes, RD (Audit recovery disabled) and
RQ (Audit recovery failed). These allow object recovery actions submitted by audits to have a
corresponding object activity that represent an unresolved difference due to disabled audit recoveries or
an audit difference that failed to be recovered.
Audits with differences no longer considered action required

The following changes to auditing status values are part of efforts to drive unresolved audit problems into
more visible areas of the product, where they can be identified and manually resolved the same way
regardless of which process identified the not-synchronized condition. These changes also ensure that
one issue for an object is reported as red action required only in one location.
Most audit recoveries are submitted to the replication manager, and audits do not wait for submitted
recoveries to end before the audit completes. Additionally, any unresolved differences are now reported
as replication errors elsewhere in the product. Therefore, the audit statuses of “Differences, no recovery”
(*DIFFNORCY) and “Differences detected, some objects not recovered” (*NOTRCVD) are now
considered successful statuses. In VSP, these audit statuses now display a new icon within the
Status column in the Audits portlet and the Audits Sts column of the Data Groups portlet and the Audit
column in the Replication Environment portlet. These statuses are reported as OK (green) in the overall
status for the data group, and in status rolled up to the application group in the Replication Environment
portlet.
Any audits that previously had either of these statuses prior to upgrading to MIMIX 9.0 will continue to
show them as action required (Red X) until the audits run again. Instances running on earlier versions of
MIMIX will continue to display this status as action required (Red X).
Differences (*DIFFNORCY) - The description of this status is updated, as follows:
The compare phase of the audit detected differences but automatic recovery actions were not attempted
due to policies in effect. Either Automatic audit recovery (AUDRCY) policy was disabled or audit
recovery actions were prevented from running because the data group was inactive or had an apply
process that exceeded its threshold (RUNAUDIT policy). For a File Member Record Counts
(#MBRRCDCNT) audit, this status can also be the expected behavior when automatically invoked File
Data (#FILDTA) audits perform recoveries for data within files for the data group. A #MBRRCDCNT
audit will not perform recoveries when automatic scheduling exists for the #FILDTA audit with the same
type of selection criteria (all-objects or priority-based objects) as the #MBRRCDCNT audit.
Other auditing-related changes
The following additional changes associated with auditing are included.
Ending an audit and Ended status changes

The following changes provide more consistent behavior and status when audits are ended.
Audit ended (*ENDED) status: This status is now possible for all audits. The reason why an audit
ended can be seen in the audit details and is one of the following:
• The audit was ended during its recovery phase because of user action. User action includes the Stop
action for the audit from VSP, option 10 (End) from either the Work with Audits display or the Work
with Recoveries display, or manually ending the audit job with the ENDJOB command.
• The audit was ended during its recovery phase because it exceeded the Maximum rule runtime
(MAXRULERUN) policy in effect.
• The #FILDTA or #MBRRCDCNT audit ended during its compare phase for one of the following
reasons:
– The data group status became inactive.
– The DB apply threshold action (DBAPYTACT) in effect caused the audit to end.
– The Maximum rule runtime (MAXRULERUN) policy in effect was exceeded.
Ending an audit: When an audit is ended by a user, either from the Stop Audit dialog or option 10=End
from the Work with Audits display, the resulting audit status now depends on whether the request
occurred during its compare phase or recovery phase. The resulting status and behavior is as follows:
• If the audit is in its compare phase (*CMPACT status) or if it is the File Data (#FILDTA) audit, the
audit is ended and its status is changed to Audit failed (*FAILED). No results are available for any
objects that may have been compared.
• If the audit is in its recovery phase (*RCYACT status), the audit is ended and its status is changed to
Audit ended (*ENDED). This is a change in behavior for most audits.
When the status becomes *ENDED because of user action, the audit's reason for ending is *ENDJOB,
which is visible when audit details are displayed. Objects that have not yet been recovered or submitted
for recovery will not be available in the Object Correction Activity window, but you may still be able to
manually recover the objects from the audit results in VSP. Objects for which a recovery was submitted
(*RCYSBM status) are identified in audit results and those recoveries will be processed through
replication processes.
Final results for objects with submitted recoveries can be viewed in the Object Correction Activity
window. The Audit Results interface (outfile) will not be updated.
Changes to audit status check in conditions that end switch

Because audits with differences are now considered an OK status and differences that could not be
recovered are surfaced as failed activity like any other error found by replication, the check for audit
status conditions that will end a switch has changed. The only remaining audit status conditions
considered as red-action required or yellow-attention indicate that audits did not run. The following
locations are updated:
• Step program MXAUDDIFF is replaced by MXAUDNORUN in application group procedures for
prechecking and switching (PRECHECK, PRECHKVRT, SWTPLAN, SWTUNPLAN, SWTVRT).
Existing procedures are automatically updated during the upgrade to MIMIX 9.0.
• In the Conditions that end switch field in the Switch Data Group dialog, the value Audit Differences
has been renamed to Audit Not Run.
• Conditions that end switch (ENDSWT) parameter on the Switch Data Group (SWTDTG) command,
the value *AUDDIFF is replaced by *AUDNOTRUN. If the value *AUDDIFF is used in automation, it
is processed as *AUDNOTRUN.
The check performed by this step program or value will end the procedure or switch data group request
if any audits exist with statuses that require action or attention. This includes audit statuses indicating
that the audit did not run due to policy, failed, or was ended.
Hold and Release actions for audit recoveries removed

Because of the changes to audit recovery processing, there is no longer a need to hold or release an
audit recovery job. The Held status (*RCYHLD) is no longer possible for audit recoveries. The Hold and
Release actions on the Audits portlet and on the Audits tab of the Audits, Recoveries, and Notifications
portlet, as well as their resulting dialogs, have been removed. In the native user interface, options
13=Hold job and 14=Release job have been removed from the Work with Recoveries display.
The Held status for an audit, which was only displayed on the Audits portlet in VSP, is no longer possible
for instances running MIMIX 9.0.
Changes to marking an audit resolved by user

The Mark Resolved action on the Work with Audits portlet and on other auditing interfaces in VSP, and
option 46=Mark Resolved on the Work with Audits display and Work with Audit History display, are no
longer available for audits with a status of Not recovered (*NOTRCVD) or Differences, no recovery
(*DIFFNORCY).
Audit-related changes to Subscription Events

The event “Audits with action required status” is no longer sent for audits with differences detected within
instances running MIMIX. 9.0.
Changes to audit-related outfiles and Retrieve commands

The following outfile and Retrieve commands have been updated:
• The MXAUDHST outfile (WRKAUDHST command) has the following changes:
– The AUDLVL field has had its heading renamed to Auditing Option, and no longer supports the
value DISABLED. Its possible values are now: *ATTRONLY, *ALL, 5, 20, 100.
Note: The same changes were also made to the MXAUDOBJ outfile (WRKAUDOBJ and
WRKAUDOBJH commands.
– The Reason for *ENDED audit status (ENDREASON) field added a new value of *ENDJOB.
• Recovery status (RCYSTS) is added as a field or parameter in the following outfiles and Retrieve
commands. This is a CHAR(10) field with these possible values: *CAPTURING, *FAILED, *NEW,
*NONE, and *WAITING.
– Outfiles: MXDGFE (WRKDGFE command), MXDGIFSTE (WRKDGIFSTE command),
MXDGOBJTE (WRKDGOBJTE command)
– Retrieve Data Group File Entry (RTVDGFE), Retrieve DG IFS Trk. Entry (RTVDGIFSTE).
• The MXDGSTS outfile (WRKDG command) added the following fields for failed recovery counts,
which are type PACKED (5 0) and have possible values of 0-99999.
– File entry recovery count (failed) (FERCYFAIL)
– IFS tracking entry recovery count (failed) (ITERCYFAIL)
– Object tracking entry recovery count (failed) (OTERCYFAIL)
These are also added as parameters to the Retrieve Data Group Status 2 (RTVDGSTS2)
command, which is new. MIMIX 9.0 updates to the Retrieve Data Group Status (RTVDGSTS)
command have caused it to each its maximum number of parameters.
• The MXDGACTE outfile (WRKDGACTE command) added these two new possible values for the U-
MX subtype (UMXSUBTYPE) field: RD (Audit recovery disabled), RQ (Audit recovery failed).
(MXHA-23106, MXHA-23109, MXHA-23111)
Auditing supported for RCAC permission and masks

The File Attributes (#FILATR) audit now audits and recovers permissions and masks (row and column
access control (RCAC)) associated with files eligible for replication.
The Compare File Attributes command now supports a new attribute, *RCACIND (Row and Column
Access Control (RCAC) indicator) for the Attributes to compare (CMPATR) and Attributes to omit
(OMITATR) parameters. This attribute indicates whether RCAC settings are equal on both systems.
For more information about configuration requirements for replicating files that use permissions and
masks, see the MIMIX Administrator Reference book.
(MXHA-24298)
Auditing supported for temporal tables

The File Attributes (#FILATR) audit now audits and recovers temporal table relationships for replicated
system-period temporal tables and their associated history tables.
The Compare File Attributes command now supports a new attribute, *TMPTBLIND (Temporal table
indicator) for the Attributes to compare (CMPATR) and Attributes to omit (OMITATR) parameters. This
attribute indicates whether the temporal table relationship settings are equal on both systems.
For more information about configuration requirements for replicating temporal tables, see the MIMIX
Administrator Reference book.
(MXHA-22644)
Replicating jobs associated with *JOBQ objects

For *JOBQ objects that are configured for replication, MIMIX now supports the ability to optionally
replicate the jobs within the job queues. When this capability is configured and a submit job request
occurs, system journal replication processes will replicate journal entries associated with submitting the
job and subsequent changes to the job state. The replicated jobs are placed in a staging area and are
not actually submitted by MIMIX on the target system.The command string of the submitted job that has
been replicated is available on the target system until either MIMIX has processed a job completion
journal entry for the source job or user action is taken. The replicated jobs that exist on a system can be
seen using the new Work with Replicated Jobs display (WRKREPJOB command) from the native user
interface.
This capability is useful in the event of a switch. The jobs from the original source system that did not
complete before the switch can be submitted or discarded on the new source system after the switch.
Changes to switch processing will now check for the existence of replicated jobs on the current source
system as a condition that ends switch processing. In application group environments, the switch
procedures also wait for you to either submit or remove any remaining previously replicated jobs on the
new source system following the switch and sets an indicator if any replicated jobs still exist for the
affected data groups.
Note: MIMIX does not replicate jobs submitted before the configuration changes are made available to
replication processes. Replication must be stopped and started to make configuration changes
available. When the data group is started with replication of jobs configured, MIMIX checks the
QAUDLVL system value for the presence of either *JOBDTA or *JOBBAS and, if necessary, will
change QAUDLVL to add *JOBBAS to ensure that journal entries for job level auditing can be
placed in the system journal. This may result in more journal entries in the system (QAUDJRN)
journal. MIMIX does not update the QAUDLVL system value to remove the *JOBDTA or
*JOBBAS value if you later change configuration to no longer replicate jobs.
Replication of job queues requires a switchable data group. Therefore, this capability is not supported for
MIMIX DR.
Action Required:
To use this capability, eligible environments must modify the configured selection rules (data group
object entries) to allow replication of jobs associated with replicated *JOBQ objects. Replication
processes must be stopped and started to make the changes available to replication.
Configuration changes for replicating jobs in a job queue

In resource groups or data groups that support replication from the system journal or from both the
system and user journal, you can configure selection rules (data group object entries) so that any *JOBQ
objects identified for replication will also have their submitted jobs replicated.
In a selection rule (data group entry) that includes objects for replication and specifies an object type of
*ALL or *JOBQ, you can use the new Replicate jobs on job queue field (REPJOB parameter) to specify
whether jobs on any job queues identified by the rule are replicated to the target system.
• No (*NO) - No jobs are replicated for any job queues identified by the selection rule (data group
object entry). This is the shipped default value.
• Yes (*YES) - The jobs on job queues identified by this selection rule are replicated.
This field is added to the Include Libraries and Objects dialog and Selection Rules Details dialog (for
libraries) in VSP and to the ADDDGOBJE, CHGDGOBJE, and LODDGOBJE commands. Similarly, the
REPJOB field is also added to RTVDGOBJE command and the MXDGOBJE outfile for the
WRKDGOBJE command.
Switch changes to support replicating jobs

The following new steps have been added to procedures for switching application groups:
MXCHKRJB - Checks for replicated jobs. This step checks to see if there are remaining replicated
jobs from the previous switch that still exist on the current source node of the data group. This step
fails if there are any remaining replicated jobs. This step is added to and enabled in:
• PRECHECK procedure with an error action of *CONT.
• SWTPLAN and SWTUNPLAN procedures with an error action of *MSGW. In these procedures,
this step runs before the actual switch operation occurs.
MXWAITRJB - Wait for replicated jobs to be submitted/removed. This step waits for all replicated
jobs on the new source node to be manually submitted or removed.
This step is added to and enabled in the SWTPLAN and SWTUNPLAN procedures with a before
action of *WAIT and an error action of *MSGW. This step runs after the switch operation occurs.
MXSETRJBI - Set replicated jobs indicator. This step sets an indicator if there are remaining
replicated jobs on the new source node for the data group. The data group cannot be switched again
until all remaining replicated jobs are submitted or removed.
This step is added to and enabled in the SWTPLAN and SWTUNPLAN procedures with an error
action of *QUIT. This step runs after the switch operation occurs and cannot be disabled or removed.
Optionally, you can also use any of the following new steps which are added as disabled steps in the
SWTPLAN and SWTUNPLAN procedures. User action is required to enable these steps. When
enabled, the following steps have a before action of *WAIT and an error action of *MSGW.
MXSBMRJB - Submits all replicated jobs. This step submits all replicated jobs on the new source
node, allowing the jobs to run.
MXSBMRJBN - Submits all new (not started) replicated jobs. This step submits all replicated jobs
that had not yet been started on their original source node to run on the new source node.
MXRMVRJB - Removes all replicated jobs. This step removes all replicated jobs from the new
source node to prevent the jobs from being submitted to run.
On the Switch Data Group dialog and SWTDG command, the new value, Replicated Jobs (*REPJOB), is
added to the Conditions that end switch field (ENDSWT parameter). This value will cause the switch
process to end if any replicated jobs exist on the source system. In a planned switch, this is also
included with the value Default (*DFT).
The replicated job indicator

If a switch occurred and there are replicated jobs remaining on the current source system, these jobs
require evaluation and must either be submitted or removed before the next switch. The switch
procedure sets an indicator to make you aware of this need.
In VSP, this condition is indicated by the Attention icon next to the name of the affected application
group, resource group, or data group in the following interfaces: Replication Environment portlet,
Application Group Resource Groups portlet, Data Groups portlet, Data Group Details and Activities
portlet, Application Group Details window, Data Group Details window, RPO/RTO Analysis window, Start
Application Group dialog, Start Resource Group dialog, and Start Data Group dialog.
In the native user interface, the name of the data group is highlighted in yellow on the Work with Data
Groups (WRKDG) display.
The Replicated job indicator field (REPJOBIND) is added to the RTVDGSTS2 command and to the
MXDGSTS outfile for WRKDG command, with possible values of *YES and *NO.
Viewing and working with replicated jobs

The Work with Replicated Jobs display identifies jobs that MIMIX replicated to the local system. This
display is only available from the native user interface by using the WRKREPJOB command or by using
option 59=Replicated jobs, which has been added to the following displays:
• Work with Application Groups display
• Work with Data Rsc. Grp. Ent. display
• Work with Data Groups display
When the local system is the current target system, the display lists the jobs that have been replicated to
this system. During normal replication activity, the listed jobs are automatically removed when MIMIX
processes the journal entry for the job completion from the source system. Following a switch, the listed
jobs need to be either submitted or removed before the data group can be is switched another time.
When the local system is the current source system, the display lists the jobs that were replicated to the
system prior to the last switch, when this system was the target. These jobs did not complete on the
originating system before the time of the last switch. Evaluate whether these jobs should be removed or
submitted to run on the local system before switching the data group.
You can use options to display or print details for the specified job, submit the job to run on the local
system, or remove the job from the list. Some actions may not be appropriate for the current role (source
or target) of the local system.
• Use option 4=Remove to remove a replicated job from the list. When you remove a job, a
confirmation display appears. Once a job is removed, it cannot be submitted. The RMVREPJOB
command can also be used to remove a job.
• Use option 5=Display to display the command string that was submitted on the original system.
• Use option 7=Submit to submit the command string of the replicated job on the local system. You
have the option to add or replace parameters (other than the Command to run (CMD) parameter)
before the command string is submitted. Any differences of Submit Job (SBMJOB) command
defaults or name-mapping of objects between systems will not be reflected in the shown command
string. If any differences are important when submitting the command string, edit the command string
accordingly. After the job is submitted on the local system, it is removed from the list of replicated
jobs. The SBMREPJOB command can also be used to submit a job.
The Work with Replicated Jobs (WRKREPJOB) command also supports the ability to output results from
the local system to the MXREPJOB outfile.
MIMIX also supports retrieving information about replicated jobs on the local system with the Retrieve
Replicated Jobs (RTVREPJOB) command.
The Open MIMIX List (OPNMMXLST) command added the value *REPJOB to the Type of request
(TYPE) parameter to support opening a list of all replicated jobs from the local system. This is for use
with RTVREPJOB command.
(MXHA-23617)
Improved support for spooled files

Spooled files are now a fully supported object type in MIMIX and can now be fully configured to be
replicated or excluded. Replicated spooled files can now be audited and any spooled files with
differences can be recovered via MIMIX recovery processes. MIMIX is changed so that the five pieces of
information needed to uniquely identify a spooled file are available: spooled file name, spooled file
number, and the three-part spooled file job (name/user/number). One or more parameters or fields have
been added to interfaces to allow you to specify a unique spooled file. For replication, this is
accomplished by adding the ability to specify *SPLF as an object type and adding fields that allow you to
specify or display the spooled file's name, job name, and job user. Changes include:
Configuration
The MIMIX portal application in VSP includes changes to selection rule dialogs to support enhanced
spooled file configuration. Selection rules now provide the ability to identify specific spooled files for
replication. The selection rules allow you to specify *SPLF for the Type field and new subfields for the
Replicate spooled files field allow you to fine-tune spooled file selection by the Spooled file name, Job
name, and Job user subfields. Each uses a default value of All, or can specify a name or generic name.
Changes to the Include Libraries and Objects, Copy Selection Rule, Selection Rule Details, and Exclude
Libraries and Objects dialogs provide significantly more flexibility to include or exclude spooled files and
include the following:
• When adding or changing a rule that includes objects in replication and Yes is specified for Replicate
spooled files, the Type field can use the default All or specify *OUTQ or *SPLF, and the Spooled file
name, Job name, and Job user fields can use the default All or be qualified with a name or generic
name or number.
• When adding a rule to exclude objects from replication and the Type field is *SPLF, the Spooled file
name, Job name, and Job User fields can use the default value All or be qualified with a name or
generic name or number.
• When copying a rule, the spooled file fields will be displayed, enabled, or disabled depending on the
Type value selected. Refer to the corresponding help topic in VSP for more information.
The Move Selection Rule dialog supports *SPLF for the Type field and displays the values for the
Replicate spooled files field and subfields when the Type is All, *OUTQ, or *SPLF.
In the Data Protection Reports, the protection status of a library is impacted by explicitly included or
excluded spooled files.
In the native user interface, data group object entries now provide the ability to identify specific spooled
files for replication. The object entry commands now include the value *SPLF for the Object type
(OBJTYPE) parameter and a new parameter, Spooled file criteria (SPLF) that has three elements
(Spooled file name, Job name, and Job user). Each uses a default value of *ALL or can specify a name
or generic name.
Changes to the Add Data Group Object Entry (ADDDGOBJE) and Change Data Group Object Entry
(CHGDGOBJE) commands that provide significantly more flexibility to include or exclude spooled files
include the following:
• When adding or changing an entry to include objects in replication (PRCTYPE(*INCLUDE)) and
*YES is specified for the Replicate spooled files (REPSPLF), the Object type (OBJTYPE) parameter
can use the default *ALL or specify *OUTQ or *SPLF, and the Spooled file criteria (SPLF) parameter
can use the default value *ALL or be qualified with a name or generic name or number.
• When adding or changing an entry to exclude objects from replication (PRCTYPE(*EXCLUDE)) and
*YES is specified for Replicate spooled files (REPSPLF), the only valid Object type (OBJTYPE) is
*SPLF, and the Spooled file criteria (SPLF) can use the default value *ALL or be qualified with a
name or generic name or number.
Other configuration commands that support *SPLF for the OBJTYPE parameter and can specify values
for the Spooled file criteria parameter include:
• Display DG Object Entry (DSPDGOBJE)
• Load Data Group Object Entry (LODDGOBJE)
• Remove DG Object Entry (RMVDGOBJE)
• Retrieve Data Group Object Entry (RTVDGOBJE)
The Work with DG Object Entries display added a new view for spooled file information and includes a
column for spooled file criteria (Splf Crit). The possible values include:
• Specific - Additional criteria exists. Use option 5=Display or 6=Print to view the additional selection
criteria for spooled files.
• *ALL - All spooled files for output queues matching this data group object entry are replicated.
• - (dash) - No spooled files are replicated based on this data group object entry.
The Retrieve Data Group Object Entry (RTVDGOBJE) command also has three new CL variable
parameters for the three-part spooled file criteria: spooled file name, spooled file job name, and spooled
file job user (RTNSPLFNAME, RTNSPLFJOB, and RTNSPLFUSR) to qualify the entry retrieved by the
request.
The Copy Data Group Object Entry (CPYDGOBJE) command supports *SPLF for the OBJTYPE
parameter and includes two parameters, From spooled file criteria (FROMSPLF) and To spooled file
criteria (TOSPLF). These parameters support *ALL, generic names, and fully specified names. The
default value for each element in FROMSPLF is *ALL. The default value for each element in TOSPLF is
*FROMSPLF, which means that the values specified for the corresponding spooled file name element of
the FROMSPLF parameter are used.
Fields added to the WRKDGOBJE outfile, MXDGOBJE, include Spooled file name (SPLFNAME),
Spooled file job name (SPLFJOB), and Spooled file job user (SPLFUSR).
Replication
Object replication will now replicate the specified spooled file or its attributes that are identified by
configured selection rules (object entries).
The MIMIX portal application in VSP includes changes to dialogs, windows, and tabs to support
enhanced spooled file replication.
You can now see your replicated spooled files in the Replicated Objects window and portlet, which now
support spooled file objects (Type field displays *SPLF). The Source Object field displays spooled file
information in the format outputq(spooledfilename/spooledfilenumber). The Target Object field displays
the spooled information in library/outputq(spooledfilename/spooledfilenumber) format. Hover the cursor
over the spooled file to display the spooled file name, number, and three part job name (splname/splnum
- jobnum/jobuser/jobname).
• Object Details dialog - When the Type is *SPLF, the source and target spooled file information is
displayed, including Source spooled file and Target spooled file fields with their respective Number,
Output queue, and Job fields.
• Compare Object Details from Nodes window - Spooled file comparisons display *SPLF in the Type
field and Spooled file name, Number, and Job (jobnum/jobuser/jobname format) information.
– Compare Object Details from Nodes, General tab - Spooled files with differences between nodes
that are significant to replication display the icon. For replicated attributes that are different
between nodes, the icon is displayed. For attributes that are different between nodes but that
are not replicated, the icon is displayed. Flyover text provides information and suggested
recovery action.
You can see current spooled file activity on the Object Activity tab in the Data Group Details and
Activities portlet on the Data Groups page. The Object Activity Details window displays spooled file
information in the Spooled file and Type fields.
In the native user interface, you can see the current and completed activity for Spooled files on the Work
with DG Activity Entries (WRKDGACTE) and the Work with Data Group Activity (WRKDGACT) displays.
Both support *SPLF for the OBJTYPE parameter. On WRKDGACT, you can specify values for the
Spooled file criteria (SPLF) parameter and on WRKDGACTE, you can specify the Spooled file name
(SPLF) and Spooled file job (SPLFJOB) parameters. The spooled file information view of the Work with
DG Activity Entries display (accessed using F11) added a new Job Name column to the existing SPLF
Information columns (Name, Number), which displays the name of the job that produced the spooled file
number. The full spooled file name, number, and three-part job name is shown on the 5=Display panel
and 6=Print details output.
Audit and compare support for spooled files

Auditing spooled files now supports the ability to detect differences and perform recovery for individual
spooled files within an output queue. Spooled files are supported for all three types of audit runs (all
objects, prioritized, and differences only).
The Libraries (#OBJATR) audit now supports the auditing of spooled files. When Do not recover is
specified for the Object on target policy (OBJONTGT(*DELETE)) and No is specified for the Keep
deleted spooled files parameter (KEEPSPLF(*NO)) for the data group object entry, then spooled files
that exist only on the target system are deleted by the audit. When KEEPSPLF(*YES) is specified, then
spooled files that exist only on the target are not considered as differences.
Action Required
To prevent spooled files in replicated output queues that were placed in the output queues using
processes outside of replication from being deleted on the target system by the Libraries audit, set the
Keep deleted spooled files parameter (KEEPSPLF) for the library selection rules (data group object
entries) that replicate spooled files to Yes (*YES).
Interface changes:
The MIMIX portal application in VSP includes changes that support spooled file replication
enhancements in the following:
• Libraries Audit Results (#OBJATR) window - Displays the spooled file information in the Object fields
for both Source and Target.
– Details row action - Displays spooled file information in the resulting Libraries Audit Results
Details window.
– Libraries Audit Results Details window - Supports the Compare Details and Synchronize row
actions for spooled files.
• Compare Details row action - Displays spooled file information in the resulting Compare Object
Details from Nodes window.
• Audited Objects window - Displays audited spooled files in the list of objects in the upper pane of the
window.
• Object Audit History window - When the Type field is *SPLF, the Object on node fields display the
spooled file information. The Job field is displayed directly below them.
In the native user interface, the Work with Audited Objects (WRKAUDOBJ) and Work with Audited Obj.
History (WRKAUDOBJH) commands include spooled file support for any of the Object, Object Type,
Spooled file criteria, Spooled file name and Spooled file job parameters (and/or elements). On the
resulting Work with Audited Objects and Work with Audited Obj. History displays, spooled files are
displayed in the format NAME/NUMBER JOBNBR/JOBUSER/JOBNAME.
Fields added to MXAUDOBJ, the outfile for both WRKAUDOBJ and WRKAUDOBJH, include Spooled
file name (SPLFNAME), Spooled file number (SPLFNBR), Spooled file job name (SPLFJOB), Spooled
file job user (SPLFJOBUSR), and Spooled file job number (SPLFJOBNBR).
The Compare object attributes (CMPOBJA) command includes the following changes:
• The Object type element of the Object (OBJ) parameter now includes the *SPLF value.
• The Object parameter added two new qualified elements (Spooled file name, Spooled file job) and
specify *ALL as the default. The Spooled file name can be qualified by its number, and the Spooled
file job can be qualified by the job user and job number. Generic names and *NONE may also be
specified.
• The Attributes to compare (CMPATR) and Attributes to omit (OMITATR) parameters now support the
Spooled file attributes indicator (*SPLATRIND).
Fields added to CMPOBJA outfile, MXCMPOBJA, include Spooled file name (SPLFNAME), Spooled file
number (SPLFNBR), Spooled file job name (SPLFJOB), Spooled file job user (SPLFJOBUSR), and
Spooled file job number (SPLFJOBNBR).
Problem Detection and Recovery

Spooled files are now processed by target journal inspection and virtual switch recovery, and replication
processes and audits automatically attempt to recover spooled files according to automatic recovery
policies like any other replicated object type.
The Data Groups and Data Groups in a Resource Group portlets show the error and recovery counts in
the Obj and Rcy fields under the Replication heading and include spooled file recoveries.
The Object Activity tab of the Data Group Details and Activities portlet shows spooled files that require
manual recovery and information in the Source Object and Target Object columns. Both automatic and
manual recovery can be viewed from the Object Correction Activity window. If manual recovery is
required, actions are available. Both the Object Activity tab and the Object Correction Activity window
support actions for comparing and synchronizing spooled files, including Compare Details and
Synchronize Object. Hover the cursor over the spooled file to display the spooled file name, spooled file
number, and three part job name. Similar changes were made to the Virtual Switch Activity and Objects
Changed on Target windows.
Other changes include:
• Spooled files that exist only on the target system and are configured to be kept on the target, even if
deleted from the source, do not require recovery and are marked as recovered.
• Spooled files created during virtual switch are deleted during virtual switch recovery, regardless of
the configuration setting.
• On the Synchronize Object (SYNCOBJ) dialog, when the Type field is *SPLF, the Source Object field
displays spooled file information.
– When synchronizing spooled file objects, the following fields are disabled: Synchronize
authorities, Save active, Save active wait time, and Maximum sending size.
• On the Activity Entry Details dialog, when the type field is *SPLF, spooled file information is displayed
in the Spooled file field.
• On the Remove Activity Entries and Retry Activity Entries dialogs, the spooled file information is
displayed in the Source Object field.
• The Synchronize Object field action is supported for spooled files and displays the Synchronize
Object (SYNCDGACTE) dialog.
In the native user interface, spooled files with errors are included in the Object errors column on the
Work with Data Groups (WRKDG) display. You can see the current and completed activity and issues
that require resolution for Spooled files on the Work with DG Activity Entries (WRKDGACTE) display.
You can then take corrective action using commands that also include spooled file support for any of the
Object, Object Type, Spooled file criteria, Spooled file name, and Spooled file job parameters (and/or
elements). They include the following:
• Synchronize object (SYNCOBJ)
• Synchronize DG Activity Entry (SYNCDGACTE)
• Remove DG Activity Entries (RMVDGACTE)
• Retry DG Activity Entries (RTYDGACTE)
• Cancel DG Activity Entry (CNLDGACTE)
Other changes
The DSPDGSPLF command and resulting Display DG Spooled Files display have been removed.
(MXHA-22052)
Ignoring attribute differences in distributed environments

In MIMIX environments that distribute data using non-switchable data groups or using data groups
whose target node is a replicate node of an application group, you can configure which attributes of
replicated objects will be ignored by MIMIX audits to streamline distribution. When attributes of
replicated objects are configured to be ignored by audits, MIMIX does the following:
• Audits will ignore differences detected for the specified attributes and not report those differences as
errors. Similarly, compare commands that specify a data group also will ignore differences for the
specified attributes.
• Any differences for the specified attributes will be maintained according to the default behavior of
MIMIX synchronization requests. This includes requests made by audit recoveries.
To ensure audit results correctly report status for objects that have attributes ignored as a result of this
functionality, there are several new auditing-related status values, as described below.
Also for these MIMIX environments, if you have objects within audit results with compare status values
of *NE or *NC, you can use the Ignore Differences action from the Audit Results or Result Details
windows to create or update selection rules for the object so that the attributes or data found different by
the audit will be ignored by subsequent audits.
Action Required:
To use this capability, eligible environments must modify the configured selection rules (data group
entries) to specify which attributes of replicated objects can be ignored by auditing.
Configuration changes to ignore attribute differences for replicated objects

This functionality can be configured in non-switchable data groups or within data groups whose target
node is a replicate node of an application group. If specified in selection rules for switchable data groups,
it is ignored.
In VSP, when a selection rule is configured to ignore attributes of replicated objects, the Ignored
Differences column identifies the ignored attributes on the appropriate tab of the Selection Rules window
or on the File Selection Rules window
In VSP, dialogs for adding (Include) or changing (Details) selection rules have a new Differences to
ignore during auditing field that you can use to identify which attributes of replicated objects will be
ignored by auditing. In the native user interface, the equivalent is the Attributes to ignore (IGNATR)
parameter on the Add and Change commands for data group entries. Audits will ignore differences
detected for the specified attributes and any differences will be maintained by the default behavior of
MIMIX synchronization requests. Possible values include:
• None (*NONE) - No attributes are ignored.
• Attributes Only (*ATRONLY) - All non-data attributes are ignored.
• Data Only (*DATAONLY) - All data attributes are ignored. This includes *DATACRC and *VALUE
attributes. Data within physical files cannot be ignored.
• Attributes and Data (*ATRDATA) - All attributes (data and non-data attributes) are ignored.
• Select Differences - You can also select one or more attributes from a list of available attributes for
the type of selection rule (data group entry).
Retrieve commands and outfiles associated with data group entries have added parameters or fields to
identify the number of ignored attributes (NBRIGNATR) and the Ignored attributes (IGNATR). This
affects the following commands and outfiles: RTVDGOBJE, MXDGOBJE outfile (WRKDGOBJE),
RTVDGDLOE, MXDGDLOE outfile (WRKDGDLOE), MXDGIFSE outfile (WRKDGIFSE), RTVDGFE,
and MXDGFE outfile (WRKDGFE).
Synchronize changes to support maintaining ignored attribute differences

The Synchronize DB File, Synchronize Object, Synchronize IFS Object, and Synchronize DLO dialogs
and the SYNCOBJ, SYNCDLO, SYNCIFS, and SYNCDGFE commands added a field that allows you to
specify how the synchronize request will process any attributes and data that are configured to be
ignored for the object being synchronized.
This is the Ignored differences field in VSP dialogs. In the native user interface it is the Ignored attribute
processing (IGNATRPRC) parameter. Possible values are:
• Keep target values (*KEEP) - Ignored attributes will not be synchronized and will keep their current
values on each system in the data group. This is the default value.
• Replace target values (*REPLACE) - MIMIX synchronization will replace all of the attributes using
values from the source system object, including any attributes that are configured to be ignored.
New auditing status values for ignoring attribute differences

When the configuration allows replicated attributes to be ignored, the following new status values can
appear in these locations:
Differences ignored (*IGNATR) status for audits: The audit detected one or more objects with
attribute differences that were ignored based on the MIMIX configuration. All other selected objects were
compared with no detected differences This status is considered successful.
In VSP, this can appear in the Status column of the Audits portlet and numerous other locations where
audit status is displayed. In the native user interface, this appears in the Audit Status column on the
Work with Audits display (WRKAUD) and on the Work with Audit History (WRKAUDHST) display. In the
MXAUDHST outfile (for WRKAUD and WRKAUDHST commands), *IGNATR is added as a possible
value for the Audit Status (AUDSTS) field.
Object audit status category of *IGN: When an object listed on the Work with Audited Objects
(WRKAUDOBJ) display has this value, the status category is Ignored attribute, and the object has one or
more attributes with an audit status of *IN or *IC.
Audit compare status (difference indicator) values of *IN and *IC: The compare phase of audits and
the output from commands that compare attributes can report the following new difference values for
attributes when the configuration allows replicated attributes to be ignored by auditing:
*IC - The values are not equal based on the MIMIX configuration settings, but attribute differences
are configured to be ignored.
*IN - Indicates differences were detected, but were ignored according to MIMIX ignored attribute
configuration settings.
The values *IC and *IN can appear as a compare status in the Audited Objects window and the Object
Audit History window, the Work with Audited Obj. History display (WRKAUDOBJH command), and as a
difference indicator value in Audit Results and Audit Result Details windows for audits that compare
attributes. These values also can appear as values in the Compare Status (CMPSTS) field in the
MXAUDOBJ outfile (WRKAUDOBJ command, and in the Difference Indicator (DIFIND) field in outfiles
for the CMPOBJA, CMPDLOA, CMPIFSA, and CMPFILA commands.
(MXHA-12049)
Improvements to journal analysis

Following an unplanned switch, the journal analysis function is strongly recommended for each data
group of type *ALL or *DB to identify journal entries in the user journal that were not sent to the target
system before the source system failed. MIMIX has significantly revised and expanded the journal
analysis function. Improvements include:
• Journal analysis now supports all journaled *FILE, *DTAARA, and *DTAQ objects and journaled IFS
objects that are replicated through the user journal. The interface for performing journal analysis has
changed to support the additional object types and improve ease of use. For details, see “Journal
Analysis interface changes” on page 59.
• Two new step programs added to the unplanned switch procedure (SWTUNPLAN) allow MIMIX to
implement an indicator within user interfaces of the presence of data groups that need journal
analysis and to automate disabling policies that could result in recovery actions that interfere with
your ability to perform journal analysis.
Note: This improvement is only for environments that use application groups. These capabilities
are not available for environments that use MIMIX Model Switch Framework (RUNSWTFWK
command) or the Switch Data Group dialog (SWTDG command) to perform an unplanned
switch.
For details, see “Changes to SWTUNPLAN procedure for journal analysis” on page 61.
• Interfaces that start replication processes for data groups that are part of an application group are
changed so that, following an unplanned switch, the start request is prevented if journal analysis has
not been performed. The affected interfaces also support the ability to start replication processes
anyway. For details, see “Replication start prevented following unplanned switch of application
group” on page 61.
• Policy interfaces have new values for the Automatic database, object, and audit recovery policies
and the Object only on target action policy to indicate that the policy was disabled by MIMIX due to
an unplanned switch of an application group. These new values also identify the previous value.
Interfaces for starting data groups also have the ability to enable the recovery polices that were
disabled by the SWTUNPLAN procedure. For details, see “Policy changes due to an unplanned
switch of an application group” on page 62.
Be aware that starting replication and enabling policies before journal analysis has been performed risks
data loss for any unprocessed entries that you still need to recover manually.
Journal Analysis interface changes

You should always contact your certified MIMIX representative for assistance before performing an
unplanned switch. Following an unplanned switch, journal analysis is strongly recommended before you
restart replication processes. This has not changed.
The Journal analysis function is only available from the native user interface, and continues to be
accessed by using option 43=Journal analysis on the Work with Data Groups (WRKDG) display. The
behavior and resulting interfaces associated with this option have been redesigned to improve ease of
use and to support journaled IFS objects, data areas, and data queues as well as files.
Following an unplanned switch, you may also want to contact your certified MIMIX representative for
assistance with performing journal analysis.
Before restarting replication processes, assess the Work with Data Groups display (WRKDG command)
from the system that was the source prior to switching, then use option 43=Journal analysis to access
information about unprocessed journal entries that require analysis.
The resulting Journal Analysis Summary display identifies the last processed (applied) entry for the
data group. When the analysis has not yet been performed, you must press F9=Analyze journal to
collect the information about unprocessed entries from the user journal on the local system.
When F9 is used, the display also summarizes the affected transactions at the time the information was
retrieved. The unprocessed information identifies the sequence number range that requires user
analysis and action to avoid losing transactions when MIMIX replication processes are restarted and this
(local) system becomes the new target system. When F9 is used, it also clears the internal indicator for
journal analysis and removes the associated icons that appear in VSP interfaces after an unplanned
switch of an application group.
You can use F10=Work with objects to view the retrieved details about the affected objects and
unprocessed entries.
The resulting Work with Journal Analysis of Objects display identifies the last transaction applied to
the target system and objects with transactions in the user journal on the source system which MIMIX
replication had not started or had not completed at the time the information was retrieved from the local
system. F11 toggles the display between views for library-based objects (files, data areas, data queues)
and IFS objects.
The information displayed for each listed item includes a count of the number of journal entries found
and the status associated with user-performed journal analysis of the object. These options are
available:
• 5=Display statistics and 6=Print statistics - You can display or print statistical information about
journaled transactions for the specified object. When option 5 is used, the resulting Display Journal
Analysis of Object display shows details related to the unprocessed journal entries associated with
the selected object, including the first and last of the unprocessed entries and statistical information
about the journaled transactions.
• 11=Display journal entries - Allows you to display journal entries that need to be analyzed for the
specified object. The user journal entries for the identified object that have not been processed by
MIMIX are listed on the resulting Work with Jrn. Entries for Jrn. Analysis display.
Note: From the Work with Jrn. Entries for Jrn. Analysis display, you can use options to display or
print details about the selected user journal entry for the object that has not been processed
by MIMIX.
• 46=Acknowledge - Allows you to acknowledge that you have analyzed journal entries for the
specified object.
• 47=Mark as new - Allows you to mark a previously acknowledged object as new to indicate that
additional analysis of journal entries needs to be performed for the specified object.
Indicator added when journal analysis is recommended

For data groups that were part of an unplanned switch of an application group, a step program in the
SWTUNPLAN procedure sets an internal indicator that journal analysis is needed. The actual journal
analysis can only be performed from the native user interface.
These VSP interfaces provide an indication that journal analysis information has not been accessed and
that journal analysis is recommended:
• The Attention icon is displayed to the right of the name of the data group and its associated
application group on the Replication Environment portlet, as well as to the right of the data group
name on the Data Groups portlet and the Data Group Details and Activities portlet. The icon is also
displayed next to the name of the associated resource group and application group in the Application
Groups and Resource Groups portlets. Flyover text for the icon identifies whether journal analysis
information as not been accessed, recovery policies are disabled, or both.
• The Attention icon appears next to the name of a selected data group in the Start Data Group
dialog, or next to the name of a selected resource group or application group when one or more of its
data groups are affected in the Start Resource Group, or Start Application Group dialogs. These
dialogs also display a message indicating that journal analysis is recommended and that you should
contact your certified Syncsort representative.
In the native user interface, there are no equivalent indicators that journal analysis is needed due to an
unplanned switch. However, the following changes do provide some indication:
• The data group name is highlighted in Yellow on the Work with Data Groups display (WRKDG
command) when its recovery policies have been disabled by an unplanned switch of an application
group. This highlighting also appears on all views of the Display DG Status display (DSPDGSTS
command.) This condition rolls up into the *ATTN status value in the Replication Status column on
the Work with Data Rsc. Grp. Ent. display (WRKDTATRGE command) and the Work with Application
Groups display (WRKAG command).
• The Retrieve DG Status (RTVDGSTS) command added parameters JRNANZREQ and
RCYPCYDSB and the MXDGSTS outfile (WRKDG command) added Char(10) fields for Journal
analysis required after unplanned switch, and Recovery policies disabled after unplanned switch.
Both support values of *YES and *NO.
The journal analysis indicator is cleared (and the data identifying the unprocessed transactions is
cleared) when you do any of the following after an unplanned switch:
• Use the F9 (Analyze journal) key on the Journal Analysis Summary display to retrieve information
about user journal transactions on the local system that require analysis. Note that pressing F9
clears the indicator even if you have not yet addressed any of the unprocessed entries.
• Start data group with a request that specifies to clear the journal analysis indicator.
• Start all data groups in an application group with a request to clear the journal analysis indicator.
Changes to SWTUNPLAN procedure for journal analysis

In environments that use application groups, the unplanned switch (SWTUNPLAN) procedure has
additional steps added.
MXSETDGJA - Set journal analysis indicator for data group. This step sets an indicator on data
groups that are part of the unplanned switch operation to identify that journal analysis is needed and that
and manual correction should be completed before the data group is started. Indicators appear in
interfaces for data groups as well as the resource group and application groups to which they belong.
MXDGDSBPCY - Disables recovery policies. This step disables policies that allow submission of
automatic recoveries at the data group level. This prevents automatic recoveries from interfering with
your ability to perform journal analysis and to address unprocessed transactions in the user journal on
the system that was the source before the unplanned switch was performed. The affected policies are
Automatic database, object, and audit recoveries (DBRCY, AUDRCY, AUDRCY) and Object only on
target action (OBJONTGT).
Following an unplanned switch, it is recommended that these policies remain disabled until after journal
analysis and manual correction are completed. User action is required to enable the policies after journal
analysis has been performed.
User interfaces for polices provide an indication that the policies have been disabled by MIMIX due to an
unplanned switch of an application group.
Replication start prevented following unplanned switch of application group

As a result of running the unplanned switch (SWTUNPLAN) procedure, MIMIX tracks whether journal
information on the system that was the source system of the data group prior to switching has been
accessed for analysis following the switch. (Journal analysis information is accessed when you press F9
on the Journal Analysis Summary display in the native user interface.) MIMIX is changed so that if the
information has not been accessed and you request to start replication processes, shipped default
values on the start request prevent the start from occurring.
Clear journal analysis option on start: The checkbox “Start without performing journal analysis and
manual recovery” appears in the Start Application Group, Start Resource Group, and Start Data Group
dialog when the selection includes one or more data groups that were part of an unplanned switch and
journal analysis information has not been accessed. In the native user interface, the equivalent to the
checkbox is the new Clear journal analysis (CLRJRNANZ) parameter on the Start Application Group
(STRAG) and Start Data Group (STRDG) commands. Possible values are:
• When unchecked (*NO), replication processes for data groups will not be allowed to start following
an unplanned switch if their journal analysis information has not been accessed. This is the shipped
default, which helps you to prevent unintended loss of the information needed to analyze and
manually resolve any unprocessed journal entries in the user journal on the system that was the
source prior to switching.
• When checked (*YES), replication processes for data groups will be allowed to start following an
unplanned switch, and MIMIX will clear the journal analysis indicator for all data groups in the
specified application group or resource group, or for the specified data group. This value should only
be used when you are certain any unprocessed entries from the system that was the primary node
prior to switching have been addressed or are not needed. When data groups are started, the journal
analysis information from that system is no longer available. In application groups with three or more
nodes, data groups that are disabled will not be started, but their journal analysis information is
cleared.
Notes:
• Be aware that if an unplanned switch was performed on a data group that is not part of an application
group, the journal analysis indicator is never set. Accessing journal analysis information via F9 on
the Journal Analysis Summary display is not tracked and information about any unprocessed entries
is lost when the data group is started following an unplanned switch.
• The checkbox does not appear in the Start Data Group dialog and the CLRJRNANZ parameter on
the STRDG command has no effect on a data group that is not part of an application group.
• When using the Start Application Group dialog or STRAG command for application groups with three
or more nodes, data groups that do not include the node that was the primary node before the switch
can be started without specifying to clear journal analysis information. The application group will
have a replication status of Attention (*ATTN).
Policy changes due to an unplanned switch of an application group

Policy interfaces identify the policies that are automatically disabled by an unplanned switch of an
application group (SWTUNPLAN procedure). The table below lists the affected policies.
• On the Policy Summary window, the policies listed will show the value Disabled followed by the
icon. Hover text for the icon indicates that MIMIX disabled the policy.
• On the Data Group Policies window or the Set MIMIX Policies (SETMMXPCY) command, the polices
listed will display a new value. These new values cannot be specified and are only possible at the
data group level:
Table 4. New values for polices disabled by MIMIX via the SWTUNPLAN procedure
Policy New Values
Important Note: When these policies display these values, the unplanned switch procedure disabled the
policies to prevent interference with your ability to perform journal analysis and address unprocessed
transactions in the user journal on the system that was the source before the unplanned switch was performed.
When you have completed those activities, you must change these policies at the data group level to return to
normal operations.
Automatic database recovery • Disabled by MIMIX (previously Enable) - *MXDSBENB

(DBRCY) The automatic detection and recovery action functions are disabled
because an unplanned switch was performed. The unplanned switch
Automatic object recovery process disabled this policy, which was previously set to Enable
(OBJRCY) (*ENABLED).
Automatic audit recovery • Disabled by MIMIX (previously Use Instance Value) - *MXDSBINS
(AUDRCY) The automatic detection and recovery action functions are disabled
process disabled this policy, which was previously set to Use Instance
Value (*INST).
Object only on target action • Disabled by MIMIX (previously Delete Object) - *MXDBSDEL
(OBJONTGT) The action to be taken on objects that exist only on the target is disabled
process disabled this policy, which was previously set to Delete Object
(*DELETE).
• Disabled by MIMIX (previously Use Instance Value) - *MXDSBINS
The action to be taken on objects that exist only on the target is disabled
process disabled this policy, which was previously set to Use Instance
Value (*INST).
Start DG request returns policies disabled by unplanned switch to previous values
In order to return to normal operations after you have completed journal analysis and any manual
recovery activities for a data group that was part of an unplanned switch of an application group, you
must change the data-group-level policies disabled by the unplanned switch procedure back to their
previous values. Changes to the Start Data Group dialog and STRDG command allow you to perform
this task as part of starting replication processes for a data group.
The Enable recovery policies checkbox (ENBRCYPCY parameter) specifies whether to enable policies
associated with recovery behavior for the specified data group that were disabled by an unplanned
switch. The affected policies are those listed in Table 4. (The checkbox appears in the dialog when the
selection includes one or more data groups that were part of an unplanned switch and have one or more
policies that were disabled by MIMIX.) Possible values are:
• When unchecked (*NO), the policies disabled by the unplanned switch will remain disabled for the
data group. This is the shipped default. This value is appropriate when there is a business need to
start replication even though all of the unprocessed entries from the system that was the source prior
to the unplanned switch have not been recovered. Before starting with disabled recoveries, ensure
that you have printed a list of the objects and unprocessed journal entry information that you will
need to finish manually recovering the entries. Allowing replication processes to start with disabled
recoveries prevents automatic recovery actions from potentially causing data loss for the
unprocessed entries that you still need to recover manually.
• When checked (*YES), the recovery policies for the data group will be enabled to their previous
values. This is appropriate when you are ready to return to normal operations.
(MXHA-22918)
VSP supports enhanced DDM authentication method on

IBM i
VSP supports portal connections to IBM i servers that are configured to use *ENCUSRPWD as the DDM
authentication method.
Additional steps may be required, especially when VSP is running on a supported Windows platform.
See Knowledgebase article 52673.
(MXHA-26174, STR-5519)
CHKMMXRCV checks whether receiver can be deleted

The new Check MIMIX Receiver (CHKMMXRCV) command checks whether MIMIX has completed
processing the data in the specified receiver and if the receiver meets all other criteria for deletion based
on the MIMIX journal definition.
Specify the name and library of the journal receiver to check. If MIMIX has completed processing the
specified receiver and the other criteria are met, the receiver is eligible to be deleted and the command
completes successfully. Messages are issued for each reason that the receiver is not eligible to be
deleted. The CHKMMXRCV command does not actually delete the receiver if it no longer being used by
MIMIX.
The command can be added to a delete journal receiver exit program (QIBM_QJO_DLT_JRNRCV) or
inserted into any customer program that deletes receivers or checks if receivers are ready for deletion.
(MXHA-27056)
Converting selection rules between include and exclude

VSP now supports converting selection rules between include rules and exclude rules. Two new actions
are available on each tab (Libraries, Directories, Folders) of the Selection Rules window:
• Convert to Include - available on rows for Exclude selection rules, this action opens the appropriate
Convert to Include dialog
• Convert to Exclude - available on rows for Include selection rules, this action opens the appropriate
Convert Include to Exclude dialog.
Converting a selection rule changes configured name space. Audits and other functions such as
synchronization requests will get changes immediately. However, the changes do not take effect for
replication until the resource group or data group is stopped and started.
The Convert dialogs convert only the selected rule. For example, if a selected rule identifies a library
object, only that rule is converted; other rules that identify objects within that library will not be converted.
Directory selection rules that exclude IFS objects using advanced generics cannot be converted.
Convert Exclude to Include dialogs - The dialogs for converting an exclude selection rule to an include
rule support the Synchronization options field, which has two possible choices:
• Synchronize objects new to MIMIX when replication starts.
When selected, the objects identified by the selection rule will be synchronized the next time
replication processes are started. Replication activity will increase during synchronization.
• Synchronize manually.
This is the default value. When selected, additional steps are required to complete the configuration.
If you do not synchronize manually, MIMIX will wait for the next audit to find objects that are missing
from the target system and take audit recovery action to synchronize them.
Also, when converting an exclude rule to an include rule that selects library objects and the selection rule
is in a resource group or data group that cooperatively processes any files, you must run the File
Selection Rules audit following the conversion to ensure that the appropriate file selection rules are also
created.
Convert Include to Exclude dialogs:- Converting an include selection rule an exclude rule may cause
changes to objects on the source system to no longer be replicated.
If the rule being converted is for library objects and cooperatively processes any files, the associated file
selection rules may require manual deletion before the File Selection Rules audit runs.
(MXHA-23952}
Changes to automatic job restart and cleanup

MIMIX jobs no longer automatically restart every 24 hours. MIMIX system level jobs and data group level
jobs that previously relied on the automatic restart capability (RSTARTTIME parameter) to remove
unnecessary messages from their job logs now perform this function periodically. Affected system level
jobs include the journal manager and target journal inspection jobs. Affected data group level jobs
include the object send, object retrieve, container send, status receive, object receive, container receive,
status send, database reader, database send/receive, and object apply jobs.
The ability to configure the job restart time (RSTARTTIME parameter) has been removed from system
definition and data group definition commands (such as CRTSYSDFN, CHGSYSDFN, CRTDGDFN, and
CHGDGDFN) and from dialogs for creating and changing resource groups and data groups. The
removal of the automatic restart also means that configuration changes no longer become effective due
to the automatic restart. The end restart required to make changes effective now must always be
initiated by you.
After upgrading an existing installation that specified a time for RSTARTTIME system definitions or data
group definitions, the specified time will be ignored and cannot be changed. The new behavior is
equivalent to the previous restart time value of *NONE. Previously, RSTARTTIME defaulted to 000000
(midnight).
IMPORTANT! Be aware that if you previously relied on the “nightly restart” to make configuration
changes effective, you must now ensure that you end and restart replication processes to make
configuration changes effective. If you previously used a restart time of *NONE and have automation
that performs the job cleanup functions that were not performed as a result, you should evaluate
automation to determine whether it may interfere with how automatic MIMIX job cleanup is now
performed.
(MXHA-22351)
Object Status Send Process status now provided in

additional status interfaces
Status for the object status send (STSSND) process was extended to now be included with status
reported for object replication processes that run on the target system. The status send process must be
active on the target system to ensure that data group activity entries status can be reported correctly on
both the source and target systems.
In VSP, changes are included in the:
• Data Groups portlet on the Data Groups page - Obj column for the Target is now a summation of the
object apply and status send processes.
• Data Group Details and Activities portlet on the Data Groups page - New Send activity statuses field
for Target Processes on the Object Statistics tab now includes the status for the object status send
process.
• Data Groups portlet on the Application Groups page - Target column now includes the rolled up
status for the object status send process when either an application group is selected in the
Application Groups portlet or a resource group is selected in the Resource Groups portlet.
• Arrivals and Backlog portlet on the Analysis page - Processes column under Objection Replication
on the Data tab now includes the status for the object status send process.
The following subscription events in VSP are updated to include monitoring for STSSND process:
• Data groups with action required status.
• Data groups with a stopped or partially stopped status.
• Data group processes with action required status.
In the native user interface, changes are included in the:
• Work with Data Groups display (WRKDG command) - Target Obj column status for the data group
now provides a summation status of the object apply and status send processes.
• Data Group Status display (DSPDGSTS command) - Detailed object views (object View 1 and View
2) accessed from this display now have a new Status Send field that shows the status of the status
send process on the target system for the data group. From this display, use F7 (Object view) to
access View 1 and View 2 (use F11 to toggle between the object views).
• Start and End Data Group (STRDG/ENDDG commands) - Status send (STSSND) is checked
separately for starting or ending a data group and is included when any of the following values are
specified for the Start processes (STRDG) or Processes (ENDDG) fields: All, All target, All Object,
and Object target.
• Previously, STSSND was started or ended as part of the OBJSND processing. For STRDG, if
OBJSND was up and STSSND was down, then STSSND would not be restarted. For ENDDG, if
OBJSND was down and STSSND was up, then STSSND would not be ended.
• MXDGSTS outfile (WRKDG command) - New field STSSNDSTS is added to automate the collection
of status for the object STSSND process.
(MXHA-23598)
Minimum supported operating system version is now V7R1

The minimum supported version of the IBM operating system for MIMIX 9.0.01.00 and later is now
V7R1.
(MXHA-23329)
Java 8 supported for product install wizards

VSP 3.2 now supports Java 8. Software upgrade processes will automatically upgrade VSP versions 3.0
and 3.1 to 3.2.
VSP 3.2 does not support Java 6. This means that VSP 3.2 cannot be installed on systems running IBM
i 6.1. (MIMIX and iOptimize products also do not support running on IBM i 6.1.)
If you cannot upgrade all installed product portal applications to versions that are compatible with VSP
3.2, you will need to maintain two VSP servers. Refer to “VSP 3.2 compatibility with product portal
applications” on page 2 for additional information.
Java install requirements

The installation wizard for System i does not ship the JRE, so the installation processes will instead use
the latest compatible version of Java that is found on the system. To operate VSP on System i servers,
those systems require a compatible version (5770-JV1 or 5761-JV1) of IBM Developer Kit for Java
(*BASE) and either Option 16 (Java SE 8 32 Bit) or Option 17 (Java SE 8 64 Bit). Option 17 is strongly
recommended.
The VSP installation wizards for Windows (and AIX) now include Java 8 JRE. Java 8 JRE will be used
when installing VSP 3.2 on Windows or AIX.
Java Runtime requirements
• System i: Java 8 JRE (64 bit) is the preferred version. However, Java 7.1 JRE or Java 7 JRE are
supported and can be used instead.
• Windows or AIX: Java 8 JRE (included with the install wizards).
(STR-5347)
Obsolete functionality removed from MIMIX

MIMIX has removed code, commands, parameters and values from user interfaces for functionality that
is considered obsolete.
Action Required
Before upgrading, use the CHKDLTFCN command to check for configuration that is obsolete in version
9.0. For details, see Step 2 of “Before installing the service pack” on page 6.
If you attempt to upgrade and the upgrade fails with message LVE3817, user action is required to
address configuration that is no longer supported before the upgrade can be performed.
Also, after upgrading, action may be required to check automation for commands or values that have
been removed. See the following for detailed information.
Configured obsolete functionality that is checked by the upgrade process - When upgrading to
version 9.0, the upgrade process will check for the existence of configured obsolete functionality in the
MIMIX installation. The upgrade ends with message LVE3817 if any of the checked-for functionalities
are configured and issues error messages that identify what to do to address the configuration. The
following are checked:
• Transfer definitions that specify *SNA or *OPTI for the Protocol (PROTOCOL) parameter are no
longer supported. The only supported protocol is *TCP. MIMIX must be configured to use transfer
definitions that specify *TCP before upgrading. If transfer definitions that specify *SNA or *OPTI as
the protocol are not being used, they can be deleted.
• The data area poller process is no longer supported. *DTAARA objects identified by data group data
area entries need to be identified for replication by data group object entries (library selection rules)
and the data group data area entries must be removed.
• File alias naming is no longer supported. Any configured data group file entry aliases (DGFEALS)
must be removed. If you still require some form of name mapping for replication, contact your
certified MIMIX representative for assistance.
• Switch definitions of type *SM517A or *SM9001 (for hardware switching) are no longer supported.
Switch definitions support only *TCP or *NONE for the TYPE parameter. If the switch definition is still
needed, contact your certified MIMIX representative for assistance in changing your environment to
use a switch definition with a different value for the TYPE parameter.
• Extended policy MCDISABLEDG is no longer supported. The value of the extended policy must be
set to 1 before upgrading. Contact your certified MIMIX representative for assistance and to discuss
other possible configuration implications.
Other removed functionality that is not checked by the upgrade process includes:
• The Object only on target action (OBJONTGT) policy no longer supports the value Synchronize
(*SYNC) and that value is no longer displayed in the Policy Summary window, Policies dialogs, and
the SETMMXPCY command. If this value is used, the upgrade process will change it to *DISABLED.
• The Apply history log spaces element of the Database apply processing (DBAPYPRC) parameter of
the data group definitions is changed to the value 0 by the upgrade process. The value 0 will always
be used regardless of what is specified on the CRTDGDFN or CHGDGDFN commands, or on Data
Group or Resource Group dialogs.
• The Synchronize Data Group (SYNCDG) command is removed.
• The UPS monitor is no longer supported and UPSMON is no longer a restricted name for other
configuration objects. The following commands have been removed: UPDUPSAVL, TSTPWRCHG,
CHGUPSAVL, CHGUPSCFG, CHGUPSMSG, DSPUPSSTS.
• The MIMIX for SAP feature no longer supports 3-tier transparent switching. The CHKR3PRF, and
INZR3SWT commands and the R3SWTCMN *SVRVPGM have been removed.
• The Electronic Customer Support function within License Manager is no longer supported. The
CHGLKVSPT, DLTLKVSPT, ENDLKVSPT, and STRLKVSPT commands have been removed.
• The support tools provided by the CHKMMX and CLRMMXDTA commands are removed.
When checking automation, also check for the following:
• Check automation that specifies the PROTOCOL parameter for the values *SNA or *OPTI in these
commands: CRTTFRDFN, CHGTFRDFN, RMVTFRDFN, WRKTFRDFN CPYACTF, RUNCMD, and
RUNCMDS.
• The following commands for data group data area entries have been removed: ADDDGDAE,
CHGDGDAE, CPYDGDAE, CPYDGDAE, DSPDGDAE, DSPDGDAEX, LODDGDAE, RMVDGDAE,
RTVDGDAE, RTVDGDAE, VFYDGDAE, WRKDGDAE. Also, the DTAARAITV parameter is no
longer available on commands for data group definitions or the DPYDGCFG, OPNMMXLST, and
RTVDGSTS commands.
• The following commands for file alias naming have been removed: ADDDGFEALS, CHGDGFEALS,
DSPDGFEALS, DSPDGFEALX, RMVDGFEALS, WRKDGFEALS.
• The following switch definition commands no longer support TYPE values of *SM517A or *SM9001:
CRTSWTDFN, CHGSWTDFN.
(MXHA-10781)
Fixes included in service pack 9.0.01.00

This service pack includes all relevant changes to earlier level 9.0 service packs and fixes in 8.1.24.00
and earlier levels of version 8.1.
MXHA-25604 User space create, delete, and I/O write operations have been reduced for database log
space, improving database apply performance.
MXHA-25756 VSP now displays current audit and compliance status in the data groups portlet.
MXHA-25962 Record level repairs made by the replication manager (MXREPMGR) when there is no
other activity flow to the remote journal in a more timely manner.
MXHA-26460 VSP has been updated to provide proper default row actions for File Activities in
*HLDERR status.
MXHA-26476 The object status and recovery text in the Object Correction Activity window are now
correct when an object with a failed recovery is in the process of having a different
exception recovered.
MXHA-26627 Status for disabled data groups is no longer included in rollup status for application
groups displayed in the Replication Environment portlet on the VSP Summary page.
MXHA-26647 VSP has updated flyover text for the notification icon in the Nodes portlet to instruct users
to go to the Notifications portlet for more details.
MXHA-26916 When a metered usage MIMIX instance is removed from VSP, it is now also removed
from the Metered Usage portal application.
MXHA-26965 The adjusted time stamps for the received and applied WRKDGTSP timestamp fields will
no longer show large (999:99) fields when system to system timestamp difference is too
large.
MXHA-27197 Journal Manager status no longer shows *RCYASP or *INACTASP when the available
spaces on the system ASP exceeds 2,147,483 MB (about 2TB).
VSP
VSP version 3.2.01.00 is included with MIMIX service pack 9.0.01.00.
Fixes for VSP

VSP 3.2.01.00 includes all relevant changes to earlier VSP level 3.2 service packs and fixes in 3.1.14.00
and earlier levels of version 3.1.

Mimix 9.0.02.00 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Mimix 9.0.02.00 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Read This First

Supported installation processes

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 1

VSP 3.2 compatibility with product portal applications

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 2

Product VSP server VSP server VSP server

MIMIX 8.1 8.1.11.00 and higher Only 8.1.01.00 through 8.1.10.00

8.1.10.00 and earlier

iOptimize 8.1 8.1.11.00 and higher Only 8.1.01.00 through 8.1.10.00

8.1.10.00 and earlier

MIMIX for AIX 5.2

MIMIX for AIX 5.1

Double-Take for AIX 5.0

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 3

Enhancements and Behavior Changes

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 4

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 5

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 6

Table 1. Deleted functionality checked by the CHKDLTFCN tool.

Item checked Description Message ID issued if

SNA/OPTI Checks whether the installation has an SNA LVE3812

SM517A/SM900A Checks for hardware switch types of LVE3815

MCDISABLEDG Checks extended policy MCDISABLEDG for LVE3816

3. Move any user-created objects or programs in libraries LAKEVIEW, MIMIXQGPL, or VSI001LIB or

Table 2. Data to exclude from MIMIX replication

Data Category Type Do Not Replicate

System Libraries IBM-supplied libraries, files, and other objects for

User profiles System user profiles, such as QSYSOPR and

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 7

Data Category Type Do Not Replicate

MIMIX Libraries LAKEVIEW

IFS directories /LakeviewTech

User profiles and LAKEVIEW

Authorization lists IOAUTLST72

User profiles IOPTOWNER

Device description VSINSVRT

IFS directories /VISIONSOLUTIONS

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 8

Data Category Type Do Not Replicate

Libraries (and contents) ITID8n

Authorization lists IDAUTLST8n

User profiles and ITIDOWNER

Device description VSINSVRT

IFS directories /VISIONSOLUTIONS

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 9

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 10

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 11

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 12

Post-install actions for this service pack, all install methods

After a new two-node install

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 13

After upgrading an existing installation

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 14

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 15

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 16

Before installing on Windows

After installing on Windows

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 17

New function or an enhancement in the indicated software.

Fixes included in service pack 9.0.02.00

Fixes for VSP

9.0.02.00 © 2017, 2018 Vision Solutions, Inc. All rights reserved. 18

New function or an enhancement in the indicated software.