Mimix PDF

Read This First
Version 7.1 Service Pack 7.1.03.00

Prerequisites: If you are upgrading to MIMIX version 7.1, a MIMIX version 7.0 service pack (7.0.00.00
or higher) must be installed first.
Note: If you are installing from an OMS/ODS™ product, this prerequisite does not apply.
MIMIX version 7.1.03.00 includes all relevant changes to version 7.1.01.00 and earlier levels of version
7.0.
Action required
This document can be used for either or both of the following:
• Install or upgrade the product, its portal application, and Vision Solutions Portal (VSP) on its native
operating system.
• Install the product's portal application and VSP on a system running a supported Windows operating
system.
The following topics provide instructions associated with installing this service pack. Any changes which
may require you to take additional action are listed below with links to additional descriptions.
“Before installing the service pack” on page 3 - required for all installation methods.
“Installing the service pack on IBM Power Systems” on page 5 - it is recommended you use the
MIMIX Installation Wizard.
“After installing the service pack instructions” on page 6 - required for all installation methods.
“Installing VSP 2.0 & Portal Application on Windows” on page 8 - instructions for using the Vision
Solutions Portal (VSP) 2.0 & Portal Application Installation Wizard for Windows®.
Important changes
You should be aware of the information in the following topics before you install this service pack:
Enhancements
New IBM Flex System Event portlet in VSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
To see a list of fixes included with this service pack, see “Fixes included in service pack 7.1.03.00” on
page 9.
Superseded
This service pack includes the contents of the following superseded service packs. If you do not already
have the following service packs installed, their contents are also installed when you install service pack
7.1.03.00. To see highlights and additional fixes for a superseded service pack, click on the link.
7.1.02.00 - Highlights and fixes
MIMIX® is a registered trademarks of Vision Solutions, Inc. MIMIX Availability, iOptimize, MIMIX Enterprise, MIMIX Professional,
and MIMIX Global are trademarks of Vision Solutions, Inc. AS/400, DB2, eServer, i5/OS, IBM, iSeries, OS/400, Power, System
i, IBM i, and WebSphere are trademarks of International Business Machines Corporation. All other trademarks are the property
of their respective owners.
7.1.03.00 © Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 1
Read This First
7.1.01.00 - Highlights and fixes
MIMIX® is a registered trademarks of Vision Solutions, Inc. MIMIX Availability, iOptimize, MIMIX Enterprise, MIMIX Professional,
and MIMIX Global are trademarks of Vision Solutions, Inc. AS/400, DB2, eServer, i5/OS, IBM, iSeries, OS/400, Power, System
i, IBM i, and WebSphere are trademarks of International Business Machines Corporation. All other trademarks are the property
of their respective owners.
Installation Instructions
Before installing the service pack
The following describes changes that may require modifications to your MIMIX environment before you
install the service pack.
Action required:
• Do not replicate libraries LAKEVIEW, MIMIXQGPL, VSI001LIB, any MIMIX installation libraries
including MXIWIZ*, any MIMIX data libraries, libraries in which iOptimize is installed, and the
following IFS directories: ‘/visionsolutions/http/vsisvr’ and ‘/LakeviewTech’.
• Do not replicate the MIMIXOWN or LAKEVIEW user profiles.
• If iOptimize™ or MIMIX Director is installed in the same system or partition as MIMIX, do not
replicate the following:
Objects and IFS directories to exclude from replication.

iOptimize MIMIX Director
Libraries and their contents
Note: For MIMIX Director, 8n is the release level. For example, for release 8.1, n=1.
IOPT71 ITID8n
IOPTSPLARC IDSPLARC8n
IOPTOBJARC IDOBJARC8n
Objects in library QSYS and corresponding message queues
Authorization lists IOAUTLST71 IDAUTLST8n
User profiles IOPTOWNER ITIDOWNER
ITIDGUI ITIDGUI
VSI001LIB VSI001LIB
Device description VSINSVRT VSINSVRT
IFS directory VISIONSOLUTIONS VISIONSOLUTIONS
• Do not place user created objects or programs in the LAKEVIEW, MIMIXQGPL or VSI001LIB
libraries or in the IFS location /visionsolutions/http/vsisvr. This includes any programs created as part
of your MIMIX Model Switch Framework. If you place such objects or programs in these libraries,
they will be deleted during the installation process. Objects that are in these libraries must be placed
in a different library before installing this service pack. Job descriptions, such as the job description
used by the MIMIX Port job, can continue to be placed into the MIMIXQGPL library.
• QTEMP cannot be in the system portion of the library list.
• It is strongly recommended that you apply any IBM PTFs (or their supersedes) associated with IBM i
releases as they pertain to your environment. Refer to the Recommended OS Fixes link on the
Customer Care page in Support Central for a list of required and recommended IBM PTFs.
• If you run other products that use the same journals on the same systems as MIMIX, such as
Replicate1™ or iOptimize™, there may be considerations for journal receiver management. For
details, see "Interaction with other products that manage receivers" in the MIMIX Administrator
Reference book.
• Review Technical Alerts which can be found at Support Central in the Notifications section of the
Customer Care page. From Support Central, choose My Product >Customer Care > Notifications.
Before installing the service pack
Special instructions are listed below by service pack. Perform any actions necessary for
your environment before installing. It is necessary to perform any special instructions
provided for 7.1.03.00, as well as any listed special instructions for service packs that are
not yet installed. (You can skip special instructions for service packs already installed on
your system.)
The following procedure ends MIMIX products for an installation. If you have multiple
installations of MIMIX, the first installation updated will update License Manager. Because
of this, you should end MIMIX operations on all installations before installing.
1. Use the following command on a management system to end all system managers,
journal managers, collector services, application groups, data groups, active audits
and recoveries, the master monitor, and all MIMIX monitors:
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.
2. Repeat Step 1 for each additional MIMIX installation.
3. If you are not using MIMIX to schedule audits, ensure that your scheduling
mechanism does not start audits during the installation process.
4. If you currently use MIMIX Availability Manager, use the following command on any
system which hosts an instance of MIMIX Availability Manager:
LAKEVIEW/ENDMMXAM INST(name)
where name is the name of the instance. The Vision Solutions supplied default
instance name is MIMIXAM.
5. Use the following command on all systems to end the MIMIX subsystem:
ENDSBS SBS(MIMIXSBS)OPTION(*IMMED)
Installing the service pack on IBM Power Systems
MIMIX Installation Wizard recommended: Vision Solutions strongly recommends that you use the
MIMIX Installation Wizard to install version 7.1 products. The MIMIX Installation Wizard provides a
simple method for downloading, distributing, and installing products on a single IBM Power™ System or
on multiple Power Systems simultaneously.
In addition, the MIMIX Installation Wizard also does the following:
• Easily and automatically obtains and applies license keys via Vision AutoValidate™.
• Automatically installs the Vision Solutions Portal (VSP) server and MIMIX portal application on the
selected IBM Power™ Systems, or upgrades them if needed. If you skip the VSP shutdown step,
updates to the server are not installed and MIMIX portal application updates are not deployed to the
server. The server provides support for browser-based user interfaces to Vision Solutions products
which provide portal applications.
The MIMIX Installation Wizard does not support installing into a library located on an independent ASP.
For more information about requirements for using MIMIX Installation Wizard, see Support Central.
Support Central provides an executable (.exe) file for each product download, which contains the MIMIX
Installation Wizard as well as the actual product update.
If you cannot use the MIMIX Installation Wizard, the following books provide information for using other
means to install:
• The Using License Manager book describes requirements and best practices that must be in place
before installing products in your environment. This book also includes the secondary install
procedures and supporting information for installing via the 5250 emulator.
• The Getting Started with Vision Solutions Portal book describes requirements and installation options
for Vision Solutions Portal. This book also describes how to manually make the MIMIX portal
application known to the server and describes best practices for configuration.
After installing the service pack instructions
The following topics describe changes in this service pack that may require modifications to your MIMIX
environment after you install.
Special instructions are listed below by service pack. Perform any actions necessary for your
environment after installing. It is necessary to perform any special instructions provided for 7.1.03.00, as
well as any listed special instructions for service packs that are not yet installed. (You can skip special
instructions for service packs already installed on your system.)
2.0.03.00
Add IBM Flex System Event Log portlet to a custom page in VSP . . . . . . . . . . . . . .10
7.1.01.00
Perform a controlled end and change data group to use immediate commit mode. .12
Change definition for preexisting data groups to use shared object send process . .13
Update automation that uses MXSYSDFN outfile if needed . . . . . . . . . . . . . . . . . . .17
Change policies to allow priority auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Change journal definitions for systems on which target inspection will run . . . . . . . .26
Run DPYDGCFG for data groups before starting replication processes . . . . . . . . . .26
Evaluate programs for use of journal entry time stamp . . . . . . . . . . . . . . . . . . . . . . .33
Change FEOPT parameter for lock member during apply. . . . . . . . . . . . . . . . . . . . .35
Optionally install VSP on a Windows system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
7.1.03.00
Synchronize replicated *VLDL objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
\
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. 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(system) PORT(nnnnn)
where system is the host name or address and nnnnn is the port number or alias defined in the
transfer definition for the system on which you are running this command
3. 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 MXAUDITSCD job, and the MXCOMMD job:
installation-library/STRMMX
4. Repeat Step 2 and Step 3 for each additional MIMIX installation.
5. As needed, make any known configuration changes on any installation that was upgraded.
6. Perform this step if you will be using Vision Solutions Portal from a system running IBM i:
a. Do one of the following:
• If you installed using the MIMIX Installation wizard and accepted defaults, skip to Step b.
• If you installed using 5250 emulator processes and Vision Solutions Portal is not at a level
which supports the latest portal application, download the MIMIX Installation wizard from
Support Central and use that wizard to upgrade the Vision Solutions Portal server.
• If you installed using 5250 emulator processes and Vision Solutions Portal is presently at a level
compatible with the latest portal applications, make the portal application known to the server,
enter the command: VSI001LIB/ADDVSIAPP APP(MIMIX).
• If you want Vision Solutions Portal but it is not currently installed, you can use the MIMIX
Installation wizard and choose the option to install the portal application.
b. If you started Vision Solutions Portal from the MIMIX System i Installation Wizard, skip this step.
Otherwise, start the server using the following command:
VSI001LIB/STRVSISVR
The default port is 8410. Each instance of the server uses three consecutive ports. If you cannot
use this port, go to the Getting Started with Vision Solutions Portal book for instructions on
changing the port number and other information.
c. Enter the following URL in your web browser and Log In:
http://server:port
where:
• server is the IP address or host name where Vision Solutions Portal is installed
• port is the port number (the default is 8410)
7. As needed, update your Runbook. For more information about the Runbook, contact your certified
MIMIX consultant.
Note: The Runbook Capture Tool is not supported in V7.
8. If you use MIMIX Availability Manager™ to monitor earlier versions of MIMIX, specify the name of the
server instance to start in the following command:
LAKEVIEW/STRMMXAM INST(name)
The default instance name is MIMIXAM.
Note: MIMIX Availability Manager™ does not support monitoring of MIMIX V7 or later. It can only
be used to monitor installations running earlier versions of MIMIX.
9. If you use the Vision Solutions plug-in for the IBM® Systems Director Navigator for i5/OS® you must
end and restart the HTTP Administration Server. This plug-in is associated with MIMIX Availability
Manager. Check with your i5/OS administrator before doing the following:
a. End the server using the following command:
ENDTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
b. Confirm that all jobs in the QHTTPSVR subsystem have ended by using the command:
WRKACTJOB SBS(QHTTPSVR)
c. Start the server using the following command:
STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
d. Ensure that the ADMIN2 job in the QHTTPSVR subsystem is started before attempting to access
the Vision Solutions plug-in. Use the command:
WRKACTJOB SBS(QHTTPSVR)
10. Check your MIMIX status using the information provided in the Using MIMIX book.
11. If you plan to use Vision Solutions Portal from a system running the Windows operating system, use
the instructions in “Installing VSP 2.0 & Portal Application on Windows” on page 8.
Installing on Windows
Installing VSP 2.0 & Portal Application on Windows
These instructions are for the Vision Solutions Portal (VSP) 2.0 & Portal Application Installation
Wizard for Windows®. This wizard automatically installs the VSP server (version 2) and the portal
application for the selected Vision Solutions® product onto a system running a supported release of the
Windows® operating system. Support Central provides an executable (.exe) file which contains this
wizard.
Note: This wizard does not install the associated Vision Solutions 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.
Before installing VSP 2.0 & Portal Application on Windows

