Reflex HP NonStop Monitoring and Management includes the following :

• All HP NonStop files (including object, edit, ENSCRIBE and NonStop SQL) and comprehensive file attribute checking (including; if licensed, %full, number of records, broken, corrupt, timestamp change etc.) - includes a **status agent. Entire subvolumes can also be checked at a nominated poll period. 
   
• (** a status agent provides comprehensive information about the requested object including current status. This is obtained from the appropriate subsystem typically using a SPI or PATHSEND call.)
   
• File arrival monitoring from remote systems based on calendar periods.
   
• All Event Management Service (EMS) events for both system and application.
   
• Aleri ATLAS™ global banking technology.
   
• ASYNC lines with automatic detection and status agent.
   
• BASE24™ XPNET including autodetection and status agent for stations, lines, links, processes, devices and XPNET nodes.
   
• CPUs performance including a status agent for viewing configuration information (e.g. TLEs configured, high / low pin PCB counts etc.)
   
• Disks Status Agent (also Storage Management Foundation (SMF) virtual disks), monitoring of individual %full, cache hits and so on for both virtual and physical HP NonStop disks.
  Also a comprehensive status agent for viewing disk configuration, e.g. disk paths.Individual Disk I/O can be monitored and each Disk can be monitored against specific values.
   
• EXPAND line monitoring
   
• HP NonStop network clustering
   
• MultiBatch batch scheduler (PowerPoint - 1.6MB) including alerting, autodetection and status agent (both Guardian and OSS compliant).
   
• NetBatch™ job scheduler including alerting, automatic detection and status agent.
   
• Open System Services (OSS) monitoring for UNIX image of HP NonStop.
   
• Open System Management (OSM) monitoring.
   
• PATHWAY monitoring including autodetection and two status agents. These modules provide an array of monitoring functions for checking TERMINALS, OBJECTS, SERVERS, TCPs, PROGRAMS as well as complete configuration checking (using SPI) including DEBUG ON/OFF, number of supporting processes defined, HOMETERM / program not present, server running from a ZZBI file, server FROZEN and so on.
   
• Processes including status agent (also monitors missing, looping, suspect (e.g. in INSPECT) and busy processes). All process types supported (TNS, TNS/R and TNS/E running in Guardian or OSS). Detailed Status Agent included that can help in determining the cause of problems by showing information such as files opened, procedure call trace etc. Also provides the ability to start a Measurement.
   
• Remote Data Facility (RDF) monitoring.
   
• SPOOLCOM component monitoring including autodetection and status agent (also includes monitoring of the number of jobs in the spooler, via JOBSLOTS).
   
• TCP/IP including autodetection and status agent (version 4 and 6) for monitoring TCP/IP process, subnet, route, listner and telserv components.
   
• Transaction Management Facility (TMF) monitoring including status agent (hung, long running transactions, datavols, tape media, auditdump, audittrials).
   
• TAPE mount requests.
   
• WebSphere MQ™ (IBM MQ series) including autodetection and status agent (version 5.1, 5.3 and 5.3.1.4 on OSS).
   
• X25 including autodetection and status agent
   
• OSI/MHS status agent and autodetection. Users having OSI/MHS subsystems can utilise the Reflex 80:20 OSI/MHS Autodiscovery module to populate the OSI/MHS stack programmatically for MTAs, APPLs, CUGs, DLISTs, DLISTMEMBERs and ROUTEs and subsequently request status and configuration information for each object.
   

Also includes :

• Graphical (and audio monitoring) high-level HP NonStop system node display  (network monitor) and status monitor display (per node). All graphical displays are concurrently accessible.
   
• Dashboard for HP NonStop performance monitoring.
   
• Comprehensive EMS event viewer using object filters, filter tables and nominated collectors. Full search and EMS token breakdown and cause / effect / recovery included.
   
• Text to EMS conversion (Gateway) including 512 text events generated to EMS.
   
