[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

3876.0. "More TSAM problems" by SNOC01::MISNETWORK (MCC=My Constant Confusion) Wed Oct 07 1992 23:30

    RE 3580, 3782, 3838 and any other poor souls out there using TSAM.

    The problem of not being able to register MS100s, and no support
    for the MS380s is bad enough, but now I find that there is a problem
    when I start using alarms on MS300s. THIS IS FRUSTRATING!!!!!

    I have 4 MUXserver 300s, and 12 alarm rules polling these, basically 2
    rules for each link as follows -

    (CHANGE_OF(TERMINAL_SERVER .S.SNOM04 LINK B LINK STATUS,Running,*),-
        AT EVERY 00:00:30),  or

    (CHANGE_OF(TERMINAL_SERVER .S.SNOM04 LINK B LINK STATUS,*,Running),-
        AT EVERY 00:00:30)

    I tested these alarms individually to be sure that they worked. But
    when I enable all the alarms individually via a command script, I get a
    reliability problems. I check the status of the alarms, only to find
    that they are running, enabled and that the last result of evaluation is
    in progress, but they never go out and poll the MUXservers. Hence all
    the alarm counters remain at zero. If I then try to disable them, my
    process ends up in RWMBX state. This does not happen all the time, but
    it happens!

    I have tried enabling the alarms from batch, via FCL, via FCL fired up
    from the Iconic Map and via the Iconic map, all have the same symptoms.

    This is not good guys. I have one particular customer who has been
    waiting for TSAM ( without bugs ) since last year, and they will
    definately cancel their DECmcc lease when they find this problem.
    A SOLUTION IS NEEDED URGENTLY !!!!!!

    Cheers,
    Louis
T.RTitleUserPersonal
Name		DateLines
3876.1The mice are running as fast as they canTOOK::FONSECAI heard it through the Grapevine...Thu Oct 08 1992 12:2331
I suggest that you grab the new TSAM kit I've described in 3.last.
That may fix some of your hanging problems.  But not all...

I'm sure I've said this before, but I'll say it again.  TSAM is slow.
If the *all* of the commands you are running alarms on won't
run in the time you have allotted for the repeat interval, you'll
just overload TSAM.

So in your example, you have got 16 SHOW commnads being executed against
TSAM every 30 seconds.  It just won't work.  TSAM takes much longer
for each individual command to execute, and because of the way it was designed
all of those requests get queued up through one process.

Figure out how long the commands that you are alarming on take,
and set up your repeat time that way.
If the only alarms going through TSAM were these sixteen SHOWS,
and we had figured out that each command takes 5 seconds, then
the repeat interval for each alram rule should at minimum be
5*16=80 seconds.  I would make it two minutes, since you want your
alarms to be reliable, and you also want there to be breathing room
for you to execute other interactive TSAM commands on demand.

I'm completely aware of your frustration with slowness.  I got here
long after the design for TSAM had this bottleneck. (whose presence
was neccessary but not insurmountable.)
You need to let product management (Laurel BLUMON::Nelson) know that
speed in this product is important.

Good luck...

Dave
3876.2New kit and interval worksSNOC01::MISNETWORKMCC=My Constant ConfusionSun Oct 11 1992 23:0523
    Thanks for the quick reply Dave.
    
    I have installed the kit you mentioned, and increased the repeat
    interval to 50 secs for now (10 secs below your recommendation), and all 
    seems to be working fine now. I will see how reliable they are, and if
    need be extend the interval. 
    
    The need for the smallest interval as possible is, like most alarms,
    driven by the fact that we need to know about outages before the users
    call us. The way I have set these alarms up for now is I check the link
    status every 50 secs, another alarm is monitoring these alarms checking
    for any exceptions, and if 3 exceptions occur in 3 minutes, then
    another alarm is triggered to check the status of the server, and
    depending on the result, a message is sent to us telling us either the
    server's console is in use, or whatever else the error is. I will be
    simplifying this soon by using the data collector in conjunction with
    the link status rules.
    
    Might need to let product management that TSAM shouldn't mean Terribly
    Slow Access Module  =8')
    
    Cheers,
    Louis
3876.3TOOK::FONSECAI heard it through the Grapevine...Mon Oct 12 1992 10:563
Glad to see this helped.  Terribly Slow AM... gotta remember that one! :-)

-Dave
3876.4TSAM+Data Collector works wellSNOC01::MISNETWORKMCC=My Constant ConfusionMon Oct 12 1992 22:0211
    
    All is well !!!!!!
    
    Have setup the polling interval to be 1 minute, and am using the data
    collector to tell me when the MUXserver links are down/up, and also to
    notify us when the server is down (Cannot communicate with target). If
    the console is use, nothing happens (we donnot get notified)
    
    Cheers,
    Louis