Re: [foxboro] Remove autostart of legacy servers?
- From: "Hicks, David" <david.hicks@xxxxxxxxxxxxxxxx>
- To: 'Kevin FitzGerrell ' <fitzgerrell@xxxxxxxxxxxxxxx>, "'foxboro-bounce@xxxxxxxxxxxxx '" <foxboro-bounce@xxxxxxxxxxxxx>, "'foxboro@xxxxxxxxxxxxx '" <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 20 Mar 2006 19:17:17 -0500
Kevin,
On the remote collector machine (w2k server) in the configuration menu is
the rtp, messages, reduction, and the other component configurations. I do
not have access to an AIM historian machine at the moment, but in the
component configurations there is a tab for defining the local collector
attributes and the remote collector attributes. This is where you would
define which station is the AW collector for the instance. It can be
defined by IP or name assuming it is in the host file.
There should be no historian instance configuration on the AW's if the only
AIM instance exists on the remote collector.
I am not sure how the system is able to start up 2 historian instances under
the same name with the ipchisti. On occasions that I have seen this, there
is an error in the log which says basically just that - that there is
already a historian instance of that name already running.
If you look at the configuration and are unable to get anywhere, you may
send me an import file from the remote collector machine.
Have you gone back and looked to see if the /etc/histlns and /etc/histlocs
files remain as you originally built them? Curious...
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
To: foxboro@xxxxxxxxxxxxx
Cc: Dave Hicks
Sent: 3/20/06 4:52 PM
Subject: Re: [foxboro] Remove autostart of legacy servers?
Hi Dave,
Thanks for the response!
> "While this configuration follows the guidelines in the AIM* manuals,
> system
> definition doesn't support this type of configuration."
>
> The above statement is correct, however you can create a 70 series
> station in the system configuration, define the station with IP and
> historian, but do not attach it to the node. This allows complete
> configuration of the historian instance to be used and seen by the
> utilities in system definition to configure the historian access.
System
> Definition will complain because the station is not monitored and on
the
> node, but all other features work as normal. The remote collector
server
> could be configured in this method.
>
I did look at doing this but still had problems with the workstations
and AWs
not pointing to the legacy server. What I've done in sysdef is put
AHIST6
(FoxHistory for Solaris) on P101AW value puhs01. All system monitors
have
puhs01 as their Historian Database Name. After committing the
workstations I've
gone through and adjusted /etc/histln, /etc/histnls and /etc/histlocs to
contain
"puhs01", "puhs01", "puhs01 P101AW" on all the stations so the
workstations can
find the legacy server.
> "I may be completely off-base about the windu registry. One of the
> Foxboro
> engineers who worked on my CAR originally mentioned that that was
where
> the
> legacy server startup arguments were saved."
>
> The above statement is also correct, but the windu only points to the
> files ipname_for_r_servers and the TZ_for_r_servers which are created
> when a start_server RFH <IP or IPNAME> is run manually and the TZ
> argument is used. IF TZ is not used as an argument, then disregard the
> TZ_for_r_servers. AIM historian should only attempt to start the
servers
> if something is starting the AIM historian. /usr/fox/bin/fox_apps.dat
> would have an entry AIMHISTORIAN which is the go_AIMHISTORIAN script
in
> UNIX and in Windows would be AIMSTAR. For remote collections (histsend
> and histreceive) only require AIMAPI. AIMHISTORIAN does not need to be
> running on any workstation other than the workstation that hosts the
> historian server. Only one ipchisti can be running against any
historian
> instance. The device monitor controls this as this process has access
to
> the OM.
>
That's interesting. When I install the remote collector on the 4 AWs,
the
install script puts both AIMAPI and AIMHISTORIAN scripts in. Both are
run.
When histstart is run by the AIMHISTORIAN script it starts fetchdog, and
on
P101AW and P401AW it also starts ipchisti and the legacy servers.
ipname_for_r_servers exists on P101AW, but not on P401AW.
> Questons:
> When the P4AW01 is rebooted and is running the servers is the process
> ipchisti also running?
Yes. I kill ipchisti and fetchdog after this workstation reboots.
> How is it that you have 7 segments connected without LAN interfaces?
I've got NCNIs in each segment connected to switches with a V7.1 blade
workstation. This is a supported configuration. Previously this system
had 4
nodes, CLANs and NBE/FONBEs.
> Have you "dumped" the device monitor to determine where it thinks the
> historian server should be running?
> /opt/fox/bin/tools/glof -p DEV_MONITOR - list hex strings with MAC
> address of device monitor hosting station
> /opt/fox/bin/tools/fist <wokstation letterbug> - list MAC address for
> the defined workstation
> When you have determined the workstation running the device monitor:
> /usr/fox/cs/dmrecon d - creates the current device monitor
> configuration in a .cfg file
I've dumped the device monitor but see no references at all to the
historian.
I'm looking in cs_dm.current. I also checked cs_devmon.cfg with bpatch
and
don't see any historian reference there.
> Are there any workstations or peripherals failed?
> Have you searched the other workstations to see if others are running
> ipchisti?
No other stations are running ipchisti, although as noted all the 4
remote
collectors are running fetchdog (at least until I kill it on P401AW).
Where does fetchdog get it's list of processes to restart?
>
> The device monitor would only allow one ipchisti process instance to
run
> against a single historian instance name. Perhaps there is a naming
> convention incorrect somewhere in regards to this particular
workstation
> in relation the historian instance.
>
> In the historian configuration as defined for the remote collector,
> which workstation is defined to make the remote connection? There
should
> be a configuration for both the local and remote machines.
Could be. Where should I be looking at this configuration?
Regards,
Kevin FitzGerrell
Carter Holt Harvey, Ltd.
+64 27 460 9994
> ----- Original Message -----
> From: Kevin FitzGerrell<mailto:fitzgerrell@xxxxxxxxxxxxxxx>
> To: Dave Hicks<mailto:hicks_dave@xxxxxxx>
> Sent: Sunday, March 19, 2006 9:58 PM
> Subject: Re: [foxboro] Remove autostart of legacy servers?
>
>
> Dave,
>
> We've got a large network with 4 AWs in different plant areas.
>
> We have an AIM* historian off-platform on a server class machine
> running W2K
> Server Edition. We run one historian instance, puhs01, with a 30,000
> tag
> license (May be 20,000 tags -- we have two other networks and a total
> of 52,000
> tags licensed).
>
> Each of the 4 AWs has a remote collector for puhs01. This way if one
> plant area
> is down for shut/maintenance, and the AW is offline (backups, etc...)
> the
> historian is not affected for other plant areas.
>
> Because there can be only one legacy server for a historian, we had
to
> pick an
> AW to put it on. The one we picked initially turned out to be a bad
> choice
> (P401AW), so we re-assigned the legacy server function to a different
> AW
> (P101AW). We work extra hard to keep P101AW up, it being the CSA
host.
> The
> challange has been to get the legacy servers to not start on P401AW
> when it's
> rebooted.
>
> While this configuration follows the guidelines in the AIM* manuals,
> system
> definition doesn't support this type of configuration. We've set up
> the
> following files on all AWs:
> histln:
> puhs01
>
> histlns:
> puhs01
>
> histlocs:
> puhs01 P101AW
>
> The WPs have an empty histln file and the histlns and hostlocs are
the
> same as
> the AWs.
>
> I may be completely off-base about the windu registry. One of the
> Foxboro
> engineers who worked on my CAR originally mentioned that that was
where
> the
> legacy server startup arguments were saved.
>
> The manual (B0193YM_E) notes (Page 157) "The legacy servers preserve
> the
> arguments supplied to the start_server script for the next automatic
> startup.
> The histstart program restarts the servers using the same parameters
> that were
> used when the servers were started manually."
>
> What I had hoped was to find where the auto-start functionality and
> parameters
> were saved, and remove them.
>
> So, ASCII art:
>
> Win2K server
> puhs01 instance
> |
> --------------------------
> | | | |
> P101AW P201AW P301AW P401AW
> AW51E AW51E AW51E AW51E
>
> This system has 7 segments, each with NCNI pair, connecting to V7.1
> fibre
> switches. Four of the segments have an AW, the other three are
control
> stations
> only. The system has one Blade workstation at 7.1 running as NFD
> master. Each
> AW51E hosts 3-8 control stations, and is associated with 3-4 WPs.
Total
> of 44
> stations (control, comms and workstations) on the network.
>
> I'm open to suggestions on the configuration if there are problems
with
> what
> we've set up. We're going merge this network with our other two
> networks over
> the next year under an I/A V8.1 layer (currently we pass data between
> networks
> over INI15 links), and will probably be looking at merging the
> historians too.
>
> Regards,
>
> Kevin FitzGerrell
> Carter Holt Harvey, Ltd.
> +64 27 460 9994
>
>
> Quoting Dave Hicks <hicks_dave@xxxxxxx<mailto:hicks_dave@xxxxxxx>>:
>
> > Kevin,
> >
> > A little confused about what you are attempting to do.
> >
> > If the remote collector is not the server, which workstation is
> serving
> > alarms, alarm history, messages, etc?
> >
> > Please provide a topology of workstations involved and which
> > workstations are active historians and which workstations are the
> > historian servers.
> >
> > When any of the historians are started up the I/A looks at the
> > /etc/histlocs, /etc/histlns, and /etc/histln to determine where the
> > servers should start. If a remote collector it would check for the
> files
> > listed below. The system definition or system configuration would
> have
> > to be modified to point to these particular workstations for
> historian
> > access. I am not sure as to the role /opt/windu would play in this
> > structure other than to provide the client connection services to
> which
> > ever workstation has made a graphical request. There are several
> pieces
> > involved in the historian access including the device monitor,
which
> > potentially could be locking a certain workstation to a certain
> > historian and allow access to the ipchisti for that particular
> > historian. This sounds very much like a system configuration issue,
> so
> > if you would provide more detail, we can narrow it down.
>
>
_______________________________________________________________________
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:
