Conference azur::mcc

	Brad,

	As for your second question...

	The use  of Target Entity within an alarm rule would allow each
	alarm rule on  the  data collector to target (turn color) other
	icons.

>	The use  of Target Entity within an alarm rule would allow each
>	alarm rule on  the  data collector to target (turn color) other
>	icons.

John,

Your statement implies I can write multiple alarms against the collector.
That would then imply I can have multiple events sent to the collector. How
do I differentiate between different events when sending from the 
MCC_SEND_EVENT command? Is it done from the title (ie. does title equal the
event name?)? For example:

$ MCC_SEND_EVENT
	DEST...
	COLLEC...
	TITLE "LKG_OFF_NET"
	TEXT...
	SEVERITY...

The receiver NOTIFY command would then be:

NOTIFY DOMAIN <domain_name> ENTITY LIST = (COLLECTION) -
	EVENT = (LKG_OFF_NET)

or write an alarm against the collection with this specific event.

Sorry about these questions if they seem to be childs play, but I'm trying
to understand these mechanisms so I can evaluate whether to put some time
aside for this. The doc doesn't quite bring me to the proper level of
understanding.

thanks,
brad...

    An answer for your first question.
    
    No, You do not run DECmcc at the remote end. You write an event sending
    routine. We supply sample code with the Data Collector that provides
    the lower level routines that interface with DECnet. The whole idea
    is that we want a simple collector mechanism which can be installed
    on any remote node and uses a minimum of resources. Thus, you can
    have one on every remote node that has DECnet. 
    
    If your collector is serving as an intermediary for other
    non-manageable devices which do not have DECnet, then you can
    drop domain icons of any shape on your map for each of the
    non-DECnet nodes. In theory, you then use the target entity
    statement in the alarm rule to get the correct icon to turn
    color. Now here comes the tricky part. You need to have the
    remote collector know about each unmanageable entity and
    send the instance data for each of them within the event.
    
    I need to talk to Jean Lee to make sure that we are doing the
    correct thing for your example. If not we will include this
    in our requirements for the next development cycle.
    
    wally

re: first question

Wally's right.  MCC doesn't have to run on remote node

re: second question

>The docs lead me to think that each Collection can only control one 
>icon, true???

Not true.

The event that you generate at the remote end using the object library supplied
with the data collector requires several arguments, among them are the 
collection entity to send the event to and the target entity that the event
applies to.

(above nomenclature not guaranteed to match documentation)

It is the target entity that will turn a color when an event is received by the
IMPM, not the collection entity.

The idea here is that you can have multiple psuedo-sinks (collection entities)
and by letting managers drop the right collection entities into the right
domains you give the managers enough flexibility to pipe only the collection 
events that make sense for a given domain into that domain.

With the FT kit, you have to 
	1) have the collection entity that you're sending events to in the 
	   domain that you want icons to change colors in.  That gets 
	   the event into the right domain.
	2) have a notify request for the domain in question (or one of its 
	   parent domains) enabled in the IMPM with the following arguments:
		Entity List = (collection *)	
				(or you can be specific on the collection name)
		Events = any event
	   That will cause the IMPM to be listening for the event.

Currently you can't save/restore notify requests in the IMPM, so you have
to set up the notify request by hand each time.  That will be fixed for SSB.

Collection events are posted in the CONFIGURATION event partition, so the
"default" notify requests don't pick up data collector events.  The alternative
would be to have the collection AM post these events in then NOTIFICATION event
partition, but then there would be no way to turn them off if they're not 
desired and still be able to listen for Alarm events.  I can see reasons for 
wanting it both ways.  I flip-flop back and forth as to which way I think
make sense.  Half of me (the ease-of-use half) says "Gee, if they didn't want 
collector events they wouldn't put a collector in the domain... so the collector
should post in the NOTIFICATION partition".  The other half says "To preserve
flexibility, we'd better keep those collector events in the CONFIGURATION
partition.  And we'd better get SNMP to re-think where they're posting their
events too."

>Even if it can only theoretically control one icon can I use targetting with
>the event??,

You can use retargetting on the events the DC generates.  Presently the DC 
generates a single event.  And no, there's no way to retarget based on the
arguments of an event.  But you can retarget based on the event source and
on the managed object, which may be sufficient if the existing capabilities
described above aren't.

