Placement and activation are defined as follows in the default installation:
In menu mode | Using the INSTALL-UNITS SDF statement | |
Placement | ||
Define default Placement | Via the menu: Edit, option 4 (Install): “Global installation parameters”: Placement mode: 1 (default; preset) | PLACEMENT-MODE= *STD (default; preset) |
Overwrite existing files | Implicitly valid | REPLACE-OLD-FILES = *YES (default; preset) |
Do not force user ID | Implicitly valid | FORCE-LOCATION = *NO (default; preset) |
Activation | ||
Define default Activation | Via the menu: Edit, option 4 (Install): “Global installation parameters”: Activation preparation mode: 1 (default; preset) | ACTIVATION-MODE = *STD (default; preset) |
Placement – specifying the depot location of the files to be installed
The file attributes of an installation item that is to be created are taken from the delivery information.
IMON reads the supply components (release items) of the supply units to be installed from the distribution medium and stores them as installation items on the target system. The file attributes of an installation item are taken from the product movement file of the SOLIS2 delivery. The depot location, i.e. the path name of the installation item is affected by the definitions in SYSSII file and other user input.
The path name is formed as follows in the default installation:
:<catid>:$<userid>.<item-name>
where <catid> | refers to the catalog ID of the pubset on which the supply units will be installed. The catalog ID is taken from the target system specification (TARGET-SYSTEM=*PARAMETERS(...,PUBSET=<catid>). |
<userid> | refers to the installation ID that is specified in the following order:
|
| <item-name> | refers to the installation item. |
If no such file exists, it is created with the file attributes defined for the supply component.
Existing files of the same name are overwritten without further user input (default is REPLACE-OLD-FILES=*YES; for more information on the other setting options, see “Customer-specific installation”, "Placement and activation in the customer-specific installation "). The old file attributes are retained.
The following applies if a file cannot be overwritten because of a file lock, for example:
If the file is a syntax or message file (installation items of the type SDF and MES), the installation procedure tries to cancel the file lock. If this attempt is unsuccessful, the procedure is canceled and a message that requires an answer is output on the operating console. The operator’s response governs the subsequent processing:
“Repeat”
“Ignore”
The installation procedure attempts once again to cancel the file lock.
The installation is continued despite the file lock, i.e. the affected installation item is not installed.
“Abort”
The installation is aborted with an error.
The installation is canceled immediately if another installation item cannot be overwritten.
Handling password-protected files
The files remain password-protected. This is also the case for locked syntax and message files that are further processed automatically by IMON.
Handling libraries
Libraries (installation items of the type MOD, MAC, SRC, PL*, PLM, PLR and PLS) are handled as files in terms of the depot location and the installation item name.
An exception to this are libraries that are a subset of another library. These do not have to be installed under the defined path name, instead the elements they contain must be merged into the defined library. During the installation, these libraries are stored under the defined path in an intermediate step. The elements are then copied to the other library.
An alternative library that does not yet exist is configured in the target system with its elements and flagged as “mixed”. If this library already exists, versions of elements for which a new element exists in the supplied library are deleted. The new elements of the supplied library are then added once more to the existing library. The library updated in this manner is then flagged as “mixed”.
The installation is aborted if the library cannot be accessed (e.g. file lock).
Handling procedure files
Procedure files (installation items of the type DO or ENT) as handled in the same way as the other item types in the default installation.
Handling installation items of the type NST or %xx
Supply components that are not BS2000 files (e.g. publications, data volumes) are ignored by IMON.
Handling dummy items
Dummy items (installation items of the type *DF with full path names or of the type *DP with partial path names) are part of the delivery information.
They are generated during the installation or exist already under the installation ID. While dummy items are entered in the SCI with their logical names, they are not assigned a path name automatically.
In the following cases, a path name is entered during the installation process, where the correction version of the dummy item must always be <= the correction version of the installation item:
The delivery is a first-time delivery:
The following applies if the dummy item is a SYSREP file: If the relevant release unit is assigned an RMS file and a default path name is defined in this RMS file, the first path name found in the RMS file is entered in the SCI. The path name of the generated loader is entered once RMS processing is concluded.
If a default path name is defined in the product movement file, a new path name is formed from the catalog ID of the target system and the default path name. The default system ID is used if the default path name does not contain a user ID.
With this type of processing, path names that were transferred from RMS files are also overwritten by dummy items of SYSREP files. The path name of the generated loader is entered however once RMS processing is concluded.
The delivery is a correction delivery:
The SCI does not as yet contain a path name for the dummy item:
The following applies if the dummy item is a SYSREP file: If the relevant release unit is assigned an RMS file and a default path name is defined in this RMS file, the first path name found in the RMS file is entered in the SCI.
The path name of the generated loader is entered once RMS processing is concluded.
The path names are not updated if a default path name is defined in the product movement file.
The SCI already contains a path name for the dummy item:
The path name in the SCI is retained regardless of whether or not the dummy item is contained in the correction delivery.
Handling SYSSII files
The SYSSII files are first transferred to the target system, merged with the PLAM library SOLLIB.IMON.SYSSII under the work file ID and then deleted again.
You can suppress transfer of the SYSSII files to the target system if you use an IMON parameter file (see section "IMON parameter files").
Central repositories for certain files
When you use an IMON parameter file you can specify central storage locations for documentation files and subsystem declarations (see section "IMON parameter files" "IMON parameter files ").
Activation – preparing for activation of the software to be installed
Syntax files
IMON enters syntax files in the SDF parameter file of the target pubset without the need for further user input, IMON processing the SDF parameter file with the default names $TSOS.SYSPAR.SDF.
If another SDF parameter file is activated in the target system, IMON first saves a copy under the default name and then processes the parameter file with the default name.
The next system start is entered as the activation time (corresponds to MODIFY-SDF-PARAMETERS with SCOPE=*NEXT-SESSION). IMON obtains the name of the subsystem and the syntax file type from the product movement file.
If the DSSM catalog contains a definition for the syntax file of the subsystem, IMON does not perform activation but the syntax file is automatically activated by DSSM.
Message files
Message files (installation items of the type MES) can be activated at different times. The activation time is queried by IMON.
Message files of subsystems that were loaded with or before DSSM are activated via the Class 2 system parameter without the need for further user input:
The BS2CP message file SYSMES.BS2CP.170 (in BS2000 V8.0) corresponds to the default value of the MSGFIL01 system parameter. It is simply installed. If it is already activated, it is first deactivated, installed, and then reactivated.
The message files of the release units BCAM, CALENDAR, DSSM, FITC, MIP, and SRPMNUC are merged in the global message file that is defined in the MSGFIL02 system parameter (default is $TSOS.SYMES.EKP.01). If the global message file is
already activated, it is first deactivated, extended, and then reactivated.
All other message files are entered by IMON in the MIP parameter file of the target pubset.
The next system start is entered as the activation time (corresponding to the command MODIFY-MIP-PARAMETERS with SCOPE=*NEXT-SESSION).
Note on reinstallation of syntax and message files which have already been activated
In the course of reinstallation IMON deactivates the file concerned, renames the file <file>.nnn (suffix nnn = 001 through 999), and reactivates the renamed file. Subsequently the new component is installed under its standard name. When the next startup takes place, the syntax and message files with a suffix are automatically deleted.
Subsystem
IMON modifies the static subsystem catalog in preparation for activation of a subsystem (installation item SSC/SSD). To do this, IMON ascertains the path name of the static subsystem catalog (default is $TSOS.SYS.SSD.CAT.X on the target pubset) and requests its confirmation. In the case of subsystems for which a remove option exists, you can specify whether an earlier version of the subsystem should be removed prior to the installation (default: earlier version is removed).
A backup copy is created under the name <subsystem-catalog>.<time-stamp> before the subsystem catalog is modified.
IMON also generates a subsystem catalog source file under the name <subsystem-catalog>.SRC. It can be used as a basis from which the regenerate the static subsystem catalog in its default format at any time (e.g. if problems occur after the subsystem settings are changed).
Once the subsystem catalog is generated, IMON searches for a procedure with the name <subsystem-catalog>.USER-MODIF. If this procedure exists, it is started using the CALL-PROCEDURE command. You can use this procedure to define repeated installation activities.
RMS files
In the case of an installation where no user input is required and the delivery was not first parked, system corrections are transferred to the RMS depot. IMON generates the rep loader. IMON enters the logical names and the path names generated by RMS in the SCI.
POSIX satellites
The POSIX items identify the commands that IMON must provide to the /START-POSIX-INSTALLATION program. This program is called at POSIX subsystem start.
For each POSIX item, IMON writes an “add product” command in the file “$SYSROOT.IMON.ACTIONS.ADD”. Any old version of the same product must be removed from the POSIX system. Therefore, before adding a new one, IMON retrieves from the POSIX configuration file ($SYSROOT.POSIX-CONFIGURATION) the old version(s) of this product that must be removed. The associated “remove” commands are stored in “$SYSROOT.IMON.ACTIONS.REM”.
The following must be borne in mind before restarting the POSIX subsystem:
The POSIX installation program can access the installation units registered in the SCI only if these are in the LOCKED=NO status, i.e. after the installation units have been activated.
If activation has not yet taken place, access is not possible.
In this case the $SYSROOT.IMON.ACTIONS.ADD and $SYSROOT.IMON.ACTIONS.REM files must be saved under another name before the POSIX subsystem is restarted.
Procedures
Procedures (type DO and ENT) that are to run after first querying the installation parameters, are started automatically by SOLIS without the need for further user input in the case of installation on the home pubset. Batch procedures (type ENT) are also deleted automatically once they run.
In the case of installation on an imported pubset, these procedures must be started manually as part of postprocessing. Procedures of the type DO are started using the ENTER-PROCEDURE or CALL-PROCEDURE command, procedures of the type ENT are started using the ENTER-JOB command.
In both cases the names of the procedures to be started manually are output to SYSOUT when the Installation procedure is generated or to the console when the installation procedure is running (see also the console log).