Example ipc_info file
Server name | Protocol (s/p/d) | Executable server |
---|---|---|
oracle8 | s | ${BSE_BIN}/ora8_srv6.2 |
bshell | s | ${BSE_BIN}/bshell6.2 |
fs | s | ${BSE_BIN}/fs6.2 |
db2v5
db2v5 |
d
s |
db2v5_srv6.2
${BSE_BIN}/db2v5_srv6.2 |
- Server name: Used as identifier by the calling program.
- Protocol: Identifies the
communication protocol
- Socket (s)
- Pipes (p)
- Direct connection (d)
- Executable server: Identifies the executable to communicate with.
The
ipc_info
file resides in
${BSE}/lib.
Direct connections are only allowed for database drivers. A direct connection loads the database driver shared library (UNIX) or DLL (Windows) in the database client binary, for example, the bshell. This is also known as ‘combo-driver’.
Direct connections are limited to one database server. By default, a database driver can handle up to 64 sessions simultaneously. If the number of sessions for a database server exceeds this limit, a second database server is started as a separate process; for that reason, a direct driver entry is always followed by a standalone-entry with the ‘p’ or ‘s’ protocol type (see the previous table).
bdb_max_sessions
driver resource.
Do not specify a path for a direct connection. A shared library/DLL that is associated with a direct connection is picked up from ${BSE}/shlib. It is required that the product version & PA-number of the client binary (for example, bshell) exactly matches the product version & PA-number of the (database) shared library/DLL from ${BSE}/shlib. You cannot mix debug and release builds.