Conference azur::mcc

   Andrew -

   You get the dispatch error because the Terminal Server AM has not been
   enrolled properly.  

   With regards to the parse table error during the installation of the
   Terminal Server AM, this was a parse table builder problem which has 
   been fixed in the MCC BMS SSB kit.  (The problem actually did NOT affect 
   the operation of the Terminal Server AM anyways).

   It probably was a mistake to try to install the Terminal Server AM, if
   you were having problems with the basic MCC system, which it sounds like
   you are.

   Rather than just criticizing the Terminal Server AM, and saying that
   it should not be in field test, it would probably be more helpful, both 
   to you and to the Terminal Server AM development team, to work on finding 
   the source of your problems.  

   We have many internal and external sites successfully using the Terminal
   Server AM, and I would be happy to help you get it running on your system. 

   You should start by sending me a copy of the installation log.

			Lynne Izbicki
			DTN 543-4419

Now that you have had your induction into MCC and DNS ( and accompanying
curse ) it is time to find out what is going on.

So you have two options, give us a call and we can talk you through it,
ot answer the following and we will work through it here (either way
have these answers ready).

hardware:
DECmcc software version:
VMS version:
IVP completion status:
environment --
	cluster or standalone
	DNS client or server

what were you attempting to do:
from what PM:

    re .1
    
    	Thanks for the patient reply. FWIW I did realise that the AM was
    not enrolled correctly but haven't figured out how to de-enroll it yet
    but I will check in here now that my problem has been clarified as I
    believe there are some notes about de-enrolling. Also, MCC was working
    before we installed the AM but this is not to say that the AM broke it,
    it just means we didn't leap into the FT with a known faulty base
    product.
    
    re .2
    
    	H/W = VAXstation 3100  Model 48 - 20 meg
    	S/W = SSB Kit Released 7 March 1991 (There may be later SSB kits)
    	VMS = 5.4-1
    	IVP = Successful
    	Standalone System
    	DNS Server
    
    	Beyond the above, the install worked fine but a week or so after
    the install (before the TS AM went in) the DNS licenses ran out on the
    MCC node and on the node shadowing its clearinghouse. THis blew MCC up
    until we got new licences and of interest to you may be the fact that
    we fixed the license on the MCC node and forgot about the shadow node
    until we received DNS informational erros about failed to propagate
    followed by MCC fatal errors. I'm not sure this should happen. ANyway,
    the licenses are fixed now but these intermittent DNS-related problems
    are occurring.
    
    	It is pretty difficult to find a convenient time to call as we are
    working a 12 hour time difference here. I have no doubt (having had a
    night's sleep) that these problems are our fault but what concerns me
    is that I have 9 years experience in DEC handling VMS and layered
    products, Tony has umpteen years experience as a telecomms guy dealing
    with all sorts of network products - if we can't get this stuff to work
    what hope for our customers?
    
    	Maybe we can split the difference and just re-install the MCC kit
    with DNS working properly on both systems and see if that helps.
    
    thanks,
    Andrew Waites
                  

On a completely separate note:

Tony and Andrew have expresses a degree of frustration that we should perhaps
at least be aware of.  As MCC is installed in more and more customer sites, we
should be taking steps to avoid this level of frustration in the field.  When a
DEC internal person hits these kinds of problems, they have the notes files and
a wide variety of local support mechanisms to blow off steam to.  When a
customer hits this frustration level, they have an IBM rep to blow off to (and
IBM reps love to hear customers get p*ssed off at DEC).  Speaking as a
relatively intelligent system manager, I can sympathize with some of the issues
(if not the tone) brought up in the base note.  I still have only a limited 
understand of the concepts and approaches used in MCC and I've been working
on little but for the past month or two.  I can imagine the problems that a
system manager must have when bringing up MCC is not the only task he's
attending to.

Knowing that there are several human factors, documentation, and training types
that must be following this conference, I would suggest that perhaps we need to
visit (or revisit as the case may be) some of the human factors angles of
the MCC product.  The functionality, flexibility, and ingenuity behind this
product are probably the best DEC has ever offered.  Now let's see if we can
find a way to package it (sugar coat it if you will) so that the customer who
makes the wise decision and purchases it won't be as frustrated as some of our
own staff are getting.

I too am getting frustrated, but I think we can smooth out many of the
problems, so I'm hanging on...

timf

    RE:.0
    
    Andrew,
    
    Please do not spontaneously combust.  You are having problems that I
    for one have never seen before.  We have tested MCC using many dozens
    of configurations of DNS, VMS, and MCC.  No one can test using every
    possible combination and permutation, that would take years, and we are
    trying to make some money, which requires shipping on time with some
    reasonable functionality.  Whenever two large projects, like MCC and
    DNS, attempt to "slam-dance", and try to make it look like artistic
    expression, there are always synergistic problems.  We have minimized
    this as much as possible.  We have added much more documentation on
    troubleshooting MCC/DNS problems.  Almost always (but not always)
    something "unusual" happens which starts everything going south.  I
    remember one case where the disk was bad.  It was pure luck that
    we noticed a VERY high error count on that disk.  If you consistently
    rebuild PTB, and you consistently get RMS errors when you analyse the
    file, why is that an MCC problem?  MCC cannot tell RMS to write out an
    invalid RMS structure to disk (if any readers know how, then I would
    like to hear it) without getting an RMS error back.  Please check the
    error count on that device (it better be 0).
    
      As far as DNS is concerned, I would recommend the simplest
    configuration possible.  If you have a large DNS space, and you need
    things like replicated clearinghouses, etc., then okay, you need it.
    MCC still works, but there is fundamental law of engineering that says
    the probably of something breaking is directly proportional to the
    number of components that are trying to work together.  Now if the DNS
    namespace has become corrupt because the license has expired on the
    Clearinghouse node and the shadowing node, then you probably need to
    rebuild your namespace.  Again, I cannot see how this can be viewed as
    a problem with MCC (it probably would have happened even if MCC was not
    installed).
    
    I'm not saying that you haven't found an MCC bug, or that the
    documentation is perfect.  In your case, it appears as though you have
    several problems all interacting, and masking each other.  The best
    approach it to isolate one problem at a time, fix it, and go onto the
    next.  It is time consuming, but much less time consuming than wrapping
    it all up as one large (seemingly hopeless) problem.
    
    -Matt.
    

    Matt,
    
    	Excuse the delay in getting back onto this. My name gets even
    muddier eh. We have the license problems resolved and the DNS errors
    (that were occurring pretty regularly without the aid of MCC) seem to
    have died down - although it is always a worry not knowing exactly why.
    Brings us down to the TS AM and will have an update on that shortly.
    Tony is now back from various travels (including stunning
    demonstrations of MCC elsewhere) and has to work with me again (sigh)
    but we will try a couple of simple rebuilds prior to our final option
    which is a complete rebuild from scratch.
    
    	I agree with the suggestion that we should maybe avoid shadowing
    the clearinghouse but am tempted to keep at it if only to continue to
    test the product/s.
    
    regards,
    Andrew

    
    There are two issues regarding the complexity of DECmcc that our
    customers are going to face - product complexity and concept
    complexity.  Product complexity refers to the types of problems that
    have been documented in this note, and others.  Its dealing with all of
    the installation issues, layered products, licenses, DNS, etc. 
    Obviously its a Digital goal to simplify products as much as humanly
    possible - to the point where customers can can through the
    installation phase and live to tell about it.
    
    Concept complexity refers to the types of issues the customer faces in
    trying to solve their [network] management problems using DECmcc.
    Its dealing with domains, identifying what entities to monitor, how
    often to monitor, what alarm rules to establish, what reports to
    generate, how to perform problem management, troubleshooting using
    DECmcc, ... (and the list goes on).  Managing large, very multivendor
    networks with all kinds of devices, vendors, and uneducated network
    users IS complex.  DECmcc may help simply the management of these
    environments - but only after a million questions have been answered to
    help get DECmcc operational.  Note that there is a distinct difference
    between installed and operational.  Operational is configured and
    actively monitoring the network, generating alarms, and so forth.
    
    Many customers are willing to pay [Digital] fairly good money to help
    solve the concept complexity issues.  These same customers appear
    willing to bundle in DECmcc startup services, which help solve some of the
    product complexity issues for the customer (not DEC).  I recently
    posted a note in the NETMGT notes conference about DECmcc customized
    startup services being offered by the Digital Services (EIS) Network
    Consulting Group.  I'll cross-post that note as the next reply here.
    These services are for customers only, and they are not intended to
    replace ease-of-installation or ease-of-use requirements that
    Digital places on our products.  
    
    My reply does not address the primary points made in this note, but
    might help promote ideas with respect to the question of "How are
    Digital's customers going to deal with DECmcc?"
    
    Mike
    

               <<< ENUF::$1$DUA4:[NOTES$LIBRARY]NETMGT.NOTE;1 >>>
                            -< Network Management >-
================================================================================
Note 237.0                      DECmcc Consulting                      6 replies
EISNCG::OLEARY                                       40 lines  27-MAR-1991 10:28
--------------------------------------------------------------------------------
    
    The Digital Services (formerly EIS) Network Consulting Group is 
    developing a DECmcc service consultancy to include the new and
    ever-changing functionality of BMS V1.1 and beyond.  We've delivered
    countless consultancies involving the standard DECmcc-EMS and SMS 
    products, but BMS changes many of the components of our previous
    service.
    
    In a nutshell, our consultancy model for DECmcc involves three distinct
    (but important) phases:
    
    	I.   Network management requirements analysis and design
    	II.  Customized implementation of network management tools
    	III. Network management expertise transfer
    
    Phase I  covers the absolutely necessary planning function required
    prior to implementing network management tools.  The functional
    requirements and deployment strategy (among other things) are
    determined here.  Phase II is the desirable "start-up" service that
    many customers are looking for.  This phase currently involves DECmcc
    and VAX/DNS, and bridges the gap between installation of products and
    full-function network management station.  Phase III allows
    experienced Digital consultants to transfer critical network management
    expertise to the customer's staff.  Typically, this phase involves a
    mix of hands-on consulting using the tools to troubleshoot problems and
    consulting sessions/seminars on network management procedures.  This
    final phase bridges the gap between the customer having a production
    management station and being able to effectively manage the network
    with the station.  Phase III also identifies areas which still need to
    be addressed (through products, consulting, or by the customer).
    
    I am in the process of writing up a service description for the DECmcc
    consultancy.  Comments and suggestions regarding the DECmcc service are 
    encouraged - please send them to EISNCG::OLEARY.  In addition, we
    just started up a consulting notes conference (EISNCG::CONSULTING)
    where information (when completed) will be posted.  
    
    Regards,
    
    		Mike

    With 500 customers about to get SMS/EMS V.next in about a month, the
    need for a well defined setup service is needed.  A fixed price, and
    set of deliverables - and knowledge about where the resources are going
    to come from will make it successful.  Probably 50-75% of those 500
    customers need this service in the timeframe of June 10'th thru
    October.  In many cases, the bounded service would detect the need for
    more service, such as what Mike's group (.8) offers.  The question, is
    where does the bounded service come from?  Does NETstart provide that
    today?  
    
    bill

    
    Phase II of the service described in .8 is probably the bounded service
    that you are referring to, Bill.  In its "bounded-est" form its
    
    	- installing the product(s)
    	- configuring the options/loading the databases to some degree
    	   	(enough to get the customer rolling and enough to train the
    		 customer on the different features)
    	- training the customer on how to use DECmcc
    	- some "hands-on network management and troubleshooting using
                DECmcc" consulting
    
    
    Do you think a centralized service delivery group is necessary for
    this?  Also, if someone *forced* me to come up with a number of
    days/hours to make this service bounded (yet sellable), I would
    push strongly for 5 days.  
    
    Mike

    What is needed - and at the 5x5 yesterday it was discussed - is a
    quick service that can hit a higher percentage of SMS/EMS customers. 
    What is being proposed is a training seminar of a day or so to be
    delivered at ACT's during Q1, with a $50 or so charge to customers.  
    It would cover the top 10 mistakes that one makes during the
    installation of MCC, and set some expectations of what the product can
    do in it's V1.1 incantation.  It would also contain a mild sales pitch
    for services such as Mike's Phase II service.
    
    What is needed in the long run is a decentralized version of Mike's
    service - Phases 1-3.  There are currently too many customers that need
    the week of service, but there are not enough bodies to go around, and
    those that are around are too expensive - plus the knowledge must be
    pushed closer to the customer.
    
    bill

I and another DEC engineer, each with something like 15 years at DEC, have
found that mcc is almost unusable.  This is one of the few products that I
have used where the documentation is an absolute necessity to do anything
with it at all.

Things are further complicated because the model that mcc for how an
organization works runs counter to the way that DEC works.  At this point
we stuck; mcc looks to be much more trouble than it is worth, but we have
some bridges that we need to manage and the decbridge 600 is only supported
thru mcc ems.

And I thought that rbms was bad....

RE: .12

Well, there are a few things you can do about your frustration.

1.	Just flame in the notes files and get nothing done.

2.	Flame at MCC engineering and piss them off, getting nothing done

	( I tried this, so I know the results from direct experience :-} )

