Guide to Vision iTERA Availablilty Monitoring · 2020. 11. 18. · Vision iTERA Availability Monitoring Vision iTERA Availability for IBM i provides business continuity for small

Guide to Vision iTERA Availability templates

CopyrightCopyright Halcyon - A Division of HelpSystems. All rights reserved. This document is intended as a guide to the Vision iTERA Availability monitoring templatesavailable with Halcyon software products for IBM i. This documentation contains Halcyon proprietary and confidential information and may not bedisclosed, used, or copied without the prior consent of Halcyon Software, or as set forth in theapplicable license agreement. Users are solely responsible for the proper use of the softwareand the application of the results obtained.Although Halcyon Software has tested the software and reviewed the documentation, the solewarranty for the software may be found in the applicable license agreement between HalcyonSoftware and the user.Publication Revision: June 2019

Overview Halcyon Templates are designed to provide the same level of monitoring across a number ofsimilar devices by applying a set of user-defined filters with a single-click. This greatly reducesset-up time and ensures all systems are covered by at least a basic level of monitoring. Should you need to make a system-wide change at a later date, a single update covers allsystems using the template.

C H A P T E R

CHAPTER 1INSTALLATIONIf you already use any of Halcyon's Level 1 to 4 software suites then followthese instructions to install templates to a customized environment on the IBM i. If you do not currently use Halcyon's tools in your IBM environment but wish tohave more information, an on-line demonstration or a free trial then please seethe list of contacts on the back page of this guide.

Installation of Customized EnvironmentFollow these instructions to install templates to a customized environment. 1 Install the Halcyon solution, using the appropriate installation guide.2 Once successfully installed, log into the environment to which you wish to

apply the customized template, for example, HALPROD/HALCYON.3 From the command line run ENDMON and press F4. Follow the prompts to

complete the ending of the monitors. Note: The installation of the customized environment fails if the monitors are not

stopped.

4 From the command line type CSTENV and press F4.5 Type the required authorization code for the template you wish to apply and

press Enter.

I n s t a l l a t i o n 1-1

Figure 1.1 Entering the customization code

Note: Each customized environment requires an authorization code. Please contact [email protected] or your local Halcyon reseller for details on how to obtain this code.

The Customized environment is now installed. 6 From the main menu of your Halcyon solution, select option 5=Work with

Rules. The template rules applicable to the customized environment that youinstalled can be found in the listed queue and rule groups. Default actionschedules are installed and additionally, where appropriate, changes tosystem defaults may also be made.

In most cases, the templates supplied can be used immediately uponcompletion of installation, but there may be instances where you need tochange rule properties to match those of your own environment. This can bedone by taking option 2=Change against the rule and making the requiredchanges. Similarly, should you require multiple rules for different messagequeues or devices and so on you can use option 3=Copy against the ruleand then make the required amendments.

1- 2 H a l c y o n T e m p l a t e s

mailto:[email protected]

Rule ActionsUnless otherwise specified, all template rules are implemented with a defaultaction schedule which sends an alert message to your local console (option10=Message Console from the main menu). Should you wish to amend thisoption, take option 2=Change against the action within the rule and make theamendments as required.

Note: Please refer to the user reference guide for your Halcyon solution for details of actions that may be applied to rules.

I n s t a l l a t i o n 1-3

C H A P T E R

CHAPTER 2VISION ITERA AVAILABILITYCUSTOMIZATION TEMPLATES

Vision iTERA Availability MonitoringVision iTERA Availability for IBM i provides business continuity for small tomedium business enterprises, virtually eliminating planned and unplanneddowntime by maintaining a real-time backup system that can quickly take overas the production system when required.Halcyon iTERA templates have been created to monitor iTERA versions 6.0,6.1 and 6.2. Apply the rules relevant to the version of Vision iTERA that you areusing.

Template AssignmentIn most cases, the templates supplied can be used immediately uponcompletion of installation, but there may be instances where you need tochange rule properties to match those of your own environment. This can bedone by taking option 2=Change against the rule and making the requiredchanges. Similarly, should you require multiple rules for different messagequeues or devices and so on you can use option 3=Copy against the rule andthen make the required amendments.

ActionsUnless otherwise specified, all template rules are implemented with a defaultaction schedule which sends an alert message to your local console (option10=Message Console from the main menu). Should you wish to amend thisoption, take option 2=Change against the action within the rule and make theamendments as required.

Note: Please refer to the user reference guide for your Halcyon solution for details of actions that may be applied to rules.


Message Queue RulesThere are three specialist iTERA Message Queue Rule Groups, eachcontaining a selection of rules to monitor v6.0, v6.1 and v6.2 iTERA messagequeues. Each of the rule groups contains identical rules but check a message queue in adifferent Library that relates to the version of iTERA installed on your system.

• iTERA v6.0 Message Queue Rules check E2MSGQ in library ITHAA1• iTERA v6.1 Message Queue Rules check E2MSGQ in library HA61A1• iTERA v6.2 Message Queue Rules check E2MSGQ in library HA62A1

Use the rules in the Message Queue Rule Group that apply to your installedversion of iTERA. The following rules are deemed as being critical to monitor to ensure stabilityand accuracy of the iTERA replication.

No Global Exclusions DefinedSequence number 0 is a special sequence number which cannot be deleted,even if you do not define any global exclusions for the named message queue. If you have messages that are to be totally excluded from any type of action,take option 2=Change against sequence 0 to define the exact criteria for theexclusion. If a global exclusion exists for a message, then none of the othersequence numbers for this message queue are searched for a match and noaction is taken.

