Using ClientServer Programming Languages

Using Client/Server Programming Languages

Distributed processing and client/server processing are quite widespread in the data processing community. Distributed processing describes the interaction of multiple computers working together to solve a business problem. Client/server processing is a specific type of distributed processing in which a client computer requests services from a server. The client is typically a personal computer with a graphical user interface (GUI). DB2 is a popular candidate as a database server.

The popularity of client/server development has an impact on the DB2 application development environment. Often, DB2 developers access DB2 using a client/server application development product that communicates to DB2 using a gateway product. Popular client/server programming languages include PowerBuilder, Visual Basic, Visual C++, VisualAge, Kylix, and Delphi.

Connecting to DB2

Applications that run on a non-S/390 platform require DB2 Connect and CAE to access DB2 for OS/390 data. IBM's DB2 Connect is available to enable applications written for Windows, OS/2, and Unix. You can use this gateway product to connect client applications directly to DB2 for z/OS and OS/390. The Client Application Enabler (CAE) is also required and available on Windows, OS/2, and multiple Unix variants.

The application (or ODBC driver) calls CAE, which in turn sends the request to the DB2 Connect gateway. DB2 Connect passes the call to DB2 for OS/390 in the form of a DRDA request, as illustrated in Figure 14.1. CAE and DB2 Connect enable your applications or third-party products such as Microsoft Access and Lotus Approach running on the Windows platform to access DB2 for z/OS directly.

Figure 14.1. Using DB2 Connect and CAE to Connect to DB2 for z/OS.

Actually, there are two options for client applications:

• Use CAE and DB2 Connect Personal Edition on the client machine.

• Use a server machine where DB2 Connect Enterprise Edition is installed. Then the client machine requires only CAE. CAE is connected to the server machine through NetBIOS, IPX, or TCP/IP.

Regardless of which of the above option is deployed, the DB2 for z/OS location name must be defined in CAE. For additional information and guidelines on using DB2 Connect please refer to Chapter 43, "DB2 Connect."

Of course, DB2 Connect is not the only gateway product on the market. Other popular gateway products exist for connecting DB2 for z/OS to client/server applications, such as Neon Systems' Shadow Direct gateway product.

Client/Server Guidelines

Building client/server applications requires knowledge of multiple platforms and the network used to connect them. The following tips and tricks can be useful when building applications that span platforms.

Be Aware of SQL Anomalies

GUI-based client/server development tools may not offer SQL that is completely compatible with DB2 for z/OS. As such, certain features discussed in the DB2 manuals (and this book) may not be available when you're using a client/server language.

Likewise, some client/server languages require a call level interface to SQL (such as ODBC). This requirement causes the application to use dynamic SQL with all the performance implications as discussed in Chapter 12, "Dynamic SQL Programming."

Consult the Documentation for the Tools Being Used

Some of the rules and advice laid out in the preceding three chapters of Part II may not hold true for client/server programming with DB2. For example, the client/server development tool might build SQL statements for you and submit them to DB2 through the gateway. Sometimes, odd constructs, such as allowing SELECT ... INTO for multiple rows can be permitted because the gateway provides buffering services and automatically handles building cursors . It is imperative that you understand not only how your client/server development tools work to create applications, but how they interface to the database management system, which in this case is DB2 for z/OS.

Be Aware of the Complex Nature of Client/Server Computing

Additionally, the client/server environment relies upon a complex network of computing resources.

Mainframes, midranges, PCs, and workstations are commonly networked together, as illustrated in Figure 14.2.

Figure 14.2. A complex client/server environment.

In a client/server environment, rely on the documentation that came with your application development tool and middleware product(s).

Use Stored Procedures

Minimize network traffic by implementing stored procedures for frequently executed pieces of code. If you concentrate multiple SQL statements within a stored procedure, less data needs to be sent across the network. Network traffic is usually the single most important determinant of client/server application performance.

Use Triggers

By using triggers to maintain database integrity you can further minimize SQL requests over the network. When data integrity routines exist within the database, application programs do not need to check for invalid data because the database will ensure only valid data is entered. By doing more work within the DB2 database and requiring fewer program requests the performance of a client/server application can be improved.

Consolidate SQL Requests When Possible

Consolidate related SQL statements into a single request to reduce the number of requests and responses transmitted across the network. For example, change

 SELECT EMPNO, LASTNAME FROM EMP WHERE EMPNO < '001000'; SELECT EMPNO, LASTNAME FROM EMP WHERE EMPNO > '009000'; 

into

 SELECT EMPNO, LASTNAME FROM   EMP WHERE  EMPNO < '001000' OR     EMPNO > '009000'; 

One SQL statement sends fewer requests across the network. You can use this technique on all SQL statements, not just SELECT statements.

Ensure FOR READ ONLY for Distributed Cursors

Be sure that the FOR READ ONLY (or FOR FETCH ONLY) is used on each DECLARE CURSOR statement. Failure to do so has a negative impact on performance by disabling efficient block fetching. The FOR READ ONLY clause is ODBC-compliant and therefore more appropriate in a complex client/server environment.

Consult Chapter 41, "DRDA," Chapter 42, "Distributed DB2," Chapter 43, "DB2 Connect," and Chapter 44, "Distribution Guidelines," for more information on the following topics:

• DB2 distributed database support

• The use of DB2 as a database server

• Techniques for deploying DB2 Connect

• General distribution techniques and guidelines