version 6.2 service pack 6.2.03 - vision...

Read This First

Version 6.2 Service Pack 6.2.03.00iTERA version 6.2.03.00 includes all relevant changes to earlier level 6.2 service packs, 6.1.23.00, and earlier levels of version 6.1.

Prerequisites:

• The minimum level required for the IBM i operating system is IBM i 6.1.

• Upgrades to iTERA version 6.2 require version 6.2 license keys and are supported from any iTERA version 6.1 service pack (6.1.01.00 or higher).

• The minimum level required for License Manager is 7.0.22.00. The installation wizard will automatically update License Manager to the required level.

• Review the “System Requirements” section and ensure that your systems meet all requirements.

Supported installation processesThis document supports installing or upgrading the product using the iTERA Installation wizard. The wizard is recommended and supports standard and custom install options. If you cannot use the iTERA Installation Wizard, the Using License Manager book includes the secondary install procedures and supporting information for installing via the 5250 emulator.

To see requirements for using the wizard, click the More Info link from the wizard’s Welcome panel.

Action requiredThe following topics provide instructions associated with installing the product. Any changes which may require you to take additional action are listed in the following sections with links to additional descriptions.

“Before installing the service pack” on page 3

“After installing” on page 4

Important changesYou should be aware of the following information before you install this service pack. Also check the Before Installing and After Installing sections for potential configuration changes.Enhancements

Improved resiliency and logging for iTERA Alert processing. . . . . . . . . . . . . . . . . . . . 5

To see a list of fixes included with this service pack, see “Fixes included in service pack 6.2.03.00” on page 5.

iTERA and Vision AutoValidate are trademarks of Vision Solutions, Inc. AIX, AS/400, DB2, eServer, i5/OS, IBM, iSeries, OS/400, Power, PowerHA System i, and WebSphere are trademarks of International Business Machines Corporation. All other trademarks are the property of their respective owners.

6.2.03.00 © Copyright 1999, 2016 Vision Solutions, Inc. All rights reserved. 1

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

Accelerator Job fields removed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Disabled Role Swap Readiness Monitor tests will now display in WRN status . . . . 31New default values for audit history retention parameters in SETPCY command . . 32Role Swap Readiness Monitor DEFN test now checks audit configuration . . . . . . . 31

Enhancements#FILATR audit now audits attribute Long SQL Name . . . . . . . . . . . . . . . . . . . . . . . . 28Automatic recovery for journaling discrepancies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Constraint and database relations discrepancies now automatically corrected . . . . 31IFSASSIGN test added to Role Swap Readiness Monitor . . . . . . . . . . . . . . . . . . . . 30Improved handling for large IFS objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Improved Journal Manager Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Improved performance of initial replication of user profiles . . . . . . . . . . . . . . . . . . . . 31Improved resiliency and logging for iTERA Alert processing. . . . . . . . . . . . . . . . . . . . 5Internal iTERA product files now journaled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33iTERA Installation Wizard now supports Windows® 8.1 and Windows® 10. . . . . . . 32Minimum supported OS level is now V6R1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32MQ replication journal now automatically created . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Multiple enhancements to Work with Libraries (4.11) . . . . . . . . . . . . . . . . . . . . . . . . 18New #FILDTA change date (CHGDATE) policy value for #FILDTA audit . . . . . . . . . 27New ITREQLIC command available. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7New options to display logical and physical files added to 4.11 . . . . . . . . . . . . . . . . 20New options to not start apply processes and jobs after role swap. . . . . . . . . . . . . . 22New screen views in IFS Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28PWDLVL and JOBD tests added to 30.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Support for environments running IBM i 7.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32System Monitor history data can now be saved using command E2SYSDTA . . . . . 11Troubleshooting information for audit attributes added to Reference Guide. . . . . . . 25Work with Locked Objects (4.22) screen now includes EXCLRD . . . . . . . . . . . . . . . 25

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 6.2.03.00. To see highlights and additional fixes for a superseded service pack, click on the link.

6.2.02.00 - Highlights and fixes

6.2.01.00 - Highlights and fixes


Installation Instructions

Installation and upgrade proceduresSupport Central provides an executable (.exe) file for the product download, which contains the iTERA Installation Wizard as well as the actual product update.

iTERA Installation Wizard recommended: Vision Solutions strongly recommends that you use the iTERA Installation Wizard to install version 6.2. The wizard provides a simple method for downloading, distributing, and installing the product on a single IBM Power™ System or on multiple Power Systems simultaneously.

In addition, the iTERA Installation Wizard easily and automatically obtains and applies license keys via Vision AutoValidate™.

This document includes instructions for installing service pack updates using the wizard. If you cannot use the iTERA Installation Wizard, the Using License Manager book provides instructions for iTERA operators who must use the installation and license key support provided by License Manager.

• If you are performing an upgrade from v6.1 to v6.2, use the iTERA Availability v6.2 Upgrade Guide. It contains instructions for performing a v6.1 to v6.2 upgrade using either the wizard or 5250 emulator.

• New product installations are performed by our Professional Services team and Certified Business Partners using documentation prepared for that purpose.

Before installing the service packIf you have other Vision Solutions products that are managed by License Manager on the same systems as iTERA, you will also need to shut them down at the same time.

1. Ensure your systems meet the required settings for correct iTERA operation. Review the “System Requirements” section and ensure your systems are in compliance.

It is strongly recommended that you apply the latest IBM PTFs associated with IBM i releases as they pertain to your environment. For details, see “Checking systems for recommended IBM PTFs” on page 38.

2. Go to the Vision Solutions Support Central site and log in with your user name and password.

3. Select CustomerCare > iTERA > Downloads. Verify that 6.2 is displayed in the Version drop-down box.

4. Click the file 6.2.03.00: Wizard on IBM i and save the file to your PC.

5. If required, perform the following actions, before installing, that are necessary for your environment. The actions are listed below by service pack. It is necessary to perform any special instructions provided for 6.2.03.00, as well as the following actions for service packs that are not yet installed. (You can skip actions for service packs already installed on your systems.)

6.2.01.00If running IBM i 7.3, IBM PTFs may need to be installed on your systems . . . . . . . .32

Install iTERA Service Pack1. Launch the iTERA Installation Wizard by clicking the executable (.exe) file that you downloaded in

Step 4 above.

Note: You must end all jobs associated with your iTERA installation on all nodes. The installation


http://www.visionsolutions.com/services-support/support/contact-customercare

wizard will not perform this task. When the wizard instructs you to end iTERA, perform Step 1a through Step 1c. The wizard verifies that the installation is shut down and will not allow you to continue if there are active product jobs or locks.

If you have multiple installations of iTERA, the first installation updated will update License Manager. Because of this, you should end iTERA on all installations before installing.

a. End the iTERA subsystems on all nodes. Use the command E2ENDSBS on any node.

b. Check for object locks. Use the command WRKOBJLCK QSYS/installation-library *LIB

c. If running iOptimize on any system in your iTERA installation, end iOptimize:installation-library/ENDID *ALL

Follow the on-screen instructions in the wizard, taking note of the following:

• On the Installation Options panel, select “Upgrade an existing installation”.

• On the Node Login screen, enter the primary node’s IP address or system name in the “Node” field and a *QSECOFR-equivalent profile with *ALLOBJ and *SECADM authority and its password in the “User Profile” and “Password” fields. (The iTERA Admin profile cannot be used.) After advancing to the next screen, the other nodes in the environment are displayed in the wizard panel. Log in to the additional nodes with the *QSECOFR-equivalent profile.

2. Advance through the wizard’s screens, following all on-screen instructions carefully. When finished, close the wizard.

After installingPerform these steps after successfully installing the service pack fix on all systems.

1. Log on to all nodes using the iTERA admin profile.

2. Use the following command on any node to start the iTERA subsystems on all nodes:

E2STRSBS

3. Update the System Monitor on the primary node (1.1, F10=Update Monitor) and verify that all values fall within acceptable ranges (refer to the System Monitor (1.1) chapter of the iTERA Availability Reference Guide). If there are issues, execute the steps on the Monitoring Checklist, located in the iTERA Availability User Guide, to troubleshoot and resolve.

4. If running iOptimize on any system in your iTERA installation, use the following command on each system to restart iOptimize:

installation-library/STRID *ALL

After installing, perform any of the following actions that are necessary for your environment. The instructions are listed by service pack. It is necessary to perform any special instructions provided for 6.2.03.00, as well as the following actions for service packs that were not installed when you started this process. (You can skip special instructions for service packs previously installed on your system.)

6.2.01.00Download updated user documentation from Support Central . . . . . . . . . . . . . . . . .25


Highlights Version 6.2 Service Pack 6.2.03.00

These icons indicate:

A change that may require action. For example, you may need to modify automation programs or exit programs or perform other actions before or after installing the service pack.

A change in behavior or a change to the user interface. You should be aware of the change, but no action may be required.

New function or an enhancement in the indicated software.

Improved resiliency and logging for iTERA Alert processing

Improved resiliency and logging if communications or I/O failures occur during iTERA Alert processing.

Jobs E2A_EMAILJ and E2A_RECVJ are new and replace job QJVACMDSRV.

(ITHA-13263)

Fixes included in service pack 6.2.03.00

ITHA-12184 Improved handling of heal entries associated with renamed file members. RSRMON will no longer report outstanding or unprocessed heal entries due to file member renaming.

ITHA-13286 Data area and data queue objects created in a journal-at-birth library will now be replicated to target systems via apply job journal entry replay. SQL Sequence data area replication will still be performed by object sync request (OSR) entries.

ITHA-13450 #FILATR will no longer generate an excessive number of T-GR journal entries in QAUDJRN on systems running OS 7.2 and higher.

ITHA-13451 Authority failure messages are no longer reported by the transport apply job if they can be subsequently resolved in the data apply job.

ITHA-13460 System Value Replication (5.8) Changed the method of replication for time-sensitive system values.

ITHA-13461 The QGPL library will now be included in the iTERA jobs library list even if originating in the system portion of the library list.

