QMNet

QMNet uses the QMClient interface to provide an extension to the QM file system allowing network access to files on another QM system. Unlike use of NFS or mapped network drives, QMNet provides locking of remote records, ensuring that data integrity can be maintained on distributed data. Where both ends of the connection support it, the network traffic is encrypted.

Use of QMNet creates a server process on the remote system for each separate QM session that has one or more files open through QMNet. This process will consume a licence. If QM's security system is enabled on the remote system, the user name of the server process as defined using SET.SERVER must be registered for access to QM (see Application Level Security)

Two steps are necessary to use QMNet. Firstly, the server must be defined, mapping the server name to a network address, user name and password. Secondly, the remote file must either be defined using a Q-type VOC record or it may be accessed using the extended filename syntax server:account:file.

Defining the Server

QMNet supports two styles of server definition; public servers and private servers.

Public server definitions are available to all users of the system. They are created by a user with administrative rights in the QMSYS account using the SET.SERVER command and persist until they are explicitly deleted.

Private server definitions are local to the QM session in which they are defined. They are created using the SET.PRIVATE.SERVER command. On a secure system, access to this command may be restricted by the system administrator. A private server definition would normally be created dynamically by the application, either supplying the authentication details internally or prompting the user.

Both commands have the same form:

SET.SERVER name ip.address user.name password

and prompt for items not provided on the command line. The remote server must have remote access enabled by setting the NETFILES configuration parameter to 2.

A server defined with the SET.SERVER command can be accessed by all users. The ADMIN.SERVERS command can be used to create or modify server definitions to apply restrictions on which users can access the server.

Defining the Remote File

Each remote file is defined by an extended form of the Q-type VOC entry where field 4 contains the name of the server.

Once the file has been defined, it may be accessed by programs in the same way as a local file. The following restrictions apply to access from QMBasic programs:

•The OPENSEQ statement and related sequential file access operations are not supported.

•Access to remote files inside transactions will be non-transactional.

•The FILEINFO() function will return the file type as FL$TYPE.NET (6). Some modes of FILEINFO() are not supported.

•A maximum of 10 servers may be accessed at one time by any one QM process. There is no practical limit to the number of files that may be open on each server.

Listing Server Definitions

A list of all defined QMNet servers accessible by the user can be displayed using the LIST.SERVERS command.

LIST.SERVERS {ALL}

The ALL option, available only to users with administrative rights, includes servers to which the user has no access.

Deleting a Server Definition

The definition for a remote server may be deleted using the DELETE.SERVER or DELETE.PRIVATE.SERVER command. Deletion of public server definitions is restricted to users with administrative rights in the QMSYS account.

DELETE.SERVER name

Server Security

The default behaviour of the SET.SERVER command is to create a server definition that may be accessed by all users of the system. There is a potential security weakness here because the slave process started on the remote system to handle the QMNet connection runs as the user name specified in the server definition, regardless of the user name of the local user accessing the remote file. Security can be improved by arranging that the user name used for the remote slave process is dependent on the user name or user group of the local user. This can be achieved by use of the ADMIN.SERVER command or an extended form of the SET.SERVER command.