Hard drives in system ASP are degradedWhen hard drives in system ASP become degraded, performance issues canarise with disk I/O while writing to disks, especially when journaling. This message rule, which operates on a 24/7 basis, monitors for messageHAE0189 being received in Message File E2MSGF within library ITERA.

Disk space exceeds error threshold RSR monitorThe RSR Monitor continuously shows you are ready to role swap. This message rule, which operates on a 24/7 basis, monitors to see if theavailable disk space exceeds the error threshold specified for the RSR Monitor.If so, message HAE0190 is generated and this is received in Message FileE2MSGF within library ITERA.

V i s i o n i T E R A A v a i l a b i l i t y C u s t o m i z a t i o n T e m p l a t e s 2-5

Disk space exceeds warning threshold RSR monitorThe RSR Monitor continuously shows you are ready to role swap. This message rule, which operates on a 24/7 basis, monitors to see if theavailable disk space exceeds the warning threshold specified for the RSRMonitor. If so, message HAE0191 is generated and this is received in MessageFile E2MSGF within library ITERA.

Disk space exceeds sysval thresholdWhen the disk space exceeds the System Value threshold, the system starts toshut down services in order to conserve disk space. This message rule, which operates on a 24/7 basis, monitors to see if theavailable disk space exceeds the System Value threshold. If so, messageHAE0200 is generated and this is received in Message File E2MSGF withinlibrary ITERA.

RSR check object out of syncThis rule checks to see if RSR object is out of sync, object is not journaled, not syncing or has been omitted from syncing.This message rule, which operates on a 24/7 basis, monitors to see if the RSRobject is out of sync (or any of the other conditions listed above). If so, messageHAE0421 is generated and this is received in Message File E2MSGF withinlibrary ITERA.

RSR check for record count audit errorsThis rule checks RSR record count audit errors which if present, could indicateobjects are out of sync.This message rule, which operates on a 24/7 basis, monitors the RSR forrecord count audit errors. If any exist, message HAE0432 is generated and thisis received in Message File E2MSGF within library ITERA.

One of the systems could not ping the otherIf one system is unable to ping the other, it may suggest that there is acommunication breakdown or that one of the systems is offline, both of whichwill affect the ability to perform accurate replication. This message rule, which operates on a 24/7 basis, monitors the pingavailability between systems. If any discrepancies exist, message HAE0101 isgenerated and this is received in Message File E2MSGF within library ITERA.

One of the apply jobs is not running on tgtThe iTERA apply jobs apply any updates to the replication between systems. Ifone of the apply jobs is not running on the target machine, replication may benot be accurate. This message rule, which operates on a 24/7 basis, monitorsthe results of RSR apply job tests against the apply jobs on the target machineand if any are found not to be running, message HAE0181 is generated and thisis received in Message File E2MSGF within library ITERA.


Apply job in message waitThe iTERA apply jobs apply any updates to the replication between systems. Ifone of the apply jobs is in message wait status, replication may be not beaccurate. This message rule, which operates on a 24/7 basis, monitors the results of RSRapply job tests against the apply jobs on the target machine and if any are foundto be in message wait status within the subsystem, message HAE0182 isgenerated and this is received in Message File E2MSGF within library ITERA.

Apply job on hold on the targetThe iTERA apply jobs apply any updates to the replication between systems. Ifone of the apply jobs is not running on the target machine, replication may benot be accurate. This message rule, which operates on a 24/7 basis, monitors the results of RSRapply job tests against the apply jobs on the target machine and if any are foundto be in hold status, message HAE0183 is generated and this is received inMessage File E2MSGF within library ITERA.

Jrnrcv disk used > threshold set in MONTHRThis rule monitors to see when a system check of journal receiver disk spaceused reveals a value over the threshold set in the MONTHR test in RSR. This message rule, which operates on a 24/7 basis, monitors the journalreceiver disk space used against the threshold set in the MONTHR test in RSR.If the value exceeds the threshold, message HAE0201 is generated and this isreceived in Message File E2MSGF within library ITERA.

Rmt jrn not active from primary to targetThis rule checks if a remote journal is not active from the primary system to thetarget system.This message rule, which operates on a 24/7 basis, monitors the remotejournals for activity between the primary and target system. If a receiver is foundto be inactive, message HAE0204 is generated and this is received in MessageFile E2MSGF within library ITERA.

1+ apply jobs not active on targetThis rule checks if one or more apply jobs are not active on the target system.This message rule, which operates on a 24/7 basis, monitors the apply jobs onthe target system and if one or more are found to be inactive, messageHAE0205 is generated and this is received in Message File E2MSGF withinlibrary ITERA.


Apply pnd > threshold set in MONTHRThis rule checks if the apply pending entries value is over the threshold limit setin the MONTHR test in RSR. This message rule, which operates on a 24/7 basis, monitors the apply pendingentries value against the threshold set in MONTHR test in RSR. If the valueexceeds the threshold, message HAE0208 is generated and this is received inMessage File E2MSGF within library ITERA.

Apply pnd latency > nbr mins set in MONTHRThis rule checks if the apply pending latency is higher than the number ofminutes set in the MONTHR test in RSR. This message rule, which operates on a 24/7 basis, monitors the apply pendinglatency against the number of minutes set in MONTHR test in RSR. If the valueexceeds the set number of minutes, message HAE0209 is generated and this isreceived in Message File E2MSGF within library ITERA.

