VMAX3 & VMAX All Flash: Error code: 08.0492.06 w/Event Source: disk, Event ID: 7

Article Number: 521998 Article Version: 3 Article Type: Break Fix

VMAX 100K,VMAX All Flash,VMAX3 Series

08.0492.06 – Event Source: disk, Event ID: 7, Event Type: ERROR

08.0492.06 – dialing home against SP

Error code: 0492.06

Component SP (SW)

Symp Date Time Count DV

208.0492.06 <date> <time> <date> <time> 1PC related problem — Event Time: <date> < time>, Event Source: disk, Event ID: 7, Event Type: ERROR

Symmwin has an event log service that monitors the Windows OS Event logs. If a disk error is detected in the event log, the service will call home with an 0492.06 event.

  1. First Identify which MMCS is reporting the 0492.06 event.

    The Dial home event will contain this information;






    And connect to the MMCS reporting the 0492.06 event.
  1. Once connected open up the Event Viewer;

    Start > search for Event Viewer >

    User-added image

    User-added image
  1. Once in the Event Viewer, route to the System Alerts;
Event Viewer (Local) > Windows Logs > System
User-added image

Sort by Date and Time to find your dial home Event ID.

Double click your Error Event ID to bring up the details.

User-added image

(*If your events are not found, please check the other MMCS*)
  1. If the Event ID 7 error count is less than 5 errors per hour, or 5 errors over 30 days, close the SR with the following update” Event viewer shows less than 5 errors in one hour”.

If more than 5 errors per hour are displayed:

  • Collect the Security and System event logs.
Select Security > Action > Save All Events As


Repeat for System, and save as System.txt

User-added image

Alternative: Right click on Security > Save All Events As


Repeat for System, and save as System.txt

User-added image

  • Attach both of the Security.txt and System.txt to Dial home SR.
  • Collect MMCS part location, SN, and PN
  1. Escalate to Recovery/Engineering to confirm if MMCS replacement is needed (as per KB/SFA: 000336125)

Note: this is a similar solution as is outlined in KB/SFA: 000425239 (Symmetrix VMAX: System dials home with 208.0492.06 errors.)


OneFS Events and Alerts

The OneFS Cluster Event Log (or CELOG) provides a single source for the logging of events that occur in an Isilon cluster. Events are used to communicate a picture of cluster health for various components. CELOG provides a single point from which notifications about the events are generated, including sending alert emails and SNMP traps.

Cluster events can be easily viewed from the WebUI by browsing to Cluster Management > Events and Alerts > Events. For example:


Or from the CLI, using the ‘isi event events view’ syntax:

# isi event events view 2.370158

ID: 2.370158

Eventgroup ID: 271428

Event Type: 600010001

Message: The snapshot daemon failed to create snapshot ‘Hourly – prod’ in schedule ‘Hourly @ Every Day’: error: Name collision

Devid: 2

Lnn: 2

Time: 2018-04-09T17:01:33

Severity: warning

Value: 0.0

In this instance, CELOG communicates on behalf of SnapshotIQ that it’s failed to create a scheduled hourly snapshot because of an issue with the naming convention.

At a high level, processes that monitor conditions on the cluster or log important events during the course of their operation communicate directly with the CELOG system. CELOG receives event messages from other processes via a well-defined API.

A CELOG event often contains the following elements:




Events are generated by the system and may be communicated in various ways (email, snmp traps, etc), depending upon the configuration.


Specifiers are strings containing extra information, which can be used to coalesce events and construct meaningful, readable messages.


Extra chunks of information, such as parts of log files or sysctl output, added to email notifications to provide additional context about an event.

For example, in SnapshotIQ event above, the event text contains a specifier and attachment that has been mostly derived from the corresponding syslog message:

# grep “Hourly – prod” /var/log/messages* | grep “2018-04-09T17:01:33”

2018-04-09T17:01:33-04:00 <3.3> tme-sandbox-2 isi_snapshot_d[5631]: create_schedule_snapshot: snapshot schedule (Hourly @ Every Day) pattern created a snapshot name collision (Hourly – prod); scheduled create failed.

