The MULTIDEFS File on VMS and Linux

This appendix applies to the OpenVMS and Linux (including macOS) platforms only.

It describes the MULTIDEFS file which forms part of a local database definition, see The Local Database, for a database residing on an OpenVMS or Linux node.

This file contains operational parameters for the database server for such a database and these are read when the database server is started. It is not possible to change the parameters for a running database server.

The MULTIDEFS Parameter File

Comments in MULTIDEFS are introduced by the character sequence --, or by the character ! or #.

A new MULTIDEFS file can be generated by using the command:

mimcontrol -g


If the MULTIDEFS file is not found when starting a database server, the MIMCONTROL command will create a new file and fill it with the default values for all parameters.

Linux:On a Linux node, the MULTIDEFS file is located in the database home directory and is called multidefs.


VMS:On an OpenVMS node, the MULTIDEFS file is located in the database home directory and is called MULTIDEFS.DAT.

The actual default values used may vary and may depend on factors like machine type and the amount of physical memory available on the machine.

The following is an example of the MULTIDEFS parameter file which may be generated by MIMCONTROL:

Example of MULTIDEFS File on Linux

-- Mimer SQL version 11.0.5A parameters generated 2021-01-18 10:31

Databanks          100                 # Max # of databanks (20-1000)

Tables             4000                # Max # of tables (500-1000000)

ActTrans           20000               # Max # of active trans (500-1000000)

SQLPool            1000                # Initial SQLPool (400-8388607 kb)

RequestThreads     8                   # # of request threads (1-100)

BackgroundThreads  3                   # # of background threads (1-100)

TcFlushThreads     1                   # # of t-cache flush threads (0-20)

Users              100                 # Max # of logged in users (1-5000)

DBCheck            1                   # DB check, 0=index, 1=all, 2=immediate,

                                         3=im. index, 4=im. all (0-4)

Pages4K            206867              # # of 4K bufferpool pages (11-2147480000)

Pages32K           18784               # # of 32K bufferpool pages (7-2147480000)

Pages128K          2187                # # of 128K bufferpool pages (0-2147480000)

DelayedCommit      0                   # Delayed commit, 0=Off 1=On

                                         2=Disabled (0-2)

DelayedCommitTimeout 100               # Delayed commit timeout in milliseconds


GroupCommitTimeout 2                   # Group commit timeout in milliseconds


Oper                                   # Receivers for messages

DumpPath           .                   # Path for dump directory

TCPPort            inetd               # TCP/IP port

MaxSQLPool         216000              # SQLPool max size (2400-16777215 kb)

NetworkEncryption  1                   # Client/server encryption, 0=None

                                         1=Optional, 2=Required (0-2)

MemLock            0                   # Lock bpool in memory, 0=No 1=Yes (0-1)

MiniDump           1                   # Small bufferpool dump (no page content),

                                         0=No 1=Yes (0-1)

BackgroundPriority 0                   # Thread priority, 0=Default, 1=Highest,

                                         40=Lowest (0-40)

AutoStart          1                   # Autostart, 0=No, 1=Yes (0-1)

DumpScript         ./ %p     # Dump Script

ServerType         3                   # Server type: 3=mimexper, 7=miminm (3-9)

IOQueue          128                   # Max # of concurrent I/O requests


Example of MULTIDEFS File on OpenVMS

-- Mimer SQL version 11.0.3C Beta Test parameters generated 2020-05-03 22:30

Databanks          100                 # Max # of databanks (20-1000)

Tables             4000                # Max # of tables (500-1000000)

ActTrans           20000               # Max # of active trans (500-1000000)

SQLPool            1000                # Initial SQLPool (400-8388607 kb)

RequestThreads     8                   # # of request threads (1-100)

BackgroundThreads  3                   # # of background threads (1-100)

TcFlushThreads     1                   # # of t-cache flush threads (0-20)

Users              100                 # Max # of logged in users (1-5000)

DBCheck            1                   # DB check, 0=index, 1=all, 2=immediate,

                                         3=im. index, 4=im. all (0-4)

Pages4K            206867              # # of 4K bufferpool pages (11-33554432)

Pages32K           18784               # # of 32K bufferpool pages (7-4194304)

