C. The applcomm.db File Format

Accelrys applications store this information in a human-readable file similar in concept to the UNIX file /etc/services, which lists network services and the ports on which they are available. This application communications database file is named applcomm.db.

Under normal circumstances, applcomm.db is edited automatically during installation of the invoking Accelrys application and does not need to be altered. This appendix documents the file's format for those cases when you need to augment the information in this file.

File contents

The applcomm.db file contains records describing machines in the network, possible communication protocols, and applications that can be run on those machines.

Three different types of records can appear in this file. The symbol in the first position of each line is a control character and must be one of the following:

# - Comments

M - Records describing machines in the network

P - Records describing communication protocols

A - Records describing applications

The following points apply to record lines in general:

Empty records (containing only spaces and/or tabs) are legal and are treated as comments

All other records are ignored, but a warning message is displayed with the contents of the ignored record

Fields in the records are separated by spaces and/or tabs

Records describing machines

The following points apply to record lines that describe machines on your network:

Machines can be (but need not be) grouped in classes. There is no special meaning in the class name, with the exceptions of MVS and manual.

One machine may belong to more than one class.

Classes (and machines) can also be grouped. However, looping is forbidden: if class A belongs to class B, class B may not belong to class A.

Grouping in classes helps the coding of A-records.

If a machine is not defined in any M-records, it gets assigned the class default.

The format of an M-record is as follows:

M class machine1 [machine2...]

where:

class Name of the class, which can be any arbitrary name.

machine Name of a remote machine or a machine class.

Examples:

# SGI

M slow beauty bohr clover dirac watson

M medium bam-bam buster dino gomez ram

M fast altoid newton null

M Indigo ram buster dino null

M sgi slow medium fast Indigo

# Other machines

M rios hanz franz hogan

M hp720 avoid devoid

# all of them

M unix sgi rios hp720

Records describing supported network protocols

The format of a P-record is as follows:

P protocol machine1 [machine2...]

where:

protocol Either unix or tcp

machine Either the actual host name or a class name as defined in an M- record

If a machine is not defined in any P-records, UNIX protocol is accepted for a local UNIX machine, and tcp otherwise.

Examples:

P unix unix

P tcp unix eagle.tc.cornell.edu rain.cray.com

Records describing supported applications

The format of an A-record is as follows:

A machine application executable [argument[...]] Aclass application executable [argument[...]]

where:

machine Actual host name on which application is available

class A machine class, defined by an M-record

application The application name (charmm, xplor, and so on)

executable The command that should be executed on the machine to run the application (If this

command does not exist in the user's default path, the full path name must be given in the A-record.)

argument Any argument that must be passed to the application

An A-record is necessary for every application that you want to start by using the Accelrys remote job module.

Examples:

A remote_unix rjrd /home/accelrys/quanta/exec/rjrd

A remote_unix xplor /home/accelrys/xplor/xplor.bat

Example applcomm.db file entries

The following applcomm.db extract contains example entries for quantum applications.

# These lines specify the locations of the ADF

# files. You may need to alter the specifications

# if you want to run ADF on a machine on which you do

# not have Cerius2 licensed. A SGI adf c2_install_dir/exec/adf.exe

A SGI ADFBIN c2_install_dir/adf/bin

A SGI ADFUTILITIES c2_install_dir/adf/bin

A SGI ADFRESOURCES c2_install_dir/Cerius2-Resources/ADF/atomicdata

# The following line specifies the location of the main

# Gaussian 92 directories. Replace the path name with that

# for your own installation. If you don't have Gaussian

# 92, omit this line.

A SGI g92root /usr/mydir/gaussian92

# The following line specifies the location of the main

# Gaussian 94 directories. Replace the path name with that

# for your own installation. If you don't have Gaussian

# 94, omit this line.

A SGI g94root /usr/mydir/gaussian94

# The following lines specify an alternative location for the

# Gaussian 92 and Gaussian 94 scratch directories. If this

# line is omitted, the current working directory is used.

A SGI g92scratch /usr/disk2/gaussian.scratch

A SGI g94scratch /usr/disk2/gaussian.scratch

# The following two lines are standard. Only change them

# if you have a non-standard installation, or if you

# want to run mopac on a machine on which you do not

# have Cerius2 installed.

A SGI mopacdir c2_install_dir/mopac

A SGI mopac6exe c2_install_dir/mopac/mopac6.exe

# The following line specifies the location of the MOPAC7

# executable. If you don't have MOPAC7, omit this line.

A SGI mopac7exe /usr/mydir/mopac7/mopac7_sgrw/mopac.exe

# The following line specifies the location of the MOPAC93

# executable. Replace the path name with that of your own

# installation. If you don't have MOPAC93, omit this line.

A SGI mopac93exe /usr/mydir/mopac93/m93_src/mopac93.exe

# The following line specifies the location of the

# DMol3 executable. Only change it if you have a

# non-standard installation, or if you want to run DMol3

# on a machine on which you do not have Cerius2 installed.

A SGI dmol3exe c2_install_dir/exec/dmol3