Configuration parameters are required for each database in an Adabas Extended Operation (AEO) environment. These configuration parameters tell AEO about special criteria which have been defined for the database by the DBA, and therefore about how AEO should react when certain database events occur.
The configuration parameters are stored in configuration files. One configuration file, named ADABAS.INI, contains configuration parameters that apply to all databases in the Adabas environment on that node. In addition, for each database, there must be a file DBnnn.INI, where nnn is the database number.
The files ADABAS.INI and DBnnn.INI contain definitions such as container assignments, nucleus parameters and control parameters for AEO. They are ASCII files, so they can be edited with a standard text editor. However, a text editor does not guarantee that the configuration files are syntactically correct. In order to maintain the AEO-specific entries in the configuration files, we recommend that you use the administration command adaini.
Each configuration file is divided into topics, with the following syntax:
[topic name] # start of topic "topic name" item1 name = item1 value # name and value of item 1 item2 name = item2 value # name and value of item 2 .... [topic name-END] # end of topic
Each topic contains item definitions and/or subtopics. There can be several nesting levels, but usually there are not more than 2 levels, i.e. the main topic level and one subtopic level.
Topic names, item names and values are case sensitive. Comment lines start with the character "#".
Empty lines are ignored. White space, i.e. blanks and tabs, surrounding topic names, item names and values are also ignored. If a value contains white space, it must be enclosed by single or double quote delimiters. Delimiters that occur within a value must be typed twice.
Note:
You cannot use environment variables as values within the
configuration file. They must be substituted by their explicit values.
The following is an example of a configuration file with two nesting levels and one comment line:
[topic1 name] # start of topic on nesting level 1
item1 name = item1 value # name and value of item 1
# Start of topic2 # comment line
[topic2 name] # start of topic on nesting level 2
item2 name = item2 value # name and value of item 2
[topic2 name-END] # end of topic 2
[topic1 name-END] # end of topic 1
The configuration file ADABAS.INI contains information that applies to all databases in an AEO environment. If there is a file DBnnn.INI for a particular database, the information in that file overrides the information in the ADABAS.INI file. ADABAS.INI can be modified with a standard text editor or with the administration command adaini. This can also verify the topic NUCPARMS. See the adaini online help for the utility syntax.
ADABAS.INI contains the following information:
Database-independent information, e.g. default nucleus parameters and environment information for new databases being created. Also general information such as the location of ADABAS.LOG (log file for all databases on the local node), what to do if a report utility (adarep, adafin, adapri, adaclp, adaplp, adaerr, adatst) or display function (adaopr/adadbm display=...) is run.
Basic database definitions, e.g. location of the individual DBnnn.INI files and the database ID.
On Linux and Windows platforms, ADABAS.INI must be in the subdirectory etc of the directory that is pointed to by the environment variable ADADATADIR. If there is no ADABAS.INI file in this directory, AEO is automatically disabled and only the standard Adabas functionality is available.
ADABAS.INI is divided into sections, with one topic per section. Each section of ADABAS.INI starts with a line containing the name of the topic enclosed in square brackets, using the syntax [topic-name]. The topics relevant to AEO are:
DB_DEFAULTS (with various subtopics)
DB_LIST (with one subtopic per DBID)
MISCELLANEOUS
NODE_PARAMETER, with the subtopics
ALERT
ANALYSER
ARCHIVE_LOGFILE
LOGGING
Important:
The item ACTION in the topic NODE_PARAMETER, subtopic
ANALYSER must be set to 'yes' in order to activate AEO. Please refer to the
administration command adaini in
the section Administration Commands for further
information.
These topics are described in the following sections.
The topic DB_DEFAULTS contains default definitions used by ADAFRM or by adainst to create DBnnn.INI. Its contents are copied to DBnnn.INI without the enclosing lines [DB_DEFAULTS] and [DB_DEFAULTS-END]. For further information, refer to the section DBnnn.INI later in this section.
# configuration # recommended values [DB_DEFAULTS] ... [NUCPARMS] ... [NUCPARMS-END] ... [DB_PARAMETER] ... [DB_PARAMETER-END] ... [ENVIRONMENT] ... [ENVIRONMENT-END] ... [DB_DEFAULTS-END]
The items in the topic NUCPARMS can be verified by the administration command adaini with the VER parameter. Potentially unique abbreviations will then be automatically replaced by the correct item names (e.g. the abbreviation LOG will be automatically corrected to LOGGING).
In this topic, default environment variables can be defined. If the variable is set in the shell environment, the nucleus will take the value, otherwise the setting of the ENVIRONMENT topic will be used.
The topic DB_LIST lists the numbers and names of the available databases, as well as the name and location of the associated DBnnn.INI file. The details for each database are given in a separate subtopic DBID_<dbid> within the topic DB_LIST.
# configuration # recommended values
[DB_LIST]
[DBID_<dbid>] PC platforms:
INI_FILE = <configuration file name %ADADATADIR%\db<dbid>\DB<dbid>.INI
for this database> Linux:
$ADADATADIR/db<dbid>/DB<dbid>.INI
NAME = <database name>
[DBID_<dbid>-END]
[DB_LIST-END]
Note:
You cannot use environment variables as parameters in the
configuration file. You must therefore substitute the ADADATADIR environment
variable by its full expanded name in the INI_FILE item.
The topic MISCELLANEOUS contains database-independent information for this node. The item NODE_NAME is used for the logging that is activated by the subtopic LOGGING of the topic NODE_PARAMETERS (see later in this section).
On Linux platforms you can use the Linux command "uname -n" to get the system node name.
The syntax for the topic MISCELLANEOUS is as follows:
# configuration # recommended values [MISCELLANEOUS] NODE_NAME = <node name> [MISCELLANEOUS-END]
The topic NODE_PARAMETER contains AEO definitions for all databases on this node.
# configuration # recommended values
[NODE_PARAMETER]
[ALERT]
ACTION = <yes/no>
ACTION_ROUTINE = <action routine> ada_alrt
MINIMUM = <minimum severity required E
to call the action>
[ALERT-END]
[NODE_PARAMETER-END]
The recommended action routine is ada_alrt, which has the following parameters:
| Parameter | Description |
|---|---|
| 1 | utility name |
| 2 | process ID |
| 3 | DBID |
| 4 | user login name |
| 5 | node name |
| 6 | severity |
| 7 | message header key |
| 8 | message header |
| 9 | message text |
The ALERT action is used to inform the DBA (and possibly other users) when an Adabas event occurs, for example, Adabas could "mail" all messages with severity E (error) and F (fatal) automatically to the DBA.
The subtopic ALERT of the topic NODE_PARAMETER defines the Adabas alert action. If the ALERT action is enabled (ACTION=yes), the severity of each Adabas message is checked, and if it is greater than or equal to the defined MINIMUM severity, the action routine specified by ACTION_ROUTINE is started asynchronously. The severity priority is: I (information) < W (warning) < E (error) < F (fatal). Thus, if MINIMUM=E, only messages with severity E and F will call the ALERT action.
The list of recipients of the alert is determined by the contents of the environment variable ADA_ALRT_LIST, which is a concatenation of one or more user specifications that are separated by blanks. The user specifications depend on the platform. On Windows, it is the name of a computer, e.g. pcABC1 if the machine is in the same domain or /DOMAIN:pcABC1 if the computer is in another domain. On Linux, it is the user name or an e-mail address.
set ADA_ALRT_LIST ="pcABC1 /DOM-HQ:pcABC2" (for Windows) setenv ADA_ALRT_LIST "abc user.xyz@myCompany.com" (for C shell)
The subtopic ANALYSER of the topic NODE_PARAMETER enables/disables the AEO analyser. If the analyser is disabled, all Adabas actions, including LOGGING and ALERT, are automatically disabled.
Note:
This is the global switch which enables/disables AEO.
# configuration # recommended values
[NODE_PARAMETER]
[ANALYSER]
ACTION = <yes/no>
[ANALYSER-END]
[NODE_PARAMETER-END]
 |
