One solution would be to have each piece of software read its constants from a separate data file during the initialisation phase of execution. However this would rapidly become an administrative nightmare as the number of files escalates. Separate users would be forced to make copies of all the files and soon even getting the program to produce the same results twice would become difficult! Also such a solution runs contrary to the requirement that there be a central database from which all constants could be drawn.
An additional problem is that some constants are more constant than others! For example certain calibration constants will change on a regular basis and it is vital that the software uses the correct version for the data being processed. There is no reason why data from a number of runs might not be concatenated into a single file to be processed by SNOMAN which raises the possibility that the constants change while SNOMAN is running.
The management of titles system provides a solution to both these problems. It provides central input of all constants without compromising the modularity of the software - new constants can be added without changing the system. It also provides an interface to the database and actively manages all the constants in its domain, dynamically updating them on an event by event basis as required.
The system uses a ZEBRA bank as the basic storage unit. Software writers requiring constants have to design a bank in which they record them. To simplify the process of creating such banks, the system uses the ZEBRA TZ titles Package (this explains why program constants are often referred to as ``titles"). TZ allows a bank to be created in free format with embedded comments using any editor and provides an input facility to read a file containing any number of such banks into a ZEBRA memory. This titles file can then be used to load the banks into the database or can be used directly with SNOMAN.
The management of titles system gets its titles from either the database or from a set of one or more titles files. Banks from titles files always take priority over those from the database and this provides a convenient way to develop new banks or change existing ones without disturbing the database. So, in general, the system reads titles files containing new or modified banks and then gets any other required banks from the database. In principle only one titles file is required, however several are provided to allow the data to be organised logically. So, for example, JOB_CONTROL.DAT contains job control, GEOMETRY.DAT the geometry and so on.
Centralising the input of the banks is, of course, only half the battle. Individual software components still need to get access to them. To do this they make requests to the management of titles system passing it the name and number of the bank they require and the type of access wanted. The system supports 2 types of access: link access and COMMON block access. Link access is the simplest; the caller provides a link variable which on return is set to point to required constants. COMMON block mapping also provides a link but also makes an image copy of the bank to a caller designated COMMON so that it is equivalent to having read the constants directly into the COMMON.
The system has dynamic management of the titles. It checks all titles banks at the start of each event and updates any that have to be changed. Updating may involve reading a new version from the Database. It also involves updating all links and COMMON blocks through which the software gains access to the constants. To do this, the system has to be able to inspect any titles bank and determine if is valid for the current event. In order that it can do this, all title banks must start with a 30 word database header. A description of this can be found in:-
Companion/Titles Banks/DBHDR Database Header
The Programmer's Manual describes the management of titles system in more detail.