There were early plans to allow users to extend the DC to post user-defined
events.  I'm not sure of the status of those plans.


Anyway, it sounds like what you want to do is the following:

1) set up a domain for these non-manageable entities
2) populate the domain with reference entities named such that the event sink
   application will be able to generate events with the "target entity"
   argument equal to the reference entity's name
3) put a collection entity into that domain and have the event sink application
   send its events to that collection entity
4) plan on creating a notify request for that domain in the IMPM to listen
   for incoming collection events 
   (entity list = collection *, events = any event)

Then, sit back and watchen dem lights blinken.

enable mcc 0 collection_am sink decnet

    
    Hi,
    
    Sorry,if this has been answered somewhere else
    
    I tried to play with the collector access module and send event from 
    the dcl and shell level ,but it seems that the command MCC_SEND_EVENT
    is not defined in DCL tables ,nor as a symbol.I also look for 
    a specific MCC_SEND_EVENT exe without any success. 
    
    So I am wondering is this command is defined somewhere and what to
    do to enable its.
    
    In Advance thanks
    
    Jean
    
    

    That is because mcc_send_event is not the correct call. The call to the
    datacollector interface is different, and has not been openly
    documented at this time. To use it from your own application we will be
    providing a library to link against which will contain all of the
    services necessary to send a message. At this point in time it is my
    understanding that we are working (that is Jean Lee is) with a select
    group of people to run a field test on the api/library that the module
    is supplying. We are still hoping to make the send also available
    directly from the mcc interface, so that managers can send messages
    (like: I am taking the router down at 1:00) between management systems
    as events, allowing them to turn icons colors and be logged by the
    notification services.
    
    jill
    

Hi!
I'm working with T1.2.4, and I wanted to try playing with the data collector
based on the little that's written in chapter 8 of the Alarms and
Notification Services Use" manual and some of these notes.

But I guess I'm lacking some of the basics.  How do I "Enable the Data 
Collector" from the iconic map?  Where can I find the programming and
DCL interfaces to send data from the remote node?

The FCL command:
MCC> enable mcc 0 collecion_am sink decnet

gives me the message:

%MCC-W-VEINVALID, entity MCC is not valid with verb ENABLE

Pointers and/or status, please?

Tnx,
Sid

The programming and DCL interfaces for the data collector were
not complete in time for T1.2.4 field test.  They will be made available
on the net as soon as they are complete.

-- Erik

    I will assume (being the VMS bigot that I am) that you're running MCC
    on VMS.

    You *should* be able to start up the DC event sink with T1.2.4,
    however, you won't be able to do much with it.    The info in the docs
    about sending events to it is (as we sometimes say) "leading the
    implementation...".    ;^)

>
>The FCL command:
>MCC> enable mcc 0 collecion_am sink decnet
>

    Aside from the fact that you misspelled "collection_am", that syntax
    should have worked.   If you can verify that the entries for the
    collection_am are in your dispatch table (use mana/tool/test_driver),
    and it still doesn't work, you may need to do a DAP rebuild.  

    I had to resort to this a week or two ago... for some reason my parse
    tables got scrambled.     If you must, do the rebuild as a last resort
    and start it just before you leave at night.   Be sure all your
    pgflquota and related params are "up there" or yea verily your system
    shall becometh as a useless monolith, flailing away until the four
    horsemen of the MWAIT visiteth thee...

/doug

>    I will assume (being the VMS bigot that I am) that you're running MCC
>    on VMS.

Correct. (glad to know another bigot..)

>The info in the docs about sending events to it is "leading 
> the implementation...". 

Great expression.  I'll have to remember that.
I'll look forward to seeing the software available on the net.

>    Aside from the fact that you misspelled "collection_am"..

Isn't "cut and paste" wonderful?  That's exactly what I did and I just
copied the command to the note.  However, when I corrected the spelling, this
is what I got:

MCC> enable mcc 0 collection_am sink decnet
ops_evc_send_internal_event Failed at step 10, status = 52859675
mcc_evcam_enable_sink failed at step 6, status = 52859675
%XPO-W-NOMSG, Message number 0020DCE0