Warning: If "ACTION=no" is set, all other AEO settings will be ignored, and AEO will be disabled. |
# configuration # recommended values
[NODE_PARAMETER]
[ARCHIVE_LOGFILE]
ACTION = <yes/no>
ACTION_ROUTINE = <action routine> ada_svlg
MAXIMUM = <maximum number of 7
archive generations>
[ARCHIVE_LOGFILE-END]
[NODE_PARAMETER-END]
The recommended action routine is ada_svlg, which has no parameters.
Each logging message is appended to the end of the Adabas log file. To prevent uncontrolled growth of this file, you can submit the command specified by the item ACTION_ROUTINE with an external scheduler every day. This routine reads the item ACTION and exits without doing anything if ACTION=no. If ACTION=yes and MAXIMUM=0, the log file is deleted without archiving. If ACTION=yes and MAXIMUM is greater than 0 and less than 100, MAXIMUM number of generations of log files (one generation per execution of ada_svlg) are archived. This is done by appending a generation number in the range 1 ... MAXIMUM for PC platforms or 01 ... MAXIMUM for Linux to the log file name, for example, ADABAS.LOG.1 for PC platforms or ADABAS.LOG.01 for Linux. Log files with a generation equal to MAXIMUM are erased during the next run of ada_svlg.
Note:
ada_svlg cannot run while the log file is in use by other
tools, for example, adalog -t.
# configuration # recommended values
[NODE_PARAMETER]
[LOGGING]
ACTION = <yes/no>
FILTER_MESSAGES_WITHOUT_HEADER = <yes/no>
FILTER_REPORT_UTILITIES = <yes/no> PC platforms:
LOG_FILE = <log file name> %ADADATADIR%\etc\ADABAS.LOG
Linux:
$ADADATADIR/etc/ADABAS.LOG
[LOGGING-END]
[NODE_PARAMETER-END]
Note:
You cannot use environment variables as parameters in the
configuration file. You must therefore substitute the ADADATADIR environment
variable by an explicit path name in the INI_FILE item.
The subtopic LOGGING of the topic NODE_PARAMETER defines parameters for the logging of Adabas messages. Adabas messages (normally written to standard output exclusively) are analyzed and appended to the AEO log file if the associated logging filter conditions are true. Additionally, AEO logs new Adabas messages (that are not written to standard output), which contain special event and action information.
The name of the log file is given by the item LOG_FILE.
The item ACTION enables/disables AEO logging for all databases on this node. If logging is enabled, each Adabas utility appends its logging information to the sequential file defined with item LOG_FILE. The writing of logging messages is synchronized using an Adabas semaphore. The logging filter recognizes two conditions:
Messages without a header are ignored (i.e. not logged), if:
FILTER_MESSAGES_WITHOUT_HEADER
= yes
Messages from Adabas report utilities are ignored (i.e. not
logged), if:
FILTER_REPORT_UTILITIES = yes
The Adabas report utilities are: adaclp, adafin, adaplp, adapri, adarep, adatst.
Each entry in the log file has the following format:
<process id> <yymmddhhmmss> <dbid>
<user ID> <Adabas message>
where yymmdd and hhmmss are the
current date and time, respectively.
The items in the log file entry are separated by blanks.
Note:
If an Adabas log message contains 0 as database ID, the
database ID has not yet been determined when the message was created.
For each database that is to be administered by AEO, there must be a DBnnn.INI file, where nnn is the database number. The DBnnn.INI file contains information that applies to the database number nnn, and overrides the information in the ADABAS.INI file.
If there is no DBnnn.INI file for a database, AEO does not work with the database, so only the standard Adabas functionality can be used. Also, there must be an INI_FILE entry in the DB_LIST section of ADABAS.INI for the database nnn.
DBnnn.INI contains the following:
Database information, e.g. container assignments, nucleus parameters
User definitions which describe the permissions to run actions
The location of the DBnnn.INI files is defined by the item INI_FILE in the DB_LIST topic of ADABAS.INI.
When creating a new database with the utility ADAFRM, a DBnnn.INI file is generated. The utility adaini can be used to modify the contents of DBnnn.INI and also to verify the topic NUCPARMS.
DBnnn.INI is divided into sections, with one topic per section. Each section starts with a line containing the name of the topic enclosed in square brackets, using the syntax [topic-name]. The available topics are:
CONTAINER
DB_PARAMETER, with the subtopics
ACTION_DBA
ADANUC_STARTED
ADANUC_TERMINATED
AUDIT_TRAIL
DELETE_CHECKPOINTS
OFFLINE_CHECKPOINTS
RECOVER_LOST_BLOCKS
REORDER_FILE
SAVE_DB
SSX_CONFIGURATION
TERMINATE_ADANUC
ENVIRONMENT
NUCPARMS
RESERVED_LOCATION
TEMPORARY_LOCATION
# configuration # recommended values [CONTAINER] ASSOx = <ASSOx device> # n lines for ASSO1 ... ASSOn DATAx = <DATAx device> # n lines for DATA1 ... DATAn WORK1 = <WORK1 device> # 1 line for WORK1 SORTx = <SORTx device> # n lines for SORT1 ... SORTn TEMPx = <TEMPx device> # n lines for TEMP1 ... TEMPn NUCCLGx = <NUCCLG device> NUCPLGx = <NUCPLG device> [CONTAINER-END]
The Adabas containers ASSOx, DATAx, WORK1, SORTx and TEMPx are defined in this topic. Additionally, the Adabas sequential files NUCCLGx and NUCPLGx are defined in this topic.
If explicit external environment definitions for these items exist, their values override the DBnnn.INI values. Therefore, you can use the items in DBnnn.INI to define default values.
Important: If you enable the INCREASE_<container> actions in the DB_PARAMETER topic, AEO must be informed of the disk location to use if a new container is required. You do this by appending at least one extra DATAx and ASSOx to your lists, and these define the location that AEO will use if the INCREASE_<container> action is started.
When adding or removing a container with the utility ADADBM, the container definition in the DBnnn.INI file is updated.
The topic DB_PARAMETER defines actions and other definitions for AEO.
The topic ACTION_DBA contains the names of all users for whom AEO will start actions if required. Adabas and all utilities will also work for other users, but all actions defined in the topic DB_PARAMETER are only initiated for users defined as ACTION_DBA.
Linux: The user name is case-sensitive.
PC platforms: If no user is defined and AEO is enabled, the respective actions will be initiated for any user.
# configuration # recommended values
[DB_PARAMETER]
[ACTION_DBA]
<user name 1> (see platform-specific notes given above)
<user name 2>
...
[ACTION_DBA-END]
[DB_PARAMETER-END]
# configuration # recommended values
[DB_PARAMETER]
[ADANUC_STARTED]
ACTION=<yes/no>
ACTION_ROUTINE=<action routine> ada_nsta
[ADANUC_STARTED-END]
[DB_PARAMETER-END]
The recommended action routine is ada_nsta, which has the following input parameters:
| Parameter | Description |
|---|---|
| 1 | utility name = ADANUC |
| 2 | process ID |
| 3 | DBID |
| 4 | DB status = ONLINE |
| 5 | user login name |
| 6 | node name |
| 7 | session number |
The action routine is submitted by the Adabas utility ADANUC only if the nucleus started successfully.
The ACTION_ROUTINE will only be submitted if ACTION=yes.
# configuration # recommended values
[DB_PARAMETER]
[ADANUC_TERMINATED]
ACTION=<yes/no>
ACTION_ROUTINE=<action routine> ada_nsto
[ADANUC_TERMINATED-END]
[DB_PARAMETER-END]
The recommended action routine is ada_nsto, which has the following input parameters:
| Parameter | Description |
|---|---|
| 1 | utility name = ADANUC |
| 2 | process ID |
| 3 | DBID |
| 4 | DB status = ONLINE |
| 5 | user login name |
| 6 | node name |
| 7 | termination status (= TERMINATED or ABORTED) |
The action routine is submitted by the Adabas utility ADANUC when the nucleus terminates.
The ACTION_ROUTINE will only be submitted if ACTION=yes.
# configuration # recommended values
[DB_PARAMETER]
[AUDIT_TRAIL]
ACTION=<yes/no>
FILTER=<all/rejected>
[AUDIT_TRAIL-END]
[DB_PARAMETER-END]
To write the audit trail set ACTION to YES. The default value is NO.
To only log rejected authentications and authorizations for Adabas direct call interface, set FILTER to REJECTED. The default value is ALL.
# configuration # recommended values
[DB_PARAMETER]
[DELETE_CHECKPOINTS]
ACTION=<yes/no>
ACTION_ROUTINE=<action routine> ada_dlcp
MINIMUM=<minimum age (in days) for checkpoints 100
to be deleted>
[DELETE_CHECKPOINTS-END]
[DB_PARAMETER-END]
The recommended action routine is ada_dlcp, which has the following input parameters:
| Parameter | Description |
|---|---|
| 1 | utility name = ADANUC |
| 2 | process ID |
| 3 | DBID |
| 4 | DB status = ONLINE |
| 5 | user login name |
| 6 | node name |
| 7 | date string for ADADBM command DELCP |
The action routine is submitted by the Adabas utility ADANUC when
the nucleus starts
the nucleus writes a checkpoint and the last time a checkpoint was written is at least one day ago (this case will occur for databases which are usually always online)
The ACTION_ROUTINE will only be submitted if ACTION=yes.
MINIMUM must be greater than 0. This value defines the minimum age (in number of days) for checkpoints to be deleted.
# configuration # recommended values
[DB_PARAMETER]
[INCREASE_<container>] ASSO or DATA
ACTION=<yes/no>
ACTION_ROUTINE=<action routine> ada_iass or ada_idat
MINIMUM=<minimum free space (in percent)> 15
EXTEND_RATE=<minimum extend rate (in percent)> 10
MESSAGE = (I=<i>,W=<w>,E=<e>,F=<f>) (I=40,W=20,E=10,F=5)
[INCREASE_<container>-END]
[DB_PARAMETER-END]
The recommended action routines are ada_iass (for ASSO) and ada_idat (for DATA), each of which has the following input parameters:
| Parameter | Description |
|---|---|
| 1 | utility name (upper case) |
| 2 | process ID |
| 3 | DBID |
| 4 | DB status (ONLINE or OFFLINE) |
| 5 | user login name |
| 6 | node name |
| 7 | current number of ASSO/DATA extents (e.g. 7) |
| 8 | new extent name (e.g. ASSO8) |
| 9 | extent size in MB |
The action routine is submitted by the following Adabas utilities:
ADAREP submits the action asynchronously when executing "adarep dbid=<dbid> free"
ADANUC submits the action asynchronously after space allocation
ADAFDU, ADABCK, ADAFRM, ADAREC, ADAORD submit the action asynchronously after space allocation when ADANUC is offline
ADAMUP, ADAINV submit the action synchronously during space allocation when adanuc is offline
The message DBFREE is logged by adarep and by every Adabas utility which performs space allocation.
The ACTION_ROUTINE will only be submitted if ACTION=yes.
The Analyser compares the current free space (in percent) with the configured MINIMUM (valid range: 5-50 percent). If the amount of free space is less than the specified minimum value, the Analyser computes how much additional space is required and starts the action to allocate the additional space.
The calculation of additional space is done in two steps:
Additional space equal to the current size of the database multiplied by the value of EXTEND_RATE (valid range: 5-100 percent) is calculated. This definition ensures that the additional space is relative to the current size. The additional space calculated here is added to the value resulting from step 2.
It may be that even with the additional space calculated in step 1, the ratio of the free space to the total database space would be less than the percentage specified by MINIMUM. This can happen if a large block was allocated, thus causing the limit for the required minimum amount of free space to be not only reached but also greatly fallen short of. In this case, a second allocation of space is required, so that the ratio specified by MINIMUM is reached.
The amount of additional space to be allocated is therefore the result of adding the values from steps 1 and 2.
Adabas is able to increase ASSO/DATA while the nucleus is active. When the nucleus is active, space allocation (even for utilities) is done from ADANUC. The action routine takes the new container definition from the topic CONTAINER, so be sure to define one or more CONTAINER items for this action. If such a definition is missing, the action stops without increasing the size of the database.
The Analyser also compares the computed free space ratio with the defined percentage values i, w, e, f in the item MESSAGE. These values must be in the range 1-100 and in descending order, i.e. i > w > e > f. The message DBFREE is logged if the free space is equal to or smaller than one of these values.
# configuration # recommended values
[DB_PARAMETER]
[OFFLINE_CHECKPOINTS]
MESSAGE = (I=<i>,W=<w>,E=<e>,F=<f>) (I=50,W=20,E=5,F=2)
[OFFLINE_CHECKPOINTS-END]
[DB_PARAMETER-END]
The item MESSAGE defines the severity for the Adabas message CPBFREE. If Adabas is offline, the AEO Analyser is called every time an Adabas checkpoint is written into the checkpoint block. It evaluates the number of free entries in the checkpoint block and compares it with the numeric values (which must be greater than 0) of the MESSAGE parameters i, w, e and f. These values must be defined in decreasing order, i.e.: i > w > e > f. Thus, if there are 10 free entries and MESSAGE=(I=50,W=20,E=5,F=2), an Adabas message CPBFREE with severity W is written.
Note:
The message CPBFREE is logged for every Adabas utility that
writes checkpoints while the nucleus is offline.
# configuration # recommended values
[DB_PARAMETER]
[RECOVER_LOST_BLOCKS]
ACTION=<yes/no>
ACTION_ROUTINE=<action routine> ada_rlst
[RECOVER_LOST_BLOCKS-END]
[DB_PARAMETER-END]
The recommended action routine is ada_rlst, which has the following input parameters:
| Parameter | Description |
|---|---|
| 1 | utility name (upper case) |
| 2 | process ID |
| 3 | DBID |
| 4 | DB status (ONLINE or OFFLINE) |
| 5 | user login name |
| 6 | node name |
The action routine is submitted by
the Adabas utility ADANUC when Adabas return code 77 occurs and the associated command is an Adabas utility command
the Adabas utility ADAREP: "adarep dbid=<dbid> layout"
the Adabas utility ADAVFY: "adavfy dbid=<dbid> lost"
The ACTION_ROUTINE will only be submitted if ACTION=yes.
Lost blocks can only occur only in a utility context. If AEO was not active in this situation and lost blocks already exists, you may use ADAREP or ADAVFY to find lost blocks and to submit this action.
Note:
RECOVER_LOST_BLOCKS does an implicit reset of UCB entries for
the given database.
# configuration # recommended values
[DB_PARAMETER]
[REORDER_FILE]
ACTION=<yes/no>
ACTION_ROUTINE=<action routine> ada_reor
MAXIMUM=<maximum number of AC/NI/UI/DS extents> 12
MESSAGE =(I=<i>,W=<w>,E=<e>,F=<f>) (I=5,W=8,E=12,F=14)
[REORDER_FILE-END]
[DB_PARAMETER-END]
The recommended action routine is ada_reor, which has the following input parameters:
| Parameter | Description |
|---|---|
| 1 | utility name = ADAREP |
| 2 | process ID |
| 3 | DBID |
| 4 | DB status (ONLINE or OFFLINE) |
| 5 | user login name |
| 6 | node name) |
| 7 - 106 | Adabas file number list |
The action routine is submitted within the context of the SAVE_DB action by a call of the Adabas utility ADAREP with the following parameters: adarep dbid=<dbid> content
The message FIFREE is logged by every Adabas utility which performs space allocation.
The ACTION_ROUTINE will only be submitted if ACTION=yes.
The ADAREP utility calls the AEO Analyser, which checks all database user files (Adabas system files are ignored) for their number of AC/NI/UI/DS extents. If one extent number is greater than or equal to the defined MAXIMUM (valid range: 3 - 32), this file will be reordered. The action is started once to reorder all such files (see action parameters 7 - 106). So the reorder task is performed one file after the other sequentially.
Important: This ACTION_ROUTINE is not directly submitted when Adabas allocates an extent, because at this time Adabas is still using the file, and this would result in an access conflict with the reorder action. This action may only be started after the database has been successfully saved. Therefore the action REORDER_FILE checks if the action SAVE_DB (see section Subtopic: SAVE_DB) has successfully finished. This is done by comparing the value of environment variable ADA_SAVE_DB with input parameter 3. If they match, the reorder is started. In every other context the action terminates without reordering a file.
Every time Adabas allocates file extents, the Analyser compares the current extent number with the defined message values i, w, e and f. These values must be greater than 1 and in ascending order, i.e. i < w < e < f. The Adabas operations message FIFREE is logged for any file for which one extent type (AC,NI,UI,DS) is equal to or greater than one of the defined message values i, w, e or f.
# configuration # recommended values
[DB_PARAMETER]
[SAVE_DB]
ACTION=<yes/no>
ACTION_ROUTINE=<action routine> ada_svdb
[SAVE_DB-END]
[DB_PARAMETER-END]
The recommended action routine is ada_svdb, which has the following input parameter:
| Parameter | Description |
|---|---|
| 1 | database ID = dbid |
The action routine should be started with an external scheduler via ada_actn. It takes the following steps:
checks the action definitions ( ACTION must be yes)
expands the backup file name with extension <dbid>.<nn> to
(PC platforms:) BCK001=%ADADATADIR%\db<dbid>\BCK001.<dbid>.<nn>where <nn> is in the range 01 ... 99 and one higher than the last backup file found in that directory
(Linux:) BCK001=$ADADATADIR/db<dbid>/BCK001.<dbid>.<date>.<time>where <date> is in the form yymmdd (years, months, days) and <time> is in the form hhmm (hours, minutes).
starts backup with the DUMP option
(after successful backup:) sets the environment variable ADA_SAVE_DB=<dbid>
starts "adarep dbid=<dbid> content" to check the conditions for the action REORDER_FILE.
Note:
If you want to modify a backup option or the location of the
backup, customize ada_svdb to your specific requirements.
# configuration # recommended values
[DB_PARAMETER]
[SSX_CONFIGURATION]
<option>=<value>
[SSX_CONFIGURATION-END]
[DB_PARAMETER-END]
In the section Infrastucture Security Library of the section Adabas Role-Based Security (ADARBA) you can find examples and example templates for the different authorization types. These templates are not complete as some of the settings are customer-specific and must be modified where necessary.
# configuration # recommended values
[DB_PARAMETER]
[TERMINATE_ADANUC]
SHUTDOWN=<n1> 0
CANCEL=<n2> 12
ABORT=<n3> 12
[TERMINATE_ADANUC-END]
[DB_PARAMETER-END]
The topic TERMINATE_ADANUC contains information for adastop. The item values n1, n2 and n3 must be numeric (greater than or equal to 0).
adastop executes the utility ADAOPR to stop the database. ADAOPR has 3 options to stop a database:
ADAOPR SHUTDOWN waits until all transactions are terminated, and then shuts down the database.
ADAOPR CANCEL rolls back all open transactions immediately and then shuts down the database.
ADAOPR ABORT stops the database without doing a clean shutdown and writes a dump.
adastop does the following:
If n1 > 0, adastop first performs ADAOPR SHUTDOWN and then waits for up to n1 * 5 seconds for the termination of the database. If n1 = 0, ADAOPR SHUTDOWN is not performed.
If the database has not yet terminated after step 1, and n2 > 0, adastop performs ADAOPR CANCEL and then waits for up to n2 * 5 seconds for the termination of the database. If n2 = 0, ADAOPR CANCEL is not performed.
If the database has not yet terminated after step 2, and n3 > 0, adastop performs ADAOPR ABORT and then waits for up to n3 * 5 seconds for the termination of the database. If n3 = 0, ADAOPR ABORT is not performed.
If the database has not yet terminated after step 3, adastop aborts with an error message.
With the recommended values, adastop does not perform ADAOPR SHUTDOWN, and starts directly with ADAOPR CANCEL. If the database is not down after 12 * 5 seconds = 1 minute, ADAOPR ABORT is performed. If then the database is not down after 12 * 5 seconds = 1 minute, adastop aborts with an error message.
You may define all Adabas environment variables in this topic (with exception of the nucleus container and SAM files). If explicit external environment definitions for these items exist, the external values override the DBnnn.INI values. Therefore, you can use these items in DBnnn.INI to define default values.
# configuration # recommended values
[ENVIRONMENT] # Any Adabas environment variable may
# be defined here.
ADAUEX_n = ... # Adabas user exit
ADANUCLOG = ... # Location or path for nucleus log
# upon adastart.
ADANUCLOGOLD = <COPY|APPEND> # selection to copy or append
# the previous session of nucleus log to
# <ADANUCLOG>.old
ADATCP_DNSLOOKUP = <YES|NO> # enables/disables a reverse
# lookup for incoming adatcp
# connections
ADATRT = .... # file name of the shared library (Linux)
# or dynamic link library (PC) containing
# the Adabas translation table
ADAHYX_n # Adabas hyperexit
[ENVIRONMENT-END]
If the environment variable ADANUCLOG is neither defined nor valid, the default log location is defined in $ADADATADIR/db<dbid>/adanuc.log for Linux platforms, or in %ADADATADIR%\db<dbid>\adanuc.log for Windows platforms.
ADANUCLOG and ADANUCLOGOLD are defined in one of two ways: as environment variable, or by using the adaini command to enable it in DBnnn.INI.
If ADANUCLOG is simultaneously defined in DBnnn.INI and as environment variable, the valid nucleus log is taken from environment variable setting.
If the environment variable ADANUCLOGOLD is defined as
COPY, the previous session of the nucleus log is copied to the environment value <ADANUCLOG>.old, or the default location $ADADATADIR/db<dbid>/adanuc.log.old for Linux platforms or %ADADATADIR%\db<dbid>\adanuc.log for Windows platforms.
APPEND, the previous sesson of the nucleus log is appended to the environment value <ADANUCLOG>.old, or the default location $ADADATADIR/db<dbid>/adanuc.log.old for Linux platforms, or %ADADATADIR%\db<dbid>\adanuc.log for Windows platforms.
These environment settings are used by the Adabas utilities when the corresponding environment variables are not defined.
The ADATCP_DNSLOOKUP environment variable enables or disables the reverse lookup of incoming adatcp connections. The default value is ‘NO’. This prevents performance issues because a DNS (Domain Name Service) lookup can be very time consuming. The command ‘ADAOPR DB=nnn DISPLAY=TCPCONNECTIONS’ will then show the host names that are delivered by the client and a local port number 0. The host’s name given by the client, also known as ‘Node Id’ in the user queue, might not be the real one (see also the client function lnk_set_adabas_id() in the Command Reference, Calling Adabas). If the ‘real’ host’s names are wanted, set ADATCP_DNSLOOKUP to ‘YES’.
# configuration # recommended values [NUCPARMS] PLOG # Any nucleus parameter may be defined here. NU=100 .... [NUCPARMS-END]
The topic NUCPARMS defines any nucleus parameter with the exception of DBID. These values are used by adastart when starting the database. The DBID is passed to the nucleus by adastart, which itself takes it as a parameter.
These parameters can be verified by the administration command adaini with the VER parameter. Potentially unique abbreviations will then be automatically replaced by the correct item names (e.g. the abbreviation PORT will be automatically corrected to PORTNUMBER).
# configuration # recommended values [RESERVED_LOCATION] LOCATIONx = <path name> # n lines for disk locations with free space [RESERVED_LOCATION-END]
When an auto expand of the database is necessary and a new container is to be created, Adabas searches for free space in the locations specified.
# configuration # recommended values [TEMPORARY_LOCATION] TEMPLOCx = <path name> # n lines for disk locations with free space [TEMPORARY_LOCATION-END]
When Adabas needs temporary disk space for the nucleus or utilities, Adabas searches for free space in the locations specified.