View source

'''What is CSA?'''
<br>
CSA stands for '''C'''ompound '''S'''ummary '''A'''ccess.  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 [http://www.imdb.com/title/tt0091203/taglines 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?'''
<br>
The way Foxboro designed their DCS, it would be a problem to have duplicated tag names on the system, [http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=duh&x=12&y=18 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?'''
<br>
CSA_SERVER is located in the <tt>/usr/fox/csa</tt> directory.  

The database files are located in <tt>/opt/fox/csa</tt>.

'''What's in the databases?'''
<br>
Mostly the Compound Name, Block Name, and block type.

'''What tools are available for working with CSA?'''
<br><tt>
AP_STOP:        executable shell script <br>
AP_delete:      executable binary <br>
CSA_Merge:      executable shell script <br>
CSA_Report:     shell script  - Generates text reports <br>
CSA_SERVER:     executable binary <br>
CSA_SETUP:      executable binary <br>
CSA_Save:       executable shell script <br>
CSA_Stop:       executable shell script <br>
CSA_Transfer:   executable shell script <br>
CSA_stn:        executable shell script <br>
csa_fn:         executable binary <br>
csa_stn_save:   executable binary <br>
</tt>

'''Hey! CSA_Report doesn't work!'''
<br>
Yeah, that's a known bug.  See Foxboro helpful hint HH1007.  Anyway the fix is to edit <tt>CSA_Report</tt> and change ''<tt>csa_save</tt>'' to ''<tt>csa_stn_save</tt>''.  The report will be put in a directory called <tt>/opt/fox/csa/CSA_REPORT</tt>.


'''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>