Network latency > nbr mins set in MONTHRThis rule checks if the network latency is higher than the number of minutes setin the MONTHR test in RSR. This message rule, which operates on a 24/7 basis, monitors the networklatency against the number of minutes set in MONTHR test in RSR. If the valueexceeds the set number of minutes, message HAE0210 is generated and this isreceived in Message File E2MSGF within library ITERA.

Nbr objs req sync > threshold set in MONTHRThis rule checks if the number of objects requesting sync is over the thresholdlimit set in the MONTHR test in RSR.This message rule, which operates on a 24/7 basis, monitors the number ofobjects requesting sync being greater than the threshold set in MONTHR test inRSR. If the value exceeds the threshold, message HAE0211 is generated andthis is received in Message File E2MSGF within library ITERA.

Objs req resync > threshold set in MONTHRThis rule checks if the number of objects requesting resync is greater than thethreshold limit set in the MONTHR test in RSR.This message rule, which operates on a 24/7 basis, monitors the number ofobjects requesting resync being greater than the threshold set in MONTHR testin RSR. If the value exceeds the threshold, message HAE0212 is generatedand this is received in Message File E2MSGF within library ITERA.

Obj in obj sync status test is out of syncThis rule checks if an object in the object sync status test is out of sync, notjournaled, not selected or omitted. If an object in the object sync status test isout of sync (or in any of the other conditions listed above), message HAE0219is generated and this is received in Message File E2MSGF within library ITERA.


Mirrored object is not currently journaledThis rule checks if a mirrored object is not currently journaled. If this condition isfound, message HAE0272 is generated and this is received in Message FileE2MSGF within library ITERA.

One apply job has had seq overriddenThis rule checks if a one of the apply jobs has had the sequence numberoverridden indicating a possible ‘out-of-sync condition. If this condition is foundin any of the apply jobs , message HAE0374 is generated and this is received inMessage File E2MSGF within library ITERA.

One apply job has had seq overriddenSimilar to the previous rule, this rule also checks if a one of the apply jobs hashad the sequence number overridden indicating a possible ‘out-of-synccondition. If this condition is found in any of the apply jobs , message HAE0375is generated and this is received in Message File E2MSGF within library ITERA.

DTAARA E2CURINFO contains an invalid CRGThis rule checks if data area E2CURINFO contains an invalid CRG. If thiscondition is found, message HAE0623 is generated and this is received inMessage File E2MSGF within library ITERA.

Note: This indicates a configuration issue which should be resolved by Vision Customer Care department.

Error occurred while processing objectThis rule, which operates on a 24/7 basis, monitors the processing of objects. Ifan error occurs with the processing of any object, message HAE0987 isgenerated and this is received in Message File E2MSGF within library ITERA.

Unable to change owner on targetThis rule checks the ability to change the owner on the target system. If it is notpossible to change the owner it could lead to a potential application issue duringa role swap. This message rule, which operates on a 24/7 basis, monitors this functionalityand if unable to change owner on the target system, message HAE0157 isgenerated and this is received in Message File E2MSGF within library ITERA.

Unable to change authority on targetThis rule checks the ability to change the authority on the target system. If it isnot possible to change the authority it could lead to a potential application issueduring a role swap. This message rule, which operates on a 24/7 basis, monitors this functionalityand if unable to change authority on the target system, message HAE0158 isgenerated and this is received in Message File E2MSGF within library ITERA.


Audits did not complete successfullyThis rule monitors the system audits. If one of the audits did not completecorrectly it may cause an issue with replication. This message rule, which operates on a 24/7 basis, monitors this functionalityand if one of the audits has not completed successfully, message HAE0242 isgenerated and this is received in Message File E2MSGF within library ITERA.

Note: If this message is received, it is recommended by VISION that you choose option 6 from the iTERA main menu in order to investigate.

Audit job in message waitThis rule monitors the audit jobs in the iTERA subsystem. If one of the audit jobsis in a status of message wait this may cause an issue with replication. This message rule, which operates on a 24/7 basis, monitors this functionalityand if this condition is found in one of the audit jobs in the iTERA subsystem,message HAE0243 is generated and this is received in Message File E2MSGFwithin library ITERA.

Audit has not run within warning intervalThis rule monitors the system audits. If an audit has not run within the warninginterval specified in the Audit Command Console this may cause an issue withreplication. This message rule, which operates on a 24/7 basis, monitors this functionalityand if this condition is found in one of the system audits, message HAE0245 isgenerated and this is received in Message File E2MSGF within library ITERA.

Audit has not run within severe intervalThis rule monitors the system audits. If an audit has not run within the severeinterval specified in the Audit Command Console this may cause an issue withreplication. This message rule, which operates on a 24/7 basis, monitors this functionalityand if this condition is found in one of the system audits, message HAE0246 isgenerated and this is received in Message File E2MSGF within library ITERA.

Some part of the Mirror down job not validThis rule monitors the Mirror down job and is only required if you are using thisfunctionality. If the Mirror down job is not valid, possible due to the program notbeing on the target system, this may cause an issue with replication. This message rule, which operates on a 24/7 basis, monitors the Mirror downjob and if this condition is found, message HAE0507 is generated and this isreceived in Message File E2MSGF within library ITERA.

2- 1 0 H a l c y o n T e m p l a t e s

