Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1367

News	FAQ
Search	Home

System databases

The local characteristics of an aips++ installation will be described in system databases. Note that the term database in this context simply refers to a file or set of files which store information, much like the passwd, group, services, etc. files in unix. The SP (system parameter) and ID (imaging device) files in $\cal {A}$IPS are further examples of such databases. The SP file stored information on peripherals such as data disks (including disk bookings and TIMDEST limits), tape drives, TV, graphics, print and plot devices, the (pseudo-) array processor system, access restrictions, local system identification, and so on. The ID files stored a detailed description of each image display device, and were themselves used as a lock file for arbitrating TV access. aips++ will probably not need to duplicate the $\cal {A}$IPS parameter set, but some databases certainly will be needed.

A problem with the $\cal {A}$IPS system databases came to light in the late 1980s when multiple-host installations of $\cal {A}$IPS in a network environment started to become the norm. The design implicitly assumed a single-host installation, the norm in the preceeding decade. Having a separate SP file for each host did not cater for large areas of commonality between hosts at the same site. For example, changing a system parameter common to all machines at a particular site required changing the SP file for each individual machine. The fact that SP and ID files could only be modified by using special purpose programs was an added inconvenience.

These problems can be circumvented in aips++ by using a heirarchical scheme based on ASCII text files. Each of a sequence of ASCII files would be read in a set order. The first file in the sequence would contain a complete set of default definitions. Subsequent files would refer to an ever more restrictive domain of applicability and contain definitions overriding those of preceeding files. Given the directory heirarchy proposed in part 1 of this discussion document, the following sequence suggests itself

      $AIPS/$ARCH/$VERS/aipsrc
      $AIPS/$ARCH/$VERS/$SITE/aipsrc
      $AIPS/$ARCH/$VERS/$SITE/$HOST/aipsrc

where the variables (not necessarily environment variables) have the following meanings

      AIPS    ...root of the aips++ directory tree (e.g. /aips++)
      ARCH    ...host architecture (e.g. sun4, ibm)
      VERS    ...released (base) or development (apex) version
      SITE    ...site name (e.g. aoc)
      HOST    ...host name (e.g. baboon)

The first file in the sequence $AIPS/$ARCH/$VERS/aipsrc, containing default definitions, would be distributed with aips++ and not be changed in the installed system. Instead, any site specific parameters would be defined in $AIPS/$ARCH/$VERS/$SITE/aipsrc. The hosts within each site would each have their own aipsrc file, and typically this would be used for attached peripherals. It has been argued that a .aipsrc file should also be provided for users to override system defaults. This would require a mechanism to prevent them from circumventing access restrictions. The routine which reads the databases should allow that the host, and possibly the site aipsrc files be empty or missing.

The fact that site-specific databases reside in a subdirectory with a site-specific name allows for easy maintenance of aips++ among multiple sites belonging to a single institution. Given that a particular site holds the master copy for an institution, all that should be required to keep the slave copies up-to-date is to copy the directory tree from the master. The fact that the master and slave sites have different names will prevent the slave's databases from being overwritten.