Absolutely everything there is to know about CSA
From Cassandra
What is CSA?
CSA stands for Compound Summary Access. It is how I/A keeps track of Compound:Block names, which must be unique throughout the system. There are a set of CSA databases and a program called CSA_SERVER used to guarantee uniqueness of a name. As in the movie Highlander, "there can be only one." That's right, there is only one CSA_server for each I/A area. So, a connected multi-node system have only on CSA.
Why have CSA?
The way Foxboro designed their DCS, it would be a problem to have duplicated tag names on the system, duh. So whenever you try to create a block, the system checks with CSA to make sure that the name is valid and unique. Having a single place that can impact the DCS is a concern. When CSA is unavailable, you cannot add new blocks with the control configurator. Why didn't Foxboro just query a name on the DCS and see if it returns a value before letting you add it? Because a CP could be temporarily off line when a query was broadcast. Once the CP came back online, BAM! duplicated Compound:Block name. So, we have CSA. Wait a minute, you're saying Foxboro can make a fault tolerant CP, but can't make a backup CSA server? That if CSA gets corrupted I'm screwed? Yup, that's what I'm saying.
Where does CSA reside?
CSA_SERVER is located in the /usr/fox/csa directory.
The database files are located in /opt/fox/csa.
What's in the databases?
Mostly the Compound Name, Block Name, and block type.
What tools are available for working with CSA?
AP_STOP: executable shell script
AP_delete: executable binary
CSA_Merge: executable shell script
CSA_Report: shell script - Generates text reports
CSA_SERVER: executable binary
CSA_SETUP: executable binary
CSA_Save: executable shell script
CSA_Stop: executable shell script
CSA_Transfer: executable shell script
CSA_stn: executable shell script
csa_fn: executable binary
csa_stn_save: executable binary
Hey! CSA_Report doesn't work!
Yeah, that's a known bug. See Foxboro helpful hint HH1007. Anyway the fix is to edit CSA_Report and change csa_save to csa_stn_save. The report will be put in a directory called /opt/fox/csa/CSA_REPORT.
Quick example
Save the csa database
# cd /usr/fox/csa # ls AP_STOP CSA_Report CSA_Save CSA_stn AP_delete CSA_SERVER CSA_Stop csa_fn CSA_Merge CSA_SETUP CSA_Transfer csa_stn_save # # CSA_Save /opt/<directory>
Version 6.5.2/7.1.1you need to use an additional argument.
# CSA_Save IKNOWWHATIDO ./directory
The IKNOWWHATIDO is an OM argument implemented from way back that allows the user to over ride certain constraints imposed by the object manager itself.
This is a very dangerous argument to use because it will do as you tell it, typo's and all.
Manipulate the files in /opt/<directory> if you know what you do
# CSA_Stop
Delete the csa database
# cd /opt/fox/csa # ls BPARM_DEF.dat CP4006 FD31FT MBPLUS drivers.lic BPARM_DEF.idx CP40B3 FDG001 MG1501 foxblock.lic CMPD_INDEX.dat CP40IO FDG030 MG3001 CMPD_INDEX.idx CP6001 FDG3FT MG30FT vol001 CP3001 CP6003 HCP407 STN_INDEX.dat vol003 CP3017 CP6004 HCP4B5 STN_INDEX.idx vol200 CP4001 CP6005 HCP603 CP4002 F30BFT IG0001 aW5101 CP4003 FD30B1 M30BFT drivers.chk # # rm delete_all_without_the_BPARM*_files # ls BPARM_DEF.dat BPARM_DEF.idx #
Start the csa process
# cd /usr/fox/bin # go_ACSA
Check that the CSA has registerd the global variable otherwise reboot the AW Both variable values needs to be the same
# glof -p CSA_SERVER Global find for process "CSA_SERVER" = 0 00 00 00 01 00 0D 49 30 30 30 31 30 31 08 00 20 E3 82 46 00 00 00 00 00 00 00 # glof aw5101 Global find for letterbug "aw5101" = 0 00 00 00 01 00 0D 49 30 30 30 31 30 31 08 00 20 E3 82 46 00 00 00 00 00 00 00
Restore the csa database
# CSA_Merge /opt/<directory>
