DOCS

Description of Server Settings

This section provides a detailed description of the settings in the server initialization file.

ACCESS=<comm_section>

Section: [<server_start>]

The ACCESS setting specifies the name of the section that contains all required communication settings for the server. For details, see <comm_section> Section.

ADB=<dbname>

Section: [<server_start>]

The ADB setting declares the database <dbname> to be an administration database.

The database that is to be defined as the administration database must be assigned to the server data space with this setting in the initialization file:

DATABASE<n>=<db_section>

where n = 1,2, ... 128.

The value of <dbname> is the logical name of the database. It is defined by this setting in the <db_section> section of the initialization file:

NAME=<dbname>

User passwords and user accounts are stored in the administration database.
In principle, any database can be used as the administration database, but only one database can be assigned as administration database at run-time. That database must be assigned to the data space of the server in mode U (UPDATE). The logical database name in the ADB setting must match the logical name of one of the databases that are assigned to the data space of the server. If this is not the case, the setting is recognized as incorrect and the server cannot be started.

ADBX=<alt_auth>

Section: [<server_start>]

The ADBX setting specifies the name of the section that contains the settings for external user authentication. See <alt_auth> Section.

The ADBX setting requires the ADB setting.

AllowDisabledPasswords=YES | NO

Section: [<alt_auth>]

The AllowDisabledPasswords setting enables/disables the password check option for Rochade accounts, which are not defined as internal:

•

YES

For logging into Rochade, a user needs not to enter a password if its Rochade account is not defined as internal and the password check for that account is disabled in the ADB.

This setting is provided for backward compatibility. You must be aware that its activation implies the risk that a user can get unlimited access to certain data or functionality in Rochade.

•

Default. For logging into Rochade, each user must enter a password if its account is not defined as internal.

The setting takes only effect for external authentication via Windows domain or LDAP.

AllowInternalAccounts=YES | NO

Section: [<alt_auth>]

The AllowInternalAccounts setting enables/disables the definition of internal accounts that can be used for logging into Rochade even if external authentication is used.

•

YES

Internal accounts can be defined.

•

Default. Definition of internal accounts is not allowed.

LDAP properties and group assignments are not considered for internal accounts even if the LDAP directory contains an account of that name.

ATTR_CREATE=ALL | SUCCESS | FAILURE | NONE

Section: [<audit_log>]

The ATTR_CREATE setting specifies which events will be logged in the Rochade audit log when an attribute is created.

•

ALL

Successful as well as failed attempts to create an attribute will be logged.

•

SUCCESS

Only successful creation of an attribute will be logged.

•

FAILURE

A log entry will be written only if errors occurred during an attempt to create an attribute and the attribute, therefore, was not created.

•

NONE

Default. No log entries will be written when an attribute is created.

ATTR_DELETE=ALL | SUCCESS | FAILURE | NONE

Section: [<audit_log>]

The ATTR_DELETE setting specifies which events will be logged in the Rochade audit log when an attribute is deleted.

•

ALL

Successful as well as failed attempts to delete an attribute will be logged.

•

SUCCESS

Only successful attempts to delete an attribute will be logged.

•

FAILURE

A log entry will be written only if errors occurred during an attempt to delete an attribute and the attribute, therefore, was not deleted.

•

NONE

Default. No log entries will be written when an attribute is deleted.

ATTR_MODIFY=ALL | SUCCESS | FAILURE | NONE

Section: [<audit_log>]

The ATTR_MODIFY setting specifies which events will be logged in the Rochade audit log when an attribute is modified.

•

ALL

Successful as well as failed attempts to modify an attribute will be logged.

•

SUCCESS

Only successful attempts to modify an attribute will be logged.

•

FAILURE

A log entry will be written only if errors occurred during an attempt to modify an attribute and the attribute, therefore, was not modified.

•

NONE

Default. No log entries will be written when an attribute is modified.

ATTR_READ=FAILURE | NONE

Section: [<audit_log>]

The ATTR_READ setting specifies which events will be logged in the Rochade audit log when an attribute is read.

•

FAILURE

A log entry will be written only if errors occurred during an attempt to read an attribute.

•

NONE

Default. No log entries will be written when an attribute is read.

AUDITING=ON | OFF

Section: [<db_section>]

The AUDITING setting specifies whether audit logging is active for the database.

•

Default. An audit is written for the database if audit logging is active for

the server.

•

OFF

No audit log is written for the database.

AUDITLOG=ON | OFF

Section: [<audit_log>]

The AUDITLOG setting specifies whether or not an audit log will be written.

•

An audit log is written.

•

OFF

Default. No audit log is written.

AUDITLOGBACKUP=<auditlogback_file>

Section: [<audit_log>]

The AUDITLOGBACKUP setting specifies the name of the file in which the backup of the Rochade audit log will be stored.
If this setting is missing, you cannot back up the audit log.

AUDITLOGDATEFMT=<format_string>

Section: [<audit_log>]

The AUDITLOGDATEFMT setting specifies the date format.
The information specified in <format_string> is listed in the given order in the audit log. Between the values for the hour, the minute, and the second, a colon will be inserted as a separator.
You can specify the date format in <format_string> by concatenating the appropriate information IDs (without separating them by blanks) from this table:

String for Time Units	Explanation
%M	Month: two-digit value
%D	Day: two-digit value
%Y	Year: four-digit value
%H	Hour: two-digit value
%N	Minute: two-digit value
%S	Second: two-digit value

This default applies if the setting is not specified:

%M/%D/%Y %H:%N:%S

AUDITLOGESC=0xhh | <symbol>

Section: [<audit_log>]

The AUDITLOGESC setting specifies the symbol for escaping the separator character in the Rochade audit log. This can be a character in hexadecimal code or any character of the character set.
If an escape symbol occurs within a value, the whole value is escaped and the escape symbol within it is doubled.

