Conference azur::mcc

    an interesting thought..
    
    Now of course, wouldn't you just know it, I have my own 2 cents to add.
    
    With the split of the DECmcc group into two organizations (the
    framework, and the network applications groups) the networks group
    could actually package up a DECmcc completely customized for SNMP
    management *ONLY*. This type of an approach would allow for the type of
    customization you are looking for as well as a number of other
    throughout the system so as to provide an SNMP manager that comes up
    and autoconfigs all snmp entities right out of the box, starts
    monitoring for traps,....
    
    What do you think?
    

A very quick reply indeed......

I have a feeling that we are going to be going head to head against some
other very focused packages if we sell an SNMP based package only.

In my account, the powers that be appear to have ignored their huge 
existing proprietary base of DECnet Phase IV and SNA in favor of the
DME arguements put forward by HP.  Our user interface still lags behind
many of those vendors that only do SNMP management.

And if we only want the SNMP shop, why not sell MSU?  

If we can get our user interface to look and feel like MSU we might have
something w/o losing the nice integration and understructure of MCC.

The only problem I see with the prepackaged automated out of the box
approach to SNMP is that customers will then want the same thing for
all other AM types.

This should be an interesting discussion!

Al

AL-

I can see where you want to go, and I wish we were there, but it won't
be awhile even if we start today.  Unfortunately, Terminal Servers which 
can be managed both with TSAM and the SNMP AM curently require that they
be represented by two seperate icons.

One slightly kludgey solution might be to create a domain for each
terminal server which contains the two AM icons.  You would do the same
thing you are doing now with changing the name of the terminal server
icon file, but instead copy it to a file name with the word domain in
it.

(By the way, if you are not aware, you might be interested to know that
you can edit or create new icons running the DECW$EXAMPLES:BITMAP.EXE
utility.)

Dave

Dave,

I may be taking an overly simplistic view of this but it seems that it should 
be as simple as having the TSAM throw another icon in MCC_COMMON with the
appropriate file names.

I'm not certain I follow as to why a different icon is needed.

Also, can an entity now be registered as both a terminal server and as an
SNMP device?   If so, must it be refered to as two different names?

Al

We are probably both not understanding one another, is this what you want?

1. TSAM delivers standard terminal_server icons. (as current)

2. TSAM delivers another set of icons which look the same as the first, but
have SNMP in their file names.  When you bring up the toolbox and select
an IP station, you then get to pick from icons which show DS700, etc. on them.

If you wish #2, then you'll have to talk to the SNMP folks.  It would be
be improper for the TSAM installation to provide icons for another AM.
I would be happy to provide the SNMP folks with my icons.

I will mention that I'm not very enthused about this way of doing things,
and I am not sure you fully understood what I meant when I said that
the SNMP AM and TSAM require seperate icons to manage the same physical
entity.  By providing an identical set of icons for two seperate AMs
as you appear to asking, you prevent the user from knowing which 'protocol'
or AM will be used to comminucate with the server, when they click on
the icon.

Now on in the future, this may not be a problem, as then all new DECservers will
support a full management capabilities from SNMP, but today no.  Today, if
the user wants to set any terminal server attribute on a DECserver, they
must use TSAM, the SNMP AM would only be useful for shows, and then only
on the newer terminal servers.

Is this what you are talking about?

-Dave

Dave,

I guess this discussion could carry on for quite a while, but due to my limited
knowlegde of the internals of MCC, I would have suspected that it would be
fairly easy to do your #2.

Now, I haven't really had a chance to see where all the pitfalls might be, but
one of the things that MCC is knocked down for is it's difficult installation
and setup, compared to other products.  I simply see the inclusion of the
same or similar icon in the tool box, under SNMP as another thing the customer
does not have to do in terms of customization.

I guess on further thought you (the collective you) could come up with all
sorts of reasons why this could cause problems.  

I suppose the ideal situation will be addressed in your final statement of
total transparency.  The user should never have to know what protocol is being
used to manage any entity.

Again, this is probably not a major issue, but I would hope to hear from other
field folks on this for additional views.

I am curious about your statement that it would be improper for
the TSAM folks to supply an icon for the SNMP installation.  Is this an
architected limitation or a political one?

thanks,
Al

    Maybe we need a registration of ICON names?
    
    I agree that there is a risk that if the TSAM folks included an Icon
    for the SNMP class it might conflict in name with either an existing
    icon or a planned icon. This would be chaos.
    
    At this time the only registration that seems to exist in order to
    prevent conflicts is the use of the entity class in the icon name.
    The SNMP people get excusive use of the MCC_SNMP_ICON.DAT files
    and the LANBU people get exclusive rights to the MCC_BRIDGE_ICON.DAT
    files.
    
    If we had a central registry, or had some additional guidlines on
    naming of icons then groups could supply icons in multiple classes
    with the result that the end user would see more consistancy.
    
    For example, I have been using a convention for a series of icons I
    have created that cross many classes. They look like this;
    	MCC_class_RACK-uniquename_ICON.DAT
    because they are all rack mounted products in the same scale. Some are
    MCC_CONCENTRATOR_RACK-DC500_ICON.DAT
    MCC_BRIDGE_RACK-DB620_ICON.DAT
    MCC_TERMINAL_SERVER_RACK-DS550_ICON.DAT
    MCC_SNMP_RACK-WELLFLEET_ICON.DAT
    
    etc.
    I think there is merit to being able to augment the icon selection
    without getting into a hassle over who ownes em.
    
    What say?
    
    s/rob
    