ITHA-13471 IFSREP job will no longer go into MSGW when IFS replication is ended for an IFS object that has not previously been accessed.

ITHA-13488 Object Audit Level Definitions (4.62) - Initial library syncs can now be delayed.

ITHA-13501 Outq and Spool File Replication (5.3) Backup. After pressing F4 and returning the 'Backup Entries' values will now remain on the screen.


ITHA-13537 Command MRRDWNGRP will now be successfully replicated to target systems if defined as a job scheduled entry. It will no longer fail with message HAP0158.

ITHA-13559 Work with Triggers (4.23) - Improved support for short quoted trigger names.

ITHA-13563 Work with Libraries (4.11) 6=Select for Tape now works in environments with multiple target nodes defined. The option can be used successfully on additional target nodes after replication to the first node has completed.

ITHA-13576 The Receiver Chain Warning value in System Monitor Alert Limits (E2MONTHR) now permits a value of 9999 (unlimited). When this value is specified, receiver chain warnings will no longer be issued for the E2MONTHR test in the Role Swap Readiness Monitor.

ITHA-13586 Improved resiliency of #FILDTA audit when dealing with journals that are in use or locked.

ITHA-13594 #FILDTA audit will now correctly report a file as *NE (not equal) when file has exceeded the deleted record threshold and one file has more trailing records than the other file.

ITHA-13608 A message is now sent to E2MSGLOG when the subsystem has ended.

ITHA-13612 Adding a new node (30.21, F6) now works properly even if the cluster name is not blank.







ITREQLIC command available for requesting, retrieving, and applying product license keys

The ITREQLIC command provides a simple, automated method for requesting, retrieving, and applying iTERA license keys.

This command can be used when any of the following conditions occur:

• When a System i serial number, model number, or processor feature code has changed.

• When existing license keys will expire soon or have expired and new keys are required.

The command includes two standard parameters, Retrieve license information and Apply license key, plus an additional parameter, Display Java output.

The ITREQLIC command initiates (opens) an outbound connection to a Vision Solutions server that is listening on port 80 and then returns the LKP via this same port. This port is required in order to use the ITREQLIC command. If the port is closed or restricted by a firewall, then the manual license key request and retrieval procedures, documented in the iTERA Installation Guide, iTERA Upgrade Guide, and Using License Manager Book, must be used instead.

Run the command on each system in the replication environment for which updated keys are required.

Appropriate messages indicate the success or failure of each process and the reason.

• The command may be run with both the Retrieve license information and Apply license key parameters set to *YES, in which instance, the retrieval process will be initiated and completed first, followed by the application of the key.

• To retrieve the license key but not apply it, set Retrieve license information to *YES and Apply license key to *NO.

• To apply a previously retrieved key, set Retrieve license information to *NO and Apply license key to *YES.

6.2.01.00 (Included with 6.2.03.00) © Copyright 1999, 2016 Vision Solutions, Inc. All rights reserved. 7

• Retrieve license information - When set to *YES, system information is retrieved, including serial number and processor group. The information is packaged into a License Request Package (LRP) and sent to the Vision Solutions server. If the requesting system is properly enrolled and entitled, then a license key package (LKP) is generated and sent to the requesting system. The LKP is then placed in /VISIONSOLUTIONS/LICENSEKEYS/IT_VISIONSOLUTIONS.LKP.

• Apply license key - When set to *YES, the license key found in /VISIONSOLUTIONS/LICENSEKEYS/IT_VISIONSOLUTIONS.LKP is applied on the system. When set to *NO, the key is not applied on the system.

• Display Java output - For debugging purposes, the Java output (using Java’s Verbose option) used to retrieve the license keys, can be displayed.

(ITHA-12303)

PWDLVL and JOBD tests added to Communication Test (30.7)

New tests, PWDLVL and JOBD, have been added to the Communication Test (30.7).

• The PWDLVL test verifies the password level is consistent between nodes.

• The JOBD test verifies that the libraries in the E2JOBD exist on the system. DDM will not work unless all libraries in the job description exist on all systems in the environment.

(ITHA-12481)

Accelerator Job fields removed from Apply Job Maintenance

The Accelerator Job field (and associated fields) have been removed from the Apply Job Maintenance screen (3.4, option 2). The apply accelerator technology was previously incorporated into the apply process, so the fields are now obsolete.

(ITHA-12627)

Request License Key (ITREQLIC) Type choices, press Enter. Retrieve license information . . *YES *YES, *NO Apply license key . . . . . . . *YES *YES, *NO Additional Parameters Display Java output . . . . . . *NO *NO, YES VERBOSE Bottom F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel F13=How to use this display F24=More keys



ITHA-11178 Improved handling and auto recovery of trigger differences detected by #FILATR audit.

ITHA-12457 A non-filtered object in a user journal that is renamed to a filtered object will no longer appear in the Mirrored Object Maintenance screen (4.21) and will no longer be processed by the audits.

ITHA-12641 Improved recovery of constraint discrepancies identified by the #FILATR audit that are caused by partial mirroring of related files due to object filters.

ITHA-12694 Improved handling of *SQLPKG objects when they are recreated on the source system using the REPLACE(*YES) option.

ITHA-13047 Audit jobs now use a LANGID value specified in the MIMIXOWN user profile so that audits will compare correctly.

ITHA-13260 User Profile Replication Errors (5.8) - Failed commands now display even if they contain non-displayable characters

ITHA-13268 IFSREP job will no longer fail if an IFS object included as part of a tape sync is deleted before the tape is restored.

ITHA-13308 Apply jobs that were not active at the time a failover was initiated can now be started.

ITHA-13320 Improved file authority auditing and recovery to repair primary group differences.

ITHA-13322 Improved Work with Triggers (4.23) to better manage *MULTI event triggers.

ITHA-13327 IFS Replication (5.2) no longer issues CPF501B - Operation sequence for member E2IFSREP not valid. (C I) when using Status Search field and pressing F7 multiple times.

ITHA-13332 E2MSGLOG routing (F8) will no longer create a message routing entry if no changes were selected.

ITHA-13341 IFS Replication (5.2) will no longer include *SOCKET objects in the internal iTERA files.

ITHA-13342 Multi System Monitor (1.11) option 7=E2MSGLOG now functions properly.

ITHA-13364 IFS replication (5.2) Tape sync to a lower OS level is now supported.

ITHA-13371 Restored job logging level to match iTERA 6.1.

ITHA-13381 Outq and Spool File Replication (5.3) - option 38 is obsolete and has been removed.

ITHA-13383 IFS Replication job (IFSREP) will no longer start journaling the root '/' directory due to a rare condition during the restore of an IFS directory.


ITHA-13391 Replication Options (30.23) 4=Disable Global and 6=Enable Global no longer require ending and restarting the iTERA subsystem.

ITHA-13396 Partial receivers will no longer be created by JRNMGT when the System Monitor is updated on heavily used systems where millions of objects are journaled to the same journal.

ITHA-13410 Work with Triggers (4.23) will now identify which trigger has a quoted name during an initial sync

ITHA-13423 Improved DDM resiliency when attempting to send commands to remote systems.







System Monitor history data can now be exported using command E2SYSDTA

Data Capture

Information from the System Monitor (1.1) can now be extracted and exported to an external file in order to provide system statistical information that can be used to analyze system load over select periods of time, system performance, and to assist users in configuring audit run times during low system usage.

Data will be automatically captured by iTERA whenever the System Monitor is updated. This occurs every 15 minutes (default) or when manually updated (1.1, F10=Update). The update interval can be changed for the System Monitor Interval parameter in the Job Management Control screen (2.21, F8).

Data capture can be disabled by setting the parameter SYSDTA to N (No) in the Parameter Update screen (10.50).

Data in the internal history file is retained for 60 days and then purged. The Retention Days parameter can be changed in the File Retention screen (10.51). Locate System History in the Description field, use option 2=Change, specify the desired value in the Retention Days parameter, and press Enter.

E2SYSDTA

A new command, E2SYSDTA, extracts the data from the data capture information. Each data set can include data from one or more systems for a specified time period or by specifying the transactions to include.

The data selection can be viewed on the screen (Output = *), exported to an iSeries output file (Output = *OUTFILE) or exported to a delimited (.csv) file (Output = *EXPORT), which is stored in IFS directory /VISIONSOLUTIONS/ITERA/installName/E2SYSDTA. Data that is exported to an outfile or IFS file is not automatically purged.

The history data is synchronized to all nodes so the E2SYSDTA command can run on any node.


Output = *OUTFILE

Output = *EXPORT

F10=Additional parameters

(ITHA-11682)

Improved Journal Manager IntegrationJournal Manager integration in iTERA includes new options and fields for managing receivers, improved Role Swap Readiness Monitor reporting, and improved messaging and error handling.

New options, fields, and function key on Journal Manager screen (3.32)

The Journal Manager screen includes several new options, columns, and a new function key, as well as enhancements to existing options. Some options and fields, as indicated below, appear on the target node only.

iTERA System Data (E2SYSDTA) Type choices, press Enter. Title . . . . . . . . . . . . . 'iTERA System data for: 01/04/2016' TITLE Type of information . . . . . . *SYSMON *SYSMON TYPE System name . . . . . . . . . . *ALL F4 for list, *ALL SYS Output . . . . . . . . . . . . . * *, *EXPORT, *OUTFILE OUTPUT Time period for report: PERIOD Starting date . . . . . . . . *CURRENT Date, *CURRENT, *PRV Starting time . . . . . . . . *START Time, *START

Ending date . . . . . . . . . *CURRENT Date, *CURRENT, *PRV Ending time . . . . . . . . . *END Time, *END

Bottom F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel F13=How to use this display F24=More keys

File to receive output . . . . . *DATE Name, *DATE OUTFILE Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB Output member options: OUTMBR Member to receive output . . . *FIRST Name, *FIRST Replace or add records . . . . *REPLACE *REPLACE, *ADD

