Version and uptime are the key for strategic choices.
Keep a highest versions enabled and limit the numbers.
Uptime....that no two of the 5 you select ever be down at the same time.
Whether to implement system changes, or even for scheduled maintenance
Below in SOL1407 you will find the recommendation.
Fix/Resolution
Option 1
"Reducing the number of stations that can be Device Monitor will help reduce
the opportunity for thrashing by reducing the number of stations which can
become the Device Monitor (DM) and will also simplify troubleshooting by
reducing the number of stations which must be investigated. On a small system
1-2 stations should be designated as DM stations. On a large system 4-6
stations at the most should be designated as DM stations."
On some later versions of V8.x Device Monitor is started up through a
go_ADM.ksh located in d:/usr/fox/bin. In this case comment out the ADM line in
the fox_apps.dat file also located in d:/usr/fox/bin.
On 9.X systems other SOL/FAQ talk to disabling in the registry
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Brahm Neufeld
Sent: Friday, January 12, 2018 8:03 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Loss of Alarms & dm_recon - looking for understanding.
Hi Russell,
Thank you for the reply! We have had (very) intermittent issues with loss of
alarms and thrashing for a while - feels good to have found the issue.
If I understand correctly, any station running cs_devmon.exe can become a
DEVMON master. Looking at my 19 stations and servers, 15 of them have
cs_devmon.exe running. I found SOL1281 for XP and SOL2160 for Windows 7/Server
2008 to disable DEVMON as required.
Two hopefully brief follow-up questions, would appreciate a push in the right
direction.
Are there any recommendations for choosing the "strategic" AW's for DEVMON (I/A
level, uptime & availability, proximity to root switches, etc) - or just pick 5
good stations?
Is the 5-station guidance documented anywhere?
Regards,
Brahm Neufeld
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Russell Boulay
Sent: Thursday, January 11, 2018 6:50 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [EXT SENDER] Re: [foxboro] Loss of Alarms & dm_recon - looking for
understanding.
dm_recon can be run from any station...the current Master will run the command
Now maybe to your source of your issue.
How many DEVMON's are in your system?
If you have many AW's and every one of them is capable of being DEVMON,
probably not a good thing.
FoxMass TAC recommends you limit that number to a strategic 5 AW's.
DEVMON having to touch dozens of AW's is not good, as while they are thrashing
around for ownership and health, loss of alarms can occur and devices be left
in failed state.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Brahm Neufeld
Sent: Thursday, January 11, 2018 9:39 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Loss of Alarms & dm_recon - looking for understanding.
Hello list,
We've experienced a few issues with alarms not reaching workstations. I expect
this to be resolved by getting our workstations committed to the same level of
System Definition. In the meantime, we can restore alarms by running dm_recon
on the current Device Manager host (see: SOL965, 766, 1407, 1645 for finding
the current DM host and running dm_recon, and FAQ1908 for Device Monitor in CCS
9.3).
We have a couple versions of I/A / CCS in service: 8.8, 9.2, 9.3 (just one at
9.3, which tends to be DM master due to its numerical seniority).
Regardless of what station I run D:\usr\fox\cs\dm_recon.exe on, I always see in
SMON:
Device Monitor on {DM master} receives reconfigure message
Device Monitor Init done on {DM master} with version DMVER_9.3.0
Question #1: Is running a dm_recon on *any* station equivalent to running
dm_recon on the DM master? If I give my operators a button to "fix alarms" that
runs dm_recon on the local station, will the DM master always be refreshed and
CP APRINT tables updated?
If the answer is " to resolve loss of alarm destination issues, dm_recon *must*
be run on the DM master", I have a follow-up question (below).
I found a way to execute Windows programs on remote stations: this works on
"Standard" I/A; I am not sure about Secure. On a Windows station, you can run
the command:
wmic /node:LTRBUG process call create "cmd.exe /c
D:\usr\fox\cs\dm_recon.exe"
... to run dm_recon on a remote station "LTRBUG". Perfect when you don't have
quick physical access to the current DM master.
Question #2: To resolve alarming issues, can I use the firehose method and call
dm_recon on every one of my stations (the DM master being one of them) using a
batch file and the above bit of script? Or, can you help me understand why this
is a bad idea.
Or Question #3: Has anyone scripted the steps of SOL965 for determining the
current DM Master? If yes, that could be combined with the wmic command to run
the command on the DM master.
Regards,
Brahm Neufeld
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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
