[foxboro] The save_all script Was: Re: Out of sync databases

Hi list,

If you use the standard tools, the remarks Alex Johnson made that the standard 
procedure does NOT make copies of your include files are completely true. 
(what else would you expect from Alex?)

However:
The "save_all.sh" script as found on Cassandra WILL take care of these 
#include files.
This is not important for this topic right now.
I do think it was worth reminding the list though.
With the "save_all.sh" script, #include files are saved on a per CP basis in 
the directory "include" under the same directory structure you chose for the 
save_alls. The default is "/opt/SAVALLS", which would mean they would end up 
in /opt/SAVEALLS/include/<CPLETTERBUG>).

In fact it is (we think) a key differentiator to use this script to maintain 
save_alls for your system over other tools to perform this task. (not 
compatible with IACC though)

Good luck in re-syncing you databases

Kindest regards,

Ron Deen @home

On Monday 16 April 2007 18:02, Johnson, Alex P (IPS) wrote:
> Dave,
>
>
> *         You cannot edit a checkpoint file.
>
> *         It is possible to edit CSA, but it's not necessary in this
> case.
>
> *         The right approach is to resynchronize the workfile to
> reality. I think there is a helpful hint and I know that I wrote this up
> for the list before.
>
>
>
> Here is that write-up. I'm not sure how well it will show up on the
> list, but anyone that wants a MS Word copy can send me a request
> off-list. I won't respond to an on-list request.
>
>
>
> AJ
>
>
>
> It must be the time of year, the topic of how to properly back up a CP
> and how to recover from the loss of the hard drive on the hosting AW has
> come up several times and I'm getting tired of doing this one at a time.
> So, here are my thoughts for all to ponder.
>
>
>
> This is really a case where free advice is worth what you pay for it.
> Remember, this does not replace the standard company policy of:
>
>
>
> 1)       SAVE ALL
>
> 2)       Failure
>
> 3)       INITIALIZE
>
> 4)       Reboot
>
> 5)       LOAD ALL
>
>
>
> However, even the company standard procedure does not address
> everything, e.g., #include files. So, be sure you keep those up to date
> somewhere off platform.
>
>
>
> So, with all of the expected caveats about free advice and standard
> documented procedures, read on.
>
>
>
>
>
> I have the general outline of a procedure, but it is NOT for the faint
> of heart. There are at least a few difficulties and probably more. The
> ones that I can think of are:
>
>
>
> 1)       Recovery of Sequence Code Source and Ladder Logic source is not
> going to happen, you must have up to date backups of this code.
> Basically, my advice is, "Make a SAVE ALL every time you recompile a
> Sequence Block or a PLB block." Also, if you use #includes you need to
> back those up, they won't be on the SAVE ALL.
>
> 2)       Block Order recovery can be awkward. You can use the order
> shown by the CP in the FoxSelect or Select window as the master and make
> the workfile match it - see below for what I'm talking about.
>
> 3)       dbvu does not like dumping out the parameters of CPs that have
> certain ECBs in them. I'm talking about the -t option (at least the last
> time I tried it on a CP60). This can make life tougher.
>
>
>
> General words of advice:
>
> 1)       Get help from Field Service! I can't stress this enough. There
> are guys who have had the (mis)fortune of doing this more than once. You
> probably have not.
>
> 2)       Understand what the relationship is between CSA, work files,
> checkpoint files, CP RAM, and the Sequence Block and Ladder Logic source
> code.
>
> 3)       In the future, be dead certain to make SAVE ALLs after all
> changes to Sequence (IND, EXC, DEP) or PLB blocks. This preserves your
> source code. Regular Save Alls will minimize the work, but will not
> eliminate the need for this procedure.
>
> 4)       If you use #include statements in your sequence code, you'd
> better back those files up! SAVE ALLs don't preserve them.
>
> 5)       Save Alls can be automated using scripts that can be found on
> the Cassandra Web Site. While that will not totally remove the need for
> SAVE ALLs after alterations of Sequence and Ladder Logic code, it will
> help.
>
>
>
> Here is the general gist of the procedure.
>
>
>
> 1)       Setup a duplicate system off line. It should contain at least
> an AW/AP with the latest backup tape for the CP host and a CP of the
> same type with the same letterbug.
>
> 2)       Boot the off-line system
>
> 3)       Determine which compounds/blocks have been added / deleted
> between the two CPs. You can use a variety of tools to get this
> information.
>
> a.       Workfile contents
>
>                                                                i.
> The print options of the ICC and ICC Driver Task can document the
> workfile
>
>                                                              ii.
> The refs toolkit - on the Cassandra site - can document workfiles
>
> b.       CSA
>
>                                                                i.
> The CSA tools (see the attached file csa_util.doc) can be used to see
> what CSA thinks is there.
>
> c.       CP's Running Database
>
>                                                                i.
> /opt/fox/bin/tools/dbvu - can be used to examine a checkpoint file and
> pick out compound and block names.
>
>                                                              ii.
> FoxSelect can be used to determine what the CP actually has in it (same
> info as dbvu)
>
> d.       Block Order - Use Select or FoxSelect to see the order of the
> blocks as known to the CP.
>
> e.       Source Code Files - are a problem because they are on the host
> and not in the CP. There is no way to to ensure that you actually have
> the latest source code for the Sequence Blocks and PLB blocks.
>
> 4)       Use the off-line system to build a correct CP image. That is,
> one
>
> a.       That has the correct set of compounds and blocks. This is a
> pain.
>
> b.       That has the right block order
>
> c.       That has up to date Sequence and Ladder Logic blocks
>
>                                                                i.
> The correct Sequence Code and Ladder Logic files
>
>                                                              ii.
> The correct #include files.
>
>                                                             iii.
> Recompiled source
>
> 5)       Once you have an up to date CP configuration in the off-line
> machine, you need to move it to the main machine.
>
> a.       Make a backup of the critical files
>
>                                                                i.
> cd /opt/fox/ciocfg
>
>                                                              ii.
> tar cvf <cpLbug>.tar <cpLbug> <cmpdName> <cmpdName>
>
> where <cpLbug> is something like CP0001
>
> <cmpdName> is the name of a compound in the CP that contains Sequence or
> PLB blocks.
>
> b.       Move the tar file (<cpLbug.tar>) to the on-line host and put it
> in /opt/fox/ciocfg
>
> c.       Extract the files (tar xvf <cpLbug>.tar)
>
> d.       Start the ICC and perform an upload from the CP
>
> 6)       Use the CSA utilities to fix the CSA database if necessary.
>
>
>
> Other techniques are possible given different starting points. Some of
> you may have everything back documented with FoxCAE for example, but
> they all boil down to this.
>
>
>
>
>
> Regards,
>
>
>
> Alex Johnson
>
> Invensys Systems, Inc.
>
> 10900 Equity Drive
>
> Houston, TX 77041
>
> 713.329.8472 (voice)
>
> 713.329.1700 (fax)
>
> 713.329.1600 (switchboard)
>
> alex.johnson@xxxxxxxxxxxxxxxx
>
>
>
>
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of David Johnson
> Sent: Monday, April 16, 2007 10:22 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: [foxboro] Out of sync databases
>
>
>
> Hey gang,
>
>
>
> I have a customer with the following problem.
>
>
>
> Several blocks (~10) exist in the checkpoint file, and in CSA, but
>
> not in the work file.  Unfortunately these blocks are all in the _ECB
>
> compound and I do not want to delete the compound, or initialize the
>
> CP. (Everybody wants to go to heaven, nobody wants to die.)  So, I
>
> was wondering if there is a way to delete the blocks from the
>
> Checkpoint file (and CSA).  I could then rebuild them and everything
>
> would sync up.
>
>
>
> So the question is
>
> Can you delete a single block from the CP (checkpoint file) that is
>
> not in the work file?
>
> I could use iccdrvr.tsk to DELETE C:B, but don't know if it will
>
> work, and hesitate to try it without more knowledge.
>
>
>
> Regards,
>
> David
>
>
>
>
>
>
>
> _______________________________________________________________________
>
> 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:             http://www.freelists.org/list/foxboro
>
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
>
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
>
>
>
>
>
>
> Confidentiality Notice:
> The information contained in this electronic message and any attachment(s)
> to this message are intended for the exclusive use of the recipient(s) and
> may contain confidential, privileged or proprietary information. If you are
> not the intended recipient, please notify the sender immediately, delete
> all copies of this message and any attachment(s). Any other use of the
> E-Mail by you is prohibited.
>
>
>
>
> _______________________________________________________________________
> 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:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 
 
_______________________________________________________________________
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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: