The DB.cfg file contains information crucial to the database and the promotion of data from remote servers. If this information is erroneous, then promotion may fail which will surely impact plotting. You are encouraged to look at a sample DB.cfg file while reading this document.
The DB.cfg file is a relatively simple configuration file which has few keywords but these keywords can be duplicated many times for different projects. Furthermore, the DB.cfg is very extensible which can make additions to the SDDAS system relatively painless in the future.
The DB.cfg can use environment variables in place of actual hard coded paths if desired and we recommend to use the SDDAS_HOME variable whenever possible. This makes the file able to be passed to different computers with little to no hassle.
Comments may also be placed in the DB.cfg file if desired. Use the "#" character to preface a comment. The "#" character to the end of the line will be ignored.
Also, each value (with the exception of NCP) is to be enclosed in quotation marks (").
Lastly, for all keywords that are paths, you may make use of the "%" character. If the defined value (or path) in the configuration file has as its last character '%', then no alteration to the path is performed.
The first token in the DB.cfg is the NCP value. NCP is an acronym for "Number of Concurrent Processes". During promotion, NCP processes will be launched each with the intention of getting data from a remote site. Increasing this number does not necessarily increase the speed of promotions since multiple sockets need to be setup to the server which can bog the server down. For best results, we encourage you to set the value of NCP to 1.
Example:
NCP 1 # number of concurrent processes available
The ITEMS token defines all the attributes which can be queried. This list is extensible and we currently make use of the following keywords:
The default values are as follows:
###################################### ### Default Values ###################################### DatabasePath.VALUE "$SDDAS_DATA" PostTimePath.VALUE "$SDDAS_DATA" RealTimePath.VALUE "$SDDAS_DATA" PidfPath.VALUE "$SDDAS_DATA" NetID.VALUE "129.162.154.15" DataPromote.VALUE "$SDDAS_HOME/bin/PromoteData_TCL" MetaPromote.VALUE "$SDDAS_HOME/bin/MegaMetaPromote"
The LEVELS token defines the hierarchy in a slightly different way. Each item defined in LEVELS will have the default information (i.e. each value of ITEMS) defined for each value in LEVELS. This means every project (from PROJECTS.cfg) must be defined under the LEVELS token. If you wish to change the value for a certain part of the hierarchy, you must define a new level for it.
This sounds confusing and it is, but an example should clear this up.
Suppose you have a project such as INTERBALL which has part of the project at one site and a different part of the project at another site. You need to define two LEVELS for INTERBALL. The LEVELS line will look like the following:
Examples:
LEVELS "TSS" "UARS" "INTERBALL" "INTERBALL:TAIL:PROMICS-3"
Notice the ":" between the levels of the hierarchy. This signifies that there will be defined below the additional information for this particular branch of the hierarchy.
The VALUE keyword is a token used to redefine a default value for a particular part of the hierarchy. This keyword can be repeated several times for each LEVEL and each ITEM.
Examples:
UARS.RealTimePath.VALUE "$SDDAS_DATA/UARS/test_data%" TSS.NetID.VALUE "129.162.155.19" TSS.RealTimePath.VALUE "$SDDAS_DATA/TSS/realtime_data%" INTERBALL:TAIL:PROMICS-3.NetID.VALUE "192.71.13.3" INTERBALL.NetID.VALUE "128.40.70.74"