I'm basicly in agreement.  The reasons I could not provide SNMP icons
are practical.  (But also to conform with political & SQM guidelines.)

Mainly, a person who pops DECmcc which includes the SNMP AM should not
see a change in available icons in his toolbox just because they happened
to have installed/not installed TSAM (which is by the way not available
on Ultrix.)  The SNMP AM should not dependant on whether or not
TSAM is installed...

I've made the offer Al, I suspect the SNMP folks are ignoring this
note because it doesn't have their name on it, you have to go to them
if you want this, I don't know who on their end can make this decision,
but you might start by checking with Chris Brienen.

-Dave

I propose two things....

1) Re-enter this entire discussion and rename it using SNMP_something
   so the SNMP guys will respond.

2) Build a large cinderblock wall at LKG and other Engineering facilities
   and paint it in large letters  "POLITICAL WALL".  Then place a can next
   to each wall and fill that can with sledge hammers.  Everyone should then
   be required to spend at least 15 minutes each day, with sledge hammer in
   hand, attacking the wall.  


On the more serious side, I like rob's idea of a registry or some mechanism
that would allow for auto-update of icons so that the customer does not
need to do this.

Al

Now, let's all calm down a bit.  The DECmcc group does communicate
among its parts.  Rob has answered as a representative of this group.
We will make sure that "the snmp folks" are aware of the discussion,
and will attempt to make the correct decision about icons based
on technical and customer considerations rather than politics.

-- Erik

RE: .8

>I've made the offer Al, I suspect the SNMP folks are ignoring this
>note because it doesn't have their name on it, you have to go to them
>if you want this, I don't know who on their end can make this decision,
>but you might start by checking with Chris Brienen.

	We're not ignoring this lively discussion.  It's just that you guys are
having so much fun that we thought we'd just read along.

	Anyway, at present, the snmp am developers have nothing what-so-ever to
do with the snmp icons that are included in the toolbox.  These are provided for
our use by the IMPM developers.  This is likely to change in the future. 

Dan

    I have talked to most of the folks involved and no one really seems to
    have any problem with another group supplying icons for a class other
    than the class that they are responsible (if it would help, I will
    supply them and we can end it... :-).
    
    I propose a naming scheme that will remove the most serious problem as
    an impediment, namely accedentally replacing an icon supplied by
    someone else.
    
    Today the scheme is
    	MCC_classname_uniquedescriptor_ICON.DAT
    therefore we must simply be sure that no two groups use the name
    "uniquedescriptor".
    
    I propose that development groups other than the group responsible for
    a given class include THEIR class number in icon names for other
    classes. FOr example;
    	MCC_SNMP_SERVER_ICON.DAT would be supplied by the owner of SNMP, in
    this case, the DECmcc Engineering group while
    	MCC_SNMP_17_SERVER_ICON.DAT would be supplied by the group that
    owns global entity class 17.
    
    All we would need to do is agree that groups would not start the
    "uniquedescriptor" with a numeric folloed by underscore unless they are
    supplying it for another class and in that case the numeric would be
    the class number they own.
    
    Comments?
    
    s/rob

Sorry Rob, I'm not very enthusiastic about your plan.  My feeling is
when DEC delivers an AM, all of the icons DEC could ever have provided
should show up for that AM.

Follow this thought: just imagine a customer installs the SNMP AM
on one system with TSAM, and on another system w/o TSAM (very possible,
since TSAM does not run on Ultrix.)  The user will see one set of SNMP
icons on one system, and a larger set of icons on the other.  If I were a
customer this would set me to scratching my head.  I would probably
call DEC to find out why the Ultrix kit did not come with all of the VMS
icons.

I think we should do several things:

1. Document for Joe User how to create/edit/copy icons.  Give them the
example of copying a TSAM icon to SNMP.  Even if SNMP does end up using
our icons, this will cover us when we didn't get every one that we should
have.

2. Identify who will be interested in copying icons. Then do it!  I have no
problem with anybody using the TSAM icons.  Get in touch with me, or
just grab the TSAM kit, they are all in Saveset B.  I am not going to go
out of my way to do this myself though.

3. If this is an important enough issue, I think you Rob are the person
to be the icon-meister.  You have done a great job with the new rack mount
icons which I will be including, and you know who to get in touch with who
anyhow.

4. Although Al went on a long tirade about brick walls
etc., that is not the problem.  Why would I spend my time working on an issue
I disagree with?  Al, you have a DEC badge too, if some one is not doing
what you want, make sure it gets done by contacting the concerned party
yourself, and making the request, don't beat me up for not picking up your
ball.

Regards,
-Dave