Conference azur::mcc

    Regrettably no, we don't support a change in attribute partition.
    It's been suggested as a future capability for Alarms, but it won't
    be done for V1.2
    
    	aud...

    This is a feature that can be found in the HUGHS Lan Systems product
    "Monet".  From their literature:  "Once a vendor's device is registered
    in the database, the LEARN utility automatically extracts its
    configuration parameters and enters them in the relational database. 
    This makes configuration of large multivendor networks practical and
    easy.  bla-bla-bla... MONET can also alert the network manager if
    real-time configuration parameters are out-of-sync with those stored in
    the database.  These parameters can be updated automatically,
    accompanied by a discrepancy report".  I saw a demo of this - and it
    seems like a useful feature.
    
    Now, for MCC - I'd think you could hack the feature by recording a
    partition to the historian, then run a report that compared parameters
    from two recording sessions - it would be in datatrieve or ingres sql.
    
    bill
    

    This is a feature that has been in a variety of classic management
    systems. It was a primary feature of BBN's NU for years. It will
    most likely be addressed in the future as a Generic Configuration
    Management FM. 
    
    I am not in favor of a hack on this one. You want a well thought
    out scheme that differentiates between production systems and
    test systems. It also needs to be sensitive to new releases and
    distribution of software for the objects under management.
    
    wally

>    Now, for MCC - I'd think you could hack the feature by recording a
>    partition to the historian, then run a report that compared parameters
>    from two recording sessions - it would be in datatrieve or ingres sql.
    
From DCL you could also *hack* something like this if its only one node, if 
it's more you'd need a config file to read from and a loop action. A database
report would be the best bet as described in -.1 if the environment is large.

After -recording- characteristics partition with a poll period of
1 day then start a resubmitting procedure to do the following:

$ mcc show node4 xxxxx all char, for start _yesterdays-date_ every 24:0 -
  until _todays-date_ , to file=xxxxx.dat
$ diff/output=xxxxx.dif xxxxx.dat
$ search xxxxx.dif "records found:"/output=check_dif_xxxxx.tmp
$ open check_dif check_dif_xxxxx.tmp
$ read/end_of_file=end_dif check_dif record_line
$ diff_num = f$element(5," ",record_line)
$ show sym diff_num
$ close check_dif
$ if diff_num .nes. "0" then 
$ mail/subject="xxxxx charicteristic change" xxxxx.dif <account>
$ END_DIF:
$ pur xxxxx.dif
$ pur check_dif_xxxxx.tmp
$ purge xxxxx.dat
$ exit

**WARNING untested, but the ideas should all be there, except determining
  the working dates**

kind regards,
brad...
    

    Thanks for the suggestions and work-arounds. I only see the solution
    suggested in .3 as the one I can present to customers. I realise of
    course the difficulty to integrate an RSM-like configuration management
    functionality in DECmcc extended to any entity, however, this is what
    we promise to customers when we talk about "Extended Management" and
    the OSI functional domains.

    Georges.