Mirror down job command in errorThis rule monitors the Mirror down job and is only required if you are using thisfunctionality. If the Mirror down job command is in error status this may causean issue with replication. This message rule, which operates on a 24/7 basis, monitors the Mirror downjob and if this condition is found, message HAE0509 is generated and this isreceived in Message File E2MSGF within library ITERA.

Apply latency > RSR MONTHR warningThis rule, which operates on a 24/7 basis, monitors the apply latency and if thecurrent value is greater than the RSR MONTHR value, message HAE0611 isgenerated and this is received in Message File E2MSGF within library ITERA.

Apply latency > RSR MONTHR errorThis rule, which operates on a 24/7 basis, monitors the apply latency and if thecurrent value is greater than the RSR MONTHR error value, message HAE0612is generated and this is received in Message File E2MSGF within library ITERA.


TCP/IP RulesThere is one set of iTERA TCP/IP rules regardless of whether you are usingv6.0, v6.1 or v6.2

ITERA TCP/IP checkThere are two rules in the ITERA TCP/IP rule group.

Note: These two rules use system variables, (such as the IP addresses of the relevant systems) that will need amending to your localized settings prior to the rule being activated.

Check status of source systemThis rule, that runs every 5 minutes on a 24/7 basis, checks if there has been achange in the status (from available to not available or vice versa) of the sourcesystem since the last check was made. If the status has changed, an alert is raised and sent to the system consolespecified within the action schedule.

Check status of target systemThis rule, that runs every 5 minutes on a 24/7 basis, checks if there has been achange in the status (from available to not available or vice versa) of the targetsystem since the last check was made. If the status has changed, an alert is raised and sent to the system consolespecified within the action schedule.


Job Queue RulesThere are three sets of iTERA Job Queue rules depending on whether you areusing v6.0, v6.1 or v6.2. Select the version appropriate to your current iTERAinstallation.

E2JOBQ ITHAA1 iTera Job Queue v6.0The rule in this group runs constantly and makes a check every 60 seconds.

v6.0: Check job queue E2JOBQ is not heldThis rule checks that the E2JOBQ is not in a status of held. If the status of theE2JOBQ is held, an alert is raised and sent to the system console specifiedwithin the action schedule. The rule is also suspended for 15 minutes to allowyou time to investigate and resolve the issue.

E2SYSJOBQ HA61A1 iTera Job Queue v6.1The rule in this group runs constantly and makes a check every 60 seconds.

v6.1: Check job queue E2SYSJOBQ is not heldThis rule checks that the E2YSYSJOBQ is not in a status of held. If the status ofthe E2SYSJOBQ is held, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.

E2SYSJOBQ HA62A1 iTera Job Queue v6.2The rule in this group runs constantly and makes a check every 60 seconds.

v6.2: Check job queue E2SYSJOBQ is not heldThis rule checks that the E2YSYSJOBQ is not in a status of held. If the status of the E2SYSJOBQ is held, an alert is raised and sent to the system console specified within the action schedule. The rule is also suspended for 15 minutes to allow you time to investigate and resolve the issue.


Performance RulesThere are three specialist iTERA Performance Rule Groups, each containing aselection of rules to monitor v6.0, v6.1 and v6.2 iTERA performance issues. Each of the rule groups similar rules but check a different subsystem thatrelates to the version of iTERA installed on your system. The rules in V6.1 andv6.2 are identical so only one listing for both versions is provided here. Only thesubsystem changes:

• iTERA v6.0 Performance Rules check subsystem E2A1SBS• iTERA v6.1 Performance Rules check subsystem HA61A1• iTERA v6.2 Performance Rules check subsystem HA62A1

Use the rules in the Performance Rule Group that apply to your installed versionof iTERA.

For iTERA v6.0In the following rules, if you have not used ESA1SBS as the default subsystem,change the name of the subsystem in these rules to the one used by yourorganization.

ITERAV60 iTera v6.0 Performance ChecksNote: In the ITxxxx library on both nodes is a file called E2PJOBS. This file holds

a list of jobs that should be running in your subsystems based on the role that machine is performing. When the subsystems start up, it will automatically start those jobs.

Check E2A1SBS subsystem is activeIt is most likely that you will have one subsystem per Cluster Resource Group(CRG) on both the primary machine and the target machine. If you havemultiple CRGs defined, then you will have more than one subsystem. Thesubsystem names are based on the two-character CRG code designated duringinstallation (for example E2A1SBS). All iTERA HA jobs run in the subsystem. This rule checks that the E2A1SBS subsystem is always active. If thesubsystem becomes inactive, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.


Check no jobs on hold in subsystem E2A1SBSThis rule checks that there are no jobs in a status of HELD within the E2A1SBSsubsystem. If any jobs are found in this status, an alert is raised and sent to thesystem console specified within the action schedule. The rule is also suspendedfor 15 minutes to allow you time to investigate and resolve the issue.

Check no jobs in MSGW in subsystem E2A1SBSThis rule checks that there are no jobs in a status of MSGW within theE2A1SBS subsystem. If any jobs are found in this status, an alert is raised andsent to the system console specified within the action schedule. The rule is alsosuspended for 15 minutes to allow you time to investigate and resolve the issue.

PRIMARY: A1_HEALNnn job must be activeThis is the job for the Autonomic Heal technology. The job processes the Healrequests. The alphanumeric prefix and numerical suffix are system dependent.Check with your system administrator for the actual naming convention of theheal job used in your iTERA replication process.This rule checks that the A1_HEALNnn job is always active on the primarysystem. If the heal job becomes inactive, an alert is raised and sent to thesystem console specified within the action schedule. The rule is also suspendedfor 15 minutes to allow you time to investigate and resolve the issue.

PRIMARY: A1_JSNDRC must be activeThis is the Java Send Remote Command which runs a multi-threaded Javaapplication that sends, receives, and executes remote commands. Thealphanumeric prefix is system dependent. Check with your system administratorfor the actual naming convention of the Java Send Remote Command used inyour iTERA replication process. This rule checks that the A1_JSNDRC job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: A1_OBJMON1 must be activeThis is the Object Monitor Job. This job uses the QAUDJRN system journal toidentify object-level changes in mirrored libraries. These changes includecreates, deletes, changes, renames, moves from one library to another and soon. The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of the Object Monitor job used inyour iTERA replication process. This rule checks that the A1_OBJMON job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


PRIMARY: A1_OBJMON2 must be activeThis job processes ZC entries, audit level changes, authority audits, objectauthority changes, alternate name audit, user profile changes, system valueaudit and changes, save files. it also processes audits that go through thetransport journal, such as source member, library, logical file attributes and alsosubmits a purge job that removes old records from several files. The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the A1_OBJMON2 job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: A1_OBJMON3 must be activeThis job processes the same jobs as A1_OBJMON2. The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the A1_OBJMON3 job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: A1_RSRMON must be activeThis job initiates the individual tests contained in the Role Swap ReadinessMonitor.The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the A1_RSRMON job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: A1_RJTSAA must be activeThe remote journal transport syncing sending job(s) are used to replicate bothmirrored and non-mirrored objects to the target using remote journaling.The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the A1_RJTSAA job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


PRIMARY: A1_RMTCMD must be activeThe Remote Command Monitor job monitors for any remote commands comingfrom the target system that are to be run on the primary. The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the A1_RMTCMD job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: A1_SYNC_Nnn must be activeThis job uses DDM to processes sync requests from the E2POSR file whichresides on the target machine (nn is the two digit number of the target nodemachine).The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the A1_SYNC_Nnn job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: A1_SYSMON must be activeThis job submits the MONSTS job, which updates the information displayed inthe System Monitor screen, such as local journal status, remote journalingstatus, apply job status, and unapplied journal entries. It is initiated every fifteenminutes but can be adjusted, if needed.The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the A1_SYSMON job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: JSNDRCJAVA must be activeJSNDRCJAVA is the Java application started by the xx_JSNDRC job. This rule checks that the JSNDRCJAVA is always active on the primary system.If this job becomes inactive, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.


TARGET: A1_OBJMON1 must be activeThis is the Object Monitor Job on the target device. This job uses theQAUDJRN system journal to keep track of restoration of libraries, objects, andso on, in order for the system to know when to carry on and perform otherfunctions.The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the A1_OBJMON job is always active on the targetsystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

TARGET: A1_RSRMON must be activeThis is the Role Swap Readiness Monitor job that initiates the individual testscontained in the monitor on the target system.The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the A1_RSRMON job is always active on the targetsystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

TARGET: A1_RMTCMD must be activeThis is the Remote Command Monitor job which monitors for any remotecommands coming from the primary system that are to run on the targetsystem.The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the A1_RMTCMD job is always active on the targetsystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

TARGET: A1_JSNDRC must be activeThis is the Java Send Remote Command which runs a multi-threaded Javaapplication that sends, receives, and executes remote commands.The alphanumeric prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the A1_JSNDRC job is always active on the target system.


If this job becomes inactive, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.

TARGET: JSNDRCJAVA must be activeThis is the Java application started by xx_JSNDRC.This rule checks that the JSNDRCJAVA job is always active on the targetsystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

TARGET: ZMA1JRNA must be activeThis is the apply job(s) for mirrored journals. Mirrored journals are journals thatwere created for the iTERA HA product. There is an apply job for each mirroredjournal.This rule checks that the ZMA1JRNA job is always active on the target system.If this job becomes inactive, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.

TARGET: ZMA1RJRA must be activeThis is the apply job for transport journals. There is one transport journal applyjob per transport journal. There is one transport journal apply job per transportjournal.This rule checks that the ZMA1TRJRA job is always active on the target system.If this job becomes inactive, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.

TARGET: ZRA1SJNA must be activeThese are the apply jobs for RJT syncing journals process the journal entriesfrom the xx_RJTSAA job on the primary system. There is one ZR job for eachRJT Sync journal.This rule checks that the ZMA1SJNA jobs are always active on the targetsystem. If any of these jobs becomes inactive, an alert is raised and sent to thesystem console specified within the action schedule. The rule is also suspendedfor 15 minutes to allow you time to investigate and resolve the issue.

TARGET: ZU_xxxx must be activeThese are the apply jobs for user journals. This job only runs if user journals(journals that have been set up by third-party software vendors or createdoutside of iTERA HA) have been incorporated into iTERA HA.The alphanumeric suffix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process.


This rule checks that the ZU_xxxx jobs are always active on the target system.If any of these jobs becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

