DB2 connector
IMPORTANT: the DB2 connector is currently in beta, it has only been tested with DB2/LUW, but not with DB2/z and DB2/i.
If you have access to one of these databases, please contact us, we'd love to work with you to make sure this connector works properly with all versions of DB2.
The DB2 connector implements the DRDA v5 protocol. It can intercept any part of the dialog between database clients and database servers, and read and modify this dialog. This applies to on-premise DB2 as well as DB2 in the cloud
DB2 is a vast and complex beast, so it's always possible we missed something. If so, please let us know and we'll fix it promptly.
Related pages
DB2 filters: shows all the filter types for DB2
Contexts: lists the JavaScript contexts available in filters
Data types: how DB2 data types are mapped to JavaScript
DB2 packets: describes all the supported packet types
DB2 and SSL: setting up SSL to clients and server
Rejecting a request: explains how a request filter can reject a request
Parameters
This connector takes the following parameters:
Connection name
Can be any name you want.
Active
If checked, then this connection will be active any time Gallium Data is running, meaning that the local port will be open and listening for requests. If you uncheck this (and then click Publish), then the connection is "commented out" -- it's as if it didn't exist, but you can still keep it around and re-activate it later.
Type
The type of database for this connection. This is set when you create the connection and cannot be changed afterwards.
Server host
The name or address of the database server. This can be a partial name (like dbserver), a fully qualified name (like dbserver.it.acme.com), an IP4 address (like 181.77.230.42) or an IP6 address if your network supports IP6 (e.g. 266a:1790:2920:69e0:35c:d8ac:da8e:15e0).
If you are running Gallium Data as a Docker container, and the database is on the host machine, you can use host.docker.internal (on Windows or Mac, but see here for Linux).
Local address
The address on which to listen for requests. This is typically only relevant if your Docker container has more than one address. By default, Gallium Data will listen on all addresses (which is equivalent to 0.0.0.0).
Server port
The port on the database server. For DB2, it's usually 50000 but it can also be something else.
Local port
The port number in the Docker container on which Gallium Data will be listening to requests from database clients.
This is the port in the Docker container -- if you map it to your host machine, you can map it to any other port number.
Use SSL to server
Whether to connect to the DB2 server using SSL/TLS, or not. See DB2 SSL setup for details.
Trust server certificate
Whether to accept DB2's SSL certificate at face value, or not.
If this is option is not selected, and Use SSL to server is selected, then DB2's SSL certificate will be verified when Gallium Data connects to DB2, either by being signed by a well-known certificate authority (CA), or by verifying it with the chain of certificates provided in the project's Trust entry. If your DB2 server uses a self-signed certificate, and you want this option to be true, then you will need to add the DB2 server's certificate or a parent certificate in Gallium Data, in the Trust area of the Crypto section:
If this option is selected, then the SSL certificate from the DB2 server will be accepted without verification.
SSL authentication with server
If checked, Gallium Data will provide client-side certificate to DB2 when connecting over SSL/TLS. If this option is selected, a valid SSL private key and certificate must be added to Gallium Data's Keys area in the Crypto section, and this private key must be signed by a CA that the DB2 server trusts.
Use SSL to client
If this is checked, then database clients must use SSL/TLS to connect to Gallium Data. Unencrypted connection attempts will be rejected. See DB2 SSL Setup for details.
By default, Gallium Data will use an off-the-shelf self-signed certificate. You should replace this certificate with your own certificate for any serious application.
If your DB2 clients use host name validation, you will need to set up the certificate accordingly.
Require SSL authentication from clients
If this is checked, clients must provide a client-side certificate. Clients that attempt to connect without a verifiable client-side certificate will be disconnected.
Timeout to server
This specifies the number of milliseconds to wait when establishing a connection to the database server. The default value (10 seconds) is usually adequate for most cases.
Force column information
If checked, Gallium Data will modify query requests to the DB2 server so that column information is always included in result sets, with a very small performance penalty.
If this is not checked, some result sets may not have column names, and in those cases, column values will be accessible only by index.
This option should typically not be turned on unless you have a specific need for it.