Read This First MIMIX®download.visionsolutions.com/files/Support/Downloads/MIMIXha1/V90/9.0.02.00/MIMIX_9.0...The MIMIX for AIX 5.1 portal application is supported only on VSP 3.1

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 processesThis 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 requiredThis document provides service pack installation instructions for all supported installation media.

Important changesBefore 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.

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

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 applicationsVSP 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

Portal Application

VSP server

version 3.2

VSP server

version 3.1

VSP server

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.0The 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 ChangesApplication groups required for new default data groups . . . . . . . . . . . . . . . . . . . . .31Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Audit recovery actions now automatically submitted . . . . . . . . . . . . . . . . . . . . .44Auditing best practices improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Auditing improvements for permissions and masks (RCAC) . . . . . . . . . . . . . . .48Auditing improvements for temporal tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48Auditing policy changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41Audits with differences no longer considered action required . . . . . . . . . . . . . . .45Automatic recoveries for File Member Record Counts (#MBRRCDCNT) audit .40Changes to audit status check in the conditions that end switch . . . . . . . . . . . .46Changes to Ending an audit and Ended status . . . . . . . . . . . . . . . . . . . . . . . . . .46Changes to priority-based auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Changes to subscription events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47Optionally override auditing policies when submitting manually . . . . . . . . . . . . .43

Changes to automatic job restart and cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64Changes to automatic recovery reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

Failed audit recoveries included in replication error counts . . . . . . . . . . . . . . . .38Recovery status added for file, IFS tracking, and object tracking activities . . . .37

CHKMMXRCV checks whether receiver can be deleted . . . . . . . . . . . . . . . . . . . . .63Configuration changes to support best practices and multithreading . . . . . . . . . . . .30

Application groups required for new default data groups . . . . . . . . . . . . . . . . . .31Defaults changed for data groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31New default and changes to Target constraint management (DBAPYPRC) . . .34New default for Commit mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34New default for Cooperative journal (COOPJRN) . . . . . . . . . . . . . . . . . . . . . . . .33New default for Lock member during apply (FEOPT) . . . . . . . . . . . . . . . . . . . . .34New default for Number of DB apply sessions (NBRDBAPY) . . . . . . . . . . . . . .33Selection Rule (data group entry) changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Converting selection rules between include and exclude . . . . . . . . . . . . . . . . . . . . .64Ignoring attribute differences in distributed environments . . . . . . . . . . . . . . . . . . . .56Improved support for spooled files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

Auditing and comparing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Configuration changes for replicating spooled files . . . . . . . . . . . . . . . . . . . . . .52Libraries (#OBJATR) audit now supports auditing of spooled files . . . . . . . . . . .54Replication of spooled files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53Spooled file problem detection and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . .55

Java 8 supported for product install wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66Journal analysis improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

Changes to unplanned switch SWTUNPLAN procedure . . . . . . . . . . . . . . . . . .61Journal Analysis interface changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59Policy changes due to unplanned application group switch . . . . . . . . . . . . . . . .62Replication prevented following unplanned application group switch . . . . . . . . .61

Minimum supported O/S version is now V7R1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66Mobile support-VSP interfaces responsive on smaller devices . . . . . . . . . . . . . . . .19


Multi-object selection for manual corrections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Multithreaded database apply processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Configuration changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Conversion between single-threaded and multithreaded . . . . . . . . . . . . . . . . . .27Copy data group (CPYDGDFN) changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36Database apply sessions configurable for single-threaded or multithreaded . . .32Delete Application Group dialog, Delete Resource Group dialog changes . . . .36Multithreading configured indicators in VSP . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Operation and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Outfile and Retrieve command changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36Subscription event changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

New Replication Environment portlet on redesigned Summary Page . . . . . . . . . . .19Object Correction Activity window improvements . . . . . . . . . . . . . . . . . . . . . . . . . . .37

Automatic recoveries from audits now included . . . . . . . . . . . . . . . . . . . . . . . . .37Failed recoveries also reported in Data Group Details and Activities portlet . . .37Manual recovery actions added for failed recoveries . . . . . . . . . . . . . . . . . . . . .37

Object Status Send Process status now provided in additional status interfaces . . .65Obsolete functionality removed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67Product portal application compatibility with VSP 3.2 . . . . . . . . . . . . . . . . . . . . . . . . .2Replicating jobs associated with *JOBQ objects . . . . . . . . . . . . . . . . . . . . . . . . . . .48

Configuration changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49Replicated job indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50Switch 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.

SupersededThis 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 packIf 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


http://www.syncsort.com/DYK-PTFutility

http://www.syncsort.com/DYK- CHKDLTFCN

will fail the upgrade if any of the obsolete configuration elements still exist.

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 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 or OPTI transfer definition.

LVE3812

Data area polling Checks the installation for Data Area Poller entries.

LVE3813

File alias naming Checks installation for file alias naming entries.

LVE3814

SM517A/SM900A Checks for hardware switch types of SM571A and SM900A.

LVE3815

MCDISABLEDG Checks extended policy MCDISABLEDG for values of zero.

LVE3816

Table 2. Data to exclude from MIMIX replication

Data Category Type Do Not Replicate

Application Environment

Temporary objects or files You may not need to replicate temporary files, work 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 Environment

Libraries IBM-supplied libraries, files, and other objects for System i, which typically begin with the prefix Q.

User profiles System user profiles, such as QSYSOPR and QSECOFR


MIMIX Environment

Libraries

(and contents)

LAKEVIEW

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

(and contents)

/LakeviewTech

/VISIONSOLUTIONS

/VisionISOImages

User profiles and corresponding message queues

LAKEVIEW

MIMIXOWN

MIMIXCLU

iOptimize Environment

If iOptimize is installed on the same system or in the same partition as MIMIX, do not replicate the following:

Libraries

(and contents)

IOPT

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

and corresponding message queues

IOPTOWNER

ITIDGUI

VSI001LIB

Device description VSINSVRT

IFS directories

(and contents)

/VISIONSOLUTIONS

/VisionISOImages

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



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.00Check for IBM PTFs required for multithreaded database apply processing . . . . . .25Ensure product portal applications are compatible with VSP when installing . . . . . . .2Ensure that Java requirements for installing and runtime are met . . . . . . . . . . . . . .66Ensure that systems are running IBM i 7.1 or higher . . . . . . . . . . . . . . . . . . . . . . . .66Upgrades 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.

MIMIX Director Environment

For MIMIX Director, 8n is the release level. For example, n=1 in release 8.1. If MIMIX 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 corresponding message queues

ITIDOWNER

ITIDGUI

VSI001LIB

Device description VSINSVRT

IFS directories

(and contents)

/VISIONSOLUTIONS

/VisionISOImages

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



http://www.visionsolutions.com/supportcentral/products/mimix-for-ibm-i/9-0/notifications


Installing the service pack on IBM Power SystemsMIMIX 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.

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

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.


http://www.syncsort.com/supportcentral

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 instructionsThe 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 methodsThis 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.00Configure *JOBQ objects to replicate jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49Configure attributes to ignore in data distribution environments . . . . . . . . . . . . . . . .56Review the OBJONTGT policy value and KEEPSPLF parameter setting for all

data group object entries that replicate output queues . . . . . . . . . . . . . . . . .54Upgrades to 9.0 may need to address obsolete configuration or update

automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67Upgrades to 9.0 may need to convert resource groups to use multithreading or

update automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Upgrades to 9.0 may need to update automation that creates or changes data

groups or configured selection rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

After a new two-node installNote: 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.

2. If the installation wizard is still open, click the Launch VSP button on the Summary panel to open a 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 upgradeUse 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.


12. If the installation wizard is still open, click the Launch VSP button on the Summary panel to open a 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 WindowsThis 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 WindowsBefore 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 WindowsDefault 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 WindowsIf 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.00This 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.

VSPVSP 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 jobsThe 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

interfaces

Description

Check multithreading requirements:

• Check Multithreading Eligibility dialog

• Menu option: 31=Check for conversion

• CVTRG OPTION(*CHECK)

Validates that the data groups in the selected resource groups meet the requirements for conversion to multithreaded database apply processing and reports problems that would prevent conversion. Replication processes can be active when this option is used. The following requirements are checked:

• The data groups cannot have a database apply user exit program.

• Each data group must specify Use User Journal for Cooperative processing type (COOPJRN(*USRJRN)), values other than None (*NONE) for the 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.


Convert to multithreading:

• Convert Resource Groups to Multithreaded dialog

• Menu option: 32=Convert to multithreading

• CVTRG OPTION(*CVTTOMT)

Converts eligible data groups within the specified resource groups from existing configuration values to values required for multithreaded database apply processing. Resource groups whose data groups are already configured for multithreading are not processed. Prior to converting, this option verifies the same requirements as performed by *CHECK, with one difference. The check for open commit activity is performed on all associated data groups and no open commit activity can exist unless you explicitly select the checkbox for Discard open commit cycles (in VSP) or specify *DISCARD for Open commit handling (OPNCMT) in native user interfaces.

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

Description


(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.

Convert from multithreading:

• Convert Resource Groups to Single-threaded dialog

• Menu option: 33=Convert to single-threaded

• CVTRG OPTION(*CVTFRMMT)

Converts data groups configured for multithreading that are within the specified resource groups to configuration values compatible with single-threaded database apply processing. Resource groups whose data groups are already configured for single-threaded database apply processing are not processed.

When converting from multithreading to single-threading, you can optionally specify to use configuration data saved by an earlier conversion of the resource group to multithreading. Replication processes must be ended by a controlled end, and no open commit activity can exist unless you explicitly select the Discard open commits checkbox in the dialog or specify *DISCARD for Open commit 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 saved configuration:

• Change Configuration Expiration dialog

• Menu option:34=Change saved config retention

• CVTRG OPTION(*CHGEXP)

Changes the expiration date for a saved configuration associated with a specified resource group. The resource group must have had configuration saved by a previous conversion to multithreading. If saved configuration does not exist for the resource group, a diagnostic message is issued. Replication processes can be active when this option is used.



interfaces

Description


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 reportingThe 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 recovery is required.

*FAILED - The most severe status of any recoveries indicates that the recovery has failed.


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)

- Waiting for recovery. For details, use the Object Details action.

*CAPTURING -The most severe status of any recoveries indicates that the recovery is capturing information on the source system.

*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, use the Object Details action.

*NEW - The most severe status of any recoveries indicates that the recovery 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.

Table 2. Recovery statuses for VSP and native user interface

VSP interfaces Native user interfaces


Multi-object selection available for manual correctionsOne 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 EnhancementsThis 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:


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

Table 3. Policy mappings for upgrades

Previous Policy New Policies

Audit level

(AUDLVL)

Audit runs

(AUDRUN)

File data per-

centage to audit

(FILDTAOPT)

Directory audits

(IFSAUDOPT)

Folder audits

(DLOAUDOPT)

Disabled (*DISABLED)

Disable (*DISABLED)

100 Attributes and Data (*ALL)

Attributes and Data (*ALL)

10 (*LEVEL10) Enable (*ENABLED)

5 Attributes (*ATTRONLY)

Attributes (*ATTRONLY)








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 objectsFor *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 filesSpooled 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 environmentsIn 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 analysisFollowing 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 (DBRCY)

• Disabled by MIMIX (previously Enable) - *MXDSBENB The automatic detection and recovery action functions are disabled because an unplanned switch was performed. The unplanned switch process disabled this policy, which was previously set to Enable (*ENABLED).

• Disabled by MIMIX (previously Use Instance Value) - *MXDSBINSThe automatic detection and recovery action functions are disabled because an unplanned switch was performed. The unplanned switch process disabled this policy, which was previously set to Use Instance Value (*INST).

Automatic object recovery (OBJRCY)

Automatic audit recovery (AUDRCY)

Object only on target action (OBJONTGT)

• Disabled by MIMIX (previously Delete Object) - *MXDBSDELThe action to be taken on objects that exist only on the target is disabled because an unplanned switch was performed. The unplanned switch process disabled this policy, which was previously set to Delete Object (*DELETE).

• Disabled by MIMIX (previously Use Instance Value) - *MXDSBINSThe action to be taken on objects that exist only on the target is disabled because an unplanned switch was performed. The unplanned switch 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 iVSP 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 deletedThe 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.


http://www.syncsort.com/DYK-VSPDDM

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 excludeVSP 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 cleanupMIMIX 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 interfacesStatus 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 V7R1The 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 wizardsVSP 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 MIMIXMIMIX 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.00This 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).

VSPVSP 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.


Documents

Read This First MIMIX®download.visionsolutions.com/files/Support/Downloads/MIMIXha1/V90/9.0.02.00/MIMIX_9.0...The MIMIX for AIX 5.1 portal application is supported only on VSP 3.1