Itera Library Changes

Read This First

Version 6.1 Service Pack 6.1.03.00

New installation and upgrade procedures The iTERA installation and upgrade processes have been aligned with other Vision products. The changes allow for a common install and upgrade experience across product lines.Vision Solutions strongly recommends that you use the iTERA Installation Wizard to install version 6.1. (Read more about the changes on page 10.) Support 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.1. 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 also easily and automatically obtains and applies license keys via Vision AutoValidate™. Note: This Readme document provides 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.0 to v6.1, use the iTERA Availability v6.1 Upgrade Guide. It contains instructions for performing a v6.0 to v6.1 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.

Action required The 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. “Install iTERA Service Pack” on page 3 “After installing” on page 3

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

Important changes You 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 6.1.03.00” on page 5. • To review the features included in iTERA Availability version 6.1 see “Highlights Version 6.1 Service Pack 6.1.01.00” on page 10.

Superseded This service pack includes the contents of all previous v6.1 service packs (including cumulative fix packs). If you do not already have the following service pack installed, its contents are also installed when you install service pack 6.1.03.00. To see highlights and additional fixes for a superseded service pack, click on the link. 6.1.02.00 - Highlights and fixes 6.1.01.00 - Highlights and fixes

6.1.03.00 © Copyright 2002, 2013 Vision Solutions, Inc. All rights reserved. 2 Installation Instructions Install iTERA Service Pack These instructions are for installing the product via the Installation Wizard. 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. 1. Prior to initial iTERA v6.1 installation (or upgrade from v6.0), you were instructed to ensure your systems met either recommended or required settings for correct iTERA operation. If settings have changed on your systems, review the “System Requirements” section and ensure your systems are in compliance. 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.1 is displayed in the Version drop-down box. 4. Click the file 6.1.03.00: Wizard on IBM i and save the file to your PC. 5. After the save has completed but before executing the wizard, execute E2ENDSBS on any node (ends the iTERA subsystem on all nodes). 6. Launch the iTERA Installation Wizard by clicking the executable (.exe) file that you downloaded in Step 4. 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. 7. Continue to advance through the wizard’s screens, following all on-screen instructions carefully. When finished, close the wizard. 8. Log on to the primary node using the iTERA admin profile. 9. Execute the command E2STRSBS to start the iTERA subsystems. Note: E2STRSBS now starts the subsystems on all nodes. (See “2.12 E2STRSBS and 2.13 E2ENDSBS command changes” on page 11 for additional details.)

After installing Perform 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 6.1 Reference Guide). If there are issues, execute the steps on the Monitoring Checklist, located in the iTERA Availability 6.1 User Guide, to troubleshoot and resolve. Special instructions are listed below by service pack. It is necessary to perform any special instructions provided for service packs that were yet not installed when you started this process. Perform any actions

6.1.03.00 © Copyright 2002, 2013 Vision Solutions, Inc. All rights reserved. 3 After installing necessary for your environment after installing. (You can skip special instructions for service packs previously installed on your system.) 6.1.02.00 Enable automatic audit recovery policy ...... 6 Enable xx_VLDIFS jobs...... 6

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

Fixes included in service pack 6.1.03.00

ITHA-9413 Apply job log no longer shows MCH3601 with certain file operations.

ITHA-9659 Updated the Library Syncing Status screen (4.12) to correctly display NetSend as the remote library status while the library is being sent to the target.

ITHA-9663 Improved handling for journal at birth objects that are also filtered.

ITHA-9667 Resolved an issue that caused HAE0574 in E2MSGLOG.

ITHA-9672 Start IFS mirroring now starts journaling on the target to the assigned journal when the object is journaled to a different journal than its parent directory.

ITHA-9675 CRG names are now validated for correctness during the 6.0 to 6.1 upgrade.

ITHA-9679 Apply job will no longer fail when CPF9803 message is received.

ITHA-9684 Vision audits now start journaling and resync directories efficiently.

ITHA-9690 Improved the method for calculating the Journal Entries Not Applied field in the System Monitor (1.1).

ITHA-9692 Corrected date routine in the E2MSGLOG when viewing message log detail.

ITHA-9705 System Monitor Page Down (1.1) now correctly retrieves the latest service pack information.

ITHA-9745 Improved processing of files that encounter CPF5090 errors and incorrectly remain on the Objects Requesting Sync screen.

ITHA-9752 4.30 authorization lists (*AUTL) now replicate correctly.

ITHA-9829 Vision audits no longer fail with MCH0601 when processing a large number of library objects.

ITHA-9831 Configuration settings in the Replication Options screen (30.23) are now retained after 6.0 to 6.1 upgrade.

ITHA-9865 #IFSATR and #DLOATR audits no longer show *NC after changing objects to a different journal.

ITHA-9894 Disabled IFS tape sync functionality. This will be restored in a future service pack. For additional details, refer to Technical Alert TA_IT6.1_033_IFS_Tape_Sync_Issue.

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 software. xx_VLDIFS now appropriately detects FID mismatches

IFS validation program 2.21 xx_VLDIFS now appropriately detects FID mismatches. (ITHA-9631, ITHA-9685, ITHA-9686) Action required: If you disabled the xx_VDLIFS jobs in 2.21 (as indicated in TA-IT-030- Temporarily_Disable_xx_VLDIFS_Jobs) and have not yet reenabled them, enable them by executing the following the instructions: 1. From the iTERA Main Menu on the primary node, select 2.21 to access the Job Monitor Maintenance screen. 2. Next to each xx_VLDIFS job, selection option 2=Change. 3. For the Run parameter, change the value to Y and press enter. 4. On the Job Monitor Maintenance screen, verify that the scheduled xx_VLDIFS jobs are shown with a Run value of Yes.

Performance issue for #IFSATR and #DLOATR recovery resolved

Resolved a performance issue with automatic recovery via the #IFSATR and #DLOATR audits for detected IFS and DLO attribute mismatch. (ITHA-9666) Action required: If you disabled the Automatic audit recovery policy for the #IFSATR and #DLOATR audits (as indicated in TA-IT-028-Temporarily_Disable_Audit_Recoveries) and have not yet reenabled it, do the following to set the Automatic audit recovery policy back to adopt the installation-level policy of *INST. Note: *INST matches what is globally defined for the SETPCY command. The default value for SETPCY is *ENABLED. Therefore, setting an individual audit to *INST adopts the installation policy value, which, by default, is to enable automatic audit recovery. 1. From the iTERA Main Menu on the target system, select 1.8 to access the Audit Command Console. 2. Press F2=Vision Audits. 3. Press F10 one or more times until the Audit Summary view of the Work with Audits screen is displayed. (In the Audit Summary view, the Audit Rule column is the first column on the left

side of the screen.) 4. For each #IFSATR and #DLOATR audit, select option 36=Change DG policies, then press Enter. 5. Type *INST for the Automatic audit recovery parameter, then press Enter.

Fixes included in service pack 6.1.02.00

ITHA-1978 Notification that a virtual role swap is in progress is now also displayed on the iTERA main menu on the primary.

ITHA-3430 When creating a new journal (3.1, F6) use of the same journal receiver name prefix by more than one journal is no longer permitted.

ITHA-9458 *STMF objects in the IFS root directory now have journaling started on the target system.

ITHA-9546 Improved message handling within MRRDWNJOB and MRRENDJOB command processing.

ITHA-9547 Message HAE0587 in E2MSGLOG will show the job that has the member locked.

ITHA-9575 When submitting jobs, the job description library list will now be used.

ITHA-9576 Information about a directory entry is deleted when the directory entry is deleted (5.7).

ITHA-9586 CPF5006 no longer occurring in joblog during Role Swap when F5=Refresh is pressed on the Role Swap error screen.