File to receive output . . . . . *DATE Name, *DATE EXPORT Directory . . . . . . . . . . /VISIONSOLUTIONS/ITERA/{installName}/E2SYSDTA Export file options: EXPOPT Replace or add records . . . . *REPLACE *REPLACE, *ADD Add column names . . . . . . . *NONE *NONE, *SQL, *SYS

Transactions to include . . . . *AUTO *AUTO, *ALL, *MANUAL TRANS


Primary view:

Backup view:

3.32 New options

The new options in the Journal Manager screen include the following:

• 9=Cleanup Receivers - Executes the Journal Manager job (JRNMGT) on only the selected journals to remove receivers that have exceeded the retention time specified in the Journal Control Parameters. The JRNMGT job will continue to run for all receivers at its specified interval (default 30 minutes).

SYSTEM1 PRIMARY iTERA Availability 6.2 XPRCV293 HAA1ADMIN Journal Manager 2/10/16 QPADEV0004 Managed Journals 14:42:12 Type Options, Press Enter. 2=Change 4=Remove 5=WRKJRNA 7=Display Journal 8=Display Receiver Status 9=Clean Up Receivers 11=View Status Position Mng RcvChg JrnRcv Sav Total Old Partial Opt Library Journal Rcv FrqMin RtnHrs Req Rcv Rcv Rcv HALA1C QCMTJRN Yes 120 8 No 5 ITHAA1JRN E2CFGJRN Yes 120 8 No 3 ITHAA1JRN A1C03A Yes 120 8 No 5 ITHAA1JRN A1IJRA Yes 120 8 No 5 ITHAA1JRN A1IJRB Yes 120 8 No 5 ITHAA1JRN A1IJRC Yes 120 8 No 5 ITHAA1JRN A1JRNA Yes 120 8 No 5 ITHAA1JRN A1JRNB Yes 120 8 No 5 ITHAA1JRN A1JRNC Yes 120 8 No 5 ITHAA1JRN A1JRND Yes 120 8 No 5 ITHAA1JRN A1JRNE Yes 120 8 No 5 More... F3=Exit F5=Refresh F8=Add Journal F9=JRM Defaults F10=Rebuild Stats F11=Previous

SYSTEM2 BACKUP 1 iTERA Availability 6.2 XPRCV293HAA1ADMIN Journal Manager 2/10/16QPADEV0004 Managed Journals 15:09:49Type Options, Press Enter. 2=Change 4=Remove 5=WRKJRNA 7=Display Journal 8=Display Receiver Status 9=Clean Up Receivers 11=View Status 12=View Sync Dependencies Position Mng RcvChg JrnRcv Sav Total Old Partial Sync SyncOpt Library Journal Rcv FrqMin RtnHrs Req Rcv Rcv Rcv Rcv Dep HALA1C QCMTJRN Yes 120 8 No 5 ITHAA1JRN E2CFGJRN Yes 120 8 No 6 ITHAA1JRN A1C01A Yes 120 8 No 6 ITHAA1JRN A1IJRA Yes 120 8 No 6 ITHAA1JRN A1IJRB Yes 120 8 No 6 ITHAA1JRN A1IJRC Yes 120 8 No 6 ITHAA1JRN A1JRNA Yes 120 8 No 5 ITHAA1JRN A1JRNB Yes 120 8 No 5 ITHAA1JRN A1JRNC Yes 120 8 No 5 ITHAA1JRN A1JRND Yes 120 8 No 5 ITHAA1JRN A1JRNE Yes 120 8 No 5 More...F3=Exit F5=Refresh F8=Add Journal F9=JRM Defaults F10=Rebuild StatsF11=Previous


• 11=View Status - Displays current journal status information, including the number of receivers, number of journal entries, and the size of the receivers for each of the receiver categories.

• 12=View Sync Dependencies - Available on the target node only; displays the list of files for which processing has not completed.

3.32 New Columns

The new functions on the Journal Manger screen include the following:

• Total Rcv - Indicates the total number of receivers associated with the journal.

• Old Rcv - Indicates the number of receivers that are older than the retention hours set for the journal that have not been deleted.

• Partial Rcv - Indicates the number of all partial receivers (whether old or not).

• Sync Rcv - On target node only; displays the number of receivers where at least one sync dependent file is linked to a receiver. When a file is initially synced and activity occurs during the save/restore process, then the activity causes a sync dependency to occur. The first receiver of the activity is protected from being deleted until the activity has been applied to the target system.

SYSTEM1 PRIMARY iTERA Availability 6.2 XPRCV293HAA1ADMIN Journal Processing Statistics 2/10/16QPADEV0004 Library/Journal . . ITHAA1JRN/A1JRNA 15:36:08

Last Processing Time . . 2016-02-10-15.10.06.096000 Journal Size Sync Receivers Entries (MB) DepTotal . . . . . . . . . . 6 147 2 Old All . . . . . . . .Not Saved . . . . . . . . 6 147 2 Old Not Saved . . . . .In Use . . . . . . . . . . 2 31 1 Old In Use . . . . . . .Partial . . . . . . . . . Old Partial . . . . . .

F3=Exit F12=Cancel

SYSTEM2 iTERA Availability 6.2 XPRCV295 HAA1ADMIN Journal Manager 2/10/16 QPADEV0008 Sync Dependencies 17:51:01 Library/Journal . . . . . . . . . . . ITHAA1JRN/A1JRNA Object Object First Journal Sync Library Object Type Receiver Library Journal Data Queue A12212#F UFDFIELD *FILE A1RCVA0002 A12212JRN A1JRNA E2Q0000328 A12212#F UFDFILES *FILE A1RCVA0002 A12212JRN A1JRNA E2Q0000335 Bottom F3=Exit F5=Refresh F12=Cancel


• Sync Dep - On target node only; displays the number of objects (usually files) that have entries that must be applied before the receivers can be deleted.

3.32 New Function Key

The F10=Rebuild Stats function key rebuilds the receiver information and updates the totals for the new columns.

New fields added to 3.32 option 8=Display Receiver Status

Option 8=Display Receiver Status in the Journal Manager screen (3.32) now also includes the following two fields:

• Sync Dep - On target node only; displays the number of objects (usually files) that have entries that must be applied before the receivers can be deleted.

• Partial - Indicates the number of all partial receivers (whether old or not).

New Journal Manager Parameters (3.32, option 2=Change)

The Journal Manager includes two new parameters: Report Beyond Retention Warning and Report Beyond Retention Error. If a receiver exceeds the specified number of hours, then the condition is detected when the JRNMGT test in the Role Swap Readiness Monitor runs for the journal. The parameters appear in the JRM Default Parameters (3.31) screen and on the Journals Control Parameters (3.31, option 2=Change) screen.

SYSTEM2 iTERA Availability 6.2 XPRCV29HAA1ADMIN Journal Manager 2/11/16A11002 Managed Receivers 18:47:30

Library/Journal . . . . . . . . . . . HAA1JRN/A1JRNAiTERA Managed . . . . . . . . . . . . YES

Save Delete In Sync Library Receiver Req Hours Use App Sts Dep Partial A1FCS2JRN A1RCVA0111 NO 16- NO N A1FCS2JRN A1RCVA0112 NO 14- NO N A1FCS2JRN A1RCVA0113 NO 12- NO N A1FCS2JRN A1RCVA0114 NO 10- NO N A1FCS2JRN A1RCVA0115 NO 8- NO N A1FCS2JRN A1RCVA0116 NO 6- NO N A1FCS2JRN A1RCVA0117 NO 4- NO N A1FCS2JRN A1RCVA0118 NO 2- NO N A1FCS2JRN A1RCVA0119 NO 0 NO N A1FCS2JRN A1RCVA0120 NO 2 NO N A1FCS2JRN A1RCVA0121 NO 4 NO N More..

F3=Exit F5=Refresh F9=Applications F10=Rebuild Sts F12=Cancel


These two new parameters also appear in the JRM Default Parameters (3.31) screen.

If the parameter values for a given journal are set to zero then the defaults entered in JRM Default Parameters (3.31) are used.

Enhancements to Role Swap Readiness Monitor tests (1.7)

JRNMGT

The JRNMGT test now detects and reports when receivers eligible for deletion still exist. The test indicates the reason and resolution. There will normally be only one message for each journal.

SYSTEM1 PRIMARY iTERA Availability 6.2 XPRCV293HAA1ADMIN Journal Control Parameters 2/10/16QPADEV0004 Library/Journal . . ITHAA1JRN/A1JRNA 15:23:04

Control Journal Management . . . . . . . Y Y=Yes, N=NoReceiver Change Frequency . . . . . . . 120 MinutesJournal Receiver Retention . . . . . . . 8 HoursSave Required Before Delete . . . . . . N N=No, Y=YesMaxopt Level . . . . . . . . . . . . . . *MAXOPT3Report Beyond Retention Warning . . . . 0 Hours, 0=DefaultReport Beyond Retention Error . . . . . 0 Hours, 0=Default

F3=Exit F5=Refresh F8=Load Defaults F12=Cancel

SYSTEM1 PRIMARY iTERA Availability 6.2 XPRCV211RHAA1ADMIN Journal Manager 2/10/16QPADEV0004 Default Mirrored Journal Parameters 15:25:28

Job Processing Frequency . . . . . . . . . . . . 30 MinutesControl Journal Management . . . . . . . . . . . Y Y=Yes, N=NoReceiver Change Frequency . . . . . . . . . . . 120 MinutesJournal Receiver Retention . . . . . . . . . . . 8 HoursSave Required Before Delete . . . . . . . . . . N N=No, Y=YesProtect Receivers from Early Deletion . . . . . Y Y=Yes, N=NoReport Beyond Retention Warning . . . . . . . . 2 HoursReport Beyond Retention Error . . . . . . . . . 6 Hours

For user journals only, the default for the Journal Control Managementparameter is N and the default for the Save Required Before Deleteparameter is Y.

F3=Exit F5=Refresh F12=Cancel


In the Role Swap Readiness Status screen (option 5=Test Results), each of the messages indicates the number of receivers not deleted and the reason code. If there are multiple reasons then the highest on the list will be displayed for that journal.