Pages128K          2187                # # of 128K bufferpool pages (0-1048576)

DelayedCommit      2                   # Delayed commit, 0=Off 1=On 2=Disabled


DelayedCommitTimeout 100               # Delayed commit timeout in

                                         milliseconds (0-60000)

GroupCommitTimeout 2                   # Group commit timeout in milliseconds


Oper               OPER                # Receivers for messages

DumpPath           <> # Path for dump directory

TCPPort            1360                # TCP/IP port

MaxSQLPool         216000              # SQLPool max size (2400-16777215 kb)

MemLock            0                   # Lock bpool in memory, 0=No 1=Yes (0-1)

MiniDump           1                   # Small bufferpool dump (no page content)

                                         , 0=No 1=Yes (0-1)

DECPort            MULTI               # Decnet network object

ProcName           MULTI               # Process name prefix

NetUsers           5000                # Max # of network users (1-5000)

ServPrio           5                   # VMS prio for server process (0-16)

Cleanup            60                  # Cleanup interval (1-10000 seconds)

Multithread        0                   # Kernel thread limit (0-64)

BPResident                             # Bufferpool resident area name

HomeRAD            -                   # Home RAD

MULTIDEFS Parameters




Specifies the maximum number of databank files that the database server can have open at any one time.


Specifies the maximum number of tables that can be accessed simultaneously by the database server.


Specifies the maximum number of transactions that can be active in the database server.


Initial size of the SQLPool area in K bytes. This area contains information about each session, i.e. opened tables and databanks, compiled SQL programs, etc. The SQLPool area will expand automatically if it is too small, but it will not be larger than MaxSQLPool.


The number of threads in the database server that can serve client requests.


The number of background threads in the database server.


Extra threads that run in the background to help clear the transaction cache. This is beneficial for systems with long-running transactions. The thread keeps the size down of the transaction cache by deleting records that are no longer used. When there are no long running transactions the cache can be cleared efficiently without scanning the cache so in this case the thread is not needed. Default is 1 thread. To get the same behavior as in version 10.0 specify 0 threads for this parameter. For very large databases with long-running transactions more than 1 thread can be used.


The maximum number of users that are allowed to connect to the database server. This parameter should not exceed the number of users specified in the Mimer SQL license key.

This number is also used to calculate the size of the shared memory region used for local database server communication. About 70 Kbytes of shared memory will be allocated for each user.


A number which specifies what kind of check that should be performed when a databank is opened which previously was not closed properly.

0 - check index pages

Index pages only are checked in the foreground while applications that access the databank waits for the operation to complete.

1 - check data pages

A full databank check (involving index and data pages) provides for more secure operations, but may take much longer to execute than an index page check. When a full check is done, the index pages are checked in the foreground and the data pages are checked in the background so there is a smaller effect on performance.

2 - Immediate restart, no check

This options performs no checking when the file is opened. The system still verifies the integrity of each page through a checksum. A few pages may have been pre-allocated and these are not reclaimed when this option is used. If the option is subsequently changed these pages will be reclaimed the next time the databank is opened.

3 - Immediate restart, check index pages

This option performs a check of all index pages in the databank in the background. This is done concurrently with other operations on the system.

4 - Immediate restart, check all pages

This option performs a check of all pages in the databank in the background. This is done concurrently with other operations on the system.

The Immediate restart options require a license key called “Imm Restart”.

Databank checks can be avoided by always shutting down the database server properly with the MIMCONTROL command, especially prior to shutting down the machine.


The number of 4 Kbytes pages in the bufferpool area containing pages from the databank files. The default value of this parameter is 12.5% of the total RAM memory in the machine.

VMS:There may be an OpenVMS limit set for the amount of memory a process may allocate, this limit will not be exceeded. Among the various OpenVMS parameters, WSMAX is likely to be of primary interest in connection with this limit.


The number of 32 Kbytes pages in the bufferpool area containing pages from the databank files. The default value of this parameter is 8.33% of the total RAM memory in the machine.


The number of 128 Kbytes pages in the bufferpool area containing pages from the databank files. The default value of this parameter is 5% of the total RAM memory in the machine.


