IBM Support

How does the DB2 Command Line Processor (CLP) process model work?

Technote (FAQ)


How does the DB2 Command Line Processor (CLP) process model work?


The CLP consists of two main processes, the short-lived "db2" front end process (FP) and the persistent "db2bp" back end process (BP). The FP's primary function is in essence to pass user input to the BP and render results from the BP for the user. It is short-lived as it runs for only an individual command execution. The BP is persistent in order to maintain a connection to an instance/database across multiple commands. The FP is responsible for spawning the BP process if necessary.

The FP communicates with the BP via a set of message queues (input,request and output). The parent process ID - typically the invoking shell - along with the numeric user ID is used to identify the message queues for a session. The FP tests for the existence of the message queues based on this and knows thus whether or not to spawn the BP process.

If we look at an example session with an active BP process:

db2inst6 19743 19742 0 10:57:25 pts/13 0:00 -ksh
db2inst6 20084 1 0 10:58:41 pts/13 0:00 /home0/db2inst6/sqllib/bin/db2bp 19743A631 5 A

we can see the parent process ID (the invoking shell) in the first argument to the BP process, along with the numeric user ID:

$ id
uid=631(db2inst6) gid=631(db2iadm6)

This argument is hashed to generate the IPC key used to identify the queues:

q 788529170 0x47873c3 --rw------- db2inst6 db2iadm6 db2inst6 db2iadm6 0 0 134217728 24765 20084 11:23:55 11:23:55 10:58:40
q 788529169 0x74d1b3a2 -Rrw------- db2inst6 db2iadm6 db2inst6 db2iadm6 0 0 134217728 24765 20084 11:23:55 11:23:55 10:58:40

(The output queue is created and destroyed as needed.)

In a db2trc trace you can see the hash results, e.g.

3751 | | | | | sqlogkey entry

bytes 25

Data1 (PD_TYPE_STRING,17) String:

3752 | | | | | sqlogkey exit [rc = 0x74D1B3A2 = 1959900066]

(The prefix "R11" is used with request queues.)

As the source information (i.e. parent process ID plus numeric user ID) is always available to the FP process, it can on each invocation identify the correct queues (prefixes are constant) to connect to in order to communicate with its paired BP process.

If you invoke a sub-shell, e.g. when running a script, the FP's parent process ID differs so a new BP is needed. Likewise if you use "login" to change the current shell's authorisation the IPC keys will change too. This maintains session isolation.

The FP communicates with the BP via a custom queue implementation utilising a shared memory area and Window events and mutexes. The principles of communication and queue identification are the same.

The BP process is responsible for communication with the instance, be it locally via IPC or remotely via TCP/IP. When a connection is made a db2agent EDU is spawned (or assigned from the pool) within the instance to service the CLP client. This is the same as for any other client. We therefore end up with a simplified basic flow of commands for the CLP as:

shell command line -> invokes FP process with arguments -> passed on to BP via message queue -> passed on to instance via IPC or TCP/IP --+
return to shell command line <- FP displays results and terminates <- passed on to FP via message queue <- response passed to BP via IPC or TCP/IP <-+

The TERMINATE CLP command terminates the BP process. ( )

Document information

More support for: DB2 for Linux, UNIX and Windows
Programming Interface - CLP

Software version: 9.7, 10.1, 10.5

Operating system(s): AIX, HP-UX, Linux, Solaris, Windows

Reference #: 1983930

Modified date: 23 May 2016