| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 755.1 | Another one down to TCPIP? | MINDER::PUNSHON | Universe fixed in next release | Wed Feb 27 1991 07:56 | 21 |
| This may or may not be related, but seems to be a problem.
Upgraded to V1.1 BMS and everything was fine.
Installed TCPIP010 and a problem occurs.
During startup invoking MCC_STARTUP_DNA4_EVL.COM gives
Internal error in DECnet Phase IV AM.
MCC Error = specified tag not found within
current constructor
when trying to
SET node4 kesnue local sink MONITOR name = MCC_DNA4_EVL
What is the problem? Re-installing BMS clears the problem, then adding
TCPIP causes it again.
:-)
Ken
|
| 755.2 | Looks like a bad Dictionary to me. | TOOK::GUERTIN | E = mcc | Wed Feb 27 1991 11:45 | 9 |
| It looks as though your MCC Dictionary has gotten corrupted when you
control-Yed out of the installation. Since MCC is so data-driven,
once the Dictionary is corrupt, stange things start to happen. One
of the first signs is that PTB starts to "toss it's cookies". In
this case, you are better off reinstalling MCC BMS V1.1 (MCS), then
installing TSAM and SNMP on top of it. Assuming the MCC BMS kit
installs cleanly, the others should install cleanly also.
-Matt.
|
| 755.3 | SNMP_AM damages data dictionary.... | TOOK::CAREY | | Thu Feb 28 1991 09:25 | 24 |
|
Re: .2
Matt, I agree that it looks like something ugly happened in DAP after
the control-Y. Ouch.
Re: .1
This seems to be a different problem. The Phase IV AM is complaining
that it cannot interpret the request input argument on the SET request.
It appears that the SNMP AM is stepping on the dictionary in this
situation, and actually instructing the parse tables to use a
different argument for the SET command than the DNA4_AM expects.
The result? At least for the moment, you have to decide whether you
want so manage TCPIP nodes and only look at DECnet, or whether you
would like to be able to SET characteristics of the DECnet entities.
Watch this space for an update to the SNMP kit. This dictionary error
will be addressed in there for sure.
-Jim Carey
|
| 755.4 | **X1.1** of SNMP_AM damages dictionary | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Thu Feb 28 1991 14:24 | 20 |
| <<< TOOK::WORK$214:[NOTES$LIBRARY]MCC.NOTE;2 >>>
-< DECmcc Product Family; Introductions Note 6 >-
================================================================================
Note 3.57 Baselevel update announcements 57 of 57
CHRISB::BRIENEN "DECmcc Bridge|Station|SNMP Management." 13 lines 28-FEB-1991 14:15
-< X1.1 TCPIP SNMP AM kit NO LONGER AVAILABLE >-
--------------------------------------------------------------------------------
RE: Note #3.41 "Latest TCP/IP SNMP AM kit"
The kit announced in note 3.41 (named MCCTCPIP010.A|B but actually
representing an X1.1 [experimental] version with prototype WELLFLEET and
socket interface code) has a problem that can, in some cases, disable the
SET directive support provided by DECmcc for OTHER classes (e.g. BRIDGE,
NODE4, etc).
There is no longer (he said hopefully) network access to this kit.
Please do NOT install this kit (dated 27-Nov-90) on DECmcc V1.1 systems.
Chris Brienen
|
| 755.5 | It's gone | MKNME::DANIELE | | Thu Feb 28 1991 14:52 | 14 |
| Hello world,
There is no longer network access to the ** X.1.1 ** TCP/IP AM kit.
As always, I am somewhat confused by terminology. The fact that
this kit, which defines dictionary entities ONLY for the global
class SNMP and its children, and that up until the most recent
DECmcc V1.1 MCS kit used to work fine, now "has a dictionary
problem" strikes me as somewhat odd.
But...
Clearly PTB has changed somewhere along the line.
Does the V1.0 TCP/IP kit still work with DECmcc V1.1?
|
| 755.6 | error in argument code 4 on attrib list (should be 1) | GOSTE::CALLANDER | | Fri Mar 01 1991 16:53 | 16 |
|
Ptb hasn't changed, but as things go sometimes errors remain hidden.
The problem is in the .MS file used to build the dictionary entries.
The definition of the SET directive was defined with the wrong argument
code for the attribute list argument. This error was not seen until
the SNMP module had children (since the parent entity had no settable
attributes defined). The last entry to put in the directive definition
is the entry used in the parse tables.
Since entity code 1 is the phase 5 entity, and that is an internal
developement effort we might want to consider modifying PTB so that
the first definition is the only one used (for the common directives
defined in the SRM) and not the last one.
jill
|
| 755.7 | Where do I find a correct version of TCP/IP ? | OSLACT::BJORN | Once again | Mon Mar 04 1991 08:08 | 16 |
| I'm still in the process of re-installing DECmcc to get the latest version of
BMS and it's optional modules. I've gotten into a loop where everything goes
wrong, and I have to reinstall BMS each time.
The last one was a unsynchronised shutdown of the node I'm working from.
I started VMSINSTAL and went home after the dictionary update started.
When I got back, I found my workstation rebooted, so I had to got the long way
from re-installing BMS again, and TSAM. TSAM failed again during help update and
left HELP blank!. I guess I forgot to stop the TSAM process. I'm not sure. So
I'll try again from a blank MCC_COMMON.
I'm also planning to re-install TCP/IP AM. Where can I find the previous version
of TCP/IP SNMP AM, which used to work? Isn't there a version which works with
BMS V1.1 SSB?
Bj�rn Olav Haugom
|
| 755.8 | | MKNME::DANIELE | | Mon Mar 04 1991 08:30 | 40 |
| Re .7:
The V1.0 kit pointer is in note 386. My UNDERSTANDING is
that this kit works fine with BMS 1.1.
RE .5,.6:
Yes, I realize the code should be 1, not 4. CMS bug on my part
when building the ("unsupported", interim) release to accompany
DECmcc 1.1 EFT. The point I'm trying to make is simply that
if by defining a code under the SNMP entity the wrong way can
demolish the Phase IV entity, due to what is done to the
parse table by PTB, then perhaps instead of calling this
"dictionary corruption" some thought should be given to how
the tools work.
>This error was not seen until
> the SNMP module had children (since the parent entity had no settable
> attributes defined).
I'm not sure what you mean here, ther have been child entities
defined for SNMP since its internal FT in April of 90.
> The last entry to put in the directive definition
> is the entry used in the parse tables.
> Since entity code 1 is the phase 5 entity, and that is an internal
> developement effort we might want to consider modifying PTB so that
> the first definition is the only one used (for the common directives
> defined in the SRM) and not the last one.
Fwiw, that's exactly how it used to work. The first definer of SET
won. The SNMP AM was passed 1 even though its SET directive was defined
with a argument id of 4.
That's what prompted me to ask about the 1.0 kit, since it appears
something at least is different.
Shouldn't DAP refuse these definitions if they are going to
cause such havoc?
|
| 755.9 | ? | MKNME::DANIELE | | Mon Mar 04 1991 08:33 | 4 |
| And if something significant hasn't changed since 1.1 EFT, how come
none of the FT sites reported any problems?
Curious in Telecomm Engineering ;-)
|
| 755.10 | Rebuilding HELP | SCRPIO::LIZBICKI | | Mon Mar 04 1991 11:24 | 19 |
|
Re: .7
Hello Bj�rn -
With regards to problems building the help files, you should do
the following before trying to rebuild the help files:
$ DELETE MCC_COMMON:*.TOP;*
(The final TSAM kit will do this before attempting to rebuild the
help files during installation.)
It sounds like the dictionary and parse table updates went OK
during your installation, so you don't need to repeat these
steps again. Just answer YES to the help-file build question...
Lynne
|
| 755.11 | It's worse | MKNME::DANIELE | | Tue Mar 05 1991 08:47 | 42 |
| > <<< Note 755.8 by MKNME::DANIELE >>>
> Re .7:
> The V1.0 kit pointer is in note 386. My UNDERSTANDING is
> that this kit works fine with BMS 1.1.
> RE .5,.6:
> Yes, I realize the code should be 1, not 4. CMS bug on my part
> when building the ("unsupported", interim) release to accompany
> DECmcc 1.1 EFT.
I was hallucinating. The request argument code for the SET directive
for SNMP child entities has ALWAYS been 4, not 1. It's the same in
the V1.0 product as it is in the X1.1 interim kit, which means that
V1.0 of SNMP is not going to work on the latest BMS 1.1 system.
For what it's worth, here is what happened. I had a routine that
parsed In_P and switched on the argument code ( the ID of the
constructor, I think ). This wasn't the value of 4 I had defined in
MSL, but rather the value 1. As was explained to me, this was because
PTB's algorithm was 'whoever defines it first wins'. So I modified
the routine and passed it the directive code to switch on. This was all
for the V1.0 SNMP AM.
At some point things changed. I've been told that PTB's algorithm
is now 'whoever defines it last wins'. That change, perhaps in
conjunction with various management modules ( like Phase IV ) adding
new checks on the value of the SET request argument code, has caused
this problem. Whatever combination of changes occurred seems to have
happened after EFT of 1.1, and probably after the first MCS kit, since
no problems like this have been reported until now.
( By 'first' and 'last' I think is meant the value of the global class
codes as processed in numerical order by PTB. SNMP is 18. All other
classes in the BMS dictionary must be < 18. )
Sorry for all the confusion. I'm sure this will be addressed very soon.
Mike
|
| 755.12 | was first, now last | TOOK::DITMARS | Pete | Tue Mar 05 1991 12:04 | 5 |
| Mike's statement regarding PTB's behavior change is correct:
- it used to be "first SET in dictionary wins"
- as of 10-jan-1991, it's "last SET in dictionary wins"
The behavior change was due to a bug fix for supporting multi-keyword verbs.
|
| 755.13 | Obviously a problem. Here's the plan: | TOOK::CAREY | | Fri Mar 08 1991 11:57 | 48 |
|
Well, it looks like we know just about everything about this problem
except how to fix it.
Here's the plan:
The V1.1 SNMP AM is being modified so that it will work with the DECmcc
V1.1 Parse Table Builder and dictionary, so that is no problem.
The V1.0 SNMP AM will have this problem on DECmcc V1.1.
We have included in the DECmcc release notes (on both the BMS and DIR
kits) instructions for fixing the DECmcc dictionary by hand during the
SNMP AM installation if the SNMP AM V1.0 is wanted on DECmcc V1.1.
If possible, we will include these instructions in the SNMP AM
V1.0 release notes as well.
The instructions are pretty simple (just be careful), but they are in
the release notes, which aren't necessarily read at all, let alone
before installation of a product. I know we tell everyone to read
them, but I never do!
So, watch for the error seen in .0 with DECmcc V1.1. I've never seen
it for any reason other than this one. If you see it, get the release
notes and get your customer on the right track! The quicker we can
admit this error and repair it, the less impact on the customer, and
the less impact on his opinion of DECmcc as a product and Digital as a
company.
It's time to stop arguing about what exactly is wrong here, and
recognize that WE made a mistake, and we can fix it.
I just want our customer's to see a SET directive that works on DECnet
requests!
Thanks in advance for helping us to sort this one out.
-Jim Carey
P.S. We're learning fast, and now we know something else to watch out
for in the next release!
|
| 755.14 | I'm done, honest | MKNME::DANIELE | | Fri Mar 08 1991 12:30 | 16 |
| re .11:
> ... which means that
> V1.0 of SNMP is not going to work on the latest BMS 1.1 system.
amd .13:
> The V1.0 SNMP AM will have this problem on DECmcc V1.1.
Don't be confused by these statements. It isn't the SNMP AM (V1.0 or
X1.1) that is going to exhibit problems. It's that when these are
installed on DECmcc V1.1, OTHER modules (like Phase IV, perhaps others)
will exhibit problems.
Hopefully clear,
Mike
|
| 755.15 | Don't wait for SNMP AM V1.1... | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Mon Mar 11 1991 09:10 | 17 |
| RE: 755.13
> The V1.1 SNMP AM is being modified so that it will work with the DECmcc
> V1.1 Parse Table Builder and dictionary, so that is no problem.
Just to avoid too much (more) confusion, SNMP AM V1.1 does NOT ship with
DECmcc V1.1. There is no existing SNMP AM V1.1 (X1.1 was a prototype).
Do NOT wait for another version of SNMP AM to install on top of DECmcc V1.1
(i.e. SNMP AM V1.0 is the only orderable SNMP AM).
Chris Brienen
P.S. More confusion: there could be a new
SNMP AM that layers on DECmcc V1.1,
and be available before DECmcc V1.2,
but don't bet on it...
|
| 755.16 | What if the dictionary is already built? | NSSG::R_SPENCE | Nets don't fail me now... | Tue Mar 19 1991 16:20 | 11 |
| Ok, I read the release notes. Thanks for the info.
I had a call from someone who missed a detail and rebuilt the
dictionary and parse tables before discovering the stuff in the release
notes. I am told that the first command listed didn't work so... now
what?
FYI, BMS was installed, followed by the TCPIP module and the Terminal
server module, then the note in the release notes was found.
s/rob
|
| 755.17 | A little more info please. | DANZO::CARR | | Wed Mar 20 1991 14:41 | 10 |
|
It really shouldn't matter if the parse tables were updated during
the TCP/IP AM installation. The instructions in the release notes should
still work.
I don't understand what "the first command listed didn't work" means,
can you clarify?
Dan
|
| 755.18 | | NSSG::R_SPENCE | Nets don't fail me now... | Wed Mar 20 1991 15:44 | 16 |
| What I was told was that the first command listed in the release notes
that were to be applied to correct the interaction with other MMs
failed.
I believe the command is ;
DELETE CLASS Snmp SUBCLASS interface DIRECTIVE Set REQUEST Set -
ARGUMENT AttributeValues
Unfortunatly the person who his having the problem (at the NYC ACT)
has to go through 3rd parties at the moment due to their cluster being
down today for upgrades.
s/rob
|
| 755.19 | a silly question | RAMPAL::DITMARS | Pete | Thu Mar 21 1991 09:44 | 6 |
| > I believe the command is ;
>
> DELETE CLASS Snmp SUBCLASS interface DIRECTIVE Set REQUEST Set -
> ARGUMENT AttributeValues
they did enter this command at a DAP> prompt, and not an MCC> one, right?
|
| 755.20 | | NSSG::R_SPENCE | Nets don't fail me now... | Thu Mar 21 1991 11:22 | 6 |
| I am pretty sure she was doing the right thing.
After today's customer demo I expect she will add her own info. Thanks
to y'all for the help so far though.
s/rob
|
| 755.21 | question on installing | HKGACT::ALICELAM | | Tue Sep 24 1991 00:31 | 65 |
| I found problems when I try to install the DECmcc TCP/IP SNMP V1.0.
Before that I have successfully install the DECmcc BMS V1.1.
I have read the release notes but still I can't find the reason.
Below is part of the install log file:
Parse table build complete.
DECmcc Help File Builder
Component Version: V1.1.0
Processing file DUA27:[DECMCC]MCC_ALARMS_FM.HELP
Processing file DUA27:[DECMCC]MCC_BRIDGE_AM.HELP
....
....
Sorting character cell help topics.
Sorting windows help topics.
Verifying hierarchy...
Verifying for character cell
No topics specified, empty library will be created.
Verifying for windows
No topics specified, empty library will be created.
Processing file(s)....
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=726192DA, PC=0003685B, PSL=0BC00004
Improperly handled condition, image exit forced.
Signal arguments Stack contents
Number = 00000005 00000000
Name = 0000000C 00000003
00000001 7FEDECCC
726192DA 7FEDF35C
0003685B 00000000
0BC00004 00033C4D
0007C0D4
00000000
000ADD6B
00000000
Register dump
R0 = 06442079 R1 = 72617262 R2 = 00002079 R3 = 7FEDEC44
R4 = 00000000 R5 = 00000004 R6 = 00000200 R7 = 0007C0D4
R8 = 7FEDF35C R9 = 0006691C R10= 0006627C R11= 0007C0D4
AP = 7FEDEC08 FP = 7FEDEBC8 SP = 7FEDEC44 PC = 0003685B
PSL= 0BC00004
*********************************************************
Fatal DECmcc TCP/IP SNMP V1.0-0 event occurred during installation
*********************************************************
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
Installation of MCCTCPIP V1.0 completed at 03:57
Enter the products to be processed from the next distribution volume set.
* Products:
VMSINSTAL procedure done at 03:58
|
| 755.22 | try... | BSYBEE::EGOLF | John C. Egolf LKG2-2/T02 x226-7874 | Tue Sep 24 1991 07:47 | 14 |
| two suggestions...
1. Run the AUDIT com file specified in note 1255 to ensure your
quotas are set up properly.
2. Upgrade to the new TCP/IP SNMP AM noted in note 3.100
Since many others have installed the AM without crashing, I
believe that some quota or not enough disk is the problem.
Pls let us know what you find out.
JCE
|