The operational programme database for the RFS PCA. E. Bracke SL/RFS-bc ---***--- 1 Introduction. The Executer of the RFS PCA is essentially a processor capable of executing sequences of sequences of commands. A sequence in this respect is represented as a table, containing references to operational code (a programme) or other tables. For such a system to operate, it is of importance that the tables are indeed referencing existing programmes or tables. The consistency requirement can become quite cumbersome to comply with when the system grows. There exist however a tool to help building these tables and ensuring their consistency: a database manager. 2 Design considerations. 2.1 Generation of tables for runtime. As such, the guaranteed consistent tables in the database abstract format can not be used by the Executer programme. All database managers have data extraction tools available in order to get tables from the internal format out of the database and stored in files (called reports in database terms). Indeed, quite powerful extraction rules can be constructed in order to meet the representation requirement. The Executer programme needs on two occasions information from the database: - In the compilation phase of the Executer itself we need to know how many operational programme blocks exist in the system as well as their names. - When reconstructing the tables, in an accessible format for the Executer, we need to know what the guaranteed tables must contain. On these occasions the system will access the files (reports) created by the database manager and downloaded into the relevant computer where the Executer is to operate. These files can be in the form of pure ASCII files, readable by any text editor, but in a predetermined format. There are three different files necessary: - file: rout_n.ora This file contains the definition of a label that represents the number of executable programme building blocks available to this Executer as well as the C-code prototype definition of these programme blocks. - file: rout_e.ora This file contains initializer values for the runtime name of each executable programme block, its C-code function name and a constant label. - Finally, while building the runtime tables for the executer, input from the database is also needed. Therefore every table is represented by a file. 2.2 Maintenance aspect. Maintaining a system of programme building blocks is greatly enhanced when using a database manager. Entry of new building blocks and modification of existing ones can be formalized, extraction of data (the creation of the compile and runtime files) can be automated, meeting the consistency ensurance aspect already mentioned in the introduction of this note. Output of the database generation can easily be inspected in case of doubt of correct input to the operational Executer: the input files contain man understandable ASCII. 2.3 Link with the presentation layer database. Inevitably a link has to be laid between the operational programme database and the database which describes all possible commands, available to a user at a console. It would obviously be of an advantage if both databases were existing under the same manager: the link could then be constructed within the same environment. For the presentation layer database it has been decided to use the ORACLE database manager. The operational programme database can be constructed while using the same tool. 3 Example layout of a database. 3.1 Definitions. In the following example of an operational programme database, the field definitions are as follows: - Class_Attr: Attribute defining class of the database entry: FirstLast, Executable, Abort, Switch or Complex. Only the last one references a table; the others reference programme code. - Runt_name: An unambiguous ASCII name under which the entry is known in runtime. - File_name: Name of the ASCII file containing either one or more executable programme source object(s) or the database extracted references that describe a table. - Nb_cmnds_seqel: ASCII number reflecting the number of executable programme sources or the number of sequence elements in the table. - C_code_fn: Source code name of an executable programme in case of an executable class reference, not defined in case of a table class reference (i.e. Complex). - Link: Not defined in case of an executable class database entry, giving the runtime name of an executable class reference in case of a table class entry. - CLA_A: Giving the Command Level Attribute: Absolute for an executing class type of entry, not defined for a table class reference. - Entry_date: The date of entry of this reference into the database in the inverse order (YYMMDD, the mutad). 3.2 Appendix. The appendix shows further examples of the three types of files, extracted from the database. These files are useable while compiling the RFS PCA Executer source code and in runtime by the Executer while building the C-code structures that together form the runtime operational programme database. 3.3 Layout example of an operational programme database. E CMND_0 cmnd_n.c ÚÄ 4 ÄÄ¿ cmnd_0 nd 1 911213 E CMND_1 cmnd_n.c <Ä´ nd ÃÄ> cmnd_1 nd 1 911213 E CMND_2 cmnd_n.c <Ä´ nd ÃÄ> cmnd_2 nd 2 911213 E CMND_99 cmnd_n.c <ÄÙ nd ÀÄ> cmnd_99 nd 1 911213 C CMDNT_0 cmdnt_0.ora ÚÄ 3 ÄÄ¿ nd CMND_0 nd 911213 nd nd nd <Ä´ nd ÃÄ> nd CMDNT_1 nd nd nd nd nd <ÄÙ nd ÀÄ> nd CMND_99 nd nd C CMDNT_1 cmdnt_1.ora ÚÄ 2 ÄÄ¿ nd CMND_1 nd 911213 nd nd nd <ÄÙ nd ÀÄ> nd CMDNT_2 nd nd C CMDNT_2 cmdnt_2.ora 1 nd CMND_2 nd 911213 Notes: - In the field: "E" class designates an executable programme entry; whereas "C" designates a sequence (CoMmaND Name Table). - If entry in the database of is an executable class, the field can be defined as "not defined". If is a table class (Complex) both the and fields can be defined as "not defined". - Upon entry in the database of the database must reserve and ask for the definition of the now reserved records.