3.	Offer CONSTRUCTRIVE feedback, and, as a result, have a real positive
	influnce on the product direction.

	( I tried this too, so I know the results from direct experience :-} )

In the past few months, I have found the MCC engineering has, with very few
execptions, been EXTREAMLY willing to listen and try to understand the problems
arround easy of use.  Last week, some people outside MCC were invited to a
design review of an AM to make sure the customers views and needs were
understood.  The people (in MCC) there want to do the right thing, but the 
problems being addresses are probably about as complex as TOPS-10(SMP) or 
VMS V4.  Maybe even more complex. Not an easy task, considering the 
time-to-market demands being made at the same time.

RE: 
>Things are further complicated because the model that mcc for how an
>organization works runs counter to the way that DEC works.

After 15 years "inside" DEC, it appears that you have lost some insight
of our customers.  After spending the last 5 years (of the 15 I have been at 
DEC) doing direct consulting for customers, NOT ONE CUSTOMER has EVER been
organized like DEC.  NOT ONE.  We dont make money building products designed for
DEC's use.

MCC is addressing LOTS of issues, some very complex problems, and, today,
is probably one of the best designed and flexable network management tools 
arround.  It seems that your problem is that it is OVERKILL for managing one
or two bridges, but thats not the market.  Companies like CITICORP are looking
at MCC for the management of almost 600,000 "devices" network (world) wide, with
products from dozens of different manufactures.  MCC is designed "just right"
for customers like that, and lots of smaller ones, too.

From what I have seen, V1.2 looks like it will be MUCH better, in terms of
functionality, features, and options.   I just wish it were shipping next week.

(This ad NOT paid for by MCC engineering. It just happens to be the way I feel.) 

thanks DAVE we do try our best to listen. One of the hardest things we have
found with people moving from the older point products is that they are
like an old pair of shoes, they have just grown accustomed to them.

MCC follows NCL and not NCP and RBMS (or any of the other point products),
that does mean learning new things. But along with learning new commands
and syntax you have alot to gain. We have tried hard to put help into
the system, like the FCL forms mode with it's command completion and PF2
context sensitive help key. To take advantage and learn about MCC overall you
need the Director and BMS  use manuals. From there you only need the 
books applicable to what you want to do (and yes documentation is working
to cut down onthe number of pages and get bookreader formats available to
help in this area as well).

We are always open to input, and do our best ot incorporate it. We don't do
things like the old products, but hope that we are starting to move into
a realm where you will someday be asking otehr prodcuts to do it like
MCC. Keep the feedback coming.

jill
PL for notification services and FCL PM

So, I'm not sure that you can say that DEC is organized totally unlike any
customer; that all the customers that you have personally dealt with may not
be like DEC is certainly not a surprise to me, and I agree that we should not
design products exclusively for the way that DEC works, but that is no reason
to ignore the reality of DEC.

