Zim Server has many possible configurations. multi-user single-user  

Zim Integrated Server

Usually, the Database Agent process accesses a local Zim database (local refers to relationship to the server). The Database Agent process is started much like any version of Zim: it has its own working directory; it uses Zim directory files to look up object names used in client requests; it uses areas.zim and dirs.zim in the standard way; and so on.

While a Zim database is being accessed by one or more Database Agent processes, it can also be accessed directly from a local multi-user Zim application, such as from a full Zim system, a query runtime system, or a runtime system.

When the Database Agent process receives a request to access a specific table, that table name is looked up in Zim directories. If the table is defined to be managed by another server (e.g. Oracle or another Zim Integrated Server), the Database Agent process uses the appropriate Server Access Module (SAM). For example, a Zim application running on Windows could access a table being managed by Zim Integrated Server running on an IBM platform. That server, in turn, could detect that the table is, in fact, managed by another Zim Server on an HP platform, so the request would be passed to the HP one. The Zim Server there could detect that, in fact, the table is really managed by Oracle running on a Linux environment, and so the request would be passed (by means of an Oracle SAM running on the HP) to Linux. See the diagram below.

Example of Possible Server Configurations

Client

A client process can connect to one or more Zim Servers at the same time. However Zim Database Agent processes (which can be on different machines) do not provide support for distributed deadlock detection or distributed transaction commit. As a result, two clients can deadlock each other. In addition, if a transaction updates information across more than one server, failures at either server or in communications could result in the transaction not being completely committed.

Because of Zim’s multi-server capability, a Zim application can concurrently access a local Zim database (local to the application), zero or more Zim databases managed by Zim Integrated Server, and zero or more third party databases (such as Oracle, DB2/2, etc.).

Example of Other Client Configurations