Creating/Editing mSQL Databases for CODA

As mentioned in the procedure for operation of the run control, CODA cannot be initialized without the mSQL daemon running. This is because CODA uses mSQL databases to store information about run configuration and the operational status of components. There are two tools included with CODA that allow the creation and maintenance of these databases: CEdit and DBEdit. The default directory for storing CODA run control databases is currently /home/halld/micro/coda/rcdb, but databases can also be stored in /usr/local/coda/2.6.1/common/rcdb.

CEdit

CEdit is the more user-friendly of the two tools. It features a gui that is designed for the creation of new CODA databases, and the addition of components and other information pertaining to configuration. CEdit can be opened from a terminal by typing "cedit".

• Different run types are stored in databases, based on the components of the run. For example, the "micro_test" databases allows the use of an event builder and read-out controller. There is another database, "coda_test", which allows the use of an event builder, ROC, and event recorder.

• Create a new database by clicking "File -> New Database". By next clicking "File -> New", a new run type can be created.

• Open an existing database with "File -> Open Database". This will then allow access to different run types stored in that particular database. For example, "File -> Open Database -> micro_test" will open the default run control database, which was included with the halldtrg5 machine.

• To access run types in a particular database, click "File -> Open", and select the particular run type. For example, with the micro_test database open, "File -> Open -> Simple" will open the default basic run configuration, which consists of event builder and ROC.

• When creating/editing a run type, the canvas in the center of the gui is most important. When creating a new run type, either the canvas will begin blank, or will include the basic components associated with that particular database.

• Components can be added by clicking on their icon on the left side of the screen, and then clicking on the canvas. From top to bottom, the components are Trigger Supervisor (TS), Read-Out Controller (ROC), Event Builder (EB), Event Recorder (ER), Binary Output File, CODA Output File, Debugger, Script, and Trash.

• Components can be connected in a manner similar to labview, and it is important to ensure that the connections are directed properly (e.g. ROC -> EB, not the converse), and that the connections are affixed to the proper input/output on each component (outputs should be halldtrg5.phys.uconn.edu).

• Be sure to save the database/run type and exit CEdit before trying to run CODA.

• The components required for a minimal setup are a ROC, Event Builder, Event Recorder, and Output File. Each ROC needs to be connected to the Event Builder, and the Event Recorder needs to be connected to an output file, but the event recorder and event builder do not need to be connected to each other.

DBedit

DBedit is a more general table-editing tool, and should only be used to work on existing databses, and even then with caution, as it can easily corrupt a CODA database.

• Open DBedit by typing "dbedit" in a terminal window. The first screen that should appear is the mSQL browser.

• In the "host" field of the mSQL browser, select "localhost". A new tab labeled "localhost" should appear in the upper left of the DBedit screen.

• Click on the "localhost" tab. On the top line of the screen that appears, select the relevant database, in the field next to "Server localhost".

• Different parts of the database can then be accessed via the "table" field, directly under "Server localhost".

• Tables can be run types (like "simple") or be made up of run types or other configuration groupings. For example, one can open a table labelled "sessions" that allows the editing of parameters of all runtypes in that database simultaneously.

• Opening a run type in DBedit allows for quick editing of parameters of run components. For example, in the "simple" run type table, the inputs, output connections and format, order of activation, and "in use" status can be edited via typing into the relevant table column. This is much harder to set-up and troubleshoot than the graphical Cedit interface, hence the recommendation that Cedit be used in most cases. However, hen trying to make a specific edit to a specific parameter of the run configuration, DBedit can be more efficient.

• Opening other kinds of objects as tables can have varying results. Opening "runtypes" allows editing of the id's of runtypes, while "sessions" allows one to edit parameters of a runtype such as run number, congifuration, owner, and other identifiers. This kind of editing is what DBedit is best used for: general run control parameters of existing configurations, as opposed to creation of new run configruations or addition of components.