Conference azur::mcc

>I would like to be able to send messages from any other system supporting
>UDP, specifically today from a Sun.
>This would allow me to quickly cobble together a cheap 'integration' from
>some other management system (managing some telecom devices).

No problem.  We did this a while back when the UDPIP sypport was added.
 All you need to do is copy over the example mcc_evc_send *source code*
and the API *source code* from your MCC kit, then build it on the Sun
system. (I'm pretty sure the instructions on how to make the binary are
in the file as comments)

>
>What is the message format and procedures over UDP.
>I have the port number.
>

I have no idea what you're talking about there.


regards, 
doug

hmm, i have a field test (T1.3.1) bms kit, and i think i'm missing a file...
could you post it or email it?
don't think it's in the toolkit kit either.
thanks.


hayes1> source mcc_evc_send_build.csh
mcc_evc_api.c:
cpp: error mcc_evc_api.c:139: Can't find include file inet_common_def.h
mcc_evc_api_dna_unix.c:
mcc_evc_send.c:


hayes1> ls
total 136
-rw-r--r--  1 adams       23948 Mar  8 15:05 mcc_evc_api.c
-rw-r--r--  1 adams       35880 Mar  8 15:05 mcc_evc_api_def.h
-rw-r--r--  1 adams       13254 Mar  8 15:05 mcc_evc_api_dna_unix.c
-rw-r--r--  1 adams       20956 Mar  8 15:05 mcc_evc_api_dna_unix.o
-rw-r--r--  1 adams       18808 Mar  8 15:05 mcc_evc_send.c
-rw-r--r--  1 adams       19304 Mar  8 15:05 mcc_evc_send.o
-rw-r--r--  1 adams        3547 Mar  8 15:05 mcc_evc_send_build.csh


hayes1> tail mcc_evc_send_build.csh
# Access to this sample in no way implies a limit to Digital's ownership
# of the Data Collector AM, any DECmcc software component, or DECmcc
# as a whole. Nor does access to this sample imply any current or
# future rights to use DECmcc. All rights to use DECmcc and/or any
# of its componenents are detailed in the various licenses of those
# components and are in no way abrogated by access to this sample.
#
########################################################################
#!/bin/csh
cc -Dunix -g -o mcc_evc_send mcc_evc_api.c mcc_evc_api_dna_unix.c mcc_evc_send.c
 -ldnet
hayes1>

hayes1> cd /
hayes1> find . -name  inet_common_def.h -print
hayes1>

QARed and fixed for V1.3
I'll see if we can get you a copy.

-- Erik

    
    Yep. Looks like a few files were left of the T1.3.1 kit.  I was assured
    by the "proper authority" that all the necessary files are in the
    V1.3.0 kit.
    
    I have already emailed the "inet_common_def.h" include file, but will
    attach it here in case anyone else runs into this before SSB.

/doug
( inet_common_def.h attached )
    
#define	SNMP_BUFFER_SIZE	460
#define	SNMP_MAX_NAME_SIZE	252
#define	SNMP_MAX_ENTITY_LEVELS	6
#define SNMP_MAX_ADDR_STR_SIZE	15
#define SNMP_EXC_VALUE_SIZE	512
#define SNMP_EXC_MAX_ARGS	3
#define SNMP_MAX_CACHE_ENTRY    50

typedef	unsigned char		BOOLEAN;

#define CMA_ALERTED		9

#ifndef TRUE 
#define	TRUE			1
#endif

#ifndef FALSE
#define	FALSE			0
#endif

#ifndef NULL
#define	NULL			0
#endif


struct	IPAddress
	{
	unsigned char 	addr_bytes[ 4 ];
	unsigned char	addr_string[ SNMP_MAX_ADDR_STR_SIZE + 1 ];
	unsigned int	addr_length;
	};

/*
struct	EntityInfo
	{
	struct IPAddress IPA;
	unsigned char	host_name[ SNMP_MAX_NAME_SIZE ];
	unsigned int	host_length;
	unsigned int	levels;
	BOOLEAN		is_host;
	BOOLEAN		is_wild;
	char 		FILLER[2];  * Fixes unaligned data access on ULTRIX *

	unsigned char	ent_value[ SNMP_MAX_ENTITY_LEVELS ][ SNMP_MAX_NAME_SIZE ];
	MCC_T_Descriptor ent_descr[ SNMP_MAX_ENTITY_LEVELS ];
	unsigned int 	ent_class[ SNMP_MAX_ENTITY_LEVELS ];
	unsigned int 	ent_wild[ SNMP_MAX_ENTITY_LEVELS ];
	};
*/

