The next section describes the connectivity information that is in each field of the sqlhosts file.
The database server name field (dbservername) gives the name of the database server for which the connectivity information is being specified. Each database server across all of your associated networks must have a unique database server name. The dbservername field must match the name of a database server in the network, as specified by the DBSERVERNAME and DBSERVERALIASES configuration parameters in the ONCONFIG configuration file. For more information about these configuration parameters, refer to ONCONFIG Parameters for Connectivity.
The dbservername field can include any printable character other than an uppercase character, a field delimiter, a newline character, or a comment character. It is limited to 128 characters.
If the sqlhosts file has multiple entries with the same dbservername, only the first one is used.
The sqlhosts information must include the name of each coserver and the name of the group to which the coserver belongs.
The database server uses the dbservername field as the key to an index to look up the connectivity information in the remaining fields in the sqlhosts file. Specify a coserver name in this field. For a single-coserver system, the sqlhosts file should contain two entries:
For a single-coserver system, set INFORMIXSERVER to either the database server name or the coserver name. See Required Environment Variables.
The field can also contain the name of a dbserver group. For more information about database server groups, refer to Group Information.
The connection-type field (nettype on UNIX or PROTOCOL on Windows NT) describes the type of connection that should be made between the database server and the client application or another database server. The field is a series of eight letters composed of three subfields, as Figure 11 shows.
The following sections describe the subfields of the connection-type field.
The first two letters of the connection-type field represent the database server product.
For information about DRDA, refer to the IBM Informix: Enterprise Gateway with DRDA User Manual.
The middle three letters of the connection-type field represent the network programming interface that enables communications. For more information, see Network Programming Interface.
Interprocess communications (IPC) are used only for communications between two processes running on the same computer.
The final three letters of the connection-type field represent the network protocol or specific IPC mechanism.
IPC connections use shared memory or stream pipes. The database server supports two network protocols: TCP/IP and IPX/SPX.
Table 5 summarizes the possible connection-type values for database server connections.
For information on the connection types for your platform, see Connections That the Database Server Supports.
The host name field (hostname) contains the name of the computer where the database server resides. The name field can include any printable character other than a field delimiter, a newline character, or a comment character. The host name field is limited to 256 characters.
The following sections explain how client applications derive the values used in the host name field.
When you use the TCP/IP network protocol, the host name field is a key to the hosts file, which provides the network address of the computer. The name that you use in the host name field must correspond to the name in the hosts file. In most cases, the host name in the hosts file is the same as the name of the computer. For information about the hosts file, refer to TCP/IP Connectivity Files.
In some situations, you might want to use the actual Internet IP address in the host name field. For information about using the IP address, refer to IP Addresses for TCP/IP Connections.
When you use shared memory or stream pipes for client/server communications, the hostname field must contain the actual host name of the computer on which the database server resides.
When you use the IPX/SPX network protocol, the hostname field must contain the name of the NetWare file server. The name of the NetWare file server is usually the UNIX hostname of the computer. However, this is not always the case. You might need to ask the NetWare administrator for the correct NetWare file-server names.
The interpretation of the service name field (servicename) depends on the type of connection that the connection-type field (nettype) specifies.
The service name field can include any printable character other than a field delimiter, a newline character, or a comment character. The service name field is limited to 128 characters.
When you use the TCP/IP connection protocol, the service name field must correspond to a service name entry in the services file. The port number in the services file tells the network software how to find the database server on the specified host. It does not matter what service name you choose, as long as you agree on a name with the network administrator.
Figure 12 shows the relationship between the sqlhosts file and the hosts file, as well as the relationship of sqlhosts to the services file.
In some cases, you might use the actual TCP listen-port number in the service name field. For information about using the port number, refer to Port Numbers for TCP/IP Connections.
When the nettype field specifies a shared-memory connection (onipcshm) or a stream-pipe connection (onipcstr), the database server uses the value in the servicename entry internally to create a file that supports the connection. For both onipcshm and onipcstr connections, the servicename can be any short group of letters that is unique in the environment of the host computer where the database server resides. It is recommended that you use the dbservername as the servicename for stream-pipe connections.
A service on an IPX/SPX network is simply a program that is prepared to do work for you, such as the database server. For an IPX/SPX connection, the value in the servicename field can be an arbitrary string, but it must be unique among the names of services available on the IPX/SPX network. It is convenient to use the dbservername in the servicename field.
The options field includes entries for the following features.
| Option Name | Option Letter | Reference |
|---|---|---|
| Buffer size | b | page Buffer-Size Option |
| Connection redirection | c | page Connection-Redirection Option |
| End of group | e | page End of Group Option |
| Group | g | page Group Option |
| Identifier | i | page Identifier Option |
| Keep-alive | k | page Keep-Alive Option |
| Security |
s (database server) r (client) |
page Security Options |
| Communication support module | csm | page Communication Support Module Option |
When you change the values in the options field, those changes affect the next connection that a client application makes. You do not need to stop and restart the client application to allow the changes to take effect. However, a database server reads its own connectivity information only during initialization. If you change the options for the database server, you must reinitialize the database server to allow the changes to take effect.
Each item in the options field has the following format:
letter=value
You can combine several items in the options field, and you can include them in any order. The maximum length of the options field is 256 characters.
You can use either a comma or white space as the separator between options. You cannot use white space within an option.
The database server evaluates the options field as a series of columns. A comma or white space in the options field represents an end of a column. Client and database server applications check each column to determine whether the option is supported. If an option is not supported, you are not notified. It is merely ignored.
The following examples show both valid and invalid syntax.
| Syntax | Valid | Comments |
|---|---|---|
| k=0,s=3,b=5120 | Yes | Syntax is correct. |
| s=3,k=0 b=5120 | Yes | Syntax is equivalent to the preceding entry. (White space is used of instead of a comma.) |
| k=s=0 | No | You cannot combine entries. |
Use the buffer-size option (b=value ) to specify in bytes the size of the communications buffer space. The buffer-size option applies only to connections that use the TCP/IP network protocol. Other types of connections ignore the buffer-size setting. You can use this option when the default size is not efficient for a particular application. The default buffer size for the database server using TCP/IP is 4096 bytes.
Adjusting the buffer size allows you to use system and network resources more efficiently; however, if the buffer size is set too high, the user receives a connection-reject error because no memory can be allocated. For example, if you set b=64000 on a system that has 1000 users, the system might require 64 megabytes of memory for the communications buffers. This setting might exhaust the memory resources of the computer.
On many operating systems, the maximum buffer size supported for TCP/IP is 16 kilobytes. To determine the maximum allowable buffer size, refer to the documentation for your operating system or contact the technical-support services for the vendor of your platform.
If your network includes several different types of computers, be particularly careful when you change the size of the communications buffer.
The connection-redirection option indicates the order in which the connection software chooses a coserver within a group.
By default, a client application is connected to the first coserver listed in the sqlhosts file. If the client cannot connect to the first database server, it attempts to connect to the second database server and so on.
If the connection-redirection option is on (c=1), the database server attempts to establish a connection in a random order among members of the dbserver group.
The following table shows the possible settings for the connection redirection option.
Use the communication support module (CSM) option to describe the CSM for each database server that uses a CSM. If you do not specify the CSM option, the database server uses the default authentication policy for that database server. You can specify the same CSM option setting for every database server described in the sqlhosts file, or you can specify a different CSM option or no CSM options for each sqlhosts entry.
The format of the CSM option is illustrated in the following example:
csm=(csmname,csm-connection-options)
The value of csmname must match a csmname entry in the concsm.cfg file. The connection-options parameter overrides the default csm-connection options specified in the concsm.cfg file. For information on the concsm.cfg file entry, refer to CSM Configuration File.
The following example specifies that the PSWDCSM communication support module will be used for the connection:
csm=(PSWDCSM)
For more information on the CSM, refer to Database Server Connection. For more information on the concsm.cfg file, refer to CSM Configuration File.
Use this option to specify the ending database server name of a database server group. You can use this option only in a group entry. If you specify this option in an entry other than a database server group, it is ignored.
If no end-of-group option is specified for a group, the group members are assumed to be contiguous. The end of group is determined when an entry is reached that does not belong to the group or at the end of file, whichever comes first.
When you define database server groups in the sqlhosts file key, you can use multiple related entries as one logical entity to establish or change client/server connections. Use the following steps to create database server groups.
The database server group name can be the same as the initial DBSERVERNAME for the database server.
The only options available for a database server group entry are as follows:
Table 6 shows sqlhosts entries that define database server groups.
| dbservername | nettype | hostname | servicename | options |
|---|---|---|---|---|
| asia | group | - | - | e=asia.3 |
| asia.1 | ontlitcp | node6 | svc8 | g=asia |
| asia.2 | onsoctcp | node0 | svc1 | g=asia |
| usa.2 | ontlispx | node9 | sv2 | |
| asia.3 | onsoctcp | node1 | svc9 | g=asia |
| peru | group | - | - | |
| peru.1 | ontlitcp | node4 | svc4 | |
| peru.2 | ontlitcp | node5 | svc5 | g=peru |
| peru.3 | ontlitcp | node7 | svc6 | |
| usa.1 | onsoctcp | 37.1.183.92 | sales_ol | k=1, s=0 |
| asia | group | - | - | e=asia.3 |
| asia.1 | ontlitcp | node6 | svc8 | g=asia |
| asia.2 | onsoctcp | node0 | svc1 | g=asia |
| usa.2 | ontlispx | node9 | sv2 | |
| asia.3 | onsoctcp | node1 | svc9 | g=asia |
| peru | group | - | - |
The example in Table 6 shows the following two groups: asia and peru. Group asia includes the following members:
Because group asia uses the end-of-group option (e=asia.3), the database server searches for group members until it reaches asia.3, so the group includes usa.2.
Because group peru does not use the end-of-group option, the database server continues to include all members until it reaches the end of file.
You can use the name of a database server group instead of the database server name in the following environment variables:
The value of INFORMIXSERVER for a client application can be the name of a database server group. However, you cannot use a database server group name as the value of INFORMIXSERVER for a database server or database server utility.
DBPATH can contain the names of database server groups as dbservernames.
In addition, the group name can also be in the SQL CONNECT command.
The identifier option assigns an identifying number to a database server group. The identifier must be a positive numeric integer and must be unique within your network environment.
The keep-alive option is a network option that TCP/IP uses. It does not affect other types of connections.
The letter k identifies keep-alive entries in the options field, as follows:
k=0 disable the keep-alive feature k=1 enable the keep-alive feature
When a connected client and server are not exchanging data, the keep-alive option enables the network service to check the connection periodically. If the receiving end of the connection does not respond within the time specified by the parameters of your operating system, the connection is considered broken, and all resources related to the connection are released.
When the keep-alive option is enabled, the network service spends additional resources to check the connection.
When the keep-alive option is disabled, the network service does not check periodically whether the connection is still active. If the opposite end of the connection terminates unexpectedly without any notification, as when a PC reboots, for example, the network service might never detect that the connection is broken.
If you do not include the keep-alive option in the options field, the keep-alive feature is enabled by default. You can set this option on the database server side only, the client side only, or on both sides. For most cases, it is recommended that you enable the keep-alive option.
The security options let you control operating-system security-file lookups. The letter s identifies database server-side settings, and the letter r identifies client-side settings. You can set both options in the options field. A client ignores s settings, and the database server ignores r settings.
The following table shows the possible security option settings.
The security options let you control the way that a client (user) gains access to a database server. By default, an Informix database server uses the following information on the client computer to determine whether the client host computer is trusted:
With the security options, you can specifically enable or disable the use of either or both files.
For example, if you want to prevent end users from specifying trusted hosts in the .rhosts file, you can set s=1 in the options field of the sqlhosts filefor the database server to disable the rhosts lookup.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]