| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 972.1 | Bad IP address format, but wait... | MKNME::DANIELE | | Wed May 01 1991 09:35 | 27 |
| > Can anyone tell me what "Internal Logic Error 100" means?
Dan Carr is out until at least Thursday, so I'll barge in.
From a quick scan of the code, it means (at least) 3 things:
1. The user is running the X1.1 prototype AM, not the V1.0 AM.
2. The problem statement seems incorrect, since the code in question
cannot return the "No Such Entity" exception AND Internal Error 100
in the same response. (Perhaps I've misunderstood the question.)
3. Internal Error 100 means the gethostbyname() call returned an
IP address whose length is not 4 bytes. This makes me suspect
UCX and BIND again.
Could you try/suggest this?
After system startup, try issuing commands to UCX to translate the
names used as global SNMP identifiers:
$ UCX> SHOW HOST mumble
If these work, but the AM still can't translate them, we have a problem.
Some time after startup does the system reach a steady state, where
all the alarm rules work as expected?
Mike
|
| 972.2 | | KERNEL::RWATSON | UK CS Product & Tech Group | Wed May 01 1991 14:15 | 21 |
| Hi Mike
Thanks again for your help.
I've already asked the engineers involved to check the versions and
also to check out UCX. I've suggested to them that they write some DCL
to repeatedly ask UCX to translate names and see if by beating it up we
will get a failure. I've also asked them to check if the names are held
locally, and if not then maybe we can try this as a work around and
eliminate BIND.
As for the problem statement - I'll go back and check the sequence of
events, but I think the "Internal Logic Error" is being returned when
the rule has fired but has not failed with the "No such Entity" reason
- ie its fired for some other reason. Sorry if I mislead you here!
Well go and look at UCX/BIND in some details and post the results.
Thanks again for looking up the code
Bob
|
| 972.3 | | KERNEL::RWATSON | UK CS Product & Tech Group | Thu May 02 1991 13:17 | 15 |
|
The version of the SNMP AM is V1.0.0 according to ANA/IMAGE and
tomorrow we will have the engineer's onsite double check this through
the MCC interface.
Today they experimented with putting the global entity names that UCX
is looking up into the local UCX database, and apparently this had
little effect - ie the "No Such Entity" error still occurred. I'll have
this double checked again tomorrow, but if this is the case then it
appears to eliminate the UCX/BIND theory.
Regards
Bob
|
| 972.4 | it's X1.1 | MKNME::DANIELE | | Thu May 02 1991 13:45 | 18 |
| > The version of the SNMP AM is V1.0.0 according to ANA/IMAGE and
> tomorrow we will have the engineer's onsite double check this through
> the MCC interface.
The image ident field was not modified for the X1.1 prototype.
Check out the date, it will be 16-Nov-90. It's the X1.1 prototype,
because logic error 100 is not in the V1.0 image.
> ie the "No Such Entity" error still occurred. I'll have
> this double checked again tomorrow, but if this is the case then it
> appears to eliminate the UCX/BIND theory.
Are the host names resolveable by UCX before the alarms are enabled?
Are you sure it's the No Such Entity exception, which also lists
the entity name, and not the "No such entity in dictionary" error?
Mike
|
| 972.5 | Ok- so now we will check the date | KERNEL::RWATSON | UK CS Product & Tech Group | Fri May 03 1991 14:00 | 42 |
|
We seem to always be just one step behind you...
> The image ident field was not modified for the X1.1 prototype.
> Check out the date, it will be 16-Nov-90. It's the X1.1 prototype,
> because logic error 100 is not in the V1.0 image.
ok - so yesterday we were asked to check the version using the SHOW
MCC 0 TCPIP AM command and this returned V1.0.0. ANA/IMAGE also
returned V1.0.0. What your saying is _both_ these field may not have
been updated - Yes?
I'll have to get the engineer from France to go back to site (its not a
short trip I am afraid) and check the date now. I appreciate the
importance of checking that its the right version - we did what we
thought were valid checks before starting this call.... but clearly
because the image idents were not upto date these checks may have been
invalid.
> Are you sure it's the No Such Entity exception, which also lists
> the entity name, and not the "No such entity in dictionary" error?
Yes. I have a fax in front of me showing the output from the log
showing:
Expression: (SNMP MUCIA2 SYSUPTIME < 0 ,AT EVERY 0:0:30)
Data: No such entity: SNMP MUCIA2
Finally - we have also had the customer turn off BIND and load the name
into the local UCX database and this problem is still seen.
Anyway - we will go back to site again to check the date. This will not
happen now until Monday now.
Regards
Bob Watson
|
| 972.6 | UCX show host, please | MKNME::DANIELE | | Fri May 03 1991 16:27 | 38 |
| > ok - so yesterday we were asked to check the version using the SHOW
> MCC 0 TCPIP AM command and this returned V1.0.0. ANA/IMAGE also
> returned V1.0.0. What your saying is _both_ these field may not have
> been updated - Yes?
No. What I'm telling you is that logic error 100 is part of
NEW code that was added AFTER V1.0, when I added TCP/IP socket
support to the AM. I'm asking you to please believe me that your
engineer has the wrong version, and not to expend any more energy
on this aspect of the problem.
> Yes. I have a fax in front of me showing the output from the log
> showing:
> Expression: (SNMP MUCIA2 SYSUPTIME < 0 ,AT EVERY 0:0:30)
> Data: No such entity: SNMP MUCIA2
> Finally - we have also had the customer turn off BIND and load the name
> into the local UCX database and this problem is still seen.
OK, let's concentrate on this problem, which has nothing to do
with logic error 100. One thing I HAVE asked you to do twice now
is to show me UCX being able to resolve the host name. Please
have your engineer provide a log of:
$UCX> show host MUCIA2
$MCC> show snmp MUCIA2 all attributes
$MCC> enable mcc 0 alarm rule whatever
that shows the failure.
Could this be simply that the UCX host name is defined in lower
case, so the DECmcc attempt to translate the upper case name fails?
Regards,
Mike
|
| 972.7 | humble apologies... | KERNEL::RWATSON | UK CS Product & Tech Group | Tue May 07 1991 05:17 | 29 |
|
Hi Mike
MAN/ENT
sho mcc 0 tcpip all char
---> version v1.0.0
ANALYSE/image MCC_TCPIP_AM.EXE
---> MCCTCPIP v1.0-0
link date 16-NOV-1990 18:18:40.32
link ident "05-05"
> I'm asking you to please believe me that your
> engineer has the wrong version, and not to expend any more energy
> on this aspect of the problem.
ok - ok I'm convinced!
Sorry, I did not mean to doubt you - it was just that there appeared to
be alot of evidence showing the AM was V1.0. However now they've
checked the versions and sure enough its 16-Nov-1990. Apologies for
wasting your time here! We'll get the correct stuff installed.
I'll follow up on the other part of the problem and the tips you've
given once we've shown they still happen with the wrong version.
Regards
Bob
|
| 972.8 | Apologies again , solution perhaps... | STRASB::MOSER | Jean-Marc MOSER -- Strasbourg @ZTO | Fri May 17 1991 06:04 | 13 |
|
The end perhaps...
We re-install the SDC TCPIP_AM with link date "4-OCT-1990"
Everything is looking good for the moment...
We think that the X1.1 version must be removed from network access...
Many thanks for Bob and the people who help us to solve our problem.
Best regards
Jean-Marc MOSER
|
| 972.9 | | MKNME::DANIELE | | Fri May 17 1991 11:38 | 14 |
| > We re-install the SDC TCPIP_AM with link date "4-OCT-1990"
> Everything is looking good for the moment...
I'd still like to see a log showing UCX attempting to resolve a host
name for which the SNMP AM returns a "No Such Entity" exception.
It's real hard for me to believe that there is any difference between
the SDC kit and the X1.1 kit in this aspect. Any further data you
could provide would be helpful.
I don't believe there has been network access to X1.1 for several
months, where are you copying from?
Mike
|