Read This First. Version 7.1 Service Pack

Transcription

1 Read This First Version 7.1 Service Pack Prerequisites: If you are upgrading to MIMIX version 7.1, a MIMIX version 7.0 service pack ( or higher) must be installed first. Note: If you are installing from an OMS/ODS product, this prerequisite does not apply. MIMIX version includes all relevant changes to version 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 9 - 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:.behavior Change Data Group Details and Activities portlet To see a list of fixes included with this service pack, see Fixes included in service pack on page 10. 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 Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 1

2 Superseded 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 To see highlights and additional fixes for a superseded service pack, click on the link Highlights and fixes Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 2

3 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 Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 3

4 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 , 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) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 4

5 Installation Instructions 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 Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 5

6 Installation Instructions 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 , 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.) \ Change definition for preexisting data groups to use shared object send process..11 Update automation that uses MXSYSDFN outfile if needed Change policies to allow priority auditing Perform a controlled end and change data group to use immediate commit mode..10 Run DPYDGCFG for data groups before starting replication processes Change journal definitions for systems on which target inspection will run Evaluate programs for use of journal entry time stamp Change FEOPT parameter for lock member during apply Optionally install VSP on a Windows system 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) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 6

7 Installation Instructions 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. Start the server using the command: VSI001LIB/STRVSISVR The default port is 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 to access the Log In page: where: server is the IP address or host name where Vision Solutions Portal is installed port is the port number (the default is 8410) d. Log in using your IBM i userid and password. After you have logged in, the portal opens to the Home page. e. A default portal connection exists for the node on which you logged in. When you log into the Vision Solutions Portal, follow the instructions in the Welcome portlet on the Home page to add a product instance. When the instance is added, you will see the instance name and status appear in the navigation area. For more information, see the Getting Started with Vision Solutions Portal book. 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 Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 7

8 After installing the service pack instructions the instructions in Installing VSP 2.0 & Portal Application on Windows on page Copyright 1999, 2012 Lakeview Technology Inc. All rights reserved. 8

9 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 not automatically started on a Windows platform when default choices in the installation wizard are used. Start the VSP server by one of the following: Use the Start VSP Server button in the wizard. Manually start the VSP server using the instructions in the Getting Started with Vision Solutions Portal book Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 9

10 Highlights Version 7 Service Pack 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. 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) Fixes included in service pack Changes included in service pack fix the following reported problems: MIMIX MXHA-10560Priority based #IFSATR audit now correctly chooses objects to compare on the remote side. Vision Solutions Portal 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 Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 10

11 Highlights Version 7 Service Pack 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. 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 11

12 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: (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 12

13 *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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 13

14 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 14

15 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 15

16 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 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) (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 16

17 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 17

18 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 18

19 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 19

20 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) Start after, Start until (5250) 3 a.m to 8 a.m. Any time (*ANY), *NONE Specifies a time range, in 24-hour format during which prioritized audits are allowed to start. Deselecting 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 differences Monthly Daily, Weekly, None An object with no differences is 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 20

21 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 21

22 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 22

23 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) (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 23

24 Changes to support enhanced environment analysis features 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 24

25 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 25

26 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 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 26

27 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 17. 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 systemlevel 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 27

28 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 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 17. 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 28

29 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 29

30 (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 17. 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 17. (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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 30

31 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 instancelevel 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 31

32 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 recreate 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 32

33 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 (Included with ) Copyright 1999, 2012 Vision Solutions, Inc. All rights reserved. 33