We have been dealing with this problem for 2 years and are currently running
Foxview 6.1B and 99.2 versions. The basic problem is that the next update
of the Foxview screen will not occur until the time is past the last update.
So, when the time is set back 1 hour the display will stop updating for 1
hour.
We have had success (with both versions) by just setting the time back and
then restarting all the running Foxviews. Since the Foxview display may
freeze after the time change you may have to "kill" the Foxview processes
from the command line. The "boot" instance should restart itself
automatically.
We were also cautioned about the possibility of the alarm manager not
updating and the need to kill the alarm server task (ast) after the time
change, but our testing has not shown a problem with this.
Regards,
Terry
-----Original Message-----
From: Lowell, Tim: [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 20, 2000 10:49 AM
To: 'Foxboro DCS Mail List'
Subject: RE: Daylight Savings time (again)
Brain damage, I like that one...
No, Foxboro I/A does not use the TZ variable. If you are especially unlucky
to be using FoxView, you cannot even set the time backwards for the end of
Daylight Saving Time, or you will freeze any AW51 or WP51 running FoxView.
Even the developers of FoxDraw/FoxView blame the developers of I/A for not
using the TZ variable right in the Release Notes, so what are you gonna do?
Well, what we are going to do is run all winter an hour ahead, just like we
did last winter. We have no alternative. I hear from the TAC web site that
FoxView 99.2.1 only requires a restart of FoxView if you set the time
backwards, as opposed to a full AW/WP51 reboot. Anybody know if that is
true? That we could do, with some advanced planning and script files.
Rebooting all 17 of our AW/WP51's is not an option.
Tim
-----Original Message-----
From: Stan Brown [SMTP:[EMAIL PROTECTED]]
Sent: Friday, October 20, 2000 10:38 AM
To: [EMAIL PROTECTED]
Subject: Daylight Savings time (again)
I think we had this discussion about this time last year,
but I have
forgotten the conclusions (if any).
Is there any reason that the Foxboro machines (AP, WP, AW)
can't have
there hardware clock set to UTC, and use the TZ ebvironment
variable to
present date/time information to the operators in local
time? We have
several other UNIX based systems which are set up this way,
and it
avoids all the flailing around that happens twice a year.
All data on these other machines is loges in UTC, and any
viewing of it
is morphed to the local time via the OS via the TZ
environment
variable. This is so clean, i can't believe that it's not
the way to do
it on Foxboro systeams. Or am I missing some Foxboro brain
damage?
-----------------------------------------------------------------------
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings from this list are the work of list subscribers and no warranty
is made or implied as to the accuracy of any information disseminated
through this medium. By subscribing to this list you agree to hold the
list sponsor(s) blameless for any and all mishaps which might occur due to
your application of information received from this mailing list.
To be removed from this list, send mail to
[EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]
-----------------------------------------------------------------------
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings from this list are the work of list subscribers and no warranty
is made or implied as to the accuracy of any information disseminated
through this medium. By subscribing to this list you agree to hold the
list sponsor(s) blameless for any and all mishaps which might occur due to
your application of information received from this mailing list.
To be removed from this list, send mail to
[EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]
