Conference azur::mcc

1898.0. "Applications Management future" by TOOK::MATTHEWS () Mon Dec 09 1991 14:30

This note is to help those people in the field who handle questions
about Remote Applications Management. Usually these questions come
up in the context of OSI futures because OSI talks a lot about 
the management of arbitrary applications.

There are active development projects today within Digital to
provide management of VMS, Ultrix, and various applications
running on machines remote from the management user or process.
Most of these projects will use DEC CMIP as the management protocol,
the DEC CMIP AM (aka Decnet Phase 5 AM) as their access module and
the as yet unannounced common agent on VMS and Ultrix (aka OSF1)
as their agent platform. 

Historically, if you needed to add an object to DECmcc, you had
to develop and agent and an access module. You still do if you
choose a non-standard management protocol. However, if your object
supports DEC CMIP, SNMP, and in the near future OSI CMIP, you can
reduce the development effort significantly. The SNMP AM allows
you to introduce new objects via a MIB extension. The DEC CMIP
AM has always supported dynamic addition of new child entities of
node via the use of the MSL translator. As of V1.2, we will extend
this to global entities that will be the peer of node. 

In the future, the OSI AM will be completed with similar functionality.
This means that for the 3 generic management protocols of the future,
there is no AM development required; only the development of an MSL
description. For SNMP, you only need a MIB extension that accurately
reflects the object, DECmcc provides a MIB translation tool that
converts MIB extensions into MSLs. 

Although initially, we will not have a GDMO to MSL tool, one is being
planned and manual translation can be done if you know the right
incantations in the interim. 

This removes one of the development costs to support new objects. Let's
talk about the agent side. If the applications is resident on a VMS
or Ultrix system, then the common agent reduces the agent side support.
The management protocol stack, object module dispatching, and object
enrollment functionality is part of the common agent. This leaves the
minimal core functions which are specific to the object as the only
remaining development work necessary.

If the application resides on a brand x system, you still need to
implement the full agent. 

So, in future sales contacts, if the customer is talking about ultimate
applications management, you have a strong story to tell. As of V1.2,
if their application is on a VMS or Ultrix platform, they can start
their application development. If it absolutely requires OSI compliance,
we can still start their development, but it may be a few more months
until we have OSI CMIP fully implemented in DECmcc and the OS platforms.
This is a far more optimistic picture than we could paint before. Now
applications management is not some far distant future thing. It is
something that can be developed today and fielded in CY92.

If you have customers with strong requirements in this area; contact
me at TOOK::MATTHEWS. If you need to know about the VMS Common Agent
contact Maribeth Marcello in ZKO. If you need to know about the Ultrix
Common Agent contact Marilyn Fries or Oskar Newkerk in Seattle.

wally