This problem is not what you might call "urgent", since as you said there's
not much I can do with the data collector without any data for it to
collect.  But I thought you might be interested.

Sid

 >MCC> enable mcc 0 collection_am sink decnet
 >ops_evc_send_internal_event Failed at step 10, status = 52859675
 >mcc_evcam_enable_sink failed at step 6, status = 52859675
 >%XPO-W-NOMSG, Message number 0020DCE0
 >

Try doing a "DISABLE" and re-enabling.   If that doesn't work, look for the
process "MCC_EVC_SINK" on your system, kill  it and try enabling again.

If that still doesn't work, check that you have the TASK object on your system
and that you are enabling from an account with plenty-o-privs.   I think it's
best to do the ENABLE from SYSTEM, that way the log file that the sink creates
remains in SYS$MANAGER (it lands in SYS$LOGIN: of the user that starts it.)

/doug

>Try doing a "DISABLE" and re-enabling.

This gives:

ops_evc_send_internal_event Failed at step 10, status = 52859675
NOEVENTREQ, EVC sink is not up.
MCC 0 COLLECTION_AM SINK DECnet
AT 23-JAN-1992 17:02:21
Disable completed successfully.

(but the enable command still doesn't work).

>look for the process "MCC_EVC_SINK" on your system, kill  it 
No process with that name exists on my system.

>check that you have the TASK object on your system

AHA! The TASK object is "DISABLED".  Probably beacuse of these newfangled
INSPECT requirements.  I'll have to talk to the sysmgr and in the meantime
I'll wait for some more docs on the data collector.

Thanks,
Sid

re: .13,

> AHA! The TASK object is "DISABLED".  Probably beacuse of these newfangled
> INSPECT requirements.  I'll have to talk to the sysmgr and in the meantime
> I'll wait for some more docs on the data collector.

	Maybe we've never run into this because nobody I know in the
    DECmcc development group runs INSPECT [yet].  Personally, I password
    protect my TASK object and use proxy accounts to access it safely.
    I ran into this problem with another product I developed which
    relies on the existence of a [protected] TASK object (DECpulse),
    and as a result, added the DECPULSE_TASKMAKER.COM as well as
    DECPULSE_PROXYMAKER.COM command procedures to the kit to create
    protected TASK objects for the user's system automagically.

    	I wonder if the recent Security Inquisition ever bothered to
    check with development groups before enforcing such edicts as
    the complete elimination of the TASK object from the network?
    After all, the TASK object can be used safely as long as it is
    properly password protected.
    
    				   -davo

    actually Doug we did run into it. On Kishka (my cluster) where we
    run a tight ship including meeting almost all inspect requirements, we
    didn't even have a task object. When we added the object we hit all
    kinds of problem with getting it setup, and inspect doesn't love it.
    
    They do security inquisitions on us, and they do complain. You probably
    haven't read through all the data you get after your inspect
    inquisition is run. If you want a sample of what the hand-slap
    looks like I can mail you one.
    
    jill
    

FWIW: I run INSPECT on my workstation  & I haven't had any failed tests about
TASK object protections (and I can get the EVC sink running...)

/dou

    I don't anymore either, just a matter of figuring it out. How to set it
    up without upsetting inspect. I know end results were I have proxies
    from all non prived accounts so as to pick up events, and I now have a
    task object (don't remember if it has a password or not...will have to
    check).
    

    	I started to enter what is now note #2269.0 as a reply to this
    note, but I figured I'd start a new note to prevent ratholing this
    discussion.  See note #2269.0 for information on two new command
    procedures which might come in handy for creating password protected
    TASK objects and associated proxy accounts for use by DECmcc Directors.

    				   -davo

Hi!
I also copied the files pointed to by note 3.134. but I didn't even
get as far as getting a clean .exe file.  I didn't make any changes in
the c files.  I compiled and linked as instructed:  That is:
	$ cc /define=VMS mcc_evc_send.c, mcc_evc_api.c, mcc_evc_api_dna.c
	$ link mcc_evc_send.obj, mcc_evc_api.obj, mcc_evc_api_dna.obj

The compilation passed okay, but then the linker gave me a lot of undefined
symbols warnings (the actual output is at the end of this note).

When I tried to run it I got access violations of course.  What's wrong?

Sid

$ link mcc_evc_send.obj, mcc_evc_api.obj, mcc_evc_api_dna.obj

%LINK-W-NUDFSYMS, 18 undefined symbols:
%LINK-I-UDFSYM, 	C$MAIN_ARGS 
%LINK-I-UDFSYM, 	CALLOC 
%LINK-I-UDFSYM, 	CTIME 
%LINK-I-UDFSYM, 	EXIT 
%LINK-I-UDFSYM, 	FREE 
%LINK-I-UDFSYM, 	GETENV 
%LINK-I-UDFSYM, 	MALLOC 
%LINK-I-UDFSYM, 	MEMCPY 
%LINK-I-UDFSYM, 	MEMSET 
%LINK-I-UDFSYM, 	PRINTF 
%LINK-I-UDFSYM, 	SLEEP 
%LINK-I-UDFSYM, 	SPRINTF 
%LINK-I-UDFSYM, 	STRCMP 
%LINK-I-UDFSYM, 	STRCPY 
%LINK-I-UDFSYM, 	STRLEN 
%LINK-I-UDFSYM, 	STRNCPY 
%LINK-I-UDFSYM, 	TIME 
%LINK-I-UDFSYM, 	TOUPPER 
%LINK-W-USEUNDEF, undefined symbol C$MAIN_ARGS referenced
	in psect $CODE offset %X00000008
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol PRINTF referenced
	in psect $CODE offset %X00000025
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol EXIT referenced
	in psect $CODE offset %X0000002E
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCMP referenced
	in psect $CODE offset %X0000003F
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol PRINTF referenced
	in psect $CODE offset %X0000004D
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol EXIT referenced
	in psect $CODE offset %X00000056
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol PRINTF referenced
	in psect $CODE offset %X00000067
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol PRINTF referenced
	in psect $CODE offset %X00000072
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol EXIT referenced
	in psect $CODE offset %X0000007B
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol TOUPPER referenced
	in psect $CODE offset %X000000B2
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCMP referenced
	in psect $CODE offset %X000000CB
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol PRINTF referenced
	in psect $CODE offset %X000000DA
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol EXIT referenced
	in psect $CODE offset %X000000E3
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCPY referenced
	in psect $CODE offset %X000000F4
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRLEN referenced
	in psect $CODE offset %X000000FF
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCMP referenced
	in psect $CODE offset %X00000111
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol PRINTF referenced
	in psect $CODE offset %X00000120
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol EXIT referenced
	in psect $CODE offset %X00000129
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCPY referenced
	in psect $CODE offset %X00000138
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRLEN referenced
	in psect $CODE offset %X00000143
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol MEMSET referenced
	in psect $CODE offset %X00000159
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCPY referenced
	in psect $CODE offset %X00000165
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRLEN referenced
	in psect $CODE offset %X00000173
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol MEMSET referenced
	in psect $CODE offset %X0000018D
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCMP referenced
	in psect $CODE offset %X0000019A
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol MEMSET referenced
	in psect $CODE offset %X000001DD
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCMP referenced
	in psect $CODE offset %X000001EA
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol GETENV referenced
	in psect $CODE offset %X000001F8
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol SPRINTF referenced
	in psect $CODE offset %X00000209
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRLEN referenced
	in psect $CODE offset %X00000214
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCPY referenced
	in psect $CODE offset %X00000228
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRLEN referenced
	in psect $CODE offset %X00000233
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCMP referenced
	in psect $CODE offset %X00000244
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol MEMSET referenced
	in psect $CODE offset %X000002CB
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol TIME referenced
	in psect $CODE offset %X000002D5
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCPY referenced
	in psect $CODE offset %X000002EE
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol CTIME referenced
	in psect $CODE offset %X000002FD
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCPY referenced
	in psect $CODE offset %X0000030A
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRLEN referenced
	in psect $CODE offset %X00000315
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol EXIT referenced
	in psect $CODE offset %X0000034E
	in module MCC_EVC_SEND file DECMCC$DISK:[DEMO.DC]MCC_EVC_SEND.OBJ;1
%LINK-W-USEUNDEF, undefined symbol MEMCPY referenced
	in psect $CODE offset %X0000001A
	in module MCC_EVC_API_GENERIC file DECMCC$DISK:[DEMO.DC]MCC_EVC_API.OBJ;1
%LINK-W-USEUNDEF, undefined symbol MEMSET referenced
	in psect $CODE offset %X000000B2
	in module MCC_EVC_API_GENERIC file DECMCC$DISK:[DEMO.DC]MCC_EVC_API.OBJ;1
%LINK-W-USEUNDEF, undefined symbol PRINTF referenced
	in psect $CODE offset %X0000017C
	in module MCC_EVC_API_GENERIC file DECMCC$DISK:[DEMO.DC]MCC_EVC_API.OBJ;1
%LINK-W-USEUNDEF, undefined symbol SLEEP referenced
	in psect $CODE offset %X000001CC
	in module MCC_EVC_API_GENERIC file DECMCC$DISK:[DEMO.DC]MCC_EVC_API.OBJ;1
%LINK-W-USEUNDEF, undefined symbol FREE referenced
	in psect $CODE offset %X0000020E
	in module MCC_EVC_API_GENERIC file DECMCC$DISK:[DEMO.DC]MCC_EVC_API.OBJ;1
%LINK-W-USEUNDEF, undefined symbol PRINTF referenced
	in psect $CODE offset %X0000023E
	in module MCC_EVC_API_GENERIC file DECMCC$DISK:[DEMO.DC]MCC_EVC_API.OBJ;1
%LINK-W-USEUNDEF, undefined symbol MALLOC referenced
	in psect $CODE offset %X0000037B
	in module MCC_EVC_API_GENERIC file DECMCC$DISK:[DEMO.DC]MCC_EVC_API.OBJ;1
%LINK-W-USEUNDEF, undefined symbol MEMCPY referenced
	in psect $CODE offset %X000003B1
	in module MCC_EVC_API_GENERIC file DECMCC$DISK:[DEMO.DC]MCC_EVC_API.OBJ;1
%LINK-W-USEUNDEF, undefined symbol MEMCPY referenced
	in psect $CODE offset %X00000428
	in module MCC_EVC_API_GENERIC file DECMCC$DISK:[DEMO.DC]MCC_EVC_API.OBJ;1
%LINK-W-USEUNDEF, undefined symbol MEMSET referenced
	in psect $CODE offset %X00000044
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRLEN referenced
	in psect $CODE offset %X0000004C
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol CALLOC referenced
	in psect $CODE offset %X00000054
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRNCPY referenced
	in psect $CODE offset %X000000E0
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCPY referenced
	in psect $CODE offset %X000000F3
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol FREE referenced
	in psect $CODE offset %X0000026C
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol FREE referenced
	in psect $CODE offset %X00000279
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRNCPY referenced
	in psect $CODE offset %X000002C4
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRCPY referenced
	in psect $CODE offset %X000002D6
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRLEN referenced
	in psect $CODE offset %X000002E0
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRLEN referenced
	in psect $CODE offset %X000002F0
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol FREE referenced
	in psect $CODE offset %X000003E7
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1
%LINK-W-USEUNDEF, undefined symbol FREE referenced
	in psect $CODE offset %X000003F4
	in module MCC_EVC_API_DNA file DECMCC$DISK:[DEMO.DC]MCC_EVC_API_DNA.OBJ;1

Yeah, I goofed.

    I assumed (silly me) that *everyone* always has LNK$LIBRARY defined.
    The problem you're seeing is unresolved reference to C RTL functions
    that the Linker notices.

    I have re-written the build.com procedure to *explicity* link against
    SYS$SHARE:VAXCRTL rather than depend on the user having defined
    LNK$LIBRARY.

    Sorry for the inconvenience.
    New build procedure is attached. 

    /doug
                                 <attachment>

$!******************************************************************************/
$!
$ if f$search("sys$system:vaxc.exe") .eqs. "" 
$ then 
$   write sys$output "You must have the VAX C compiler to compile this program!"
$   exit
$ endif
$
$ if p1 .eqs. "DEBUG" .or. p1 .eqs. "debug"
$ then 
$   cc_opts :== /debug/noopt/define=(VMS,"""debug""")
$   link_opts :== /debug/executable=mcc_evc_send.exe
$   gosub do_it
$   write sys$output " DEBUG Build complete."
$   exit
$
$ else
$   cc_opts :== /define=VMS
$   link_opts :==/executable=mcc_evc_send.exe
$   gosub do_it
$   write sys$output " NON-DEBUG Build complete."
$   exit
$
$ endif
$
$ do_it:  
$ cc 'cc_opts - 
	mcc_evc_send.c, -
       	mcc_evc_api.c, - 
       	mcc_evc_api_dna.c
$ link 'link_opts - 
	sys$input/opt
mcc_evc_send.obj
mcc_evc_api.obj
mcc_evc_api_dna.obj
sys$share:vaxcrtl/share
$
$ return
$!

Thanks, Doug and Jacques.  Based on the last few notes,
I got it to work also (sort of), and can use it to change the color 
of an icon based on CPU utilization for example.

Some additional notes and questions:

1. > Setting the sink 
   >	Must be done with FCL "Enable MCC 0 Collection_am sink DECnet"
   >and get the message "Enable successfull"

If you exit MCC and then enter again, you don't have to re-enable the sink.
I assume if the system is rebooted, you do have to re-enable it.  Right?
In any case, when I tried to enable the sink the second time I got the
following error message:
	MCC> ENABLE MCC 0 COLLECTION_AM SINK DECNET
	mcc_evcam_enable_sink failed at step 0, status = 52854873
	%XPO-W-NOMSG, Message number 0020DCE0
I assume this is because it was already enabled, but the error message
could be a *trifle* clearer.  :-)


2. Enabling the alarms
>	- Call Notification Program in the "Application" window
>	- Click "Notify requests" 	in new window
>	- Click "create"		in new window

As mentioned in a previous note, this has to be redone manually every time 
you enter MCC, but supposedly will be fixed by SSB (right?).  In the
meantime, is there a way of doing this automatically via a command file?

3. >The only point which does not yet work...

I see the text in the detail window of the notification window (that's how
I can show the CPU Utilization number for example).  But I haven't yet figured 
out where I should see the TITLE.  Where is it supposed to appear?

4. The main thing I haven't figured out yet is connecting the Data Collector
to a specific icon, that is "sinking" to a known entity.  How do I make
this association?  For example, I define a data collector called 
"MYNODECPULOAD".  I have an entity called .MYNODE in the same domain as
the data collector.  MCC is running on a node called TACT20.  From the node
MYNODE I run the sendevent routine as follows:

$ SENDEVENT :== $SYS$LOGIN:MCC_EVC_SEND.EXE
$ SENDEVENT TACT20 MYNODECPULOAD ".MYNODE" "My title" "cpu load=90%"  CRITICAL

This command colors the data collector very nicely, but doesn't do a thing
for the icon .MYNODE.  What else do I have to do?

Thanks,
Sid

Try:

SENDEVENT TACT20 MYNODECPULOAD "NODE4 MYNODE" "My title" "cpu load=90%" CRITICAL
				^^^^^^

