Mar 1 ’03
Mainframe Data Access: A Windows’ Window Into z/OS Data
Getting real-time access to that information in its native form is becoming more important to companies, with today’s requirement of continuous availability. According to market research firm IDC, the top two application integration challenges today are integrating new technologies with legacy systems and the many disparate systems that need integration. Fully 55 percent of the users IDC surveyed felt that it’s “critical” or “extremely important” to have products and services that support integration today. Moreover, this number is expected to increase to 85 percent by 2004.
So enterprises recognize the importance of sharing information between disparate systems. However, the glass house needs to ensure that the organization’s strategic information is never compromised. The challenge is in giving decision makers and other end users real-time access to important data, while maintaining the security and integrity of legacy systems.
The fundamental problem in accessing mainframe data from a Windows application is that the two environments are based on different architectures and are evolving in different directions. (Figure 1 summarizes the architectural differences.) Understanding this is essential to bridging the gap between the two platforms, because these differences mandate the way data is stored, manipulated, and displayed.
The Windows system is based on the Intel architecture. Microsoft intends to continue evolving the Windows platform and to converge on a shared code base for all environments. Microsoft is deploying Windows everywhere, with the goal of surrounding the glass house and, ultimately, rendering it irrelevant. On top of Windows is .NET, which is less a change to Windows than a change to how code is developed and applications are deployed, installed, and maintained. The .NET framework is key to the future of all Microsoft offerings.
The z/OS system is based on the 40-year-old System/360 architecture. IBM continues to exploit the key features of the System/360 architecture — its robustness, reliability, and scalability. IBM now has an absolute monopoly in the System/390 hardware and Operating System (OS) space. The company has invested substantial energy in developing the WebSphere application platforms and the Java language. It’s safe to assume that the mainframe will continue to be the focal point for strategic applications and data.
Accessing mainframe data from the desktop, and getting it into a usable format, can be cumbersome. Options include:
- Moving to a more modern set of applications (e.g., SAP, PeopleSoft, Siebel) — While promising much, these Enterprise Resource Planning (ERP) systems are expensive, slow to implement, and have a host of hidden costs. Many business processes will have to be redesigned and functionality may be lost.
- Creating a universally accessible data warehouse or data mart — Implementing a data warehouse or data mart is time-consuming; maintaining it is even more expensive and complex.
- Transforming the critical data to a relational data manager with a data-distribution capability — Unfortunately, this is more complicated than it might first appear. While redesigning a legacy database, it’s usually necessary to reengineer existing business processes. Legacy databases with older Relational Database Management Systems (RDBMSes) versions aren’t always compatible with newer versions and tools.
- Using ad hoc processes — These include special COBOL extraction programs, screen scraping, File Transfer Protocol (FTP), Network File System (NFS), or e-mail. Companies often use ad hoc approaches either because they don’t want to — or, for some reason, cannot — commit to a more elegant, effective solution. Unfortunately, these approaches aren’t always timely or complete; they’re also people-intensive, error-prone, and enduring. “Sneaker net” is alive and well in virtually all mainframe enterprises.
As noted, all these approaches have serious limitations. A more effective approach is to provide an integration layer between Windows and the mainframe. Providing such a bridge between the Windows world and the mainframe is difficult anyway. Making that bridge easy-to-use and easy-to-install has proven almost impossible — until recently.
It is now possible to make z/OS look like a Microsoft SQL Server, enabling users to free the z/OS data from its “data jail” and make it quickly, easily available on the desktop. This approach includes:
- ActiveX Data Objects (ADO), ADO.NET, and Object Linking and Embedding (OLE) database application interfaces
- NET Web and data services
- XML capability
- A three-tier architecture (since not all important data is on the z/OS)
- Support for multiple mainframes, multiple data types, and multiple data sources.
A Windows ’ Window into z/OS Data
There is now the capability to provide Windows 98, NT, 2000, and XP applications and browsers with real-time access to OS/390 and z/OS data, including VSAM, QSAM, IMS, and DB2 databases.
With this, an organization can receive data in real-time from a mainframe and use it in an off-the-shelf Windows or Web-enabled application, without the time-consuming, costly process of duplicating and transforming the data.
Any new or existing enterprise application can directly read data from wherever that data resides. Source data can come from any type of platform, even from multiple sources simultaneously. The data isn’t moved from its storage location; the software provides the specific data records or fields required by the requesting application, integrating data from the various sources, if necessary.
DB2 data can be merged with VSAM, QSAM, and IMS databases. By applying meta information to the unstructured mainframe files, the technology can retrieve the data as a relational structure.
For example, the end user can simply select a menu item in Microsoft Excel, request a view of mainframe data, and directly populate a worksheet. Multiple data types from multiple mainframes or Logical Partitions (LPARs) are easily joined in a single query.
Data Access Subsystem
This approach would employ a three-tier architecture:
- The data access subsystem (which operates as an authorized subsystem under OS/390)
- The data access server (Windows 2000 or NT4.0)
- The desktop (any Win 32-compatible platform).
This technology would interface at the OS level to read directly from stored data at the file or record level. The subsystem is multi-threaded; each application and file cluster is independently controlled by subsystem priority settings. This threading system enables the software to be scaled with multiple servers running on multiple threads on the mainframe, if desired.
The administrator defines the metadata (source templates), which are used as the data dictionary. The template tells a subsystem the physical location of the data, the records and fields to extract, and the format in which to present the data to the client.
In addition to acquiring, converting, and managing the data, the subsystem ensures security. When the primary host is an OS/390 system, agents operate through the System Authorization Facility (SAF), interfacing with Resource Access Control Facility (RACF), Advanced Communications Function 2 (ACF2), or Top Secret. The primary host controls exactly which users have permission to access specific files. This level of security extends from the mainframe through the data access servers, and culminates at the data access clients.
Data Access Server
The data access server runs as a service on a Windows NT, 2000, or XP server. The server is responsible for maintaining security of the multiple clients accessing the mainframe, while simultaneously working with the client to ensure client standards compatibility. Client standards are achieved using Microsoft Component Object Model (COM) as the network-abstraction layer.
Data from the mainframe is presented to Windows applications using ADO, ADO.NET, OLE DB, and ASP.NET. This allows numerous Windows programs, including all Microsoft Office products, to directly view data without further manipulation. This approach also allows the client, bridge interfaces, and applications to use standard Windows functions and features.
The data access server provides the join engine that allows access to multiple mainframes. A stored query facility (result template) enables joins to be performed across all mainframe data sources and data locations.
The business impact of this is significant in that it lets enterprises:
- Easily develop new applications (or convert existing open systems applications) to access mainframe data
- Instantly access multiple data sources and present integrated data to requesting applications. This new approach:
- Accesses data instantly and presents it in industry-standard formats
- Lets organizations use their legacy data quickly, easily, and cost-effectively for more accurate strategic decisions
- Leverages investments in mainframe computing.
At organizations that implement this approach, end users may no longer be frustrated that their mainframe data isn’t as easy to use as data from Windows applications. Z