ITHA-9590 In Job Scheduler Replication (5.5), individual job settings now always take precedence over map entries.

ITHA-9610 IFS and DLO objects that are replicated to multiple systems are now correctly selected with the #IFSATR and #DLOATR audits.

ITHA-9650 xx_RPTREP is no longer using excessive CPU.

ITHA-9676 Corrected an intermittent error, SQL0206 “Column not found”, that was occurring during the v6.0 to v6.1 upgrade.

ITHA-9677 #IFSATR and #DLOATR audits no longer incorrectly report objects as not found on the target system.

ITHA-9689 #IFSATR and #DLOATR automatic recovery processing now appropriately updates the IFS and DLO configuration files.

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

Fixes included in service pack 6.1.01.00

ITHA-8791 Failovers will no longer go into *MSGW if remote receivers are missing for a journal.

ITHA-9400 A file with a clear data filter will be resynced when a member is renamed.

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

Installation and configuration-related changes The iTERA installation and upgrade processes have been aligned with other Vision products. License Manager is now installed whenever iTERA is installed. The changes allow for a common install and upgrade experience across product lines. Features of these changes include: • Multiple installations of the product software on a system are now allowed. Each installation participates in a replication environment independent from other installations on the same system. • Two nodes are required for a standard primary to backup replication configuration. (An additional node is permitted in the replication environment and that node may be defined as either an additional backup or as a replicate node.) • iTERA v6.1 supports upgrades from iTERA v6.0 only. Customers using an earlier version of the product must first upgrade to iTERA v6.0. • When an upgrade from v6.0 is performed, all CRGs within the existing v6.0 installation are automatically upgraded to separate v6.1 installations. Naming conventions are adopted from the v6.0 CRGs for library names, CRG name, Admin profile, etc. Running iTERA v6.0 (and earlier) and v6.1 on the same system is not supported. • An installation must be at the same product level on all systems. • iTERA v6.1 can be installed via the iTERA Installation Wizard (recommended) or through a secondary procedure using License Manager via a 5250 emulator session. – This Readme document provides instructions for installing service pack updates using the wizard. – The iTERA Availability v6.1 Upgrade Guide contains instructions for performing a v6.0 to v6.1 upgrade using either the installation wizard or a 5250 emulator using License Manager. – New product installations are performed by our Professional Services team and Certified Business Partners using documentation prepared for that purpose. – The Using License Manager book provides instructions for iTERA operators who must use the installation and license key support provided by License Manager.) In addition, License Manager: • Provides a common location from which to access and maintain multiple installations of Vision Solutions products • Manages license keys for installed Vision Solutions products

• Installs software and fixes for Vision Solutions products using secondary processes from a command line • Exists in the LAKEVIEW library • Supports prior versions of products that use License Manager technology. The iTERA menu option 10.44 displays License Manager’s Vision Solutions Installed Products screen (options 6, 9, and 13 are valid for iTERA); option 9 on License Manager displays the License Manager Main Menu screen (options 1 and 2 and 30 are valid for iTERA)

INSPRD requirements for new installs The Install tool (INSPRD) in License Manager is for users who are installing from a streamfile (STMF). Action required: If you will be using 5250 emulator processes to create a new installation of iTERA 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. The installation procedures in the Using License Manager book describe how to make the INSPRD tool ready to use and when to use it. Note: You must complete all installation pre-requisites contained in this Readme document prior to using the INSPRD tool (see “Install iTERA Service Pack” on page 3) as well as the appropriate configuration and/or upgrade steps in “After installing” on page 5.

2.12 E2STRSBS and 2.13 E2ENDSBS command changes A new parameter on the E2STRSBS and E2ENDSBS commands (System) controls the behavior for starting and ending the iTERA subsystems. The default setting for the commands is to start or end the subsystems on all nodes in the replication environment in the correct order. The commands take longer to complete than the same commands in v6.0. The extra processing time is normal and is due to the need to start or end the necessary subsystems and jobs on each node. This ensures that your iTERA environment is completely started or ended before the command completes. The table below describes the available command parameters and their respective behaviors. Note: Command parameters are reset to the default whenever a new service pack is installed.

Table 1. Start and end subsystem command behaviors

SYSTEM E2STRSBS E2ENDSBS Parameter Val- ues

*ALL Starts the iTERA subsystem for all Ends the iTERA subsystem for all (Default) nodes in the replication environment; all nodes in the replication environment; targets first, then primary. primary first, then all targets. The command waits until the OBJMON1 The command waits until the job is active before advancing to the subsystem is ended before advancing next node. to the next node. It is not necessary to specify the System It is not necessary to specify the parameter on the command, unless the System parameter on the command, default has been changed. unless the default has been changed.

Table 1. Start and end subsystem command behaviors

SYSTEM E2STRSBS E2ENDSBS Parameter Val- ues

*LOCAL Starts the iTERA subsystem only on the Ends the iTERA subsystem only on local node (the system on which it is the local node (the system on which it executed). is executed). The command waits until the OBJMON1 The command waits until the job is active before ending. subsystem is ended before ending. Command example: Command example: E2STRSBS SYS(*LOCAL) E2ENDSBS SYS(*LOCAL) [System Name] Starts the iTERA subsystem on the Ends the iTERA subsystem on the specified node. specified node. The command waits until the OBJMON1 The command waits until the job is active before ending. subsystem is ended on that system Command example: before ending. E2STRSBS SYS(SYSTEM1) Command example: (where “SYSTEM1” is the system E2ENDSBS SYS(SYSTEM1) name) (where “SYSTEM1” is the system name)

*NOCHK Starts the iTERA subsystem on the Ends the iTERA subsystem on the specified node. The command does not local node only and then ends wait until the OBJMON1 job is active immediately, without waiting for the before ending. subsystem to end.

Note: Initiating the command E2STRSBS will also start the MIMIXSBS subsystem. When the E2ENDSBS command is executed, iTERA automatically detects if there are multiple installations dependent upon MIMIXSBS and only ends it if there are no others. MIMIXSBS should not be ended if there are multiple installations of iTERA or other products that use MIMIXSBS that reside on the same system. MIMIXSBS does not generally need to be ended when performing various types of processing, such as a role swap. See “Auditing Subsystem - MIMIXSBS” on page 15 for additional details. iTERA Library Changes The base iTERA product library now contains the Journal Manager and iTERA Alert objects. Separate libraries for those features have been eliminated.

6.1.01.00 (Included with 6.1.03.00) © Copyright 2002, 2013 Vision Solutions, Inc. All rights reserved. 12 iTERA Menu Changes iTERA Menu Changes New options have been added and some existing options have changed or been removed in several iTERA menus. These changes support new functionality in version 6.1.

Table 2. iTERA menu changes

Menu Description Details Option

1.11 Multi System Monitor Renamed from Cluster Host Monitor

1.22 Review Record Count Audit (Backup) Replaced with #FILDTA audit

1.23 Review Object Attribute Audit Replaced with #OBJATR and #FILATR audits. (Backup)

1.50.10 Heal Status Option removed

1.50.14 Device Existence Test Previously, this test was only available via 5.4 F10, opt 11.

1.50.15 Job Sched Existence Text Previously, this test was only available via 5.3 F10, opt 11.

1.50.16 Directory Entry Existence Test Previously, this test was only available via 5.7 F10, opt 11.

2.25 Start Comm Apply Jobs New. This option starts the apply jobs for communications journals that run on the primary node. See “Communications Journals” on page 21 for information on communications journals.

3.6 Journal Apply Statistics Previously, this option was only available on the target.

3.32 iTERA Managed Journals Renamed from JRM Managed Journals

