PROCESS CONTROL - CONTROL SYSTEMS - QUINNESEC Ed Zychowski 9/10/98 Download: ez_archive.zip (7 KB), ez_archive.tar.Z (8 KB) IMPORTANT: This application has only been tested on 51-series stations at V4.2.3 The I/A system has two basic methods of backup. The first method, called a saveall, backs up the database of the control processsors, spectrum interface processors, AB stations etc. This back-up is made to diskette from a copy stored on the hosting application processor or application workstation. This type of backup can be performed during normal operation of the stations. The second form of backup is an image dump of workstations or application workstations. This backup is performed to a streaming tape and is made while the workstation is offline in "single user mode" and takes about an hour to perform. In the event that there is a failure of the hard drive on an application workstation, and control database changes have been made, this backup system is potentially inadequate even though a saveall of the control processor has been made. This is due primarily to how the compound summary access software and checkpoint software works. Without getting into a lot of detail about how the software works, here are a few examples of some of the problems. If a block had been added since the last tape backup, the block won't be accessible from ICC. The block will still be running in the control processor and can be visible from select. The block cannot be "re-entered" from ICC because CSA sees it as existing. In the event that the control processor would need to reload, the block will not be there. You cannot up load the block from the control processor because an upload only uploads a subset of block parameters. The "save all" is useless because the only way to get saveall data back into the control processor is to initialize the control processor (completely deleting the control processors control database) and then doing a "load all" which will re-sync the CSA database. If the process is running, this is not usually acceptable. I have spoken with a number of people from Foxboro and they acknowledge the problem exists. During the start-up of a recent I/A conversion, the hard drive on the application workstation was corrupted and we learned that this is a real problem. To minimize the problem, I have written a program called ez_archive, which will automatically copy these important files to a remote station each day. In the event of a loss of the hard drive on an application workstation, the drive would be repaired, the most recent tape would be loaded and the backup files would be restored back to the application workstation from the remote station. On the application workstation, the files ez_archive and ez_mask should be copied to an appropriate directory. In our I/A system, that directory is /usr/ci/archive. The same directory should be created on the remote station that will be used as a repository for the back up files. The back up station for our I/A node is 02WP02. IMPORTANT !!!!! The locale variables ArchPath and ArchSta must assigned appropriately in the script file ez_archive. This is done by editing the file. For example, given that my directory structure is /usr/ci/archive and my remote node letterbug is 02WP02, the first two lines of the script should be: ArchPath='/usr/ci/archive' ArchSta='02WP02' Remember to use correct unix syntax for variable assignments. (ie. no spaces, correct quote symbol (` is different than '). Next make sure the file ez_archive and ez_archive.restore are executable if they aren't by entering the command: chmod +x ez_archive ez_archive.restore The script ez_archive can then be added as a cron process via crontab. In our system, it will run every day at 3am. The program uses the directories in the file ez_archive.mask to filter directories in /opt/fox/ciocfg so that unnecessary files are not saved. This has the additional benefit that if a new station or compound is added, the archive software will not have to be modified. The new files will be backed up automatically. Additionally, if a compound or station is removed, the backup files will also be removed. The file ez_archive.log will be created on the application workstation in the same directory as the script. This file will list the last 20 times the archive ran. The code will also automatically rmount the remote station in the event that it becomes unmounted. Any errors generated by the script will be reported via e-mail to the user as all cron processes without a defined output destination do. The openwindows application mailtool works well to monitor this. On the remote station, using the ArchPath as the starting point, the directory structure of the original files will be reconstructed. For example, on the application workstation, the source code of block BPCHEM:BPPROD is in /opt/fox/ciocfg/BPCHEM/BPPROD.s. On the remote station (using the our setup), the file will be on 02WP02 at /usr/ci/archive/opt/fox/ciocfg/BPCHEM/BPPROD.s. To restore the files back to the correct location from the remote station, run the ez_archive.restore script. This script will get the remote station letterbug and path from the ez_archive script. Before running the ez_archive.restore script, it is necessary to ensure that the remote system is mounted to the AW.
Copyright ©2000 The Cassandra Project
web posted: 18 April 2000
last updated: 19 April 2000
Contact the webmaster for comments and/or questions.