| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1224.1 | | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Fri Mar 01 1996 16:44 | 16 |
| jw,
This can be caused by several "cock-pit" errors. One of which is that
the action routine definition within the database is not setup
properly. Since brd_example is setup to use the API the action rotuine
type must be set to one of the choices for image based action rotuines.
To get to the menu in question use the following menu path from the
X-windows editor:
Edit->Action->Show/Modify->pick-the-action-routine-in-question
You will find a box named Action Type with 3 radio buttons. Depending
on the application you will use the 2nd of 3rd button from the top. If
it's brd_example then you would probably use the 3rd button.
Regards,
Dan
|
| 1224.2 | any other ideas? | CSC32::KLIMAS | | Mon Mar 04 1996 13:10 | 30 |
| Hi Dan,
The customer supposedly selected button 3 so that should be ok. I have
not actually verified this though. The customer can successfully get a
script file to run so he knows how to set it up and from what I can see
the only thing that would be different is the radio button selected
when I have a command file to execute and when I have an image.
I do not know for sure if he is passing any parameters or not but I
will check.
He says he is doing a reconfig after defing the action routine in pcm.
I also saw a reference to an "action tieout period" but could not
determine what the "period" is. Could that be part of the problem?
This really sounds like we are having a problem trying to talk to ens
via ipc but I am not sure why. Could there be some part of the kit
that did not get installed that could be causing a problem or part of
unix for that matter?
Do you think it would help to run the ivp?
Any other "cockpit" movements that you know of that might cause us to
not be able to talk to ens?
Thanks in advance and for anything you can provide.
Douglas Klimas
|
| 1224.3 | | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Mon Mar 04 1996 13:21 | 48 |
| > Hi Dan,
How did I know that this was MCI.......;-}
> The customer supposedly selected button 3 so that should be ok. I have
> not actually verified this though. The customer can successfully get a
> script file to run so he knows how to set it up and from what I can see
> the only thing that would be different is the radio button selected
> when I have a command file to execute and when I have an image.
> I do not know for sure if he is passing any parameters or not but I
> will check.
> He says he is doing a reconfig after defing the action routine in pcm.
> I also saw a reference to an "action tieout period" but could not
> determine what the "period" is. Could that be part of the problem?
Okay, thats the first part and it appears that they have a filter
setup. They aren't trying to run this interactively are they?
If they are then that is the problem as the connection method
being used within the brd_example is not the technique needed for
running the example interactively.
> This really sounds like we are having a problem trying to talk to ens
> via ipc but I am not sure why. Could there be some part of the kit
> that did not get installed that could be causing a problem or part of
> unix for that matter?
Nope, as if things were missing the "make" command would have barfed
when they built the example. Note also that the other out-of-the-box
action routines use the same IPC (if that wasn't obvious). The next
step ( if they really aren't trying to run the example interactively) is
to define the environment variable
CONSOLE_DEBUG "ENS,ACTION"
export it and restart PCM. Retry the example and then check the
temporary dir for a new logfile and post it as well as the Console
Notify daemons logfile. You don't want to leave this variable defined
for any length of time as it can get *quite large* if a lot of events
are occurring.
Regs,
Dan
P.S. Beers_MCI_Team_Owes_Dan++;
|
| 1224.4 | operation not supported on socket error | CSC32::KLIMAS | | Mon Mar 04 1996 17:41 | 13 |
| NO parameters are being passed to the routine.
I am not sure where the Console Notify daemon writes his log file but
all the files created today after setting the console_debug variable
show an error or
operation not supported on socket
Not sure what it is telling me yet but I will look in stars.
Thanks in advance,
Doug
|
| 1224.5 | do we need to pass a parameter? | CSC32::KLIMAS | | Tue Mar 05 1996 13:50 | 19 |
| Ok looks like finally go this to work but I and the customer have a
couple of questions.
We got it to work by passing 1 userdata item even though we did not
need to pass anything.
1. Is there a requirement that when my action routine is an a image to
be run that there must be at least 1 userdata item passed? We did not
need to do this with a script file and we could get it to run fine.
2. If there is a process running with a particular image and we want to
change something in the image for that process, what is the correct way
to get a new image to be run? Do we just kill the process and replace
the image and let it get started again?
Thanks in advance
Doug
|
| 1224.6 | | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Tue Mar 05 1996 14:02 | 32 |
| > Ok looks like finally go this to work but I and the customer have a
> couple of questions.
> We got it to work by passing 1 userdata item even though we did not
> need to pass anything.
> 1. Is there a requirement that when my action routine is an a image to
> be run that there must be at least 1 userdata item passed? We did not
> need to do this with a script file and we could get it to run fine.
Yes. This is because of the clause in the action routine defintion of
"EACH userdata item" or "ALL userdata items". ENS keeps track of
the running actions and the userdata passed to them. This is how it
knows that a particular instance of an action is still running.
> 2. If there is a process running with a particular image and we want to
> change something in the image for that process, what is the correct way
> to get a new image to be run? Do we just kill the process and replace
> the image and let it get started again?
Your ketchin' on Billy Bob!! ;-} It's best if you replace the image and
then kill it because an event could occur between the time you kill the
process and copy the image to the user actions directory and obviously
you'd get another instance of the old action.
Regs,
Dan
Thanks in advance
Doug
|