Fred White's Enchilada Proposal ------------------------------- Background ---------- SigImage has requested that HP provide a metadata repository beneficial to utilities (backup and maintenance) and applications. This proposal arose during a meeting in Las Cruces, (a source of great Enchiladas) and was fittingly assigned "Enchilada" as a project name. Subsequently, four (4) different approaches arose as to what form the Enchilada should take. One of these approaches is the subject of this paper. HP is sympathetic to the concept but rightfully doesn't want to embark on any detailed design and implementation until SigImage and HP decide on which approach to follow. This paper presents Fred White's approach which is, hopefully, specific enough so that the reviewer can understand it. It leaves the detailed design and implementation specifics up to the design team which is recommended to consist of HP personnel together with a small group of 3rd party utility personnel as determined by the SIEC. I understand that the other three proposals all require some modifications to IMAGE root files. Mine does too but I believe them to be minimal. Glossary -------- IDB ... an Image, TurboImage or ImageSQL database. ADB ... an Application Data Base which consists of all of the files, if any, and all of the IDBs, if any, that are accessed by the software of a given application. An ADB is never empty. TACO .. an acronym for the Enchilada proposed in this paper. TEMPLATE ... a term applied to a *special* virgin IMAGE root file which is used to control creation of all TACOs (see later). Introduction ------------ My proposal is based on the beliefs that (1) any Application Manager (AM) who wishes to have an Enchilada for his Application Database (ADB) (no matter how many files and/or IDBs his ADB contains), is best served by a single, easily accessible and maintainable Enchilada and (2) that HP will prefer an Enchilada which (a) has minimal impact on existing customers, (b) takes advantage of existing software (HP and 3rd Party) with a minimum cost of development, maintenance and documentation and (c) which is readily extensible in response to future demands. It is my belief that the TACO described herein possesses these characteristics. Proposal -------- Each TACO is a *special* IMAGE database which is created by an Application Manager to serve as the residence for the metadata pertinent to his/her ADB. Users can have as many TACOs as they want but at most one per application (including test applications). The exact details of the TACO are left to the design team but some of the things I visualize are: The first TACO dataset will be a manual master serving as a residence for the names of all files and/or IDBs which collectively constitute the AM's ADB. The filename field will be large enough to contain the names of files (and IDBs) resident on other systems to provide for multi-system ADBs. The second TACO dataset will be a manual master serving as a residence for the product name(s) of any and all utilities dealing with the files/IDBs of the ADB and the TACO itself. Another will be a detail related to the first two providing space for utilities to log information about functions they have performed upon ADB files and IDBs. The specifications for this third dataset will be drawn up by the design team members. The design team will include other datasets as needed for the storage of other kinds of metadata such as blobs (or blob names), date/time data types, IMAGE/SQL splits and update/types and various other metadata discussed at the Las Cruces meeting. The design exists in the form of a schema retained and maintained by HP. A modified version of DBSCHEMA creates the TEMPLATE by processing this schema to generate a virgin root file distinguished from normal root files by having a "TACO" tag and a file code of -399. This root file is the TEMPLATE for subsequent TACO creations (see below) and is present in all FOS releases. The -399 file code is to prevent DBUTIL from creating a database with this TEMPLATE as its root file. This root file serves as a template for all subsequent TACO creations (see below) and is present in all FOS distributions. TACO Creation ------------- DBUTIL can have a TACOCREATE command with syntax identical to its current CREATE command: TACOCREATE [/maintenance word] After verifying that the HP supplied TEMPLATE exists and has a file code of -399, DBUTIL copies the TEMPLATE to and sets the file code of to -400 after which an implicit CREATE is performed. TACO Maintenance ---------------- The AM may (at any time) use a database utility to review the TACO's dataset capacities and, if needed, change those capacities to meet their application's needs. Utilities (DBUTIL & 3rd party) can provide the AM with a command such as: ATTACH to For IDB root s, the utility inserts the (and timestamp?) in the IDB root file and the root's (and file code) in the first dataset of the TACO. For other files, the utility inserts the (and file code) in the first dataset of the TACO. To reverse this process, the utility will also provide a command such as: DETACH from Ideally, HP would provide intrinsics which DBUTIL and other programs could call to perform ATTACH & DETACH. QUERY can be used by the AM and others to read TACO data and is available to the AM for adding, modifyingy and deleting all TACO data except that resident in the first dataset (unless QUERY is provided with ATTACH/DETACH commands. TACO Advantages --------------- It benefits from the security provisions and access methods provided for all IMAGE databases. It takes advantage of existing HP software with very few changes/additions. TACOs on all systems are standardized with item names, item specs, dataset names, dataset fields, paths and sort fields the same on all systems so that properly designed utilities can work on all TACOs on all systems. All releases include a TEMPLATE which is always a a superset of an earlier TEMPLATE. Changes, if any, are in the form of additions so that new TACOs created from the new TEMPLATE can be backward compatible with existing software. It permits metadata sharing by ALL files and IDBs of an ADB thus eliminating metadata synchronization problems and minimizing metadata data entry. It is extensible (with SigImage and HP approval) to support future metadata requirements without incurring new root file modifications. It is expandable via the CHANGE CAPACITY commands of 3rd party utilities. It is flexible in that new files and IDBs can be easily ATTACHed and old files and IDBs DETACHed in response to application changes. Also, files and/or IDBs under test can be ATTACHed (and subsequently DETACHed) with ease. The TACO metadata is accessible via QUERY and existing 3rd party software. It requires minimal modifications to root files: 1. For IDBs, a field large enough to contain the name of the associated TACO. 2. For TACOs, a tag to distinguish it from IDB root files. It requires no future modifications to root files. ----------------------------------------------------------------