Before launching the Vision Solutions Portal (VSP) 2.0 & Portal Application Installation Wizard for
Windows®, ensure that your client workstation meets the following minimum requirements:
Note: Closing other applications will improve the performance of the wizard.
• 128 MB free RAM
• One of these operating systems: Windows® 2008 R2 or Windows® 7
• Minimum 8-bit color depth (256 colors)
• Minimum 1024 x 768 resolution
• The user who runs this wizard must have administrator privileges for the system on which it is run.
Installing VSP 2.0 & Portal Application on Windows

Vision Solutions Portal can be installed on a 64-bit or a 32-bit Windows® operating system. VSP server
software and product portal application are stored on the system in either \Program Files\ or
\Program Files (x86)\. If both folders exist on the system, the \Program Files (x86)\ folder
is used. For more information, see the wizard’s More Info document.
Shut down products

Default options will cause the wizard to shut down the VSP server if necessary. This affects access to all
instances, including instances of other products’ portal applications, running on the server.
Starting VSP 2.0 & Portal Application on Windows

The VSP server is automatically started on a Windows platform when default choices in the installation
wizard are used. If you choose to uncheck the option to start the VSP server, use the instructions in the
Getting Started with Vision Solutions Portal book to manually start it.
Highlights Version 7.1 Service Pack 7.1.03.00
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.
Validation list entry (*VLDL) updates are now correctly rep-

licated
Action required
After installing the service pack, customers who replicate *VLDL objects must synchronize all
replicated *VLDL objects. Use SYNCOBJ with an object type of *VLDL. (MXHA-10702)
Fixes included in service pack 7.1.03.00

Changes included in service pack 7.1.03.00 fix the following reported problems:
MIMIX
MXHA-9123 RTVDGSTS now returns *NONE for LCLSYSROLE if the local system is neither
the source or target system for the specified data group.
MXHA-10174 IFS permissions changed through the QSHELL command, CHMOD, now
replicates correctly.
MXHA-10396 Message LVI3354 has been updated to better explain information.
MXHA-10482 Processing time improved for DPYDGCFG command when run with either *ALL
or *DGIFSE is specified for INCLUDE.
MXHA-10558 MXREPMGR job improved to use less CPU when processing IFS exceptions.
MXHA-10573 CRTJRNDFN for the target journal definition now works for names that are less
than 6 characters.
MXHA-10591 OBJATR audit recovery no longer deletes objects from the target system when
they exist on the source system and the OBJONTGT policy is set to *DELETE.
MXHA-10606 SETDGAUD *AUTOJRN now runs on target system for initial start of a data group.
MXHA-10632 Message LVE0102 is no longer issued if IFS objects no longer exist when
updating the tracking database.
MXHA-10693 Target Journal Inspection no longer reports on entries prior to switches.
MXHA-10696 CRTMMXDFN no longer fails with LVE3905 when a journal migrated from OMS
has TGTSTATE(*STANDBY).
SP7.1.03.00 Highlights
MXHA-10703 In environments that replicate journaled IFS objects, newly created *STMF objects
now have their target journaling status set to *YES and the *STMF data is
replicated.
MXHA-10774 MIMIX upgrade from V7.0 to V7.1 no longer fails with MCH3601 messages when
converting IFS exception entries.
MXHA-10804 SYNCIFS and #IFSATR no longer fail with LVE0101 due to incorrect IFS path
length in installations with more than 2 nodes.
MXHA-10820 Target Journal Inspection no longer reports F-OP (File Opened) and F-CL (File
Closed) journal entries as unauthorized entries on Target.
MXHA-10823 MXREPMGR job improved to use less CPU when processing object and DLO
exceptions.
MXHA-10832 Target Journal Inspection no longer reports valid entries as "unauthorized on
target" after switching a DG of TYPE(*DB).
MXHA-10864 Shared audit reader now does additional checks before determining if a data
group should be added to its processing.
MXHA-10866 Improved performance of MXIFCMGR which no longer writes unneeded history
records for disabled data groups.
MXHA-10872 Database apply no longer fails with MCH3601 when the record in OMIFSXEP is
not found.
Vision Solutions Portal 2.0.03.00

IBM Flex System Event Log portlet
A new portlet is available within Vision Solutions Portal that can display events for a specified
IBM Flex System and resource group. The portlet also supports displaying events for a specified
IBM Systems Director server and resource group. Examples of events include an operation that
completes, a hardware component failure, or a processor threshold exceeded.
The IBM Flex System Event Log portlet displays events that the management server receives
from any resource to which you have authority to view. The portlet allows you to see events from
multiple resources, their status, and details about the event. This portlet does not have a shipped
location on any page within VSP. Instead, the portlet is available to be added to a custom page.
Action required
To use this portlet, you must add it to a custom page. Configure the portlet in edit mode and
specify the server address, a port for remote connection, and a resource group. (STR-2586)
Updates for Data Group Details and Activities Portlet

The Data Group Details and Activities portlet in the MIMIX portal application has the following
changes:
• On the DB statistics tab, the status of an RJ link monitor that is not configured is now
displayed as Unknown . Previously, a blank was displayed. Also, the status shown in the
Journal Cache and Journal State fields now displays as Unknown instead of a dash -
when the data group has not been started.
• On the DB statistics tab and the Object Statistics tab, status for Target journal inspection
processes is now always displayed when the data group is enabled and target journal
inspection is configured. Also, the status Not active indicates that target journal inspection
has not run because all data groups that use the journal definition as a target journal are
either new or re-enabled and have not been started.
• Several columns were added to the File Activity, IFS Tracking, and Object tracking tabs so
that all errors are displayed for each listed entry. An overall status column added left of the
listed entries identifies the most severe error. An Activity column shows the status of
replication errors. The Not Journaled - Source and Not Journaled - Target columns indicate
whether a journaling error exists. Previously, status identified only the most severe error. The
same changes were also made to the Related Files window.
• On the IFS Tracking and Object tracking tabs, the action Start Journaling has been added to
the toolbar. You can use this action to start journaling for multiple selected entries.
(MXHA-10421)

MIMIX
MXHA-10560 Priority based #IFSATR audit now correctly chooses objects to compare on the
remote side.
STR-2774 CHGVSISVR command now successfully updates the port number when run from
a job having a LANGID other than English or a CCSID other than 37.
7.1.02.00 (Included with 7.1.03.00) © Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 11
Immediate commit option for database apply

Environments that use commitment control can now optionally configure data groups to
immediately apply journal entries that are part of a commit transaction. Previously, the database
apply process (DBAPY) always delayed processing entries that were part of a commit
transaction until the journal entry indicating the commit completed was processed.
For most users, the immediate commit mode provides a performance improvement for the
database apply process. This can be significant in environments where long-running open
commit cycles occur regularly. In immediate commit mode, 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 is a concern if you use data on the
target system for reporting purposes.
Configuration - The Commit mode element is added to the Database apply processing
(DBAPYPRC) parameter on commands for creating and changing data group definitions
(CRTDGDFN, CHGDGDFN). The specified value for Commit mode determines how the apply
process will handle journal entries that are under commitment control. Its values are:
• *DLY - This is the default value and preserves the behavior of previous releases. MIMIX
delays applying journal entries that are part of a commit transaction until a C-CM journal
entry (set of record changes committed) or C-RB (set of record changes rolled back) for
the commit transaction is processed. This mode is preferred if a majority of commitment
cycles will be rolled back. This mode will also prevent reports run on the target system
from showing uncommitted data.
• *IMMED - MIMIX immediately applies journal entries that are part of a commit transaction.
This mode is preferred when the environment has long-running commitment cycles that
are eventually committed. With this mode, audits can more accurately compare data while
commit cycles are open because fewer transactions are held until the commit cycle
closes.
A similar change has been made to include the commit mode on the Display DG Definitions
display (option 5 on the Work with Data Group Definitions display [WRKDGDFN command]).
Status - The commit mode in use for a data group does have a noticeable effect on the
information displayed in certain detailed status fields.
• In a 5250 emulator, this can be seen when displaying detailed status for a data group
using option 8 from the Work with Data Groups display. When immediate commit mode is
used, the value of the Apply Point Sequence # on Database View 2, will be closer in value
to that displayed for the Processed Sequence # on Database View 1.
Previous service packs (included)
• In Vision Solutions Portal, this can be seen in the DB Statistics tab in the Data Group
Details and Activities portlet. When immediate commit mode is used and there is an open
commit cycle, the last sequence number processed should be near the last sequence
number applied. Also, the count of open commit entries will be lower in immediate commit
mode than in delayed mode.
Changes to starting data groups - The Start Data Group (STRDG) command and the
corresponding dialog in Vision Solutions Portal are changed to prevent starting a data group
following a change to the specified commit mode when a data group has open commit cycles.
Message LVEC0B3 is issued to indicate that open commit cycles must be resolved before a start
request can make the configuration change effective.
Additional changes - The following additional changes were made to provide programmatic
support for commit mode:
• Added the DBCMTMODE parameter to the Retrieve DG Definition 2 (RTVDGDFN2)
command.
• Added the DBCMTMODE field to the MXDGDFN outfile for the WRKDGDFN command.
Action required:
No action is necessary if you want to continue using delayed commit mode, which preserves
previous behavior of MIMIX. If you want to use immediate commit mode, do the following after
upgrading to or installing version 7.1:
1. Perform a controlled end of the data group that you want to change.
2. When the controlled end completes, verify that there are no open commit cycles using
DSPDGSTS DGDFN(name system1 system2) VIEW(*DBVIEW1).
3. Change the data group definition to specify *IMMED for the Commit mode element of the
Database apply processing (DBAPYPRC).
4. Start the data group.
(MXHA-62)
Data groups use shared object send process

The object send process reads journal entries from the system journal (QAUDJRN) on the
source system. Environments with multiple data groups that perform system journal replication or
any form of cooperative processing can benefit from a shared object send process. Sharing an
object send job among data groups decreases the total number of jobs reading from the system
journal (QAUDJRN), thereby reducing the CPU used by MIMIX on the source system.
New data groups now default to using a shared job per system for the object send process
(OBJSND). Also, now you can configure a data group to use a shared object send job that is
limited to a specific subset of data groups. The option to use a dedicated object send process per
data group, as in previous releases, is still available. Data groups that existed before upgrading
to version 7.1 must be manually changed if you want to use this capability.
Configuration - The Object send prefix element is added to the Object processing (OBJPRC)
parameter on the Create Data Group Definition (CRTDGDFN) and Change Data Group Definition
(CHGDGDFN) commands. The value specified for the Object send prefix determines whether
the object send process uses a dedicated or shared job as well as the prefix used in the job
name. Possible values are:
• *SHARED This default value results in the data group using the shared default object
send job on the source system. All data groups with the same source system that specify
*SHARED use the same job for the object send process. The prefix MX$ is used in the job
name, unless those characters are already used for a data group short name. In that case,
the third character of the prefix is changed to create a unique prefix.
• *DGDFN The object send job is unique to the data group and uses the data group short
name for the job name prefix. The value *DGDFN preserves the behavior of previous
releases.
• name When you specify a three-character prefix, this data group and any other data
groups on the same source system that specify the same prefix will share the object send
job with this prefix.
Note: A shared object send job can process journal entries for objects within SYSBAS or within
only one independent ASP. In environments with independent ASPs, each system within
the set of data groups sharing the same object send job must be identified consistently
within those data groups in the appropriate ASP group parameter (ASPGRP1 or
ASPGRP2). This is required regardless of whether a system is currently the source or
target for the data groups.
Status - Detailed status for a data group now indicates when the send process is shared.
• In a 5250 emulator, this is identified below the object send process field on the merged
view and right of the field on object views 1 and 2 of the Data Group Status display (option
8 from Work with Data Groups display or DSPDGSTS command). The value *SHARED
indicates the default shared job for the system is used. A three-character prefix indicates
the job is shared with a subset of data groups using the same prefix.
• In the Vision Solutions Portal, this is identified in the Send and receive row within the
Processes section of the Object Statistics tab of the Data Group Details and Activities
portlet. The name "Instance" is appended to the process name when the default shared
job for the system is used. When the data group uses a job shared with a subset of data
groups, its three-character prefix is appended to the process name. These values are also
included in flyover help for the process in this portlet as well as for the Source column in
the Data Groups portlet.
A prefix is not displayed in either interface when the data group has a dedicated object send job.
Start and end behavior - When starting data groups that share an object send process, the first
data group to start will start the shared job at that data group’s starting point in the system
journal. As additional data groups start, each recognizes that the shared object send job is active.
The object send job determines whether the starting point for that data group is earlier or later
than the sequence number being read. If the data group’s starting point is later, replication will
begin when the shared job reaches the data group's starting point. If the data group’s starting
point is earlier, the shared job completes its current block of entries, then returns to the earliest
point for any of the data groups being started. The shared job reads the earlier entries and routes
the transactions to the data group being started. When the shared job reaches the last entry it
read at the time of the STRDG request, it resumes routing transactions to all active data groups
using the shared job.
If the starting data group has a significant object send backlog, the other data groups sharing the
job will not receive transactions to replicate while the backlog for the starting data group is being
addressed. Therefore, when a backlog exists, it is recommended that you change the data group
configuration to use a dedicated job, start the data group, and allow it to catch up to the current
location of the shared job. Then end the data group, change its configuration to use the desired
shared job, and restart the data group.
When ending data groups that use a shared object send job, the job is ended by the last data
group to end.
Job restart behavior - When a object send job is shared by multiple data groups, the data group
with the earliest configured job restart time (RSTARTTIME) in the data group definition is used to
restart the shared job.
Additional changes - The configuration and status changes are also reflected in the following:
• Added OBJSNDPFX parameter to the Retrieve DG Definition 2 (RTVDGDFN2) and
Retrieve Data Group Status (RTVDGSTS) commands
• Added OBJSNDPFX field to the outfiles for WRKDGDFN command (MXDGDFN) and
WRKDG command (MXDGSTS) command
Action required:
If you want to use a shared object send process for data groups that existed before the upgrade
to version 7.1, do the following:
1. Ensure that data group does not have a significant backlog for its object send process.
2. End the data group.
3. Change the data group definition (CHGDGDFN) to specify either *SHARED or a prefix in the
Object send prefix element of the Object processing (OBJPRC) parameter.
4. Start the data group.
Determining the optimal number of data groups that can share an object send process in your
environment may require adding small numbers of data groups into a shared object send
process and monitoring the impact on performance and throughput. Factors include the number
of data groups acted on together, the type of data replicated by the sharing data groups, and the
existence or lack of persistent threshold conditions for the object send process. (MXHA-72,
MXHA-8737)
Arrivals and Backlog portlet

The new Arrivals and Backlog portlet on the Analysis page charts recent history of the rate at
which replication work arrived and the size of any replication backlogs. This portlet displays
information for instances running MIMIX version 7.1 or higher.
By charting historical arrival rates and backlogs together, it is easier to identify how trends and
anomalies in arriving journal activity correlate to when and why replication backlogs occurred.
Identification is key to reducing or eliminating the exposure that backlogs create.
All displayed arrival and backlog data are calculated and graphed by intervals. The Chart tab
graphs the calculated data and the Data tab identifies the numbers derived for each interval that
were used in the graphs. Each tab has separate sections for database and object replication. You
can expand or collapse each section or change settings in Edit mode to control which replication
process is displayed.
For each type of replication, three key pieces of information are displayed:
• Arrivals - the calculated number of transactions that have been arriving in journals on
source nodes within the selected time. This is the potential amount of work to perform.
The actual amount performed may have been filtered to smaller amounts.
• Backlog - the sum of replication backlogs within the selected time. This indicates whether
MIMIX processes kept pace with arrivals. For database replication, the chart and data tabs
include the RJ backlog. The RJ backlog represents the transactions on the source that
have not been transferred to the target. This is your exposure to data loss in the event of
an outage on the source.
• Process status - the worst of the tracked replication statuses within the selected time. This
indicates whether replication processes were stopped or replication problems may have
been the cause of a backlog.
Initially, the portlet displays data for all data groups in the instance over the past two hours,
calculated in five minute intervals. You can filter the data to specific node pairs or data groups, as
well as change the length of time for the displayed data, which also changes the length of the
intervals. Data displayed in the portlet is retrieved when the Analysis page is accessed or
refreshed. Changing filtering criteria refreshes your view of the data but does not retrieve new
data. (MXHA-1395, MXHA-8416)
Default naming convention changed for remote journaling

environments
MIMIX changed the naming convention used for target journal definitions automatically created
by the Create Data Group Definition (CRTDGDFN) command. In remote journaling
environments, target journal definitions created by the CRTDGDFN command now use the
convention that was previously recommended for multimanagement environments. This change
provides a consistent convention between two-node environments and MIMIX Global
environments. Any future transition from a two-node environment using this convention to a
three-or-more node environment will be simpler.
Also, MIMIX now assigns a two-character remote journal ID to each system in the installation.
The ID is used in the target journal definition naming convention to ensure unique target journal
and receiver names. IDs are assigned to existing system definitions during the upgrade to MIMIX
7.1 and to new system definitions when they are created. The ID can be displayed in the details
of a system definition, but it cannot be changed.
When target journal definitions are created by the CRTDGDFN command, they are created using
the format sourcenn@R, where:
• source is the first six characters from the journal name of the source journal definition.
• nn is the two-character remote journal ID of the source system.
• @R identifies the name as being for the remote (target) journal of a local-remote journal
pair.
If a journal definition name is already in use, the source is shortened to five characters and the
sixth character will be assigned a numeric value. The nn@R suffix is also used in the names of
the target libraries for the journal, receivers, and threshold message queue.
Existing journal definitions are not changed. Journal definitions created by the Create Journal
Definition (CRTJRNDFN) command or the Add Remote Journal Link (ADDRJLNK) command do
not use this convention. However, any new data groups created after the upgrade will create
target journal definitions using this naming convention. This convention is recommended if you
manually create target journal definitions.
Action required:
You may need to update any automation that uses the MXSYSDFN outfile. A field is added to this
outfile for the remote journal ID. If automation calls the WRKSYSDFN command specifying
OUTMBR(*ADD), update your automation to account for the new field. (MXHA-5708)
Clarified time of next attempt for entries in delay/retry

When an object activity entry is undergoing delay/retry processing, MIMIX now considers
whether the retry attempt is pending when displaying the time of the next attempt to process the
entry. The value *PENDING is now used to indicate the time of the next attempt has passed, and
processing for the entry is waiting while object replication processes are busy processing other
entries. This value appears in the following locations:
• The Timestamp of next attempt field on the Display DG Activity Details display (accessed
from option 5 on the Work with DG Activity Entries display)
• The Next retry field within the Retry Information section of the Activity Entry Details dialog,
(accessed from the Data Group Details and Activities portlet)
The field is only displayed on the system of the process that is in delay/retry.
The Next retry timestamp (NXTRTYTSP) field in the MXDGACTE outfile (WRKDGACTE
command) returns an alternative timestamp when an entry is pending. For more information, see
the MIMIX Administrator Reference book. (MXHA-5859)
Changes to Work with Systems (WRKSYS)

Several changes to the Work with Systems (WRKSYS) command and display now provide
support for outfiles, status for additional system level processes, and better correlation of function
to that provided in the Nodes portlet of the MIMIX portal application.
The WRKSYS command now has standard parameters for specifying output files (OUTPUT,
OUTFILE, OUTMBR) The output file created from the Vision-supplied model database file
MXSYSSTS, found in the product library. The outfile returns status for all system definitions.
The following changes were made to Work with Systems display:
• The new Journal Inspect. column shows the current combined status of target journal
inspection processes on the system. Inspection occurs on systems that are the target
systems for replication. The inspection process uses one job for each target journal to be
inspected on the system.
• The new Collector Services column shows the status of collector services on the system.
Collector services is necessary for the MIMIX portal application to function in Vision Solutions
Portal. Keeping collector services active also allows historical statistics to keep being
collected.
• Option 7 has been renamed to 7=System manager status. Previously it was named
7=Display status.
• Option 9=Start now includes all target inspection processes on the node.
• Option 10=End now includes all target inspection processes on the node. You can optionally
end collector services, and if the system is participating in a cluster, Cluster Services.
• Option 11=Jrn inspection status has been added to access the Work with Journal Inspection
Status display for the journal definitions of the selected system definition.
Related changes to other commands
• Parameters added to the Start MIMIX Manager (STRMMXMGR) and End MIMIX Manager
(ENDMMXMGR) commands allow starting and ending Target journal inspection
(TGTJRNINSP) and Collector services (COLSRV) on a system. Possible values for each
parameter are *YES and *NO.