>Try:
>SENDEVENT TACT20 MYNODECPULOAD "NODE4 MYNODE" "My title" "cpu load=90%" CRITICAL
				^^^^^^
Yes, that works.  Thanks a lot!!
Now, anyone want to tackle the other items I mentioned?

>If you exit MCC and then enter again, you don't have to re-enable the sink.
>I assume if the system is rebooted, you do have to re-enable it.  Right?
Right. 
Right.

>
>In any case, when I tried to enable the sink the second time I got the
>following error message:
>	MCC> ENABLE MCC 0 COLLECTION_AM SINK DECNET
>	mcc_evcam_enable_sink failed at step 0, status = 52854873
>	%XPO-W-NOMSG, Message number 0020DCE0
>I assume this is because it was already enabled, but the error message
>could be a *trifle* clearer.  :-)

Right again.   Hopefully that return status will be handled better in the next
FT release...


>As mentioned in a previous note, this has to be redone manually every time 
>you enter MCC, but supposedly will be fixed by SSB (right?).  

Right again. You're batting 1.000 so far!   The EFT Update release will have
loads of enhancements to Notification Services.    Among these will be the
capability to create/copy/save/restore notification requests.

>In the
>meantime, is there a way of doing this automatically via a command file?

Not from the Iconic Map.  You can do this for the FCL.  Just save them as
scripts and run them....

