| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 240.1 | A domain contains global entities... | BARREL::LEMMON | | Wed Aug 08 1990 09:40 | 8 |
| Conceptually a domain is a group of global entities.
The Select List allows the user to populate the domain with specific
global entities. An example of this is SELECT LIST = (NODE4 *, BRIDGE *).
It sounds like you are trying to create a domain to contain alarm rules.
This is not possible.
/Jim
|
| 240.2 | mcc 0 alarm rule name | GOSTE::CALLANDER | | Wed Aug 08 1990 12:06 | 7 |
|
To be more specific about your (.0) invalid entity error, the entity in
your select list ALARMS RULE <name> is incomplete. The entity is MCC 0
ALARMS RULE <name>. The parsing of the name is most likely what caused
the error.
|
| 240.3 | What did you hope to accomplish? | TOOK::PLOUFFE | Jerry | Wed Aug 08 1990 12:26 | 14 |
| RE: <<< Note 240.0 by KETJE::PACCO >>>
Dominique.
.1 and .2 are right on the money (thanks Jim and Jill).
As I understand it, you can only populate a domain with registered global
entities (alarm RULEs are child entities and they cannot be registered).
What exactly were you trying to accomplish? Maybe if we could understand
your purpose, we would be able to give you a better answer...
- Jerry
|
| 240.4 | Could become a customer concern. | KETJE::PACCO | | Thu Aug 09 1990 09:17 | 23 |
| The problem came from the fact that I was playing with MCC and tried to
approach it as customers would do.
I inserted a rule, which was btw very hard and user unfriendly, and then
tried to organize it. I was imagining two operators, each of them
working on a different scope (domain) of management.
I was hoping to
1). be able to classify some rules in 1 domain (e.g. rules for bridge
management) and rules for DNET4 in another domain.
2). be able to ENABLE ALL RULES of a specific domain, without having
these to enable these one after each other.
Apart from the actual limitations of the handling of alarms,
I feel it unacceptable not being able to do this approach on a
management system: structure everything in the management system in the
way the customer would like.
This would perhaps need to define rules as GLOBAL entities.
Dominique.
|
| 240.5 | May I suggest a different approach? | TOOK::PLOUFFE | Jerry | Thu Aug 09 1990 10:18 | 35 |
| RE: <<< Note 240.4 by KETJE::PACCO >>>
I understand your concern, and it is *valid*, but the populate command
was not the vechicle chosen for accomplishing these goals.
I believe that we have an alternate approach to resolving your concern...
There are plans (see product management for timeframes/versions/etc.)
to provide the ability to CREATE/DELETE/SHOW/ENABLE/DISABLE rules related
to a specific domain or entity.
This way you don't have to define domains that are just made up of alarm
rules. Domains were meant to group global entities. Alarm rules were
meant to detect error conditions about these global entities and their
children.
> The problem came from the fact that I was playing with MCC and tried to
> approach it as customers would do.
I hope that the approach described above is intuitive also. I never
realized that populate would be considered for this purpose. If you want
populate to do this, I suggest you contact John Egolf (TOOK::) directly
(manager of the Domain FM).
> I inserted a rule, which was btw very hard and user unfriendly, and then
> tried to organize it.
I agree that the command line syntax for entering rules is difficult to
enter, but we believe that the power (and future flexibility) of an
expression based package offset this difficulty. It was a tradeoff in
the v1.0 package. Future versions will simplify the process - especially
via DECwindows forms.
- Jerry
|