In this section, you will learn to set up these three connectivity scenarios:
From a DB2 for z/OS client to a DB2 for Linux, UNIX, and Windows server
From a DB2 for z/OS client to a DB2 for iSeries server
From a DB2 for z/OS client to a DB2 for z/OS server
The DB2 Connect software is not required in these scenarios.
Chapter 6, Configuring Client and Server Connectivity, we mentioned that APPC is supported when connecting from a DB2 for Linux, UNIX, and Windows client to a host server. However, inbound connections using APPC from a host client into a DB2 for Linux, UNIX, and Windows server is not supported. TCP/IP is assumed for all the scenarios described in this appendix.
Before describing the different connectivity scenarios, we need to explain what the Communications Database (CDB) is. The CDB consists of several updatable system tables where connectivity information is stored in the host. In previous versions of DB2 UDB for z/OS, it used to be a separate database; currently, it is part of the Catalog. The CDB tables are only used by DB2 UDB for z/OS when it behaves as a client (Application Requester). Figure E.1 shows the relevant CDB tables used for a TCP/IP connection with several rows inserted.
Thus, the DB2 for z/OS client will use IP address 9.23.190.25 and port 50000. Also, because SECURITY_OUT = P, it will pass a user ID and a password to the server because authentication will be performed at the server. Note as well that the USERNAMES column has a value of O. This should normally be the case when SECURITY_OUT = P, and it means there is a need to look into the SYSIBM.USERNAMES table for the user ID and password. The columns AUTHID, NEWAUTHID, and PASSWORD show the mapping between the TSO ID and the ID and password combination that will be passed to the server. At the DB2 for Linux, UNIX, and Windows server, the database manager configuration parameter AUTHENTICATION must be set to SERVER in order for these settings to work.
For this example, we assumed the second DB2 for Linux, UNIX, and Windows server had a database called SAMPLE as well (not SAMPLE2). However, because the LOCATION column of the SYSIBM.LOCATIONS table is a primary key, and because there was already an entry for SAMPLE for the first row of SYSIBM.LOCATIONS, the only way to put an entry in the table is to first create an alias to the database in the DB2 for Linux, UNIX, and Windows server as follows:
db2 catalog db sample as sample2
Then we could add an entry in SYSIBM.LOCATIONS for SAMPLE2.
Now you have learned how to read and populate the CDB tables. Let's discuss the three different connectivity scenarios.
Figure E.2 shows the overview for the scenario described in this section.
Table E.1 presents the list of commands required to set up this connection.
Commands to Run on Machine 1 ( tlba22me ) DB2 for z/OS | Information You Need to Obtain from Machine 2 ( aries ) DB2 for Linux, UNIX, and Windows to Perform the Commands on Machine 1 |
---|---|
Step 1: Configure the CDB (Communications Database) | |
Option 1:
Note: MYUDBLNK is an arbitrary name used to link tables SYSIBM.LOCATIONS and SYSIBM.IPNAMES. When SECURITY_OUT = A, authentication has already been verified at this machine. |
|
Option 2:
Note: MYUDBLNK is an arbitrary name used to link tables SYSIBM.LOCATIONS, SYSIBM.IPNAMES, and SYSIBM.USERNAMES. A value of P for the security_out column implies that authentication will be performed at server machine 2. TS56692 is the TSO ID on this mainframe machine 1 client. | |
To make sure the changes to the CDB take effect, restart DDF ( -stop ddf, -start ddf ). This may not be necessary if you have entered a new entry in the CDB. | |
Step 2: Bind SPUFI | |
Note: DSNESPCS is the package to bind for the SPUFI application with isolation Cursor Stability. DSNESPRR would be for isolation Repeatable Read. The library specified contains DBRM member DSNESM68 (for the SPUFI application) and is dependent on how DB2 was set up in your system. After the packages have been bound against server machine 2, the PLAN has to be bound. Using * in the package list guarantees the PLAN is bound in all locations. | SAMPLE is the database in machine 2 that you want to connect from the z/OS client machine. The user ID performing the bind should have been granted the appropriate authorization/privileges. |
Step 3: Test the Connection from DB2I Using SPUFI | |
Make sure to specify the connect location field as SAMPLE. Then issue the following command:
Note: There is no connect statement issued from SPUFI, but there is a specific field where you put the location you want to connect to. Note as well that the user ID and password are stored in the CDB. | When configuring the CDB using option 1 (when column SECURITY_OUT = A), you would be passing the TSO ID to the DB2 for Linux, UNIX, and Windows server. For this example, the TSO ID is TS56692 . Thus, in order to access a table for SELECT , you would need to do this:
|
Table E.2 provides troubleshooting hints for connectivity problems.
NOTE
DB2COMM and SVCENAME are set up automatically during the installation of DB2 for Linux, UNIX, and Windows for the default instance. Any other new instance created after installation with the
db2icrt command will not have these parameters set up.
NOTE
DB2 will check the
services file on the machine where the DB2 command is issued.
Figure E.3 shows the overview for the scenario described in this section.
Table E.3 presents the list of commands required to set up this connection.
Commands to Run on Machine 1 ( tlba22me ) DB2 for z/OS | Information You Need to Obtain from Machine 2 ( big400 ) DB2 for iSeries to Perform the Commands on Machine 1 |
---|---|
Step 1: Configure the CDB (Communications Database) | |
[View full width]
Note: MY400LNK is an arbitrary name used to link tables SYSIBM.LOCATIONS, SYSIBM.IPNAMES, and SYSIBM.USERNAMES. When SECURITY_OUT = P authentication will be performed at server machine 2. TS56692 is the TSO ID on this mainframe machine 1 client. |
|
To make sure the changes to the CDB take effect, restart DDF ( -stop ddf , -start ddf ) This may not be necessary if you have entered a new entry in the CDB. | No corresponding information required on this machine. |
Step 2: Bind SPUFI | |
Note: DSNESPCS is the package to bind for the SPUFI application with isolation Cursor Stability. DSNESPRR would be for isolation Repeatable Read. The library specified contains DBRM member DSNESM68 (for the SPUFI application) and is dependent on how DB2 was set up in your system. After the packages have been bound against server machine 2, the PLAN has to be bound. Using * in the package list guarantees the PLAN is bound in all locations. | TORISC6 = the local RDB name In order to bind the packages, you first need to create the collections:
Then grant iSeries user john01 the appropriate authorization/privileges against the collection. |
Step 3: Test the Connection from DB2I Using SPUFI | |
Make sure to specify the connect location field as TORISC6. Then issue the following command:
Note: There is no connect statement issued from SPUFI, but there is a specific field where you put the location you want to connect to. Note as well that the user ID and password are stored in the CDB. Issue this query for testing purposes. The sample table QIWS.QCUSTCDT is normally available after installation of iSeries unless it was removed or not set up by your iSeries administrator. | Grant the appropriate SELECT privilege to the user:
Also, most tables in iSeries are automatically journalled, but the QCUSTCDT sample table is not, so make sure to journal it. |
Table E.4 provides troubleshooting hints for connectivity problems.
Client Machine torisc6 | Database Server tlba22me |
---|---|
This command can be performed from the TSO Command Processor (assuming the hostname was used instead of the IP address itself in the SYSIBM.IPNAMES table). | big400.youracme.com = the host name of the database server If you cannot ping, there may be problems with the DNS. Try pinging the IP address. |
| 91.89.168.6 = the IP address of the database server This will confirm whether or not there are problems with the network. |
No corresponding information required on this machine. | Since the database server is DB2 UDB for iSeries, check: Is DDM started? If not, execute the following:
|
If you used a service name instead of the port number in your SYSIBM.LOCATIONS table, make sure the entry is correct in the services file at the client machine. | No corresponding information required on this machine. |
This command shows all connections and port numbers and their statuses. It can be performed from the TSO Command Processor. |
This command shows all connections and port numbers and their statuses. It can be performed from the OS/400 Main menu, options 6 -> 5 -> 10 -> 7 -> 3. |
Figure E.4 shows the overview for the scenario described in this section.
Table E.5 presents the list of commands required to set up this connection are given in the next table.
Commands to Run on Machine 1 ( tlba22me ) DB2 for z/OS | Information You Need to Obtain from Machine 2 ( tlba23me ) DB2 for z/OS to Perform the Commands on Machine 1 |
---|---|
Step 1: Configure the CDB (Communications Database) | |
Note: MY390LNK is an arbitrary name used to link tables SYSIBM.LOCATIONS, SYSIBM.IPNAMES, and SYSIBM.USERNAMES. When SECURITY_OUT = P authentication will be performed at server machine 2. TS56692 is the TSO ID on this mainframe machine 1 client. |
|
To make sure the changes to the CDB take effect, restart DDF ( -stop ddf , -start ddf ) This may not be necessary if you have entered a new entry in the CDB. | No corresponding information required on this machine. |
Step 2: Bind SPUFI | |
Note: DSNESPCS is the package to bind for the SPUFI application with isolation Cursor Stability. DSNESPRR would be for isolation Repeatable Read. The library specified in the bind package command contains DBRM member DSNESM68 (for the SPUFI application). This library location will vary depending on how DB2 was set up in your system. After the packages have been bound against server machine 2, the PLAN has to be bound. Using * in the package list guarantees the PLAN is bound in all locations. | MEXICO is the location name for the DB2 UDB for z/OS subsystem in this machine 2 that you want to connect from the other DB2 UDB for z/OS client. The user ID performing the bind should have been granted the appropriate authorization/privileges. This may also be required to run the packages:
|
Step 3: Test the Connection from DB2I Using SPUFI | |
Make sure to specify the connect location field as MEXICO. Then issue the following command:
Note: There is no connect statement issued from SPUFI, but there is a specific field where you put the location you want to connect to. Note as well that the user ID and password are stored in the CDB. Issue this query for testing purposes. The sample table dsn8810.emp is normally available after installation of DB2 for OS/390 and z/OS unless it was removed or not set up by your mainframe DBA. The example uses Version 8 emp table. If connecting to a DB2 for OS/390 and z/OS Version 7 subsystem, use table dsn8710.emp instead. | Make sure the user executing the query has the appropriate authorization/privilege, for example:
|
Table E.6 provides troubleshooting hints for connectivity problems.