– For the STRMMXMGR command, the default value for both parameters is *YES, which
starts the process. When *YES is specified for TGTJRNINSP and the specified system is
a target system for replication, a job is started for each journal that is configured for target
journal inspection.
– For the ENDMMXMGR command, the default value for TGTJRNINSP is *YES, which
ends the journal inspection jobs on the system. The default value for COLSRV is *NO,
which allows status to continue to be available in Vision Solutions Portal when other
processes on the system are ended.
• The Retrieve System Status (RTVSYSSTS) command added support to return values for
journal inspection status and collector services status, and to provide support for use with the
OPNMMXLST command. The following parameters have been added: LISTID,
RTNSYSDFN, JRNINSPSTS, and COLSRVSTS.
• The Open MIMIX List (OPNMMXLST) command now supports the value *SYSSTS for the
Type of request (TYPE) parameter for use with the RTVSYSSTS command.
(MXHA-5922)
Priority-based auditing
Version 7.1 introduces the concept of prioritized object auditing. Prioritized auditing can reduce
the impact of auditing on resources and performance that some customers experienced with
previous auditing capability (now called scheduled auditing). Prioritized object auditing benefits
customers who cannot complete IFS audits, cannot audit every day, or do not audit at all
because of time or resource issues.
The biggest difference between prioritized object auditing and scheduled auditing is how objects
are selected to be audited. The other significant difference is when each type of audit is allowed
to run.
• In prioritized object auditing, an audit run selects objects according to their internally
assigned priority category and an auditing frequency assigned to the category. The result
may be a subset of the objects replicated by the data group. Each time a prioritized audit
runs, its subset of objects selected to check may be unique. MIMIX automatically runs a
prioritized audit periodically within its specified time range every day. It may run
approximately once per hour or more often during its time range.
• In scheduled object auditing, an audit run selects all objects that are configured for the data
group and within the class of objects checked by the audit. MIMIX automatically runs the
audit according to its specified scheduling criteria. Each time a scheduled audit runs, all
eligible objects are selected.
A manually invoked audit is always a scheduled audit. The #DGFE audit is not eligible for
prioritized auditing because it checks configuration data, not objects. When both scheduled and
priority audits are allowed for the same rule and data group, MIMIX may not start a prioritized
audit if the scheduled audit will start in the near future.
MIMIX determines the auditing priority of each replicated object based on its most recent change,
most recent audit, and the frequency specified for auditing priority categories. At any time, every
replicated object falls within one of several predetermined categories. Objects that had
differences in their most recent audit have the highest priority. Objects in this category are always
selected, even if the differences were automatically resolved. Also, within all object selection
categories for prioritized object auditing, the #FILDTA audit always selects all members of a file
for which auditing is less than 100 percent complete. Policies determine how often replicated
objects within other priority categories are eligible to be selected for auditing.
Initially, the objects selected by a prioritized audit may be nearly the same as those selected by a
scheduled audit. However, over time the number of objects selected by a prioritized audit
stabilizes to a subset of those selected by a scheduled audit.
Results of prioritized audit runs are reflected within auditing user interfaces. When MIMIX is used
from the Vision Solutions Portal (VSP) you can use additional functions, such as filtering the
Replicated Objects portlet to the objects that had an audit status of not equal in their last audit.
Policies determine whether an audit for a data group runs by priority, by schedule, or both.
Policies also determine when prioritized audits are allowed to run every day and when scheduled
audits run. New data groups default to using both prioritized and scheduled auditing. Data groups
that existed before upgrading to MIMIX version 7.1 continue to use their existing values for
scheduled audits.
Action required: Customers who upgraded to version 7.1 and want to use prioritized object
auditing must change policies. Each unique audit for a data group must be set separately. This is
most easily done using the Policy Summary window in Vision Solutions Portal. It can also be
accomplished using the Audit Schedule portlet or the Set MIMIX Policies (SETMMXPCY)
command to specify values for the Priority audit (PTYAUD) parameter.
Policies for prioritized object auditing

Interfaces that allow setting or viewing policies used for auditing have changed to include
prioritized object auditing.
In VSP, the Audit Schedule portlet displays current policy values for scheduling the selected audit
and data group. The Audit Schedule Details dialog allows you to select prioritized object auditing
and to specify when priority audits can start and the frequency for each priority category. From a
5250 emulator, the Priority audit (PTYAUD) parameter added to the Set MIMIX Policies
(SETMMXPCY) command provides the same capability.
To change multiple audit schedules at the same time, use the Policy Summary window which can
be accessed from global action menus throughout the MIMIX portal application.
The policy values are:
Shipped default values for the Priority audit policy for new data groups.
Field Default value Additional values Description
Allowed to start (VSP) 3 a.m to 8 a.m. Any time (*ANY), *NONE Specifies a time range, in 24-hour
Start after, Start until format during which prioritized
(5250) audits are allowed to start. De-
selecting the Prioritized object
auditing checkbox in VSP or the
value *NONE prevents prioritized
auditing.
New objects Daily Hourly A new object is one that has not
been audited since it was
created.
Changed objects Daily Weekly, Monthly A changed object is one that has
been modified since the last time
it was audited.
Unchanged objects Weekly Daily, Monthly, None An unchanged object is one that
has not been modified since the
last time it was audited.
Audited with no Monthly Daily, Weekly, None An object with no differences is
differences one that has not been modified
since the last time it was audited
and has been successfully
audited with no changes on at
least three consecutive audit
runs. Objects remain in this
category until a change occurs.
Also, the Audit Schedules tab on the Policy Summary window now includes these columns for
prioritized auditing: Start After, Start Until, New Objects, Changed Objects, Unchanged Objects,
Audited with no Differences. Preferences allow control over which of these fields are displayed.
Changes to displayed auditing information

The following information is added or changed in both user interfaces.
Objects Audited (VSP) or Objects Selected (5250) - Identifies how objects were selected for
auditing in the most recent run of the audit. The user interfaces use different labels, as indicated.
• All (*ALL) - The audit run was a scheduled audit that was submitted either automatically by
MIMIX or manually by user action. Scheduled audits select all objects that are configured for
the data group and within the class of objects checked by the audit.
• Prioritized (*PTY) - The audit run was a prioritized audit that was automatically submitted by
MIMIX. Prioritized audits select only the subset of eligible objects within each auditing priority
category.
In VSP, Objects Audited appears in the following portlets: Audits, Audit Details, Audit History, and
Audits tab in the Audits, Recoveries, and Notifications.
In a 5250 emulator, Objects Selected appears on the initial view (Summary) of the Work with
Audits display, the new summary results view of the Work with Audit History display, and when
displaying audit details.
Compliance - The definition of audit compliance changed. Compliance is an indication of
whether the audit ran within the time frame of the compliance thresholds set in auditing policies.
For audits configured for scheduled object auditing or both scheduled and prioritized object
auditing, compliance status is based on the last run of a scheduled audit or a user-invoked audit.
For audits configured for only prioritized object auditing, compliance status is based on the last
run, which may have been a prioritized audit or a user-invoked audit. A user-invoked audit or a
scheduled audit checked all objects that were configured for the data group and within the class
of objects checked by the audit whereas a prioritized audit may have checked only a subset of
those objects.
In the 5250 emulator, compliance appears in the Compliance summary view of the Work with
Audits display and when displaying audit details. In VSP, compliance appears in the following
portlets: Audits, Audit Details, and Audits tab in the Audits, Recoveries, and Notifications.
Object Differences - In a 5250 emulator, the title of this column is shortened to Object Diff. and
the field will now display +++++ if more than 99,999 differences exist.
In VSP, Edit mode for the Audit History portlet allows you to control whether the portlet lists all
audit runs or hides prioritized audits when the objects selected for a priority audit is zero.
Next Scheduled Run and Priority Start Time - The next scheduled run of an audit is
specifically for scheduled auditing. Priority Start Time is added to identify when prioritized audits,
if used, are allowed to start. In VSP, Edit mode preferences for the Audits portlet controls whether
these columns are displayed. In a 5250 emulator, the Schedule summary view of the Work with
Audits display now includes a third F11 view that shows settings for priority auditing.
Prioritized audit results in Replicated Objects portlet

When selected in Edit mode for the Replicated Objects portlet, the portlet displays Last Audit
Details columns. The last audit of the object may have been either scheduled or prioritized. The
name of the last audit to include the object, the date it ran, the audit status, and a successful
audit count are displayed.
The Successful field displays the number of consecutive times the object was audited
successfully by the indicated audit. A successful audit is when the object is considered equal on
both nodes. Each successful audit increases the number by 1, except for the #FILDTA audit. An
audit status considered unknown does not change the count. Any other audit status resets the
number to 0. A dash (–) is displayed if the object has not been audited.
MIMIX is changed to clarify what is considered a successful #FILDTA audit when the audit runs
with the audit level policy set to 10 or 20. At those levels, the #FILDTA audit compares only a
percentage of file data with each audit run. It takes multiple runs of the audit to check 100% of the
data that exists when the first increment starts. MIMIX now tracks the percent complete and
updates the Successful field in the Replicated Objects portlet and the Object Details dialog only
after all file data that existed when the first increment started has been successfully checked.
Also, the Progress Toward Next Successful Audit column was added to the Object Details dialog
to indicate the percent of data successfully audited toward a complete audit. This column only
appears for *FILE objects audited by the #FILDTA audit. A dash is displayed for all other audit
types for this object. The percentage increases in 5% increments for each successful audit when
the audit level is set to 10. The percent complete increases in 20% increments for each
successful audit when the audit level is set to 20. A successful audit is when the object is
considered equal on both nodes. An audit status considered unknown does not change the
percent. Any other audit status resets the percent to 0 and hides the column. When the
percentage reaches 100%, this column is hidden and the value of the Successful column
increments by 1.
For more information, see “Replicated Objects portlet” on page 34.
Related changes
The Audit Details portlet now shows additional fields when the selected audit's status is Not run
or Waiting to run. The Objects to audit field indicates whether all objects will be selected by the
audit (a scheduled audit) or prioritized objects will be selected by the audit (a prioritized audit).
The Run on node field identifies where the audit will run. Also, the Last attempt field is no longer
displayed when the audit status is Not run.
Commands that compare attributes now have a new report type available. The Compare File
Attributes (CMPFILA), Compare Object Attributes (CMPOBJA), Compare IFS Attributes
(CMPIFSA), and Compare DLO Attributes (CMPDLOA) commands now support the value
*OPTIMIZED for the Report type (RPTTYPE) parameter. The value *OPTIMIZED creates a
combined report that indicates at an object level when the objects are equal. For objects that are
not equal, the individual attributes that are not equal are included in the report. Audits now use
this report type to return results.
Outfile changes:
The Objects selected (OBJSEL) field has been added to the MXAUDHST outfile for the Work
with Audit History (WRKAUDHST) command to identify how objects were selected for the audit
run.
The System 1 object type (SYS1OBJTYP) and System 2 object type (SYS2OBJTYP) fields have
been added to the following outfiles to facilitate tracking audits for each object:
• MXCMPIFSA outfile for the Compare IFS Attributes (CMPIFSA) command
• MXCMPDLOA outfile for the Compare DLO Attributes (CMPDLOA) command
(MXHA-5930, MXHA-8134, MXHA-9431)
Changing audit scheduling policies for multiple audits

Through Vision Solutions Portal, you can now change scheduling information for multiple audits
at once.
On the Audit Schedules tab on the MIMIX Policy Summary window, checkboxes next to the listed
audits allow you to select one or more audits to be changed using the Change action on the
toolbar. The Change action opens the Audit Schedule Details dialog.
The Audit Schedule Details dialog is changed so that, when multiple audits are selected from the
Policy Summary window, the Prioritized Object Auditing and Scheduled Object Auditing fields
appear as dropdown lists with values of No Change (default), Enable, and Disable. When Enable
is selected in either field, its associated subfields are displayed and also support a value of No
Change. This allows you to change one scheduling attribute without changing other attributes for
the selected audits.
When the selected audits are all #DGFE, none of the prioritized object auditing fields are
displayed. (MXHA-8913)
Changes to support enhanced environment analysis fea-

tures
Version 7.1 of MIMIX includes several significant enhancements for analyzing your replication
environment. To support making those enhancements possible, the following changes were
made.
MXCFGJRN journal definitions and journal environments