>I see the text in the detail window of the notification window (that's how
>I can show the CPU Utilization number for example).  But I haven't yet figured 
>out where I should see the TITLE.  Where is it supposed to appear?

It's a bug.  Fixed in the EFT update kit.  Right now you see "General Event" in
the Title window, right? Notification Svcs does some 'special case' code on
Data COllector events to substitute the event title (that you specified on the
send_event call) to for the actual event name (General Event, which is realy
the ONLY event the Data COllector supports.).

Also, must specify a full Class/Instance pair for the target entity (e.g "NODE4
.MYNODE") and be sure to enclose with quotes.!

regartds, 
doug

On the subject of enabling the notification services automatically on
startup by running a script from the FCL interface:

From FCL I type:
MCC>notify domain .tavis entity list = (COLLECTOR taviscpuload), -
	event=(any event)

(where "tavis" is the domain and taviscpuload is the data collector entity)
And I get the response:

%MCC-S-NOTIFSTART, Notify request 1 started

However, when I send the event to the data collector like I did before,
I don't get any notification in the Notification window, and the icon
doesn't turn color.  What I do get in my FCL window is an event message:

%%%%%%%%%%%%%% Event, 18-MAR-1992 14:56:43 %%%%%%%%%%%%%% [1]
Domain: LOCAL_NS:.tavis                               Severity: Critical
Notification Entity: Node4 LOCAL_NS:.taveis
Event Source: COLLECTOR LOCAL_NS:.taviscpuload
Event: General Event
 Collector General Event:
                             Event Text = "CPU LOAD! Percentage Utilization 99"
                            

(where .taveis is the sink node, and the message and severity are what I sent).

Is this what's supposed to happen?  How can I set up the notification service
and icon color change from FCL?  And once I succeed in doing that, how can I 
have the FCL script run automatically at startup?

Thanks,
Sid

You can't enable Notification for IMPM from another process (which is whate
you're doing.)

Until FT Update, you will have to MANUALLY create the notify request for the
Iconic Map *FROM* the Iconic Map, each time you start it. I.e there is no way
(pre-eftUpdate) to save a "default notifications startup profile.

Patience and fortitude....

;^)

