The Service Database

The service database provides a way to associate arbitrary human-readable strings with the parameters needed to uniquely identify a particular protocol service. The strings are passed to lgo_Open() and lgo_Attach() to identify the service.

The default service database is service.db located in the cfg directory. This is a text file which can be edited with any text editor, such as the Windows editor notepad.

Each line in the service database has the following format:

<service> <protocol> <major device> <minor device> <cfg file>

where

• <service> is the string which identifies the service. The limit is 31 characters, no white space, not case sensitive.
• <protocol> is protocol ID number from laygodef.h.
• <major device> is id of the physical line to use. Valid values are 0 through 1 less than the number of configured lines.
• <minor device> is the LCN for X.25 or the DLCI for Frame Relay Permanent Virtual Circuits (PVCs). X.25 Switched Virtual Circuits (SVCs) are assigned LCNs and DLCIs dynamically, so the value should be 0. Valid values depend on the protocol and network service subscription.
• <cfg file> is the name of a configuration file for the service. This field is not currently used. null.cfg indicates the default configuration should be used.

The # character in the first column is the comment marker. Comments and blank lines are ignored.

The service names in the default database have the form:

<protocol><major>[<minor>]

For instance:

#
#	X.21 bis
#
PHYS0    4    0    0    null.cfg
PHYS1    4    1    0    null.cfg
PHYS2    4    2    0    null.cfg
PHYS3    4    3    0    null.cfg

#
#    HDLC LAPB
#
LAPB0    5    0    0    null.cfg
LAPB1    5    1    0    null.cfg
LAPB2    5    2    0    null.cfg
LAPB3    5    3    0    null.cfg

#
#    X.25 Major Device with SVCs and 8 PVCs
#
PKT0     6    0    0    null.cfg
PVC01    7    0    1    null.cfg
PVC02    7    0    2    null.cfg
PVC03    7    0    3    null.cfg
PVC04    7    0    4    null.cfg
PVC05    7    0    5    null.cfg
PVC06    7    0    6    null.cfg
PVC07    7    0    7    null.cfg
PVC08    7    0    8    null.cfg

However, any strings can be used. For instance, for a connection to Dallas on physical line 0, you might name X.21 bis, HDLC LAPB and X.25 major device services DALLAS_X21, DALLAS_LAPB and DALLAS_X25. X.25 PVCs on that line might be designated DALLAS_1, DALLAS_2, etc. If the connection to Dallas later changes to line 3, only the service definitions need to be changed.

A single service definition may have multiple names. For instance, if physical line 0 is sometimes used for a connection to Dallas, sometimes for a connection to Paris, PARIS_X21, PARIS_LAPB and PARIS_X25 might be defined in the same way as DALLAS_X21, DALLAS_LAPB and DALLAS_X25. In this case, the connection to Paris could not be opened at the same time as the connection to Dallas.

Note: Use of the service database is optional (but recommended). The parameters associated with the service name can be passed directly as parameters to lgo_OpenProtocol() and lgo_AttachProtocol().