So what happens under the hood? CELOG is a large, complex system, which can be envisioned as a large pipeline. It gathers events and statistics info on one end from isi_stats_d and isi_celog_monitor, plus directly other applications such as SmartQuotas, SyncIQ, etc. These events are passed from one functional block to another, with a database at the end of the pipe. Along the way, attachments may be generated, notifications sent, and events passed to a coalescer.

On the front end, there are two dispatchers, which pass communication from the UNIX socket and network to their corresponding handlers. As events are processed, they pass through a series of coalescers. At any point they may be intercepted by the appropriate coalescer, which creates a coalescing event and which will accept other related events.

As events drop out the bottom of the coalescer stack, they’re deposited in add, modify and delete queues in the backend database infrastructure. The coalescer thread then moves onto pushing things into the local database, forwarding them along to the master coalescer, and queueing events to have notifications sent and/or attachments generated.

The processes of safely storing events, analyzing them, deciding on what alerts to send and sending them is separated into four separate modules within the pipeline:


The following table provides a description of each of these CELOG modules:




The first stage in the processing pipeline, Event Capture is responsible for reading event occurrences from the kernel queue, storing them safely on persistent local storage, generating attachments, and queueing them by priority for analysis.


Extra chunks of information (log file extracts, sysctl output, etc) are added to alert notifications to provide additional context about an event.


The Reporter is the third stage in the processing pipeline, and runs on only one node in the cluster. It periodically queries Event Analysis for changes and generates alert requests for any relevant conditions.


The Alerter is the final stage in the processing pipeline, responsible for actually delivering the alerts requested by the reporter. There is a single sender for each enabled channel on the cluster.

CELOG local and backend database redundancy ensures reliable event storage and guards against bottlenecks.

By default, OneFS provides the following event group categories, each of which contain a variety of conditions, or ‘event group causes’, which will trigger an event if their conditions are met:


Say, for example a chassis fan fails in one of a cluster’s nodes. OneFS will likely capture multiple hardware events. For instance:

  • Event # 90006003 related to the physical power supply
  • Event # 90020026 for an over-temperature alert

All the events relating to the fan failure will be represented in a single event group, which allows the incident to be communicated and managed as a single, coherent issue.

Detail on individual events can be viewed for each item. For example, the following event is for a drive firmware incompatibility.

Drilling down into the event details reveals the event number – in this case, event # 100010027:


The “Open Event Help” link on each event group detail window will bring up the specific info page for each event from the OneFS help guide.


OneFS events and alerts info is also available online at the following URL:



The Event Help information will often provide an “Administrator Action” plan, which, where appropriate, provides troubleshooting and/or resolution steps for the issue.

For example, here’s the Event Help for snapshot delete failure event # 600010002:


The OneFS WebUI Cluster Status dashboard shows the event group info at the bottom of the page.


More detail and configuration can be found in the Events and Alerts section of the Cluster Management WebUI. This can be accessed via the “Manage event groups” link, or by browsing to Cluster Management > Events and Alerts > Events.


7021536: Verastream Host Integrator Event Handler Examples: Writing Data to JMS Message Queue

About this Event Handlers Example

This event handler is to generate an XML document using data from a table procedure, which is then sent to a JMS (SonicMQ) message queue.

The following sample shows output from all procedures in the CCSDemo model. The same event handler could work with all procedures; however, parameters vary according to the procedure.

<?xml version="1.0" encoding="UTF-8"?>


<GetAccount Table="Accounts">






<AccountSearch Table="Accounts">








<GetTransactions Table="Transactions">







It is undesirable for an exception to interfere with procedure execution (unless this is the intended behavior), so log any XML-related exceptions and continue processing.

Parameters for connecting to the JMS queue can be hard coded or read from the Verastream properties files script.properties (server) or dt_script.properties (Design Tool).

Event Handler Code

