|Powered by QM on a Linux server|
Use of the QM multivalue database software is controlled by licence from Zumasys. This page provides an overview of the licensing policy.
What does the licence control?
A QM licence is issued to a named company or individual and is normally for use on a specific system identified by a system id code. The licence sets the maximum number of simultaneous users of the software, the platform (Windows, Linux, etc), the site text that will be displayed on entry to QM, and the availability of optional add-on components. There may also be an expiry date. Use within cloned virtual machine environments requires that each clone is separately licensed.
Each user of a QM system runs as a separate operating system process which falls into one of two broad classifications, interactive or phantom. Interactive processes are users connecting to a QM server via a terminal emulator, directly from the operating system command prompt (a console user), via the QMClient API or other route where the client side is controlling the actions of the server process. Phantom processes are background activity that has no direct interaction with the user. There is a special case of an interactive phantom (iphantom) which is a phantom process that has a accepted an incoming network connection, effectively becoming an interactive process.
The user limit set by the licence determines the maximum number of interactive processes, including interactive phantoms. Attempting to start a new interactive process when this limit has been reached will fail.
There is also a limit on the number of simultaneous phantom processes. This limit is normally eight plus a further one for each two licensed users after the first four. Some licences may have different rules for determination of the phantom limit. Attempting to start a new phantom process when the limit has been reached will check whether there are spare interactive users available and, if so, borrow one of these.
The QMNet subsystem that allows access to data on remote QM servers is built on an extension to the QMClient API. Opening a connection creates a QM process on the remote system that handles all QMNet activity for the same QM process on the local system. This consumes one licensed user on the remote system in addition to the licence used by the connecting process on the local system. This process terminates when the last QMNet file is closed although the NETDELAY configuration parameter can be used to keep the connection open briefly. QMNet has no additional impact on licensing on the local system.
Each child process created by the WEBSVC command to process incoming web requests consumes a licensed user, releasing it on termination.
The device licensing option allows multiple interactive connections from the same client device to share a licence. It has no effect on phantom processes. Device licensing is typically used to allow both a terminal emulator connection and a QMClient connection from the same PC. Device licensing is available in sizes of two, four or eight sessions per user. In the two session per user mode, for example, the first two users connecting from the same client device consume only a single licensed user. A third connection from the same device will consume a second licensed user. The system maintains these counters on a per-device basis such that if any one of these three users disconnects, the remaining two processes share the one licensed user.
Device licensing requires support in the client device. It is available with console users, AccuTerm, Winnix, QMClient and the largely obsolete QMTerm. Other terminal emulators will not take part in the device licensing system. Also, the licence terms state that device licensing may not be used with an intermediate layer that effectively makes multiple client devices appear to be just one device.
The connection pooling system allows a QMClient or phantom process to go into an idle state, waiting for new work to arrive. Except for non-interactive phantoms, the process continues to consume a licensed user whilst in the idle state. The pool timeout can be used to terminate the idle process if no new work arrives in a set time.