Conference azur::mcc

957.0. "TowerSet datatype bugs" by MARVIN::COBB (Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917) Thu Apr 25 1991 16:10

While researching  another  note  reply  I  came across a couple of problems
using  TowerSets.   Note that the Phase V router and gateway products do not
include  DNS  and  so management of them makes non-trivial use of TowerSets.
In  addition,  TowerSets  are  needed  for a number of stages in our problem
solving guides (those involving possible problems with DNS).

Please QAR these for me.

1) TowerSet display loses important information.

Consider the (real MicroServer) Towerset that DECnet-ULTRIX displays as:

    Address                      =
       {
          (
          [ DNA_CMIP-MICE ]  ,
          [ DNA_SessionControlV3 , number=19 ]  ,
          [ DNA_NSP ]  ,
          [ DNA_OSInetwork , 49::00-41:08-00-2B-0B-05-41:20 ]
          ) ,
          (
          [ DNA_CMIP-MICE ]  ,
          [ DNA_SessionControlV3 , number=19 ]  ,
          [ DNA_NSP ]  ,
          [ DNA_OSInetwork , 49::00-42:08-00-2B-0B-05-41:20 ]
          ) ,
          (
          [ DNA_CMIP-MICE ]  ,
          [ DNA_SessionControlV3 , number=19 ]  ,
          [ DNA_NSP ]  ,
          [ DNA_OSInetwork , 49::00-01:AA-00-04-00-5B-06:20 ]
          )
       }
MCC displays this as

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-05-41: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-05-41: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-5B-06:20}}}

This has lost the very important Session Control EndUserSpec (number=19) and
replaced it with the useless string "Network Management".  If I am trying to
track  down  a problem with connectivity I will need to know which object is
being connected to.

2) Input of TowerSets does not seem to be supported:

MCC> set  node  msrv26  event  disp  outb  stre  abc  sink  addr  {{{Network Management -- CMIP or NICE,none}}}
%MCC-E-DATATYPE_NOT_SU, data type is not supported

When you  fix  this  (which is a showstopper for using MCC as the management
tool for routers and gateways), please make sure that you allow TowerSets to
be  entered  in  the  format  DECnet-ULTRIX uses as well as your own format.
Note  that we go to very great lengths to explain, slowly and carefully, how
to  construct  the TowerSet for a node in our problem solving documentation.
We  don't  do  it  for  fun  --  it  is very important.  That is *completely
useless* if the directors all use different formats for TowerSets!!

<Flame On>

I am  getting  very  fed  up  with  the  fact  that MCC seems to often use a
different  syntax  than  that specified in NETMAN.  I can understand wanting
things  to be user-friendly but you are shooting yourselves in the foot.  If
you  persist,  we  have no option but to state in our documentation that you
cannot use MCC to manage our products because of these differences! We can't
describe  different  syntaxes  for different directors: we can only describe
the  lowest  common  denominator  which  is  NCL using the syntax defined in
NETMAN (Entity Model).

At the  very  least  you must make sure that you always allow the NETMAN and
NCL syntax for input.

<Flame Off>

Maybe you  guys  have  never seen our problem solving or management manuals.
Maybe  you  don't  understand the scale of the problem we have to deal with.
If  you  want to look at it let me know and I will give you access to recent
drafts.

Graham

    Graham,
    I thought it was a phase 0 requirement for us to be a superset of NCL.
    I would suggest you qar us where we conflict.  I believe a lot of
    the problems you are seeing is because the functionality was traded
    off for "time to market", as they say.  If we are indeed shooting
    ourselves in the foot, then you should get more involved in MCCs
    phase review process.  But remember, the managers ultimately have
    the final say.  They don't always make the right decisions, but
    they have a pretty high batting average!  I'm glad to see people
    with the courage to say, "Hey, that's wrong, fix it!".  But,
    keep in mind that everyone wants their Christmas ornaments to hang
    on the MCC tree, and we still have to ship something to pay the
    rent.
    
    -Matt. 

Thanks for the response, Matt.  I guess that my comments are really directed
at the architects and management, rather than the engineers, and I will take
them  up  offline.  I didn't mean to cause offence to the engineers involved
(I am used to causing offence to managers and architects :-)).

In the  meantime, I would appreciate the problems from .0 being entered into
the QAR system.

Thanks
Graham

> If we are indeed shooting
>  ourselves in the foot, then you should get more involved in MCCs
>    phase review process. 

	Help me out Matt.  When was there a document available describing
	mcc 1.1's support of TowerSet, to this level of detail, so that
	someone could could have provided input?

    Mike,
    
    When some people say "NCL" they mean the architected command line
    syntax.  Others mean the Phase V equivalent of NCP.  I was referring
    to the former.  There is an NCL syntax document which describes what
    rules to follow for "syntax generators".  The FCL team read it, and
    implemented to it.  Towerset is a Constucted Datatype.  I believe
    either NCL or NETMAN describe that syntax.  I think we just say, "We're
    going to follow NCL and NETMAN wherever possible".  Or something like that.
    You really need to talk to a manager (like John Egolf) to get exact
    wording.  We never say that we will implement every datatype (that
    would be a very difficult, moving target, to hit). And some datatypes are
    are only partially implemented (for example, I don't believe we support
    variant records on input).  The datatypes which are not supported, or
    have partial support are supposed to be spelled out in the release
    notes.  If we say that we support a given datatype, but we use a
    different syntax, that would be a QAR against the SRM, not the
    implementation (in my opinion), since that is where we (MCC) define what
    syntax we will use for the datatype.  Sometimes we screw up.  And then
    we fix the SRM and the implementation.  (The SRM describes the BinAbsTim
    syntax as VMS time syntax; I could never figure that one out.)
    
    So to answer your question.  The implementation is driven from the SRM,
    which gets driven from product requirements. I'm not sure if that's the
    answer you were looking for.  Maybe someone else can give you a better
    answer.
    
    -Matt.

    
    
    	I have filed a QAR on this one for you Graham.
    
    JimH