Version 7.1 Service Pack 7.1.02.00Prerequisites: 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.02.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 9 - instructions for using the Vision Solutions Portal (VSP) 2.0 & Portal Application Installation Wizard for Windows®.
Important changesYou should be aware of the information in the following topics before you install this service pack:
To see a list of fixes included with this service pack, see “Fixes included in service pack 7.1.02.00” 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.
SupersededThis service pack includes the contents of the following superseded service packs. If you do not already have the following service packs installed, their contents are also installed when you install service pack 7.1.02.00. To see highlights and additional fixes for a superseded service pack, click on the link.
Before installing the service packThe 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:
• 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.
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
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.02.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:
Installing the service pack on IBM Power SystemsMIMIX 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 instructionsThe 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.02.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.)
\
7.1.01.00Change definition for preexisting data groups to use shared object send process . .11Update automation that uses MXSYSDFN outfile if needed . . . . . . . . . . . . . . . . . . .15Change policies to allow priority auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17Perform a controlled end and change data group to use immediate commit mode. .10Run DPYDGCFG for data groups before starting replication processes . . . . . . . . . .24Change journal definitions for systems on which target inspection will run . . . . . . . .24Evaluate programs for use of journal entry time stamp . . . . . . . . . . . . . . . . . . . . . . .31Change FEOPT parameter for lock member during apply. . . . . . . . . . . . . . . . . . . . .33Optionally install VSP on a Windows system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
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:
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. Start the server using the 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 to access the Log In page: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)
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
Installing VSP 2.0 & Portal Application on WindowsThese 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 WindowsBefore 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 WindowsVision 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 WindowsThe 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.
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 7.1.02.00Changes included in service pack 7.1.02.00 fix the following reported problems:
MIMIX
MXHA-10560Priority based #IFSATR audit now correctly chooses objects to compare on the remote side.
Vision Solutions Portal 2.0.02.00
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.
Highlights Version 7 Service Pack 7.1.01.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.
Immediate commit option for database applyEnvironments 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.
• 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 processThe 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 portletThe 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/retryWhen 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
– 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 auditingVersion 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.
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. 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 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.
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 33.
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 auditsThrough 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 inspectionVersion 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.
– 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 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 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 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.
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 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 renamedThe 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 applicationYou 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:
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 addedThe 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.
• 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 retirementJournal 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 DBSNDThe 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 portletThe 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 portletsThe 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.
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 changesAudit 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 applicationSome 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)
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 represented
Instance status in navigation area
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 status.
Actual compliance status.
In Audit and Compliance columns in Data Groups portlet.
DPYDGCFG command no longer failsThe 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 EnvironmentsSupport 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 attributesMIMIX 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 changesThe 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 improvementsSeveral 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 SAVFIf 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 UpdatesThe 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 PortalVision 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:
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:
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)
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)
Fixes included in service pack 7.1.01.00Changes included in service pack 7.1.01.00 fix the following reported problems:
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-10299The counts included in message LVI3354 now correctly represent actions taken by the Deploy Data Group Configuration (DPYDGCFG) command.
MXHA-10338MXIFCMGR 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.
![Getting Started with SAM V71 Microcontrollersww1.microchip.com/...32-bit-Cortex-M7-Microcontroller-Getting-Start… · Getting Started with SAM V71 Microcontrollers [APPLICATION NOTE]](https://static.documents.pub/doc/80x56/5f2bb60600b6e45f4a4a25ab/getting-started-with-sam-v71-getting-started-with-sam-v71-microcontrollers-application.jpg)
