During deinstallation all installed or parked supply units that are not needed any more are removed. The deinstallation procedure consists of the following actions:
activated files are deactivated, if necessary
installed files are deleted, if necessary
entries in the IMON-SCI are removed
If the original state that existed before the installation is to be restored and a supply unit is to be deinstalled, then this can be accomplished under certain circumstances using the Undo function (see section "Undo - undoing an installation").
The deinstallation process is triggered using the IMON function “Edit: Deinstall” or the DEINSTALL-SUPPLY-UNITS statement. The process is divided into two phases:
| deinstallation preparation actual deinstallation process |
Deinstallation preparation
In this phase IMON checks which objects are affected by the deinstallation and if the deinstallation can be performed without error:
Analysis of the target system and of the SCI to determine which files are affected:
IMON first creates a list of all affected files and then checks the target system (to see if the files exist) and the SCI (assignments to other installation units that will remain installed in the system)
Note
The target system to be processed for the deinstallation (i.e. the home pubset of the target system) is determined using the catalog ID of the currently open SCIs.
Analysis of file access:
The access rights of the files to be deinstalled are checked and changed with the MODIFY-FILE-ATTRIBUTES command, if necessary.
Subsystems check:
If a supply unit to be deinstalled corresponds to one or more subsystems, then IMON checks if the affected subsystems are deactivated.
Test mode
The deinstallation can also be called in the Test mode (operand EXECUTION= *NO in the DEINSTALL-SUPPLY-UNITS statement or Direct Execution = 2 (No) in the menu mode). In this case only the analysis is performed and the results are recorded.
Actual deinstallation procedure
In this phase actual deinstallation is performed with the following actions:
deactivation of files
deletion of files
cleanup of the SCI
Deactivating files
Some special files that were activated during installation (e.g. syntax files, message files), must be deactivated in the same manner for deinstallation:
Syntax files (SDF item type)
The entries for each syntax file to be deinstalled are removed from the following files:
Default SDF parameter file of the target system
SDF parameter file that is entered in the SCI for the syntax file
An activated syntax file is deactivated directly.
Message files (MES item type)
The entries for each message file to be deinstalled are removed from the following files:
Default MIP parameter file of the target system
MIP parameter file that is entered in the SCI for the syntax file
An activated message file is deactivated directly.
Subsystem declarations (SSC and SSD item types)
Subsystem declarations located in SYSSSC files to be deinstalled are removed from the static subsystem catalog (the default catalog and the subsystem catalog entered in the SCI).
The corresponding source files of the subsystem catalog (<dssm catalog>.SRC) are also updated.
The dynamic subsystem catalog is updated accordingly for the current system during deinstallation, and the affected subsystems are removed dynamically (REMOVE-SUBSYSTEM command). The affected subsystem must be stopped before this is done (STOP-SUBSYSTEM command).
POSIX files (item types *PS / *NP)
Deinstallation of installed POSIX items is executed before the removal of the files, synchronously in the processing of the “Edit: Deinstall” or the DEINSTALL-SUPPLY-UNITS statement. If POSIX is not present, the “Edit: Deinstall” or the DEINSTALL-SUPPLY-UNITS statement is aborted. Then the operator is asked at the console to choose among abort or continue the processing.
Deleting files
All files that belong only to the selected supply units are deleted in the target system.
Cleaning up the SCI
All affected supply units are removed from the SCI together with the installation units they contain (when they are not also assigned to another installed supply unit).
Consistency and error handling
To ensure consistent deinstallation, the deinstallation procedure is performed in several steps. Each step of the deinstallation must execute successfully before the next step can be started.
If an error arises during a step of the deinstallation, an error handling routine is initiated:
In interactive mode, processing is stopped and a message requiring confirmation and containing information on how to deal with the error is output. The deinstallation is aborted, continued while ignoring the error or continued in the Test mode depending on the response from the user.
In batch mode, execution of the DEINSTALL-SUPPLY-UNITS statement is continued in the Test mode when an error arises.
Restrictions
The following actions performed during installation are not undone during deinstallation:
Library elements that were merged with alternative libraries during installation are not removed during deinstallation.
The RMS delivery quantities are not cleaned from the RMS depot.
For parked supply units, the entries are reset in the SCI to their original status. The parked files are erased using the clean-up procedure generated during parking (see the PARK-UNITS statement, "PARK-UNITS Park Software "). No saving of these erased file is available (operand FILE-SAVING is ignored).
Message files that were merged into the default system message file (SYSMES.EKP.01) are not removed during deinstallation.