TARGET: ZZA1JRNA must be activeThe ZZxxAudit jobs audit the local journal receiver for any changes that occuron the target that did not originate from the primary. The ZZxxAudits are a majorcomponent of the Virtual Role Swap, which allows you to perform a completetest of the target environment’s processes that are redundant (for example:applications that are being replicated).The alphanumeric (A1) is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the ZZA1JRNA jobs are always active on the targetsystem. If any of these jobs becomes inactive, an alert is raised and sent to thesystem console specified within the action schedule. The rule is also suspendedfor 15 minutes to allow you time to investigate and resolve the issue.

TARGET: XPJRNMGT must be activeThis is the Journal Manager Job. This job manages and cleans up journalreceivers.This rule checks that the XPJRNMGT job is always active on the target system.If this job becomes inactive, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.

For iTERA v6.1 and v6.2 In the following rules, if you have not used HA61A1 or HA62A1 (depending on your version of iTERA) as the default subsystem, change the name of the subsystem in these rules to the one used by your organization.

Note: The following rules use subsystem HA61A1 as an example. If you are using iTERA v6.2 please substitute this with HA62A1.

Check HA61A1 subsystem is activeThis rule checks that the HA61A1 subsystem, the default installation subsystemfor the iTERA Availability v6.1 product, is always active. If the subsystem becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


Check MIMIXSBS subsystem is activeThe MIMIXSBS is used by iTERA to run the jobs necessary for auditing. If the subsystem becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

Check no jobs on hold in subsystem HA61A1This rule checks that there are no jobs in a status of HELD within the HA61A1subsystem. If any jobs are found in this status, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

Check no jobs in MSGW in subsystem HA61A1This rule checks that there are no jobs in a status of MSGW within the HA61A1subsystem. If any jobs are found in this status, an alert is raised and sent to thesystem console specified within the action schedule. The rule is also suspendedfor 15 minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_ALERT job must be activeThis starts iTERA Alert processing. This job is displayed and enabled only wheniTERA Alert is enabled.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_ALERT job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_APRBMON job must be activeThis job monitors the operating system for completion of unique key accesspath rebuild, then notifies the apply job that it can process the journal entries forfiles.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_APRBMON job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


PRIMARY: HA_AUDMON job must be activeThis job processes audits in the Audit Command Console.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_AUDMON job is always active on the primarysystem.If this job becomes inactive, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.

PRIMARY: HA_CHK_E2A job must be activeThis job checks whether Alert is running.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_AUDMON job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_CHK_Z_ job must be activeThis job checks whether the ZZ Audit jobs are running.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_CHK_Z_ job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_CHKOBJM job must be activeThis job performs an obsolete object check. If data area ALWDLT is set to Y(the default), then any objects that exist on the target that do not exist on theprimary will be deleted. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_CHKOBJM job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


PRIMARY: HA_CLRSNCO job must be activeThis job performs a daily clean up of data queues, save files, and purge of healrecords. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_CLRSNCO job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_CSTANZ job must be activeThis job analyzes the system for constraints and loads the 4.24 screen with theones that iTERA can manage.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_CSTANZ job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_DEVREP job must be activeThis job ensures that Device Replication is running and assists in the efficiency and speed of the replication process for configuration devices. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_DEVREP job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_DIRREP job must be activeThis job ensures that Directory Entry Replication is running. This job isdisplayed and enabled only when Directory Entry Replication is enabled.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_DIRREP job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


PRIMARY: HA_HEAL+++ job must be activeThis job processes the Heal requests.The alphanumeric (HA) prefix and +++ suffix are system dependent. Check withyour system administrator for the actual naming convention of this job as usedin your iTERA replication process. This rule checks that the HA_HEAL+++ job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_IFSCMD job must be activeThis is a supporting job for the IFS apply jobs. Executes the instructions forchanges to authority and owner attributes for a directory being synced. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_IFSCMD job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_IFSMON job must be activeThis job handles object syncing during the initial sync, object level replication,and audit resyncs.This job is displayed and enabled only when IFS Replicationis enabled. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process.

PRIMARY: HA_IFSPRG job must be activeThis job purges IFS audit history. This job is displayed and enabled only whenIFS Replication is enabled.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_IFSPRG job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


PRIMARY: HA_JBSREP job must be activeThis job ensures that Job Scheduler Replication is running. This job is displayed and enabled only when Job Scheduler Replication is enabled.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_JBSREP job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_JOBMON job must be activeThis job periodically checks the subsystem and restarts any jobs that should berunning. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_JOBMON job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_JRNMGT job must be activeThis job ensures that the Journal Manager is running and manages and cleansup receivers.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_JRNMGT job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_OBJMON1 job must be activeThis job uses the QAUDJRN system journal to identify object-level changes inmirrored libraries. These changes include creates, deletes, changes, renames,moves from one library to another, and so on. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_OBJMON1 job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


PRIMARY: HA_OBJMON2 job must be activeThis job processes ZC entries, audit level changes, authority audits, objectauthority changes, alternate name audit, user profile changes, system valueaudit and changes, and save files. Also processes audits that go through thetransport journal, such as source member, library, and logical file attributes. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_OBJMON2 job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_OBJMON3 job must be activeThis job processes longer running jobs, including some Audit CommandConsole audits, such as DIRE, JOBSCDE, DEV, and SPLF audits.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_OBJMON3 job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_OBJMON4 job must be activeThis job processes IFS entries retrieved from QAUDJRN.This job is displayedand enabled only when IFS Replication is enabled. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_OBJMON4 job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_PRGLOG job must be activeThis job deletes any records found in history and log files older that the retentionperiod. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_PRGLOG job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


