T.R | Title | User | Personal Name | Date | Lines |
---|
4964.1 | Try enrolling Alarms | MOLAR::ROBERTS | Keith Roberts - Network Management Applications | Wed Apr 28 1993 09:21 | 6 |
| I don't know what is causing the problem .. but you can try to
re-create the Alarms MIR by enrolling Alarms again ...
MCC> enroll mcc_alarms_fm
/keith
|
4964.2 | That worked - but why? | RDGENG::PRATT | | Wed Apr 28 1993 09:27 | 11 |
| Hi Keith,
Re-enrolling the alarms fm fixed the problem, but do you have any idea why it
went wrong? The system has been up for 38 days.
Is there anything I can do to try and capture any error messages etc, that may
give a clue should it happen again.
Thanks
Ian
|
4964.3 | MIR-of-all-MIR's must have forgot about Alarms | MOLAR::ROBERTS | Keith Roberts - Network Management Applications | Wed Apr 28 1993 14:25 | 14 |
| >> but do you have any idea why it went wrong ?
No .. When you enroll Alarms, it tries to create the Alarms MIR's.
All other Alarm directives simply try to access the MIR, but not
re-create it. Why suddenly the MIR was thought not to exist is beyond
me. There is a MIR-of-all-MIR's file which describes all other MIR's.
I imagine that the information in this file was lost or something.
Did you loose *any* rules? If not, the Alarm MIR's themselves were not
lost, just the MIR-of-all-MIR's forgot about Alarms.
Any MCC-Kernel-Types got an idea ?
/keith
|
4964.4 | date problem? | RACER::dave | Ahh, but fortunately, I have the key to escape reality. | Wed Apr 28 1993 14:48 | 9 |
| I have seen this too, and it was related to the "MIR of all MIRs", as you
put it, having the wrong date for the creation of the MIR. That may not be
the case this time, but if you adjust the system date (I.e. set it back) after
creating a MIR, then the MIR will not "exist", even if it is actually there.
after the correct amount of time, the MIR will suddenly "re-appear".
There was a problem with VMS 5.5-something upgrades that caused the system to
get a date that was a year early. I did not notice it until I had installed
MCC, and had to re-create all the MIRs to get them seen after I set the date
to the correct value.
|
4964.5 | | RDGENG::PRATT | | Thu Apr 29 1993 14:38 | 16 |
| Re: .3
I did not lose any alarm rules.
Re: .4
No - no upgrades have been down recently - in fact the last installation was MCC
V1.3 (and that was when the SSB kit shipped). The system time is correct.
It is a bit worrying as I only noticed it after a couple of days when I realised
that I hadn't been receiving my usual daily collection of alarms. I will keep
an eye on it in the future and see if it happens again.
Cheers
Ian
|
4964.6 | system time is Ok, but check the MCC_TDF logical for the correct value | MOLAR::ROBERTS | Keith Roberts - Network Management Applications | Thu Apr 29 1993 17:09 | 0 |
4964.7 | TDF was wrong | RDGENG::PRATT | | Fri Apr 30 1993 07:29 | 12 |
| Hi Keith,
I had forgotten to change the MCC TDF when the clocks changed (remembered DNS).
It did manage to work for 3 weeks before it went wrong though.
Thanks for your help.
I'll remember to change when the clocks go back.
Cheers
Ian
|
4964.8 | Alarms repository problem still exists... | CUJO::HILL | Dan Hill-Net.Mgt.-Customer Resident | Wed Nov 03 1993 00:46 | 10 |
| I have encountered this problem along with a DSPMMLOCFILERR,
Dispatch local management module file access during probe.
I have tried everything suggested in these and other notes, but nothing
works.
Any ideas??
Thanks,
Dan
|
4964.9 | It was a problem with time... | CUJO::HILL | Dan Hill-Net.Mgt.-Customer Resident | Wed Nov 03 1993 14:40 | 6 |
| Seems that I had neglected to check the system date/time completely.
The time was correct, but the system manager had put in 1990 instead of
1993 as the year. Once this and MCC_TDF were set properly, everything
worked "magically".
-Dan
|