| AAAAAAAARRRRRRRRGGGGGGGGGGHHHHHHHH!
Do we get beat up by customers who want performance or beat up by
customers who want instantaneous extensibility?
MCC, at least in the short term, needs to decide on what its design
center is. Trying to satisfy the user with a management system which
will manage thousands of objects in a timely manner, yet will instantly
respond to a change in its metadata, is just not realistic. Trying to
do both has led us to doing neither particularly well.
I might point out that the major competitors (HP, for example) have an
even worse story to tell in this regard, where a significant
reconfiguration effort is necessary when the system is extended.
As far as the specific situation in the base note is concerned, note
that dynamic dictionary update in fact has never worked correctly since
the dictionary was cached starting just before the release of V1.0 of
MCC - we have had dozens of reports of dictionary corruption from
people trying to do something like this, so we decided to not allow it
at all until we could do it right.
We are in fact thinking about going further in this aspect and not
allowing enrollments in a running system. Concurrency control on the
dispatch table is also very expensive and we just can't manage 10000
entities and handle hundreds of events per second (yes, 100's per
second is what people are asking for) when we have to continually worry
about someone changing the metadata out from under us.
We also have some feedback from customers which runs counter to the
original premise of dynamic extensibility. The customers who manage
large networks treat the management system as any other production
system, i.e., changes are made in a very, very, carefully controlled
manner, typically involving a backup system and a long period of
parallel testing followed by an instantaneous switchover of the test
system onto the live system. This mode of operation dictates a
different style of update mechanism from dynamic enrollment.
As a longer term goal, it certainly would be nice to be able to meet
both goals. Some sort of compromise involving quiescing part of the
system while other parts continue to run is certainly a possibility.
But in the short term as long as the performance people are yelling
louder, we are tending to make decisions in favor of optimizing
runtime.
|
| On a less architectural note, I believe there are some work-arounds
if indeed all you want to do is install new AMs. (I'm speaking only for
VMS here...)
Run the installation without updating the dictionary (if the install
allows you to do that.) Then make temporary copies of the dictionary
in some other directory, and apply the dictionary update to them.
Copy the dictionary back into MCC_COMMON, and start using the new AM.
All of DECmcc which is still running of course will still be pointing at
the old dictionary, but anyone starting a new iconic map process will
grab the latest.
I believe Larry Grossman has included this algorithm in the Kitinstal
template, and TSAM already does this if there is enough disk space.
Other AM developers would do well to use this method on the next go-round.
-Dave
|