The DB2 product family is truly universal. It spans AS/400 systems, RISC System/6000 hardware, IBM mainframes, non-IBM machines from Hewlett-Packard and Sun Microsystems, and operating systems such as Windows NT and 95/98, OS/2, AIX, HPUX, SCO UnixWare, and Sun Solaris. And now, IBM is extending that universality even further as the AS/400 database joins the DB2 Universal Database family.

With OS/400 V4R4, DB2 for AS/400 has been rebranded DB2 Universal Database for AS/400 (DB2 UDB for AS/400). This new name reflects some added benefits that AS/400 users will realize with DB2 UDB. First, this new version of OS/400 marks a major advancement in AS/400 database technology by extending the AS/400’s relational databases to store, administrate, and control all types of information in the DB2 UDB architecture. This new version of the database is also downward-compatible, as are all previous releases of DB2 on the AS/400. No database tables or applications changes are necessary for them to run on the DB2 UDB for AS/400. With newly supported data types—such as Binary Large Objects (BLOBs), Character Larger Objects (CLOBs), and Double-byte Character Large Objects (DBCLOBs)—users can define a DB2 UDB for AS/400 database table to store such large, complex objects as Web interactive movie files (such as MPEG), digitized employee photographs (in .jpeg, .gif, or .tif formats), or audio track files (such as .wav). By writing a program that supports embedded SQL, you can even “import” an audio file or movie file into your native applications.

To serve your traditional and client/server applications with better interaction between the database and the file systems, DB2 UDB employs “datalink” technology. This technology is very new. In fact, you could say that it is an invention of the database vendors. While operating system vendors want everyone to start using COM/DCOM and Win32 API as the starting point to access file data and application data, database vendors want everyone to start from the database itself (even for local file system data), so datalink was created. Thus, you can start from the database and pass through datalink to get to whatever file system is under the cover. The datalink function provides the following:
• It allows DB2 UDB for AS/400 to manage data stored in external file systems as if it were stored in the database itself.
• It uses a URL-based format to link the external data into the database table.

• It allows nontraditional data, such as spreadsheets and word processor documents, to remain in their local network file system while, at the same time, allowing them to be linked to a DB2 UDB for AS/400 database table.
• It allows the database to access data from the local file system and return requested information to an AS/400 user whenever that user requests data from the datalink through the database.

In short, datalink brings the best of both worlds (DB2 UDB for AS/400 database and network file systems) to your applications, and as time goes by, it will be interesting to see what kind of killer apps will be built from this technology.

A Bright New Set of Tools

Not only does DB2 UDB extend the AS/400’s relational database capabilities, but it also allows AS/400 users to now enjoy the same strong array of tools available for other DB2 UDB family products. These tools include, as described in the next paragraphs, Client Access Operations Navigator (OpsNav) and the Command Center/Client Configuration Assistant.

Within the latest V4R4 version of Client Access, the SQL procedure creator and SQL performance monitor provide functions that previous releases did not. The SQL procedure creator provides templates for building various SQL procedural statements, greatly simplifying the creation of SQL stored procedures for application developers. With the new V4R4 performance monitor Operations Navigator controls the start and stop of the monitor, as well as the production of performance analysis reports. These reports use memory-based analysis to identify long-running SQL statements and requests that cause temporary system indexes to be created.

Besides Client Access, the DB2 UDB family of products provides additional tools for the AS/400. If, for example, you have DB2 UDB installed on your Windows or OS/2 workstation, DB2 tools such as Command Center and Client Configuration Assistant become accessible. Client Configuration Assistant (CCA) is a standard DB2 UDB tool used on other IBM DB2 UDB systems, such as Windows NT, Windows 95, OS/390, and AIX. If you develop embedded SQL applications in Windows to access data in any of the remote DB2 UDB servers, you could use Client Configuration Assistant to configure OS/2, Windows 95, and Windows NT workstations (see Figure 1). Those configuration steps by CCA are necessary to configure the workstations to access the AS/400 database. Both DB2 utilities use SQL packages, which can be bound using CCA. There is no need for database administrators to perform any manual steps.

Another common DB2 UDB tool, the DB2 Command Center (Figure 2), can be used to enter DB2 commands and SQL statements to your AS/400 in an interactive window and display the execution results in a results window. You can scroll through the results and save the output to a file. Because both Command Center and CCA are tools from the DB2 UDB family, they work with all DB2 database servers in the family (including DB2 UDB for AS/400), so there is no need to switch between one tool and another.

A Replication Primer