Just to provide a bit more background, I work in CVG and we have in our lab
more lan equipment than 50%, or maybe 80%, of our customers have company wide.
What CVG tests is VAXclusters and the design center for VAXclusters is now
fiber.  In a few years it will not be uncommon for the large VAXcluster
configurations to have something on the order of 100+ LAN components and
I expect that our lab will have reached something on the order of 1000 LAN
compenents.  We will on occasion be configuring all of this equipment into
a single computer system.  Actually, to say `our lab' is also somewhat
misleading, since at that time I expect that we will be running in a
distributed environment and we will have two or more labs separated by
20-50 kilometers.

The kinds of issues that a VAXcluster system manager will need to deal with
will include virtually everything that current corporate network managers
are faced with, plus all the current issues faced by current system managers.
For some managers there will be no distinction between system management
and network management.

While I'm not directly involved with addressing the product requirements in
this area, CVG peer organizations are, in particular, the groups that have
developed VCS, VPA, SPM, etc., are now working on integrating and adding to
these products.  MCC is one major facit of the overall piece.

I suppose my greatest frustration is that a lot of people in the LAN area
don't understand that VAXclusters is one of the major engines driving the
sales of our LAN products.  The market for FDDI components is limited until
VMS provides some major support for FDDI.

Does the MCC engineering and business model support the idea of selling
MCC as a component of a computer system sale, and not as part of a corporate
communication system sale.  Keep in mind that many DEC computer system sales
are in conflict with the corporate IS computing model, eg., IBM computer
systems.  Does your model depend on a strong cooperative working relationship
between your customer and his corporate organization, or can you sell into
the situation where there is minimal cooperation.

DEC's corporate network group needs to provide quality service to the entire
corporation, and CVG's requirements place them in an awkward position.  They
have suggested that we isolate our network from the corporate network on more
than one occasion and we had to resolve that issue at the VP level.