Conference azur::mcc

V1.0 of the Vitalink Translan AM WILL NOT work with V1.2 of DECmcc.   

There have been substantial changes to the kernel (namely: the threads package)
and the mcc_ea routines have changed (used by the Translan AM).    You will
have to wait until an updated version of the AM is available.

... and before you ask:  we don't have a commitment from Vitalink on when they
will provide the next release.  Hell, they don't even have a T1.2 toolkit to
start the work with, yet.

Stay tuned.

/doug

    I thought the message for EMA/MCC was the wonderful world of Plug and
    Play ;-)

    Just because we develop extra functions (even re code) in the Kernel,
    SHOULD NOT MEAN THAT THE SOFTWARE BUILT AROUND THE CORE stops to
    function (I can understand that situation if the developers of the AM
    did not "O Bay" the rules)

    What guarantee has the field that code developed to MCC 1.1 will work
    with V1.2, if there is any doubt then this means that parallel
    development is not possible, and all code developed will need to be
    "certified" against 1.2 :-(

    Can someone in engineering Please provide an explanation, this does not
    paint a good picture.

    Amrit

    See Note 1907.2 for information about backwards compatibility.

    
    To make it real clear, we had to make a decision, and no it wasn't an
    easy one. Our initial releases were VMS only, it would have been
    wonderful if we could have ported to the ULTRIX environment without
    having to modify the base system, but this was not possible. We also
    found that some areas of our process model had to be modified to get
    things working under multiple platforms. Unluckily these changes mean
    that at a minimum all earlier components must recompile and relink. For
    some components that will be all that is necessary, for others they may
    be required to make some modifications within their modules to make
    sure that  OS dependencies are handled, and that the module works
    correctly under the CMA thread package.
    
    

Back in early December no date (or for that matter committment) was available 
for the Translan AM for DECmcc V1.2. Have there been any changes to the status?

This is now becomming important. One of the reasons many people, both internally
for Easynet and for the various Network Services and externally in our customer
base, changed to DECmcc was the ability to monitor/manage Translan Bridges from
the same environemnt as the DECnet environment. If a version of the Translan AM
is not forthcomming soon, many of the people who would be testing V1.2 in a live
environment and providing valuable FT feedback will be restricted to running on
V1.1 only. They will also probably not upgrade when V1.2 actually ships.It is 
not sensible to suggest losing Translan support as many operations now depend 
on it.

The bottom line is that without Translan support, many people will NOT install
DECmcc V1.2.

Please can we have an update.

Paul.

From:	DELNI::TERZIAN "DAVE TERZIAN...DECMCC STRATEGIC VENDOR PROGRAM...DTN 226-5611  03-Feb-1992 1030"  3-FEB-1992 10:28:34.19
To:	HAZARD::BAKER,TOOK::MCPHERSON,TOOK::E_HATEM
CC:	TERZIAN
Subj:	Vitalink V1.2 TransLAN AM

Paul,

I didn't have time to respond to your note, but V1.2 of the Vitalink AM
is scheduled for completion within the next few months.  Vitalink just got
the DECmcc V1.2 FT kit along with management go ahead so no work has begun yet.

Regards,

Dave

    	Hi, any news yet Doug?
    
    Cheers....

Trust me; I'll let you know when it's ready.  A notice will be posted in here
as well as sent to my TRANSLAN_AM_SITES.DIS distribution.

By the way, at last count it appears that the TransLAN AM has been copied to at
least 255 different systems and I have about 40 _confirmed_ installations on
the Easynet, to date.

/doug

    By the way Doug, is there any way we could persuade Vitalink
    to provide some more functionality. Such as:
    
    Allow collection/trapping of (at least) their Alarm messages.
    Polling to determine when a line has gone down on a bridge
    just doesn't cut it.
    
    Also realignment of the attributes. For instance, you seem to get 
    some redundancy of specific attributes across different attribute
    groups.
    
    
    Another anxiously awaits,
    
    Steve
    
    

re . Note 1885.9 by TROU07::SLEE 

>    By the way Doug, is there any way we could persuade Vitalink
>    to provide some more functionality. Such as:
>    
>    Allow collection/trapping of (at least) their Alarm messages.
>    Polling to determine when a line has gone down on a bridge
>    just doesn't cut it.
    
    If I haven't said it already, Vitalink's plans are ONLY for making the
    changes required to enable their TransLAN AM to operate in a DECmcc/VMS
    v1.2 environment.  Period.   They are not planning any enhancements.

    YOU DO have workarounds for this, made easier with V1.2.  Frinstance,
    you can write a simple shell script or program that will read all of
    the silly alarm messages that TransLANs spew across the console port.
    (assuming you can establish an RS-232 connect to at least one TransLAN
    in your metwork. )    

    The program (or DCL or Shell script) can simply watch for a predefined
    list of Translan events, grab the address or whatever, then send that
    event to DECmcc using the Data Collector API (see sample C code if you
    want to use a DCL or shell script to do this).   With a little bit or
    creative Targeting from DECmcc, you'd have a decent workaround.

    Also, the 10.5 rel;ease the TransLAN software will have concurrent SNMP
    and RBMS support.  THe SNMP agent (and DECmcc SNMP AM) supports
    EnterpriseSpecific traps.  The 10.5 software a;;pws you to map the
    console messages or alarms into SNMP traps, so you can use the SNMP AM
    to receive these traps and do what you will from there. 

    That oughta keep you busy & off the streets for a while.

>    Also realignment of the attributes. For instance, you seem to get 
>    some redundancy of specific attributes across different attribute
>    groups.

    This, I do not understand.  ATTRIBUTE PARTITIONS (e.g. Identifier,
    Status, Characteristic, Counters, Statistics) are architected and
    rigidly-defined groupings of entity attribute.     Dispatching is done
    on a PARTITION-wide basis.

    ATTRIBUTE GROUPS are arbitrary developer-defined groupings of
    attributes from *any* attribute partitions.   The intent is to allow
    developers to 'clump' together attributyes that are very likey
    relatad from an end-user's point of view.  Specifically, the "Spanning
    Tree" attribute group (used by BRIDGE and TRANSLAN) contains attributes
    that ALL have to do with Spanning Tree calculation etc, but also fall
    into different ATTRIBUTE PARTITIONs...   That would account for the
    'redundancy' that you comment about.

    Is that what you are referring to?   If so then it is NOT a bug.  It's
    a feature.   Honestly.
    
/doug    

    
    Steve
    
    

    What is the status of the TransLAN access module for an Ultrix-based
    DECmcc station.  My customer wants to run on Ultrix (since he sees this
    as an opens systems direction) for as much as possible.  Given that the
    TransLAN AM has to be modified to work with DECmcc 1.2, and this in
    part was due to providing support for Ultrix (i.e. the internal
    interface changes), does this mean that the TransLAN AM will work on
    both VMS and Ultrix DECmcc V 1.2 onwards?
    
    If not, does the possible work round in using SNMP apply to older
    TransLAN such as III's?
    
    Thanks and Regards,
    
    jeff

    
    There is no intention to get the TransLAN AM to work on ULTRIX.
    The demand for the Vitalink Bridge AM (VBAM) on DECmcc/VMS is due largely to
    customers that don't want to install UCX to run TCP/IP.  It would be
    a significant amount of work to get the module to work on DECmcc/ULTRIX 
    due to transport issues, etc.
    
    However, the SNMP agents in the Vitalink bridges should be sufficient
    for most operations on both the VMS and ULTRIX platforms. 
    
    Functionality of VBAM vs. SNMP is as follows.  VBAM provides fairly
    complete bridge management of the TransLAN and TransRING products. 
    SNMP provides full management for TransLAN 350, TransLAN 335, TransRING
    and partial management for TransLAN III and TransLAN 320.
    
    Since upgrades are very expensive, our hope is that once the upgrade to 
    DECmcc V1.2 is complete, no further upgrades will be required.  However, 
    time will tell...
    
    Dave Terzian