[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| 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 |
2464.0. "VMS BMS X1.2.15 Alarms - INV_HANDLE" by RDOSW1::PARKER () Mon Mar 02 1992 23:30
Hi,
The following Alarm Rule on VMS 5.5 - DECmcc/BMS 1.1 works correctly; now in
VMS 5.5 - DECmcc/BMS x1.2.15 - Internal error... & INV_HANDLE...
!
! =: Monitor Circuit Counters Zeroed :=
!
CREATE MCC 0 ALARMS RULE RDOSW1_FAST_POLL -
EXPRESSION = (OCCURS(NODE4 RDOSW1 CIR sva-0 COUNTERS ZEROED)) ,-
DESCRIPTION = "Circuit counters Zeroed" ,-
PROCEDURE = MCC_COMMON:MCC_ALARMS_MAIL_ALARM.COM ,-
EXCEPTION HANDLER = MCC_COMMON:MCC_ALARMS_MAIL_EXCEPTION.COM ,-
PARAMETER = "RDOSW1::parker" ,-
PERCEIVED SEVERITY = MAJOR ,-
IN DOMAIN RICHMOND
.....
Welcome to VAX/VMS version V5.5 on node RDOSW1
Last interactive login on Monday, 2-MAR-1992 22:03
Last non-interactive login on Monday, 2-MAR-1992 22:11
Proceed...
sw1 mana/enter
DECmcc (X1.2.15)
MCC> show mcc 0 alarms rule rdosw1_fast_poll all char, in domain richmond
MCC 0 ALARMS RULE rdosw1_fast_poll
AT 2-MAR-1992 22:16:17 Characteristics
Examination of attributes shows:
Procedure =
SYS$COMMON:[MCC]MCC_ALARMS_MAIL_ALARM.COM;4
Exception Handler =
SYS$COMMON:[MCC]MCC_ALARMS_MAIL_EXCEPTION.COM;4
Description = "Circuit counters Zeroed"
Parameter = "RDOSW1::parker"
Expression = (OCCURS(NODE4 RDOSW1 CIR sva-0
COUNTERS ZEROED))
Perceived Severity = Major
Probable Cause = Unknown
MCC> show node4 rdosw1, in domain richmond
Using default ALL IDENTIFIERS
Node4 36.702
AT 2-MAR-1992 22:16:54 Identifiers
Examination of Attributes shows:
Address = 36.702
Name = RDOSW1
MCC> !
MCC> ! a batch job will zero the circuit counters
MCC> !
MCC> notify domain richmond
%MCC-S-NOTIFSTART, Notify request 1 started
MCC> enable mcc 0 alarms rule rdosw1_fast_poll, in domain richmond
MCC 0 ALARMS RULE rdosw1_fast_poll
AT 2-MAR-1992 22:20:28
Normal operation has begun.
MCC> show mcc 0 alarm rule rdosw1_fast_poll all status, in domain richmond
MCC 0 ALARMS RULE rdosw1_fast_poll
AT 2-MAR-1992 22:20:46 Status
Examination of attributes shows:
State = Enabled
Substate = Running
Result of Last Evaluation = In progress
Current Severity = Major
MCC> show mcc 0 alarm rule rdosw1_fast_poll all status, in domain richmond
MCC 0 ALARMS RULE rdosw1_fast_poll
AT 2-MAR-1992 22:20:56 Status
Examination of attributes shows:
State = Enabled
Substate = Running
Result of Last Evaluation = In progress
Current Severity = Major
MCC Alarms internal error (Rule Driver): Could not delete
callargs->p_handle : 52876210
!!!!!!!!!!!!!! Alarm, 2-MAR-1992 22:21:08 !!!!!!!!!!!!!! [1]
Domain: RDOSW1_NS:.richmond
Severity: Major
Notification Entity: Node4 RDOSW1_NS:.RDOSW1 Circuit SVA-0
Event Source: Domain RDOSW1_NS:.richmond Rule rdosw1_fast_poll
Event: OSI Rule Disabled
Event Type = QualityofServiceAlarm
Event Time = 2-MAR-1992 22:21:06.50
Probable Cause = Unknown
Additional Info = { (
significance = True,
information = "%MCC-E-INV_HANDLE, software
error: invalid handle parameter"
),
(
significance = True,
information = "(OCCURS(NODE4 RDOSW1 CIR sva-0
COUNTERS ZEROED))
" ) }
Managed Object = Node4 36.702 Circuit SVA-0
Perceived Severity = Major
Additional Text = "Circuit counters Zeroed
"
MCC> show mcc 0 alarm rule rdosw1_fast_poll all counte, in domain richmond
MCC 0 ALARMS RULE rdosw1_fast_poll
AT 2-MAR-1992 22:21:43 Counters
Examination of attributes shows:
Creation Timestamp = 2-MAR-1992 22:20:28.48
Evaluation True = 1
Evaluation False = 0
Evaluation Error = 0
MCC> show mcc 0 alarm rule rdosw1_fast_poll all status, in domain richmond
MCC 0 ALARMS RULE rdosw1_fast_poll
AT 2-MAR-1992 22:21:49 Status
Examination of attributes shows:
State = Disabled
Substate = Disabled by error condition
Disable Time = 2-MAR-1992 22:21:06.50
Result of Last Evaluation = True
Error Condition = "%MCC-E-INV_HANDLE, software error:
invalid handle parameter"
Current Severity = Major
MCC> !
MCC> ! Note: no mail notification message about this alarm was
MCC> ! sent (IMPM or FCL).
MCC> ! IMPM notification happens correctly (salience, Notification window
MCC> ! & Graph). The rule is disabled as above.
MCC> exit
I also looked at note 2058 and checked for older images and found two entries
for MCC_TCPIP_AM.EXE;5. One is at DKA200:[SYS0.SYSCOMMON.SYSLIB], the other
is DKA200:[VMS$COMMON.SYSLIB]. File Id is the same, so that's not it - I think??
Help/Suggestions greatly appreciated.
Jeff.
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2464.1 | We thought we killed this bug 8( | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Tue Mar 03 1992 09:24 | 16 |
| Jeff,
This error has been seen before (and thought to have been fixed). Some
clean up code is not getting executed correctly when an error occurs.
Q) Can you reproduce this every time?
Q) Could you try the same test, but instead of using an Alarm Rule to
catch the event ... do this:
getevent node4 rdosw1 cir sva-0 counters zeroed, for duration 01:00:00
This is the command which Alarms executes to get the event data.
Thanks,
/keith
|
| 2464.2 | Log of getevent looks Ok. | RDOSW1::PARKER | | Tue Mar 03 1992 13:27 | 106 |
| Hi Keith,
Yes. The sequence in .0 happens each time the rule fires (IMPM & FCL).
Here's a log of the getevent...
.
.
.
sw1 mana/enter
DECmcc (X1.2.15)
MCC>
MCC> notify domian richmond
%MCC-S-NOTIFSTART, Notify request 1 started
MCC> getevent node4 rdosw1 cir sva-0 counters zeroed, for duration 01:00:00
Node4 36.702 Circuit SVA-0
AT 3-MAR-1992 12:51:13 CONFIGURATION EVENTS
Successfully received events:
Event: Counters Zeroed
Circuit counters zeroed
Seconds Since Last Zeroed = 46 Seconds
Terminating Packets Received = 0 Packets
Originating Packets Sent = 0 Packets
Terminating Congestion Loss = 0 Packets
Transit Packets Received = 0 Packets
Transit Packets Sent = 0 Packets
Transit Congestion Loss = 0 Packets
Circuit Down = 0
Failure to Initialize = 0
Adjacency Down = 0
Peak Adjacencies = 1
Data Blocks Sent = 3 Blocks
Bytes Sent = 150 Bytes
Data Blocks Received = 6 Blocks
Bytes Received = 561 Bytes
Unrecognized Frame Destination = 0 Errors
User Buffer Unavailable = 0 Errors
Node4 36.702 Circuit SVA-0
AT 3-MAR-1992 12:52:00 CONFIGURATION EVENTS
Successfully received events:
Event: Counters Zeroed
Circuit counters zeroed
Seconds Since Last Zeroed = 47 Seconds
Terminating Packets Received = 0 Packets
Originating Packets Sent = 0 Packets
Terminating Congestion Loss = 0 Packets
Transit Packets Received = 0 Packets
Transit Packets Sent = 0 Packets
Transit Congestion Loss = 0 Packets
Circuit Down = 0
Failure to Initialize = 0
Adjacency Down = 0
Peak Adjacencies = 1
Data Blocks Sent = 3 Blocks
Bytes Sent = 150 Bytes
Data Blocks Received = 6 Blocks
Bytes Received = 561 Bytes
Unrecognized Frame Destination = 0 Errors
User Buffer Unavailable = 0 Errors
Node4 36.702 Circuit SVA-0
AT 3-MAR-1992 12:53:33 CONFIGURATION EVENTS
Successfully received events:
Event: Counters Zeroed
Circuit counters zeroed
Seconds Since Last Zeroed = 47 Seconds
Terminating Packets Received = 0 Packets
Originating Packets Sent = 0 Packets
Terminating Congestion Loss = 0 Packets
Transit Packets Received = 0 Packets
Transit Packets Sent = 0 Packets
Transit Congestion Loss = 0 Packets
Circuit Down = 0
Failure to Initialize = 0
Adjacency Down = 0
Peak Adjacencies = 1
Data Blocks Sent = 3 Blocks
Bytes Sent = 150 Bytes
Data Blocks Received = 7 Blocks
Bytes Received = 686 Bytes
Unrecognized Frame Destination = 0 Errors
User Buffer Unavailable = 0 Errors
%MCC-E-INV_HANDLE, software error: invalid handle parameter
MCC> ! My fault,
MCC> ! I just did a control-C to abort the getevent & the inv_handle message
MCC> ! was displayed, then the mcc prompt.
MCC> !
MCC> ! Out of curiosity, I'll abort the getevent before the event occurs...
MCC> !
MCC> !
MCC> getevent node4 rdosw1 cir sva-0 counters zeroed, for duration 01:00:00
MCC> !
MCC> ! control-C before the event occurred just returned the mcc prompt.
MCC> !
MCC> exit
sw1
Let me know if there's more I can check.
Jeff.
|
| 2464.3 | Similar problem already QAR'd -- will add your details | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Thu Mar 05 1992 14:29 | 12 |
| Jeff,
I have tried the same rule on decnet events as you have and see the
same problem .. this is good, and will make it pretty easy to track and
fix.
A QAR on a similar INV_HANDLE problem has already been filed, #02433.
I will add your details to this QAR.
Thank you,
/keith
|
| 2464.4 | Ok. | GRANMA::JPARKER | | Thu Mar 05 1992 19:17 | 7 |
| Hi,
Ok to the QAR.
Regards,
Jeff.
|
| 2464.5 | Status of QAR #02433 ?? | GIDDAY::BROOKS | | Thu Apr 30 1992 01:31 | 10 |
|
Could someone please supply me with a status of the QAR associated
with this note. QAR #02433.
Has this problem been addressed by baselevel 19??
Thanks in advance
Niguel Brooks
SNO CSC
|
| 2464.6 | fixed in T1.2.7 | TOOK::MINTZ | Erik Mintz, DECmcc Development, dtn 226-5033 | Thu Apr 30 1992 11:09 | 4 |
| We have fixed a number of problems in this area for T1.2.7
This particular flavor can no longer be reproduced.
The QAR has been closed.
|