QMNet Network File Access


Top  Previous  Next


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. The NETWAIT configuration parameter can be used to amend the default 10 second timeout that is applied when opening the connection.


The server process will consume a licence except where device licensing allows this to be shared with another connection from the same source. The server process will terminate when the local system closes the final file on that server but the NETDELAY configuration parameter can be used to keep the server process alive for a short period to improve performance of applications that repeatedly open files on the same server.


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 and take priority over a public server definition of the same name. The SECURITY configuration parameter can be used to disallow creation of private server names that are also defined as public servers, preventing a malicious user redirecting a QMNet connection. If QM's security system is enabled, 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.SERVER 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.

A maximum of 10 separate 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.




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.





Diagnosing Connection Problems


There are many reasons why a newly defined QMNet server may fail to connect. These include issues with firewalls, access rights, configuration settings, etc. The FIND.FILE command is a useful diagnostic aid when investigation connection issues.



Locking QMNet Files


An application may use record and file locks on files opened via QMNet using exactly the same methods as for local files. The lock is maintained on the remote system and will not appear in the output from a LIST.READU command or the QMBasic GETLOCKS() function on the local system.



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.



See also: