| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 211.1 | It's quite simple really :-} :-} | TOOK::STRUTT | Colin Strutt | Fri Jul 27 1990 12:05 | 22 |
| You should not need to provide an entry point for any GROUPS of
attributes (including ALL ATTRIBUTES), only entry points for PARTITIONS
of attributes.
The PMs have enough smarts so that when a user requests, say, a display
of a group of attributes (say ALL ATTRIBUTES), then it determines, via
the dictionary, which attribute partitions are involved, and makes a
series of requests for each of the partitions individually, then it
combines the information from each partition, sucking out only those
that comprise the requested group, and displays them to the user.
So, in summary, as it was described recently:
Partitions are used for dispatch purposes
Groups are used for user interface purposes.
[If you're still following this, note that ALL COUNTERS when specified
by the user, is an ATTRIBUTE GROUP, that just happens to have the same
definition as the ATTRIBUTE PARTITION of the same name - thus the PM
algorithm determines which partitions are involved in ALL COUNTERS, and
it determines that there is only one, ie. the COUNTERS partition.]
Colin
|
| 211.2 | 1 disp entry/partition | MKNME::DANIELE | | Fri Jul 27 1990 12:50 | 17 |
| But as far as dispatch entries go, you can't wildcard the attribute
partition part of the dispatch entry macro.
So even if you have 1 routine to handle class FOOB subclass BAR's
counters and characteristics, you'd need 2 dispatch entries.
mcc_dispatch_entry -
SHOW,-
<MCC_ENTITY <FOOB, *>, <BAR, *> >,-
COUNTERS,-
show_routine
mcc_dispatch_entry -
SHOW,-
<MCC_ENTITY <FOOB, *>, <BAR, *> >,-
CHAR,-
show_routine
|
| 211.3 | Not working as advertised... | COOKIE::KITTELL | Richard - Architected Info Mgmt | Sat Jul 28 1990 11:35 | 12 |
|
Thanks for the replies. I had noticed by trial that attribute partitions
can't be wildcarded. But the only reason I even tried that is this:
$ mcc
DECmcc (T1.0.1)
MCC> show pbd x all attributes
%MCC-E-NOTFOUND, Dispatch entry for the specified entity does not exist
Colin, could I have somehow broken the implicit ALL ATTRIBUTES group you
described in .1? Should that group be defined in my MSL?
|
| 211.4 | | MKNME::DANIELE | | Sun Jul 29 1990 16:47 | 21 |
| MCC> show FOOB X all attributes
causes the FCL module to search the dictionary for any attribute
partitions defined for entity FOOB. It then issues separate
requests for each of those partitions. Assume for instance you have
defined FOOB to have characteristics, counters, and identifiers. The
above request has the same effect ( on the AM ) as if you had typed
MCC> show FOOB X all ident
MCC> show FOOB X all counters
MCC> show FOOB X all char
Sounds like you haven't defined a dispatch entry for one of the
partitions you've defined. It also sounds like the symbol
MCC_K_ATTR_PRT_ALL is treated as just another partition code in the
dispatch tables. I don't know if it was ever intended to signify
what you want to do ( dispatch any request for attributes to this
entry point ).
Regards,
Mike
|
| 211.5 | no ident partition yet
| COOKIE::KITTELL | Richard - Architected Info Mgmt | Mon Jul 30 1990 00:43 | 6 |
|
Thanks, Mike.
I don't have an identifiers partition yet (I'm just now getting out of
pseudo-entity mode and writing to the MIR). So when ALL ATT tried
to dispatch to ALL IDENT it failed.
|
| 211.6 | | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Mon Jul 30 1990 09:41 | 18 |
| Re: .1.
> So, in summary, as it was described recently:
> Partitions are used for dispatch purposes
> Groups are used for user interface purposes.
So, Colin, you are saying that there is no way for MCC to request a DNA
Phase V entity to return any of the DNA attribute groups (which are not
partitions because an attribute may be a member of more than one group)? Or
are the MCC *partitions* mapped, by the P5 AM to DNA *groups* (which sounds
like it could confuse some FM or PM)?
It seems unacceptable, to me, that a director has no mechanism to request
that an entity return all attributes that the entity knows about (including
ones that the director doesn't know about). It is unlikely that a director
will always be up to date with the entity implementations.
Graham
|
| 211.7 | FCL processing flow | GOSTE::CALLANDER | | Mon Jul 30 1990 11:59 | 213 |
|
As it currently stands, and there are proposals on the table for
future changes, the interface between modules only allows for the
requesting of a single partition at a time.
To debug problems with getting ALL ATTRIBUTES or groups to work,
use the MCC_FCL_PM_LOG logical (value 8) to see what partition is
being requested when the failure is detected. An example is attached.
A quick review of how things work for groups. First the terms that
I will be using are NOT the same so those used in our end user
docuementation. In the manuals NO distinction is drawn between groups
and partitions. Here though I will use the following:
partition - each attribute belongs to one and only one partition,
these group by type each and EVERY attribute that CAN be returned
by a module/entity
group - these are logical groupings of attributes where any attribute
many belong to any group. An attribute may belong to many groups
or none (ALL ATTRIBUTES is a special case group defined by the FCL
on the users behalf, it is NOT defined in the MS file)
To get a group to work you must do the following:
- define your attr partitions in you management spec
- define the group in you management spec (except for all attrs)
- make sure you have entry points for ALL of your partitions
- run MSL/DAP/PTB and your off.
What is done when the user enters a request for a group is the
following (starting in the FCL):
- FCL detects user requested a group
- group is broken out based upon the partitions represented
in the request
- one call is made for each partition
- as each partition returns, using the list broken out
by partition, the specific attributes are pulled from
the partition (out_p) and displayed
- if an attribute isn't returned, it is ignored
- if ALL REFERENCE fails the exception is surpressed
- if the request for a specific partition (other than REFERENCE)
fails, only the first exception is printed all others are
surpressed
------------------------------- SAMPLE RUN -------------------------------------
GOSTE$ def mcc_Fcl_pm_log 8
GOSTE$ manage/enter
DECmcc (V1.0.0)
MCC> show mcc 0 all attr
FCL PM Arguments before call_function:
AES DUMP of ENTITY IN:
depth=1 class code= 7 instance = 0
ILV DUMP of INP: in_p is NULL
ILV DUMP of INQ: in_q is NULL
ATTRIBUTE PARTITION: 1
*******************************************
FCL PM Arguments on return from call_function:
ILV DUMP of OUTP:
[ 1 ] (
[ 1 ] (
[ 1 ] (
[ 1 ] 05
[ 2 ] aa 00 04 00 74 12 a0 88 3b 9e 94
6b 93 00 17 00 0
1 03 4d 43
43 01 0e 47 4f 53 54 45 5f 44 49 52 45 43 54 4f 52 00
00
[ 3 ] 00
)
)
)
AES DUMP of ENTITY OUT:
depth=1 class code= 7 instance = 0
CVR returned:
%MCC-S-RESPONSE, Success with response reply
MCC 0
ALL ATTRIBUTES
AT 30-JUL-1990 10:14:03
Component Name = KAJUN_NS:.MCC.GOSTE_DIRECTOR
FCL PM Arguments before call_function:
AES DUMP of ENTITY IN:
depth=1 class code= 7 instance = 0
ILV DUMP of INP: in_p is NULL
ILV DUMP of INQ: in_q is NULL
ATTRIBUTE PARTITION: 2
*******************************************
FCL PM Arguments on return from call_function:
ILV DUMP of OUTP:
[ 2 ] (
)
AES DUMP of ENTITY OUT:
depth=1 class code= 7 instance = 0
CVR returned:
%MCC-S-RESPONSE, Success with response reply
FCL PM Arguments before call_function:
AES DUMP of ENTITY IN:
depth=1 class code= 7 instance = 0
ILV DUMP of INP: in_p is NULL
ILV DUMP of INQ: in_q is NULL
ATTRIBUTE PARTITION: 3
*******************************************
FCL PM Arguments on return from call_function:
ILV DUMP of OUTP:
[ 2 ] (
)
AES DUMP of ENTITY OUT:
depth=1 class code= 7 instance = 0
CVR returned:
%MCC-S-RESPONSE, Success with response reply
FCL PM Arguments before call_function:
AES DUMP of ENTITY IN:
depth=1 class code= 7 instance = 0
ILV DUMP of INP: in_p is NULL
ILV DUMP of INQ: in_q is NULL
ATTRIBUTE PARTITION: 4
*******************************************
FCL PM Arguments on return from call_function:
ILV DUMP of OUTP:
[ 1 ] (
[ 1 ] (
[ 3 ] (
[ 1 ] 09
[ 2 ] 56 01 00 00
[ 3 ] 00
)
[ 4 ] (
[ 1 ] 03
[ 2 ] 44 45 43 6d 63 63 -- DECmcc
[ 3 ] 00
)
)
)
AES DUMP of ENTITY OUT:
depth=1 class code= 7 instance = 0
CVR returned:
%MCC-S-RESPONSE, Success with response reply
Component Identification = "DECmcc"
Component Version = V1.0.0
FCL PM Arguments before call_function:
AES DUMP of ENTITY IN:
depth=1 class code= 7 instance = 0
ILV DUMP of INP: in_p is NULL
ILV DUMP of INQ: in_q is NULL
ATTRIBUTE PARTITION: 5
*******************************************
FCL PM Arguments on return from call_function:
ILV DUMP of OUTP:
[ 3 ] (
[ 6 ] (
[ 0 ] (
[ 1 ] 01
[ 2 ] 07
[ 3 ] 01
[ 4 ] 05
[ 5 ] aa 00 04 00 74 12 a0 88 3b 9e 94
6b 93 00 17 00 0
1 03 4d 43
43 01 0e 47 4f 53 54 45 5f 44 49 52 45 43 54 4f 52 00
00
)
)
)
AES DUMP of ENTITY OUT:
depth=1 class code= 7 instance = 0
CVR returned:
%MCC-S-COMMON_EXCEPTIO, Success with common exception reply
MCC>
|
| 211.8 | | TOOK::STRUTT | Colin Strutt | Mon Jul 30 1990 23:49 | 24 |
| re: .6
.6> So, Colin, you are saying that there is no way for MCC to request a DNA
.6> Phase V entity to return any of the DNA attribute groups (which are not
.6> partitions because an attribute may be a member of more than one group)? Or
.6> are the MCC *partitions* mapped, by the P5 AM to DNA *groups* (which sounds
.6> like it could confuse some FM or PM)?
No, not true - however, to get at a (MCC) GROUP of attributes (which may
reside in more than one partition) will require more than one mcc_call.
Whether the AM is smart enough to get more than one partition's worth
of attributes in one fell swoop, and hold them in abbeyance, is up to
the AM designer.
.6> It seems unacceptable, to me, that a director has no mechanism to request
.6> that an entity return all attributes that the entity knows about (including
.6> ones that the director doesn't know about). It is unlikely that a director
.6> will always be up to date with the entity implementations.
What problem(s) do you anticipate this "restriction" will cause?
As defined, what passes across the MCC interfaces must be defined in
the MCC dictionary in advance - it is invalid to pass information for
which there is no dictionary data. (There are ways to 'encode' around
this apparent restriction, but the rule still stands).
Colin
|
| 211.9 | | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Tue Jul 31 1990 09:13 | 28 |
| One of the major advantages of EMA over previous management architectures
(Phase IV in particular) is the easy and quick extensibility.
Even if we were to solve the problem of distributing dictionary updates in a
timely fashion (and it doesn't look like it *is* going to be solved in the
near future for MCC or the NCL implementations) there will always be the
problem that the director, at the network manager's location, is unlikely to
be up to date on the extensions implemented by the entity that is being
managed. Your scheme requires full management knowledge. It seems
unrealistic, to me, to expect the manager to upgrade his MCC software every
time someone on his network upgrades the software for one of the systems he
is managing.
The NCL architecture goes to great lengths to attempt to deal with (at least
displaying) attributes that NCL has never heard of but which the entity
returns unexpectedly. The scheme MCC seems to have chosen makes the notion
of attribute groups in EMA and CMIP completely unnecessary: by the principle
of putting complaxity in the director, not the agent, the only reason for
putting attribute groups in the agent is an expectation that the director
won't know which attributes go in which groups!
Of course, I am not suggesting that your mechanism violates any
architectures (except NCL but I have long since given up expecting MCC to
replace NCL) -- it is purely a product decision. I just think you will get
customer feedback to be able to at least display things that aren't in the
dictionary.
Graham
|
| 211.10 | | TOOK::STRUTT | Colin Strutt | Tue Jul 31 1990 19:01 | 17 |
| .9> Even if we were to solve the problem of distributing dictionary updates in a
.9> timely fashion (and it doesn't look like it *is* going to be solved in the
.9> near future for MCC ...
I'm confused. MCC is perfectly able to allow rapid dictionary updates.
When we first compared MCC and NCL (for VMS) in 1987, that was one of
the key differences: NCL required parse tables to be re-built and no
dictionary was shipped, whereas MCC relied on a dictionary which could
be dstributed as often as needed - we dicussed monthly distribution via
CDROM or even hourly distribution via satellite as possibilities).
[BTW this is not an indictment of NCL on VMS - VMS does not *need* to
have rapid updating of parse tables.]
So why don't you think we can update MCC dictionaries before the
entity that implements them (and the related access module) ships?
Colin
|
| 211.11 | (V,E,A) -> (*,E,*) is also needed for managing DECtrade | TRADE::ASHRAF | Gone today, here tomorrow | Wed Aug 01 1990 12:09 | 21 |
|
RE: .9 and .10
.9> there will always be the
.9> problem that the director, at the network manager's location, is unlikely to
.9> be up to date on the extensions implemented by the entity that is being
.9> managed. Your scheme requires full management knowledge.
DECtrade has a similar problem! The home-brewed director recognizes an
entity but doesn't know (and doesn't care) what verb-attribute combinations
the latter supports. This directory simply dispatches the command to the
entity which either returns the response or an exception (one of which
could be "Command not supported").
To be able to migrate to the DECmcc director, with its "easy and quick
extensibility", what we need is the exact capability Graham requests in .9,
so that any command can be dispatched to an entity - (V,E,A) can thus take
the form of (*,E,*) - without necessarily having to first define the V's
and the A's first in the dictionary.
Muhammad
|
| 211.12 | there are ways... | GOSTE::CALLANDER | | Wed Aug 01 1990 17:03 | 30 |
|
Well, one of the options you have is to do something along the lines
of what the Alarms FM did. The FM needed to be able to support new
entity classes and attributes as they plugged in, with no prior
knowledge. To do this they took the approach of using what they
call an "expression", The expression has a predefined format, but
does NOT have a predefined set of values. Instead the user enters
an "expression" in the format of ( <entity> <attribute> <operation>
<value> <qualifier> ). The predefined format is what allows them
to parse the input and pass the entity and attribute down to an
AM for evaluation **and yes I have simplied what they actually do
so as to be easier to understand.
You could do something similar. There are many options available,
this is only one.
Remember to do what you want your MM would need to support a function
for passing the command through to the entity it is managing. (Please
ignore my choice of command verbage, I am only trying to get the
idea across) What you are supporting is the ability to:
MCC> TELL <entity class> <entity instance> DO=<command>
^ ^ ^
verb entity argument
With this type of approach you now have a way of getting to new
commands, or all the commands, supported by your entity without
having to modify your interface/ms.
Again this is only one idea, MCC supports many others.
|
| 211.13 | and? | MKNME::DANIELE | | Wed Aug 01 1990 17:59 | 7 |
| > With this type of approach you now have a way of getting to new
> commands, or all the commands, supported by your entity without
> having to modify your interface/ms.
I think the point is, what happens when a new command, or the same
command, now send back new attributes?
|
| 211.14 | | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Thu Aug 02 1990 05:45 | 26 |
| .9> Even if we were to solve the problem of distributing dictionary updates in a
.9> timely fashion (and it doesn't look like it *is* going to be solved in the
.9> near future for MCC ...
.11> I'm confused. MCC is perfectly able to allow rapid dictionary updates.
The "problem" isn't technical -- it is process/product/political.
Technically the MCC dictionary can be distributed as frequently as desired:
the problem is making that happen (and agreeing the desired frequency).
From where I am, I don't see *any* progress being made on that. I would
love to learn that I am wrong. In fact I am currently discussing (with
Wally) the issue of how we get the dictionary updates that will be required
for Hastings out given your schedules around V1.1 and V2.0. Of course that
discussion will (continue to) be conducted off-line but the general issue
remains.
Actually, I don't consider this point to be key to my argument in .9,
anyway. Even if MCC were to issue a dictionary CD monthly or fortnightly, I
still believe there will be a problem in assuming that the network manager
has put the latest CD up -- he is probably still using the CD from 6 months
ago and it will take forms in triplicate, counter-signed by the head of the
DP department to get the most recent one brought up ("we can't do that in
case it causes a problem with management of the rest of the network")!!
Graham
|
| 211.15 | Minimal support is better than no support! | TOOK::PLOUFFE | Jerry | Thu Aug 02 1990 11:41 | 29 |
|
RE: Note 211.14 by MARVIN::COBB "Graham R. Cobb"
I understand what you are saying, Graham. This *is* a process, not a
technical question. It just isn't always *practical* to get the updates
out to the whole world when the agents change.
MCC should be as robust as possible, else the management of DECmcc
becomes worse than the managment of the network/system/application/etc.!
On a small network, this point is somewhat moot, but on big networks
software installations can be a process nightmare. Remember, we are not
selling DECmcc as a centralized network management solution (though it may
be used this way). We are claiming that it is a *DISTRIBUTED* management
solution - i.e., it (or pieces of it) will be installed on many systems.
At one point in time, a suggestion floated around to allow access modules
to pass up what they received from the agents directly to the PM. Some
probably already do this today. Then the PM would interpret the data as
best it could. If no data was found in the dictionary for a particular
attribute, the PM could use some sort of generic presentation name (e.g.,
"Unknow attrbute ID: xx = 23456". What ever happenned to this idea.
I realize that this kind of solution needs more work than I've described,
but it could be furthur developed and minimal support is better that not
providing any support.
- Jerry
|