This option controls how quickly a transaction commit is secured on disk. It greatly affects the performance of the database server. For example, if a single user commits two transactions in quick sequence the database server may use a single I/O to secure both transactions when delayed commit is on.

Transactions are never reordered by using the delayed commit option. I.e. it is not possible for a later transaction to be secured on disk before an earlier one. The database is thus always returned to a consistent state after a machine crash. However, if a transaction has been committed but not yet written to disk it will be lost if the database server or machine goes down in an uncontrolled fashion.

Transactions that use the XA transaction protocol are automatically committed with delay commit disabled.

Delayed commit option can be set to one of the following:

0 - Default off

In this mode delayed commit is not used unless a transaction is set to use delayed commit by the application. This is the default.

1 - Default on

In this mode all transactions where the delay mode has not been explicitly set are delayed. The transaction will be secured within the time-out period specified. If other transactions are committed before the time-out occurs the transactions may be combined into a single I/O to boost performance.

2 - Disabled

In this mode all transactions are secured to disk immediately and the application will not regain control after a commit until the transaction has been secured. This option overrides any application settings for delay commit.


This specifies the number of milliseconds to wait before the transaction is written to disk. If a value of zero is specified transactions are not flushed until the server determines that the commit set page is full. In general, this is not recommended as transactions are likely to be lost if there is an uncontrolled machine stop.

Default is 100 milliseconds.


VMS:Enable password login:
0 - password login disabled. (Only OS_USER login possible.)
1 - password login allowed.


How many milliseconds to wait for other transactions to commit before proceeding with first transaction. If another transaction arrives within the timeout period if will be grouped with existing transactions before they are committed together with a single I/O rather. This improves overall performance but the delay prolongs commits time on a system with low load. Default is one millisecond.


This parameter gives a list of host system users, i.e. operators, or e-mail addresses that should receive e-mail notification of serious problems with the database server.

VMS:On OpenVMS, you can also specify OPER.

This will enable that notification messages are sent to the central operator, i.e. processes that have set:



This parameter may specify an alternate path for the dump directories. The default is to create dump directories under the database home directory.


Specifies how the database server should handle incoming TCP/IP connection requests. If this parameter is set to - (a single dash), the TCP/IP capability will be disabled for the database server.

Linux:On Linux, the TCPPort parameter is, by default, set to inetd which means that the TCP/IP port server program, mimtcp, will be used for establishing a connection to any Mimer SQL database server (of version 8 and later). In this case clients may connect to the port to which mimtcp listens, usually 1360, and the handshake will be passed over to the requested Mimer SQL database server.

If a TCP/IP port number is specified, the database server will listen directly to that port.

VMS:On OpenVMS, the TCPPort parameter is, by default, set to the TCP/IP port number 1360. The TCP/IP port server program, MIMTCP, will automatically be started to listen to the given port, serving all Mimer SQL database servers (of version 8 and later) set up to use that port.


The maximum size (in kilobytes) of the SQLPool. The SQLPool memory area grows dynamically, but the size will never exceed this parameter. Use this parameter to control the maximum virtual size (maximum page file usage) for the database server process.


Controls the use of encryption of network communication over TCP/IP between server and clients.

0 = Network encryption disabled

Network encryption is not supported or not used.

1 = Network encryption preferred

Network encryption is enabled for version 11 clients. Older clients use unencrypted network communication. When this setting is used, older clients without support for network encryption are allowed to communicate with the database server over TCP/IP.

Use this option when there is a mix of older and newer clients that communicate with the database server over TCP/IP.

This is the default value.

2 = Network encryption required

The database server requires all clients to use encrypted communication when communicating over TCP/IP. Clients that do not support encryption are rejected at login with error code -18531.

Named Pipes via OS-user login is not allowed.

This option is recommended over option 1 when possible (i.e. when there are no older clients that need to be supported.)


A number which specifies whether the bufferpool and communication buffers should be locked in memory (1) or not locked in memory (0).


Small bufferpool dump (no page content).
0 = No
1 = Yes (default)


Linux:Specifies if the background threads should run at a higher priority than other server threads. Default is 0 meaning that the priority is not changed. Valid values are between 1 and 40, where 1 is the highest priority and 40 the lowest. A priority of 20 will give the same priority as the default value.