/doug

    
    Thanks Doug! 
    
    The T1.2.6 kit some of you have has enhancements in the notification
    space. One of these is to allow the user to supply a notification
    command procedure with the default notify commands to start up 
    in the notification window when the IM PM is initiated. But remember
    that the IM PM session and the FCL PM are seperate and that the
    only impact a command in one has on the other, is when it modifies
    the actual values of an entities attributes.
    
    jill
    
    

    by the way the error message has also been fixed:
    
    MCC> enable mcc 0 collec sink decnet
    mcc_evcam_enable_sink failed at step 0, status = 148
    
    MCC 0 COLLECTION_AM SINK DECnet
    AT 23-MAR-1992 13:54:25
    
    The requested operation cannot be completed
                      Entity Existence Info = Entity Existence Cannot Be Determined,
                          VMS Routine Error = %SYSTEM-F-DUPLNAM, duplicate name
    MCC>
    

Sid,

     Here are answers to your questions:

     1. > Setting the sink 
	> Must be done with FCL "Enable MCC 0 Collection_am sink DECnet"
	>and get the message "Enable successfull"

	Yes, it is a bug that we can only enable the sink via FCL.  We
	are working on it now.  The sink can be enabled from IMPM
	in the next release.
	
     2.  Yes, when the sink is already up, the enable should fail and return a
         better message.  The problem is already addressed and fixed. 
     
     3.  Event title "MY TITLE" is supposed to show up in the window of the 
	 summary report, both in "text" field and in the report header.  
	 However, a bug was reported in the recent versions.  The problem is
	 already addressed and fixed.  The next EFT update should be ok.

     4.  try to pass target entity in this way: "node4 .mynode" when
         calling SENDEVENT.  This should change color for MYNODE.
	
	Hope this helps.

	Jean

                        

    
    Oops,
    
    	Obviously you already got the answers, ignore the #.32 then. :-)
        I was forwarded your note .24 today, so I replied without checking 
    	the notes between .24 and .31.  I hope you are satisfied with all the 
    	answers.
             
    	Jean
    	

