Hi, In Spectrum 9.2H03 I have a lots of problems with discovery related tasks (autodiscovery, discover connections and connect with). A lot of times, this tasks never end. So I cannot launch other discovery process (a popup window tells me discovery is already running). And memory starts growing until finally SS dies!!! In this cases I cannot either stop SS manually. I have to kill -9 the process.
When is there going to be a new HotFix or ServicePack to fix this great amount of bugs in Spectrum 9.2???? It's unusual that CA doesn't release anything in so long time!!! And it's also unusual that CA release a Spectrum version with so many bugs!!! Regards. James. On Mon, Mar 28, 2011 at 8:22 PM, Pfleger, Jim <[email protected]> wrote: > 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] --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
