Conference azur::mcc

    
    Thanks for bringing this to our attention.
    
    It looks like this is a problem with a brandy new counter attribute
    being returned for DNA5 routing circuits.  We don't expect it or throw
    it out, and the Export FM isn't set up to handle (or even throw it
    away).
    
    If you need this desparately, send me mail offline and we'll see if we
    can accomodate you.  Currently we are stuck with this situation until 
    DECmcc V1.2.  Our dictionary had to freeze a long time ago to provide a
    stable environment and allow us to ship a product.
    
    Sorry to see this problem.
    
    -Jim Carey
    

Please make  sure  the  bug  here is QAR'd.  The export code must handle new
attributes  (presumably  by  ignoring  them but alteratively by storing them
even though it doesn't understand them).

This is  part  of  the  genreal robustness principle: the director can never
assume it knows all there is to know about the entities, it must continue to
work as well as it ever did if the entity is upgraded to a newer version.

Graham

RE :.2

>Please make  sure  the  bug  here is QAR'd.  The export code must handle new
>attributes  (presumably  by  ignoring  them but alteratively by storing them
>even though it doesn't understand them).

Exporter is not able to store attributes "even though it doesn't understand
them" simply because in order to create a column in the RDB table it has to
know the presentation name of the corresponding attribute. The only place to
look at is data dictionary. This is a difference between Exporter and Historian.
Historian stores data in the MCC internal format and it does not need to know
the meaning of stored data but in order to store data in the outside_of_MCC 
storage (eg. RDB file) Exporter must know how to translate them from the MCC 
format (attribute_id_code and MCC_data_type) to the RDB format (column name 
and rdb_data_type).
Exporter can ignore an "unknown" for MCC attribute but I think that situation 
will not be better. Now if AM returns an "unknown" attribute exporting request
turns in the suspended state which indicate that this request can not be
processed. Assume that Exporting ignores "unknown" attributes and writes in the
RDB only "good" data. Such request can run several days, weeks, may be months
before the user detects that RDB file is incomplete.
I think that in addition to the "suspended" state SHOW EXPORTING directive 
should give a reason why this request has been suspended.

>This is  part  of  the  genreal robustness principle: the director can never
>assume it knows all there is to know about the entities, it must continue to
>work as well as it ever did if the entity is upgraded to a newer version.

Exporter does not get data from an entity directly it calls to the AM. AM must
match the data dictionary or , may be more correct, the data dictionary must
match all MMs installed in the system. 
Do we need some procedure which can verify the data dictionary and data 
returned by AM? I think it will be very useful especially when third parties
begin to produce AMs or when AMs are sold separately from MCC.

	Sam
    

OK, so  you can't transparently handle unknown attributes.  In that case you
must  ignore  them.  Sure, if you are worried, indicate somehow that you are
ignoring information but you can't break.

I am  confident  that *every* release of our router and server products will
add  at  least  one  attribute  to  at least one entity (usually several and
usually to key entities like Routing or the Circuits).  It is impossible for
the  manager  to  keep  all the MCC systems up to date.  However, it is also
important  (for other reasons separate from the Exporter) that the AM passes
through  attributes  which aren't present in the dictionary -- unfortunately
you can't push the problem on to the AM.

As far  as  the  network  manager is concerned, it is vital that the regular
weekly  report  that  he  or  she  is producing for their boss using the RDB
export  not  break  just because a router has been upgraded.  Their response
will, very reasonably, be: "I didn't care about that new attribute before, I
don't  care  about  it  now,  but  I do care that all information about this
router  has  suddenly been lost just because it was upgraded -- my job is on
the line here.  FIX IT!".

I wish  that every engineer working on anything to do with MCC realised that
for  a management station to be successful its two overriding goals must be:
i)  accuracy  and  then  ii)  robustness.   The  *only*  thing  that is more
important than robustness is not actually lying to the user! Everything else
(performance,  user  friendliness,  flexibility  and  expandability) is very
important but will come to nothing if the first two goals aren't met.

The problem  in  .0  is  seen  by  someone  who  is field testing one of our
routers.   Peter  Hill  may  be  internal  but he is trying to use both your
product  and  mine  as  a  customer.   Customers will be in exactly the same
situation and will throw out MCC if it can't meet their needs.

Graham

RE: .4

>                                                    ...  However, it is also
>important  (for other reasons separate from the Exporter) that the AM passes
>through  attributes  which aren't present in the dictionary -- unfortunately
>you can't push the problem on to the AM.

I still can not understand what are the "other reasons" to bring unknown
(for MCC) attributes inside MCC. Who can use the attribute which is not in the
data dictionary?
In my imagination AM is like a gate for data to come inside MCC and this is 
AM's responsibility to filter them.
But I agree that current situation has to be fixed and Exporter is the easiest
place to do it now. So I entered QAR #621 in MCC_INTERNAL against Exporter FM.

	Sam
    

The other  reasons  are  to  help  the  manager  who  is  forced  to  use an
out-of-date  copy of MCC (e.g.  while visiting a remote site).  Using either
FCL or the iconic interface, he or she can at least display attributes which
were  are not present in the dictionary.  If the AM has datatype information
(which  the  Phase  V  AM  does) it can put enough information in the ILV to
allow the PM to display the attribute.

Thanks for looking at this.
Graham

    
>                                                             ...Using either
>FCL or the iconic interface, he or she can at least display attributes which
>were  are not present in the dictionary. 

This is what I tried to explane in my previous replies. May be it was not 
clear. 
Presentation moduls (fcl and impm) CAN NOT display attributes which are not
in the data dictionary. In order to display attributes  the presentation
name as well as data type must be know to PM. The only source for presentation
name is data dictionary.

 Regards, Sam 
    

Maybe we should just use the attribute's ID when we fail to find the attribute
in the dictionary.

   if (presentation_name_not_available)
        sprintf (presentation_name, "Unexpected Attribute #%d", attr_id);

Similarly, if the datatype isn't available we could do a hex dump of the value.
So in FCL you'd see something like the following when we tried to display 
an unexpected attribute with an unknown datatype

         Unexpected Attribute #347 = %x090909093409234092340909234

FCL doesn't currently do either of these things, but the Iconic Map does handle
unknown attribute IDs.  We've been QAR'd on this (generally, not continuing to
output when we encounter an "error").

The historian could do something similar as far as creating a column in
the partition table for that unknown attribute using a generated name.

RE: .8

It's very useful if FCL indicates id code for unexpected attribute. At least we
will know that data dictionary is not complete and what is missing.

But Exporter (not Historian, Historian needs to know nothing about returned
attributes) and FCL process dictionary information differently.
As I understand FCL tries to get presentation name AFTER it receives data 
in p_out (I think that data type can be obtained from p_out) and is able to 
generate a name for the unexpected attribute using its id code. Exporter must
to know a presentation name and data type of all attributes BEFORE it makes 
mcc_call. So Graham is right and the only solution for Exporter is to ignore an
unexpected attributes.

    

> Exporter must
> to know a presentation name and data type of all attributes BEFORE it makes 
> mcc_call.

You mean, I hope, "...  know ...  of all *possible* attributes ...".  

A director  can  never hope to know exactly what attributes are present in a
particular  entity  instance  without asking it.  This is nothing to do with
problems with the data dictionary just the fact that a particular entity may
not implement (or have "engaged") any particular attributes.

You do handle missing attributes, don't you?

Graham

Re: .10

> You do handle missing attributes, don't you?

If an attribute is "missing" the corresponding column in the RDB table is
empty.

	Sam