How to tell whether an SLC database secondary value is "remembered" across a DB INSTALL or whether the source file value is used:

HVS 5/16/00

First the Answer: Look in the file ref_dbsfile:savedata.inp (this file lists all secondaries which are saved.)

Now the Discussion: (HVS version...by reading further, you acknowledge my past, present, or future right of complete disclaimer of all or part.)

(A more "official" version of these database issues is listed elsewhere. I discuss here only issues necessary to define the scope of the specific matter of the ramifications of DBSAVE).

The SLC database lives in memory on the Production Control System Mainframe computer (called as of present the DEC/COMPAQ alpha node "MCC"). The structure is pre-defined...with things like primaries (example "XCOR") which have secondaries (example "BDES"). Each primary has a micro and a unit associated. Example of how the control system maintains the desired strength of a corrector would be XCOR LI12 202 BDES where XCOR is the primary, LI12 is the micro, 202 is the unit, and BDES is the secondary. BDES for this unit will have a value (of predefined datatype, in this instance a floating point representation of a real number) in the database (mainframe memory).

The database needs to be periodically re-built (it's structure is not dynamic). An example of this would be the intallation of a new magnet. The database for the magnet would need to be generated (from a source file) and then installed into mainframe memory. Terms DB Gen and DB Install are used for this process. In order to add any DB item, the entire DB must be reloaded. Again, the structure is not dynamic.

It is curious to consider what is involved in changing a database secondary value. This is generally done by software in quasi-real time. (Magnet BACT values are updated automatically via MCC<->micro interaction) Some secondary values are only "looked at" by control system software. (example the z location of a Beam Position Monitor).

Software utilities exist to allow users to change database secondary values generally at will (DBEDIT, EDITDBS). It is important to understand the distinction between what these utilities do. It is also important to understand whether the secondaries of interest have values "remembered" across a DB install.

DBEDIT:

This changes (edits) secondary values in mainframe memory. That is all it does. See help elsewhere for the nuts and bolts.

EDITDBS:

This "helps" a user change the source file(s) which are used to generate a database in memory. Changing the source file DOES NOT CHANGE the database in memory. EDITDBS does offer ability to run DBEDIT (nice features, again see elsewhere for nuts and bolts) which will change the database in memory, if user desires. Without using DBEDIT, changes to source files made using EDITDBS will not appear on the realtime control system until after a DBGEN and a DBINSTALL.

DBSAVE:

Prior to a DBINSTALL, some secondary values are "remembered" and then dumped back into the new (memory) database after installation. Examples would be magnet BDES values (one would not want a database rebuilt to change magnet strengths, right?) The stuff at the top of this note describes how to tell what secondaries get "saved" in this manner.

So my point is that if one wishes to change the database, one is generally well served by understanding how DBSAVE effects their secondaries of interest. A clear understanding of these issues will help one do the "right thing" (DBEDIT only without changing the source file, EDITDBS without DBEDIT, etc.) depending on exactly what it is one is trying to achieve.

Footnote:

If you find yourself trying to do archeology to resurrect information which got into the Real Time Control System through through DBEDIT without associated changes to the database source files, there is a place in which every DBEDIT's "mini-edit-file" gets saved (and remembered for some period of time -- presently a few months).

The place to look is LIB_DISK:[DBSYS.DBEDIT]

Anytime anyone does a DBEDIT, the mini-edit-file used gets copied into that directory. Digging through the files in that directory can help you understand how the Real Time Database came to be different than the database source files.