The reason codes include the following:

1. NOT SAVED - The receiver must be saved before it can be deleted.

2. SYNC DEPENDENCIES - There is at least one file that has outstanding entries that had not been applied after the save/restore. These entries must be applied before the receiver can be deleted.

3. IN USE - The apply job has not yet applied all of the entries in the receiver. (This is the most common reason most users will encounter.)

4. PARTIAL RECEIVERS - A sequence override may be required to resolve the problem.

SYSTEM1 PRIMARY iTERA Availability 6.2 E21550S1HAA1ADMIN Role Swap Readiness Monitor 2/11/16AS1002 Pri Tgt Last Test 17:15:46Summary Status . . . . . . . . Err Wrn 2016-02-11-17.04.14.072000Type options, press Enter. 1=Work with 2=Change Test 5=Test Results 7=Run Test 8=Submit Test 11=Expand 12=Compress Search for Sts StsOpt Test Description Pri Tgt Results ACCEL Accelerator N/A OK APPLYDATA Data Apply jobs N/A OK APRBMON Access Path Rebuild N/A OK HEAL Heal OK N/A JRNMGT Journal Manager Err OK HAA1JRN/A1JRNA has 7 recei RJSTS Remote Journal Status OK OK ZZJOBS ZZ Jobs N/A OK IFS IFS Integrated File Syst OK OK APPLYIFS IFS Apply jobs N/A OK More...F3=Exit F5=Refresh F7=E2SBS F8=E2MSGLOG F10=WRKJOBQ F13=RepeatF16=Expand/Compress F18=Submit All Tests F20=Control F24=More keys

SYSTEM1 PRIMARY iTERA Availability 6.2 E21551S1HAA1ADMIN Role Swap Readiness Status 2/11/16AS1002 17:17:43 Category/Test . . . . . . . . DATA JRNMGTType options, press Enter. 1=Work with 5=View Results 7=Work with Solution

Position to Search for

StatusOpt System Sts Text SYSTEM1 ERR JRNMGT: Job (A1_JRNMGT) is held SYSTEM1 ERR HAA1JRN/A1JRNA has 7 receivers not deleted. Cause: 5. OLD SYSTEM1 WRN HAA1JRN/A1TJRA has 2 receivers not deleted. Cause: 5. OLD

BottomF3=Exit F13=Repeat F21=System Command F5=Refresh F12=Previous


Always contact CustomerCare for assistance with performing a sequence override.

5. OLD - Although iTERA no longer needs the receiver, it has not been deleted. A common reason why this occurs is that the journal manager job is not running.

Press option 5 on a message to view the Role Swap Readiness Monitor Results screen (1.7, option 5, option 5).

The Results screen has been expanded for all Role Swap Readiness test messages to include second level text. The screen now looks similar to E2MSGLOG. In the screen below, the JRNMGT test detected that there are 7 receivers eligible for deletion that still exist due to reason code 5.

MONTHR

Enhancements to the MONTHR test include the following:

• Receivers that are not managed by iTERA that exceed the monitor threshold specified in E2MONTHR are no longer reported.

• If multiple target nodes are defined then only one error is reported from the primary instead of one for each target node.

(ITHA-12304)

Multiple enhancements to Work with Libraries (4.11)The Work with Libraries display has been expanded to include information and functionality that was formerly accessed via the Library Sync Status screen (4.12), which has been removed from the product. The following topics describe the changes.

SYSTEM1 PRIMARY iTERA Availability 6.2 E21551M1 HAA1ADMIN Monitor Role Swap Readiness Results 2/11/16 AS1002 17:23:42 System . . . . . . . . . . . . SYSTEM1 Test . . . . . . . . . . . . . JRNMGT Message ID . . . . . . . . . . HAE1081 Status . . . . . . . . . . . . ERR Message . . . . : HAA1JRN/A1JRNA has 7 receivers not deleted. Cause: 5. OLD Cause . . . . . : 1. The receivers for this journal must be saved before the receiver(s) can be deleted. 2. If during the save and restore of the object, and records in the file are updated, added or deleted, then special processing is performed including preventing the receiver from being deleted. 3. The apply job may not have completed processing all of the entries in the journal. Or, the journal manager is down. Or, there is only one receiver that is still attached to the journal. 4. The apply job does not know what the next receiver should be. 5. The journal manager may not be running properly. Or, the retention has been adjusted and the journal manager has not performed the deletions. Or, the receivers are locked and cannot be deleted. F3=Exit F7=Resolve F21=System Command F12=Previous


Improved cross library dependency handling

Cross library information and handling has been added to the Work with Libraries screen (4.11, F9=View XRef). It provides more clarity about cross library dependencies and the user no longer requires both the 4.11 and 4.12 screens in order to correctly select the proper order in which to sync libraries with logical files that are based on physical files in other libraries.

The cross library information displayed includes the following:

SYSTEM1 PRIMARY iTERA Availability 6.2 E21000REHAA1ADMIN Work with Libraries for CRG: HA62A1 1/06/16Default Journal New Libraries Only 04:51:54HA62A1JRN/A1JRNC Target System . . . SYSTEM2 116.61 GB TotalType options, press Enter. 2.93 GB Selected 1=Select 2=Update Sync Defaults 5=DSPLIB 6=Select for Tape 7=Object Detail 8=Change Journal 16=Clear New Status 17=Submit *EXCL Anz ... Position to Search for ------- Cross Libraries ------- Files Libraries RepOpt Library Status Journal Size (MB) PF LF PF LF PF LF BLMWORK New .22 1 1 BLM021C New 1.73 2 1 DAVERSQL New 21.67 18 1 DBPERFDTA New 224.45 34 1 DBSYNCHDTA New 111.01 18 1 HALA1A New 6.41 1 1 2 2 HALA1B New .91 1 1 2 2 HALA1C New 4.07 1 1 2 2 JANSREP New 2.27 18 1 JANSTEST New 538.52 1 1 More...F3=Exit F5=Refresh F7=Toggle View F9=View Desc F16=FiltersF15=Change Default Journal F23=More options F24=More keys

Table 1.

Cross Libraries

Files Libraries Rep

PF LF PF LF PF LF

Number of physical files that have at least one logical file not in the same library. (This is not the number of file associations. In the past, the number of associations were displayed.)

Number of logical files that have based on physical files in other libraries.

Number of libraries with physical files that have logical file dependencies.

Number of libraries that have logical files where the based on physical resides in another library.

The state of replication for cross-dependent libraries.

OK - All cross-dependent libraries are defined for Replication.

No - The library of the referenced logical file is not defined for replication.


Hyphens are displayed in PF and LF columns for libraries for which the cross reference has not been run.

New options to display logical and physical files added to Work with Libraries screen

Options to display physical and logical files have been added to the Work with Libraries screen (4.11).

Option 51=Display PF

Display physical file information using option 51=Display PF. This option was formerly 4.12, option 5.

Option 52=Display LF

Display logical file information using option 52=Display LF. This option was formerly 4.12, option 7.

Submitting cross library analysis

Cross library analysis is now submitted through 4.11, F18=Submit Library Analyzer, 4.11, option 19=Cross Lib Anz, xx_ANZLIB job in 2.21, or through the E2ANZLIB command. Library analysis is completed in three phases:

Library Dependencies Library . . . . . . . . . . . AS3069#E Sync Status . . . . . . . . . No Sync The library above should exist on the target system prior to replicating these libraries. Library Status AS3069#EN No Sync AS3069#ER No Sync Bottom F4=Detail F12=Cancel

Library Dependencies Library . . . . . . . . . . . AS3069#EN Sync Status . . . . . . . . . No Sync The library above has logical files based upon files found in the following libraries. Library Status AS3069#E No Sync AS3069#ER No Sync Bottom F4=Detail F12=Cancel


Phase 1: Retrieves the library name and description. This phase usually takes only a few seconds and allows the user to start replicating libraries quickly.

Phase 2: Retrieves the size of each library. The length of time for this phase is dependent upon the number of objects in each library.

Phase 3: Retrieves cross library dependency information.

The E2ANZLIB command includes three parameters.

The Scope parameter has three values:

• *BASIC - Retrieves name and description.

• *SIZE - Retrieves name and description and library size.

• *XREF - Retrieves cross reference information.

• *ALL - Retrieves name, description, size, and cross reference information.

The Submit parameter allows you to either submit immediately (*YES) or interactively (*NO).

The default command values for the library analyzer and E2ANZLIB command can be adjusted in the LIBANZSZ parameter in the Parameter Update screen (10.50). The LIBANZSZ parameter includes the following:

xx_ANZLIB job in Job Monitor (2.21)

The xx_ANZLIB job runs the library analyzer. The job’s default is every Sunday at 3:00 AM. However, it will not run until run is started by selecting 9=Toggle Run (or 2=Change with Run set to Y.)

Analyze Library (E2ANZLIB)

Type choices, press Enter.

Library . . . . . . . . . . . . Name, *ALLScope . . . . . . . . . . . . . *BASIC, *SIZE, *XREF, *ALLSubmit . . . . . . . . . . . . . *YES, *NO

SYSTEM1 PRIMARY iTERA Availability 6.2 E27010RS ZAS3543 Parameter Update 01/05/2016 LIBANZSZ Library Analysis 17:56:31 Clear Library Size before Anz N N=No, Y=Yes Calc Individual Library size Y Y=Yes, N=No Run Cross Library Anz . . . Y N=No, Y=Yes


Tape sync now initiated through Work with Libraries screen

Library replication via tape is now submitted through the Work with Libraries screen via option 6=Select to Tape.

Option 41=Cancel Syncing is now Option 41=Cancel on Target

Option 41=Cancel Syncing has been renamed to 41=Cancel on Target. In multi-target node environments, option 41=Cancel on Target now ends syncing for a specified target node instead of for all nodes.

Import Libraries from SATLITE (10.3) includes cross reference

The SATLITE import (10.3) now includes the cross library dependency information.

(ITHA-9681)

New options to not start apply processes and jobs after role swap

Two new fields have been added to the Role Swap Confirmation screen (40.30, F16, F16). When set to *NO, these fields, Start Journal Apply Jobs and Start Replication Processing Jobs, prevent replication processes from automatically starting during the recovery phase of a role swap. The user then has the opportunity to verify that information and data on the new primary is correct and complete. Once verified, the user must then start each apply job and replication processing job manually. The default for each field is *YES, which means that all replication processes and apply jobs will be automatically started during the recovery phase of the role swap.

SYSTEM1 PRIMARY iTERA Availability 6.2 Change E23550M1 ZAS3069 Job Monitor Maintenance 01/05/2016 QPADEV0009 11:01:34 Job Name . . . . . . . . . . . AS_ANZLIB System . . . . . . . . . . . . SOURCE SOURCE, TARGET Job Description . . . . . . . E2JOBD *LIBL Job Queue . . . . . . . . . . E2SYSJOBQ *LIBL Replication Option . . . . . . *BASE Submit Job . . . . . . . . . . N Y=Yes, N=No Command . . . . . . . . . . . E2ANZLIB LIB(*ALL) SCOPE(*ALL) Description . . . . . . . Cross Library Analysis Run . . . . . . . . . . . . . Y Y=Yes, N=No End job if running . . . . . . N Y=Yes, N=No Job Queue Priority . . . . . . *JOBD 1-9, *JOBD Interval . . . . . . . . . . . *DAY *ALWAYS, *DAY, *TIME Sun Mon Tue Wed Thu Fri Sat Execute Day of Week . . . . . Y N N N N N N Time of Day/Time Interval . . 3:00 HHH:MM Next Start Time . . . . . . . 2015-07-19-03.00.00.000000 Prev Start Time . . . . . . . 2015-07-13-17.16.56.901000 F3=Exit F20=Job Attributes F21=System Command F12=Previous


Start Journal Apply Jobs

When set to *NO, the Start Journal Apply Jobs parameter will disable automatic start for all apply jobs for all journals except for the communication journals. The disabled apply jobs include Data, IFS, Transport, MQ, and RJT syncing (OSR).

The communication journals will remain active in order to provide limited information to be communicated between systems, including System Monitor (1.1) updates and Role Swap Readiness Monitor (1.7) jobs to complete as well as to send back updates from the target systems for IFS and Heal requests. (However, with the apply jobs down there will not be any data sent back to the primary until the other apply jobs are started.)

The transport journal apply job is suspended, since it is used for updates of many objects, including user profiles, devices, directory entries, job schedule entries, and spooled files. Object Sync Requests (OSR) are also sent through the transport journal. Having the transport apply job down will also prevent any changes to non-journal eligible objects until the user has validated the system as required.

Apply jobs that are not started after a role swap will display on the Role Swap Monitor screen as a severe issue.

• The System Monitor will allow only certain jobs to start including the Role Swap Readiness Monitor job and remote commands. This will allow basic communication to exist, while not starting replication.

• The MXAUDITSCD job in MIMIXSBS will be automatically placed on hold, but must be manually released after the apply jobs have been started.

Start Replication Processing Jobs

When set to *NO, the Start Replication Processing Jobs parameter will cause the following:

• The OBJMON* jobs will not run since these will place entries into temporary files used by other processes.

• Any job used to replicate objects, data, or other items such as xx_RPTREP, xx_IFSREP, xx_HEALnnn, and xx_SNC_nnn will not run.

• The audit monitor (xx_AUDMON) will not be started. Starting the audit monitor (1.8 F11) will start the job unless the subsystem has ended. The audit monitor must be manually restarted after a role swap.

• xx_SYSMON will just run once in order to perform the minimal number of jobs then end. It will not continue to run until started again using E2STRMON,E2STRSBS, or 2.21.

• Any other job found in Monitored Jobs (2.21) except explicitly defined as part of the minimum jobs. This includes the job xx_SYNCNML which could copy Non-mirrored Sync (4.30).

• The System Monitor and E2STRSBS allow a only a minimum number of jobs to start, including:

– xx_RMTCMD - Remote commands

– xx_RSRMON - RSR monitor

– xx_SYSMON - System monitor (primary only)

– QGYSERVER - IBM generated jobs used by the RSRMON job (does not have to start)

– E2A_NOTIFY - IT Alert Notify if Alert is enabled


– E2A_EMAIL - IT Alert Notify if Alert is enabled

• The system monitor job xx_SYSMON when submitted by the Role Swap will only start the minimum jobs and then end.

When Start Replication Processing Jobs is set to *NO, Start Journal Apply Jobs must also be set to *NO.

You can prevent apply jobs from starting but allow all other jobs to start normally by setting Start Journal Apply Jobs to *NO and Start Replication Processing Jobs to *YES.

Manual start up

When Start Journal Apply Jobs and Start Replication Processing Jobs are set to *NO, the following must be manually started. These steps have been added to the Role Swap Checklist to allow for these manual processes.

1. On a command line, enter E2STRMON or select option 2.20 (the equivalent to calling E2STRMON).

2. Manually start apply jobs using 2.21. (The apply jobs may be started at once or individually. By allowing them to start individually, the associated objects can be verified for a journal separately.)

3. End and restart the subsystems (E2ENDSBS, E2STRSBS).

Role Swap Confirmation screen (40.30, F16, F16) changes

Role Swap Defaults

The Start Journal Apply Jobs and Start Replication Processing Jobs parameters are now included in the Set Role Swap Defaults screen (30.21, F7, F11).

SYSTEM2 iTERA Availability 6.2 E25503RE Initiate Role Swap Confirmation YOU ARE PERFORMING A LIVE ROLE SWAP. This is NOT a Virtual Role Swap New Primary System . . . . . . . . . . . . . . VSI73 Enable Disabled Profiles . . . . . . . . . . . *NO Run User Startup Program . . . . . . . . . . . *NO Start TCP/IP Interfaces . . . . . . . . . . . *NO Start Journal Apply Jobs . . . . . . . . . . . *YES <- New option Start Replication Processing Jobs . . . . . . *YES <- New option WARNING: Do NOT manually end or start iTERA Jobs or Subsystems during the Role Swap Process. Contact iTERA support if problems occur. Press F10 to Initiate Role Swap F3=Exit F5=Refresh F10=Role Swap F12=Cancel


Action required: Download updated user documentation from Support Central, including the Role Swap Checklist, iTERA HA 6.2 User Guide, and iTERA 6.2 Reference Guide.

(ITHA-10679)

Work with Locked Objects (4.22) screen now includes EXCLRD

When the F18=Submit Analyzer is executed from the Work with Locked Objects screen (4.22), the display now includes objects in both *EXCLRD (exclusive lock, allow read) and *EXCL (exclusive lock) states.

(ITHA-11685)

Troubleshooting information for audit attributes added to iTERA Reference Guide appendix

The Interpreting Audit Results appendix in the iTERA Reference Guide now includes troubleshooting information for many audit attributes.

(ITHA-12467)

Automatic recovery for journaling discrepanciesThe File Attribute (#FILATR), Object Attribute (#OBJATR), and IFS Attribute (#IFSATR) audits now automatically correct object journal attribute discrepancies between nodes. When the configured journal for a given object is an iTERA mirror journal, incorrect journal attributes will be automatically corrected on the target node. When the configured journal for a given object is a non-iTERA user journal (i.e., the journal was created outside of iTERA but imported or defined to

SYSTEM1 iTERA Availability 6.2 E25511REHAA1ADMIN Resource Groups 1/11/16QPADEV0005 13:09:01Base Library . . . . . . . . ITHAA1Transfer Port . . . . . . . 54907

CRG Name . . . . . . . . . . ITHAA1..............................................................................: Set Role Swap Defaults :: :: Enable Disabled Profiles . . . . . . . . . . *NO *NO, *YES :: Run User Startup Program . . . . . . . . . . *NO *NO, *YES :: Start TCP/IP Interfaces . . . . . . . . . . *NO *NO, *YES :: Start Journal Apply Jobs . . . . . . . . . . *YES *YES, *NO :: Start Replication Processing Jobs . . . . . *YES *YES, *NO :: :: :: F3=Exit F5=Refresh F12=Cancel :: ::............................................................................:

F3=Exit F5=Refresh F7=TCP/IP Mapping F9=PasswordF10=Replication Components F11=Role Swap Defaults F24=More keys


iTERA), incorrect journal attributes will be corrected only if the JRNFORCE policy value is set to *YES.

New Correct USER journal differences (JRNFORCE) policy in SETPCY

A new policy, Correct USER journal differences (JRNFORCE) has been added to the SETPCY command. The policy affects only the #FILATR and #OBJATR audits. Since IFS doesn't have a journal distinction of mirror and user, which apply only to journals used for library replication, journaling correction and recovery for IFS objects will occur regardless of the JRNFORCE policy value.

The value of the new JRNFORCE policy is retained with existing policy values. *YES indicates object journal attributes will be corrected by the #FILATR and #OBJATR audits even if the object is journaled to a non-iTERA user journal. The default is *NO.

The changed recovery behavior is only performed during the audit recovery process and does not affect object replication.

The JRNFORCE policy value allows the changed recovery behavior to be applied toward a specific data group or an entire installation (*INST). This will provide flexibility in the case that some data groups are required to be left alone, while others are allowed to be auto-recovered.

Note: Recovery performance may be negatively affected when journaling must be corrected on large numbers of objects found to be journaled incorrectly.

How object journal attributes are corrected

The journal attributes retained by an object include the journaled state, journal name, journal library name, the journal images setting and the journal entries to be omitted value. All attributes as well as the creation of the journal and journal library are corrected.

• Journal state - The journal and journal library is created, if necessary, and journaling is started.

• Journal name - When an incorrect journal is found to be associated to a given object,