>     3.  Event title "MY TITLE" is supposed to show up in the window of the 
>	 summary report, both in "text" field and in the report header.  
>	 However, a bug was reported in the recent versions.  The problem is
>	 already addressed and fixed.  The next EFT update should be ok.

I notice this works properly in 1.2.15 (which also fixed the bug that 
crashed MCC when cancelling a graph window).  Now I'll just have to maintain 
two versions for demos -- one with the above bugs corrected, and one which 
shows how TSAM works.  :-( 

Thanks to all who answered...

    does anybody have a pascal version of a data collector call please
    
    thanks
    Jeremy

The collector entity is just what I'm looking for BUT the way the doc are written 
and from the replys in to this note) it looks as if it is only available in the
VMS world. Is this true? If not is there a concise example of how to notify the
collector of an event using a script? Oh, second biggie; seems that it is only
mentioned in relationship to DECnet. Is this in fact the case or is there TCP/IP
support? I'm on a tight schedule so any response to these questions ASAP would be
appreciated!

>The collector entity is just what I'm looking for BUT the way the doc are
>written  and from the replys in to this note) it looks as if it is only
>available in the VMS world. Is this true? 

    This is NOT true.  The Data Collector AM (same as any DECmcc MM) works
    the same on Ultrix as on VMS.

    If, you mean the SAMPLE code that uses the Data Collector (remote) API,
    then that ALSO works on ULTRIX.   The sample program just has a couple
    of #ifdefs in it to handle building on Ultrix or VMS.   

>seems that it is only mentioned in relationship to DECnet. Is this in fact the
>case or is there TCP/IP support? I'm on a tight schedule so any response to
>these questions ASAP would be appreciated!

    The Data Collector API (and event sink) *currently* only support
    DECnet.  Obviously, we'd like to support more, but we are VERY
    resource-constrained and trying to put a kit out the door.   There are
    *very* definite plans to add support for mor transports... feel free to
    nominate your favorite(s) here...

>If not is there a concise example of
>how to notify the collector of an event using a script? Oh, second biggie;

    The sample code itself has *copious* comments within it that describe
    how to build it and use it...   The syntax for running the program
    (once built) is IDENTICAL for VMS or ULTRIX.   Translating the DCL
    procedures into allegorical Ultrix shell scripts is something that I
    had HOPED some enterprising souls (I know you're out there, I can hear
    you breating...) lurking our there would have done by now, but alas I
    hope in vain, and I am a C-shell neophyte, who's been hopelessly
    damaged by VMS, DCL and lexical functions...  Oh nooo. ;^)

    regards, 
    /doug

    I have a problem with the datacollector with a 1.2.7 system.
    I issue an enable mcc 0 collection_am sink decnet command, and as a
    result of that, the mcc_evc_sink process gets started.
    When I look in ncp for the object mcc_evc_sink however, there is no
    process id showing. When I try to use the mcc_evc_send command I get an
    error system-f-nosuchobj, network object is unknown at remote node.
    Are these problems connected to one another, and how can I make it
    work ? 

    Regards,

    Kurt.

You're on VMS, right?

It's been my experience that you have to do the enable from an account that
has sysnam and netmbx privs by default.  I'm not sure if that is documented 
or not.

If this is indeed the problem, and the requirement isn't documented,
and if you're not getting any indication to the effect that your sink isn't 
going to be working properly as a result of this insufficient priv problem, 
then we should QAR this.

    You are right Pete, I didn't have sysnam as a default privilege.
    
    I looked it up in the decmcc_alarms_notification_eft_update manual, and
    it is mentioned there.
    
    Thanks,
    
    Kurt.

    the updated version of the DC AM for SSB now explicitly checks the
    privs and instead will return a priv error instead of attempting
    to enable anyway.