This Verastream Event Handler example has 3 steps:

  1. Generate an XML document from procedure filter and data parameters.
  2. Convert the XML document to a string or a file.
  3. Connect to a (SonicMQ) JMS queue and submit the XML string .

The first two steps are functions called from the main handler method. generateXMLdocument() generates an XML document from input parameters, filter and data parameters, appending each key/value parameter pair as an element node to either a FilterParameter or InputParameter parent node. outputDoc2String() serializes the XML document to a string, transactionXML.

public ProcedureRecordSet

executeProcedure(ExecuteProcedureEvent event)

throws ApptrieveException {

try {



} catch (Exception e) {

//throw new ApptrieveException(e.getMessage());



The remaining steps continue within executeProcedure(), prior to executing the actual table procedure. Parameters for connecting to the JMS queue are read from script.properties (server only) or dt_script.properties (Design Tool only):

broker = event.getHandlerProperty("broker");

queueName = event.getHandlerProperty("queue");

uname = event.getHandlerProperty("user");

password = event.getHandlerProperty("password");

Next, a transaction queue is opened, the XML string is sent to the appropriate queue, and the queue is closed.

try {

queueTransactionData(broker, uname, password);

sendMessage(queueName, transactionXML);


} catch (Exception e) {

//System.out.println("Caught exception: " + e.getMessage());


Finally, the table procedure is executed, returning the recordset.

return event.defaultProcedure();

Downloading the Example

The zipped Java file and ReadMe, can be downloaded from the Download Library at logTransactionToQueue.zip.

Installing the Event Handler

To install the event handler, follow these steps.

  1. Copy logTransactionToXML.java to the models<your model>scriptssrc directory.
  2. In Design Tool, click Events > Rebuild.
  3. Assuming the build is successful, click Model > Tables, select any procedure, and then click Advanced Properties.
  4. Under Event handler, select logTransactionToXML, and then click Properties and note the description.
  5. Save the changes.

To set the classpath, follow these steps, where <JMS> is the directory that contains the SonicMQ jar files:


gnu-regexp-1.0.6.jar; <JMS>\javax.jms.jar;<JMS>\jaxp.jar;<JMS>\


For use by Design Tool, dt_script.properties in <VHI>etc needs to be edited in a similar manner.

Parameters for connecting to the JMS queue can either be hard-coded or (as here) read from the Verastream properties file: script.properties (server) or dt_script.properties (Design Tool). To use properties, copy the following to the appropriate .properties file.



broker=<SonicMQ server>:2506


To test the event handler, be sure that the necessary SonicMQ broker is running. The default queues in SonicMQ are SampleQ1, SampleQ2, SampleQ3 and SampleQ4; be sure that the expected queue is availabe. In Design Tool, choose "Procedure test..." from the "Debug" menu. Select table and procedure desired. Enter Procedure filters or data parameters, click "Execute". Some messages are written to the Debug Console. A new message has been added to the desired queue. XML data is readable in the body of the message using a browser.


7021510: Configuring VBA Events for Host Screen Text in Reflection for IBM 2014 or 2011

Background for Former Users of EXTRA! X-treme

In both EXTRA! X-treme and Reflection for IBM 20114 or 2011, you can configure HotSpots that enable you to click host text to send a terminal key function (for example, click “PF1” to send PF1). In EXTRA! X-treme, you could also configure actions to be automatically invoked when the HotSpot text is displayed in the host session. In Reflection for IBM 2014 or 2011, such automatic actions must be configured in a VBA event instead of HotSpots, as explained below.

Creating a VBA Event Handler to Perform an Action

In Reflection for IBM 2014 or 2011, events are exposed by the Reflection IbmScreen object. Follow these steps to create a VBA event handler with your desired code:

  1. Open a Reflection session.
  2. On the Ribbon, click the Tools tab and open the Visual Basic editor.
  3. In the Project panel on the left side of the editor, expand the Reflection Objects folder and double-click the ThisIbmScreen object. A code window opens.
  4. In the (General) drop-down list at the top of the code window, select the IbmScreen object.
  5. In the drop-down list to the right, which contains events associated with the selected object, click the NewScreenReady event. The following code is added to the code window automatically:
Private Sub IbmScreen_NewScreenReady(ByVal sender As Variant)

End sub

The NewScreenReady event will fire every time a new host screen is displayed in the terminal.

  1. Code can now be added to this event macro to identify which screen has been reached, and take any action that might be required. For example,
If ThisIbmScreen.GetText(1, 66, 14) = "APPLID CICS23A" And _

ThisIbmScreen.GetText(10, 11, 14) = "Userid . . . ." Then

'a particular screen is identified...do something...

End If


SEP 14 RU1 – Notification Emails from events months ago

I need a solution


Since we upgraded from 12.1 to 14 RU1 we are getting very often Email notifications from Risk Found events months ago. For example, on the 2 of January 2018 we got again a notification of a “New risk found” event on a client from July 2017. Another one we got from February 2016. It happens not only with the same clients and they are always online and connected and the Heartbeat is 5 Minutes. On the clients we can’t see any current event logged, so it’s definitely from the past and must be triggered from the SEP Manager and its database. We have no idea why SEP 14 is bringing such events up again after months or weeks. Is there a way to check the database or any health check procedures?





callback argument in ecm.model.Action performAction

There is a callback argument in performAction function of ecm.model.Action (JavaScript). I was wondering, when to call it, when implementing an Action.
For example, if my Action opens a Dialog: Do I call the callback after showing the Dialog or do I have to pass it to the Dialog and call it on a click on save button? What if my Dialog does not change an item, but only displays infos (read only)?


New ‘phantom event-handler’ bug in Conversation service

After the latest Conversation updates, I noticed a bug that prevents one from getting rid of the ‘Prompt for everything’ setting. Specifically, this is what is happening:

1- Months ago I created a node with slots with ‘Prompt for everything’ checked. I then added a specific prompt here.

2- In the last few days, I’ve been attempting to get rid of the above setting with no success. What happens is that the old prompt remains in the work space as a ‘phantom’ event handler node (that is, a node with the following characteristics: {“type”: “event-handler”, “event-name”: “focus”, etc.} and it continues being used by the conversation service when there are no slots filled in, even though I’ve un-checked the ‘prompt for everything’. I’ve tried re-checking the ‘prompt for everything feature’ again, changing the original prompt to something else, which results in the ‘something else’ being shown instead. However, when I revert to un-check the ‘prompt for everything’ feature, then the original prompt (which I entered months ago) shows up again. This confirms that this old node is now a ‘phantom node’ and is breaking the expected behavior.

Moreover, another symptom of this problem is the the node ‘customize’ editor displays a count of event handlers than is exactly one more than the handlers it actually lists in the GUI (that is, I happen to have 2 node-level handlers listed, but the count displays the number 3).

Could somebody at IBM please look into fixing this asap? I imagine that a work-around until then might be to mess up directly with the json in the workspace (that is, export the workspace as json, update the json file and then import it onto a different workspace) but I haven’t tried this out, and, needless to say, I’d rather avoid this ‘unsafe’ practice. Thanks!


How can I capture an onKeyPress event in the BPM UI Toolkit Text control?

I am working in IBM BPM 8.6 converting Heritage Human services with Heritage coaches to Client Side Human Services. One of our coaches uses the onKeyPress event that used to be available on the Text control to capture when the enter key is press so with can click a button using javascript. This allows the user to hit enter when they have finished with the last field and the flow moves to the next coach.

Is there any way I can do this with the Text control in the BPM UI Toolkit? There isn’t an onKeyPress option in the Events of the Text control. I’ve read through the documentation on User-defined events. I tried creating a view with the Text control in it with an event variables, but I’m clear on how to actually connect the event in my view to the actual onKeyPress event when it fires. Unfortunately, I know enough javascript to do some coding, but I don’t have advanced skills.

Is there a fairly easy way to accomplish this or this something I should be submitting an RFE for?