| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 991.1 | Attribute group (from a single partition), maybe? | MCDOUG::MCPHERSON | i'm only 5 foot one... | Mon May 06 1991 17:25 | 7 |
| Would it be an abomination to create an attribute group in your MSL that
basically picked out the pieces of the STATUS attribute partition you wanted?
Sounds pretty simple-minded, but it looks like it might be an alternative to
make the other PMs "do the dirty work for you"...
/doug
|
| 991.2 | re:.0 | BARREL::LEMMON | | Tue May 07 1991 11:02 | 56 |
|
Is there a way to selectively filter out attribute information
passed from an AM to the PM without writing my own PM?
I have a management attribute called the Diagnostic Block
which is modeled as a device status attribute. The Diag Block
is a 576 byte chunk of information; its gross to look at.
I only want to see this attribute when I explicitely ask for it,
ie., SHOW BRIDGE address DIAG BLOCK.
When I SHOW ALL STATUS I don't want to see this attribute.
Is there any way to do this?
JLL>
JLL> The current implementation does not allow this. It sounds like the issue
JLL> is making the output format of the Diag Block more user friendly. One
JLL> possibility is to define a new datatype (this would require a ECO) where
JLL> you would define how it should be displayed by the generic PMs.
JLL>
The options that I think I have at this point are:
1) Model the attribute as a separate entity
JLL>
JLL> I don't think this is intuitive to the user because they will be
JLL> navigating down to the child entity when in reality showing a attribute
JLL> of it's parent.
JLL>
2) Use another command to show this attribute, such as
> DISPLAY BRIDGE <addr> DIAGNOSTIC BLOCK, or
> DUMP BRIDGE <addr> DIAGNOSTIC BLOCK
Is this possible?
JLL>
JLL> This is possible. I would define the directive to be something like
JLL> DUMP_DIAGNOSTIC_BLOCK BRIDGE <addr>.
JLL> ---------------------
JLL> directive
JLL>
JLL> The way you have it defined would cause the generic PMs ask for
JLL> the input argument DIAGNOSTIC BLOCK. I don't think this is the
JLL> behavior you want. Also, by using another directive to display the
JLL> attribute, you are modeling the attribute as a response argument to
JLL> the action directive DUMP_DIAGNOSTIC_BLOCK.
JLL>
3) Always display the diagnostic block.
Does anybody have any suggestions?
Paul C
|
| 991.3 | Groups vs. partitions | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Thu May 09 1991 12:46 | 26 |
| This is an area of MCC that I am very unsure about and I would be interested
in understanding more as I have a similar requirement for Hastings.
If I wanted to achieve the effect you ask from NCL I would do it by leaving
the attribute out of all the standard attribute groups (ALL IDENTIFIERS, ALL
CHARACTERISTICS, ALL STATUS and ALL COUNTERS). It is not clear to me from
NETMAN whether the attribute should be returned when requesting ALL
ATTRIBUTES (my implementation does). This is what I am hoping to do with my
attribute.
This should work with the NCL implementations because they are driven off
attribute groups, not attribute partitions (an attribute is a member of
exactly one partition but of 0, 1 or more than one group). I may have
trouble with their parse table builders but I hope not.
However, I don't know what happens when MCC and the Phase V AM attempt to
deal with this. I would like to see the same effect that I get with NCL:
showing the attribute groups doesn't display the attribute but it an be
requested by name. Will it work?
In my case it won't cause too much problem if I can't get this to work. My
attribute is not a large status attribute: it is a longword characteristic
attribute containing debug flags that I don't really want people messing
with.
Graham
|
| 991.4 | New partition? | NMVT::WINKLER | | Tue May 14 1991 09:27 | 10 |
| We have a very similar requirement for DECmcc/SNA. One idea that we've
been kicking around is requsting a "maintenance" partition - to contain
attributes that we'd really like to have visible to service folks, without
cluttering up the user's view in the normal course of things.
I'd be interested in opinions on Graham's question; if we were to do that,
are we morally obligated to return their values on an "ALL ATTRIBUTES"
request?
K
|
| 991.5 | groups vs. partitions vs. all | TOOK::CALLANDER | | Wed May 15 1991 14:27 | 11 |
| Doug, in my opinion, is right on target. You should define the status
partition as you currently have it (big ugly attribute and all), and
then define an attribute group that the user can use so as to avoid
getting the diag block data. This will give the user the most flexibility
in using your module.
As to Kathrins question, it was my understanding, that if it is modeled
as an attribute we are supposed to return it in an "all attributes" request.
That includes big ugly data too. All attributes means all attributes defined
in all of the partitions; and as one of the other notes mentioned every
attribute must be long to 1 and only 1 partition.
|