PRIMARY: HA_RJTSAA job must be activeThe remote journal transport syncing sending job(s) are used to replicate bothmirrored and non-mirrored objects to the target using remote journaling.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_RJTSAA job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_RMTCMD job must be activeThis job monitors for any remote commands coming from the target system that are to be run on the primary system.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_RMTCMD job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_RPTREP job must be activeThis job is displayed and enabled only when Spool File Replication is enabledand ensures that Spool File Replication is running in order to monitor for copiedspool files.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_RPTREP job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_RSRMON job must be activeThis job initiates the individual tests contained in the Role Swap ReadinessMonitor.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_RSRMON job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


PRIMARY: HA_SNC_+++ job must be activeThis job monitors and processes resync requests for objects on the target noderequesting resync. The alphanumeric (HA) prefix and +++ suffix are system dependent. Check withyour system administrator for the actual naming convention of this job as usedin your iTERA replication process. This rule checks that the HA_SNC_+++ job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_SYNCNML job must be activeThis job controls the synchronization flow. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_SYNCNML job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_SYSINFO job must be activeThis job is used to monitor the system and track potential issues.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_SYSINFO job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_SYSMON job must be activeThis job submits the MONSTS job, which updates the information displayed inthe System Monitor screen, such as local journal status, remote journalingstatus, apply job status, and unapplied journal entries.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_SYSMON job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


PRIMARY: HA_TRGANZ job must be activeThis job analyzes the system for triggers and loads them in the 4.23 screen. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_TRGANZ job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_TRNEXT job must be activeThis job controls pass-through processing to off load long running jobs.Eliminates special setup for multiple nodes. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_TRNEXT job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_USRANZ job must be activeThis job collects user profile information. The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_USRANZ job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.

PRIMARY: HA_VLDIFS job must be activeThis validates the IFS configuration by verifying the following are valid: nodecode, CRG, object’s FID, parent’s FID, and journal assignments. Obsoleterecords are deleted. This job is displayed and enabled only when IFSReplication is enabled.The alphanumeric (HA) prefix is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the HA_VLDIFS job is always active on the primarysystem. If this job becomes inactive, an alert is raised and sent to the systemconsole specified within the action schedule. The rule is also suspended for 15minutes to allow you time to investigate and resolve the issue.


TARGET: ZMHAC01A & ZMHAC02A jobs must be activeThese are communications journal apply jobs. Communications journals aresupport journals used to report status and other information between nodes,including Heal requests, parameter updates, database updates, statuschanges, IFS replication status, etc. The originating node sends entries to allother nodes via the communications remote journal. The entries are then readand applied by the communications apply job.This rule checks that the ZMHAC01A & ZMHAC02A jobs are always active onthe target system. If this job becomes inactive, an alert is raised and sent to thesystem console specified within the action schedule. The rule is also suspendedfor 15 minutes to allow you time to investigate and resolve the issue.

TARGET: ZMHAJRNA job must be activeThis is the apply job for a mirror journal. A mirror journal is a journal that isusually created in the iTERA product for purposes of mirroring objects. There isone apply job for each mirrored journal.This rule checks that the ZMHAJRNA job is always active on the target system.If this job becomes inactive, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.

TARGET: ZMHATJRA job must be activeThis is the apply job for a transport journal. There is one apply job per transportjournal.This rule checks that the ZMHATJRA job is always active on the target system.If this job becomes inactive, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.

TARGET: ZRHASJNA job must be activeThis is the apply job for an RJT sync journal. Processes the journal entries fromthe xx_RJTSAA job on the primary. There is one ZR job for each RJT Syncjournal.This rule checks that the ZMHATJRA job is always active on the target system.If this job becomes inactive, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.

TARGET: ZU_JOURNALNAME job must be activeThis is the apply job for user journal. User journal apply jobs only exist if a userjournal (a journal that has been set up by a third-party software vendor orcreated outside of iTERA) has been incorporated into iTERA. There is one ZUjob per user journal.This rule checks that the ZU_JOURNALNAME job is always active on the targetsystem.


If this job becomes inactive, an alert is raised and sent to the system consolespecified within the action schedule. The rule is also suspended for 15 minutesto allow you time to investigate and resolve the issue.

TARGET: ZZHAJRNA job must be activeThe ZZxxAudit jobs audit the local journal receiver for any changes that occur on the target that did not originate from the primary. The ZZxxAudit functions like a safety net. There have been a significant number of instances where these jobs have identified data on the target machine that had been modified by some unauthorized process.The alphanumeric (HA) is system dependent. Check with your systemadministrator for the actual naming convention of this job as used in your iTERAreplication process. This rule checks that the ZZA1JRNA jobs are always active on the targetsystem. If any of these jobs becomes inactive, an alert is raised and sent to thesystem console specified within the action schedule. The rule is also suspendedfor 15 minutes to allow you time to investigate and resolve the issue.


Audit Journal RulesThere are three sets of iTERA Audit Journal rules depending on whether youare using v6.0, v6.1 or v6.2. Select the version appropriate to your currentiTERA installation. The rules in V6.1 and v6.2 are identical so only one listing forboth versions is provided here.

For iTERA v6.0

ITERAV60 iTera v6.0 Audit JournalThis audit journal rule group contains 4 rules to monitor the audit journalsettings of the iTERA v6.0 replication product.

