On Fri May 5 18:01:23 2000 Warren Brown wrote...
>
>At the time of the I/A release, the system is made as
>current as can reasonably be with respect to the
>several hundred patches that Sun provides.
These systems were upgraded to 6,1, whch was brand new late last year
for Y2K. A
On Fri May 5 18:20:01 2000 Airhart, Chad M. wrote...
>
>We have been having a problem uploading for the past year. We have not
>successfully done an upload by hand through the ICC in that time. We have
>a CAR out but as of yet have no help from Foxboro. The upload's fail at
>random points in
Chad,
An omread error indicates that the ICC was unable to connect to the source
of the data, i.e., the block of interest.
This could happen for a lot of reasons (this list is not complete):
1) The CP is too busy to respond to the request for data
2) The CP lacks the resources to resp
We have been having a problem uploading for the past year. We have not
successfully done an upload by hand through the ICC in that time. We have
a CAR out but as of yet have no help from Foxboro. The upload's fail at
random points in the process. The errors in the log file are an omread()
tim
At the time of the I/A release, the system is made as
current as can reasonably be with respect to the
several hundred patches that Sun provides.
The Y2k CDrom has on it a set of Sun patches that
make the release more current.
Is there a specific Sun patch that you would like
to see added to the
We have had a lot of success with Aspen's InfoPlus/21 Data Historian. It is
a true realtime relational database and SQL works superbly with it. It also
works great with other ODBC compliant programs such as Excel and Access as
well as DB to DB connectivity.
Chad Airhart
Instrumentation & Contro
On Fri May 5 14:46:49 2000 Murray, Steve wrote...
>
>Hi Stan,
>
>What is the known Solaris bug & what is the Sun fix?
1. Print que problems.
2. killing inetd can crash the kernel!
I can provide you with references on the 2nd one if you are interestd.
>
>Any idea what t
If you would prefer not to lose your alarm history when the historian
restarts or the AP reboots check out QF990113B.
Description at:
http://www.csc.foxboro.com/shared/qf/QF990113B.htm
Download at (may require login):
http://www.csc.foxboro.com/content/qfbin/QF990113B.zip
That should take care
Hi Stan,
What is the known Solaris bug & what is the Sun fix?
Any idea what the patch might break if one applied it before Foxboro
evaluated it?
I know Solaris is the operating system Foxboro used as a base for our I/A,
but I don't believe our software is the same as the Solaris you could b
On Fri May 5 12:59:09 2000 Kevin Fitzgerrell wrote...
>
>Stan,
>
>The script does return only the alarms in the current alarm history buffer
>- /usr/hstorian/almhist. Your previous alarm history buffer (from before
>the AP reboot) should still be available as /usr/hstorian/almhist.bak. If
>you w
Stan,
You're right, it has virtually no comments. It is exactly as I got it from
HH714 with just enough changes to make it run on my system (I removed some
hard returns that may just have been caused by my transfering it to my
system). I should note that alm_txt.sh is just the name I used on my
Yes the buffer is cleared on reboot or if you shutdown/restart the historian
Actually the file in question (buffer file)is copied to almhist.bak on
reboot
or shutdown of historian - so you could still retrieve the alarms by
modifying
the script
My 2 Cents for what its worth
Mark
-Original
I grabed this script, and took a look at it. Firsy of all for such a
complex script is has remarkably few comments :-)
Isthis script suppposed to return all alarms that are in the alarm
history buffer? This would be a maximum of 5000 alarms correct?
Ir i
13 matches
Mail list logo