A journal and a journal definition named MXCFGJRN will now exist on each system within an
installation. The MXCFGJRN journal definitions will appear on the Work with Journal Definitions
display (WRKJRNDFN). However, these definitions and their associated journaling environments
are for internal use by MIMIX and should not be used for other purposes or deleted.
The MXCFGJRN journal is created on each system during the install or upgrade to MIMIX
version 7.1. For existing environments, the upgrade process also creates the MXCFGJRN
journal definitions for each system definition in the installation library. For new environments,
when you create a system definition, the MXCFGJRN journal definition for that system is
automatically created.
The following changes were made to prevent this environment from being deleted, which would
adversely affect your installation:
• The Delete Journal Environment (DLTJRNENV) command is changed to prevent deleting
the MXCFGJRN journal.
• The Delete Journal Definition (DLTJRNDFN) command is changed to prevent deleting the
MXCFGJRN definition.
Deploy Data Group Configuration (DPYDGCFG) command

The new Deploy Data Group Configuration (DPYDGCFG) command will deploy data group
configuration entries to create an internal list of the current objects being replicated. MIMIX uses
this information as input for other functions, such as the Replicated Objects portlet within Vision
Solutions Portal.
The Include entries (INCLUDE) parameter determines which types of data group entries are
deployed. The default value *ALL will deploy the full configuration for the specified data group.
Other possible values include: *DGFE (file entries), *DGOBJE (object entries), *DGIFSE (IFS
entries), *DGDLOE (DLO entries), and *DGDAE (data area entries).
MIMIX automatically deploys configuration information when a data group is started if MIMIX
detects that the data group had a change to its replication scope (name space). This includes the
scenarios described in “Starting replication the first time after installing or upgrading”. After the
configuration is deployed, MIMIX processes keep the internal list of the current objects being
replicated up to date as objects are deleted, moved in or out of the name space, or as other
cooperative processing activities affecting the name space are performed.
The DPYDGCFG command interface is primarily for customers and MIMIX service
representatives to verify that a new or existing configuration will include all expected objects, or
to potentially expedite the subsequent start data group (STRDG) request following configuration.
Starting replication the first time after installing or upgrading

Start data group requests (STRDG command) automatically invoke the DPYDGCFG command
as needed to ensure that any configuration changes affecting the set of objects to replicate are
deployed. The deploy activity is necessary to ensure that MIMIX functions have access to the
most up-to-date information.
The first time you start data groups after upgrading to MIMIX version 7.1 or after configuring a
new installation may take an extended amount of time while the configuration is deployed. For
environments that replicate large quantities of IFS objects, this may be significant and may take
hours.
Action required:
To avoid a potentially long delay when starting replication processes the first time on version 7.1,
you can use the DPYDGCFG command to manually deploy the configuration.
For new installations, it is recommended that you run the DPYDGCFG command from the source
system of each data group after you have completed adding configuration entries for the data
group. Do this before starting the data groups the first time.
For upgraded installations, the upgrade process deploys all configuration information, except for
IFS entries, for existing data groups. You can use the command DPYDGCFG INCLUDE(*IFSE)
from the source system of any data group that replicates IFS objects to deploy the IFS
configuration. Allow the command to complete before starting replication processes.
Improved performance for clear pending starts

The Start Data Group (STRDG) command no longer needs to re-prime IFS tracking entries for
journaled IFS objects when the start request specifies to clear pending entries (CLRPND(*YES)).
In environments with large amounts of journaled IFS objects, this can be a significant time
improvement, including when starting data groups following a switch.
Improved start time for disabled data groups

In resource groups that include active and disabled data groups, the disabled data groups are
now kept current with changes that create or delete IFS tracking entries. As a result, the time
required to enable and start a disabled data group is reduced.
(MXHA-5933)
Target journal inspection

Version 7.1 of MIMIX includes the ability to automatically inspect journals on the target system for
changes to replicated objects by users or programs other than MIMIX. Data integrity of replicated
objects can be affected if they are changed on the target system. Also, changing replicated
objects on the target system can cause repeated auditing activity for those objects.
Target journal inspection consists of a set of processes that run on a system only when that
system is the target system for replication. Each process reads a journal to check for users or
programs other than MIMIX that have modified replicated objects. When target journal inspection
is enabled in the configuration, the number of inspection processes depends on how many
journals are used by data groups replicating to that system. There is one inspection process for
the system journal (QAUDJRN) regardless of how many data groups use the system as a target
system. Each user journal on the target system also has an inspection process.
Note:
– Target journal inspection does not occur for the journals identified in the following journal
definitions: JRNMMX, MXCFGJRN, and those that identify the remote journal used in RJ
configurations (whose names typically end with @R).
– In environments that perform bi-directional replication, target journal inspection does not
report a target object as changed by user when that object is also replicated by a different
data group using that system as its source.
– The first time that a target journal inspection process is started, it begins at the first entry
of the currently attached journal receiver regardless of where replication from the journal is
started. This can result in false target journal inspection notifications being reported.
For new installations, shipped default values for journal definitions and data group definitions
allow MIMIX to automatically perform target journal inspection.
Action Required: Journal definitions that existed before upgrading to MIMIX version 7.1 do not
automatically allow target journal inspection. Customers who have upgraded and want to use
target journal inspection need to change journal definitions for systems on which target
inspection will run. In switchable environments, change all journal definitions associated with the
data group that can become a target journal to allow inspection to start on the opposite system
following a switch. Also, data group definitions that perform user journal replication may need to
be changed to allow journaling on the target system. For examples and detailed instructions, see
topic "Performing target journal inspection" in the MIMIX Administrator Reference book.
Viewing results
Each target journal inspection process sends a notification once per day per user that changed
objects on the target system. The notifications appear in the Notifications portlet in Vision
Solutions Portal (VSP) and on the Work with Notifications display (WRKNFY command). The
source of these notifications is identified as TGTJRNINSP. You can view the details of the
notification from either user interface.
Only the first object changed by the user is identified in the notification. However, each object
changed by the user is logged in an internal database along with the notification ID. The
notification ID is used by enhanced capabilities available only when using MIMIX in VSP.
When using MIMIX through Vision Solutions Portal, the filter on the Replicated Objects portlet
allows you to see a list of objects changed on the target system. You can further filter by a
particular user, program, job, or notification ID. Also, when viewing details of a notification sent by
target journal inspection, the notification ID is displayed in the Notification Details dialog. You can
use this ID in the filter for the Replicated Objects portlet to see a list of objects changed by this
user on the target node. These capabilities are only available through Vision Solutions Portal.
Automatic correction of errors found by target journal inspection

MIMIX supports automatic correction of objects identified by target journal inspection as
"changed on target by user".
The replication manager (MXREPMGR) is a new transient process that runs in the MIMIXSBS
subsystem as needed. When target journal inspection identifies a problem with a target system
object, the replication manager process starts and evaluates how to resolve the problem. The
following types of problems are addressed:
• Replicated object was modified on target system. The replication manager updates the
internal priority for auditing the object so that the object becomes eligible for the next run of a
priority object audit. The next run (either scheduled or priority-based) of an audit which
checks the object type will correct the problem if the automatic audit recovery policy is
enabled.
• Object created on target system is within replication scope. The replication manager uses the
current settings of the Object only on target (OBJONTGT) policy to determine whether to
recover the object to the source system. If the policy permits, the object is synchronized to
the source system. The policy can also be set to delete the object from the target system.
• Replicated object was deleted on target system. The replication manager determines if the
object still exists on the source system. If the source object exists and is still within the
replication scope, it is synchronized to the target system by the next run of an audit which
checks the object type.
MIMIX tracks error conditions for three days. Once an error condition is corrected, the object will
no longer be identified as being "changed on target by user" in the Replicated Objects portlet.
Also, if it is not already started, the replication manager is started by the system manager to
perform daily cleanup activities.
Changes to support inspection status

Status for target journal inspection appears in several locations. The most useful place to start
when checking status of target journal inspection is at the system level.
• Summary of inspection status for a system - In VSP, the Nodes portlet includes a
summary of all target journal inspection processes on a node (system) In detailed view, the
Journal Inspection column is added under the group heading for Services. In summary view,
inspection statuses are included in the roll up into Srv column. From a 5250 emulator, the
processes for a system are summarized on the Work with Systems display (WRKSYS
command). Details of these changes are described in “Changes to Work with Systems
(WRKSYS)” on page 18.
• Individual inspection process status - In VSP, the new Journal Inspection Status window
displays a list of journal definitions and the status of the target journal inspection job for the
journal associated with each journal definition. This window is accessed using the Journal
Inspection Status action on the Nodes portlet and from several other locations. From a 5250
emulator, the Work with Journal Inspection Status display provides the same information.
This display using option 11 on the Work with Systems display or the new Work with Journal
Inspection (WRKJRNINSP) command. You can display details about the last entry inspected
from either user interface.
• Summarized with node status for an application group - In VSP, the Application Node
column in the Application Groups portlet includes target journal inspection processes along
with a summary of other system-level processes for all the systems in the application group.
From a 5250 emulator, the App Node Status column on the Work with Application Groups
display provides the same information.
• Summarized with manager status for a node in an application group - In VSP, when the
Recovery Domain portlet displays the recovery domain of an application group, the overall
status of a node includes all target journal inspection processes on the node along with the
status of other node-level processes. From a 5250 emulator, the same summarized system-
level process status appears in the Manager Status column of the Work with Node Entries
display.
• Summarized for target journals of a data group - At the data group level, there can be at
most two inspection processes with status. In VSP, the Data Groups portlet includes a
summarized status of the target journal inspection processes associated with a data group. In
the portlet's summary view, this is in the Target status values. In the details view, this is in the
Tgt Jrn column. From a 5250 emulator, the Work with Data Groups display (WRKDG)
includes a summary of the target journal inspection processes associated with a data group
in the Target Mgr column.
• Individual process statuses in data group details - When displaying detailed status of a
data group, status is also available for the individual inspection processes associated with
target journals for that data group. In VSP, this information is in the Data Group Details and
Activities portlet. The portlet's DB Statistics tab includes as many as two separate rows in the
Supporting Processes section, for the target user journal and system journal inspection
processes. The Object Statistics tab has one possible row in the Supporting Processes
section for the target system journal inspection process. From a 5250 emulator, the merged
view of the Data Group Status display (DSPDGSTS command) includes target journal
inspection status in the Sys Jrn Insp and User Jrn Insp fields within the Target Statistics
section. In both user interfaces, inspection status is not displayed if target journal inspection
is not configured or the data group has not been started.
Changes that support starting and ending inspection processes

Target journal inspection processes are run only when the system is the target for replication.
Inspection processes are started and ended at the system level; a single inspection process for a
specific journal cannot be started or stopped independently of other inspection processes on the
same system.
• Starting MIMIX - The Start MIMIX dialog (in VSP) and the Start MIMIX (STRMMX) command
include starting target journal inspection processes.
• Ending MIMIX - The Stop MIMIX dialog (in VSP) and the End MIMIX (ENDMMX) command
include stopping target journal inspection processes. Also, these interfaces have changes to
how audits in various in-progress conditions are handled when MIMIX ends, which are
described in help text.
• Starting and ending MIMIX managers - Target journal inspection processes are started and
ended along with system managers. This includes restarting daily when system manager
restarts. In VSP, the Start Managers and Services dialog and the Stop Managers and
Services dialog include target journal inspection. 5250 emulator changes to the Start MIMIX
Managers (STRMMXMGR) and End MIMIX Managers (ENDMMXMGR) commands are
described in “Changes to Work with Systems (WRKSYS)” on page 18.
• Starting data groups - If target journal inspection is configured and not already started,
starting data groups will automatically start target journal inspection processes on the target
system.
• In VSP, the new Start Target Journal Inspection and Stop Target Journal Inspection dialogs
allow you to start or stop all inspection processes for journals being inspected on a node.
These dialogs are accessed by the actions from the Target Journal Inspection window and
from the Data Group Details and Activities portlet.
Related changes to MIMIX portlets

The following additional changes associated with target journal inspection were made to portlets
in the MIMIX portal application.
In the Data Group Details and Activities portlet, icons on DB Statistics and Object Statistics tabs
now reflect status of disabled data groups and target journal inspection.
In the Notifications portlet, checkboxes added to the headings for the New and Acknowledged
lists allow you to take action on multiple notifications at once.
In the Recovery Domain portlet, the resulting dialogs from these actions have changed:
• The Start action now calls the Start Managers and Services Dialog instead of Start MIMIX
Managers dialog. When called from this portlet, the dialog starting the master monitor is not
possible and other managers and services can be started only on selected node.
• The Stop action now calls the Stop Cluster Services dialog. This action from this portlet does
not stop target journal inspection.
In the Nodes portlet, the Start action now calls the Start Managers and Services dialog.
Related changes to commands and displays

The following additional changes associated with target journal inspection were made to the
5250 emulator user interface.
On the Work with Data Groups display (WRKDG command), the Mgr columns for source and
target now report only the status of the managers associated with the data group on that system.
Previously, these columns included a summary of all manager statuses for the system.
The Create Journal Definition (CRTJRNDFN) command added the Target journal inspection
(TGTJRNINSP) parameter. The default value, *YES, allows the specified journal to be inspected
when the system specified in the journal definition name is the target system for replication. The
value *NO prevents inspection of the journal. When *YES is specified, the value specified for
Target journal state (TGTSTATE) must be *ACTIVE. The TGTJRNINSP parameter is also added
to the Change Journal Definition command.
Changes to the Work with Journal Definitions display include:
• The Jrn Insp column identifies whether a journal definition will permit inspection when its
system is a target system. (This is also available when option 5=Display is used.)
• When option 13=Data group definitions is selected for a journal definition that identifies a
user journal, this new option provides access to the subset of data group definitions that
include the selected journal definition.
The MIMIX Availability Status display (WRKMMXSTS) command includes problems with target
journal inspection status in the Services row.
Retrieve command changes:
• The Retrieve Journal Definition (RTVJRNDFN) command added the TGTJRNINSP
parameter to receive the indicator for whether journal inspection is performed for data groups
that specify this journal definition as the target journal definition.
• The Retrieve Journal Status (RTVJRNSTS) command has the following changes:
– The JRNDFN parameter no longer allows the value *ALL for either the name or system of
the journal definition.
– Parameters JRN and JRNLIB are added to receive the journal name and library
associated with the specified journal definition.
– Several parameters are added to receive the status of the target journal inspection
process for the journal definition (JRNINSPSTS), the name of the receiver
(INSPJRNRCV) and library (INSPRCVLIB) of the last entry processed by journal
inspection, as well as the sequence number (INSPSEQNBR), date (INSPDATE), and time
(INSPTIME) of the last entry processed by journal inspection.

• Changes to the Retrieve System Status (RTVSYSSTS) command are described in “Changes
to Work with Systems (WRKSYS)” on page 18.
Outfile changes:
• The Work with Journal Definitions (WRKJRNDFN) command's MXJRNDFN outfile added the
TGTJRNINSP field for whether target journal inspection is allowed.
• The new Work with Journal Inspection (WRKJRNINSP) command supports the MXJRNINSP
outfile for inspection process status.
• Additions to the Work with Systems (WRKSYS) command's outfile are described in “Changes
to Work with Systems (WRKSYS)” on page 18.
(MXHA-5929, MXHA-5931, MXHA-10228)
Audits and Recoveries portlet renamed

The Audits and Recoveries portlet has been renamed to the Audits, Recoveries, and
Notifications portlet. With this change a new tab, Notifications, has been added which provides
similar functionality as the Notifications portlet. (MXHA-7967)
Message Log support in MIMIX portal application

You can now access messages in the MIMIX message log from within a MIMIX instance in Vision
Solutions Portal. The Message Log window displays messages in the message log according to
the context from which the Message log action was selected. The displayed messages can be
filtered by message attributes, sending process, originating node, job, and other criteria. The
Message Log window also supports actions to display messages related by job number to a
selected message, display details of a message, and delete messages.
The Message Log action is added to the following interfaces:
• Application Groups portlet
• Data Groups portlet
• Audits, Recoveries, and Notifications portlet
• Audits portlet
• Audit Details portlet
• Audit Details dialog
• Audit History portlet
• Audit History Details dialog
• Recoveries window
• Recovery Details dialog
• Notifications portlet
• Notifications window
• Procedures portlet
• Step Status portlet

• Model Switch Framework portlet
When the action is used from a global action menu, the log displays all messages for the
instance, or in some cases, the node and instance. When the action is used from an item action
menu, the log is filtered to messages for the selected item or to messages for the job associated
with the selected item. (MXHA-5957)
Policy Summary window added

The new MIMIX Policy Summary window makes it easy to view the current policy settings across
all data groups in your environment and identify which data groups have overridden instance-
level policies. The window has multiple tabs – Replication, Audits, Audit Schedules, and Other –
that correspond to tabs in the Instance Policies and Audit Schedule dialogs.
A Policy Summary action is added to the following locations to provide access to the MIMIX
Policy window. The window opens to the tab appropriate for the location from which it was
selected:
• Data Groups portlet on the Summary page
• Data Groups portlet on the Data Groups page
• Audits portlet on the Audits page
• Procedures portlet on the Procedures page
• Model Switch Framework portlet on the Procedures page
• Replicated Objects portlet on Analysis page
The Replication tab and Audits tab display the instance-level settings in the first row, followed by
a row for each data group. On these tabs, data group rows display any override values or use an
icon to indicate that the instance value is used.
Policies on the Audit Schedule tab can only be set at the data group level so there is no instance
row. There are rows for every audit for each data group. You can use the Filter button to filter the
list by data group or by audit type. This tab also displays the next scheduled run of the audit.
Policies on the Other tab can only be set for the instance so there are no data group rows on the
tab.
From any tab, selecting the Details action from a row opens the corresponding dialog to use to
change policies for the selected row.
Preferences control how many rows of data groups are displayed per page. You can also use
preferences to choose which columns to display on the Replication, Audits, and Audit Schedules
tabs. All columns are displayed by default. (MXHA-5966)
ENDDG performance improved when activity entries are in

delay/retry
MIMIX has changed the way in which requests to end data groups handle activity entries for
which processing has been delayed. The following changes improve the performance of the End
Data Group (ENDDG) command and any command or procedure which invokes it, such as
ENDMMX, ENDAG, and switching steps that end data groups.
An ENDDG request now does the following:

• Checks for activity entries in object retrieval delay. Any entries currently in delay are
immediately processed as if the delay had completed. The object retrieve processing for
the activity entry must complete its attempt (either successful or failure). Then the ENDDG
request continues as if there was no object retrieval delay in use.
• Checks for activity entries in delay/retry cycles. If a controlled end (ENDOPT(*CNTRLD))
was requested, any delayed entry is retried without waiting for the first or second delay
interval (specified in the data group definition) or the third delay interval (specified within
policies). Either the entry is processed successfully and progresses to the next replication
process, or it is marked as Failed. (MXHA-6169)
Journal at creation changes due to QDFTJRN retirement

Journal at creation ensures that newly created objects are journaled and therefore can be
replicated. Shipped defaults for data group definitions permit journal at creation (JRNATCRT
parameter). Due to underlying changes by IBM, MIMIX changed the manner in which Journal at
creation is supported.
IBM announced the retirement of the QDFTJRN data area in the follow-on release to IBM i 7.1.
Its replacement is the Start Journal Library (STRJRNLIB) command, introduced in IBM i 6.1.
On systems running IBM i 6.1 or higher, MIMIX is changed to remove dependencies on the
QDFTJRN data area and to use the support provided by the STRJRNLIB command. MIMIX
removes the QDFTJRN data area from replicated libraries. Customers are advised not to re-
create the QDFTJRN data area after upgrading to MIMIX version 7.1.
On systems running IBM i 5.4, MIMIX continues to use the QDFTJRN data area for journal at
creation. (MXHA-6294)
Improved performance for DBRDR and DBSND

The database reader (DBRDR) process and database send process (DBSND) have been
changed to use a more efficient format for accessing journal data. The format now used does not
expose the journal entry date field as an SAA format. The date field is converted as needed
within MIMIX processing.
Action required: Customers whose environments use database replication user exit programs
need to evaluate the programs for any use of the journal entry time stamp. Contact your Vision
Solutions representative for more information. (MXHA-6408)
Improved display of member errors in File Activity Details

window
In the Data Group Details and Activities portlet, both the File Activity tab and the Object Activity
tab support actions that display the other tab's activity details in secondary windows. Previously,
data may not have been displayed in the secondary windows as expected.
The File Activity Details Window now supports displaying multiple member information for the
selected file that is experiencing replication problems. A field is added to identify the member
name, and the status of each member is identified with an icon. A Filter button and controls for
page navigation have also been added.
The new Filter Activity Details dialog allows you to filter the File Activity Details window by file
member in error and to set the maximum number of activities to display for the file.
Page navigation controls have been added to the Object Activity Details Window. The default
number for the maximum activities displayed is now 100. (MXHA-6631)
Replicated Objects portlet

The Replicated Objects portlet displays objects that match objects configured for replication for
all data groups within an instance. The objects displayed are those that are within the replication
scope on the source system of the data groups. For instances running MIMIX version 7.1 or
higher, this portlet also displays information about whether objects were changed on the target
node outside of normal replication processes, last changed on source, and last audit information.
The portlet has tabs for libraries, directories (IFS), and folders (DLO) as well as a content area
where replicated objects are listed. A tree control on each tab provides navigation through the
available data. The content area displays the replicated objects that are within the library,
directory, or folder selected from the tree of the current tab. When auditing history has been
retained, actions are available for displaying an object’s audit history and the audited objects
within a selected library, directory, or folder.
Robust filtering capability is available to limit the displayed objects to those changed on the
source system within a selected length of time, by object type, by data group, or by application
group. You can also filter the portlet by the status of the most recent audit of the objects or by
attributes of information retained about changes to objects that occurred on the target node
outside of MIMIX operations.
For replicated IFS objects, directories (*DIR) are displayed regardless of their configured method
of replication. However, only cooperatively processed stream files (*STMF) and symbolic links
(*SYMLNK) can be displayed in the portlet. *STMF and *SYMLNK objects replicated entirely
through the system journal cannot be displayed. A message indicates when a selected directory
contains but cannot display these objects.
For replicated files with members, each member can be audited by three different audits. The
portlet displays only the most recent of these audits. Use the Details action for the object to view
information about the most recent results from all three audit types.
In environments with more than two nodes or that perform bi-directional replication, replicated
objects may appear in the list multiple times, once for each data group that replicates the object.
The three-part name of the data group and the direction of replication distinguish the objects. The
three-part name is available in flyover text for the data group column and in the object details.
You can also filter by the three-part name. Objects in disabled data groups are not displayed by
default.
Normal replication and audit processes update the data available for display in the portlet. During
initial configuration, configuration changes, and regular validation activities, a message at the top
of the portlet indicates that some objects may not appear until MIMIX finishes collecting
information about objects. (MXHA-7125)
Improved performance when starting and ending data

