| 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 |
This note documents some bugs I have found during a few minutes spent
displaying Phase V attributes. I don't have access to an MCC QAR database
(as far as I know!) so they have to be entered here. This is MCC T1.1 using
the command line interface.
All tests were performed to an OSIrouter 500. All these really need to be
fixed if MCC is going to be able to manage Phase V routers. However,
numbers 1 and 2 in particular prevent MCC (by itself) being usable for
Phase V router management: NCL is needed as well.
1) MCC cannot display TowerSets.
MCC> show node msrv14 address
Node DEC:.msrv14
AT 10-JAN-1991 21:51:25 Identifiers
Address =
%MCC-E-DATA_ENCODING_E, error in data type encoding
%MCC-E-DATA_ENCODING_E, error in data type encoding
2) MCC does not display the Routing Nearest L2 Router Adjacencies attribute
(this is a Set Of LocalEntityName).
MCC> show node msrv14 routing nearest l2 router adjacencies
Node DEC:.msrv14 Routing
AT 10-JAN-1991 21:53:12 Status
MCC>
Further investigation shows that MCC doesn't display any LocalEntityName
attributes. E.g.
MCC> show Node DEC:.msrv14 Routing Circuit hdlc-0 data link entity
Node DEC:.msrv14 Routing Circuit hdlc-0
AT 10-JAN-1991 22:14:19 Characteristics
MCC>
3) Name of Routing Phase IV Prefix attribute is wrong:
PhaseIV Address Prefix = /49
4) MCC doesn't display address prefix correctly:
PhaseIV Address Prefix = /49
This should be 49::
5) BinaryAbsoluteTime not displayed correctly. The format is non-standard
but that would probably be OK (after all this isn't meant to be NCL) if the
TDF and inaccuracy were displayed.
Creation Time = 10-JAN-1991 21:34:09.37
6) OctetStrings are not displayed correctly. The Routing Circuit Point To
Point ID attribute is an OctetString which should be exactly 7 bytes long:
Point To Point ID = %X070008002B0B025201
It looks like there is an extra word containing the value 7 on the front.
7) The Routing MSL has the wrong name for the CSMA-CD circuit type: you are
still using 802.3.
Here are some things I liked and disliked (but aren't bugs):
i) The "attribute not gettable" error display for write-only attributes is
excellent! Much neater than NCL's handling.
ii) I am not at all sure whether I like the aligned "=" signs. I have got
remarkably used to NCL's left alignment.
iii) I don't like the apparantly random order of output from a SHOW ... ALL
ATTRIBUTES command. It appears to be by group (or is it partition?) but it
could do with the headings like NCL has ("Characteristics", "Status", etc.).
As it stands it appears random.
I don't like the partial re-ordering (alphabetical order within partition?)
either. Either display them in the order returned by the entity (the entity
implementor may have chosen the order deliberately to keep related things
together) or completely order them.
iv) MCC displays UIDs correctly. Congratulations! (VMS NCL *still* gets the
order of bytes wrong in the first three fields).
v) MCC is too slow. I tried the following command for both VMS NCL and MCC:
show node msrv14 routing circuit csmacd-0 adj * all attr
It wasn't a scientific test at all but the MCC output was extremely slow.
At least 6 times slower than the NCL version (probably more). It was taking
about 4 seconds per adjacency! For about 180 adjacencies it took quite a
while. Hastings is supposed to support 10,000 adjacencies on a LAN!!!
Graham
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 614.1 | SHOW comments... | NAC::ENGLAND | Mon Jan 28 1991 03:02 | 18 | |
re:.-1: What do you mean by "order them"? alphabetically? This would
make it easier to find a particular attribute in the display, but it
would make the FCL slower, since it would have to look up all
attributes before displaying any of them...
I have difficulty reading the MCC-defined SHOW displays because
the attribute names' left margin zig-zags, although it does
align the values and make it easy to visually pair the name
with the value. Suggestion: 95% of the keywords are under
30 columns, so you could do something like this:
name1 = value1
name2 = value2
...
Is this what you do in the forms interface? Or do the forms look
just like the SHOWs?
| |||||
| 614.2 | some answers | TOOK::DITMARS | Pete | Mon Jan 28 1991 17:44 | 17 |
re: .0 I work on FCL but have little experience with Phase V stuff. I've sent your note to a member of the the Phase V team. 1) Work has recently been done in FCL to correctly output towersets. However, the work was done to correct situations where there were multiple towers (FCL was only displaying the first one), and the QAR I saw didn't have the error messages you've given in your note, so I'm not sure if this work was relevant. 2) The local entity datatype is not working in FCL yet. This should be in the release notes. Sorry. as for 3-7, and your comments, we will investigate further and post more information later. thanks for the note. | |||||
| 614.3 | couple of answers | TOOK::HAO | Tue Jan 29 1991 12:07 | 18 | |
I can answer/clarify on a couple of your comments:
1) Pete is correct. We did fix a bug for Towerset recently, but it
was only for not displaying more than one tower. The current code
that we have appears to handle Towerset datatype properly. The
error that you're seeing MAY be related to the data not being
encoded properly by the AM. This is just a guess, and I'll leave
it to Jim Halpin to give the right answer.
4) The output for the Prefix Address datatype is what we coded it to
look like. According to the SRM, the address datatypes can have
two user-visible representations: ISO HRPF format, or the DNA
format. What you are seeing is the ISO format. If the SRM
isn't correct, or we've made an error in understanding the
datatype, please let us know.
Christine
| |||||
| 614.4 | TURKEY::J_HALPIN | I live at Dead Dog Farm | Wed Jan 30 1991 18:05 | 124 | |
Graham, sorry its taken so long for me to answer this note..
Here is the state of all the bugs you reported as of the DECmcc V1.1
MCS Build:
MCC> show mcc 0 dna5_am all char
MCC 0 DNA5_AM
AT 30-JAN-1991 14:32:05 Characteristics
Examination of attributes shows:
Component_Ident = DECmcc DNA5 AM
Component_Version = V1.1.0
>1) MCC cannot display TowerSets.
>
>MCC> show node msrv14 address
>
>Node DEC:.msrv14
>AT 10-JAN-1991 21:51:25 Identifiers
>
> Address =
>%MCC-E-DATA_ENCODING_E, error in data type encoding
>%MCC-E-DATA_ENCODING_E, error in data type encoding
The DATA_ENCODING error was an Access Module bug fixed after T1.1 was
released. When you submitted this note, I noticed that the AM was receiving
multiple towers in the TowerSet, but FCL was only displaying the 1st one.
Pete & Christine have fixed that bug and here is the latest output...
MCC> show node msrv14
Using default ALL IDENTIFIERS
Node TURKEY_NS:.msrv14
AT 30-JAN-1991 14:26:59 Identifiers
Examination of attributes shows:
Name = PROTO_NS:.REO.MSRV14
Address = {{{Network Management -- CMIP or NICE,
none}
{DNA Phase V Session Control,
Network Management}
{NSP Transport,
Session Control}
{OSI network or DNA Routing,
49::00-41:08-00-2B-0B-02-52:20}}
{{Network Management -- CMIP or NICE,
none}
{DNA Phase V Session Control,
Network Management}
{NSP Transport,
Session Control}
{OSI network or DNA Routing,
49::00-42:08-00-2B-0B-02-52:20}}
{{Network Management -- CMIP or NICE,
none}
{DNA Phase V Session Control,
Network Management}
{NSP Transport,
Session Control}
{OSI network or DNA Routing,
49::00-01:AA-00-04-00-4F-06:20}}}
>2) MCC does not display the Routing Nearest L2 Router Adjacencies attriMCC> show node mccrtr routing nearest l2 router adjacencies
>(this is a Set Of LocalEntityName).
Actually we do display LocalEntityNames now (and SET OF...). However,
the Command Line has a slight problem: It displays them as FullEntityNames,
i.e. the Global Class/Instance is prepended to the front of the LocalEntityName.
I have QARed this against FCL, but it won't be fixed for V1.1
Node TURKEY_NS:.mccrtr Routing
AT 30-JAN-1991 14:45:05 Status
Nearest L2 Router Adjacencies = { Node TURKEY_NS:.mccrtr Routing Circuit csmacd-0 Adjacency RTG$101E }
bute
>3) Name of Routing Phase IV Prefix attribute is wrong:
I'll fix our MSL File...
>4) MCC doesn't display address prefix correctly:
Christine has answered this. At any rate it is an FCL issue.
>5) BinaryAbsoluteTime not displayed correctly. The format is non-standard
>but that would probably be OK (after all this isn't meant to be NCL) if the
>TDF and inaccuracy were displayed.
>
> Creation Time = 10-JAN-1991 21:34:09.37
The DNA5 AM passes the BinAbsTim datatype correctly. I'll QAR this one
against FCL.
>6) OctetStrings are not displayed correctly. The Routing Circuit Point To
>Point ID attribute is an OctetString which should be exactly 7 bytes long:
>
> Point To Point ID = %X070008002B0B025201
>
>It looks like there is an extra word containing the value 7 on the front.
Yup, the AM comes up with two extra bytes somewhere. I thought I
fixed this, but its still there.... stay tuned.
>7) The Routing MSL has the wrong name for the CSMA-CD circuit type: you are
>still using 802.3.
I'll update our MSl file...
Jim Halpin.
| |||||
| 614.5 | binabstim question | TOOK::HAO | Thu Jan 31 1991 12:54 | 10 | |
Regarding Comment #5, on BinAbsTim output format:
I thought that what is being displayed by FCL is the correct BinAbsTim
format. BinAbsTim is defined in the SRM to be either a VMS Combination
Time or VMS Absolute Time format. Could you point out where in the
output it is non-standard?
Thanks,
Christine
| |||||
| 614.6 | SRM bugs | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Thu Jan 31 1991 17:12 | 22 |
Re: .3. Prefix Address. While ISO HRPF format must be accepted for input and must be used for output of non-DNA format NSAPs, the DNA format must be used for values which are legal DNA NSAPs (or prefixes). See the NETMAN architecture for the detailed rules. /49 should be displayed as 49::. All our documentation and our users use the DNA format. What would be the point of having invented it if MCC doesn't display in that format! Re: .5. BinAbsTim. I don't particularly care what it says in the SRM (although I understand why you do!). DEC Standard 112 defines the user-visible format for BinAbsTim. It is very important that the inaccuracy and TDF fields are displayed. Particularly as the Phase V MicroServer does not run the time service and hence reports its inaccuracy as infinite! I don't particularly mind if the format is different from DS112 but the information shouldn't be discarded. Graham | |||||