>>> 3.  I have long been an anti-proponent for automated save-alls and even
checkpoints.  Your quandry is one of the best examples I can give to avoid
automating something so important as your control database backups.
<<<

Sorry, but I fail to see what is so great about this example:
The system responded with: Database locked, Override yes/no.

As I believe, answering NO would have prevented this issue from occuring at
all!

I have seen "smart engineers" screw up a control databases in broad
daylight, because they figured the "locked database" message, was a mistake
from the Foxboro system, which is usually not the case, and ALWAYS should be
a warning to the engineer that he/she must investigate.

I would suggest an initialize/load_all. And use the "cassandra provided"
save_all script (that will maintain at least 10 backups) or something
similar from your precious save_alls.

I would also suggest informing your staff about the archiving utilities on
the system and the impact they may have on real life engineering!

Making important tasks in the system (like backing up control databases)
"low thresshold functions", because they automated, should be considered a
to big value just to cancel all of this because someone has made a mistake.


Regards

Ron Deen
Foxboro Nederland N.V.
Baarnschedijk 10
3741 LS Baarn
The Netherlands
Phone:  +31(0)35-5484174
Fax:    +31(0)35-5484175
Web:    www.foxboro.com
e-mail: [EMAIL PROTECTED]




-----Original Message-----
From: Stear, Bo [mailto:[EMAIL PROTECTED]]
Sent: donderdag 5 april 2001 21:37
To: 'Foxboro DCS Mail List'
Subject: RE: Failed SaveAll


Having gone from bad to worse myself, I offer consolation...

Some answers that may help:

1.  See if you have a 'check_sync' directory in /opt/fox/bin/tools.  If so,
this directory contains some CP database utilities.  I suggest running
'check_db_sync <LBUG>' on the offending CP.  This will tell you whether you
have any possibility of recovering your database.  The odds are actually
pretty slim, but if you're lucky, there are friendly folks at Foxboro that
may be able to recover your database.

2.  Given no option to recover, a clean Initialize, reboot, load-all will
must certainly get things back on track if you can afford to do so.

3.  I have long been an anti-proponent for automated save-alls and even
checkpoints.  Your quandry is one of the best examples I can give to avoid
automating something so important as your control database backups.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 05, 2001 12:29 PM
To: [EMAIL PROTECTED]
Subject: Failed SaveAll


warning: long message
---------------------

Hi folks,

I have a CP (CP-40) that has its control database corrupted when a person
answered Yes when presented with the "Database locked. Override?" dialogue
box.

A little background: I schedule a weekly cron job to perform SaveAll on all
of our CPs using the ICCAPI save_all command. As luck would have it, this
person was called in on a Sunday to fix a sequence problem, and he tried to
open a CIOCFG session on this CP while the ICCAPI save_all was running. When
presented with the "Database locked. Override?" question, he didn't hesitate
long, reasoning that it was Sunday and nobody would be working on that CP,
must be a mistake. Once in the control session, he still couldn't connect to
the CP so he rebooted it.

Since then, I have not been able to perform a good SaveAll for this CP.
Using the CIOCFG interface the SaveAll appears to run successfully, but I
can't perform a LoadAll with the resulting disk (to an off-line CP), I keep
getting "Invalid block type" error for each of the compounds in this CP.
Using the ICCAPI save_all command always resulted in a failure message with
the following text in the /tmp/output* files (at different times after
trying different things to mitigate the problem):

04AW01# more /tmp/output*
FAIL     3 save 20CP02!: Wed Mar 28 16:27:01 2001 -8 Save cmd: no path name
arg

04AW01# more /tmp/output*
FAIL     2 getorder 20CP02!: Thu Mar 29 15:52:50 2001 -15 Get compound order
cmd
: ICCget error: class= 20 error= 4 text= load_wrk: fread error

04AW01# more /tmp/output*
FAIL     4 save 20CP02!20CP02_STA: Fri Mar 30 09:08:34 2001 -8 Save cmd: no
path
 name arg

BTW, I can do an upload for this CP and the workfile appears to be in good
condition (at least good enough so that I can see all the compounds, blocks,
and parameters while in a CIOCFG session). And the CP is still running okay
as we speak.

Questions:

1. What are my options in getting a good SaveAll for this CP?

2. If I have no option, would initializing/rebooting/reloading it with a
good SaveAll (from 2 weeks back) get me out of this jam?

3. Has anybody encountered problem similar to this, and what's your remedy?

Thanks for any thought and help.

Duc

-- 
Duc M. Do
Process Control Systems
Dow Corning, Carrollton Plant
Carrollton, KY, US

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Control Centre. For further information visit
http://www.messagelabs.com/stats.asp


-----------------------------------------------------------------------
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]

-----------------------------------------------------------------------
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]

Reply via email to