groups
Performance is improved for all operations that start and end data groups which specify *YES for
the Lock member during apply element of the File and tracking entry options (FEOPT) parameter
in their data group definitions or data group file entries. This affects the STRMMX, STRAG,
STRDG, ENDMMX, ENDAG, and ENDDG commands as well as the end data group request
during a planned switch and all equivalent actions in Vision Solutions Portal/MIMIX portal
application. Configurations that have a large number of files in one database apply session will
benefit the most from this improvement.
Action required:
Locking members during database apply remains best practice for MIMIX. If you previously
changed the configuration to specify *NO for Lock member during apply for performance
reasons, Vision Solutions recommends that you change the FEOPT parameter to specify *YES
for the Lock member during apply element. (MXHA-8072)
Duration added to Audit Details, Audit History portlets

The following portlets and dialogs were updated to include audit duration. Duration is the amount
of time that the audit ran from start to completion.
• The Audit Details portlet and Audit Details dialog now include the start time of the audit from
the node on which the audit originated as well as its duration.
• The Audit History portlet and Audit History Details dialog now include duration. In addition,
the Status column in the Audit History portlet moved to the left of the Audit Start column. The
Audit Start column was previously named Audit Run.
(MXHA-8318)
Improved compare of *DTACRC attributes by #OBJATR

audit
The #OBJATR audit and the Compare Object Attributes (CMPOBJA) command now perform a
more thorough check of the *DTACRC attribute for query definition (*QRYDFN) and query
management form (*QMFORM) object types. This check is always performed for *QMFORM
objects. For *QRYDFN objects, the most thorough check is performed when the systems on
which the compared objects exist are at the same release of IBM i. (MXHA-8619)
Audit History default changes

Audit History has been changed to be turned on by default. Audit history provides historical
information about audit results and the objects that were audited. You can choose the minimum
number of days to retain audit history in the Set MIMIX Policies (SETMMXPCY) command. In
Vision Solutions Portal, the Audit History Retention is set on the Audits tab of the Policy
Summary window.
Audit history will be automatically enabled for all new MIMIX version 7.1 installations.
Installations that have upgraded to version 7.1 will retain their previous values for the audit
history retention policy.
The 7.1 shipped default values for audit history are:
• Minimum days is 7 (unchanged)
• Minimum runs per audit is 1 (unchanged)
• Object details is now *YES (was *NO)
• DLO and IFS details is now *YES (was *NO)
(MXHA-8748)
Status icon changes within MIMIX portal application

Some of the icons that represent status values within the MIMIX portal application have changed.
Procedure status icons shown in the Application Groups portlet now more clearly represent
current status. Held recoveries require user action to resolve, so their held status is now
represented by a red icon and rolled up into higher level status throughout the portal application.
Queued statuses are considered active and are now represented by green icons. Additional
changes were made to consistently represent statuses for similar concepts across portal
applications for all Vision Solution products. (MXHA-8858)
Data Group Details and Activities portlet

The tabs in this portlet no longer display status icons when the selected data group is disabled.
(MXHA-9485)
On the DB Statistics tab, a dash ( - ) is now displayed in the Journal Cache and Journal State
columns instead of no value when IBM i option 42 - High Availability Journal Performance, is not
installed on this system. (MXHA-9585)
New held recovery status for audits

A new audit status indicates that a held recovery exists for an audit and requires user
intervention before the audit can complete. (MXHA-9543, MXHA-9860)
The following table summarizes icon changes.
Status icons for MIMIX portal application

Status Old Icon New Icon Where Used
Held Was not Instance status in navigation area
represented Instance in Enterprise Status portlet
Recovery held None Audits portlet

Audit Details portlet
Audit Details dialog
Audits tab on the Audits, Recoveries, and
Notifications portlet
Data Groups portlet, Audits column (summary
view) and Audits Status column (detailed view)
Replication column in Application Groups portlet
Replication column in Resource Groups portlet
Overall status in Data Groups portlet
Held None Status column in Data Groups portlet
Held Recoveries, in recovery-specific locations
Switching Actual audit In Audit and Compliance columns in Data Groups

status. portlet.
Actual (Audits and compliance do not switch.)
compliance
status.
In progress Model Switch Framework
Switch in progress
Sync in progress
Active Recoveries, Procedures, Steps
Ending Recoveries
Queued Procedures
Compare active File activity

Compare repair
Compare release

Comparing Audits, all locations
Recovering
Waiting to run
Completed with errors Procedures column in Applications Groups portlet
Completed Procedures column in Applications Groups portlet
Successful Audits column in Data Groups portlet
Acknowledged Procedures
Acknowledged Audits
No procedure has run Procedures column in Applications Groups portlet
No replication (data is Replication column in Application Groups portlet

on switchable Dash (-)
hardware)
New Procedure, Audit

Blank
The following changes are for the Data Group Details and Activity portlet.
Held Reorganize File Activity tab
Held Promoter File Activity Details window
Held Rename Related Files window
Release
Held Rename IFS Tracking tab
No status Blank Object Tracking tab
Held Reorganize File Activity tab

Held Promoter File Activity Details window
Held Rename Related Files window
Release

Held Rename IFS Tracking tab
DPYDGCFG command no longer fails

The DPYDGCFG command no longer fails when processing IFS entries whose path names do
not match due to case sensitivity. For IFS directories replicated through the system journal, the
replicated objects database now stores path names all in lower case which corrects the issue
with case sensitivity. (MXHA-9091)
Enhancements for Intra Environments

Support has been added to allow multiple Intra configurations in one installation. Previously, only
one intra configuration was allowed per installation. Now, multiple Intra configurations are
allowed with the following considerations:
• A unique name of INTRAnnn is now supported to represent the system definition (SYSDFN)
used for an Intra environment. In the second part of the name, nnn is up to 3 valid system
definition characters. Previously, an Intra environment could only be named “INTRA”.
• Intra installation library names still must end in “I”. Configuration of the product library
(PRDLIB) parameter in the system definition is now required for Intra environments. For
example, a library named ABC would need to be named ABCI in order to be valid for an Intra
configuration. Previously, this parameter was handled by default. With the support of multiple
Intra configurations in one installation, you must manually specify this parameter.
• Remote journaling with both *SYSJRN and *USRJRN data groups is now compatible with
Intra communications.
For detailed information about configuring Intra communications, see the MIMIX Administrator
Reference book. (MXHA-535, MXHA-9133)
Support added for Windows network server user attributes

MIMIX added support for replicating and auditing the Windows network server user attributes
that are associated with replicated user profile objects (*USRPRF). These attributes can be set
with the Change Network Server User Attributes (CHGNWSUSRA) command. If the attributes
have been set, they can now be replicated and audited with their associated user profile.
To support auditing these attributes, the Compare Object Attributes (CMPOBJA) command and
the #OBJATR audit now support the value *NWSUSRA in the Attributes to compare (CMPATR)
and the Attributes to omit (OMITATR) parameters. If the attributes have been set, the #OBJATR
audit and the value *ALL for the command's CMPATR parameter will include them when
comparing user profile objects.
This support is implemented for all new installations or upgrades to service pack 7.0.13.00.
(MXHA-9151)
#DLOATR audit compares data and supports multiple audit

levels
MIMIX is changed so that the #DLOATR audit can now compare data as well as attributes for
objects of type *DOC and *STMF. Also, the #DLOATR audit now supports multiple audit levels.
When the #DLOATR audit runs at *LEVEL10, the audit only compares attributes. When run at
*LEVEL20 or *LEVEL30, a cyclic redundancy check (CRC) is also performed on data for *DOC
and *STMF objects. Previous releases were equivalent to *LEVEL10.
All new and upgraded installations of version 7.1 will run the #DLOATR audit at *LEVEL30, which
is best practice, unless the audit level policy is changed. Be aware that after installing version
7.1, the #DLOATR audit may take more time to complete, may affect performance, and may
initially result in more problems reported because data was not previously compared.
To support this functionality, the Compare DLO Attribute (CMPDLOA) command now supports
*DATACRC as a possible value for the Attributes to compare (CMPATR) and Attributes to omit
(OMITATR) parameters. When *DATACRC is specified for the CMPATR parameter, the
comparison performs a cyclic redundancy check (CRC) for object data for document (*DOC) and
stream file (*STMF) objects. The comparison reads all document and stream file data, which can
affect performance and take more time. (MXHA-9152)
Choice of system for determining database file network

relationships
You now have the ability to specify which of the systems in the data group to use for determining
database file network relationships when distributing files among database apply sessions. In
previous releases, the target system of the data group was always used.
The System for DB file relations (DBRSYS) parameter has been added to the Start Data Group
(STRDG) command and to the Start Data group dialog within the MIMIX portal application for
VSP. The DBRSYS parameter determines which system is used to determine file network
relationships. The specified system is used to assign data group file entries to apply sessions
when the start request specifies to clear pending entries (CLRPND(*YES)) in all apply sessions
(APYSSN(*ALL)). Valid values are:
• *TGT - The target system is used to determine the file relationships. This is the default and
preserves behavior of previous releases.
• *SRC - The source system is used to determine the file relationships.
(MXHA-9573)
LODDTARGE command changes

The Load Data Rsc. Grp. Ent. (LODDTARGE) command allows you to select the data groups to
load into a resource group for an application group. The LODDTARGE command is changed to
automatically create a unique resource group entry for all data groups. Data groups that have the
same name for their three-part name will be assigned to the same data resource group. The
name of each data resource group must be unique and will use the same name as its data
groups.
The following parameters have been removed from the command: Data group name space
(NAMESPC) and Data resource group entry (DTARSCGRP). (MXHA-9577)
MIMIX portal application performance improvements

Several changes to the MIMIX portal application improve performance of retrieving the displayed
information for an instance. This may be most noticeable for users who have added several
portlets to custom pages in My Folder.
Portlet data now loads faster when users select any of the following pages: Data Groups, Audits,
and Procedures. Also, users of custom pages may also see performance improvements.
Also, immediately after logging in and selecting an instance, users may see a message in
portlets indicating that the instance may still be connecting or retrieving information. This is
displayed while instance status is being retrieved. On a shipped page, this message will resolve
itself. However, on a custom page, users must refresh the browser to see the retrieved
information. (MXHA-9393, MXHA-9786)
DBAPY performance improved when processing C-RB

entries
The database apply (DBAPY) process changed the way in which it processes C-RB (rollback)
journal entries when data groups are configured for delayed commit mode processing.
Environments that use commitment control and perform many commit rollback operations will
see improved performance for the DBAPY process. Environments with a large number of apply
jobs for one or more data groups using the same journal will see the most improvement.
Performance may improve for the database reader (DBRDR) process as well.
Data groups configured for immediate commit mode processing handle C-RB entries differently
and are not affected by this change. Immediate commit mode processing is new for MIMIX
version 7.1 and is described in Immediate commit option for database apply. (MXHA-9651)
Changes when installing from SAVF

If you use 5250 emulator commands to install MIMIX instead of the MIMIX Installation Wizard, be
aware of the following:
• The Install MIMIX (INSMMX) tool available to download from Support Central has been
renamed to Install Vision Product (INSPRD).
• The downloadable INSPRD tool includes the Install Vision Product (INSPRD) command.
• The INSPRD command is a generically named copy of the Install MIMIX (INSMMX)
command in the LAKEVIEW library for License Manager.
The Install Vision Product (INSPRD) tool for License Manager simplifies the install process for
users who are installing from a streamfile (STMF). If you will be using 5250 emulator processes
to create a new installation of a Vision product on a system where License Manager is not yet
installed, you must download the INSPRD STMF from Support Central and transfer it to your
system. For new installations of MIMIX on systems where License Manager is already installed,
you can continue to use INSMMX command in places where the Using License Manager book
refers to INSPRD. (SDE-2400)
Portal Application Updates