3.33 JRM Job Schedule Entry Removed; the Journal Manager job now runs in the iTERA Subsystem. See “3.33 JRM Job Schedule Entry eliminated” on page 25 for additional details.

4.10 Library Group AutoSync Renamed from System Library AutoSync.

4.61 Audit Exclusions Renamed from Audit Exceptions.

4.63 Role Test Exceptions Removed; previously, 4.63 F7 accessed the Virtual Role Change Log. This log is now accessible only from 40.30, F19.

10.40 Display iTERA HA PTFs (7PA2K05) Removed; iTERA updates are no longer performed using 10.41 Display XP PTFs (7PA2K02) IBM-style PTFs. Service pack installation instructions are 10.42 Display IT Alert PTFs (7PA2K25) contained within this document. 10.45 Retrieve and/or Install iTera PTFs (P 10.46 Retrieve and/or Install XP PTFs (P) 10.47 Retrieve and/or Install Alert PTFs (P

Table 2. iTERA menu changes

Menu Description Details Option

10.44 Product Information Displays the “Vision Solutions Installed Products” screen and is also accessed via the WRKPRD command. The installed product version and service pack level are accessed through option 6=About version and product installation history through option 13=Display history. See “10.44 Product Information” on page 31 for additional details. Documentation for other functionality on this screen is in the Using License Manager book.

10.51 File Retention Moved from 50.11 Files.

10.52 Reorganize Files New. For details, see “10.52 Reorganize Files (E2RGZPFM)” on page 32.

30.1 System Information Previously was iTERA HA Licenses. See “30.1 System Information” on page 33.

30.24 Multi System Monitor Configuration Renamed from Cluster Host Monitor Configuration. See also “30.24 Multi System Monitor Configuration” on page 33.

30.50 Cluster Menu Removed

40.1 End jobs Pre-Role Swap Renamed from “End iTERA HA Subsystem Jobs”.

40.2 Start Jobs Renamed from “Start iTERA HA Subsystem Jobs”.

50.11 Files Moved to 10.51 File Retention

1.1 System Monitor The Journal Entries Not Applied field will now display a plus sign (+) if there are more entries than can be displayed in the field. The % Total Disk Storage Used By Receivers field now includes for each node the percent of total disk storage used by both the journal receivers for journals defined to iTERA and for QAUDJRN.

1.1 F11=Message Log, F10=Problem Log A Problem Log has been added to the iTERA Message Log screen (accessed via 1.1 F11 or E2MSGLOG, F10=Problem Log key). Note: The problem log is used to provide additional information when troubleshooting product issues. If an issue occurs in your environment, contact CustomerCare for assistance with using the problem log. When a problem is logged a problem library is created. If multiple problems are reported for the same job the occurrences of the problem are added to the log file. The information collected includes: • The joblog (DSPJOBLOG of the job).

• Job information, including call stack, file open, and file overrides (DSPJOB of the job). • OS version and system values for all systems in the CRG. • The product version and service pack level. • Information about the problem collected at the time the problem is logged. • A copy of the transaction file, if applicable, based on the job name. • If a journal is being used then a file with 1000 entries before the problem and 1000 after. • Other files as needed, if defined in the message. • Other items manually added to the problem library. Logging behavior for an individual message is controlled by selecting option 2=Change on a message in the Message Routing screen (E2MSGLOG, F8, 2=Change). Messages can now be sent to iTERA Alert based on severity.

1.1 F16=Process Monitor The Exposed Entries and Apply Pending fields will now display a plus sign (+) if there are more entries than can be displayed in the field.

1.4 Object Monitor The IFS fields at the bottom of the screen are now displayed only if IFS Replication is enabled in the Replication Options (30.23) screen.

1.6 Audit changes and enhancements The auditing capability within iTERA has changed significantly, and has been enhanced to provide similar capability as found in the MIMIX products. The WRKAUD command displays the auditing interface. This command can be accessed from the Audit Command Console via the F2=Vision Audits key. The new audits replace many of the audits in the Audit Command Console.

Auditing Subsystem - MIMIXSBS Auditing technology in iTERA utilizes architecture from the MIMIX line of products. The audits that are managed under the WRKAUD command run in the MIMIXSBS subsystem. There is only one MIMIXSBS per system, regardless of the number of iTERA product installations or of other products that use MIMIXSBS. See “2.12 E2STRSBS and 2.13 E2ENDSBS command changes” on page 11 for additional details.

1.7 Role Swap Readiness Monitor changes The tests in the Role Swap Readiness Monitor have been consolidated into seven categories: • AUDIT - Audits • COMM - Communication • DATA - Data Replication

• IFS - IFS Replication • NONLIB - Non Library processing • OBJ - Object Replication • SETUP - Setup • WRKMGT - Work Management Duplicate tests have been removed and some tests were consolidated and combined. Obsolete options and functions have been removed.

LTIAS41 PRIMARY iTERA Availability 6.1 E21550S1 ZHA61A1 Role Swap Readiness Monitor 3/05/12 QPADEV0002 Pri Tgt Last Test 14:13:47 Summary Status ...... Err Err 2012-03-05-14.11.22.401000 Type options, press Enter. 1=Work with 2=Change Test 5=Test Results 7=Run Test 8=Submit Test 9=Resolve 11=Expand 12=Compress Search for

Sts Sts Opt Test Description Pri Tgt Results AUDIT Audit Err Err Audit SYSV_AUDP Error COMM Communications OK OK DATA Data Replication OK OK IFS IFS Integrated File Syst OK OK NONLIB Non-library Processing OK OK OBJ Object Replication OK OK SETUP Setup OK OK WRKMGT Work Manangement OK OK

BOTTOM F3=Exit F5=Refresh F7=E2SBS F8=E2MSGLOG F10=WRKJOBQ F13=Repeat F16=Expand/Compress F18=Submit All Tests F20=Control F24=More keys

Option 11=Expand is used to display the tests within each category and option 12=Compress collapses the view for a selected category. F16=Expand/Compress toggles the view between displaying all tests and displaying only the test categories.

The following screen shows the Role Swap Readiness Monitor with all test categories expanded.

LTIAS41 PRIMARY iTERA Availability 6.1 E21550S1 ZHA61A1 Role Swap Readiness Monitor 3/14/12 QPADEV0002 Pri Tgt Last Test 17:10:36 Summary Status ...... Wrn Wrn 2012-03-14-17.09.11.139000 Type options, press Enter. 1=Work with 2=Change Test 5=Test Results 7=Run Test 8=Submit Test 9=Resolve 11=Expand 12=Compress Search for

Sts Sts Opt Test Description Pri Tgt Results AUDIT Audit Wrn Wrn AUDIT Audit Monitor Wrn Wrn Audit console not turned on COMM Communications OK OK DDM DDM Test OK OK FTP FTP Test OK OK IPCONWRN IP Connection Warnings OK N/A PING Ping Test OK OK DATA Data Replication OK OK ACCEL Accelerator N/A OK MORE... F3=Exit F5=Refresh F7=E2SBS F8=E2MSGLOG F10=WRKJOBQ F13=Repeat F16=Expand/Compress F18=Submit All Tests F20=Control F24=More keys

Additional details about the Role Swap Readiness Monitor are available in both the User and Reference Guides.

1.11 Multi System Monitor New commands are available for configuring the Multi System Monitor (formerly called the Cluster Host Monitor). Instructions for configuration and use are documented in the iTERA Availability v6.1 Advanced Features Guide. Note: Monitoring is supported both for v6.1 installations and for systems running iTERA HA v6.0; however the Host system must be running iTERA Availability v6.1. Special configuration is required in order to monitor v6.0 systems.

2.21 Job Monitor Maintenance changes Changes to the Job Monitor Maintenance screen eliminate the need to create separate job schedule entries for performing various maintenance tasks. In v6.0, these jobs were called E2CLRSNCOB, IFSPRGA, and E2SYNCNML. These processes are now managed in the Job Monitor Maintenance screen and appear as xx_CLRSNCO, xx_IFSPRG, and xx_SNCNML. Additional details are described below. The jobs run automatically in the iTERA subsystem, based on the defined parameters. New scheduled jobs The new jobs in the job monitor (including jobs that previously existed in various areas of the product) are described in this section.

xx_CLRSNCO This job performs a daily clean up of data queues, save files, and purge of heal records. Set the time of day for the job to run using option 2=Change on the job. Action Required: Use option 21=Additional Attributes on the job name to review the four additional parameters for this job. Change the settings, as necessary. • Retention Days - DTAQs. Specify the number of days data queues will be retained. • Retention Days - SAVFs. Specify the number of days save files will be retained. • Purge Heal Records. Specify Y (the recommended default) to purge processed heal records, N to retain them. • Retention Days - Heal Records. Set this value higher if doing problem determination.

xx_IFSPRG Purges IFS audit history. Action Required: Use Option 21=Additional Attributes on the job name to review the two additional parameters for this job. change the settings, as needed. • Keep Days - Indicate the number of days worth of audit history to be retained. • Keep Fail Days - Indicate the number of days worth of audit history that include reported audit failures that are to be retained. Note: This job is displayed and enabled only when IFS Replication is enabled in 30.23.

xx_SNCNML Action Required: The default setting for this job is to sync all non-mirrored library definitions. To better control the flow of synchronization, it may be helpful to copy this job (option 3=Copy) and then modify the library parameter in the command to limit the number of libraries that will be synced at a time. Library groups may also be specified in a definition (4.30, F6) and then used in the third parameter of the command.

xx_APRMON Monitors the operating system for completion of unique key access path rebuild, then notifies the apply job that it can process the journal entries for files.

xx_CSTANZ Analyzes the system for constraints and loads the 4.24 screen with the ones that iTERA can manage.

xx_CHKOBJM If data area ALWDLT is set to Y (the default), then any objects that exist on the target that do not exist on the primary will be deleted. This includes the removal of objects that are filtered through 4.20 with an Omit Type of 1=RMTDLT. Note: This job replaces some functionality of the Check Object Match (CHKOBJMTCH) audit, which has been removed from the Audit Command Console. It only checks object existence. It does not check any object attributes, which are now handled via other auditing processes.

xx_JOBMON In previous releases, xx_JOBMON ran in the E2SYSJOBQ. This job periodically checks the subsystem and restarts any jobs that should be running. It also submits the periodic jobs based upon the time defined in the 2.21 screen.

xx_JRNMGT The xx_JRNMGT job ensures that the Journal Manager is running. In previous iTERA releases, the Journal Manager job was scheduled via the 3.33 screen. That option has been removed.

xx_OBJMON4 The IFS processing that was previously handled by the xx_OBJMON1 job is now handled by xx_OBJMON4.

xx_PRGLOG Deletes any records found in history and log files older that the retention period. Use the 10.51 screen to review or change the retention period.

xx_SYSINFO Used in the auditing process to monitor the system and track potential issues.

xx_TRGANZ Analyzes the system for triggers and loads them in the 4.23 screen.

xx_TRNEXT Provides pass-through processing to off load long running jobs. Eliminates special setup for multiple nodes. Used by the OBJSNCSTS audit.

xx_USRANZ Collects user profile information.

xx_VLDIFS There are many situations where IFS configuration records become invalid, including but not limited to: removing a node, doing a save/restore of replicated IFS objects, an obsolete CRG due to its removal during 6.0 to 6.1 upgrade, a blank FID, the object does not exist but the record exists. This test validates the IFS configuration by verifying the following are valid: node code, CRG, object’s FID, parent’s FID, and journal assignments. Obsolete records are deleted. This job is displayed and enabled only when IFS Replication is enabled in 30.23.

2.21 Screen changes A summary of the new and changed functionality on this screen appears below. Consult the User and Reference Guides for additional details.

LTIAS41 PRIMARY iTERA Availability 6.1 E23550S1 ZHA61A1 Job Monitor Maintenance 3/05/12 QPADEV0002 17:37:34 Type options, press Enter. Display . . . Active 1=Work with App 2=Change 3=Copy 4=Delete 7=Rename 9=Toggle Run 10=Submit Immediately 11=End job 12=End/Restart Job 15=Job Attributes ... Position to Search for

Job Execute Start iTERA Opt Name System Run Option Interval SMTWTFS Time Defn HA_APRBMON TARGET Yes *ALWAYS Yes HA_AUDMON SOURCE Yes *ALWAYS Yes HA_AUDMON TARGET Yes *ALWAYS Yes HA_CHK_Z_ TARGET Yes *ALWAYS Yes HA_CHKOBJM SOURCE Yes *DAY NNNNNNY 18:00 Yes HA_CLRSNCO SOURCE Yes *DAY YYYYYYY 1:15 Yes HA_CSTANZ SOURCE Yes *DAY YYYYYYY 1:10 Yes HA_DEVREP SOURCE Yes *DEV *ALWAYS Yes HA_DIRREP SOURCE Yes *DIRE *ALWAYS Yes HA_HEAL+++ SOURCE Yes *ALWAYS Yes MORE... F3=Exit F7=Toggle View F8=Job Control F13=Repeat F16=Display All/Active F18=CHGJOBD F19=CHGCLS F20=Job Attributes F23=More options F24=More keys

Option changes: • 1=Work with App. Displays the associated program, if any, for the selected job. • 21=Additional Attributes. Valid only for the xx_CLRSNCO and xx_IFSPRG jobs. Field changes: • Run - Indicates the job is eligible to run in the subsystem. Note: Vision strongly discourages disabling jobs that have *ALWAYS specified for the Interval. Disabling a required job may affect the software’s ability to function as designed. • Option - Indicates the component or replication option the job is associated with. The replication option must be enabled in the 30.23 screen in order for the associated jobs to be displayed on this screen. • Interval - Indicates the frequency that the job will run. – *ALWAYS - The job is always running in the iTERA subsystem. – *DAY - The job runs on the days indicated in the Execute SMTWTFS field and at the time of day indicated in the Time field. – *TIME - The job runs at the interval indicated in the Execute SMTWTFS and in the Time field (e.g., if 2:00 is specified in the Time field then the job will run every two hours). • Execute SMTWTFS - A “Y” displayed in each position under the SMTWTFS column heading indicates the days of the week the job will run. Values are only applicable in this field if *DAY or *TIME is indicated for the Interval field. • Start Time - When *DAY is specified in the Interval field, the time specified in this field indicates the time of day, in twenty-four hour time format, that the job will run in the iTERA subsystem. When *TIME is specified in the Interval field, the time specified indicates how many hours may elapse before the job is again submitted. Function Key changes • F8=Job Control. • TODO: The Job Monitor run interval default for new installations is ten minutes. Upgraded installations should review this field and set accordingly, as desired. • History Collection Interval and Offset fields removed.

3.1 Local Journal Maintenance

Communications Journals Communications journals are support journals used to report status and other information between nodes, including heal requests, parameter updates, database updates, status changes, IFS replication status, etc. The originating node sends entries to all other nodes via the communications remote journal and the entries are read by the apply job for the journal, which then applies the entries. Communications journals, their remote journals and apply jobs are active in all directions on all nodes. (For communication from target to primary, their operational flow is the opposite direction from regular journals used in iTERA for replication.) In a two-node environment, two communications journals (and their related journal components, including the remote journals, local and remote journal receivers, and apply jobs) are created automatically. The journals are named xxC01A and xxC02A, where xx is the CRG code. The numeric portion of the communications journal names are the short node codes that identify the node to which the journal pertains. The two standard communications journals both end with the letter A. If additional communications journals are created (generally not needed) the journal pair will end with B, etc. If there is recurring latency on the active apply job, we recommend you discuss the issue with CustomerCare to determine whether another set of communications journals would be beneficial. (This could potentially occur on systems with a high volume of IFS objects being replicated.) The diagram below shows the communications pathway between primary-to-backup replication in a two node environment. The C01 journal sends information from Primary to Backup 1 and the C02 journal sends information from Backup 1 to Primary.

In a three node environment, there are three sets of communications journals. Each local journal will have a remote receive on each of the target nodes. The direction of communications for these journals is as follows: • The C01 journal on Primary sends information to both Backup 1 and Backup (or Replicate). • The C02 journal on Backup 1 sends information to both Primary and Backup 2 (or Replicate). • The C03 journal on Backup 2 (or Replicate) sends information to both Primary and Backup 1. The following diagram shows the flow of communications journals in a three node environment.

Default replication journal now created automatically When iTERA is installed and configured, a mirror journal for replication is automatically created and assigned as the default journal for replication in the Work with Libraries screen (4.11). Previously, the user had to manually create it then assign it as the default journal.

Load User Journals The key to load user journals is now F22=Load New User Journal. It was previously F8=Load New User Journal. The confirmation key was also renumbered from F8 to F22.

3.4 Apply Process Enhancements

Manual retention of receivers no longer needed for processing of Sync Data Queues In the past the receivers needed by the sync data queues were not protected, which resulted in having to hold the Journal Receiver Manager job (as well as other operations that would not have completed until the normal retention time of a receiver was exceeded) when a large object was synced or resynced. Additionally, because receivers are no longer held for journals not related to the resync operation the disk storage needed is reduced. Action Required: It is no longer required to hold the journal manager job when syncing large objects via network or tape. Updated instructions for performing object syncs are located in the User Guide.

Add records without creating a block of deleted records For performance reasons, with previous versions of iTERA, a block of deleted records was added to each file so that individual record inserts did not require the file to be extended. The performance penalty of extending the file for each insert was eliminated in the OS. iTERA v6.1 now no longer creates a block of deleted records.

Note: This change does not remove existing blocks of deleted records.

Library Rename In v6.0 and earlier when a library was renamed a resync was initiated and all objects in the library on the target were deleted then resynced to the renamed library. In v6.1 when a library is renamed, resync requests are eliminated by handling the rename request through the Object Monitor and the apply process. • For journaled objects, journal entries are generated for each object move request. • For non-journaled objects, the OBJMON2 job retrieves a list of the of the non-journaled objects in the renamed library and sends the list through the transport journal. The remote journal transport apply moves the objects from the original library to the renamed library. However, for objects that cannot be moved (for example, due to a lock), a resync will be initiated.

Automatic Heal Boost Heal requests are now automatically sent to the primary system using the new communications journal capability, thus dramatically decreasing the time required to satisfy the requests. The communications journal is automatically configured when the product is installed. In the past, customers who experienced a large number of heal requests (typically due to Virtual Role Swap or CRC Audit processing) could implement a manual process for increasing the rate at which heal requests were processed. This procedure was labor-intensive and required a high level of expertise to perform correctly. The new automatic method eliminates the manual procedure. It also eliminates the possibility of lock contention between the Heal process and the apply job.

Automatic Processing for Logical File Access Path Rebuild The process for handling logical file access path rebuild with unique key constraints is now fully automatic, which includes processing for the CPF5090 error message. This eliminates extra steps previously required for syncing large objects, which included holding the apply job, Object Sync Status test (OBJSNCSTS) in the Role Swap Readiness Monitor, Journal Manager job (XPJRNMGT), and the sync Job (xx_SNC_yyy). Action Required: Use the updated procedures in the iTERA Availability 6.1 User Guide to perform library and object syncs and resyncs.

New field “Assoc Comm Journal Suffix” added to 3.4 option 2 screen A new field, Assoc Comm Journal Suffix, has been added to the option 2=Change Job Attributes screen in Apply Job Maintenance (3.4). This field applies to non-comm journals only. The default value is blank. It is not likely that additional comm journals will be needed in order to handle maintenance processing for replication journals. However, if there is habitual latency in comm journal apply job processing, an additional comm journal may be created and maintenance processing for a replication journal may be sent through the added comm journal by specifying the suffix character of the new comm journal in this field. Consult with CustomerCare for assistance with creating an additional comm journal.

3.n - New options added to Journaling Maintenance Menu screens The following options have been added to the Journal Maintenance Menu screens, as indicated.

Option 10=Display Detailed Info The purpose of this option is to display journal receiver sequence numbers greater than ten digits in length. This option was added to the following screens: • 3.2 Journal Receiver Maintenance - all nodes; Last Seq field • 3.4 Apply Job Maintenance - all nodes; Next Seq to Process field • 3.5 Journal Entries Monitor - primary; Start Sequence and Current Sequence fields • 3.6 Journal Apply Statistics - target; Current Rmt Jrn Sequence and Apply Sequence fields • 3.8 Journal ZZ Job Statistics - target; Current Lcl Jrn Sequence and Verify Sequence fields

Option 15=WRKAUD This option appears on the 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, and 3.8 screens and displays the Work with Audits screen (WRKAUD) for only the audits associated with the selected journal.

Option 16=Libraries This option appears on the 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, and 3.8 screens and displays the Mirrored Libraries screen for the libraries being journaled by the journal. It is similar to the 4.11 Work with Libraries screen, however, some library management options have been excluded, System Architecture functions are available, and displayed fields are different. The default fields that are displayed are Library, Status, Size MB, and Text. When F7=Change View is pressed, many of the options that are displayed in the 4.11 option 2=Update Sync Defaults screen are displayed as fields. However, the primary functionality is the addition of the F20=Resync all objects key. All objects being journaled by the journal will be resynced. A confirmation key (F22=Continue) is required to complete the process.

Option 17=Objects This option appears on the 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, and 3.8 screens and displays the Mirrored Object Maintenance screen (Work with Mirrored Objects) with only the objects that are being mirrored by the journal. The screen is filtered based on objects in the journal’s associated data group. New functionality includes: • F20=Resync all objects - Resyncs all objects being journaled by the journal. A confirmation key (F22=Continue) is required to complete the process. • See “4.21 New options added” on page 27 for descriptions of additional functionality.

3.31 JRM Default Parameters changes The Journal Manager has been incorporated into the core iTERA product library. The ITXP43 library has been eliminated.

Changes to the Journal Manager eliminate potential conflicts and make it easier to coordinate multiple iTERA Availability, MIMIX® RecoverNowTM, and Vision DirectorTM installations as well as with other Vision, vendor, or user applications. A new parameter, Protect Receivers From Early Deletion, prevents deletion of journal receivers by users or other applications by using the OS receiver delete user exit program QIBM_QJO_DLT_JRNRCV. This exit calls each registered user exit program just prior to a receiver being deleted. If all the user exit programs return permission to delete, the OS allows the delete, otherwise, the deletion of the receiver is prohibited. Each installation of iTERA will register its own QIBM_QJO_DLT_JRNRCV user exit program. When called, the exit program will determine whether or not the receiver needs to be retained based on iTERA criteria. It is no longer required to access the Journal Manager screen on all nodes prior to creating the first journal.

LTIAS41 iTERA Availability 6.1 XPRCV211R ZHA61A1 Journal Manager 3/19/12 Default Parameters 17:24:30

Receiver Change Frequency ...... 120 Minutes Job Processing Frequency ...... 30 Minutes Receiver Retention ...... 25 Hours Delete W/O Save ...... Y Y=Yes, N=No Protect Receivers from Early Deletion . . . . . Y Y=Yes, N=No

F3=Exit F5=Refresh F12=Cancel

3.32 iTERA Managed Journals changes Action Required: If replicating WebSphere MQ, verify that the MQ journal is being managed by iTERA and that journal receivers will not be changed. Select menu option 3.32, select the MQ journal using option 2=Change, review the values specified for the Control Journal Management and Journal Change Frequency fields. If not already done, set them to Y and 99999, respectively, then press Enter.

3.33 JRM Job Schedule Entry eliminated The Journal Manager job is now managed through the 2.21 screen and runs in the iTERA subsystem. See also “xx_JRNMGT” on page 19.

4.10 Library Group AutoSync changes

Journal at Birth A new field, Manage Journal at Birth, and a new function key F19=Manage Journal at Birth, have been added. See “4.11, F19=Manage Journal at Birth” on page 26 for details. This field and function key appear in the following Library Group AutoSync screens:

• 4.10, opt 2 on a library; Journal at Birth field. • 4.10, F8, F19=Manage Journal at Birth • 4.10, F8, opt 2 on a definition, F8, Change Library Replication Defaults; Journal at Birth field.

F19=Change Library Inclusion F19=Change Library Inclusion. Displays the Parameter Update screen where the parameter LIBATOT may be changed. Library AutoSync, by default, only recognizes libraries defined as “New” in the 4.11 screen (F7=Toggle to the New Libraries Only view). If you need to create AutoSync definitions that include libraries for which the “New” status has been removed, set the “Include libraries in Auto” parameter to *ALL.

4.11 - New and changed options Option numbers have changed for 4=End Journaling, 14=Cancel Syncing, and 24=Remove CRG Assignment. • Option 14=Cancel Syncing is now 41=Cancel Syncing. It is executed on the primary. • Option 4=End Journaling is now 42=End Journaling. When executed on the primary, journaling is now ended on all nodes. • Option 24=Remove CRG Assignment is now 43=Remove CRG Assignment. When executed on the primary, the CRG assignment is removed on all nodes. The options now appear in numerical order, which is the order in which they are performed. • New: Option 44=Cancel/End All Repl - This option executes options 41, 42, and 43 on the correct node, in the correct order. Action Required: Refer to the “End replication for a mirrored library” procedure in the iTERA User Guide for instructions on using these options.

4.11, F19=Manage Journal at Birth Journal at Birth refers to the process of automatically starting journaling on objects newly created in a library. iTERA uses two methods to accomplish this, STRJRNLIB and QDFTJRN. When the STRJRNLIB command is executed on a library, or if the QDFTJRN data area exists in a library when a new object is created that is eligible to be journaled (such as a data area, data queue, or file) then as part of the create process, journaling will be started. The creation entry of that object is placed in the journal receiver, then the apply process uses that entry to create the object on the target system. Thus, the object will not require an initial sync. When set to *Yes, new installations will use STRJRNLIB if the OS is 6.1 and later, unless QDFTJRN exists in the library. This function globally starts or ends journaling at birth for all libraries. To change the sync default for an individual library, adjust the setting for the Journal at Birth field in Library Syncing Attributes screen (4.11, option 2). (Equivalent functionality exists for Library Group AutoSync (4.10).) Library-level configuration for journal at birth (4.11, opt 2, Journal at Birth field) values are: • A=Auto - When “A” is specified, and the iTERA Management Status in 4.11 F19 is set to *ON, then new objects added to the library will be journaled at birth. When set to *OFF, then new

objects added to the library will not be journaled at birth. • I=Ignore - Journaling at birth is not managed by iTERA. An existing QFTJRN data area will not be removed nor will STRJRNLIB or ENDJRNLIB be executed. • X=Delete - If the QDFTJRN data area exists in the library, it will be deleted. If the library is journaled, then the ENDJRNLIB command will be executed for the library. • Y=Yes - Journaling at birth will be started immediately.

4.20 Filter changes Objects being journaled by user journals are now eligible for filters where the filter type is “Include”. The Filter Level, Source Filter, and Target Filter (System Src Tgt) fields were removed. The functionality for these fields was never implemented in the product. Their removal has no impact on existing filters if they are being used.

4.21 New options added The following options are new: • 13=Compare File Data - Executes the #FILDTA audit for all objects being journaled by the journal. • 15=Attributes - Displays the equivalent of a DSPFD command for the object. • 16=DB Relation Sync - Deletes the file and all associated logicals and resyncs both the file and the logicals. • 17=Members - Displays a Member List screen, which includes a list of all associated members. The screen includes the following: – 6=Resync - Initiates a sync request for the selected member. – F7=Rebuild Information - Refreshes the screen with the latest member information. – F8=DSPFD - Executes the Display File Description command of the file. Note: The Mirrored Object Maintenance screen is also displayed when option 17 is selected from any of the Journal Maintenance Menu screens. See also “3.n - New options added to Journaling Maintenance Menu screens” on page 24.

4.24 now displays only *REFCST The Work with Constraints screen now shows only the constraints that can be managed by iTERA. Other constraint types are suppressed from view. To view all constraints, change the value for the CSTCTL parameter in the 10.50 screen to Y.

4.30 Non-mirrored Library Object Sync • The F20=Advanced screen was eliminated. The Auto Add, Auto Change, and Auto Delete fields are now all set to Y by default and can be managed via option 2=Change.

• The F6=Add screen includes a new Group field. A user may assign a group name to one or more definitions and then specify the group name in the Group parameter of the 4.31 SYNCNMLIB command or copy the xx_SNCNMLIB job in the 2.21 screen and specify the group name in the third parameter of the command.

4.32 SYNCOBJ is now E2SYNCOBJ The SYNCOBJ command accessed via 4.32 has been renamed to E2SYNCOBJ. The SYNCOBJ command still exists in the product, but has different parameters. It is now used by the Vision Audits to perform automatic object resyncs.

4.62 opt 2 - New field A new field, Replace Higher Audit Value was added. The QAUDJRN journal is used by iTERA to identify additions, changes, and deletions of objects. The entries recorded to the journal depends upon the audit level assigned to that object. For non-journaled objects an audit level of *CHANGE or higher is required for an entry to be added to the journal. For journaled objects changes are recorded through the data journal and these objects only need *NONE. Some objects such as *DTAQ may be set to *NONE as each entry to the data queue will also create a corresponding entry to QAUDJRN. In addition, QAUDJRN may be used for auditing purposes. This may require the auditing level to be set higher than what is required by iTERA. In previous versions, the user would need to change the audit level to the higher of the two values to retain the required audit level value. This is no longer the default. Now the product will by default keep the higher of the two values. There still may be times when an object should be set lower than the default. For example, if a *DTAQ (with *CHANGE or *ALL audit level) has 500 million entries added then 500 million entries will be added to QAUDJRN. Also for files (with *CHANGE or *ALL audit level) an entry is added each time it is opened. While this information may be useful for auditing purposes it is not used by iTERA. We also recommend that the system value QCRTOBJAUD be changed from *CHANGE to *NONE, provided you do not need the additional entries for auditing purposes. This will minimize the number of entries in QAUDJRN that are not needed. The extra entries will slow the apply and use up disk space.

5.1 User Profile Replication changes • User Profile Replication is no longer automatically started when a replication environment (CRG) is defined. Instructions for replicating user profiles are located in the iTERA Availability v6.1 User Guide. • Option 12=Mapping Conflicts has been removed. Since each CRG is now a separate installation of the product, iTERA does not cross-validate replication for user profiles. If you have more than one CRG replication environment, ensure that user profiles are not replicated by more than one of them. • New option 41=Cancel Sync. When this option is executed on a profile, the record for the profile is deleted from the iTERA file and a map entry with all parameters set to “No” is automatically added to the User Profile Mapping Search screen (5.1, F16=Dft Map). A notation is made for the map entry indicating Using option 21 on a profile that had previously

had replication ended will remove the map entry. • iTERA now supports replication for additional user profile attributes needed for integrated Windows server. However, because the OS does not provide notification to iTERA of changes to the integrated server attribute of a user profile (no entries are sent to QAUDJRN), additional handling is required to ensure profiles match between systems. On a regular basis, you must periodically use 5.1 F19=Quick Sync to re-replicate all profiles. A step has been added to the Weekly Tasks section of the Monitoring Checklist to remind you to do this. • The Date Password last changed parameter will no longer be changed when replicating user profiles. See instructions in the iTERA User Guide for additional information.

User Profile Replication Control screen changes (F20) • The exit program method was removed from the product. All changes are now processed by the OBJMON2 job. • The Controlling CRG field was removed because the installation methodology was changed. • The Transport Choice option was removed, since all user profile replication goes through the transport journal. • New options: 4=Delete profile, 14=Force Enable, 16=Force Disable, 21=Quick Sync Profile, 22=Quick Sync Password, and 41=Cancel Sync (added in 6.1.01.00). • 5.1, F16, Force Password field. When Yes is specified, then when option 21=Quick Sync or F19=Quick Sync are executed, the user profile password will be changed on the target, even if the password is disabled on the target. The default is set to No so that the Date Password Last Changed parameter for the profile will not be changed when a quick sync is performed. • Refer to the iTERA User Guide for replication instructions and to the iTERA Reference Guide for details.

LTIAS41 PRIMARY iTERA Availability 6.1 E26080S1 ZHA61A1 User Profile Search - CRG Profiles 10/16/12 QPADEV0001 Target System ...... LTIAS42 19:50:48

Type options, press Enter. 1=View 4=Disable 5=WRKUSRPRF 6=Enable 14=Force Disable 16=Force Enable 21=Quick Sync Profile 22=Quick Sync Password 41=Cancel Sync Position to Search for

Opt User Description Class Status Dis Sync Sts

Bottom F3=Exit F7=Toggle Views F8=WRKUSRPRF F10=More Functions F13=Repeat F15=Disable All F16=Dft Map F17=Enable Disabled Profiles F24=More keys

5.2 IFS

IFS Tape Sync A tape sync is now available for IFS objects. • Option 33=Select tape sync is used to prepare the IFS objects for tape sync. • F19=Submit tape sync save is used to initiate the tape save process. A confirmation window is first displayed, followed by a window on which the tape device and volume ID are specified. When the save to tape has completed the Status field in 5.2, opt 5 will display “On Tape”. • Menu 5.51, Restore IFS Sync From Tape, is available on the target node to restore the objects. Once objects are selected, a window is displayed with tape device and volume ID fields for specifying the location of the objects. Press F19=Submit Tape Restore to proceed. When the restore on the target is complete the 5.2 opt 5 Status field displays “Syncing”. instructions are documented in the iTERA Availability v6.1 User Guide in the IFS section of the Non-Library Replication chapter.

Auditing options All replicated IFS objects are automatically included in the new Vision Audits (see “6 Audit Changes” on page 31). However, if for some reason IFS objects should be excluded from auditing, options have been provided in IFS Replication to facilitate both removal and inclusion. The options are: • 16= Include in audit - An ADDDGIFSE or ADDDGDLOE command is issued for the item with a Process Type (*INCLUDE). The auditing entries can be managed from the WRKDGIFSE or WRKDGDLOE screens. • 17=Exclude from audit - An ADDDGIFSE or ADDDGDLOE command is issued for the item with a Process Type (*EXCLUDE). The auditing exclusions can be managed from the WRKDGIFSE or WRKDGDLOE screens.

IFS unapplied entries during failover The communications journal now processes the IFS jobs. This simplifies the IFS failover process and eliminates remote SQL updates. Primary system updates are now held in the journal receivers and not applied until the system is again functional.

5.3 F20 Spool File Control - screen simplified Several rarely used fields in the Report Replication Control screen were moved to the 10.50 Parameters screen (Advanced).Customers who need to use these advanced settings should contact CustomerCare for assistance.

5.5 Job Scheduler Replication

Replication to multiple target nodes now supported. Job Scheduler Replication is now supported for multiple target nodes. For new v6.1 installs, follow the instructions in the iTERA Availability v6.1 User Guide to replicate job schedule entries. (Instructions are also included for restricting replication to an additional target node.) If you are upgrading from v6.0 and replicated job schedule entries in that version, after the upgrade you will need to do the following in order to replicate to any additional nodes. 1. On all nodes, select menu option 30.23 and check or verify the following: • The Global State for Primary is ON. • The Local State for Backup 1 is ON. • The Local State on the additional target node (Backup 2 or Replicate) is OFF. 2. On the additional target node, if the Local State field is “Off” select option 16=Enable Local. (Do this on all additional target nodes on which you want job schedule entries replicated.) 3. Replicate job schedule entries as directed in the iTERA Availability v6.1 User Guide.

Potential for duplicate job schedule entries eliminated Job Schedule Replication processing has been enhanced to eliminate the potential for duplicate job schedule entries in multi-node environments after performing a role swap.

5.8 System Values Replication The Repl field has been changed and renamed to Repl/Status. The field now displays the status of replication.

6 Audit Changes The Vision Audits (F2 from the Audit Console or via the WRKAUD command) incorporate auditing technology from Vision’s MIMIX line of products. These audits replace several audits in the Audit Command Console, and have therefore been removed. Only audits for which there is not a Vision Audit replacement have been retained in the Audit Command Console. Audits from both the Vision Audits and the Audit Command Console must be run regularly in order to validate synchronicity between systems. Action Required: Review the auditing chapters in both the User and Reference Guides for a information relating to both the Audit Command Console changes and the instructions and details for the Vision Audits.

10.44 Product Information The Vision Solutions Installed Products screen provides access to options for working with installed products, including License Manager. Only options 6, 9, and 13 are valid for iTERA at this time. Documentation for working with License Manager is available in the Using License Manager book, available from Support Central.

Vision Solutions Installed Products System: LTIAS41 Type option, press Enter. 4=Uninstall 5=Display product authority 6=About version 9=Display product menu 13=Display history 30=Change product security 31=Grant product authority 32=Revoke product authority

Installation Installed Opt Product Library Version License Manager LAKEVIEW 7.0.97.00 iTERA Availability HA61A1 6.1.00.00

Bottom F3=Exit F4=Prompt F12=Cancel

10.50 Parameter Update The Parameters screen architecture has been changed and expanded to include parameters for replication control screens. • Valid values for each parameter are now displayed. • Default values are now specified for all parameters. • Parameters for replication features not enabled are not displayed. • The Scope field indicates whether a change to the value of the parameter will affect the other nodes in the environment. Global indicates that all nodes will be updated. Local indicates the change will only affect the node on which the change is made. Note: This screen should only be used under the direction of CustomerCare or if specifically instructed to do so within an authorized procedure.

10.52 Reorganize Files (E2RGZPFM) This new utility is used to remove deleted records found in files of the iTERA product library. Removing excess deleted records can improve performance. This option should be run on all nodes after the iTERA subsystems have been ended. Files in use will not be reorganized. Command defaults may be reviewed/changed in parameter RGZPRD in the Parameters screen (10.50). The setting for Reorganize on E2STRSBS may be set to Y to perform a reorg automatically just prior to starting the iTERA subsystems.

30.1 System Information This menu option displays the following information for the system: System serial number, processor feature code, processor group, LPAR number, and product version. This screen can also be displayed using the DSPSYSINF command.

30.21 Node Maintenance and 30.21 F7 Resource Groups redesigned The Node Maintenance and Resource Groups screens have been redesigned to provide a simpler interface for configuring the CRG, managing nodes, password changes, and the User IP address. Steps to define and configure the CRG appear in the Install Instructions section of this document. Field definitions, option and function key descriptions are located in the Reference Guide.

30.22 Work with TCP/IP Interfaces redesigned The Work with TCP/IP Interfaces screens have been redesigned to provide a simpler interface for working with the Replication IP and other IP addresses. Maps (fields and options used to manage them) are no longer needed and have been eliminated. Instructions for handling IP address changes are documented in the iTERA Availability v6.1 Advanced Features Guide. Field definitions, option and function key descriptions are located in the Reference Guide.

30.23 Replication Options When enabling components in the Replication Options screen, the jobs associated with the components are now immediately started. After enabling the component, it is no longer necessary to use option 8=Start replication, 2.21 Start Job Monitor, or recycle the subsystems (E2STRSBS).

30.24 Multi System Monitor Configuration See “1.11 Multi System Monitor” on page 17.

APIs The following APIs are documented in an appendix of the iTERA Reference Guide. • E2RTVROLE is a program that can be used to retrieve the role of the current system. • E2RTVRSR is a program that can be used to retrieve the current status of the Role Swap Readiness Monitor.

Command additions and changes • E2STRREP can be used to start replication for a library or object.

• E2ENDREP can be used to end replication for a library or object. • E2REPIFS can be used to start or end replication of IFS objects. • The E2HLDOUTQ and E2RLSOUTQ commands may be used in the role swap process to hold and release output queues. • The SNDRMTCMD commands has been renamed to E2SNDRMTC • E2CHGMAXS can be used to change the maximum network sync size.

E2.CUST renamed to E2_CUST The custom code library E2.CUST has been renamed to E2_CUST. Only programs relevant to v6.1 have been retained. If you used E2.CUST in v6.0, you should review and modify E2_CUST for your v6.1 environment.

Expanded Online Help Numerous F1 help panels have been added throughout the product. iTERA Alert library and subsystem eliminated The iTERA Alert product has been fully integrated into iTERA Availability, thus eliminating the separate ITALERT product library. The iTERA Alert jobs now run in the iTERA subsystem. Documentation for iTERA Alert is located in the Advanced Features Guide and the Reference Guide.

MAXOPT3 Support The Journal Parameter *MAXOPT3 is now fully supported. New journals are created with the *MAXOPT3 parameter.

MRRDWNJOB command changes A new parameter, Restart, has been added to the MRRDWNJOB command. Previously, the MRRDWNJOB command automatically ran the MRRRSTJOB command to restart the apply jobs. The Restart parameter now makes the execution of MRRRSTJOB an option. *YES is the command default. This command is documented in the iTERA Availability Advanced Features Guide. Note: The addition of this parameter makes the MRRENDJOB command obsolete. It will be removed in a future product release. Users currently using the MRRENDJOB command should transition to using the MRRDWNJOB command with *NO specified for the Restart parameter.

MRRRSTGRP - new command A new command, MRRRSTGRP, restarts the apply jobs for a group of journals. This command is documented in the Advanced Features Guide.

Product name change iTERA HA has been renamed to iTERA Availability.

QCRTOBJAUD no longer requires *CHANGE The setting of *CHANGE is no longer required for the system value QCRTOBJAUD. This may be set to *NONE, as desired.

Retrieve System Role API (E2RTVROLE) The E2RTVROLE API is used to identify the current role of the system and can be used in conjunction with a performing a particular function in a custom process. For example, if a process should be performed only on a particular node, custom code could include the following:

DCL &ROLE *CHAR 10

CALL E2RTVROLE &ROLE

IF (&ROLE = ‘PRIMARY’) THEN(DO)

[INSERT CODE]

ENDDO

V6R1 Audit removed The V6R1_AUDIT in the Audit Command Console was removed. If upgrading your OS to V6R1, follow the appropriate OS upgrade recommendations from IBM.

6.1.01.00 (Included with 6.1.03.00) © Copyright 2002, 2013 Vision Solutions, Inc. All rights reserved. 35 System Requirements The 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 6.1 for the first time or to upgrade iTERA to version 6.1. Each system in the replication environment must have this software installed and be current with the recommended PTFs and service packs applied. Refer to the Recommended OS Fixes page on Support Central. IBM licensed program products installed on the primary must also be installed on the target. Note: Upgrades to the latest service pack are supported from any version 6.1 service pack level.

Software Minimum level Notes

IBM i operating system IBM i 5.4 (V5R4M0) 1, 2

*COMPATIBLE or 3 Option 30 QSHELL *INSTALLED Option 33 Portable App Solutions Environment *COMPATIBLE 3

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

License Manager 6.0.00.00 or above 1

iTERA Availability 6.0 or above for 5, 6, 7 upgrades

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 primary 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. Required for IFS replication. 4. Required for iTERA Alert. 5. Upgrades from iTERA v6.0 are supported. If you are not at version 6.0 or above, you must upgrade to 6.0 before upgrading to version 6.1. 6. 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. 7. Upgrades to version 6.1 require license keys that are for version 6.1 only. New installs of version 6.1 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.

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

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

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

Other requirements The following TCP/IP servers must be running: FTP, DDM, TELNET, and REXEC. The REXEX server requires that port 512 be open. 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)

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

Required (or Command to System Setting display and/or Notes minimum) Settings change

Manage Receivers *SYSTEM WRKJRNA QSYS/ QAUDJRN is required for iTERA. In order for QAUDJRN iTERA to manage the QAUDJRN receivers, the CHGJRN Manage Receivers setting must be set to *SYSTEM. This setting will allow the system to Delete Receivers *NO WRKJRNA QSYS/ swap out journal receivers according to the QAUDJRN setting in the receivers. The *NO setting for CHGJRN 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..

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

Security 30 or higher WRKSYSVAL This is important for products that function QSECURITY between systems when assessing security requirements.

System Settings - Automatically Configured The 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.

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

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 *NOTEMP WRKSYSVAL This system value contains the on and off *OBJAUD QAUD* switches for object and user action auditing. iTERA replication requires that changes be *AUDLVL tracked through the QAUDJRN. *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. *NOQTEMP - indicates no auditing of objects in QTEMP.

QAUDENDACN *NOTIFY WRKSYSVAL This system value indicates the action that QAUD* 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.

QAUDFRCLVL *SYS WRKSYSVAL This system value indicates the number of QAUD* 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 WRKSYSVAL This system value controls the level of action *DELETE QAUD* auditing on the system. These settings track *OBJMGT changes and are required for system replication. *OFCSRV Check the IBM help feature for more *PRTDTA information on the changes that are tracked for *SAVRST each setting. (*SPLFDTA is only required if *SECURITY replicating spool files) *SPLFDTA *SYSMGT

QALWOBJRST *ALL WRKSYSVAL If not set correctly, software installation and fix or QALWOBJRST installation processes will not function correctly and objects will not be able to be replicated *ALWPGMADP from one system to another.

QALWUSRDMN *ALL WRKSYSVAL For iTERA to function on a system with the QALWUSRDMN 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. Specifying *ALL will prevent pointer errors associated with 30.21 opt C, from occurring. If the primary and all target nodes are on the same OS level then the system value QFRCCVNRST value may be changed without affecting iTERA.

QVFYOBJRST 1 WRKSYSVAL Setting this system value to 1 allows all user QVFYOBJRST 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.

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. • Do not replicate the ITERAOWNER, MIMIXOWN, or LAKEVIEW user profiles.

• Do not place user created objects or programs in the 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. • 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.