Killing a ICC session while in a CP/IG/FDG can leave the session lock on ;
That can be overridden when going back into the ICC session and the CP/IG/FDG
and answering yes to OVERRIDE LOCK
Or
Deleting the file with the "+" character in /usr/fox/sp/locks
Scott Landry | Schneider Electric Systems, USA | Process Automation |
United States | PRINCIPAL SITE SERVICE ENGINEER
*** Please consider the environment before printing this e-mail
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx <foxboro-bounce@xxxxxxxxxxxxx> On Behalf Of
Shelby Jones
Sent: Wednesday, July 15, 2020 10:25 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] V9.3 System that still has the ICC
[External email: Use caution with links and attachments]
________________________________
Working remotely presents the possibility of database corruption in case your
connection gets hosed while a transaction is in progress. You can be left with
a mismatch that gets your cp, workfile and CSA out of sync.
Shelby
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx <foxboro-bounce@xxxxxxxxxxxxx> On Behalf Of
Joseph M. Riccardi
Sent: Wednesday, July 15, 2020 10:36 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] V9.3 System that still has the ICC
[External email: Use caution with links and attachments]
________________________________
Folks,
I have a V9.3 IA System that still has the ICC. Plan A had a couple of trips
to the site planned to implement some ICC changes but the Coronavirus has
changed that because I cannot travel at this point in time. The ICC changes
will include adding/editing/copying some PLBs. Looking ahead to Plan B, I have
requested a remote access account on the plant's Network with plans to connect
to the IA System via RDP to an Engineering AW Workstation on site. Any
warnings I need to consider?
Since the majority of my work has been on the older UNIX Systems (yes, they are
still out there), I need to refresh my memory on the limitations associated
with the Windows version. The main limitation is that ICC changes to the CPs
can only be implemented from the host AWs. But can I copy a block from a CP
hosted by AW1 into a CP hosted by AW2? Normally this would involve an Add
Block selection, Type (PLB) 'C:Blocknametobecopied'.
If they are in CPs with different hosts, will this add/copy a PLB still work?
Ditto for C:B:Parameter connections between CPs with different hosts. No
limitations?
Any warnings I need to consider?
Thanks
Joseph
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.thecassandraproject.org%2Fdisclaimer.html&data=02%7C01%7CScott.Landry%40se.com%7C9cab21417d9d4d37b4ae08d828e4fbcc%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637304311232395751&sdata=ZEewKfjjSLkgbeoHPsHp5AHzWdclbvm0PciKbxHWdhk%3D&reserved=0
foxboro mailing list:
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freelists.org%2Flist%2Ffoxboro&data=02%7C01%7CScott.Landry%40se.com%7C9cab21417d9d4d37b4ae08d828e4fbcc%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637304311232395751&sdata=SRTKdiXWqZYWiNLHYoffsfeuP7eBo0iaWtaDt4TMzhA%3D&reserved=0
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.thecassandraproject.org%2Fdisclaimer.html&data=02%7C01%7CScott.Landry%40se.com%7C9cab21417d9d4d37b4ae08d828e4fbcc%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637304311232395751&sdata=ZEewKfjjSLkgbeoHPsHp5AHzWdclbvm0PciKbxHWdhk%3D&reserved=0
foxboro mailing list:
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freelists.org%2Flist%2Ffoxboro&data=02%7C01%7CScott.Landry%40se.com%7C9cab21417d9d4d37b4ae08d828e4fbcc%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637304311232395751&sdata=SRTKdiXWqZYWiNLHYoffsfeuP7eBo0iaWtaDt4TMzhA%3D&reserved=0
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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