Set Policies (SETPCY) Type choices, press Enter. Data group definition: Name . . . . . . . . . . . . . *INST Name, *INST, F4 for list System 1 . . . . . . . . . . . Name, *LOCAL, F4 for list System 2 . . . . . . . . . . . Name, *LOCAL, F4 for list Audit rule . . . . . . . . . . . *NONE Name, *NONE, F4 for list Automatic audit recovery . . . . *ENABLED *SAME, *DISABLED, *ENABLED... Correct USER journal differences *NO *SAME, *INST, *NO, *YES Audit notify on success . . . . *RULE *SAME, *INST, *NO, *RULE... Notification severity . . . . . *RULE *SAME, *ERROR, *INFO... Object only on target . . . . . *DISABLED *SAME, *DELETE, *DISABLED... Maximum rule runtime . . . . . . 1440 60-10080, *SAME, *INST Audit warning threshold (days) 8 1-999, *SAME, *INST... Audit action threshold (days) . 15 1-999, *SAME, *INST... Audit level . . . . . . . . . . *LEVEL30 *SAME, *DISABLED... Action for running audits: Apply in threshold . . . . . . *NONE *SAME, *CMP, *CMPRPR... More... F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys


journaling will be ended and restarted using the correct journal. The journal will be created, if required.

• Journal library - When an incorrect journal library is found to be associated to a given object, journaling will be ended and restarted using the correct journal and journal library. The journal library will be created, if required.

• Journal images (IMAGES) - When an incorrect “journal images” setting is found, the journal attribute will be changed without ending journaling where possible using the CHGJRNOBJ command. Ending and restarting journaling will be performed if the CHGJRNOBJ command is unsuccessful.

• Journal entries (OMTJRNE) - When an incorrect “journal entries to be omitted” value is found, the journal attribute will be changed (where possible) without ending journaling using the CHGJRNOBJ command. Ending and restarting journaling will be performed if the CHGJRNOBJ command is unsuccessful.

(ITHA-10773)

New #FILDTA change date (CHGDATE) policy value for #FILDTA audit

The new #FILDTA change date (CHGDATE) policy in the SETPCY command allows you to easily configure the *AUDIT setting for the #FILDTA audit. It specifies the date that #FILDTA will use in determining whether to process a file member. The file member on the source system is used in this determination. Only members changed or restored after the last successful audit will be processed.

The new CHGDATE policy value allows the changed recovery behavior to be applied toward a specific data group or an entire installation (*INST). This will provide flexibility in the case that some data groups are required to be left alone, while others are allowed to be auto-recovered.

Set Policies (SETPCY) Type choices, press Enter. Data group definition: Name . . . . . . . . . . . . . *INST Name, *INST, F4 for list System 1 . . . . . . . . . . . Name, *LOCAL, F4 for list System 2 . . . . . . . . . . . Name, *LOCAL, F4 for list Audit rule . . . . . . . . . . . *NONE Name, *NONE, F4 for list Automatic audit recovery . . . . *ENABLED *SAME, *DISABLED, *ENABLED... Correct USER journal differences *NO *SAME, *INST, *NO, *YES Audit notify on success . . . . *RULE *SAME, *INST, *NO, *RULE... Notification severity . . . . . *RULE *SAME, *ERROR, *INFO... Object only on target . . . . . *DISABLED *SAME, *DELETE, *DISABLED... Maximum rule runtime . . . . . . 1440 60-10080, *SAME, *INST Audit warning threshold (days) 8 1-999, *SAME, *INST... Audit action threshold (days) . 15 1-999, *SAME, *INST... Audit level . . . . . . . . . . *LEVEL30 *SAME, *DISABLED... #FILDTA change date . . . . . . *ALL *SAME, *INST, *ALL, *AUDIT Action for running audits: Apply in threshold . . . . . . *NONE *SAME, *CMP, *CMPRPR... More... F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys


The values for the CHGDATE policy include the following:

• *SAME = The policy value is not changed. This allows the SETPCY command to be executed and other policies to be changed without changing the current value/setting of the CHGDATE policy.

• *INST = The policy is set to the value used for the installation. This is only valid when a value other than *INST is specified for the Data group definition (DGDFN).

• *ALL = The default value. All files in the library are candidates to be audited, regardless of the last change date of the file's data member.

• *AUDIT = Only the objects that were changed since the last successful run of the #FILDTA audit are audited. The Compare Start timestamp of the last time the #FILDTA audit ran to completion is used in determining what objects are audited. Audit level *LEVEL30 is required in order to use this setting.

(ITHA-11927)

#FILATR audit now audits attribute Long SQL NameThe File Attribute audit #FILATR now includes support for auditing the Long SQL Name attribute.

(ITHA-10693)

New and improved screen views in IFS Replication, new IFS status

Two new screen views have been added to IFS Replication. The Assigned/JrnActiv view makes it easier to identify IFS objects that are assigned to a default journal or are actively being journaled but not yet synchronized. The Defined objects view makes it easier to locate specific replicated objects. Improvements to the existing tape sync view eliminate having to drill down into sub-directories in order to locate IFS objects to be included in a tape sync.

The screens are accessed using the F7 key to cycle through the additional screen views.

Assigned/JrnActiv view

The Assigned/JrnActiv view displays the IFS objects that are assigned or journal active but that are not synced. The list can be used to complete the replication process.


New status: JrnOther

When an IFS object is replicated, the status progresses through Assigned, JrnActive, and then Active. However, when an object is journaled but not replicated then the status also displayed as JrnActive. In the past, some users have mistakenly used option 3=Start mirroring on these objects.

The new status JrnOther is now used to indicate that an IFS object is journaled but not included in replication for the installation.

Improved Tape Sync view

The Tape Sync view now automatically displays IFS objects in statuses TapeSync, TapeHold, TapeFail, TapeWait, and On Tape on the Tape Sync display. The user no longer has to first drill down in the directory tree of the parent directory using the All Directories view prior to pressing F7 twice to view the tape sync objects.

Defined Objects view

The Defined Objects view makes it easier to locate specific replicated objects. The display is sorted by object name with the directory tree directly listed below each object’s name.

SYSTEM1 PRIMARY iTERA Avail 6.2 Work with Directories E27580RE 1/04/2016 CRG CRGSDSAUD Assigned/JrnActiv Directories Target: SYSTEM2 08:43:14 Default Journal SDSAUDJRN/SDIJRA Directory / Type options, press Enter. Sorting by Name 1=Assign to dft jrn 2=Start jrn 3=Start mirroring 4=Quick sync (2,3) 5=Display link 7=Cancel mirroring 8=End journaling... Position to Filter on Type Opt Object Name Type OL Status Journal sds1obj *DIR Assigned SDSAUDJRN/SDIJRA sds1obj2 *DIR Y Assigned SDSAUDJRN/SDIJRA sds22751 *DIR JrnActiv SDSAUDJRN/SDIJRA Bottom Command ===> F3=Exit F5=Refresh F7=TapeSync view F12=Cancel F13=Select default journal F23=More options F24=More keys


(ITHA-11736)

Improved handling for large IFS objectsWhen the IFSMON job or subsystems are ended while IFS objects are still syncing, IFS replication will now resume where it left off instead of re-initiating syncing when the IFSMON job or subsystems are restarted.

(ITHA-11724)

IFSASSIGN test added to Role Swap Readiness MonitorA new test, IFSASSIGN, has been added to the Role Swap Readiness Monitor (1.7). The test appears in the IFS group of tests.

IFSASSIGN checks for IFS objects that are assigned (JrnActiv) but are not replicating.

(ITHA-11683)

MQ replication journal now automatically createdWhen starting MQ Replication for the first time (Replication Options, 30.23, option 6 on *MQ) an MQ replication journal will now be automatically created and assigned as the default journal for MQ objects.

(ITHA-13214)

SYSTEM1 PRIMARY iTERA Avail 6.2 Work with Directories E27580RE 1/05/2016 CRG CRGAS6094 Defined Objects Target: SYSTEM2 12:12:58 Default Journal AS6094JRN/ASIJRA Type options, press Enter. 1=Assign to default journal 2=Start journaling 3=Start mirroring 4=Quick sync (2,3) 7=Cancel mirroring 8=End journaling ... Position to Filter on Type Opt Object Name Type OL Status Journal AS6094A *DIR / AS6094B *DIR / AS6094C *DIR / Bard *DIR Active AS6094JRN/ASIJRA /AS6094A/Story/Lonely Mountain/Dale More... Command ===> F3=Exit F2=Select Target F5=Refresh F7=All objects F8=Monitor F9=Options F12=Previous F23=More options F24=More keys


Constraint and database relations discrepancies now automatically corrected

Discrepancies detected by the #FILATR audit for the *CSTNBR, *CSTIND and *DBRIND attributes are now automatically corrected on the target node.

The discrepancy will be auto-recovered. Continued auto-recovered results on subsequent audit runs indicates that the auto-recovery action was not successful and should be further investigated.

To provide additional visibility of failures encountered during recovery, a message will be sent to E2MSGLOG indicating that a constraint action failed. During constraint recovery, it is possible that certain constraints may be either removed, added or disabled. A failure to perform any of these actions will be reported to E2MSGLOG.

A report of the audited object(s) is created by the transport journal apply job on the target system. To view the report, issue WRKSPLF SELECT(*CURRENT *ALL *ALL E21309RP1).

If a constraint is added to the target during recovery to match the primary, the enabled/disabled state should be such that it matches iTERA configuration settings of 4.24.

(ITHA-10129)

Role Swap Readiness Monitor DEFN test now checks audit configuration

The DEFN test in the SETUP group of tests in the Role Swap Readiness Monitor (1.7) now checks audit configuration in order to ensure that each data group has all six audits defined (#DLOATR, #FILATR, #FILATRMBR, #FILDTA, #IFSATR, and #OBJATR). Missing audit rules will be added to the data group configuration.

(ITHA-11683)

Disabled Role Swap Readiness Monitor tests will now display warning status

Tests that have been disabled in the Role Swap Readiness Monitor will now be displayed with the WRN (warning) status.

(ITHA-13174)

Improved performance of initial replication of user profilesImproved performance of the initial replication of user profiles (5.1).

(ITHA-13058)


New default values for audit history retention parameters in Set Policies (SETPCY) command

The default installation values for the Object details and DLO and IFS details parameters in the Set Policies (SETPCY) command are now *YES. Existing installations that are upgraded will automatically inherit the new default values.

(ITHA-13127)

Support for environments running IBM i 7.3This version of iTERA supports replication between systems running the IBM i 7.3 operating system. However, there is an issue between systems running different operating system levels, described in more detail below. Additionally, there may be new IBM capabilities in IBM i 7.3 that iTERA does not yet fully support.

Known restriction: A known issue identified in IBM APARs SE64667 and SE64928 affects environments that perform replication between systems running different operating system levels. When one of the systems is running IBM i 7.3 and the other system is running IBM i 7.2 or IBM i 7.1, events that add triggers (D-TC journal entries) cannot be properly replicated. IBM has released fixes to address the issue. The CHKIBMPTF tool has been updated with these PTFs.

Action required: Regardless of the known restriction, if any system in your iTERA environment is running IBM i 7.3, you must install required IBM PTFs on that system before installing or upgrading the product on that system. PTFs may also be needed on the systems running earlier releases of the operating system. Refer to “Checking systems for recommended IBM PTFs” on page 38 for instructions on using the CHKIBMPTF tool. The known required PTFs include the following:

• For systems running IBM i 7.3, install PTFs SI60941, SI60942.

• For systems running IBM i 7.2, install PTF SI60943.

• For systems running IBM i 7.1, install PTF SI61070.

(ITHA-13018)

Minimum supported OS level is now V6R1The minimum OS level supported by iTERA is now V6R1. This primarily affects the product in relation to the QDFTJRN data area, which will no longer be supported. Management for the QDFTJRN data area has been removed from the product. Journal at Birth using STRJRNLIB is now the only supported method for automatically journaling new objects added to a library.

(ITHA-11434)

iTERA Installation Wizard now supports Windows® 8.1 and Windows® 10

iTERA Installation Wizard can now be run on a Windows® 8.1 or Windows® 10 server to install iTERA on an IBM i. The system using the iTERA Installation Wizard must meet


http://www-912.ibm.com/n_dir/nas4apar.nsf/ALLAPARS/SE64667

http://www-912.ibm.com/n_dir/nas4apar.nsf/ALLAPARS/se64928

requirements for their specific operating system. The complete list of wizard requirements is available from Support Central as well as from the More Info link on the wizard’s Welcome panel.

(ITHA-12771)

Internal iTERA product files now journaledSome internal iTERA product files are now journaled in order to avoid duplicate key errors after a system crash. The information in the journals is used by CustomerCare to assist the user in ensuring the product is fully functional following a system crash.

(ITHA-10863)


ITHA-11763 Authority change errors will now be reported to the message log if the object is locked.

ITHA-12205 Improved handling when CPF7053 is received due to partial receiver processing by apply jobs.

ITHA-12505 The RST_NMLO joblogs will no longer contain unnecessary CPI9802 messages.

ITHA-12572 ASP Maps (3.1 F6) are now functional with journal overrides.

ITHA-12583 Journal receiver management job (xx_JRNMGT) will no longer fail due to CPF9830.

ITHA-12595 Improved usability of MRRDWNGRP and MRRRSTGRP commands.

ITHA-12652 Improved handling for replicated SQL objects following the COMMIT or ROLLBACK of commitment control transactions.

ITHA-12671 An informational message (VSI0002) is placed in QSYSOPR when iTERA detects workload capping is in use.

ITHA-12684 Reduced the occurrence of the *SQLSP difference indicator being reported by the #OBJATR audit following the recompile of a stored procedure's associated program or service program object.

ITHA-12704 When a user journal is defined to the iTERA configuration (3.1, F22), it will now be created on the target with the correct *MAXOPTx Receiver Size Option value and Journal Object Limit value.

ITHA-12711 The Work with Sync Exclusions window (4.30) will no longer allow the entry of an object name that is just an asterisk.

ITHA-12729 On the System Monitor screen (1.1), the “No” values for Local/Remote Journals Active, Apply Jobs Active and Network/Subsystem Active will now be displayed in red.


ITHA-12765 WebSphere MQ Replication (5.6) MQ journal AMQAJRN and its receivers are now copied to all target nodes when starting replication.

ITHA-12770 Improved file handle pointer management to prevent error "LVE0102 - iTERA detected internal error but continued processing." This can occur within the apply job by procedure "doIteraCompareDataActive" during #FILDTA U-MX transaction processing.

ITHA-12777 Executing the E2ENDSBS command will no longer result in an error message if the command is run when the iTERA subsystem is already inactive.

ITHA-12857 When starting journaling the #IFSATR will now use the journal of the parent directory instead of the default journal.

ITHA-12918 Improved error handling added to job xx_CLRSNCO. The job will no longer enter MSGW status due to error CPF3014.

ITHA-13017 Corrected invalid tape sync status in IFS replication (5.2).

ITHA-13031 Non-journaled objects that have had the authority changed then immediately moved will now retain the authority changes.

ITHA-13038 Spooled File replication (RPTREP) job will no longer loop due to duplicate time stamps.

ITHA-13059 Improved the cleanup for deleted nodes.

ITHA-13075 IFS replication now supports an increased number of private authorities.

ITHA-13085 E2MSGLOG - Improved message reporting for routed messages if a message fails to be sent.

ITHA-13087 Replication definitions that are defined as * will be replaced with *ALL.

ITHA-13102 Work with Remote Journaling (3.3) F14=Select Other now displays the correct remote library.

ITHA-13109 Object Sync Request (E2OSR) - E2MSGLOG. - Corrected message displayed when a program fails to replicate when the operating system of the operating system on the source system is higher than the target system.

ITHA-13146 Spooled File Replication (5.3) - Reports that have a status on the primary after a report is printed will now have the same status on the target.

ITHA-13148 Directory Entry Replication Maps (5.7 F16) - Maps with specific addresses now work properly.

ITHA-13188 User Profile Replication (5.1) will now replicate the parameter Set password to expired (PWDEXP).

ITHA-13191 iTERA Managed Journals (3.32) Corrected function key display for F6=Add Journal.

ITHA-13192 OSR sync job (xx_SNC_xxx) will now end and restart due to a DDM issue if it fails.


ITHA-13235 The journal manager job xx_JRNMGT will no longer go into MSGW due to MCH3601.

ITHA-13239 Invalid Non-mirrored Sync Definitions (4.30) exclusions are no longer permitted.

ITHA-13240 TCP/IP Interface Definition (30.22) - IP Address definitions of *NONE will now be displayed in green text instead of red.


System RequirementsThe following are system requirements for the correct operation of iTERA.

iTERA Configuration

The minimum system configuration requirement for an iTERA replication environment is a primary and a backup node. An additional node is allowed and may be defined as either backup or replicate. Not more than three systems are supported for replication.

If installing or upgrading iTERA via the Installation Wizard, the More Info doc, available from a link within the wizard or from the Product Downloads page on Support Central, lists additional requirements for using that tool.

Software requirements for installing or upgrading

The table below identifies the software required in order to install iTERA version 8.1 for the first time or to upgrade iTERA to version 8.1. Each system in the replication environment must have this software installed and be current with the recommended PTFs and service packs applied.

Use the Check IBM PTF (CHKIBMPTF) command to check whether the IBM i PTFs that Vision Solutions recommends are applied on all systems on which iTERA will be installed. See “Checking systems for recommended IBM PTFs” below for details.

Note: Upgrades to the latest service pack are supported from any version 7 service pack level.

Software Minimum level Notes

IBM i operating system

Option 30 QSHELL

Option 33 Portable App Solutions Environment

IBM i 6.1 (V6R1M0) 1, 2

*COMPATIBLE or *INSTALLED

3, 4

*COMPATIBLE

5722JV1 *BASE IBM Developer Kit For Java *COMPATIBLE 5

License Manager 6.0.00.00 or above for upgrades

6

iTERA Availability 6.1.01.00 or above for upgrades

7, 8, 9


http://portal.visionsolutions.com/default.aspx?id=31&ekmensel=c580fa7b_8_10_btnlink

Other requirements

CPWCommercial Processing Workload (CPW) for the target should be at least 50% (or better) than that of the primary.

Average CPU % UtilizationMinimum CPU for target system is 35% of that of the primary, although 50% (or more) is recommended for better performance.

DASD CapacityDASD on the target system should be the same or greater than that of the primary.

ServersThe following TCP/IP servers must be running: FTP, DDM, TELNET, and REXEC. Ping (ICMP) must also be running. The systems must be able to communicate with each other over the replication IP addresses using the ITERAOWNER user profile. Ensure that there are no security or network restrictions between the systems for these protocols in any direction.

Use the following command to start the servers:

STRTCPSVR SERVER(*DDM *FTP *REXEC)

Use the following command to set the autostart value for the REXEC server:

CHGRXCA AUTOSTART(*YES)

PortsThe following ports are required.

1. Required for new installs and upgrades.

2. Vision Solutions recommends that all nodes run the same OS level. However, iTERA does support replication for up to two version level differences. Vision always recommends that the backup node run the higher OS. For additional information, see the “Running the primary and target nodes on different levels of the IBM OS” topic in the User Guide.

3. Both are required for IFS Replication.

4. QSHELL cannot be in the SYS portion of the library list. QSHELL will be added to the E2JOBD and must remain there, even if not replicating IFS.

5. Required for iTERA Alert.

6. Required for new installs and upgrades. When installing or upgrading iTERA, License Manager is automatically installed first at the correct version (7.0.22.00 or above). If a version of License Manager earlier than 6.0 exists on the system at the time of install or upgrade, then License Manager must be upgraded to at least 6.0 (using the appropriate installation media) before installing iTERA. (Installation media for earlier versions of MIMIX include License Manager and are available on Support Central.)

7. Upgrades from iTERA version 7 are supported. If you are upgrading and are not at version 7 or above, you must upgrade to version 7 before upgrading to version 8.1.

8. Upgrades are valid only when maintenance is current. Customers not current on maintenance will only be able to re-install the same version, update, and service pack level (V.U.SP) and install fixes for that level. See “Displaying maintenance expiration and license key information” in the Using License Manager book for more information.

9. Upgrades to version 8.1 require license keys that are for version 8.1 only. New installs of version 6.2 can be completed with no license keys present, although a valid license key is required before using the product. For information about obtaining license keys, see “Working with license keys” in the Using License Manager book.

Software Minimum level Notes


Checking systems for recommended IBM PTFs

Vision Solutions recommends that certain IBM PTFs be applied on all systems or LPARs on which iTERA is installed. Vision Solutions provides the Check IBM PTF (CHKIBMPTF) command to simplify the method of determining whether the recommended PTFs are applied. The command is packaged in a downloadable streamfile attached to Knowledgebase article 45894. This version is updated approximately monthly with the latest list of recommended PTFs. Use this version before installing on a new system or any time you need to check for the latest recommended PTFs. Always restore the command to the CHKIBMPTF library as indicated in the Knowledgebase article.

The command is also packaged in iTERA’s main product library and may be run from within iTERA. This version will be updated at each service pack release.

If you download the command from the Knowledgebase, always restore it to the location identified in the Knowledgebase article. The downloaded version does not update the version in the iTERA product library. Never attempt to restore the downloaded version to the ITERA product library as doing so may adversely affect subsequent software installs.

The CHKIBMPTF command runs on a single system. Run the command on all systems where iTERA is or will be installed. Running the command checks that system for recommended IBM PTFs and generates two QPRINT outputs. One output file lists the status of only the PTFs that require attention or corrective action. The other output file lists all the recommended PTFs and their status on the system. You can also use the

Port number Required for

ICMP Ping

21 FTP

23 Telnet

446/447 DDM/DRDA

512 REXEC server

3777 Remote Journaling

50510 through 50520

The #FILDTA audit uses a communications port based on the port number specified in the transfer definition (30.21, Transfer Port field). The default port is 50510. An open port is required for each #FILDTA audit and there is one #FILDTA audit per replication journal. These audits generally run simultaneously. If you have multiple #FILDTA audits, you must open the equivalent number of ports in your firewall. For example, if the port number in your transfer definition is 50510 and you have ten #FILDTA audits, you should open at least ten ports in your firewall—minimally, ports 50510 through 50520. If you attempt to run more jobs than there are open ports, those jobs will fail.

For additional iTERA CRG installations the port number is automatically increased by ten. For example, a second CRG would have 50520 as the port specified in 30.21, Transfer Port field, and a third CRG would specify 50530. If the ports are being used by another process (such as another iTERA installation or other application or service), the port number that iTERA uses must be changed before the subsystems are started. Instructions for changing the port number are included in the Configure CRGs chapter of both the iTERA Installation Guide and iTERA Upgrade Guide.


http://visionsolutions.custhelp.com/app/answers/detail/a_id/45894/p/1

http://visionsolutions.custhelp.com/app/answers/detail/a_id/45894/p/1

release-specific PTF list in the Knowledgebase article to link to PTF cover letters for additional details about a PTF.

To download and run the Knowledgebase version of the command, use the instructions in the Knowledgebase article to download and install the command on each system. The command must include the library qualifier: CHKIBMPTF/CHKIBMPTF

To run the command within iTERA, sign on with the iTERA Admin profile and run the command on an iTERA command line: CHKIBMPTF.

System Settings

The following are required for iTERA and must be configured prior to installing or upgrading.

System Settings - Automatically ConfiguredThe system values and other parameters in the following table are automatically configured when iTERA is installed. Some of the settings are required; others indicate a recommended minimum setting. The installation/upgrade program will automatically change them if they are set lower than the required minimum. The value will not be changed if set higher. System values settings that do not fall within the parameters specified may negatively impact iTERA operation.

System Setting

Required (or minimum) Settings

Command to display and/or change

Notes

Manage Receivers *SYSTEM WRKJRNA QSYS/QAUDJRN

CHGJRN

QAUDJRN is required for iTERA. In order for iTERA to manage the QAUDJRN receivers, the Manage Receivers setting must be set to *SYSTEM. This setting will allow the system to swap out journal receivers according to the setting in the receivers. The *NO setting for Delete Receivers will allow iTERA to verify that the receivers have been sent to the backup system and changes applied prior to deleting the receivers. For this setting, if you do not have iTERA running, then the journal receivers will not be deleted and you will see an increase in disk usage.

Refer to the iTERA Availability Pre-Installation Checklist for configuration instructions.

Delete Receivers *NO WRKJRNA QSYS/QAUDJRN

CHGJRN

System values for user profile passwords (QPWD*)

Values must be the same on all systems.

WRKSYSVAL QPWD* The settings for user profile passwords must be the same on all systems in order to ensure that profile replication functions correctly.

Security 30 or higher WRKSYSVAL QSECURITY

This is important for products that function between systems when assessing security requirements.


System SettingRequired (or minimum) Settings


Notes

TCP keep alive 5 CHGTCPA TCP Keep Alive specifies the amount of time, in minutes, that TCP waits before sending out a probe to the other side of a connection. The probe is sent when the connection is otherwise idle, even when there is no data to be sent. If the value is too high, you have the potential of being exposed for the length of this setting.

TCP receive buffer size

65536 (or greater) CHGTCPA The send and receive buffer size is the TCP send and receive window size. Decreasing this value decreases the amount of data that the remote system can send before being read by the local application.TCP send buffer size 65536 CHGTCPA

Autostart Server *YES CHGDDMTCPA This setting allows for the DDM server to start automatically and not require a password when making DDM connections into this system.

If you are uncomfortable setting the password required to *NO then you will need to set up the appropriate Server Authorization List entries for the ITERAOWNER profile. See Server Authorization List Entries in the iTERA Availability Pre-Installation Checklist.

QAUDCTL *NOQTEMP

*OBJAUD

*AUDLVL

WRKSYSVAL QAUD*

This system value contains the on and off switches for object and user action auditing. iTERA replication requires that changes be tracked through the QAUDJRN.

• *NOQTEMP - indicates no auditing of objects in QTEMP.

• *OBJAUD - indicates auditing of objects will occur for those selected as the result of using the CHGOBJAUD system command.

• *AUDLVL - indicates auditing of changes controlled by the QAUDLVL system value, the CHGUSRAUD command, or AUDLVL keyword.

QAUDENDACN *NOTIFY WRKSYSVAL QAUD*

This system value indicates the action that should be taken by the system when audit records cannot be sent to the auditing journal because of errors that occur when the journal entry is sent. This is important because you will want to be notified if auditing is not taking place.


General Requirements

• Do not replicate libraries LAKEVIEW, MIMIXQGPL, VSI001LIB, any Vision Solutions product libraries (iTERA, MIMIX, iOptimize, etc.), the IFS locations /visionsolutions/http/vsisvr, and /LakeviewTech.

QAUDFRCLVL *SYS WRKSYSVAL QAUD*

This system value indicates the number of journal entries written to the security auditing journal before the journal entry data is forced to auxiliary storage. The system writes the journal entries to auxiliary storage only when this system determines the journal entries should be written based on internal system processing. Using this option provides the best auditing performance. The value in this reference file also controls the amount of auditing data that could be lost if the system ends abnormally. If auditing entries are frequently forced to auxiliary storage, system performance can be negatively affected. This system value is used to change the QAUDJRN journal to indicate how often the auditing data is forced.

QAUDLVL *CREATE*DELETE*OBJMGT*OFCSRV*PRTDTA *SAVRST*SECURITY*SPLFDTA*SYSMGT

WRKSYSVAL QAUD*

This system value controls the level of action auditing on the system. These settings track changes and are required for system replication. Check the IBM help feature for more information on the changes that are tracked for each setting.

• *PRTDTA and *SPLFDTA are only required if replicating spool files.

• If 5.7 Directory Entry Replication is enabled, *OFCSRV should be added prior to upgrade from v6.0.

QALWOBJRST *ALL

or

*ALWPGMADP

WRKSYSVAL QALWOBJRST

If not set correctly, software installation and fix installation processes will not function correctly and objects will not be able to be replicated from one system to another.

QALWUSRDMN *ALL WRKSYSVAL QALWUSRDMN

For iTERA to function on a system with the security level set at 30 or above, the QALWUSRDMN (allow user domain objects in libraries) system value must be set to *ALL or have the product library and any data library names added to the list of libraries for the system value. The installation process will add the product library and data library names to the system QALWUSRDMN value if it is not set to *ALL.

*ALL for this system value indicates that all libraries on the system may contain user domain versions of *USRxxx objects. Specifying *ALL also includes *DIR.

QVFYOBJRST 1 WRKSYSVAL QVFYOBJRST

Setting this system value to 1 allows all user objects to be restored, regardless of their signature. Other values may prevent some user objects from being restoring, thus creating an out-of-sync condition.

System SettingRequired (or minimum) Settings


Notes


• Do not replicate the ITERAOWNER, MIMIXOWN, or LAKEVIEW user profiles.

• Do not place user created objects or programs in the iTERA product library, LAKEVIEW, MIMIXQGPL, or VSI001LIB libraries, or in the IFS location /visionsolutions/http/vsisvr. 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.

• QTEMP cannot be in the system portion of the library list. For additional details on setting up the library list, refer to the topic Using best practices to set up a library list in the Using License Manager book, available on Support Central.

• QSYS2 must be in the system portion of the library list. For additional details on setting up the library list, refer to the topic Using best practices to set up a library list in the Using License Manager book, available on Support Central.

• Review Technical Alerts which can be found at Support Central in the Notifications section of the Customer Care page. From Support Central, click the CustomerCare tab, click iTERA Availability from the drop-down list, click the Notifications tab. Ensure version 6.2 is displayed in the product version drop-down box.


http://portal.visionsolutions.com/default.aspx

version 6.2 service pack 6.2.03 - vision...

Documents