If a non-existent serverdb is specified for the call of CONTROL (i.e., no parameter file with the database name exists), the following screen is displayed:
Fig.: Installation Screen 1
Serverdb name is taken from the call option -d. SERVERNODE is the computer name within the network. If the computer has no net card, the SERVERNODE name is "local".
CONTROL knows four special users:
1. The CONTROL USER has the right to perform all functions of CONTROL. The CONTROL USER can connect several times to his serverdb, for example, to retrieve information about operating parameters while performing long-time backups.
2. The SYSDBA USER is the system administrator. This user owns the system tables and has the privilege to create other administrators. This user is especially needed for the installation.
3. The user DOMAIN is the owner of the catalog tables. This user is also needed for the installation.
4. The user OPERATOR is a database operator with restricted rights. This user may only perform save functions.
In the Installation Screen, name and password are defined for the users CONTROL and SYSDBA, whereas the password is only defined for the user DOMAIN. First, the user OPERATOR has the password OPERATOR. It can be modified using the Configuration / Alter Parameters / Sysuser menu item (see Section 10.1.6).
The names and passwords have a maximum length of 18 characters. Passwords must be entered twice to recognize input errors. When the specifications are complete, the screen must be acknowleged using
either the 
key or Ok button, and a screen for the definition of the database parameters is displayed.
Fig.: Installation Screen 2
All parameters are set to default values. In a window above the functional buttons, a description is output for the parameter on which the cursor is placed. The parameters can be changed by overwriting them.
EXPLAIN can be used to display the computation formula of the numeric parameters and their dependencies of the other parameters. To obtain the second parameter screen, use the Next
button or the 
key.
Configuration Parameters
MAXSERVERDB
This parameter defines the maximum number of serverdbs in a configuration. If a stand-alone serverdb is to be configured, specify 1 here. For a distributed configuration, specify the maximum number of serverdbs involved.
MAXBACKUPDEVS
Saving and restoring the database and log can be accelerated with several tape devices used in parallel. This parameter defines the maximum number of parallel tape devices.
MAXSERVERTASKS
Servertasks in a stand-alone configuration accelerate the save and restore operations.
MAXUSERTASKS
This parameter restricts the number of simultaneously active user sessions on this serverdb.
MAXCPU
This parameter assigns the serverdb a number of CPUs. For multi-processor computers, the number of CPUs utilized by a database can be thus defined and restricted. For single-processor computers, MAXCPU must be set to 1.
DATA_CACHE_PAGES
This parameter defines the size of the data cache. The specification is made in 4 KB pages.
PROC_DATA_PAGES
This parameter defines the total size of the proc data cache. The specification is made in 4 KB pages.
PROC_CODE_PAGES
This parameter defines the size of the dbproc code cache. The specification is made in 4 KB pages.
TEMP_CACHE_PAGES
This parameter defines the size of the temp cache. The specification is made in 4 KB pages.
CATALOG_CACHE_PAGES
This parameter defines the size of the catalog cache. The specification is made in 4 KB pages.
LOG_QUEUE_PAGES
This parameter defines the size of the buffer for the write processes of the log. The specification is made in 4 KB pages.
LOG_CACHE_PAGES
This parameter defines the window size for the last log written. The specification is made in 4 KB pages.
CONV_CACHE_PAGES
This parameter defines the size of the converter cache. The specification is made in 4 KB pages.
Here you can continue Installing the Serverdb from an Existing Data Backup using the Restore button. How this is done, is described in the next section.
Fig.: Installation Screen 3
MAXLOCKS
This parameter defines the maximum size of the lock list in which row and table locks held and requested are recorded for all users.
PNOPOOLSIZE
This parameter defines the number of entries for the list of free data pages. This list is administered in main memory.
RUNDIRECTORY
The log files of some ADABAS tools are stored in the specified directory.
OPMSG1
To inform about exceptional situations, ADABAS displays messages. Priority 1 messages are displayed either on the specified terminal or output to the specified file.
OPMSG2
To inform about exceptional situations, ADABAS displays messages. Priority 2 messages are displayed either on the specified terminal or output to the specified file.
DIAGSIZE
This parameter defines the size from which the kernel diagnose file will be overwritten. The default directory of the kernel diagnose file which is called knldiag is the rundirectory. The specification is made in 4 KB pages.
TRACESIZE
This parameter defines the size from which the kernel trace file will be overwritten. The default directory of the kernel trace which is called knltrace is the rundirectory. The specification is made in 4 KB pages.
DEFAULT CODE
The internal code defined here is used to store CHAR values. For open systems, this is usually the ASCII code.
DATE TIME FORMAT
This parameter is used to define the default representation of DATE and TIME values.
In the next screen, the timeout values, the LOG, and the DEVSPACEs must be specified. And it must be defined whether the serverdb is to be installed as a remote serverdb; i.e., whether it will operate with other serverdbs in a distributed database configuration.
Fig.: Installation Screen 4
SESSION TIMEOUT
This parameter defines the maximum time of inactivity allowed for all database sessions. The specification is made in seconds. If no SQL statement is issued within the specified time, the database session concerned is implicitly terminated with ROLLBACK WORK RELEASE.
LOCK TIMEOUT
This parameter defines the maximum time of inactivity allowed for all database sessions holding locks. The specification is made in seconds. If no SQL statement is issued within the specified time and if there are other users waiting for the lock to be released, the transaction concerned is implicitly rolled back with ROLLBACK WORK.
REQUEST TIMEOUT
This parameter restricts the waiting time for a lock release for all database sessions. The specification is made in seconds. If a lock request cannot be satisfied within the time thus defined, a message is returned to the waiting database session.
DEVSPACES
The type (raw device or file), the size (in 4 KB pages), and a path name are specified here for each devspace required for a configuration. 0 specified as size for raw devices has the effect that the devspace size is implicitly determined.
LOG MODE
Here, you enter the log mode selected for this serverdb. The log modes "normal", "dual", "single", or "demo" are provided.
| NORMAL: | This log mode is the recommended default mode. It requires one archive log devspace in addition to the transaction log. The archive log must be located on disks different from all the other devspaces (system devspace, transaction log devspace, data devspaces). A minimum configuration for this log mode therefore requires at least two (physical) disks. Recovery operations after a device failure depend on which of the two devspaces was affected by the failure. |
| DUAL: | For a still higher degree of data protection, the archive log can be mirrored. The minimum configuration comprises at least three disks: one for the transaction log, one for the archive log, and one for the mirrored archive log. This configuration has the following advantages: a failure of the transaction log devspace or of one of the archive log devspaces does not interrupt database operation, and once the defective devspace has been repaired, it can be updated while the database is operational. |
| SINGLE: | In this configuration, the archive log and the transaction log build a common log devspace. This is useful for ADABAS configurations with one disk. The log should be saved in defined periods of time. If a device failure occurs, the contents of the database and of the log devspace are destroyed. The database can then be restored by using a complete backup and further log backups (Backup / Restore / Data, Backup / Restore / Log). In such a case, only the contents of the log not yet saved and open transactions cannot be recovered. |
| A sufficient degree of reliability will also be obtained for productive operation in log mode SINGLE when RAID-5 systems are used as disk peripherals. Such a configuration is not appropriate for high
load systems, because log devspaces on special disks allow for a considerably larger I/O rate than on RAID-5 systems. Log mode SINGLE can also be used for high-load configurations in conjunction with RAID-1 systems (= mirrored log devspaces). |
|
| DEMO: | In this configuration, there is no archive log, and only the transaction log is written. In contrast to log mode SINGLE, the transaction log is cyclically overwritten to prevent it from being filled completely. Therefore, the log cannot be saved. |
LOG SEGMENT SIZE
Here, you define the size of a log segment. The specification is made in 4 KB pages.
NO OF ARCHIVE LOG DEVSPACES
Here, you define the number of archive log devspaces.
NO OF DATA DEVSPACES
Here, you define the number of data devspaces.
MIRRORED
Here, you determine whether or not the system devspace and the data devspaces are to be mirrored.
DISTRIBUTED CONFIGURATION
This parameter defines whether the serverdb is to become part of a distributed configuration or not.
FIRST SERVERDB
This parameter defines a distributed configuration which consists of one serverdb only, or it defines a stand-alone serverdb as the first serverdb of a distributed configuration to be constructed. If this is not the first serverdb in a distributed configuration; i.e., "n" was specified, a screen is displayed when paging down to enter the SPONSOR SERVERDB.
If "y" is entered for DISTRIBUTION and "n" for FIRST SERVERDB, at least one other serverdb has been started that is to run in the distributed database together with the serverdb to be installed now. To establish the connection, fill in the following screen:
Fig.: Installation Screen 5
As SPONSOR SERVERDB, any serverdb can be selected from the set of already installed, distributed serverdbs. It must be ensured that the parameter MAXDISTRIBSERVER is set to a value that corresponds at least to the maximum number of distributed serverdbs.
Depending on the specification of the number of DEVSPACEs ("no of archive logs" and "no of datadevspaces"), the following screen is initialized with the corresponding number of lines. If MIRRORED was marked with Y, double the number of lines appears for the system and data devspaces. In total, 64 DATADEVSPACEs and 7 ARCHIVE LOGs are supported.
An R in the column TYPE indicates a raw device, an F indicates a file, and an L indicates a symbolic link. For the device type F, CONTROL itself creates the specified directories if they do not exist.
The SIZE is specified in 4KB pages. For raw devices with the size specification 0, the total size of the device is automatically determined. The size of the system devspace cannot be specified, because it is dynamically adapted by the system to the number of data pages used.
Fig.: Installation Screen 6
When this screen has been filled completely and confirmed with "ok", the actual installation begins.
CONTROL allows for a step-by-step installation or an uninterrupted installation without explicit confirmation. For the first installation, it is recommended to choose the automatic variant without confirmation. The step-by-step installation is useful if only a partial installation is to be performed first. This is described in Section Stepwise Serverdb Installation .
Fig.: Installation Start Screen
After selecting the Install button, the automatic installation begins without user dialog. The progress of the installation can be seen from the position of the arrow and the status message ACTIVE. If an installation step was terminated successfully, the status "ok" is displayed and the next action becomes ACTIVE.
Fig.: Status Screen 1
If the status changes to ERROR, an error occurred. Select the Protocol button to display the installation log file. CANCEL can be used to return to Installation Screen 6. Use Next and Prev to alternate between the Installation Screens to adapt the parameters to the error situation.
If the installation was aborted completely, it can be repeated at a later point in time. For the next call of CONTROL, the message "inst not complete" is displayed in the Main Screen. "configuration / Install Serverdb" (see section 10.4) can be used to start a new installation for which the values previously entered are displayed.
When the installation has reached the point "load system tables" in the Status Screen 1, the following screen is displayed to output more detailed information about the installation procedure:
Fig.: Status Screen 2
If an error occurs, the installation is aborted and the status ERROR appears behind the action just performed. Select the Protocol button to display the LOAD log file.
If all actions were performed free of errors, all lines end with "ok" and the display changes to the CONTROL Main Screen.