Design Note 95.1
EPICURE OA/LAL Database Integrated Builder System
Cynthia A. Chopp David M. Kline
The purpose of this paper is to propose an implementation strategy for the Epicure database Look-Aside-List (LAL), and to provide descriptions of the components which compose the Optimized Access (OA) View/LAL builds. The LAL is a subset of the OA view and contains only the devices which have been added, modified, or deleted since the last complete database build. The mission of the LAL implementation strategy is to move the Epicure control system closer to providing operations with a simple and consistent way of manipulating devices and device templates transparently without requiring detailed knowledge about the database. By implementing the LAL, faster build times may be realized since the number of devices to process is drastically reduced from the amount that is contained in the OA view. Additionally, the LAL section files are smaller, which have an impact on the distribution time to the remote destinations. An interactive editor will be used to perform the adding, modifying, and deleting of devices and templates using the Epicure ESM routines to produce the required screens.
There are several components which are incorporated into the LAL implementation which interact. The following sections provide a description of the components and suggest how they might perform the required tasks.
The LAL implementation will use the Epicuredb account OA builder as a point of departure. The techniques incorporated to build, and distribute, will be maintained on every destination for both an OA and LAL build. Global variables and parameter passing will be used as switches to indicate which build is being accessed, thus maintaining one group of programs to build either the LAL or OA. The implementation will use a combination of lower priority batch and detached processes to perform the required tasks. A condition handling function will be provided to reduce operator intervention by specifically checking for error conditions which could affect the execution of the OA/LAL build application. The components used to implement the build, distribution, and start up are listed and described below:
Refer to the attached sheet for a pictorial representation of the Integrated Builder System.
The purpose of this application is to automatize the current DDT and MDT files into individual devices and templates, and place them into separate RMS databases. Templates which need to be modified will be done by an authorized user creating a MDT file which represents the template. The MDT file will be presented to the application where it will be transformed and placed into the RMS database.
The RMS file subsystem will be used to implement the device and template database containing a format that will use one record per device or template. The database will have the device index as the primary key and the name as the alternate, so devices and templates may be accessed either using the DI or NAME property. This database will be accessed through the use of an interactive editing application.
Through the use of the DBEditor menus, users will be able to access the commands of add, delete, or modify to any of the devices or templates.
To add a device or template the user could choose it to be similar to another or create a totally new one. In adding, the device or template is created and stored in a temporary database. Once the user is finished and exits the menu option of adding, this information is inserted into the RMS database in alphabetical order. This information is also placed in a temporary updated device database to be used with the DBExtractor.
In modifying a device, the module is extracted from the RMS database, and the user makes alterations. Once finished, and the user exits the modify menu, this information is inserted back into the RMS database. This information is also placed in the updated device database to be used by the DBExtractor.
In modifying a template, the module is extracted from the RMS database, and stored in a temporary database where the user makes alterations. Once the user has finished and exited the menu, this information is stored in a temporary updated template database. These changes will only be processed with an OA build.
In deleting a device the user is queried for only the device name. Once found, the device will be deleted from the RMS database, along with being placed in the temporary updated device database.
In deleting a template the user is queried for only the template name. This information is stored in a temporary updated templates database, to be processed only with an OA build. Those devices that use the deleted template must also be deleted by the user. The device deletions made by the user will be processed with a LAL or OA build.
All altered devices, including deletions, for the day, will be stored in a temporary updated device database. The template which the devices use will also be entered in a temporary database to be used by the DBExtractor. Every time a LAL is built, the information from these files will be used to create the DDT and MDT files for the LAL builder. From these databases, the LAL DBExtractor application will be able to extract only certain modules of devices and their templates used, instead of extracting the entire group of modules like the OA does.
All changes made to templates for the day, will not be processed with the LAL. Any changes made to devices using these changed templates, will be using the old template version until the OA every night process is run or forced. All template changes require a complete rebuild (OA build) to become active. This waiting period is for the user to be sure of the changes made to a template.
After the user adds, deletes, or modifies a device or template they have the option to create a LAL. This list is a quicker way to view newly added device information, saving the user the time it takes to do an OA build. It contains only the changes that have been made to the devices and or templates. When the database is accessed, the LAL is viewed first and then the OA. Only at night when a build is run for the OA will the database be complete. Creating a LAL saves time and space since it only saves altered devices and or templates. All changes can be viewed after a LAL build is complete. Changes will not be brought into the OA until the every night job is run, or a forced build is made by an account manager.
Users may create a build of the LAL through the accessing of the DBEditor menus. Users will not be able to create a build of an OA. Only authorized users will have access to initiate an OA build. The only other time an OA will be built is during the every night job.
The system everynite facility will cause an OA build to execute on behalf of the EPICUREDB account. The everynite OA build will read in every RMS record, construct an OA, distribute it, and restart the database servers on WARNER, DISNEY, CRYO, front end, and test stand nodes. The everynite build collapses the OA and LAL into one OA, invalidating any previous LAL builds. If the build was successful mail status messages will be sent to account managers.
Next the application connects to the remote EDBServer processes and requests their OA and LAL serial numbers. If the serial number is less that the one extracted from the hash root, the EDBServer process is restarted. This iteration continues for all valid destinations as identified by a internal list. The internal list is a list of nodes in which EDBServer processes are present. The list is initialized by the DBScanner reading a non-volatile database implemented as an RMS file and contains the requested node list. A utility program will be present which allows one to modify the RMS file without stopping and restarting the scanner.
In future enhancements to the LAL implementation, additional functionality could be added to support the following applications: