This section describes how you create a new server for Db2 for IBM i/400.
-
On the Servers Properties dialog, select DB2/400 from the dropdown list in the DBMS type section.
-
Enter information for each field on the Server Properties dialog. Refer to the table below for field information.
Parameter |
Description |
---|---|
Name |
Use alphanumeric characters to specify a unique server name for use in the model. If the server is remote, the name must be the machine name that is used by Connect CDC to make the remote connection (see Remote hosting of IBM i Server for more information). Note: The slash (/), backslash (\), colon (:), left caret (<),
right caret (>) and spaces cannot be used in a server
name.
|
DBMS Type |
Select Db2 for IBM i/400 from the dropdown list. |
DBMS version |
Select the version number from the dropdown:
|
Server name |
Specify the name of the server that you want to model. For on-box host configuration, the Server name is the value of the <machine_name> defined in the Host Properties page. Often, the value you enter here is the same as the Name value. |
JDBC Driver |
Select a driver from the dropdown. The default is JT400offbox.
|
Driver Version |
View the JDBC Driver version. This information is obtained each time a connection to the database is made, including a Test Connection. (Informational only) |
DBMS logon IDs and DBMS logon password |
Specify the Default and Rep user IDs.
Note: When adding, updating, or deleting rows on the source table, do not use the replication user ID to make these changes. Changes made by the replication user are ignored by change capture triggers. Specify additional IDs.
|
Metabase library |
Specify the name of the library to which the metabase is to be installed. |
Install library |
Library where the Change Selector component is installed. The default is the version number for the release. For example, SHARE5881. |
Enable prepared statements |
If selected, prepared statements are enabled for the entire database server. A prepared SQL statement is a statement in which the steps to parse, analyze, validate, and determine the access path are only done once, when the statement is first prepared. On subsequent executions of the statement, the database has this information stored in memory and can skip the initial preparation steps. After a statement is prepared, only the column values change from one execution of the statement to the next. Each table can have as many as seven prepared statements: one for insert, up to five for update, and one for delete. The first time an insert, update, or delete is encountered, the statement is prepared, added to the cache, and is used to update the table. The statements are kept in the cache until removed. Using prepared statements provides a significant performance improvement when the same SQL statement is executed over and over. However, in some cases data for unchanged columns will be captured and sent across the network. Individual tables can disable prepared statements. This is useful for managing the size of the cache file. |
Database limit |
Displays the maximum size allowed by the database for open statements in the cache. The Specified limit, below, cannot exceed this value. The correct value is provided after you run a Test Connection. To do so, right-click the server name, then select Test Connection. |
Specified limit |
Enter the maximum size allowed for open statements in the cache. When the statement cache is full, the least recently used statement is removed from the cache, closed, and destroyed. If Journal batching is enabled, prior to removing the statement, pending batch updates are executed, If the statement that was removed is later referenced, a new prepared statement is created and added to the cache. Note the following:
|
Enable IASP |
Check the check box to enable Independent Auxiliary Storage Pool (IASP). An IASP is a set of disk units which contain a collection of user objects and the necessary system data (for example, storage management directories, object ownership, and authorization information) such that the IASP can be taken offline or brought online independent of system activity on other ASPs. |
Exclude Users |
Check the check box to display the Excluded Users tab. When you select the “Excluded Users” tab, the “Excluded Users” page displays. Use this page to add the user(s) that you want the Change Selector to exclude from replication on the sending table(s) that it will process. To remove a user from the list, highlight the entry in the list and press the <delete> key. Limitation: If an excluded user inserts a line into a table, that line will not be replicated to the target. If an “non-excluded” user updates that same line, Connect CDC attempts to replicate the update but may fail if the original line was never replicated to the target; it was inserted by and excluded user. Workaround: Ensure that you perform this operation in “forgiveness mode.” |
Credential Management: | Select a credential management provider that contains the login credentials for DBMS user IDs. Possible values are None and CyberArk. Selecting CyberArk enables the CyberArk Settings tab. |
Model using metabase |
Displays the name of the model. (Informational only) |
Model version |
Displays the version number, updated after each commit. (Informational only) |
Metabase version |
Displays the version of the metabase (for example, 40d). (Informational only) |
GMT offset (minutes) |
Displays the amount of time, in minutes, that local time differs from Greenwich Mean Time (GMT). For example, Boston is 300 minutes less than GMT. (Informational only) |
CyberArk Settings tab
- Click Configure in the CyberArk Settings tab to open the CyberArk Information dialog box.
- Enter the Application ID and Query String for your sample query.
- Click OK to test the connection.