Have you considered writing a Java method to access a router to query data on a mainframe database? (Imagine the speed of a hardware-based protocol.) Did you know that you can place an ODBC call to a router and get data from a mainframe via IBM’s System Network Architecture (SNA)? Or that your network can act as the fastest data access method at your fingertips? If you answered yes to these questions, you can probably skip this article. However, if this is news to you, keep reading.
Distributed Relational Database Architecture (DRDA) is ODBC on steroids in an SNA environment. Cisco’s ubiquitous Internetworking Operating System (CIOS) is how you interact with a router; you can use DRDA to access mainframe data via a router running CIOS. This article describes what DRDA is, how it works, and how you can use it.
What Is DRDA?
DRDA is a protocol within a protocol. Years ago, IBM proposed Systems Application Architecture, which describes processing on IBM platforms. Systems Application Architecture has three parts: the Common User Access, the Common Programming Interface, and the Common Communication Support (of which DRDA is a small but powerful component). Common Communication Support describes how distributed, networked applications are built. It is a compilation of communication architectures proposed by IBM and other international and U.S. standards organizations, and has six components:
• Transmission objects, which includes six different object types (for this article, we are concerned with Formatted Data Object Content Architecture, or FD:OCA)
• Data streams, which includes five different data stream types (for this article, we are only concerned with Character Data Representation Architecture, or CDRA)
• Application Services, which includes two application services categories: SNA and Open Systems Interconnection (OSI). SNA has five services, including distributed data management (DDM) and DRDA. OSI has three services, one of which is the X.400 Message Handling System.
• Session Services, which includes three categories: SNA, OSI, and TCP/IP (for this article, we are only concerned with SNA and TCP/IP).
The other two components, Network and Data Link Control, include four categories: SNA, SNA/OSI, OSI, and TCP/IP. This particular aspect is not germane to a DRDA discussion.
When DRDA was announced years ago, developers became frustrated that interoperability with other protocols (such as ODBC and NetBios) didn’t exist, and their enthusiasm for DRDA waned. This is largely because IBM did not move quickly enough for commercial adoption of DRDA mainframe data access to take hold. However, recent developments should rekindle this spark.
Figure 1. GUI Network Database Connection
DRDA is not a product, but a suite of lower-level protocols (CRDA, FD:OCA, LU 6.2 DDM, SNA/MS) that let servers (mainframes) interoperate. This provides clients access to remote data that may not be located on the machine that maintains their physical connection.
I could write a lot about how DRDA works, the various types of Units of Work, and the different levels of DRDA support within different operating systems (somewhat like ODBC compatibility layers). I’ll condense the relevant information for you. DRDA is comprised of a Requester/Server model, database protocols, and a set of standards for commands, objects, data descriptors, and communications. The Requester/Server model has three components: application requesters, application servers, and database servers. An application requester converts application requests into distributed data management format and invokes calls to a SQL API to request data from a relational database. The application server receives requests from application requesters and routes them to database servers wherein the requests have already been converted to distributed data management format. The database servers, in turn, access the relational database governing the data required.
This means that a GUI communicates with an application requester, which, in turn, communicates with the DRDA API (SQL API), which converts data into a distributed data management format, which hands off to LU 6.2 for transport through the network to another LU 6.2 node. The receiving node then turns over control to data management format, which sends the request to the DRDA API (SQL API), which hands off to the application server, which then communicates with the database server. Figure 1 illustrates this process. If you want further details, I recommend the IBM Redbooks web site at www.redbooks.ibm.com.
Middleware and DRDA
If all you had to worry about were the UNIX, Windows NT, and AS/400 boxes, you’d most likely have no problems integrating them using an ODBC/JDBC bridge (or just JDBC). But what about companies with mainframes, AS/400s, Sun Servers, HP 3000s, Windows NT Servers, Novell Servers, ad infinitum? The mainframe and its database entities add a peculiar spin that requires special attention if you’ve never worked with them before. Why should you care? The number of software developers who understand how to develop web-based applications, notably Java applets that connect to mainframes, is very small. If your company is thinking about extranet or e-commerce applications involving Java and mainframes, you’ll need to revisit some of the points presented in this article.
Figure 2. Using DRDa through the Router
Figure 3. Client Connection to DB2
DRDA is independent of the object model if you elect to implement the CIOS DRDA solution with an Open Systems-compliant tool. This means you can install an ORB/OTM to address development, access, and extensibility issues. Up until now, these issues were unexplored because they were either too complicated for developers to reuse or no one knew how to use them. Figure 2 shows the physical and logical connections required to use DRDA through the router. The top series of connections illustrates how a client or server connects to a router that, in turn, connects to a web cloud. A router connects the cloud to the mainframe—this represents the physical connection. The lower series of connections simply illustrates, logically, how this happens. It shows an application running on a piece of middleware communicating with the network via TCP/IP. Then we see this unit connected to a database connection converting the TCP/IP packets into SNA packets for passing to the mainframe. This path is reversed once the mainframe has “fetched” the requested data set.
There are other ways of connecting to mainframe data that can be categorized as custom-built middleware. Typically, the creation of custom middleware is driven by a “need for speed.” Most of the HTTP servers and enterprise servers are too slow for applications that require sub-second data access times (via CICS sockets, CICS BMS mapping, or screen scraping).
Keep in mind, you aren’t obligated to use middleware, or even CIOS, to gain the benefits of DRDA. Historically, implementing DRDA required a DRDA-based gateway, or SQL Gateway Server, to broker data between a client and the mainframe. IBM’s Data Joiner and Platinum Technology’s InfoHub 2.0 are good examples of such tools. InfoHub 2.0 features a DRDA implementation that lets you move legacy data from source to target without using a third-party database gateway. It translates SQL commands into the languages of legacy DBMSs, including DB2, VSAM, and MVS sequential files, among others. However, there might be a faster, cheaper method of accomplishing heterogeneous data source connectivity.
How Does CIOS Do Its Thing?
The router, with CIOS loaded, takes the ODBC request, containing a SQL query, converts it into a LU 6.2 data stream, and returns the result set to the PC client via ODBC. In other words, it converts the ODBC request into a request that DB2, or Universal Database (UDB), can recognize in an SNA environment without any special software on the PC client. Another way to look at it is that the router-based database access removes all of the complexity of SNA-to-TCP/IP integration as well as eliminates the need for DRDA middleware.
Focusing on how you use ODBC to connect to a router, which will then connect you to a DB2 database, the CIOS DB Connection feature allows routers running CIOS 11.3 or greater to use DRDA over TCP/IP. The router with DB Connection exists in the TCP/IP network, and clients use the DB Connection IP address and port on the router to connect to the IBM host system that exists in an SNA network.
When DB Connection is configured on a router, client-based ODBC applications can connect to IBM’s family of relational databases, which include:
• DB2 for OS/390 (MVS)
• DB2 for Virtual Machine
• DB2 for Virtual Storage Extended (SQL/DS)
• DB2 for OS/400
• DB2 Universal Server (AIX, HP-UX, UNIX, Solaris, Windows NT, Windows 95, OS/2, SCO OpenServer)
A router with DB Connection converts DRDA packets over TCP/IP to DRDA packets over Advanced Program-to-Program Communication (APPC, also called LU 6.2) and routes them to DB2 databases. DB Connection runs as a TCP/IP daemon on the router, accepting DRDA client connections over TCP/IP. When clients connect to the DB2 on a mainframe, DB Connection allocates an APPC dialog over SNA to an IBM Database Server, which then acts as a gateway between DRDA over TCP/IP and DRDA over APPC. Figure 3 illustrates this process.
What Do I Need to Use DRDA?
First, you need to know the basics of writing ODBC calls to SQL data sources. If you understand that part, then all you’ll need to know is the TCP/IP address of the daemon running on the router. Fortunately, you only need to do two things before using DB Connection. First, you need to install either the StarSQL software or an ODBC driver on your PC. Please note that you can omit the headache of ODBC driver installations by automating the connection using an ORB/OTM middleware to handle the connections for you. In other words, you can maintain a thin client architecture and still get ODBC-to-DRDA connectivity. Second, you’ll need to configure CIOS 11.3(2)T software on your router to support DRDA.
Once you’ve done these two things, you can query data on the following mainframe DBMSs:
• DB2 MVS (2.3, 3.1, 4.1, and 5.1)
• SQL/DS 3.3 and later (VM and VSE)
• DB2/400 V2R2 and later (OS/400)
• DB2 Common Server (Universal Database) for DB2/AIX, DB2/2, DB2/NT 2.1 and later
You could even link Microsoft Excel spreadsheets to the mainframe data via Excel’s ODBC connection feature.
Fast Data Access
If it’s fast access to mainframe or AS/400 SQL data you want, then you need to consider DRDA. Because of the simple architectural approach of using ODBC to connect to a socket owned by a daemon on a router, it greatly accelerates performance as well as development time. This also simplifies the skill set requirements for software development projects that require mainframe database access. While DRDA may seem like an arcane method of connecting to mainframe databases, the prospect of using ODBC certainly isn’t arcane. This is revolutionary if you think about it—the router becomes the data access point instead of a stack on a remote machine.