In today’s business computing environment, many database applications grow from a single location into multiple regional sites or even international global organizations. The dispersed data stored at remote sites necessitates movement of data into a central location for data integration to support such business intelligence needs as decision support systems or data warehouses. With the AS/400 database joining the DB2 UDB family, not only can users enjoy a homogeneous set of tools for management and administration, but they can also experience ease of data integration using DB2 replication technology.

At the highest level, replication can be defined as movement of data from a database source system to a target database. Companies use data replication for a wide variety of applications. It could be used to load and refresh data warehouses, consolidate LAN-based

data to a centralized mainframe, content delivery for e-business applications on the Web, and more. One of the most important implications of replication is redefining the application development model. In a nondata integrated environment with data distributed across multiple systems, the application has to contain all the logic to connect the different databases among different platforms for processing. With replication, a copy of the data is kept locally, allowing the application to easily access the data without the added complexity of remote connectivity.

There are two types of data replication: synchronous and asynchronous. Synchronous replication usually employs a two-phase commit protocol from a distributed database management systems (DBMS) architecture, in which the source and target systems constantly communicate with each other to guarantee that all data is synchronized. For example, two AS/400 can be paired together with OptiConnect, and software packages on the AS/400 synchronize data at all times. However, a communication error, system failure, or database update error can cause a transaction to be rolled back. A rollback then causes a full and complete instance of data refresh between the source and target systems. If your database contains millions of rows under replication, a full refresh might take days to complete—downtime that is certainly not acceptable in a real-time business environment. Besides, when multiple systems, such as one source system with 10 target systems, are involved in replication, two-phase commit protocol becomes impractical because multiple systems are competing with each other for table locks in order to complete the two-phase commit.

Thus, the most advanced data replication solution, such as the one used by the DB2 UDB family, employs an asynchronous architecture that allows data access at the source system while replication is in progress on the target system. I will take a brief look at the DB2 replication architecture to see how replication can be used to turn data integration into reality.

Two separate components, Capture and Apply, form the basic architecture for DB2 UDB replication (Figure 3). Because DB2 UDB uses the same replication architecture for multiple platforms, the same replication concepts apply to all platforms. Thus, there are Capture and Apply for AS/400, NT, AIX, and MVS, and they all work together to form a single UDB replication architecture. As seen in Figure 3, the Capture component is a journal-reading program that will “capture” the changes in the tables being replicated and deposit those changes into internal staging tables (the Change Data and Unit of Work tables in the figure). The Apply component will then pick up the changes from the internal staging tables and replicate the changes into the target system. With multiple platforms following the same architecture, the Capture and Apply components from different platforms within the DB2 UDB family work seamlessly to provide data integration services for business enterprises.

Transformation!

If you are building a data integration solution, such as a data warehouse or a data mart, you will need to transform your data from the operational systems before inputting it into the data warehouse. For example, you may want to keep only the information on customers whose ages are between 35 and 55. Or you may want to group and update a set of operational systems in different locations at the same time and perform specific SQL statements before and after the data replication for your applications. All of these advanced functions are supported by the DB2 UDB replication architecture and can be configured easily using a single user interface spanning all the supported platforms. This common replication administration tool is called DataJoiner Replication Administration (DJRA). DJRA simplifies administration tasks by providing an easy-to-use interface that will configure internal control tables for DB2 replication across multiple platforms (see Figure
4).

DB2 UDB for AS/400 joins the DB2 UDB family as one of the most reliable databases in the world. New functions such as datalinks, user-defined data types, and large-object support are some of the most advanced features provided by database vendors and provide countless possibilities for today’s e-business programming. The strong array of products from the DB2 UDB family now joins forces with the AS/400 to deliver data integration power to your company—and to your customers.

Related Materials

• IBM AS/400 home page: www.as400.ibm.com
• IBM DB2 DataPropagator home page: www.software.ibm.com/data/dpropr
• IBM Software Database and Data Management home page: www.software.ibm.com/data

Figure 1: Use CCA to configure workstations.

Figure 2: Command Center displays command execution results in a results window.

Operational System Target

• Base Tables
• Column Selection
• After Image or Before & After Image

Figure 3: The Capture and Apply components form the basic architecture for DB2 UDB replication.

CONTROL UNIT OF WORK CHANGE DATA COPY

COPY COPY

BASE CONTROL

APPLY

Journal

CAPTURE

ADMINISTRATION

Figure 4: This easy-to-use interfadce configures internal control tables for DB2 replication across multiple platforms.