08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C Date: 5 August 1985 From: W. Olin Sibert To: MAB Distribution Subject: Procedures for Software Installation and Integration This document describes the process of installing software changes into the Multics system libraries maintained on Honeywell's System-M Multics system in Phoenix, Arizona. This includes the installer's job, the installation process, and the tools used for installations. Requests for installation of software must conform to the standards documented in MAB-056 and MAB-057 (see below). When an installation has been prepared according to these procedures, it is turned over to the Systems Integration project, which follows the steps described in this document. These procedures are being followed for all installations made subsequent to the MR11 system release, in order to satisfy B2 Configuration Management requirements for all subsequent releases. This document obsoletes MTB-712 by Holmstedt, Johnson and Martinson, which described procedures in use up to MR11. Related documents include: MAB-070 Multics Configuration Management: Policy Statement MAB-066 Multics Configuraion Management: Software Development MAB-056 Multics Configuration Management: Installing Planned Changes in System Libraries MAB-057 Multics Configuration Management: Installing Emergency Changes in System Libraries MAB-063 Multics Configuration Management: Critcal Fixes for Released Software MTB-716 Multics Configuration Management: Tracking Software Changes for MR12.0 _________________________________________________________________ Multics Project Internal working Documentation. Not to be reproduced or distributed outside of the Multics project. - 1 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C THE INSTALLATION PROCESS Installation of a software change includes the following steps. This document describes the actual mechanisms used for the steps performed by the Systems Integration unit, which is responsible for maintaining the standard system libraries. This document describes only those steps for which Systems Integration is responsible; step zero serves as a placeholder only. 0) A change is prepared. This includes writing documentation (MTB, MCR) for the change, coding and testing the change, auditing the change, and finally, preparation of a Multics System Change Request (MSCR) form, which drives the installation process. 1) The installation is started. This includes creating a directory for the installation, updating the database to indicate its location, and manually copying the modules comprising the change (that is, those listed on the MSCR) into the installation directory. 2) The modules are checked for appropriate historical comments and protection notices. Comparisons (CPA output) between the new modules and the library versions is generated for the historical record. The modules are then compiled, archived, and bound, making them ready for installation into the libraries. An exception report is generated for the installer if there are any problems. 3) An exec_com is prepared to perform the actual installation and update the installation database; it is checked for correctness by the installer and missing items added manually. 4) The installation exec_com is run to install the change and add a record describing the installation to the installation database. This completes the installation. JOB OF THE INSTALLER This section describes the steps an installer might take for a simple installation. It concentrates on the steps performed manually; for details of the exec_coms used in these steps, see their individual descriptions below. To do an installation, perform the following steps: - 2 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C * STEP 1: Run begin_installation.ec, to create a directory for performing the installation; this leaves the installer's working directory set to the installation directory. * Copy all segments specified on the MSCR into the installation directory. * STEP 2: Run check_installation.ec, to check and compile the programs. This may be performed interactively or in an absentee process, depending on the size of the installation; the exec_com asks whether to run as an absentee or not. * Check the mail and absout from check_installation.ec (or the console output, if run interactively) for errors, such as compilation errors or missing segments needing recompilation because of changed include files. If there are any errors, correct them and return to step 2 (see the MSCR checklist in MAB-056 for details). Update the history comments in the modules being installed. * Fetch the source and object archives affected by the installation from the system libraries and update them with the segments being installed. Sort the archives if any components have been added. * Bind the modified object archives. * STEP 3: Run build_installation.ec, which prompts for information about the installation and creates install.ec. * Check the install.ec for accuracy, and add or change additional update_seg commands as required for special requirements of this installation, such as segment deletions or special ACL/ring bracket values. * Check install.listin (the database record containing the installation description) for accuracy, and correct if required. * STEP 4: Run install.ec. After it has run the update_seg commands, it will ask whether to proceed. Answer "yes" at this point to complete the installation, updating the libraries and database. * If the installation shows problems, manually de-install it using the update_seg command, correct the problems, and return to step 2. * A week or so after the installation has settled, delete the installation working directory using delete_installation.ec. - 3 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C THE INSTALLATION HIERARCHY All the segments used in performing an installation are kept in directories under >special_ldd (>spec). This includes segments being installed, the tools used for installations, the installation database, and the change records (cpa output, etc.) from all installations. Each installation is identified by an "installation ID" that uniquely identifies that installation for all time. An installation ID has the form "MRxx.x-nnnn", where "MRxx.x" is the Multics release in which that installation is to appear, and "nnnn" is a sequentially assigned number that is unique for all time.(1) This installation ID is used in several places: it identifies the installation in the installation database and the online change log, and it also is used to name directories containing segments related to that particular installation. For ease of typing, every installation-specific directory has both the "MRxx.x-nnnn" form of its name and a short form, consisting of just the number ("nnnn"). Directories associated with hardcore installations(2) have an additional name, the hardcore system ID (of the form "NN-MM" with an optional suffix). The following directories(3) are important in the installation process; where necessary, their use is explained further below. All the installation directories are accessable (readable) by the entire Multics project, but modifications are permitted only for the Systems Integration staff. >spec>library This contains the tools (programs and exec_coms) used to perform installations. It has subdirectories called "source", "object", "executable", "exec_coms", and "info". >spec>database This contains the current installation database, along with all databases from previous releases, and any previous database segments from the current release. It also contains the value segment used to assign installation IDs and hardcore system IDs. _________________________________________________________________ (1) This differs from earlier practice, where installations were identified by a date and MCR number, neither of which were necessarily unique. (2) Note that hardcore and online installations are now prepared in the same hierarchies, using identical techniques. (3) Five new hierarchies under >spec are involved; their names have been chosen not to conflict with previous use. - 4 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C >spec>install>MRxx.x-nnnn This is an installation preparation directory: one is created for each distinct installation. It is used to hold the segments being installed while they are being checked, compiled, and bound together. The exec_com run to perform the installation itself is also created here. The contents of these directories are strictly temporary: once an installation has been performed, its preparation directory may be deleted once an appropriate interval has elapsed. Normally, these directories are kept for seven days, although they may be kept longer for complex installations in case problems arise. Installation directories must be deleted using the delete_installation.ec (dinst.ec) exec_com, as this is required to keep the database up to date. >spec>record>MRxx.x-nnnn This is an installation record directory: it contains the output from applying the compare_ascii command between the library versions of the segments being installed and the new versions.(1) This is the permanent record of each installation: it is kept until the current release cycle is completed, and then moved to the appropriate history directory. >spec>history>MRzz.z This directory contains all the record subdirectories from an earlier release. They are moved here when a release is completed (retaining all the original names). These are the records used by the DoDCSC to evaluate a Multics release; the segments in >spec>record apply only to the release currently being built. These directories are retained indefinitely on magnetic tape after being created, but there is no requirement that they be kept online continuously. TOOLS USED FOR INSTALLATIONS This section describes the tools, primarily implemented as exec_coms, used by the installer to make installations. This list includes both the tools used directly by the installer, and the more important of the subroutine exec_coms, or special-purpose commands, invoked by those tools. _________________________________________________________________ (1) Note that no global CPA directory is required (as in the past) because the history_comment mechanism provides even stronger protection against backing out previously installed changes. - 5 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C These tools cover all aspects of the installation process except copying in the segments to be installed, archiving and binding them, and handling special update_seg requests or options. The first is an inherently manual process, and the others are sufficiently complex and case-specific that it is better to have the installer perform those steps manually than to provide a tool that will only work part of the time. Those steps may be automated in the future if required. start_installation.ec (sinst.ec) This assigns an installation ID for the installation, and creates its installation and record directories, and records the initiation of the installation in the database. It takes a single argument, the installation type ("online" or "hardcore"), and prompts for a system ID if one is needed (including the previous one in the prompt). check_installation.ec (cinst.ec) This checks all source programs in an installation directory for validity, creates the compare_ascii output in the record directory, and compiles all the programs. It performs all the checks that can be performed mechanically, such as verification of pnotices, history comments, etc., and generates execption reports as output, which are left in the installation working directory. This will typically be run in an absentee job. compile.ec This compiles a single source program, saving the output in an error file. It understands how to apply the standard compilation options for all types of source programs in the libraries; special options can be specified as additional arguments. It is used by check_installation.ec; unlike the other "subroutine" exec_coms, it is also meant to be used by the installer to correct a failed compilation once the reason for failure has been corrected. If errors occur, a message is printed to user_output, and a segment called PROGRAM-NAME.$err is created (the "$err" suffix is a convention used by the installation tools to identify segments they create for later perusal). A compilation error is assumed to have occurred if the compiler sets its severity value or if it generates more than 30 characters of output. build_installation.ec (binst.ec) This exec_com is used to create the (temporary) exec_com that actually performs any particular installation, and the database record (listin) that describes it. It is run after the installation has been checked, compiled, and bound by the installer. It is at this time that the installer is prompted for the information that will go in the installation database record. The created exec_com is - 6 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C called "install.ec" and can be edited by the installer to ensure that the installation is correct. The database record is created in listin form and called "install.listin"; it, too, may be edited by the installer to ensure that the description is correct. The "install.ec" is created by the mcms_create_install_ec program, and the database record is creates by mcms_install_prompter, which prompts for the required information. delete_installation.ec (dinst.ec) This exec_com is used to delete an installation directory once it is no longer required, either because the installation has been completed successfully and shows no problems, or because the installation has been abandoned and will not be performed. The exec_com queries if the installation has not been completed, or if less than seven days have elapsed since its completion. remove_installation.ec (rinst.ec) Ths exec_com is used to cause an installation to be de_installed, and the de_installation to be recorded in the database. It works by de_installing the "$install.io" segment in the installation working directory, and updating the database if the installer agrees that the de_installation was successful. begin_installation_.ec finish_installation_.ec These two exec_coms are called only by the exec_com created by build_installation.ec, and do the work of creating an update_seg segment, updating the change log, and updating the installation database. Aside from calls to these two exec_coms, the "install.ec" segment contains only update_seg commands; these exec_coms exist only to make the contents of the "install.ec" easier to understand. mcms_create_install_ec This is the program (derived from cus, "create update_seg") that creates the "install.ec". It understands the organization of the system libraries and how to decide what segments go where. It is driven by the contents of the installation directory. mcms_install_prompter This is the program that prompts for installation information and creates the "install.listin" file. hcom_mdc_validate_ This is a validation routine used by history_comment and mcms_install_prompter to validate the change information supplied by the installer. Its interface conforms to the - 7 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C requirements in MTB-716. It understands the standard MDC-specific installation reasons such as MCRnnnn, PBFnnnn, and MECRnnnn. Because of the many different conventions for organizing bound object segments, the installer is left to update the archives and produce the bound segments manually. This includes fetching the archives from the system libraries, updating them with changed modules, adding and deleting modules in the archives, sorting the archives, and using the binder to produce the bound segments. This design leaves a wide assortment of segments in the installation working directory, since it includes the segments copied in by the installer, the segments created by compiling those programs (executables and listings), archives and bound segments, as well as all the exception reports and support exec_coms created by the installation tools. For small installations, this clutter will not be a problem, since the total number of segments will be small, but in large installations, it may be that some segments become lost in the shuffle. This problem can be alleviated if the installer pre-creates subdirectories for listings, executables and bound objects and links to the appropriate names so the segments will be created in the subdirectories rather than the installation directory itself. The tools are not concerned with whether they are operating on segments or links to segments, so long as they can all be reached from within the installation directory. - 8 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C STEP 1: PREPARING THE INSTALLATION DIRECTORY Each installation is prepared in a directory in the >spec>install hierarchy. This directory is created by the start_installation.ec (sinst.ec) exec_com, and contains all the segments modified by the installation, as well as the exec_coms and related segments created specifically to perform the installation. The start_installation exec_com performs the following steps: 1) Check the required argument (installation type) which must be one "hardcore" or "online". In both cases, the installation ID (MRxx.x-nnnn) is assigned automatically, but for hardcore installations, the installer is prompted for a hardcore system ID (of the form NN-MM, with an optional suffix); although the hardcore ID cannot be assigned automatically, the previous ID is included in the prompt. An "online" installation is one that can be installed immediately into the libraries. A "hardcore" installation is one that requires some form of special handling, such as a new system tape, a FNP reload, or a special session. 2) Get the next installation number from the installation ID value segment (see Installation Hierarchy, above), and concatenate it with the release number to form an "MRxx.x-nnnn" installation ID. The time and user who assigned the installation ID is also recorded in the value segment, as a debugging aid. 3) Create the >spec>install>MRxx.x-nnnn directory, with the added name "nnnn", and also the system ID (if supplied). The ACLs and IACLs for all created directories are copied from the containing directories. 4) Create the >spec>record>MRxx.x-nnnn directory, with appropriate added names. 5) Enter a record in the database for this installation ID, marking the installation as having begun. This ensures that all installations will have some record in the database, whether completed or not. 6) Inform the installer of the installation ID, and make that the current working directory. The installer is now ready to start copying the segments to be installed from the directory specified on the MSCR form. The installer copies the installation ID onto the paper MSCR form, and continues with the installation. - 9 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C The next step (performed manually by the installer) is to use the copy command to place all modified source modules, include files, and bindfiles into the installation directory. The installer then checks the contents of the directory against the MSCR, and if it appears correct, proceeds to the next step. Special Installations A "special" installation is any installation that requires special handling beyond simply installing the programs in the libraries. This includes coordinated online and hardcore changes, online changes that require a reboot and special session, etc. For these installations, some additional procedures(1) must be followed. If a special installation includes hardcore changes, it is treated as a hardcore installation, and given a hardcore system ID; otherwise, it just receives a normal installation ID. Even if the installation is described by several MSCRs, after running sinst.ec, the installer copies the modules specified on all the MSCRs into the installation working directory, and treats them as a single installation. This ensures that the changes (particularly to include files) will all be done from the same set of source, and that only one record of each change will appear in the database. If more than one MSCR specifies the same program, the installer must check to be sure that the two versions specified are in fact identical. To make a coordinated (hardcore and online) installation, the installer creates a new system tape, installs the changes in the libraries, and shuts down the system. He then brings the system back with the new system tape, and depending on whether it works, leaves the installation or removes it. It may sometimes be necessary to perform the actual installation in a separate special session, and then crashing the special session before trying the new hardcore, rather than just installing it and shutting down normally. These requirements (if any) will be described on the MSCR. Unlike normal hardcore installations, for which the libraries may be updated either before testing the new hardcore tape or after, the libraries must be updated for a coordinated installation before attempting to boot with the new hardcore tape, since it depends on the online changes included in the installation. _________________________________________________________________ (1) These procedures differ from current practice, in that coordinated installations are no longer split into two pieces, a hardcore and an online portion. - 10 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C Incomplete Installations If an installation is partially prepared, and then later found to be unnecessary, the installation and record directories must be deleted by running the delete_installation.ec (dinst.ec) exec_com, which also updates the database to indicate that the installation has been abandoned. This step can only be performed prior to completion of an installation. - 11 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C STEP 2: CHECKING THE INSTALLATION Once the installer verifies that the contents of the installation directory match what's specified on the MSCR, he runs the check_installation.ec (cinst.ec) exec_com. It performs the steps listed below to check and compile all the segments in the installation directory; if errors occur during any of these steps, or other important information is generated, it is recorded in the following segments (all with name containing "$err" or "$info", a convention used by the installation tools to identify the segments they create for later perusal; the "$" is used to force them to appear first in the output of "list -sort"): $err.archive contains all the error reports from the installation, and is automatically dprinted for the installer. Mail listing all the error reports is also sent to the installer. The error archive is created from all the individual error reports, which are deleted after being placed in the archive. $err.ERROR-TYPE contains the error reports from a particular step of the operation, such as the verification of history comments or checking whether all files needed for recompilation are present. These segments are all placed in the error archive and deleted at the end of check_installation.ec. PROGRAM-NAME.$err contains all the error message written during the compilation of PROGRAM-NAME, and is created by compile.ec. These segments are all placed in the error archive and deleted at the end of check_installation.ec. $info.INFO-TYPE contains information recorded during various steps that the installer may need to look at. These segments are always created, and their contents must be inspected manually. - 12 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C The following list enumerates all the steps of the installation checking performed by check_installation.ec: 1) If "$err.archive" already exists (tht is, is this installation has already been checked one or more times), empty it of everything but the "$err.recompile" component (since that is never generated except after the first time checking). 2) Check to ensure that all the segments being installed have the required history comments. This is done by the history_comment "install" operation (see MTB-716 for details). Any errors occurring in this process are recorded in the segment "$err.hcom". 3) Check all segments being installed to ensure that they have proper protection notices. This is done by running the display_pnotice tool and placing its output in the segment $info.pnotice; this must be inspected for correctness.(1) 4) Check all segments being installed to ensure that they have proper message documentation. This is done by running extract_message_doc and placing the output in the "$info.message_doc" segment. This can be inspected manually if required, although checking for proper error message documentation is properly the auditor's job. 5) Delete the current contents (if any) of the record directory in >spec>record, as they will be entirely replaced by the operations performed in this step. 6) Create a subdirectory in the installation directory called "ldd", into which the current library copies of all modules are fetched with library_fetch. These copies are used for generation of compare_ascii output. 7) For all segments present both in the installation directory and the subdirectory, create compare_ascii output files in the record directory. 8) For all new segments (not present in the "ldd" subdirectory), copy the entire segment into the record directory, with name formed by applying "==.new". _________________________________________________________________ (1) Actually, Gary Dixon claims that add_pnotice can do the checking automatically now, but I don't understand how that works. - 13 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C 9) If any include files are being installed, use library_fetch to fetch copies of all segments using those include files that are not already present in the installation directory. Create a list of these segments in "$err.recompile" (since it is an error to omit them from the MSCR except in unusual circumstances). These segments will thus automatically be included in the compilation step. NOTE: This step will generate "$err.recompile" only once, unless the segments fetched here are deleted manually. Running check_installation.ec again will not detect the missing segments, since they will already have been fetched into the installation directory. This step is actually performed by creating a subdirectory, called recompile, fetching into it all the segments identified by a peruse_crossref of those include files, deleting all the segments fetched that are also found in the installation directory, making the "$err.recompile" list, copying any remaining segments into the installation directory, and deleting the "recompile" subdirectory. Those segments are also copied into the "ldd" subdirectory, so they can be identified as recompilations. 10) Perform compare_ascii's between all the segments in the "ldd" subdirectory and the installation directory, placing the output in PROGRAM-NAME.cpa in the record directory. For all segments where the copy in the "ldd" subdirectory is identical with the one being installed, rename PROGRAM-NAME.cpa to PROGRAM-NAME.eq and truncate it to zero length. This is done to preserve the fact of a recompilation without generating many uninformative cpa outputs. 11) Delete any PROGRAM-NAME.$err segments in the installation directory; the compile.ec places an error message into these segment if any errors occur during compilation. 12) Compile all the programs in the installation directory. This is done by the compile.ec exec_com, which understands how to compile programs in all the languages that appear in the libraries, and applies the appropriate options. It also creates an error file for each program that failed recompilation. The compiler listings and object segments are placed in the installaiton directory, though (as noted above in the section on Installation Tools), they may be forced into a subdirectory ahead of time if the installer so desires. - 14 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C 13) Collect (into "$err.archive") all the error files present in the installation directory and dprint it for the installer. If the check is run in an absentee process, the absout segment is also dprinted for the installer (using -dupt, to ensure that it is printed even if the absentee terminated abnormally). Finally, if any errors occurred, mail the archive's table of contents to the installer to alert him of potential problems. At this point, all the work that can be done automatically. The remainder of the check/compile step is performed manually by the installer. The installer first reviews the error archive (if any) and the absout from the check, and corrects any errors noted therein. If the recompilation list ("$err.recompile") was created, the installation requires recompilation of some segments that were not listed on the MSCR. These segments are fetched and recompiled automatically by the tools; however, unless the MSCR explicitly describes these segments and explains why they were not included with the installation, it is in error and must be returned. After all the checks have been performed, the installer updates all the changed modules with the "hcom install" operation. This step "commits" the installation. If this step is omitted, build_installation.ec will detect it when it checks all the components of the archives being installed. Finally, all source and object archives associated with the installation are copied into the installation directory from the system libraries. These archives are updated with the modified modules; any new modules are added at this time, and modules being deleted are removed. After being updated, the archives are sorted by the installer, using the archive_sort command. All object archives are then bound using the bind command. Binding must occur without error or warning. At this point, the contents of the installation are complete and correct, and the actual installation exec_com may now be created. This is described in the next step. - 15 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C STEP 3: CREATING THE ACTUAL INSTALLATION Once the installation has been checked, the next step is to create the installation exec_com that will actually do the work of installing it. This is done by running build_installation.ec (binst.ec), which creates an exec_com in the installation directory, called "install.ec" It consists of a call to begin_installation_.ec, followed by a series of update_seg commands, followed by a call to finish_installation_.ec. Those two other exec_coms are used by all installations; their primary purpose is to check and update the database. Before creating the install.ec, build_installation.ec runs the installation prompter program to create the database record describing this installation. This database record is created in "listin" form, in a segment called "install.listin"; it contains all information that will go into the database except the update_seg change log. The installation prompter asks the installer for the submitter, auditor, approval reasons, and a description. The install.listin may be reviewed and edited before the installation is performed, allowing the description to be edited, for instance. After collecting the database record, build_installation.ec runs the create_update_seg command to write out the appropriate update seg commands into install.ec. These are the commands that specify library modifications. If a bound segment or standalone module exists already in the libraries, it is replaced; otherwise, the installer is prompted for a library name where the segment is to be added. Segment deletions must be entered manually by editing the install.ec after it is first created. Once the install.ec is created, it is run by the installer to ensure that there are no errors. After all the update_seg commands have been executed, the second ("finish") exec_com will ask whether to do the installation, and the the installer can proceed if there have been no errors. - 16 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C STEP 4: PERFORMING THE INSTALLATION The installation step is performed by running the install.ec, and answering "yes" when asked whether to go ahead with it, if no errors occurred before that point. This step will take a long time for a large installation, but the installer's only responsibility is to monitor it for errors. The real work of install.ec is performed by two support exec_coms, begin_installation_.ec and finish_installation_.ec, in between calls to which are all the update_seg commands to make the library modifications. First, the begin_installation_.ec checks that there is no installation already in progress (by a value in the value segment) and refuses to continue until the installer corrects the problem (if any). It then checks the directory to be sure that all the segments required for the installation are present (that is, that the previous steps have been followed), that the database is not too full, and so forth. It checks that install.listin is present, properly formatted, and contains one record whose ID matches the working dir. Having verified that the directory is consistent, it creates and initiates the update_seg "io" segment, which is always called "install.io" (deleting any old one if already present), and sets the update_seg log information to be the description from the database record. At this point, it sets the "installation in progress" flag, to guard against unexpected crashes and process terminations. Having run begin_installation_.ec, the install.ec then executes all the update_seg commands for modifying the libraries. If any errors occur at this time, the installer must answer "no" when the "Proceed?" question is asked. Finally, install.ec runs finish_installation_.ec, which asks whether to proceed with the installation. If the installer answers "no", the "installation in progress" flag is turned off, but nothing is updated. If the installer answers "yes", an update_seg "install" operation(1) is performed, and then the install.listin record is added to the installation database. After the "update_seg install" is performed, the installer is _________________________________________________________________ (1) To compensate for the failure of update_seg to handle logical volume full conditions, the exec_com places a seg_fault_error handler around this call. - 17 - 08/14/85 MULTICS ADMINISTRATIVE BULLETIN MAB-067-C again asked whether the installation worked, and if he answers "yes", the database is updated. Once all this is finished, the "installation in progress" flag is turned off. De-Installations If an installation must be de-installed because it doesn't work, the remove_installation.ec (rinst.ec) exec_com is used. This marks the database record for the installation as "de-installed", initiates the update_seg .io segment, and performs a de_install operation. If errors occur in the de-installation, the installer must take care of them manually; the database is always updated to record that the installation has been de-installed. A de-installed installation is re-installed by re-running the build_installation.ec to rebuild the "install.ec" exec_com; it will query the installer as to whether the installation really should be rebuilt for reinstallation. If the install.ec is simply re-run to reinstall the installation, the attempt will be refused, because begin_installation_.ec will detect the situation. - 18 -