Consider these examples where the double quote (") is used as the escape symbol:

View	Output in Audit Log
abc"def	"abc""def"
abc"def klm	"abc""def klm"

The default depends on the AUDITLOGSEP setting (see below); for SHELL, it is the backslash (\), for RPL, the at sign (@), and for all others, the double quote (").

AUDITLOGFAIL=<string>

Section: [<audit_log>]

The AUDITLOGFAIL setting specifies the string that should appear in place of FAILURE in the audit log.

AUDITLOGFILE=<auditlog_file>

Section: [<audit_log>]

The AUDITLOGFILE setting specifies the file name for the Rochade audit log.
If this setting is missing, these file names are used as defaults:

Operating System	File Name
Windows	audit.log
UNIX	audit.log
z/OS	The file described under the ddname AUDIT

AUDITLOGFMT=<format_string>

Section: [<audit_log>]

The AUDITLOGFMT setting specifies what kind of information shall appear in the audit log as well as the sequence in which this information is to appear.
The types of information that are specified in <format_string> are listed in the specified order in the audit log. If a type of information is missing or not relevant for a particular event, it will be omitted and only the separators specified in the AUDITLOGSEP setting (see below) will be written.
In <format_string>, you can specify what types of information are to be logged by concatenating the corresponding information type IDs (without separating them by blanks) from this table:

Information Type	Information to be Logged
%A	Attribute name
%B	Database
%C	Configuration
%D	Application identifier (for example, RRT, METABILITY, or BROWSER)
%E	Event identification (for example, ITEM_MODIFY or LIC_CHNG)
%G	Naming group
%H	Namespace
%I	ID of the client session
%K	Record key (such as, unique number)
%L	System login name
%M	Client computer name
%N	Item name
%O	Item’s object ID
%P	Client computer name (Web client)
%Q	System login name (Web client)
%R	Result identification (for example, SUCCESS)
%S	Cause
%T	Date and time in MM/DD/YYYY hh:mm:ss format
%U	User name, value of system variable $ACCT
%Y	Item type number
%Z	License information

If the setting is not specified, this default applies:

%T%I%E%U%L%M%R%B%C%Y%G%H%N%A%O%S

AUDITLOGPARMS=<audit_log>

Section: [<server_start>]

The AUDITLOGPARMS setting specifies that all required settings for the audit log are defined in the section <audit_log> of the initialization file. For information about the <audit_log> section, see <audit_log> Section.

AUDITLOGSEP=<separator>

Section: [<audit_log>]

The AUDITLOGSEP setting specifies the separator that is to appear between the different types of information listed in a Rochade audit log entry.
These values are permitted for <separator>:

<separator>	Explanation
NONE	No separator will be inserted between the information types.
TAB	The tab character is used as the separator.
SPACE	The blank character is used as the separator.
COMMA	The comma character is used as the separator.
SEMICOLON	Default. The semicolon character is used as the separator.
SHELL	The individual values are listed separated by a blank; backslashes are escaped with backslashes.
RPL	The rules for Rochade words are applied: lowercase letters, the Rochade separator, and the escape symbol are escaped with the escape symbol.
0xhh	The character specified in hexadecimal code is used as the separator.
Any character	The specified character is used as the separator.

If the separator character occurs within a value, the whole value will be escaped. Consider this example where the semicolon (;) is the separator character:

Value	Output in Audit Log
abc;def	"abc;def"
abc;def klm	"abc;def";klm

AUDITLOGSUCCESS=<string>

Section: [<audit_log>]

The AUDITLOGSUCCESS setting specifies the string that should appear in place of SUCCESS in the audit log.

AUDITLOGTMP=<tmp_file>

Section: [<audit_log>]

The AUDITLOGTMP setting specifies a file <tmp_file> to which temporary data are written during the processing of the Rochade audit log. This setting is required only when the parameter <lastline> is specified with $OPER AUDIT_BACKUP.

AUTH_DB=LDAP | NULL | LDAPATTR | WINDOMAIN

Section: [<alt_auth>]

The AUTH_DB setting specifies the name of the system that carries out external authentication. These values are possible:

LDAP

The external authentication is carried out via LDAP. For more information, see LDAP Authentication and Authorization.
The server automatically uses the LDAP authentication module that corresponds to its version (such as, 32 bit or 64 bit).
Using LDAP authentication, you can assign user roles by analyzing LDAP groups. For more information, see User Authorization by LDAP Groups.

NULL

Disables the internal authentication and the LDAP authentication (such as, only Kerberos authentication and trusted connections can be used to log in).

LDAPATTR

Disables the internal authentication and the LDAP authentication (such as, only Kerberos authentication and trusted connections can be used to log in).
Retains the function to search the LDAP directory for LDAP groups and, if specified, other attributes that are assigned to the current user.

WINDOMAIN (only for Windows)

The external authentication is carried out via Windows domain.
The server automatically uses the authentication module that corresponds to its version (such as, 32 bit or 64 bit).

CACHING_LEVEL_DOC=0 | 1 | 2

Section: [<db_section>]

The CACHING_LEVEL_DOC setting specifies whether the server should load item content records from the database into memory to speed up access to the records (such as, by avoiding disk access):

•

The server does not load any records into the memory (such as, former operating principle).

•

Default. The server loads index records into the cache.

•

The server loads index and data records into the cache. ASG recommends that you use this value only for databases with several hundred users and roles to avoid excessive memory consumption.

CACHING_LEVEL_LINK=0 | 1 | 2

Section: [<db_section>]

The CACHING_LEVEL_LINK setting specifies whether the server should load link and namespace index records into memory:

•

The server does not load any records into the memory (such as, former operating principle).

•

Default. The server loads index records into the cache.

•

The server loads index and data records into the cache. ASG recommends that you use this value only for databases with several hundred users and roles to avoid excessive memory consumption.

CACHING_LEVEL_NUM=0 | 1 | 2

Section: [<db_section>]

The CACHING_LEVEL_NUM setting specifies whether the server should load name catalog records into memory:

•

The server does not load any records into the memory (such as, former operating principle).

•

Default. The server loads index records into the cache.

•

The server loads index and data records into the cache. ASG recommends that you use this value only for databases with several hundred users and roles to avoid excessive memory consumption.

CACHING_RECS_PER_SEC_INITIAL=<n>

Section: [<db_section>]

The CACHING_RECS_PER_SEC_INITIAL setting specifies the number of records per second that the server initially loads from the database into the cache, where <n> is a value ranging from 0 (such as, no records) through 1200. The default value is 300.

CACHING_RECS_PER_SEC=<n>

Section: [<db_section>]

The CACHING_RECS_PER_SEC setting specifies the number of records per second that the server loads from the database into the cache after the initial load, where <n> is a value ranging from 0 (such as, no records) through 300. The default value is 50.

The default values for the settings CACHING_RECS_PER_SEC_INITIAL and CACHING_RECS_PER_SEC increase CPU consumption by about one percent. Higher values accordingly increase CPU consumption and disk access.

CODEPAGE=[@]<codepage>

Section: [<server_start>]; [<rpc_service>]

The CODEPAGE setting specifies the code page that is to be used for converting code between Rochade-internal server code and the local code of the server computer. See Code Pages in Rochade for an overview of the code pages supplied with Rochade and their contents.

You can specify not only the Rochade code pages, but also UTF-8 and LOCALE. For more information, see also Access to the Operating System’s Locale Settings.

The UTF-8 value sets the UTF-8 code as the external default character code.
The LOCALE value specifies that the current character set of the active locale's LC_CTYPE category should be used.

For example, code conversion is necessary when the server accesses the initialization file and when the server event log is displayed.

Under Windows and UNIX, <codepage> specifies the name of the file that contains the code page. The file name must be in this format:

[<path>]c<nnnn>.icp

where:

<path> is the complete path to the file.

<nnnn> is the number of the code page.

The at sign (@) always must precede <codepage> in the CODEPAGE setting under Windows and UNIX.

Example:

CODEPAGE=@\rochade\bin\c437.icp

Under z/OS, only the number of the code page is specified for <codepage>. The at sign (@) must not be specified.

Rochade will add the string ICP ahead of this number and search for the code page ICP<codepage> in the library specified by the ddname ROCODEPG.

Example:

CODEPAGE=0037

Depending on the operating system, Rochade sets these default code pages during the installation:

Operating System	Recommended Setting
Windows	LOCALE
UNIX	LOCALE
z/OS	Country-specific code page

CODEPAGE_FILES=[@]<codepage>

Section: [<server_start>]; [<rpc_service>]

The CODEPAGE_FILES setting specifies the code page to be used for converting code between the code specified in the CODEPAGE setting and the local code of the server computer when accessing operating system files. This applies to the contents of files as well as libraries (members). For detailed information on Rochade code pages, see Code Pages in Rochade.
For specifying code pages and default installation settings, the same rules apply as for specifying code pages for the CODEPAGE setting.

If you want to specify the value UTF-8 or LOCALE in CODEPAGE_FILES, you must specify it ahead of other values (for example, CODEPAGE_FILES=UTF-8;@.\c1252.icp).

For the CODEPAGE_FILES setting, you can specify several files separated by semicolons or commas. The server observes only the first of these files. This way, you can specify the settings for the code pages in a separate section, which can be accessed by both the server and the client via the $IMPORT setting.

COMM=<communication>

Section: [<comm_section>]

The COMM setting specifies the type of communication that is to be used between client and server. These values are possible for <communication>:

<communication>	Types of Communication
TCP	TCP/IP
TLS	TLS-encrypted communication
@[<path>]<name>.dll	Communication loaded dynamically (via DLLs)

Depending on the type of communication, different kinds of settings are required. For TCP/IP, see <comm_section> Section, and for TLS, see TLS-Encrypted Rochade Communication.

COMPANY=<name_of_company>

LICENSE=<license_number>

Section: [<server_start>]

These server settings are used for Rochade licensing purposes. Every server is delivered with a license number <license_number> and the customer’s company name <name_of_company>. Each license number contains a code corresponding to the server features that the customer is legally licensed to use.
Company name and license number are linked by check numbers.
Via Java API, you can retrieve the expiration date of a server’s license during run time and read or update its COMPANY and LICENSE settings.

CREATEDB=<date>

–

Section: [<db_section>]

The Rochade Server writes a CREATEDB setting into the initialization file whenever a database is created via $OPER CREATEDB. The setting includes the date and time of day when the database was created.

DATABASE<n>=<db_section>

Section: [<server_start>]

The DATABASE setting assigns the database described in the <db_section> section to the server data space. See <db_section> Section.

If the section name is not found or if one of the defined databases cannot be opened, the server will abort the start procedure.

The integer number entered in <n> reflects the logical sequence in which the databases are assigned to the data space of the server.

A maximum of 128 databases can be assigned to the data space of a Rochade Server. For this reason, the value of <n> must be an integer between 1 and 128.

Example:

DATABASE5=DBPROC1

DATABASE2=DBPROC2

DATABASE3=DBPROC3

In the example, the databases are assigned to the data space of the server in this order:

DBPROC2

DBPROC3

DBPROC1

As you can see, <n> does not have to take sequentially increasing values without gaps, such as 1, 2, 3, but it may take values such as 5, 2, 3. However, the server assigns the databases to the server data space in increasing order.

DATACLASS=<dataclass>

Section: [<db_section>]

This setting is relevant only for z/OS operating systems.
The value of <dataclass> is the name of the SMS data class. The section <db_section> must contain at least one of these settings: DATACLASS, MANAGEMENTCLASS, or STORAGECLASS. See <db_section> Section.

DBCACHESIZE=nn

Section: [<server_start>]

This setting is relevant only for z/OS operating systems.
Where nn is the size of the database cache in kilobytes. The default value for DBCACHESIZE is 4096. The databases assigned to a single server share a common database cache.
You can use this setting to optimize VSAM access.

When the server shuts down, it writes information about cache hits and cache misses to the standard output. The cache misses value, in particular, shows the number of times the databases needed to be accessed.

Relating the information to the operations that have been performed can help you determine the optimal cache size. If you increase the cache size, you also might need to adjust the region size allocated to the server.

DBLOCK= ADVISORY | MANDATORY

Section: [<server_start>]

This setting is relevant only for UNIX operating systems.
The DBLOCK setting specifies if the Rochade Server has exclusive access rights to the Rochade databases.
Setting DBLOCK to ADVISORY prevents any change to the access rights for the databases. If the SGID bit (Set Group ID) is set for these files, it can be set back only by using the UNIX command chmod.
Under Linux, HP-UX, and Oracle Solaris, the setting DBLOCK=ADVISORY is predefined, because there is an incompatibility between memory mapping and mandatory locking.
Setting DBLOCK to MANDATORY sets exclusive access for all databases. For these files, the SGID bit (Set Group ID) is set and the XGRP bit (Execute Group) is not set. This causes UNIX to assign the Rochade Server exclusive access to the databases and to block access to the databases for all other programs.

Using this setting you can, for example, prevent a backup of the Rochade databases when the server is still running.

DFILE=[<path>]<db_file>

Section: [<db_section>]

The DFILE setting specifies the physical base name <dbfile> of a Rochade database.
Under Windows and UNIX, Rochade appends the extension .rodb to the physical base name. When <path> is not specified, the server searches the current directory for the Rochade database.

Example:

Under Windows, a database file apdata.rodb is expected to reside in the directory d:\rochade\datbas if you specify this DFILE setting:

DFILE=d:\rochade\datbas\apdata

Under z/OS, you can specify a database either via a ddname or via the DS name of a VSAM dataset.

Specifying a database via VSAM dataset is particularly useful for creating new databases while the server is running. It allows you to assign a database dynamically.

If the name specified by <db_file> starts with an ampersand (&), Rochade interprets it as the DS name of a VSAM dataset; otherwise, Rochade expects in the jobstream a DD statement with the name specified in <db_file>.

Examples:

DFILE=RODAT

where RODAT is the name of the DD statement that describes the database.

DFILE=&RODOC.VSAM.DATDB

where &RODOC.VSAM.DATDB is the DS name of the VSAM dataset.

DOMAIN=<domain_name>

Section: [<alt_auth>]

The DOMAIN setting specifies the name of the Windows domain against which password and name are to be verified. It is required if you have specified the AUTH_DB=WINDOMAIN setting.

ERRBUFFERSIZE=<size>

Section: [<server_start>]

The ERRBUFFERSIZE setting describes the size of the buffer in which the server stores information about refused server requests.
<size> is specified in bytes.
You can use the $SHOWDR command to access the information stored in this buffer.

EVENTLOG=<eventlog_file>[;<number>]

Section: [<server_start>]

The EVENTLOG setting specifies the file name <eventlog_file> for the server event log.
If the log file of the server cannot be opened, the server aborts the start procedure.
If <number> is specified, a log file that already exists at server start will be renamed to <eventlog_file>.1. If the file <eventlog_file>.1 already exists, it will be renamed to <eventlog_file>.2, etc., until the number given in <number> is reached.
The current access rights might prevent the files from being renamed.
If the EVENTLOG setting is missing from the initialization file, a default name will be used for the log file (for example, under Windows: ROCHLOG.TXT).

EVENTLOGBACKUP=<eventlogbackup_file>[;A]

Section: [<server_start>]

The EVENTLOGBACKUP setting specifies the <eventlogbackup_file> file name for the backup file for the server event log.
If option A is specified and the backup file already exists, the server event log is appended to the backup file. Otherwise, the backup file is overwritten.
Under Windows and UNIX, a valid path and file name are required for <eventlogbackup_file>. If the file does not yet exist, it will be created.
Under z/OS, the backup file must exist and be correctly allocated. You must specify a ddname or the DS name of a VSAM dataset for <eventlogbackup_file>.

EVENTLOGOPT=ALL | <option>

Section: [<server_start>]

The EVENTLOGOPT setting allows you to control the scope of the server event log via specific logging options that you specify in <option>.

These logging options are available in the server:

<option>	Explanation
A	The start of the server is logged.
C	The cancellation of tasks is logged.
H	Shutting down the server is logged.
K	Communication messages are logged.
L	Logging on / off of clients is logged.
N	Utilization of internal resources (such as, sessions, user cells, listen, and buffers) is logged.
P	Opening and closing of connections with clients is logged.
R	RPC messages are logged.
T	Idle time of the server is logged.

EVENTLOGOPT=ALL activates all the logging options except T, N, and K.
You can enter the individual logging options in whatever order you prefer. So it is irrelevant whether you enter EVENTLOGOPT=AHL or EVENTLOGOPT=ALH.
EVENTLOGOPT=ALL will be used by default if the EVENTLOGOPT setting is missing from the initialization file.

HOSTNAME=<name_1>[;<name_2>[...;<name_n>]]

Section: [<comm_section>]

Via this setting, the server identifies the clients that log on as local or remote. The setting is significant only for password verification.
If this setting is specified, the server identifies all clients as local clients that log on via an address (such as, IPv4 or IPv6) specified in <name_n>. You can specify a maximum of 10 addresses.
If the setting is not specified, the server identifies all clients that log on via the local network interface (127.0.0) as local clients.
Since the HOSTNAME setting has different meanings in the client’s and the server’s communication section, ASG recommends that you always use separate communication sections. For more information on the client communication section, see <comm_section> Section.

HOSTRES=ON | OFF

Section: [<comm_section>]

The HOSTRES setting specifies whether or not the server shall write the logical name and the IP address of the client computer into the server event log.
By default, the server writes the logical name and the IP address of the client machine into the server event log. Whenever the NAME service on the server machine is very slow or is not installed, you should set HOSTRES to OFF in order to save the time that is lost by accessing this NAME service. The default value for HOSTRES is OFF.

Example 1: Server Event Log Excerpt with Setting HOSTRES=ON

Session 001 established. Client location:

TCP/IP, HOST=lg.chlab.sax(10.20.10.124), OS=WindowsNT

Time: 08:17:38 Date: 03/24/1999

Example 2: Server Event Log Excerpt with Setting HOSTRES=OFF

Session 001 established. Client location:

TCP/IP, HOST=unknown(10.20.10.124), OS=WindowsNT

Time: 09:13:25 Date: 03/24/1999

ITEM_CREATE=ALL | SUCCESS | FAILURE | NONE

Section: [<audit_log>]

The ITEM_CREATE setting specifies which events will be recorded in the audit log when an item is created.

•

ALL

Successful as well as failed attempts to create an item will be logged.

•

SUCCESS

Only successful attempts to create an item will be logged.

•

FAILURE

Default. Only attempts that produced errors and failed to create an item will be logged.

•

NONE

Neither successful nor failed attempts to create an item are logged.

ITEM_DELETE=ALL | SUCCESS | FAILURE | NONE

Section: [<audit_log>]

The ITEM_DELETE setting specifies which events will be recorded in the audit log when an item is deleted.

•

ALL

Successful as well as failed attempts to delete an item will be logged.

•

SUCCESS

Only successful attempts to delete an item will be logged.

•

FAILURE

Default. Only attempts that produced errors and failed to delete an item will be logged.

•

NONE

Neither successful nor failed attempts to delete an item are logged.

ITEM_MODIFY=ALL | SUCCESS | FAILURE | NONE

Section: [<audit_log>]

The ITEM_MODIFY setting specifies which events will be recorded in the audit log when an item is modified.

•

ALL

Successful as well as failed attempts to modify an item will be logged.

•

SUCCESS

Only successful attempts to modify an item will be logged.

•

FAILURE

Default. Only attempts that produced errors and failed to modify an item will be logged.

•

NONE

Neither successful nor failed attempts to modify an item are logged.

ITEM_READ=FAILURE | NONE

Section: [<audit_log>]

The ITEM_READ setting specifies which events will be recorded in the audit log when an item is read.

•

FAILURE

Default. Only reading attempts that produced errors will be logged.

•

NONE

Neither successful nor failed attempts to read an item are logged.

KEEP_ACTIVE=<time>

Section: [<rpc_service>]

The function of this setting depends on the value specified in <time>:

–

If the value of < time> is greater than 0, then < time> specifies the number of seconds that a service instance remains preloaded even if the <max> value specified in the PRELOAD setting has already been reached. This is in order to optimize the starting and stopping of service instances in situations where requirements exceed the PRELOAD setting.

–

If the value of < time> is 0, Rochade will deny permission to use unbound service instances to subsequent BIND requests. In this case, unbound service instances are always terminated, regardless of the PRELOAD settings.

The default value of <time> is 60.

LASTRC=<returncode> | NOSAVE

Section: [<server_start>]

LASTRC holds the return code returned by the server at server shutdown.
LASTRC=NOSAVE suppresses updating of the LASTRC setting during server shutdown. This also applies to RPC services.

•

For information on LASTRC return codes, see Messages and Return Codes.

LICENSE=<license_number>

LISTEN=<interface>[:<port>][...[;<interface>[:<port>]]]

Section: [<comm_section>]

The LISTEN setting specifies the ports and TCP/IP addresses of network interfaces through which the Rochade Server will accept connections.
<interface> is the symbolic name or the IP address (such as, IPv4 or IPv6) of the network interface.
<port> is the port number. If the port number is not specified, the port number defined by PORT=<port> is used.
With the LISTEN setting, you can define one port for several different network interfaces as well as multiple ports for one network interface.

Example:

PORT=8888

LISTEN=HOST_EXT:8882;10.20.10.16;[2001:db8:85a3:8d3::0370]

In the example, the server accepts connections via three network interfaces. For the first interface, it accepts connections via port 8882 and for the other two, it accepts connections on port 8888 (such as, the value specified in the PORT setting).

ASG recommends that you enclose IPv6 addresses in square brackets to clearly separate them from the port numbers.
If you do not use square brackets for IPv6 addresses, Rochade interprets the number after the last colon as the port number. If you do not want to specify a port number, you must type a colon at the end of the IP address to prevent Rochade from interpreting the last part of the address as the port number.
Without the LISTEN setting, the Rochade Server, by default, accepts connections from all configured network interfaces (such as, IPv4 or IPv6) at the port specified in the PORT setting. This behavior is equivalent to the setting LISTEN=0.0.0.0;[::]. For details, see Establishing a Connection from the Server Side.
If you want the server to accept connections only via the IPv4 network interfaces, you must specify LISTEN=0.0.0.0. To restrict connections to the IPv6 network interfaces, specify LISTEN=[::].
If you want to allow local clients to run on the server machine (for example, RPC services), you must specify the localhost IP address 127.0.0.1 in the LISTEN setting.
The server creates listen sockets for the entries in the LISTEN setting. If an entry resolves to multiple addresses, it creates a listen socket for each of the addresses.

The server starts only if at least one listen socket could be created for each entry. For entries that resolve to multiple addresses, a listen socket must have been created for at least one of the addresses.

LICENSE_CHANGE=NONE | SUCCESS | FAILURE | ALL

Section: [<audit_log>]

The LICENSE_CHANGE setting specifies which license changes should be recorded in the audit log:

•

NONE

Default. None license changes are logged.

•

SUCCESS

Only successfully license changes are logged.

•

FAILURE

Only failed license changes are logged.

•

ALL

All license changes are logged.

License changes are logged in the audit log under %E with the string LIC_CHNG.

LOCKMODE= SYSTEM | STEP | SYSTEMS | OFF

Section: [ROINI-INTERNAL]

This setting is relevant only for z/OS.
The LOCKMODE setting specifies the lock mode for the initialization file. This is important for the synchronization of access to the initialization file.
The LOCKMODE setting can take these values:

•

SYSTEM

Default. This value is used to specify that a machine-wide flag is used for access to the initialization file.

•

STEP

Specifies that program-specific locking is used for access to the initialization file. All access to the initialization file is coordinated within a task (for example, server and RPC access).

•

SYSTEMS

Specifies that a flag covering multiple machines is used for access to the initialization file. This is important for coordinating access to the initialization file by jobs running on different machines.

•

OFF

Specifies that no locking mechanism is activated for accessing the initialization file. ASG recommends this value if you are using separate initialization files for server and client, and you are not working with RPC services.

LOG_ALARM=<program>

Section: [<server_start>]

The LOG_ALARM setting specifies the user program to be called by the server when one of the limits specified in LOG_MAX_SEG, LOG_RESERV, LOG_SIZE_LIMIT, or LOG_RECO_TIME_LIMT has been reached.
The first parameter passed to the user program is a string describing the reason for the call. The string is created from these messages from the file ROSRVENG.MSG:

>2230 "The number of free log files dropped below the defined reserve value!"

>2231 "All available Log Files full - Server will shut down!"

>2232 "Defined Recovery Time Limit exceeded!"

>2233 "Defined Logsize Limit exceeded!"

If this setting is not specified, an operator message is sent to the master console under z/OS.

LOG_CONSUMED_SEG=<nn>

Section: [<server_start>]

This setting specifies the LOG file number of the last completely processed LOG file. This value can be set manually or by a program. A typical example for processing a LOG file is backing it up and deleting it from the disk where it was originally written by the server.
This setting is only read by the server. The server analyzes the current value when it opens a new LOG file. The difference between the value of LOG_CURRENT_SEG and LOG_CONSUMED_SEG must never exceed the value in LOG_MAX_SEG; otherwise, the server is shut down. In analogous fashion, the server analyzes the current value of LOG_CONSUMED_SEG when changing the LOG file, and checks whether the limit specified in LOG_RESERVE has been exceeded.
If LOG_CONSUMED_SEG is equal to or larger than LOG_CURRENT_SEG at server startup time, the server will not start.
If, through a user program, you enter in LOG_CONSUMED_SEG a value equal to or larger than LOG_CURRENT_SEG, the server will shut down the next time the LOG file is changed.
If this setting is not specified or no value has been given for <nn>, 0 is set as default.

LOG_CURRENT_RECO_TIME=<time>

Section: [<server_start>]

The LOG_CURRENT_RECO_TIME setting specifies the time (in seconds) that would be required for the application of a LOG file. This time is kept by the server, also after a restart.
ASG recommends that you set the value of this setting to 0 after each backup of the databases, so that <time> represents the time for a restore based on this backup.
The server adds or updates this setting in the initialization file when writing into the LOG file.
The current value of this setting is compared each time it is updated to the value of LOG_RECO_TIME_LIMIT. If appropriate, the action defined with LOG_ALARM is triggered.
If this setting is missing or no value has been given for <time>, 0 is set as default.

LOG_CURRENT_SEG=<nn>

Section: [<server_start>]

The LOG_CURRENT_SEG number specifies the LOG file number <nn> that is used on server startup for generating the file name of the first LOG file. For details on generating LOG file names, see Restore Logging.
The server increments this value when switching LOG files and uses it for generating the name of the new LOG file.
If the setting is missing or no value has been given for <nn>, then <nn> is set to 1 by default. The server adds the setting to the initialization file and updates it each time a new LOG file is opened.

LOG_CURRENT_SIZE=<kbyte>

Section: [<server_start>]

The LOG_CURRENT_SIZE setting contains the size of the LOG file in KB. The server writes this information into the initialization file when it is shut down.
The server keeps track of the amount of data written during its entire run-time and computes the total size of it.

In addition, this size is added to the current value of LOG_CURRENT_SIZE. If the value specified in LOG_SIZE_LIMIT is exceeded in the process, the server executes the action defined in LOG_ALARM.

LOG_MAX_SEG=<nn>

Section: [<server_start>]

The LOG_MAX_SEG setting specifies the maximum number of unprocessed LOG files that can exist at the same time. Numbers between 1 and 99 are permitted.
If the setting is missing or no value has been given for <nn>, then <nn> is set to 1 by default.

LOG_MAX_SIZE=<kbyte>

Section: [<server_start>]

The LOG_MAX_SIZE setting specifies the maximum size for a LOG file in KB. If the limit is reached, the server closes the file and switches to a new LOG file.
If the setting is missing or no value has been given for <kbyte>, it is set to 0 by default. This corresponds to an unlimited size.

LOG_MAX_TIME=<time>

Section: [<server_start>]

The LOG_MAX_TIME setting specifies the maximum number of seconds after which the current LOG file is closed. This can be used to specify the time offset by which the LOG files are used to update a mirror database.
If the setting is not specified or no value is given for <time>, it is set to 0 by default. This corresponds to setting no time limit.

LOG_NAME=<filename>

Section: [<server_start>]

The LOG_NAME setting enables logging, and it specifies the name of the LOG file.
Rochade generates the names of the individual LOG files as follows:

Under Windows and UNIX, an attempt is made to split <filename> into <file>.<ext>. The actual file name then has this form:

where <segno> is the current value of the LOG_CURRENT_SEG setting, expanded to six digits.

Under z/OS, <filename> is appended with a two-digit sequence number that is the result of LOG_CURRENT_SEG modulo LOG_MAX_SEG.

For details on generating file names, see Database Maintenance.

LOG_RECO_TIME_LIMIT=<time>

Section: [<server_start>]

The LOG_RECO_TIME_LIMIT setting specifies the maximum number of seconds that the rodbucx<os> utility is allowed to take to apply a LOG file. When the value in LOG_CURRENT_RECO_TIME, which is kept by the server, reaches this limit, the user program specified in LOG_ALARM is executed.
Under z/OS, an additional operator message is sent to the master console.
If the setting is missing or no value is specified for <time>, it is set to 0 by default. This corresponds to no time limit.

LOG_RESERVE=<nn>

Section: [<server_start>]

The LOG_RESERVE setting specifies a threshold for the number of available LOG files. If the number of LOG files still available drops below <nn>, the user program specified in LOG_ALARM is called.
If the setting is missing or no value has been given for <nn>, 0 is assumed as default. So you will receive no warning before you run out of LOG files.

LOG_SIZE_LIMIT=<kbyte>

Section: [<server_start>]

The LOG_SIZE_LIMIT setting specifies the maximum overall size for all unprocessed LOG files in KB. When the limit is reached, the user program specified in LOG_ALARM is called.
If the setting is missing or no value is given for <kbyte>, it is set to 0 by default. This means that there is no size limit for LOG files.

LOGOFF=ON | OFF

Section: [<audit_log>]

The LOGOFF setting specifies whether or not user logoffs will be logged.
If the value ON is specified, logging off will be recorded in the audit log.
If the value OFF is specified, logging off will not be recorded in the audit log.

LOGON=ALL | SUCCESS | FAILURE | NONE

Section: [<audit_log>]

The LOGON setting specifies which events will be recorded in the audit log when a user logs on to Rochade:

•

ALL

Successful as well as failed user logon attempts will be logged.

•

SUCCESS

Only successful user logon attempts will be logged.

•

FAILURE

Default. Logon attempts will be recorded only if errors occur in the process.

•

NONE

No log entries are written when a user attempts to log on.

MANAGEMENTCLASS=<managementclass>

Section: [<db_section>]

This setting is relevant only for z/OS operating systems.
The MANAGEMENTCLASS setting specifies the name <managementclass> of the SMS Management class.
The section <db_section> must contain at least one of these settings: DATACLASS, MANAGEMENTCLASS, or STORAGECLASS. See <db_section> Section.

MAXATTRDIRSIZE=<byte>

Section: [db_section>]

The MAXATTRDIRSIZE setting specifies the maximum size (in bytes) up to which attribute content of an item version is stored contiguously (such as, without storing contents in separate locations).
The default value is 1024, and, as a rule, should not be changed. For more information, see Storing the Data.

MAX_INSTANCES=<number>

Section: [<rpc_service>]

The MAX_INSTANCES setting specifies the maximum number of service instances that an RPC service may have.
The default setting is unlimited. The total number of all concurrent service instances is limited to 255, however.

MODE=U | R

Section: [<db_section>

The MODE setting specifies the mode in which a Rochade database is opened.

U	The Rochade database is opened for UPDATE
R	The Rochade database is opened in READONLY mode.

NAME=<name>

Section: [<db_section>]

In the section <db_section>, the NAME setting specifies the logical name <name> of the database.
The server recognizes only the first eight characters of the logical database name and ignores the rest.
The client can access the database with this name.

The database must be assigned to the logical server data space with the DATABASE<n> setting, where n = 1,2, ... 128.

NAME=<name>

Section: [<rpc_service>]

In the section <rpc_service>, the NAME setting specifies the logical name <name> of the RPC service. The client can access the RPC service with this name.
Specification of this setting in the <rpc_service> section is mandatory.

NUMA_MODE=OFF | NONE | DEFAULT | node1 [, node2] ...

Section: [<server_start>]

The NUMA_MODE setting specifies the server’s operating mode when running on a NUMA system:

•

OFF

The server does not check whether it is running on a NUMA system and, therefore, starts without changing its operating mode.

•

NONE

The server checks whether it is running on a NUMA system and writes the extracted information to the server event log, but it does not change its operating mode.

•

DEFAULT

Default. The server optimizes its operating mode automatically according to the operating system on which it runs.

•

node1 [, node2] ...

The server optimizes its operating mode using only the CPUs of the specified nodes, where node1, node2, etc. are the numbers of the respective nodes.

In case of process errors (for example, parse errors or values that are out of range), the server startup is terminated and an error message is written to the server event log.

Under Windows, you must specify the nodes as a comma-separated list of node numbers. For example:

NUMA_MODE=0,2,4

Under Linux, you can specify the nodes using any notation that is supported by the numa_parse_nodestring function (for example, comma-separated lists of numbers, ranges, negations of ranges, etc.). For example:

NUMA_MODE=0,2,4

NUMA_MODE=3-4

NUMA_MODE=!0-1

Because of the memory mapping of Rochade databases, optimum performance on NUMA systems might be achieved by assigning the Rochade Server to a single node. ASG recommends that you run tests with different values for the NUMA_MODE setting. The optimum value depends on the specifications of your NUMA system (for example, number of CPUs per node, memory distribution and non-local access times, etc.).

ONLINE_BACKUP_DATABASE=<bufferdb>

Section: [<server_start>]

The ONLINE_BACKUP_DATABASE setting specifies that the database written in the section <db_section> is assigned to the data space of the server.
The value of <bufferdb> is the name of the section where the settings for the buffer database are defined. The same settings are required for buffer databases as for all other databases.

ONLINE_BACKUP_MODE=CLEANUP | CONTINUE | WAIT

Section: [<server_start>]

The ONLINE_BACKUP_MODE setting specifies the way the server behaves on startup after it was stopped during an online backup. This is also the only case where the server evaluates this setting.

For this setting, you can specify these values:

•

CLEANUP

Copies the contents of the buffer database to the respective databases at server start. This is equivalent to terminating the online backup with:

$OPER ONLINE_BACKUP END <var1>

•

CONTINUE

The current state of the online backup is kept at server start.

All write operations are directed to the buffer database, and all other databases connected to the server are opened in read-only mode.

•

WAIT

Default. The server cannot be restarted immediately.

The operator must set ONLINE_BACKUP_MODE to CLEANUP or CONTINUE explicitly.

OPER_CMD=ALL | SUCCESS | FAILURE | NONE

Section: [<audit_log>]

The OPER_CMD setting specifies which events will be recorded in the audit log when operator commands are used:

•

ALL

Logs successful and failed attempts to use operator commands.

•

SUCCESS

Logs only successful attempts to use operator commands.

•

FAILURE

Default. A log entry will only be written if errors occurred when an operator command was issued.

•

NONE

No log entries are written when an operator command is issued.

OPER_LOGOFF=ON | OFF

Section: [<audit_log>]

The OPER_LOGOFF setting specifies whether or not deactivating the operator privileges will be recorded in the audit log:

•

Deactivating the operator privileges will be logged.

•

OFF

Default. Deactivating the operator privileges will not be logged.

OPER_LOGON=ALL | SUCCESS | FAILURE | NONE

Section: [<audit_log>]

The OPER_LOGON setting specifies which events will be recorded when the operator privileges are activated:

•

ALL

Successful as well as failed attempts to activate operator privileges will be logged.

•

SUCCESS

Only successful attempts to activate operator privileges will be logged.

•

FAILURE

Default. A log entry will only be written if errors occurred when operator privileges were activated.

•

NONE

No log entries are written when operator privileges are activated.

PARAMS=<params>

Section: [<rpc_service>]

The PARAMS setting specifies the runtime parameters for the RPC service.
The setting enables you to configure Java API directly as an RPC service (it is not required to call a CMD batch script).

For example:

[SERV]

...

SERVICE1=JRPC

[JRPC]

NAME=JRPC

SERVICEDEBUG=ON;c:\tmp\log.txt

PROGRAM=c:\program files\java\bin\java

PARAMS=-ea -classpath "c:\rochade\bin\rochade.jar;

c:\rochade\bin\." -Xmx2000m de.rochade.rpcservice.RpcMain

CLASS=de.rochade.rpcservice.test.RpcSample1

THREAD_POOL_PORT=7911

MAX_INSTANCES=32

PRELOAD=1

KEEP_ACTIVE=60

SERVER1=COMMUCLI

The PROGRAM setting must specify the path to the Java virtual machine (JVM).

The PARAMS setting enables you to specify the parameters for the JVM including the name of the Java class to be run (for example, RpcMain).

This is the resulting command line for starting the JVM:

"c:\program files\java\jre7\bin\java" -ea

-classpath "c:\rochade\bin\rochade.jar;c:\rochade\bin\."

-Xmx2000m de.rochade.rpcservice.RpcMain "20150513151826000001" "JRPC" "C:\rochade\appl\server.ini"

To create a valid command line for Windows, the values of the NAME and PROGRAM settings and the location of the initialization file are enclosed in quotes. The value of the PARAMS setting, however, is not modified. The setting, therefore, must already contain the required quotes (for example, for paths) in the initialization file.

When reading values that contain quotes, outer quotes are removed (such as, the value "abc" "def" results in abc" "def). Under Windows, you can retain the outer quotes by adding additional apostrophes to a value (for example, '"abc" "def"' results in "abc" "def").

PERF=<filename>

Section: [<server_start>]

If this setting is specified, the server carries out performance measurements for all server sessions. For more information, see the GETSERVER parameter under Performance Analysis with the RPL Command $PERF.
The setting remains in effect from server start to server termination. The server summarizes the values for each session at the end of the session, and during shutdown writes the results to the file specified by <filename>.

PORT=<port>

Section: [<comm_section>]

The setting specifies the server port (a port number or a symbolic address that can be resolved via /etc/services). For details, see Communication Access. In some systems, the port numbers below 1024 are reserved.

PRELOAD=<min> [,<max> [,<delay>]]

Section: [<rpc_service>]

This setting controls the management of preloaded service instances to ensure speedy response to BIND requests.
The service monitor attempts to preload a number of service instances that lies within the range specified by <min> and <max>.
Preloading of up to <min> number of service instances is delayed by the number of seconds specified in <delay>. The default value is 30 seconds.
If the number of preloaded service instances reaches <max>, excess unbound instances remain preloaded until the timeout specified in the KEEP_ACTIVE setting is reached (such as, to optimize the starting and stopping of service instances).
The default value for <min> and <max> is 0. The total number of all concurrent service instances is limited to 255.
If <max> is greater than the value specified for MAX_INSTANCES, the value of MAX_INSTANCES is used as the maximum value.
If the value specified in <min> is in conflict with that specified in the MAX_INSTANCES setting, a smaller number of instances can be preloaded.

PRIMARY=<mb>

Section: [<db_section>]

The PRIMARY setting specifies the size of the primary memory (in MB) with which the physical database file is created on the drive.
For z/OS, you must specify this value.

PROGRAM=<program>

Section: [<rpc_service>]

The PROGRAM setting specifies the physical name of the RPC service.
When a service request is issued, the RPC service is carried out. Whether you must specify a complete access path for <program> depends on the operating system and on how the operating system’s environment variables are set.
Under z/OS, you can specify a job that starts the RPC service:

PROGRAM=JOB:DSN:<PFX?>.<lib>(<job_name>)

where:

<PFX?> is the dataset prefix.

<lib> is the name of the job library.

<job_name> is the name of the job that starts the RPC service.

When creating the job, you must adhere to certain rules and use specific keywords. For detailed information, see the ASG-Rochade Programmer’s Guide Volume 3.

ROAPIMSG.<lang>=[@]<API_message_file>

ROCLIMSG.<lang>=[@]<client_message_file>

Section: [<rpc_service>]

These settings specify the names of the files or members containing the messages for API, communication, and client. The extension <lang> specifies the language. The English message files must always be available when the server is started.

For details, see Initialization File for Starting the RPL Client.

ROSRVMSG.<lang>=[@]<server_message_file>

Section: [<server_start>]

The ROSRVMSG setting specifies the name of the file or member that holds the server messages. The extension <lang> specifies the language. E means English and is currently the only language setting for the server. Under z/OS, the at sign (@) must not be used in this setting. For all other operating systems, it must precede the file name.
Under Windows and UNIX, the file name is specified. The file extension of the message file should be .imf (internal message file).

Example for Windows: ROSRVMSG.E=@d:\rochade\bin\rosrveng.imf

Under z/OS, the server messages are held in members of the library ROLOAD. For <server_message_file>, you must specify the member name SRVMSG#E.

Example: ROSRVMSG.E=SRVMSG#E

SECONDARY=<mb>

Sectiont: [<db_section>]

The SECONDARY setting specifies the size of the secondary memory (in MB) with which the physical database file is created on the drive.
For z/OS, you must specify this value.

SERVER1=<comm_section>

Section: [<rpc_service>]

The SERVER1 setting specifies the name of the communication section through which the service instance accesses the server.

SERVERACCESSPERMISSIONS=<role1>[;<role2>]...

Section: [<server_start>]

The SERVERACCESSPERMISSIONS setting restricts access to the Rochade Server by specifying a list of required LDAP roles. Only users who have one of the specified roles can access the server.
The role names can contain blanks. However, they must not contain semicolons.
The setting only takes effect if external authentication is used (ADBX setting). It is ignored if internal authentication is used or if no administration database is active.
If external authentication is activated during runtime, the value of the SERVERACCESSPERMISSIONS setting is read from the initialization file and the access restrictions are set accordingly.
Deactivating external authentication during runtime disables the access restrictions.
LDAP group search must be enabled (EnableGroupSearch setting). If it is not enabled, the activation of the external authentication is rejected (otherwise, no user would have access to the server). The server startup is canceled in this case.

You cannot use the SERVERACCESSPERMISSIONS setting with the setting AUTH_DB=WINDOMAIN. The external authentication via Windows domain does not support the LDAP group search.

SERVICE<n>=<rpc_service>

Section: [<server_start>]

The SERVICE<n> setting specifies that the service is described in the section <rpc_service>. If the section name is not found, the server terminates the startup procedure.
The number <n> identifies the service at the time of the server startup. Values between 1 and 32 are permitted for <n>; they need not be consecutive numbers.

SETLASTLOGONTIME=ON

Section: [<server_start>]

This setting specifies that the Rochade Server updates the attribute PWD_LAST_LOGON_TIME of the RO_ACCOUNT item after the user has been successfully logged in.

SETTINGS=ON | OFF

Section: [<audit_log>]

The SETTINGS setting specifies whether the modification of special settings is logged:

•

Any modification of these settings will be logged:

•

The separator character

•

The escape symbol

•

The audit log format

The modifications will be logged in this format:

SETTINGS: SEPARATOR=<sep> ESCAPE_SYMBOL=<esc> FORMAT=<fmt> VERIFY=<lastEsc>

where:

<sep> is the new separator character

<esc> is the new escape symbol

<fmt> is the new audit log format

<lastEsc> is the previous escape symbol

•

OFF

Default. The modification of settings will not be logged.

STATE = STARTING | RUNNING | TERMINATING | DOWN

Section: [<server_start>]

The STATE setting describes the status of the server. The server writes this setting to the start section of the initialization file.

•

STARTING

The server is in the startup phase.

•

RUNNING

The server is running and can accept requests.

•

TERMINATING

The server is terminating.

•

DOWN

The server has terminated.

STORAGECLASS=<storageclass>

Section: [<db_section>]

This setting is relevant only for z/OS operating systems.
The value of <storageclass> is the name of the SMS Storage class.
The section <db_section> must contain at least one of these settings: DATACLASS, MANAGEMENTCLASS, or STORAGECLASS.

SUPPRESS_MSG=OFF | ON

Section: [<server_start>]

This setting is required only under z/OS. It specifies whether information that cannot be written to the initialization file is to be logged to SYSPRINT. This happens when you specify the initialization file as an instream file in the jobstream.
The default for this setting is OFF, which means that information will be logged. If you set SUPPRESS_MSG=ON, information will not be written to SYSPRINT.

SYSUID=<sysuid>

Section: [<rpc_service>]

For a description of this setting, see Description of Client Settings.

TERMINATION_HANDLER=<program> [<par>...]

Section: [<server_start>]

The TERMINATION _HANDLER setting specifies that the operating system-specific program given in <program> is to be executed when the server is terminated. The program is called in this manner:

When starting the operating system-specific program, you can presume that these conditions are met:

The databases are closed.
The server event log is closed.
The LASTRC setting has been written to the server's initialization file, and the STATE setting has the value TERMINATING.
The server will be terminated only after the operating system-specific program has terminated.

As an example (under Windows), consider the effect of this excerpt from an initialization file:

...

TERMINATION_HANDLER=c:\bin\servend.bat

...

Let this be the content of servend.bat:

notepad %1

Then the effect is this:

Before the server is terminated, the batch file servend.bat is called and executed. The name of the server event log file is passed to this batch file as a parameter. The batch file displays the server event log in an editor. The server is terminated only after the editor is closed.

This mechanism is not supported under z/OS.

THREAD_POOL_PORT=<port_number>

Section: [<rpc_service>]

The THREAD_POOL_PORT setting specifies a port on which the RPC service listens for requests to start (or terminate) additional thread instances of the service.
The specified port must be available exclusively for the corresponding RPC service to accept TCP connections.

The Java API class de.rochade.rpcservice.RpcMain is especially suited for this type of multi-threaded RPC services.

TIMEOUT=<time>

Section: [<rpc_service>]

The TIMEOUT setting specifies the time (in seconds) within which a service instance must send a status message to the service monitor. If no status message is sent within this time, the service is aborted.
The default value for <time> is 300 seconds.

TIMEOUT_KILL=<time>

TIMEOUT_LOGON=<time>

TIMEOUT_READY=<time>

TIMEOUT_STAT=<time>

TIMEOUT_TERM=<time>

Section: [<rpc_service>]

These settings define the time limits (in seconds) that the server sets for a service instance to execute particular tasks.
TIMEOUT_KILL specifies the time the server waits before terminating a service instance if the service instance continues to exist after logoff from the server. The default value is 5 seconds.
TIMEOUT_LOGON specifies the time the server waits before terminating a service instance if the service, after its start, has not logged on to the server within that time period. The default value is 120 seconds.
TIMEOUT_READY specifies the time the server waits before terminating a service instance if the service instance is not ready to take on a new task after that time period following logon at the server or finishing a task or release ($RPC UNBIND). The default value is 60 seconds.
TIMEOUT_STAT specifies the time the server waits before terminating a service instance if the Watchdog function was active but no status message was returned by the service within that time period. The default value is 300 seconds.
TIMEOUT_TERM specifies the time the server waits before terminating a service instance if the service instance did not comply with a request to terminate itself. The default value is 30 seconds.

TRACEFILEPATH=<path_name>

Section: [<server_start>]

Specifies the path name of the directory in that clients save the trace files.
The path name must end with path separator (for example, \).
Under z/OS, trace files can only saved in FHS file systems. Saving the trace files in z/OS files or library members is not supported.

Example:

TRACEFILEPATH=d:\test\trace_dir\

TRUSTED_SITES=<trusted_sites>

Section: [<server_start>]

The TRUSTED_SITES setting specifies the name of the section that contains the required settings for single sign-on authentication. For details, see <trusted_sites> Section.

UPDATE_INDEX_DELETE_LIFETIME=<seconds>

Section: [<db_section>]

The UPDATE_INDEX_DELETE_LIFETIME setting specifies the retention time (in seconds) for that deleted entries are kept in the update index if all versions of the item to which the entry pertains have been deleted. For details, see Rochade Update Index.
<seconds> is a number between 84,400 (such as, 1 day) and 345,600,000 (such as, 4,000 days). The default value is 34,560,000 (such as, 400 days).

USER=ALL | SUCCESS | FAILURE | NONE

Section: [<audit_log>]

The USER setting specifies which user-specific log entries will be recorded in the audit log:

•

ALL

Default. User entries with the identification FAILURE as well as user entries with the identification SUCCESS are recorded in the audit log.

•

SUCCESS

Only user entries with the identification SUCCESS are recorded in the audit log.

•

FAILURE

Only user entries with the identification FAILURE are recorded in the audit log.

•

NONE

No user entries are recorded in the audit log.

User-specific log entries can be written with the command $OPER AUDIT_LOG.

UserAttributes=<u_section>

Section: [<alt_auth>]

The UserAttributes setting specifies a section that contains settings for accessing the attributes of LDAP user accounts. See <u_section> Section.