Re: [foxboro] Followup to disapearing alarm manager
- From: "Grace, Kathy" <kathy.grace@xxxxxxxxxxxxxxxx>
- To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 14 Jun 2005 13:36:32 -0400
RE: kill -9 15993 ,(replacing 15993 with the PID # returned by your grep)
You should never kill the AM in this manner (or from Task Manager on NT or
XP, for that matter). This will leave those OM lists open that you are
concerned about. If the AM is indeed running try the following:
pref -<amname> amcmd "quitam on; exit"
This will gracefully shutdown the AM and close any open lists.
Kathy
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of tom.vandewater@xxxxxxxxxxxxxx
Sent: Tuesday, June 14, 2005 1:07 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Followup to disapearing alarm manager
Stan,
In the "XConfig" Display and Video configuration of Hummingbird
there is a check box that enables or disables a "Close Warning on Exit"
error message. By default, it is checked in Hummingbird. If you uncheck it
then you won't receive the warning about terminating the X session when you
pick the "X" on the window manager for the Alarm Manager.
We, too, have done a lot of testing and have tried to recreate the
scenario that causes the OM lists of two variables to be orphaned. We have
been unable to duplicate it during our testing on a freshly booted box. Our
clue that there is a problem manifests itself when operations start to get
smurfed displays or overlays on multiple display managers hosted by the same
Sun workstation.
In our configuration, we use one dual-headed WP51D and two
dual-headed PC's running Hummingbird, (Yes, 6 pieces of glass and six DM's),
for one operator seat. Our dmcfg associates a unique Alarm Manager with
each DM, so it is possible for six Alarm Managers and six Display Managers
to be active at the same time on one WP51D. We have beefed up the memory of
the WP51D's to support them. Whenever the displays start to smurf,
(typically in 2 to 6 weeks), we can check som on the WP51D and we see 50 to
80 orphaned lists of the same two variables that Duc mentioned. We reboot
the WP and then reopen the DM's on the two PC's and we are good to go for
another 2-6 weeks. Jeremy's solution could save us the pain of rebooting if
we can programmatically remove the orphaned lists on a regular basis.
(thanks for all of the help Jeremy, Duc is working feverishly on the
workaround).
Stan, I'm beginning to suspect that your problem is unrelated to the
one we are experiencing but the next time you have to reboot, please check
som before you do it, to see if there are a bunch of two variable lists
open.
Based on how your dmcfg is set up to associate one Alarm Manager
with all of your DM's, (which means you can only have a single Alarm Manager
window open per WP), I think you may have an Alarm Manager process running
but it has moved outside the viewable screen area on the PC running
Hummingbird. We have seen this happen before on PC's. You can still see an
Alarm Manager task on the PC taskbar but cannot restore or maximize it to be
displayed on the screens.
To find out if there is already an Alarm Manager active on the WP,
go to a VT100 or telnet session on the affected WP51D and type in the
following command: ps -eaf |grep CAD
If the screen returns something that looks like the following, then
there is already an Alarm Manager active and your dmcfg settings won't allow
another occurrence to be invoked.
root 15993 15908 2 12:37:07 ? 0:01 /usr/fox/wp/bin/am -type CAD -alias
21A014
If this is the case, you could kill the CAD process using the following
command:
kill -9 15993 ,(replacing 15993 with the PID # returned by your grep)
and then try starting another Alarm Manager.
Please let us all know your results the next time the problem occurs.
Thanks,
Tom VandeWater
Control Systems Developer/Analyst
Dow Corning Corporation
Carrollton, KY USA
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of stan
Sent: Tuesday, June 14, 2005 10:48 AM
To: Foxboro List
Cc: Hehn; Chris S.
Subject: [foxboro] Followup to disapearing alarm manager
I posted yesterday about alarm mangers on PC's becoming unavailable after
some run time.
I received some helpful suggestions that mentioned the problem might be
related to running out of OM lists on the host WP, because of windows being
closed on the PC. I did some testing this morning that _seems_ to exonerate
this as a possibility.
Here's what I did.
1. Reboot host WP, and reboot PC to establish X session on the PC.
2. There appear to be 3 ways to "close" the alarm manager, and or it's
associated window. These are:
a: File -L Dismiss from the CAD
b: "Close" button on the CAD
c: The "X" in the window manager decoration.
The first 20 of these results in a pop up which weans that doing this
will
close the alarm manager. The 3rd pops up a warning about terminating the
X session.
Our PC's are dual headed, and the way we have the DMCFG file set up, you
can have a alarm manager window open on one of the 2 heads, but not
both. If you close the alarm display on, say the upper head, then you
can open it on the lower one.
In any case, I repeatedly closed, and reopened the alarm manger many
times, suing all 3 mechanisms, and was unable to reproduce the "can't
pen alarm display" problem. It _does_ exist however, as I've seen it
myself after some (indeterminate, but fairly long) period.
I then looked at SOM on the host WP , and there were only 12 lists
open on this machine, and none were of size 2.
One other clue about this, is that when it's broken looking in DM Usage hows
the 2 PC sessions as "No License".
So, once again, I appeal to the wisdom of the list. Any ideas as to where
else I should be looking? And thanks for all the help on this!
--
U.S. Encouraged by Vietnam Vote - Officials Cite 83% Turnout Despite
Vietcong Terror
- New York Times 9/3/1967
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at your
own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at your
own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