E2CSTMGR must not changeThis rule, that runs on a 24/7 basis, checks for any change in the SpecialAuthority, Limit Capabilities or Status of the E2CSTMGR user profile since thelast check was made. If any of these conditions have changed, an alert is raisedand sent to the system console specified within the action schedule. The rule isalso suspended for 15 minutes to allow you time to investigate and resolve theissue.

ITERAOWNER must not changeThis rule, that runs on a 24/7 basis, checks for any change in the SpecialAuthority, Limit Capabilities or Status of the ITERAOWNER user profile sincethe last check was made. If any of these conditions have changed, an alert israised and sent to the system console specified within the action schedule. Therule is also suspended for 15 minutes to allow you time to investigate andresolve the issue.

HAA1SUP must not changeThis rule, that runs on a 24/7 basis, checks for any change in the SpecialAuthority, Limit Capabilities or Status of the HAA1SUP user profile since the lastcheck was made. If any of these conditions have changed, an alert is raised andsent to the system console specified within the action schedule. The rule is alsosuspended for 15 minutes to allow you time to investigate and resolve the issue.

HAA1ADMIN must not changeThis rule, that runs on a 24/7 basis, checks for any change in the SpecialAuthority, Limit Capabilities or Status of the HAA1ADMIN user profile since thelast check was made. If any of these conditions have changed, an alert is raisedand sent to the system console specified within the action schedule. The rule isalso suspended for 15 minutes to allow you time to investigate and resolve theissue.


For iTERA v6.1 and v6.2The following rules use v6.1 as an example. If you are using iTERA v6.2 please substitute this with v6.2 where appropriate.

ITERAV61 iTera v6.1 Audit JournalThis performance rule group contains 4 rules to monitor the audit journalsettings of the iTERA v6.1 replication product.

MIMIXOWN must not changeThis rule, that runs on a 24/7 basis, checks for any change in the SpecialAuthority, Limit Capabilities or Status of the MIMIXOWN user profile since thelast check was made. If any of the above conditions have changed, an alert is raised and sent to thesystem console specified within the action schedule. The rule is also suspendedfor 15 minutes to allow you time to investigate and resolve the issue.

ITERAOWNER must not changeThis rule, that runs on a 24/7 basis, checks for any change in the SpecialAuthority, Limit Capabilities or Status of the ITERAOWNER user profile sincethe last check was made. If any of the above conditions have changed, an alert is raised and sent to thesystem console specified within the action schedule. The rule is also suspendedfor 15 minutes to allow you time to investigate and resolve the issue.

LAKEVIEW must not changeThis rule, that runs on a 24/7 basis, checks for any change in the SpecialAuthority, Limit Capabilities or Status of the LAKEVIEW user profile since thelast check was made. If any of the above conditions have changed, an alert is raised and sent to thesystem console specified within the action schedule. The rule is also suspendedfor 15 minutes to allow you time to investigate and resolve the issue.

ADMIN must not changeThis rule, that runs on a 24/7 basis, checks for any change in the SpecialAuthority, Limit Capabilities or Status of the ADMIN user profile since the lastcheck was made. f any of the above conditions have changed, an alert is raised and sent to thesystem console specified within the action schedule. The rule is also suspendedfor 15 minutes to allow you time to investigate and resolve the issue.


Halcyon TemplatesThe following system templates are available for use with Halcyon IBMi and Windows monitoring solutions:

• AIX• AIX TEMENOS 24• AIX VIOS• HP DATA PROTECTOR• IBM SERVICES MONITORING

iCLUSTER• INFOR M3• INFOR SYSTEM 21• INFOR XA• JD EDWARDS• LINUX• MAXAVA• MISYS EQUATION• MISYS MIDAS PLUS• POWER HA• QUICK EDD• ROBOT HA• SAP• STAND GUARD ANTI VIRUS• SYMANTEC BACKUP EXEC• SYMANTEC NETBACKUP• VISION iTERA• VISION OMS/ODS REPLICATION• WEBSPHERE MQ MONITORING• WINDOWS

Learn MoreFor white papers, online product tours, datasheets, technical tips and manuals, please visit: https://www.helpsystems.com/halcyon

Contactwww.helpsystems.comUS: Toll-free: 800-328-1000 +1 952-933-0609Outside the U.S.: +44 (0) 1252 618030

TrademarksIBM®, iSeries®, Power/System i®, IBM i®, i5/OS® and AIX® are registered trademarks of International Business Machines Corporation in the United States and in other countries,All other trademarks are respective of their own companies.

https://www.helpsystems.com/halcyonhttps://www.helpsystems.com/halcyon

CopyrightOverviewInstallationInstallation of Customized EnvironmentRule Actions

Vision iTERA Availability Customization TemplatesVision iTERA Availability MonitoringMessage Queue RulesTCP/IP RulesITERA TCP/IP check

Job Queue RulesE2JOBQ ITHAA1 iTera Job Queue v6.0E2SYSJOBQ HA61A1 iTera Job Queue v6.1E2SYSJOBQ HA62A1 iTera Job Queue v6.2

Performance RulesFor iTERA v6.0ITERAV60 iTera v6.0 Performance ChecksFor iTERA v6.1 and v6.2

Audit Journal RulesFor iTERA v6.0ITERAV60 iTera v6.0 Audit JournalFor iTERA v6.1 and v6.2ITERAV61 iTera v6.1 Audit Journal

Halcyon Templates

Guide to Vision iTERA Availablilty Monitoring · 2020. 11. 18. · Vision iTERA Availability Monitoring Vision iTERA Availability for IBM i provides business continuity for small

Documents