The 2.1.01.00 Vision Solutions Portal will now update existing instances to reflect the updated
portal application's changes, additions, and deletions on pages and portlets.
Customers who have upgraded the product and portal application from a previous release or
service pack can now access the new functions in their existing instances. However, users may
lose their saved changes to portlet preferences for all portlets on all shipped (pinned) pages in
the instance. Preferences for portlets that have been placed on custom pages in My Folder are
not affected. Also, preferences for secondary windows are not affected.
If a portlet that you have on a custom page is deleted from a pinned page, you will see a
message on your custom page indicating that the portlet has been removed.
Vision Solutions Portal

Vision Solutions Portal version 2.1.01.00 includes the following highlights:
Supported product portal applications

Version 2 of Vision Solutions Portal supports portal applications for the following Vision Solutions
products:
• MIMIX® Availability™ 7.1 or 7.0 (MIMIX Professional, MIMIX Enterprise, MIMIX Global)
• iOptimize™ 7.1 or MIMIX® Director™ 8.1
• Double-Take® RecoverNow™ for AIX 4.0
The server platform on which VSP is installed may support a limited set of portal applications.
Also, earlier versions of portal applications may not be able to be installed on some platforms.
Enhanced Administrator support with administrator user ID log in

This release adds administrator-level support within Vision Solutions Portal. An administrator can
now use the administrator user ID to access the Administration page within the Home folder.
From this page, the administrator can access portlets which set up common functions, such as
email support, that the VSP server provides for one or more portal applications.
Administrator user ID
To access administrator functions on the Administration page requires logging in with the shipped
administrator user ID and password which are both: vspadmin. When you log in as administrator,
you can access only the portlets on the Administration page. No other pages in the Home folder
or in any product instance are accessible. You will be prompted to change the password for the
administrator user ID the first time you log in. Any time you need to, you can also change its
password using the Change Password portlet.
Email server support
From the Policies portlet on the Administration page, you can provide the details needed to
enable email support for portal applications. The portlet requires that you specify the SMTP email
server and port, the user ID to use if authentication is needed, and the sending user ID. This
information is used by any portal application that offers the ability to send email from a portlet.
When a user in a product instance selects an action that emails, the user provides the recipient's
address.
Changes to Instances and Portal Connections portlets

The following changes support using portal applications for products that run on platforms other
than IBM i.
Portal Connections
All portal connections now identify the platform of the node with which they connect. The platform
of the default portal connection is set to the platform on which the VSP server is running. Portal
connections created prior to version 2.0 are defaulted to IBM i.
The Platform field in the Add Portal Connection dialog identifies platforms for the available
deployed portal applications. When creating a new portal connection, select the platform for the
products that you intend to connect to with the portal connection. The Platform column in the
Portal Connections portlet identifies the platform of the node in each configured portal
connection. The Portal Connection Details dialog also displays the platform as well as any
configured instances which use the portal connection. A portal connection's Host or IP address
and Platform fields cannot be changed when the portal connection is used by an instance.
Instances
The Library column in the Instances portlet is renamed to Location. The column identifies the
location on the node where the product is installed.
When you add an instance, the Portal connection for discovery field in a product's instance
configuration wizard will display only configured portal connections that match the platform type
required by the portal application.
Support for installing VSP on Windows

In addition to running on AIX® and IBM i operating system platforms, Vision Solutions Portal
(VSP) can now be installed on a system running either a 64-bit or a 32-bit version of the following
Windows® operating systems:
• Windows Server® 2008 R2
• Windows® 7
This capability allows you to manage Vision Solutions products that run on different operating
systems from one common platform, saving you time and simplifying operations by having
standardized user interfaces.
The server platform on which VSP is installed may support a limited set of portal applications on
that platform. At this time, only MIMIX provides a portal application that can be installed on
Windows. However, the portal application supports connecting to product instances that are at
different versions.
Recommended browsers Internet Explorer 7 or above, Firefox 3.5 or above, and Safari iPad
(beta). Earlier versions are not supported.
Installing VSP on Windows If a product provides a portal application that can run on a Windows
platform, the portal application is installed by the Vision Solutions Portal (VSP) 2.0 & Portal
Application Installation Wizard for Windows®. When needed, the wizard automatically installs
version 2.0 of the VSP server with each of the following portal application install choices:
• Install the portal application

• Upgrade the portal application
• Re-install the portal application
This wizard does not install the product associated with the portal application. For additional
details about requirements for using this wizard, see the wizard's More Info document for
Windows.
The wizard also adds VSP to "All Programs" in the Windows Start menu. Options are available to
start or stop the VSP server, view Read Me files associated with each installed product portal
application, launch VSP in the default browser, and launch the VSP uninstall wizard.
Logging into VSP on a Windows platform When logging into a VSP server that is installed on
a Windows platform, you will be authenticated on the domain if one is specified. If you do not
specify a domain, VSP will attempt to authenticate the user ID on the local system first, then will
attempt to authenticate on your default domain depending on your network settings. The
administrator for the PC can add users and provide a local user ID that can be used to log into
VSP. When VSP runs on a Windows platform, a default portal connection is not created when
users log in. Users need to add a portal connection to a node in the network on which the product
they want to connect is installed.
Note: Domain\myuserid and myuserid are unique log ins. Any instances you create when
logged in with one ID are not visible when logged in with the other ID.
Commands for administering VSP on a Windows platform A set of commands are provided
that can be run from a command prompt to perform the following activities:
• Start and end the VSP server (strvsisvr, endvsisvr)
• Change the ports used by the VSP server (chgvsisvr)
• Retrieve status of the VSP server (rtvvsisvr)
• Manually add the VSP server service to Windows (vsiservice). This is normally done by the
installation wizard.
• Manually make a portal application available to VSP (addvsiapp). This is also normally done
by the installation wizard.
• Removing a portal application from the VSP server (rmvvsiapp)
This command set uses the same names on Windows as those available on other operating
system platforms where VSP can be installed. This is to provide parallel functions. For
information about using these commands, see the Getting Started with Vision Solutions Portal
book.
Action required
To install VSP on a system running a supported version of Windows, you must use the Vision
Solutions Portal (VSP) 2.0 & Portal Application Installation Wizard for Windows® that is available
for the product. Use this wizard after you have installed or upgraded the product on its operating
system platform.
After VSP and the portal application is installed on Windows, start the VSP server according to
the instructions in this readme.
Users need to add a portal connection to a node in the network on which the product they want to
connect is installed. (STR-1938)
VSP 2.0.00.06 added options to Windows Start menu

The Vision Solutions Portal (VSP) 2.0 & Portal Application Installation Wizard for Windows® now
adds Vision Solutions Portal to "All Programs" in the Windows Start menu. Options are available
to start or stop the VSP server, view Read Me files associated with each installed product portal
application, and launch VSP in the default browser. (STR-2396)
Additional instance status values in Enterprise Status portlet

The following new icons representing overall instance status can be displayed in the navigation
area for an instance as well as in the Enterprise Status portlet:
Message waiting. A message requires a user response.
Switching stopped. The flow of replication data is in the process of changing direction.
However, a switching procedure stopped or other critical errors occurred during the switch that
require user action.
Held. An item is held and requires user intervention to release it.
Undo in progress. A task is being performed that affects the entire instance and cannot be
interrupted while in progress.
Instances for more than one Vision Solutions product can be displayed in this portlet. Each
product determines which status values it will use in this portlet. Some of these status values
may not be used by every product. (STR-2393)

MIMIX
MXHA-3685 SYNCDGFE now uses a data group name on the SYNCOBJ command to
synchronize authorities after synchronizing the file.
MXHA-7846 The journal name for a new journal definition is now set correctly when using the
CPYJRNDFN command.
MXHA-9095 The SYNCDGFE command default for Allow object differences (ALWOBJDIF)
parameter is now *ALL.
MXHA-10299 The counts included in message LVI3354 now correctly represent actions taken
by the Deploy Data Group Configuration (DPYDGCFG) command.
MXHA-10338 MXIFCMGR now handles error MCH3402 when the data group definition is
deleted while in use.
MIMIX Portal Application
MXHA-8624 Menu button for actions is now disabled when there are no actions available for a
row in a portlet or window.
MXHA-9122 Status icons have been changed to provide consistency between portlets and to
enhance product status information.
MXHA-9140 The Audit Details portlet now shows the correct date and time when a data group
is re-enabled.
MXHA-9292 The Nodes portlet will show the configured nodes for a MIMIX instance even if
collector services is not active.
MXHA-9316 Audited Objects and Data Group Audited Objects windows now correctly show
object compare status values as CO (LOB), EQ (DATE), or EQ (OMIT).
MXHA-9811 Accurate information is now displayed in VSP when reconnecting to a MIMIX
instance.

Mimix PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Mimix PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Read This First

Version 7.1 Service Pack 7.1.03.00

7.1.01.00 - Highlights and fixes

Objects and IFS directories to exclude from replication.

Before installing VSP 2.0 & Portal Application on Windows

Installing VSP 2.0 & Portal Application on Windows

Shut down products

Starting VSP 2.0 & Portal Application on Windows

New function or an enhancement in the indicated software.

Validation list entry (*VLDL) updates are now correctly rep-

Fixes included in service pack 7.1.03.00

Vision Solutions Portal 2.0.03.00

New function or an enhancement in the indicated software.

Updates for Data Group Details and Activities Portlet

Fixes included in service pack 7.1.02.00

New function or an enhancement in the indicated software.

Immediate commit option for database apply

Data groups use shared object send process

Arrivals and Backlog portlet

Default naming convention changed for remote journaling

Clarified time of next attempt for entries in delay/retry

Changes to Work with Systems (WRKSYS)

parameter are *YES and *NO.

Policies for prioritized object auditing

The policy values are:

Changes to displayed auditing information

Prioritized audit results in Replicated Objects portlet

Changing audit scheduling policies for multiple audits

Changes to support enhanced environment analysis fea-

MXCFGJRN journal definitions and journal environments

Deploy Data Group Configuration (DPYDGCFG) command

Starting replication the first time after installing or upgrading

Improved performance for clear pending starts

Improved start time for disabled data groups

Target journal inspection

Automatic correction of errors found by target journal inspection

Changes to support inspection status

Changes that support starting and ending inspection processes

Related changes to MIMIX portlets

Related changes to commands and displays

(INSPTIME) of the last entry processed by journal inspection.

Audits and Recoveries portlet renamed

Message Log support in MIMIX portal application

• Step Status portlet

Policy Summary window added

ENDDG performance improved when activity entries are in

An ENDDG request now does the following:

Journal at creation changes due to QDFTJRN retirement

Improved performance for DBRDR and DBSND

Improved display of member errors in File Activity Details

Replicated Objects portlet

Improved performance when starting and ending data

Duration added to Audit Details, Audit History portlets

Improved compare of *DTACRC attributes by #OBJATR

Audit History default changes

Status icon changes within MIMIX portal application

Data Group Details and Activities portlet

New held recovery status for audits

Status icons for MIMIX portal application

Recovery held None Audits portlet

Held Recoveries, in recovery-specific locations

Switching Actual audit In Audit and Compliance columns in Data Groups

Compare active File activity

parameter are YES and NO.