Jim,

We are facing many problems with missing alarms on SRM. Sometimes the
outage takes longer on SRM than on DDM archive (the DDM matches the real
device). Sometimes the outage is missing at all. We opened a case and CA
recognized it as a bug. We're still waiting for a patch.
My ver. is 9.1.3 H15.
Sincerely.





Rogério Ferreira da Cunha
------------------------------------------------------------------------------

TIC/ADS-TC/ORS
Consultor
Tel: +55-21-3487-6848  Rota:  818-6848
[email protected]





De:     "Pfleger, Jim" <[email protected]>
Para:   "spectrum" <[email protected]>
Data:   28/03/2011 15:23
Assunto:        [spectrum] Problems with Spectrum 9.2 H03



I wanted to share with everyone some of the problems we’ve had with
Spectrum that we’re currently working with CA in the hopes that knowing
about them will help out others. I don’t know if they are specific to 9.2
H03, but I do know that they all exist on this version.

      SRM missing alarms. The SRM alarm table is missing alarms that the
      SRM event and outage tables say should be there. We originally found
      this when going through the outages table and trying to match up
      outages to alarms so we could get their trouble ticket IDs. As we’ve
      continued to work this, we’ve been able to craft a query that matches
      the number of 0x10701 events (“Alarm will be generated”) with the
      number of alarms actually in SRM for the same time period. If anyone
      would like to check the consistency of their SRM databases, contact
      me directly for the query. CA has accepted this as an issue and is
      working to determine a cause.
      Condition correlation engine does not resuppress. This one takes a
      bit of explaining, so please bear with me. Suppose you have a simple
      network like this:
            SS --- A --- B
      If B goes down, you will get several alarms, including “blade status
      unknown”, “chassis down”, and “device not responding to polls”. In
      our environment, we have a condition correlation that will use
      “device not responding” to suppress the other two, so the operators
      see one root cause, and two hidden symptoms. Now if A goes down, it
      will suppress B. Specifically, the “device not responding” alarm on B
      is cleared and immediately replaced with an “all device connections
      are unreachable” alarm. The problem is that, with the original
      “device not responding” alarm on B now cleared, there is nothing to
      suppress the “blade status unknown” and “chassis down” alarms, which
      now display to the operators. Logically, the alarm on A that is
      suppressing B should also be used to resuppress all the alarms on B,
      but this doesn’t happen. CA has accepted this as an issue, and
      created a patch that we’re currently testing.
      Notifier duplicating or not sending alarms. We’ve received two
      different patches for Notifier – one was for it occasionally acting
      on an alarm twice (about 1.5% of alarms), and the other was for it
      not acting on an alarm at all (about 0.1% of alarms). These patches
      were merged together into D89a.

These are the ones that I think will be of wide interest. When I have
substantial updates to share with the group, I will definitely do so.

If you’re seeing other strange behaviors, or have any questions about
these, please contact me to discuss. I think that an open flow of
information about these sorts of issues benefits us all.

Jim


--
JIM PFLEGER  |  Application Architect  |  Insight  |  insight.com

t. 480.889.9680 f. 480.889.9599  [email protected]

      --To unsubscribe from spectrum, send email to [email protected] with
      the body: unsubscribe spectrum [email protected] 
"O emitente desta mensagem é responsável por seu conteúdo e endereçamento. Cabe 
ao destinatário cuidar quanto ao tratamento adequado. Sem a devida autorização, 
a divulgação, a reprodução, a distribuição ou qualquer outra ação em 
desconformidade com as normas internas do Sistema Petrobras são proibidas e 
passíveis de sanção disciplinar, cível e criminal."
 
"The sender of this message is responsible for its content and addressing. The 
receiver shall take proper care of it. Without due authorization, the 
publication, reproduction, distribution or the performance of  any other action 
not conforming to Petrobras System internal policies and procedures is 
forbidden and liable to disciplinary, civil or criminal sanctions."
 
"El emisor de este mensaje es responsable por su contenido y direccionamiento. 
Cabe al destinatario darle el tratamiento adecuado. Sin la debida autorización, 
su divulgación, reproducción, distribución o cualquier otra acción no conforme 
a las normas internas del Sistema Petrobras están prohibidas y serán pasibles 
de sanción disciplinaria, civil y penal."

---
To unsubscribe from spectrum, send email to [email protected] with the body: 
unsubscribe spectrum [email protected]

<<inline: graycol.gif>>

Reply via email to