/*
struct	MCCReturnInfo
	{

	unsigned int			sts;
	unsigned int			cvr;
	unsigned int			mcc_sts;
	unsigned int			vms_sts;
	unsigned int			Exception_Index;
	BOOLEAN				Resources_Allocated;
	union {

		int		number;
		char		string[ SNMP_EXC_VALUE_SIZE ];

	      }				Exception_Value[ SNMP_EXC_MAX_ARGS ];
	char				*Exception_Ptr[ SNMP_EXC_MAX_ARGS ];

	unsigned int			SNMP_Error_Index;
	unsigned int			SNMP_Error_Number;

	MCC_A_AES			in_entity;
	MCC_A_AES			out_entity;

	MCC_T_Descriptor		*inP;
	struct MCC_R_ILV_CONTEXT	inP_ILV_cntxt;
	BOOLEAN				inP_cntxt_flag;

	MCC_T_Descriptor		*outP;
	struct MCC_R_ILV_CONTEXT	outP_ILV_cntxt;
	BOOLEAN				outP_cntxt_flag;

	MCC_T_Descriptor		*inQ;
	struct MCC_R_ILV_CONTEXT	inQ_ILV_cntxt;
	BOOLEAN				inQ_cntxt_flag;

	MCC_T_Descriptor		*timestamp;

	unsigned int			*verb;
	unsigned int			*attribute;

	};
*/
/*
struct	CacheEntry
	{
        MCC_T_FullName                  name;
        MCC_T_Integer16                 name_len;
        MCC_T_InternetName              internet_name;
        MCC_T_IPAddress                 internet_address;
        };
*/

    
    
    

 got the file via email, thanks.
hate to be a pain, but...

now i get:

hayes1> source mcc_evc_send_build.csh
mcc_evc_api.c:
mcc_evc_api_dna_unix.c:
mcc_evc_send.c:
ld:
Undefined:
tcpip_IO_host
tcpip_IO_init
get_evc_port
tcpip_IO_write
tcpip_IO_read
tcpip_IO_term
hayes1>

i can't figure out which library the tcp calls are in.
are they provided by the MCC toolkit (not installed on my system)?
i don't think so.
from the comments in the mcc files, these are 'native' calls, not the socket
interface.


and notice the get_evc_port() call also.
must be one more mcc file I need.

thanks.

Oh well.  I was afraid this was going to happen....
OK, let's try it this way :  
    
    1. copy all the files in TOOK::USER$43:[MCPHERSON.PUBLIC.EVC_API]
    2. Execute the API build script (mcc_evc_api_build.csh)
    3. Execute the mcc_evc_send build script (mcc_evc_send_build.csh)
    4. Report back here on success/failure, OK ?
    
Of course, you won't need to do any of this as soon as V1.3.0 turns up...
        
    /doug

        
Directory TOOK::USER$43:[MCPHERSON.PUBLIC.EVC_API]
    
INET_COMMON_DEF.H;2 rwxrwxr-xr-x   10-SEP-92 12:35:02     2252   [320,40]
INET_IO_DEF.H;1     rwxrwxr-xr-x   27-AUG-92 17:00:03      628   [320,40]
MCC_EVC_API.C;2     rwxrwxr-xr-x   23-OCT-92 12:03:17    23948   [320,40]
MCC_EVC_API_BUILD.CSH;1
                    rwxrwxr-xr-x   04-FEB-93 17:21:02      122   [320,40]
MCC_EVC_API_DEF.H;1 rwxrwxr-xr-x   07-OCT-92 10:03:02    35880   [320,40]
MCC_EVC_API_DNA_UNIX.C;2
                    rwxrwxr-xr-x   07-OCT-92 15:34:08    13976   [320,40]
MCC_EVC_API_UDPIP.C;2
                    rwxrwxr-xr-x   21-OCT-92 19:14:23    28966   [320,40]
MCC_EVC_SEND.C;2    rwxrwxr-xr-x   20-OCT-92 13:35:42    19468   [320,40]
MCC_EVC_SEND_BUILD.CSH;3
                    rwxrwxr-xr-x   04-FEB-93 17:21:58     3674   [320,40]

9 files in 1 directory

Thanks, that filled in the missing files.
Both build scripts are the same by the way.

Linked successfully on a non-MCC Ultrix/Risc 4.2a system,
and an MCC Ultrix/Risc 4.3 system,
now to try on a Sun.

Responding to an email requesting status...




Lets see here.
I got a friend to compile it on a sun at carnegie-melon, but i have not
tried to run the executable yet.
that has gotten delayed a bit.
if it happens, it will happen in the next two months.
i was waiting for that before posting my results in the notes file.

as far as compiling goes:
- the dnet library is obviously not present on the sun, so you need to modify
the makefile and expect 3 undefines in the final link.  no big deal since
we are interested in the udp.

- .h files are in different locations, so some modifications are required to
find those.

other than that, it seemed to compile ok.
	actually there was a little more involved, compiler specific.
	some routine declarations were in ansi format, and the compiler didn't
		support them, so they were modified.
	we had to create an 'extern int errno'.

i'll post a more complete explanation when i get it running.
and i'll also be able to perform the compiles myself, giving me a better
understanding of the precise differences.
my friend and i communicated via email, and i didn't want to take up too
much of his time, so i don't have complete knowledge.


tarpley adams

    Are there any licensing problems if customers want to run mcc_evc_send
    on other platforms - like SUN for instance?
    
    I have a customer that sells a network management application that runs
    on SUN. When they sell it, they would like to be able to interface to
    their customer's DECmcc systems.  Would it be allright for them to take
    our mcc_evc_send routines and package them into their SUN software for
    use by their customers in sending events from the SUN management
    application into DECmcc?  How are they covered for licenses - by the
    fact that their customers are running DECmcc?  Or do we regard the
    mcc_evc_send software as effectively non-licensed?
    
    What about support, or do we regard the software as unsupported?
    
    Thanks, Chris

after looking at the mcc_evc_api.c source code, it appears that we must've only
expected *end users* to want to use the api stuff, since re-selling must
(apparently) be covered by some additional agrement from DEC.  

If I understand the disclaimer mumbo-jumbo, as long as someone has bought a
DECmcc license, they are free to use & redustribute the code as they see fit,
so long as they do not resell it.   *Apparently* if they wish to resell the
code (for example, as part of another company's management system) then some
*additional* agreement from DEC is needed.  

I would like to see out stuff on as many platforms as possible and I certainly
don't want to see us putting up any artificial legal obstacles in customers (or
cooperating vendors') way....  Please contact Gail Ferreira (TOOK::FERREIRA)
for assistance in getting this worked out.

Good luck, 
/doug


[extract from mcc_evc_api.c attached]

#ifdef unix
#define module ident
#endif
#module MCC_EVC_API_GENERIC "X1.2"
/******************************************************************************
*
*  (c) Copyright 1992, DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS.
*  ALL RIGHTS RESERVED
*         
*  	THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT
*  NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL
*  OR ITS THIRD PARTY SUPPLIERS  
*  
*  	DIGITAL AND ITS THIRD PARTY SUPPLIERS, ASSUME NO RESPONSIBILITY FOR 
*  THE USE OR INABILITY TO USE ANY OF ITS SOFTWARE . THIS SOFTWARE IS PROVIDED 
*  "AS IS" WITHOUT WARRANTY OF ANY KIND, AND DIGITAL EXPRESSLY DISCLAIMS ALL 
*  IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF 
*  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*  
*  Notice:  Notwithstanding any other lease or license that may pertain to,
*  or accompany the delivery of, this computer software, the rights of the
*  Government regarding its use, reproduction and disclosure are as set
*  forth in Section 52.227-19 of the FARS Computer Software-Restricted
*  Rights clause.
*  
*  (c) Copyright 1992.  Unpublished - all
*  rights reserved under the Copyright laws of the United States.
*  
*  RESTRICTED RIGHTS NOTICE:  Use, duplication, or disclosure by the
*  Government is subject to the restrictions as set forth in subparagraph
*  (c)(1)(ii) of the Rights in Technical Data and Computer Software clause
*  at DFARS 52.227-7013.
*  
*  DIGITAL EQUIPMENT CORP.
*  550 KING ST.
*  LITTLETON, MA   
*  (508)486-5330
*  
*  RESTRICTED RIGHTS LEGEND:  This computer software is submitted with
*  "restricted rights."  Use, duplication or disclosure is subject to the
*  restrictions as set forth in NASA FAR SUP 18-52.227-79 (April 1985)
*  "Commercial Computer Software- Restricted Rights (April 1985)." 
*  
*  
* DEC is a registered trademark of Digital Equipment Corporation
* DIGITAL is a registered trademark of Digital Equipment Corporation
*
* DIGITAL distributes this software as a sample program for a remote
* source to inter-operate with DECmcc Data Collector AM. Digital expects
* no revenue from this program, and grants the rights to anyone who
* has licenses for DECmcc to copy, distribute, or modify this program
* at their risk. Digital retains the rights of authorship of the
* program with its current functionality. It can not be resold without
* the obtaining permission from Digital Equipment Corp.
* Digital does not claim the rights of derivative works
* which substantially alter the functionality of the original program.
* Although this program works with the V1.2 release of DECmcc, Digital
* makes no claims that it will perform any particular function, will
* perform a similar function with another release of DECmcc, that
* DECmcc future versions will interoperate with this sample, or that
* a similar sample will be made available in any future releases.
* The user of the sample is responsible to modify and test it adequately
* for any desired functions that they desire.
*
* Access to this sample in no way implies a limit to Digital's ownership
* of the Data Collector AM, any DECmcc software component, or DECmcc
* as a whole. Nor does access to this sample imply any current or
* future rights to use DECmcc. All rights to use DECmcc and/or any
* of its componenents are detailed in the various licenses of those
* components and are in no way abrogated by access to this sample.
*
******************************************************************************/