Mimer SQL Documentation TOC PREV NEXT INDEX

Mimer SQL Developer Site

Networking Setup

There are different system features available to administer this depending on platform and operating system versions. Currently inetd, xinetd, systemd and launchd are supported, where the first two are described more in detail below. The last one, launchd, is used on macOS.

The miminitd command is used to handle the networking setup. This is done automatically during the installation.

inetd setup

The Linux command inetd is the Internet services daemon, the server process for the Internet standard services. It is usually started up at system boot time. The configuration file /etc/inetd.conf lists the services that inetd should handle. An excerpt from the file shows the syntax used in the file:

 # Syntax for socket-based Internet services:
 #  <service_name> <socket_type> <proto> <flags> <user> <server_pathname> 

When dbinstall is executed, and the inetd.conf file is found, the following line is added to the configuration file:

 mimer stream tcp nowait root /usr/bin/mimtcp mimtcp -l

This indicates that mimtcp should be started for the mimer service. The -l option is used standalone which implies that the default log file should be used.

When the inetd configuration is changed, for example if mimer is added like described above, the inetd daemon must reread it. This is triggered by sending the HUP signal to the inetd process (located using the ps -ef command):

 # ps -ef | grep inetd
 root      8796     1  0  2006 ?        00:00:12 inetd
 # kill -HUP 8796

xinetd setup

The Linux command xinetd stands for "the extended Internet services daemon". It is the successor to inetd and works in a slightly different way. Instead of having tasks started at system initialization time, and be dormant until a connection request arrives, xinetd is the only daemon process started and it listens on all service ports for the services listed in its configuration file. When a request comes in, xinetd starts the appropriate server.

The default xinetd definitions for Mimer SQL can be found in the file mimersql.xinetd in the installation directory called misc:

 $ cat /opt/MimerSQL-11.0.1A/misc/mimersql.xinetd
 # default: on
 # description: The MIMER service allows remote users to access the
 #              Mimer SQL database servers on this node.
 service mimer
         port            = 1360
         socket_type     = stream
         wait            = no
         user            = root
         server          = /usr/bin/mimtcp
         server_args     = -l
         log_on_failure  += USERID
         disable         = no
         protocol        = tcp

If the /etc/xinetd.d directory is found when dbinstall is executed, the mimersql.xinetd file is copied there and is given the name mimer.

If the /etc/xinetd.d is not found, but /etc/xinetd.conf is found, the mimersql.xinetd contents is added at the end of the /etc/xinetd.conf file.

When the xinetd configuration is changed, for example if mimer is added like described above, the xinetd daemon must reread it. This is triggered by sending the HUP signal to the xinetd process (located using the ps -ef command):

 # ps -ef | grep xinetd
 root      8796     1  0  2006 ?        00:00:12 xinetd
 # kill -HUP 8796

Using odbc.ini data sources

The standard ODBC odbc.ini file and the Mimer SQL sqlhosts file are related to each other in both being repositories for databases, or data sources. When using ODBC to connect to a Mimer SQL database, data source names (DSN) defined in the odbc.ini file can be used. In this case the odbc.ini file is accessed first, and only if needed the ordinary database lookup is done in the /etc/sqlhosts file.

When a Mimer SQL database is created using the dbinstall command, it gets defined in the sqlhosts file in the LOCAL section. For example, if creating the database named my_db with the home directory /usr/local/MimerSQL/my_db, it will end up in /etc/sqlhosts like this:

    my_db          /usr/local/MimerSQL/my_db

If an ODBC Driver Manager is installed, there will also be an option to automatically define it in the global odbc.ini file, usually located as /etc/odbc.ini. Such a definition will look like the following:

 Driver    = /usr/lib/libmimodbc.so
 Database  = my_db
 Host      = localhost
 Port      = 1360
 Trace     = No
 TraceFile = /tmp/mimersql.log

We can now look at a simple example where the Perl DBI/DBC-ODBC interface is used to connect to a Mimer SQL database:

 #!/usr/bin/perl -w
 use DBI;
 $dbh = DBI->connect($data_source, $username, $auth) or die $DBI::errstr;
 print "Connected! ($dbh)\n";

In this case the my_db definition in the odbc.ini file will be used, more precisely the attributes Driver, Database, Host and Port are used:

The ODBC driver to be used, specific to each database kind. For Mimer this is the libmimodbc.so shared library.
The name of the database to be accessed, as defined in the sqlhosts file on the node where the database resides.
The name of the computer node where the database resides. If this attribute is left out, the value of the Database attribute will be looked up in the /etc/sqlhosts file for further information about the connection setup.
The port number to used for the database communication. If this attribute is left out, the default '1360' will be assumed.

Assuming a Mimer SQL database on a remote computer is defined in the REMOTE section of the sqlhosts file as follows:

    prod_db     typhon.mimer.se    tcp   ''    1360

Also, assuming we have the following DSN defined in the odbc.ini file:

 Driver = /usr/lib/libmimodbc.so
 Database = prod_db

To connect to the prod_db database on the typhon.mimer.se node using the program example above, we can simply change the data source definition in the program above to:


The data source remote_prod will be looked up in odbc.ini. The database name prod_db will be encountered, but there is no host defined so an attempt will be made to find appropriate connection information for the given database in the sqlhosts file. When the node typhon.mimer.se and the port 1360 are identified for the database name, the connection will be completed.

The ODBCINI environment variable can be used to point out the odbc.ini file to be used.

Note: Tabs are not allowed in the odbc.ini file.

Mimer Information Technology AB
Phone: +46 18 780 92 00
Mimer SQL Documentation TOC PREV NEXT INDEX