• Text to EMS conversion also for WebSphere MQ and OSS (MQ EMS Gateway).
   
• EMS event statistical analysis and graphing (Discovery).
   
• Enterprise manager delivery of EMS exception alerts (TIVOLI™ TEC Adapter and logfile, HP OpenView Operations™ Smart Plug-In (SPI) (now HP Operations Center™), BMC Performance Manager™ (formerly Patrol™).
   
• MEASURE on demand for processes and files (within Dashboard).
   
• Simple Network Management Protocol (SNMP).
   
• Object Monitoring Facility (OMF) conversion to Reflex.
   
• Mobile SMS paging.
   
• Email alerting.
   
• Task Automation (TaskMaster).
   
• Component rules analysis for SLA service monitoring (Service Monitor).
   
• Comprehensive EMS console event viewing and filtering (Console).
   
• Includes lean communications software, ITL's FastPipe for quick and efficient Windows to HP NonStop data relay.
   
• Security classes and profiles to prevent unauthorised access. 
   
• Includes a business-level, read-only logon.
   
• Reflex configuration reports.
   

Reflex 80:20 is a NonStop, Fault Tolerant application

Dashboard - HP NonStop real-time performance monitoring

The Dashboard facility retrieves performance and capacity statistics from a variety of NonStop subsystems (including CPU, Disk, X25, TCP/IP, Process) and then processes them in a number of ways ;

• The statistics are shown in a graphical form in a dedicated Dashboard display.
  
   
• The statistics are analysed and compared with pre-configured thresholds. If the thresholds are exceeded, then an EMS event is generated. If a value has returned below its threshold then a different EMS event is generated. This pair of “up” and “vulnerable” events can be used to animate an OverDrive Status Monitor icon and force the icon to turn blue (vulnerable) and grey (up).
  
   
• The statistics can be sent to the Insider data warehouse product Sentra, where they can used as part of a trending exercise or for Management Information reporting.
  

As with the Status Monitor facility, the Dashboard is installed on each Reflex 80:20 node and it retrieves performance statistics for the local node only. Low level, low cost GUARDIAN procedure calls are used to retrieve the latest set of statistics.

The NonStop Measure product is only accessed on user request to retrieve attributes such as file reads, writes and locks that cannot be obtained by procedure calls. The latest ZMS Measure definitions are used where available so that new counters such as IPU can be obtained. Dashboard allows users to drill down for more detailed process metrics. Users can click on a busy process to then start the process status agent to monitor what that process is doing via a call to the stack and then optionally kick off a measurement. Reflex Dashboard does not use Measure as part of it's day-to-day performance monitoring.

You can choose to switch this facility off if there is concern about processing overheads and the poll period for each different type of collection can be set by the Reflex 80:20 administrator to help manage the impact on your system. Newly collected sets of statistics are despatched to a threshold engine where the data is compared against values set by the Reflex 80:20 administrator.

When thresholds are exceeded, exception alerts are created in the local EMS event log, the events can then be transferred to the top-level Network Monitor as described (see Reflex White Paper). When the network node icon flashes, the Reflex 80:20 User has the option of selecting the OverDrive icon based status display or the Dashboard graph based performance display for that node.

For more information about Reflex Dashboard, click here.

HP NonStop Mobile Phone and Email Alerting

One of the React choices that was highlighted earlier for nominated EMS events was the “inform somebody” option. For support staff who are off site or for unattended overnight Operations, Reflex 80:20 provides a number of React Options ;

• Mobile technologies such as radio pagers and telephones
   
• Email
  

The earlier versions of the Reflex 80:20 product provided the radio paging functionality natively on the NonStop node. This involved dedicating a communications port on your NonStop system to this activity. Hayes compatible modems are still supported via this route along with a number of Radio Paging bureaus for which Insider has built customised interfaces. Further details of the supported Bureaus are available from Insider on request.

The standard TAPS protocol has also been implemented. In keeping with requests from the User community, the current Reflex 80:20 architecture has been extended to provide the paging functionality through an outboard Windows Server. The Reflex 80:20 product is now shipped with a set of Windows Services that provide Paging and in addition Email and Enterprise Management Gateway facilities.

Events that need to be routed to this set of Windows Services still need to be registered in the NonStop hosted Reflex 80:20 event database. Depending on your choice of escalation further data entry screens are displayed that allow you to configure telephone numbers, Email addresses and the event token fields that need to be despatched to your selected destination.

As a nominated EMS event is retrieved from the event logs by the Event Monitor it is dispatched to a configured IP address and port number (a fall back address can also be configured) and the Reflex 80:20 NT Service will then route the formatted details onward depending on the nature of the request.

• Email is provided by an Insider SMTP gateway running on the Windows Server.
   
• Paging, SMS and GSM access is provided by the Windows hosted MessageMaster facility. This will be shipped and implemented as part of the Reflex 80:20 Windows Service installation.
   
• Insider supports Tivoli integration via either log file or TEC adaptor methods. Insider is a certified Tivoli partner.
   
• Reflex 80:20 supports integration with HP OpenView. Insider is a certified HP OpenView partner. Reflex can also escalate EMS events to BMC Performance Manager.
  

A final and more basic way of escalation is via an SNMP trap. Insider ships a MIB definition as part of the package. This can be loaded into an Enterprise Manager and it provides a richer trap definition than the native NonStop facility.

Each EMS event has a unique trap number allocated and the traps variable bindings include subject, manager, criticality, description and any available cause effect and recovery information. This SNMP facility has been implemented on the NonStop node and does not require a Windows Server.

EMS WebSphere MQ Monitoring Gateway

EMS MQ Gateway is an off-the-shelf solution (and integrates seamlessly with Reflex for graphical monitoring) which will finally give you full EMS event tokens from all those business-critical MQ WebSphere events (including version 5.3.1.4 on Open System Services (OSS)) that are suffering from a lack of visibility on the HP NonStop platform. Reflex also provides a built in status agent to give detailed status and configuration information for all Guardian and OSS WebSphere MQ components as well as providing exact graphical mapping for MQ Gateway EMS events.

By using simple screens EMS MQ Gateway enables you to set up the rules by which MQ events will be converted into full EMS event tokens. The process is simple. You identify the portions of the MQ event you want to convert and then identify the conversion rules (what you want to keep from the original event and what you want in the new event) to create the new EMS message.

EMS MQ Gateway Key Features :

• Converts existing MQ WebSphere text tokens to full EMS events
  
   
• Differentiates between "identical" MQ WebSphere events
  
   
• Allows MQ subsystem to be part of full object sets
  
   
• Can connect through to Reflex, BMC Patrol, HP OpenView or Tivoli via (separate) certified SPI (Smart Plug-In) and TEC gateways
  
   
• Automated EMS template generator
  
   
• Enables creation of new and discrete MQ WebSphere events to match your service monitoring
   
   
• Also works for WebSphere MQ versions 5.1 and 5.3 (5.3.1.4) (on OSS)
   
   
• Availability on the HP NonStop Server S-series and NonStop Integrity Server (32-bit) architectures
   

For more information about Reflex for Monitoring HP NonStop WebSphere MQ, click here.

HP NonStop PATHWAY application monitoring using Reflex 80:20

The Reflex 80:20 Pathway automatic detection utility allows Reflex users to generate full graphical, drill-down object trees for the real-time monitoring of servers, terminals, programs and TCP's. Supplied agents provide full status and information on all of these components and EMS events can also be directly mapped to the graphical component that is either vulnerable or critical.

The following files are supplied as part of the Pathway installation object subvolume:

PATHAD - Pathway Autodiscovery utility
PATHAG - Status Agent for Pathway objects
PATHPW - Pathway Server Definition file

Autodiscovery Module - Pathway Systems

The Reflex 80:20 Pathway Auto-Discovery utility is designed to easily scan and load various user-definable Pathway components for a nominated Pathway system.

PATHAD supports the loading of the following PATHWAY components:

• Servers

• Terminals

• Programs

• TCP’s

REFLEX PATHWAY MONITORING module (PWYMON)

This is a polling module that checks the status of nominated Pathway serverclasses at regular intervals.

It can also be used to alert on situations which will produce a DOWN event or a VULNERABLE event. An UP event will be issued for when the situation has been resolved.

DOWN event situations

• The serverclass is running with less than the minimum number of processes, e.g. alert if the serverclass is running with less than 2 processes.

• The serverclass has debug enabled.

• The home terminal configured for the serverclass does not exist.

• The object that the serverclass is configured to use does not exist.

VULNERABLE event situations

• The serverclass is running against a ZZBI object.

• The serverclass is in a frozen state.

When the state returns back to an acceptable state then a corresponding UP event will be issued.

EMS event range:

SSID:    
INSIDER.50.0

UP event:   
6000

VULNERABLE event:  
6001

DOWN event:   
6002

A Reflex Transit file - TRANPWYM - is provided for the above events. The Reaction for all events utilises a format string value of ~manager~.~subject~, which relates to the EMS event tokens for 'Pathmon Process' and 'Pathway Server' respectively.

The contents of the transit file can be imported via the RFIMEX utility.

Monitoring Pathway ServerClasses

The Pathway serverclasses that are to be monitored are listed in a PWYLIST file. There can be a maximum of 10 PWYLIST files, which are named PWYLIST0 to PWYLIST9. Each file can have multiple serverclasses declared for monitoring.

These files are standard EDIT type files (filecode 101) and are typically stored in the Reflex data subvolume (RFLXDAT).

The contents of the PWYLIST files follow a strict format as follows:

Column references

• Any lines that have a ? in column 0 are treated as a comment.

• A Y in column 0 means that the declaration on that line is enabled; any other character means that the declaration is disabled.

• Column 2 is used to declare the Pathmon in which the serverclass is configured.

• Column 10 is used to declare the serverclass name.

• Column 31 is used to specify the minimum number of processes that the serverclass should have running.

• Column 41 is used to specify if debug alerting is required; values allowed are Y/N.

• Column 46 is used to specify if valid home terminal alerting is required; values allowed are Y/N.

• Column 51 is used to specify if valid program alerting is required; values allowed are Y/N.

• Column 56 is used to specify if ZZBI alerting is required; values allowed are Y/N.

• Column 61 is used to specify if frozen serverclass alerting is required; values allowed are Y/N.

An example file - PWYLIST0 - can be found in the Reflex data subvolume (RFLXDAT).

Reflex Admin / File Alias configuration

Each PWYLIST file that is to be used must be declared in the Admin / File Alias screen of Reflex, which shows the contents of

the Reflex DATACONF file. The File Aliases specified must be in the range PWYLIST0 to PWYLIST9.

Reflex Admin / Parameters configuration

The Admin / Parameters screen contains configuration details that are used by the Pathway Monitoring module, which are:

• PWYMON-INTERVAL - specifies the time interval in seconds, between monitoring polls to the specified Pathway serverclasses.

• PATHMON-PROCESS - specifies the Pathmon that Reflex is running under.

Reflex for HP NonStop Network Monitoring

The OverDrive view represents the status of a single HP NonStop node. This tab discusses how Reflex 80:20 is implemented across a NonStop network.

Reflex 80:20 needs to be installed on each of the HP NonStop nodes that will be monitored (including ServerNet, Integrity and Blade technologies). Each Reflex 80:20 system will connect to its own local Primary EMS collector ($0) and selected alternate collectors, and listen and process local EMS events based on the local event database.

Automation and escalation to external agencies such as an Enterprise Manager, Mobile SMS, Email or SNMP, will be the responsibility of each of the local Reflex 80:20 systems.

Each local Reflex 80:20 node will be responsible for maintaining a table of the status of the icons on display for its node. This will be updated as the Reflex Event Monitor passes new information to it as it arrives in the local EMS logs.

Outside of this, the Reflex 80:20 administrator needs to create a Network Hierarchy file that contains the names of all of the Reflex 80:20 nodes in the network. At least one of these nodes needs to be classed as the parent and typically it is the node that you have your Reflex 80:20 GUI client connected to.

Each child node will then send regular status updates to the parent(s) stating that during the last poll period they have processed;

• no events or

• at least one vulnerable event or

• at least one down event.

• A fourth condition also exists, the parent expects a message from a child and it never arrives.

The parent node has a state table for the nodes in the network and it is used to animate a display showing node icons. The icons will be shown as grey (no messages processed), red (at least one down), blue (at least one vulnerable) or orange (no child message received).

Clicking on the appropriate node icon brings up the detailed status display for that node and the underlying fault can then be investigated further. Clicking on the bar chart icon first and then the HP NonStop node brings up the performance metrics for that node, e.g. CPUs, Disks, Processes, X.25 etc.

The interval that these child -> parent messages are sent is at the discretion of the Reflex 80:20 administrator. Even in a large multi-node environment therefore, network traffic is minimal but control from a single point is possible.

To provide a level of fault tolerance it is possible to configure your client program so that it has a list of alternative IP addresses and port numbers to connect to, in the event of a network failure. If an up to date network summary is available at this alternative address you will be able to view the latest status position.

HP NonStop X.25 Monitoring

Management of HP NonStop X.25 lines and SU’s is available with the Reflex product.

If a line or SU fails, then an EMS event will be issued, with the option to forward it to a variety of escalation tools, e.g.:

• Status Monitor
• Mobile SMS or Email
• Enterprise Manager
• Restore failed Line / SU via Reflex TASK

The Reflex 80:20 Dashboard module - operating in real-time - graphically displays a variety of X.25 performance attributes. The performance metrics displayed are based on user-configurable parameters. If thresholds are breached, then the Dashboard display is dynamically updated, with the option to escalate the resultant EMS event.

By using a combination of Threshold Alerting and Dashboard / HP NonStop EMS alerts, operations and network personnel can be forewarned of any potential problems which may occur on your X.25 lines.

For example, Reflex 80:20 is issuing alerts regarding numerous ‘REJects’ occurring at Frame Level. This could ultimately affect Packet data loss if resolution is not undertaken.

To facilitate improved X.25 management, Reflex 80:20 now supports the following attributes :

• ALL Frame Level Statistical Information (RNR, REJ, DISC, RSTRT, etc.)
• ALL Packet Level Statistical Information (RNR, REJ, FRMR, DISC, etc.)
• Line State (STARTED, STOPPED)
• Link State (DOWN, NOT READY, READY)
• Line Quality (100%, 90%, etc.)
• Modem Errors
• No. of SU’s in use
• No. of SU’s started
• No. of SU’s not started

X.25 Lines and Sub-Devices can be ‘Autodiscovered’, creating a tree structure of your X.25 network within Status Monitor.

These objects are then ready to receive EMS alerts from Dashboard and from HP NonStop.

If required, a TASK can be executed for the ‘failed’ object - executed automatically, or manually.

By using the ‘Get Detail’ status agent function, configuration and statistical details for:

• Packet Level
• Frame Level
• Line Status
• Link State

are all provided in ‘one view’.

Reflex 80:20 provides both an auto-detection utility and a status agent for the comprehensive, real-time monitoring of the HP NonStop TCP/IP subsystem (both TCP/IP v4 and TCP/IP v6).

If a TCP/IP subsystem component fails, then an EMS event will be issued, with the option to forward it to a variety of escalation tools, e.g.:

• Status Monitor
   
• Mobile SMS or Email
   
• Enterprise Manager, e.g. Tivoli, HP Operations Center, BMC Performance Manager
   
• Restore the failed TCP/IP subsystem component via a Reflex TASK
   

By using Reflex threshold alerting to generate HP NonStop EMS alerts, operations and network personnel can be forewarned of any potential problems which may occur on TCP/IP subsystem components.

TCP/IP objects that can be detected and monitored are:

• TCP/IP process 
   
  
• TCP/IP subnet
   
  
• TCP/IP route
   
  
• TCP/IP compatibility process (Parallel TCP/IP)
   
  
• TCP/IP compatibility subnet (Parallel TCP/IP)
   
  
• TCP/IP compatibility route (Parallel TCP/IP)
   
  
• TCP/IP Listner 
   
  
• TCP/IP Telserv process

 
Graphical TCP/IP object trees can be generated automatically for instant monitoring or can be constructed and tailored by the user, grouping appropriate components together.

EMS alerts can be mapped directly against each graphical TCP/IP object and users can also request object status using the Reflex TCP/IP status agent.

For more information about Reflex TCP/IP monitoring, click here.

In its most basic form, Reflex for HP NonStop Batch Schedules monitoring can be split into two discrete functions; Reactive Monitoring and Proactive Monitoring.

Central to both of these threads is the HP NonStop Event Management Service (EMS). Reflex for HP NonStop Batch Reaction module monitors by connecting to this logging environment to retrieve and process batch events (MultiBatch, NetBatch or in-house macros) that you have nominated. In this way batch schedule failures reported to EMS can be extracted by Reflex, alerted and escalated.

There are 4 options within Reflex for HP NonStop Batch monitoring for reacting to nominated job EMS events;

• Graphically flash the problem in the Reflex Status Monitor screen against the appropriate batch component or view the EMS exception alert in the Console module (provided as part of the standard Reflex deliverable)
   
• Relay the event to an appropriate Enterprise Management solution such as hp Operations Center, TIVOLI or BMC Performance Manager using a certified Reflex API or SNMP trap
   
• Escalate the alert using one or a combination of; mobile SMS text, SNMP, e-mail address or radio pager
   
• Finally, you can relay the event detail to the ITL product SENTRA, where it can be used as part of a trending exercise or for Management Information reporting
   

Reflex for HP NonStop Batch proactive monitoring will operate quietly in the background, tracking system and application processes. If a process disappears, the Reflex Process Monitor will raise an event to alert operators to the problem.

For more information about Reflex for monitoring HP NonStop Batch Job Schedules, click here.

For Reflex / TIVOLI TEC integration, 3 solutions are available : 

Windows log file approach:

With this solution, TIVOLI can be configured to monitor a Reflex Windows log file. This log file is set-up and written to by Reflex running on HP NonStop (via TCP/IP using ITL's FastPipe communication) in a defined record format anytime a configured Reflex Tivoli Reaction is triggered by a HP NonStop EMS message.

The log file resides on a nominated Windows platform known to Tivoli (pre-configured by Tivoli TEC administrators). The defined format for each EMS record written to the log file has already been imported into Tivoli (by Tivoli administrators using Tivoli BAROC files) prior to start-up. This is done so that Tivoli is aware of the Reflex log file message/record format before it starts to monitor the log file. 

TIVOLI TEC Event Adapter approach:

With this solution, Reflex uses a TIVOLI TEC Event Adapter to programmatically write directly to TIVOLI with an appropriate API message structure. Reflex continually monitors any number of HP NonStop platforms through dynamically generated event filter objects and optionally, alternate collectors. When an EMS event message is seen which has a corresponding Reflex reaction configured, the event is then escalated with a Reflex programmatic call to the TIVOLI TEC Adapter. 

Command line tool:

If a command line tool exists on-site for writing events to TIVOLI, Reflex can make use of this command line executable or Macro to escalate events by stringing the appropriate parameters to it and then executing it. ITL used this approach to alert to HP Service Desk currently. This approach is also used by Reflex to alert to BMC Performance Manager.

For more information relating to the integration of the Reflex product with Tivoli, click here.

Reflex - HP NonStop Smart Plug-In (SPI) for
HP Operations Center™ for Windows (formerly OpenView)

The hp OVO Smart Plug-In technology demands a greater level of sophistication for central enterprise control and goes beyond basic event alerting. The Reflex SPI offers a comprehensive view of your entire hp NonStop network (including HP NonStop Integrity and Blade technology) from the hp OVO Management Console.

Before the introduction of the hp Smart Plug-In technology, the extent and depth of monitoring and interaction provided could only be realistically achieved using more proprietary, platform specific products beyond enterprise management solutions. The Reflex SPI naturally extends hp OVO with the required tools, operator initiated commands and service tree views for complete hp NonStop platform management.

Maintaining the enterprise management layer and ensuring it is in-step with updates to the hp NonStop network for hardware, middleware and your live applications is simplified by design, using an advised software strategy. The Reflex SPI compliments the hp OVO Management Console by delivering tools that allow for easy, single-click administration of new hp NonStop policies, alerts and service tree updates. The NSK based Reflex Smart Plug-In agents are engineered to provide very low utilisation of NonStop resources in relaying alerts to hp OVO. A ‘listen rather than interrogate’ design principle allows the Reflex SPI to perform real-time notification of NonStop issues without jeopardising any of your live application performance, or response times.

The hp OVO alert relay mechanisms on the NonStop platform are further optimised by incorporating pre-filtering rules. This approach strips out unwanted events allowing selective and sensible filtering of critical NonStop server and application alerts for major subsystems, which includes TCP/IP, MQ Series, XPNET™ and BASE24™. This unique feature provides hp OVO end users with the confidence that all events displayed in the hp OVO ‘Active Message’ Management Console views, are real NonStop issues.

The Reflex SPI takes full advantage of the hp OVO Service Views approach by quickly alerting on potential problem areas for your NonStop network. Users of hp OVO can represent NonStop subsystems, by node and by their own chosen alias names for key system areas or business functions, e.g. ATM network stations, live application files, suspect looping processes and BASE24 switch interchanges.

The service view display offered by the Reflex SPI will quickly isolate any deficiencies in your ability to meet agreed SLAs by underlining key failing critical path components, subsystems and application processes. This approach allows for the service provision of your NonStop network to be proactively maintained rather than being compromised when a number of key NSK components have failed.

The Reflex SPI provides the hp OVO Management Console with all the traditional troubleshooting capabilities associated with the Guardian Event Management Service (EMS), including Probable Cause and Recommended Action, and all mandatory EMS tokens and the user applied hp OVO severity settings. Also available through the hp OVO Console are secure Task Automation (both manual and system initiated), detailed NSK component information, configuration, statistics and user requested real-time object status.
HP OVO tools are provided for service tree topology detection of NSK subsystems (both Guardian and application), hp OVO policy and event acknowledgement import and running the Reflex GUI Client.

Reflex Smart Plug-In functions provide a comprehensive and future proofed strategy for managing your entire NonStop network through the hp OpenView Operations solution. The Reflex SPI now makes it possible to deliver pertinent NonStop information and status, providing real and effective NonStop problem resolution to the enterprise management layer of the business, for the first time.

For more information, see Reflex Smart Plug-In (SPI) page.

Latest News :

Insider Technologies has successfully completed a HP NonStop Blade accreditation test exercise at the HP offices at Wood Street, London. The testing took place between April 21st and 24th 2009.
 
The ITL product successfully accredited was ;

Reflex
The mainframe class monitoring and management software suite for the HP NonStop environment.

The hp NonStop 'Blade Ready' version of the software is ;

Reflex, version 4.7L2
The software is available from May 1st 2009.

The version of the Blade operating system that the product was verified against was ;

J06.04.02 on a HP Integrity NonStop NB50000C Blade System
 
For further information about the Insider Technologies Blade accreditation program, please contact the Insider Help Desk on +44 (0) 161 876 6606 or use our contact page.

Reflex 80:20 Version 4.7M – Available Q1, 2010 

Individual Disk Monitoring (I/O Times):

Individual Disk I/O monitoring is now available, where this facility can obtain the count of timings that I/O took on each Disk (Primary, Backup, Mirror and Mirror Backup Paths), polling each Disk at regular intervals.

If a specified monitoring value is exceeded then an EMS event is issued to alert HP NonStop personnel of the problem. When the Disk Paths return to specified I/O levels, then a subsequent EMS event is raised to clear the alert. All events can be forwarded to matching Disk Objects in Reflex Status Monitor, or escalated as with other types of Reflex monitoring and alerting.

Disk I/O monitoring continues to take place for all Disk Paths, even if half of a mirrored volume is down and there is no need to run Measure Counters to obtain this information; you just need to specify the I/O values and polling period and let Reflex alert you to any issues with Disk I/O.

For further details on Reflex Disk monitoring, please visit the following link.
 

TCP/IP extensions for 4.7M:

Reflex 80:20 provides an auto-detection utility and status agent for comprehensive, real-time monitoring of the HP NonStop TCP/IP subsystem (both TCP/IP v4 and TCP/IP v6), where Process, Telserv, Route, Listner and Subnet components can all be monitored.

If a TCP/IP subsystem component fails, then an EMS event will be issued with the option to forward it to a variety of escalation tools, e.g.:

• Reflex Status Monitor
• Mobile SMS
• Email
• Enterprise Managers: Tivoli, HP Operations Center, BMC Performance Manager
• Restore the failed TCP/IP  component via a Reflex TASK (automatically, or by Operator intervention)

Graphical TCP/IP object trees can be generated automatically for instant monitoring or can be constructed and tailored by the user, grouping appropriate components together.

EMS alerts can be mapped directly against each graphical TCP/IP object and users can also request object detail where the equivalent SCF data is graphically represented.

From release 4.7M, TCP/IP Subnet M-State Monitoring has been included, where Reflex can monitor the M-State flag for autodiscovered Subnets, which can assist in identifying a problem with TCP/IP v6 Failover.

If a Subnet M-State flag is identified as DOWN, then an EMS event is issued to alert HP NonStop personnel of the problem. When the M-State flag returns to normal, then a subsequent EMS event is raised to clear the alert. All events can be forwarded to matching Subnet Objects in Reflex Status Monitor, or escalated as with other types of Reflex monitoring and alerting.

For further details on Reflex TCP/IP monitoring, please visit the following link.

File-Metrics extensions for 4.7M:

The Reflex File Metrics monitoring facility can track a list of nominated files or subvolumes (including SQL, ENSCRIBE and Edit files) where numerous file attributes can be monitored and rules configured, so that if the monitored file / subvolume is not in a ‘healthy’ state, then a Reflex EMS event will be raised. As with TCP/IP monitoring, these alerts can be forwarded to a variety of destinations.

Some examples where users can benefit from Reflex File Metrics monitoring are:

• File is Corrupt, Broken or Crashed Open

• File has lost its Audit flag

• Timestamp of file has changed since last poll

• Saveabend files found in monitored subvolume

• File has lost its SQL Compiled status

• File no longer exists

• File upon arrival does not meet certain criteria, e.g. timestamp or security attributes are incorrect

From release 4.7M, several enhancements have been made to allow for increased flexibility, improved memory management and increased limits to the number of files that can be monitored.

For further details of Reflex File monitoring, please visit the following link.