During certain circumstances like in situations where the background threads cannot manage to shorten a transaction queue a higher priority might help. Giving a too high priority might have unexpected side effects.

To be able to change the thread priority Linux capabilities is used. To allow the Mimer SQL executable to do this the setcap command is used:
sudo setcap CAP_SYS_NICE+iep  /opt/mimersql1103-11.0.3D/bin/mimexper

To do this the libpam-cap needs to be installed, and the user that will manage the Mimer SQL database must be give permissions to change priorities. This is done by adding CAP_SYS_NICE <user> after the line that says none * in /etc/security/capability.conf.


Linux:By default, this parameter is set to 1 which indicates that the database should be started automatically when the operating system goes into multi-user mode. If the parameter is set to 0 the database will not be started automatically.


Linux:If the database server goes into an erroneous and unrecoverable state, it will produce dumps of the current internal database structures before it goes down. If this situation occurs, it is of great importance for the error detection process to get a Linux kernel stack trace from the location where the error was located.

By defining this parameter to a command that can produce a kernel trace, such as pstack, stack information will be automatically generated to mimer.log. The %p option, used in the example above, is used to get the current process ID as a parameter to the command given.


VMS:Specifies the DECNET network object that the database server listens to. Each database server must use a unique network object. The default value is the database name.

If you set this parameter to - (a single dash), the DECNET capability will be disabled for the database server.


VMS:This parameter specifies the process name prefix for the database server. (The last part of the process name is always Srv).

Specify a maximum of 11 characters. The default value is to use the first 11 characters of the database name.


VMS:This parameter specifies the number of users who can access the database through a network connection.

The value used by the system will be the minimum of this parameter and the Users parameter. The default value is 5000.

Since the Users parameter can not be larger than 5000, this means that all users may be network users.


VMS:This parameter specifies the OpenVMS priority for the database server process.


VMS:Specifies the time (in seconds) between the cleanup sweeps that check for terminated database clients.


VMS:If the BPResident parameter is blank (default) the bufferpool will be allocated in normal process memory and is backed by the paging file. The paging file process quota for the database server will be increased accordingly.

If the BPResident parameter specifies a name, a memory resident global section with this name will be created to hold the buffer pool. Since physical memory is used, the buffer pool will not be backed by the paging file. Also, the working set quota of the process does not have to include the buffer pool. This is recommended for larger buffer pools.

To use the BPResident parameter, the user that starts the database server must hold the VMS$MEM_RESIDENT_USER process right.

Please see the VMS Guide for more information.


VMS:Multithread can be used to limit the number of kernel threads used by a database server. When running several instances of Mimer servers on a machine with a large number of cores, it can be beneficial to limit the number of kernel threads (and the number of cores) each database server can use.

The default value is zero, which means that the number of kernel threads are not limited.

This feature requires OpenVMS 8.4 or later.


VMS:The parameter HomeRAD can be used to specify a Home RAD (Resource Affinity Domain) for the database server process. If a server hosts multiple Mimer database servers, it can be beneficial to start the servers in different RAD’s.

An article in OpenVMS technical Journal V16 about RAD support on Integrity servers can be found here:

The default value of the HomeRAD parameter is - (a minus sign), which means that no HomeRAD is set. By specifying a number, the database server process will use the specified RAD as its home RAD.

If you specify a Home RAD and also specify a memory resident global section (parameter BPResident), you should create the section in the same RAD.


This option decides which Mimer SQL database server program that should be started to operate the database files for the database:

3 - mimexper

The Mimer SQL Experience database server. This is the standard database server. See Mimer SQL Experience Database Server.

7- miminm

The Mimer SQL In-memory database server. See Mimer SQL In-memory Database Server.


Linux:Specifies the maximum number of concurrent IO requests queued to the operating system. Default is 128, but more advanced disk systems such as SANs, battery backed caching IO controllers, PCI Express connected SSDs and NVMe SSDs can make use of larger queues. This can give a significantly higher database performance. However, specifying a too large queue can overload the IO subsystems. Maximum queue length is 65535.