| You mention MTU. Should we infer that this only happens when the customer
selects an SNMP object? Or does it happen for *other* objects ? I.e. do
you see the same behavior for NODE4, STATION, BRIDGE, etc object?
/doug
|
| re .1
MTU as in the mib translator.
The network in question is primarilly IP, no PhIV, PhV, or bridge
devices.
The real question remains what causes this error?
Any takers before I dial up engineering??
Jack
|
| Ok. Let's start over and try to nail it down a bit more.
re .0
> Previously he found: When selecting a system from the map
> pulling down it CHARS, then querying for interfaces he was
> getting back a successful response.
>
In the interest of boing precise, I assume you mean that from the
Iconic Map:
1. the user is selecting an SNMP object,
2. double-clicking to get to the "Interface..." child object
3. double-clicing on "Interface" to enumerate the avaiable
interfaces on the object
4. selecting an interface from the list
5. going to the Operations Menu
6. selecting "SHOW -> Characteristics".
7. At that point, the user gets the error.
Is this what you mean?
> Now when he does a query (from most any system except himself)
> he is getting:
> VMS routine error 0
> MCC Routine %MCC-E-ILVEOC, end of constructor reached
Do you mean "...for most any system except..." ?
^^^
If so, then what sort of SNMP obects are you selecting to return this
error?
re .2
>
> The real question remains what causes this error?
>
And my questions remains: what happens when you try a SHOW to something
OTHER than an SNMP object? I'm trying to help you narrow this down
and it might be premature to point at the SNMP AM -- at least without
first doing a little bit of kicking the tires. (Reminds me of a joke
about Field Service... ;^))
For future reference: when you want to know what an error message is
*supposed* to indicate, you can look it up in the SRM -- sorry I'm at
home right now, otherwise I'd look up the exact text on this one for
you. Notice that I said 'supposed' to indicate -- sometimes developers
have been known return the wrong code for an error. It doesn't happen
often, but it can happen.
/doug.
|
|
> In the interest of boing precise, I assume you mean that from the
> Iconic Map:
> 1. the user is selecting an SNMP object,
> 2. double-clicking to get to the "Interface..." child object
> 3. double-clicing on "Interface" to enumerate the avaiable
> interfaces on the object
> 4. selecting an interface from the list
> 5. going to the Operations Menu
> 6. selecting "SHOW -> Characteristics".
> 7. At that point, the user gets the error.
>
> Is this what you mean?
under normal conditions 1-6 work fine. His error comes
randomly when he is executing step 2. Then the illegal
constructor error occurs. Since this is all via the
DEC mib (already defined inside the application), and
since he has been "messing" extensively with the MIBS,
my suspicion is he's corrupted the db.
Today he also noted he was seeing this occur a few times
at the original install after they had tried out "a few things"
(we had a parallel problem with the DTK when they had installed
it without putting in ULTPGM, and then were having thread errors)
with the system.
>> Now when he does a query (from most any system except himself)
>> he is getting:
>> VMS routine error 0
>> MCC Routine %MCC-E-ILVEOC, end of constructor reached
>
>
> Do you mean "...for most any system except..." ?
^^^
YES, FOR, not FROM
> If so, then what sort of SNMP obects are you selecting to return this
> error?
This is all during the above step 2-3.
re .2
>
> The real question remains what causes this error?
>
> And my questions remains: what happens when you try a SHOW to something
> OTHER than an SNMP object? I'm trying to help you narrow this down
> and it might be premature to point at the SNMP AM -- at least without
> first doing a little bit of kicking the tires. (Reminds me of a joke
> about Field Service... ;^))
>
The problem is they have NO components other then IP on there
network, so there is nothing registered to query against.
(I wish there were!!, and there network config is so tightly managed
they need a 3 team agreement to add components or change MCC!)
> For future reference: when you want to know what an error message is
> *supposed* to indicate, you can look it up in the SRM -- sorry I'm at
> home right now, otherwise I'd look up the exact text on this one for
> you. Notice that I said 'supposed' to indicate -- sometimes developers
> have been known return the wrong code for an error. It doesn't happen
> often, but it can happen.
>
> /doug.
We've been battling with SSB to send us the ULTRIX MCC kits,
but they keep scheduling us for the VAX/VMS kits, I've been
hunting the SRM on the network as a result.
thanks for the assistance,
Jack
|