Chapter 5: Operational Setup

---

4.6 DB2 connectivity to z/OS and S/390®

In this section we describe the different ways to establish connectivity among Java applications running on multiplatforms (Windows, Linux UNIX) to access data from DB2 for z/OS and OS/390 subsystem or vice versa.

4.6.1 Type 2 connectivity from a non-z/OS platform

The configuration in Figure 4-15 describes an environment where the DB2 UDB for z/OS and OS/390 system is not local to the JDBC driver, and the WAS system is running on a different machine, as well as on a different platform than the DB2 UDB.

Figure 4-15: Type 2 connectivity from a non-z/OS platform

In the upper half of Figure 4-15 we show a configuration where DB2 Connect Server and WAS are on the same machine. In this kind of setup you can eliminate the communication cost between the WAS server and the DB2 Connect Server. Instead of TCP/IP, shared memory can be used to communicate between local applications and DB2 Connect.

If you set up a DB2 Connect server separately from your Web Application Server, as shown in the lower half of Figure 4-15, you can decrease the maintenance workload. You can manage all the connection settings at one place and can monitor transactions running through the DB2 Connect Server. Also connections to the target server can be limited to a small number of DB2 Connect servers.

4.6.2 Type 4 connectivity from a non-z/OS platform

In this case, our application is running on a non-z/OS platform and we are using a Type 4 driver to connect an application to access data from DB2 for z/OS system. In the upper half of Figure 4-16 we show a configuration where our Java application is using a Type 4 driver to communicate directly to DB2 UDB for z/OS and OS/390 through DRDA. The Type 4 driver converts JDBC API calls into DB2 API calls using DRDA protocol.

Figure 4-16: Type 4 connectivity from a non-z/OS platform

When using the Type 4 driver, you do not need DB2 Connect to access data on a DB2 for z/OS and OS/390 system. In the lower half of Figure 4-16 we use DB2 Connect Server even though we are using a Type 4 driver. So the question arises, why is there a DB2 Connect Server in the figure, if it is not required? The answer is that the DB2 Connect Server provides functionality that is not provided by the Type 4 driver. These functions include sysplex awareness and connection concentration. For a more detailed description of these features, please see Distributed Functions of DB2 for z/OS and OS/390, SG24-6952.

Another question related to the previous section ("Type 2 connectivity from a non-z/OS platform" on page 113) is, why not to use only a Type 4 driver instead of Type 2, in all the scenarios where the Java application is running on another platform?

The reason is that the current Type 4 driver is not a full replacement of the DB2 Connect functionality. The Type 4 driver does not support all the functions that the Type 2 driver does. For example, connection pooling and two-phase commit are currently not supported by the Type 4 driver.

Important: 

If you use the Type-4 driver, since it is implemented as a DRDA Application Requestor, you can access DB2 for z/OS and OS/390 without having to go through DB2 Connect. However, from a licensing point of view, you still need a DB2 Connect licence to be able to connect to a DB2 for z/OS and OS/390 using the Type 4 driver.

4.6.3 DB2 UDB for z/OS and OS/390 as a DRDA application requester

The configuration shown in Figure 4-17 describes the environment when we have WebSphere Application Server running your Java applications that talk to a Type 2 JDBC driver, which further talks through RRS to a DB2 UDB system that is local to the machine running the WAS. Then this local DB2 diverts all requests to a remote database server using DRDA.

Figure 4-17: DB2 for z/OS and OS/390 as DRDA AR

The application will connect directly to the remote DB2 UDB system. However, the local DB2 has to exist because its services as a DRDA Application Requester (AR) are needed to be able to connect to the remote DB2 UDB system.

This kind of environment provides a very secure and high-availability environment running WebSphere Application Server systems on zSeries hardware in a parallel sysplex.

4.6.4 Application on z/OS connecting DB2 UDB for Multiplatforms

The DB2 UDB for Windows, UNIX, and Linux provide DRDA Application Server functionality as a standard function. Also DB2 for z/OS and OS/390's DDF also provides DRDA Application Requestor functions.

Figure 4-18 shows the configuration when an application program is running under the z/OS or S/390 environment accessing data form DB2 UDB for Multiplatforms server through DDF. TCP/IP is the only supported network protocol DB2 UDB for Multiplatforms Version 8 serves.

Figure 4-18: DB2 for z/OS and S/390 as AR and DB2 UDB for Multiplatforms as AS

This kind of configuration is very rare but still useful when we need to integrate legacy-based applications with a multiplatorm environment.

---