Re: [foxboro] P2P links locked
- From: dirk.pauwels@xxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Mon, 13 Sep 2010 11:51:19 +0200
Hi Tom,
Thanks for this valuable hint,
I'm always very carefull when I delete blocks, (I look up all references
to other blocks both internal and external) but sometimes when testing
stuff I might have deleted P2P source blocks and created or changed others
without checkpointing in between. I'll certainly keep this in mind.
Our rsom lists didn't show any links as deleted, we only noticed that a
couple of links which should have been there, weren't.
Thanks & Rgds,
Dirk
wrote:
Dirk,
This is in response to your recent note about corruption
of Foxboro
CP OM lists. This is a rare but long-lived problem that apparently still
exists. We experienced this problem on multiple occasions and it was
communicated to Foxboro each time. They were all discovered shortly after
ICC configuration activity. The problem occurred when blocks had been
copied and deleted in the ICC. I submitted documentation on the first
occurrence of this problem to Sue Papineau of the TAC group at the Foxboro
Customer Satisfaction Center on June 24th 1998. At the time we were at
Ver. 4.1.1.
I am convinced that the problem is brought on by DELETING
a block
that is involved in a CP-CP (peer to peer) communication and then adding
or
changing other blocks before exiting the ICC or doing a checkpoint of that
CP. It is common knowledge that peer to peer OM connections are not
updated
in blocks that are modified with external connections until a checkpoint
occurs. If you delete a block that frees up an OM list variable and then
add another connection before a checkpoint has occurred I believe that it
is
not being correctly managed and can cause cross linking or corruption of
OM
lists between CP's.
This is a very insidious bug because it can actually
cause
corruption of OM variables that were in no way associated with the
modification made during the current session of ICC configuration. That
is
what happened to us in the scenario described below. Just because you fix
the problem that you see doesn't mean you haven't created another one that
will rear its ugly head in the future.
As a possible precautionary measure, I would suggest
doing a
checkpoint immediately following any deletion of a block or parameter that
is involved in CP to CP communication. Do this before making any other
changes in the ICC. Exiting the ICC will also cause a checkpoint to occur
if any changes to the control database have occurred during that session.
_______________________________________________________________________
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:
