The mainframe is outstandingly good at two things: running transactions and storing data. The mainframe’s success in transaction processing is evident in the way organizations are trying to make mainframe transactions available to users over the Internet through Service-Oriented Architecture (SOA). The mainframe’s strength for storing data is reflected in the amount and importance of data stored in VSAM and other files as well as in large databases such as IMS, DB2, and others.
In the past 40-plus years, mainframe sites have learned their lessons about the importance of backing up data and being able to restore it within minutes of an unexpected outage. The ability to keep users continuously productive yet still back up their data is an old problem with much-practiced solutions. The need to keep the data secure so only authorized users can access only specified parts of the database is another clearly understood problem with well-defined and embedded solutions.
Mainframe users aren’t rigidly set in their ways and unable to adapt to modern usage and techniques. On the contrary, mainframe users have, in a Darwinian sense, faced these problems many times, and the sites that adopted the most successful ways of dealing with them are still in business. Organizations that were less successful in adapting their methods to the difficulties of storing and using data have disappeared. Other companies learned from the strategies of the survivors and copied their approach.
As a consequence, many data centers today are comprised of these highly successful mainframes, along with myriad other distributed systems that are most likely running different applications on differing variants of UNIX and Windows. It’s quite difficult to integrate information from an Oracle database on a distributed platform with data from SQL Server from a Windows server, combine them both with mainframe data, and make everything available, say, to Excel running on a Windows laptop.
But even describing a problem such as this glosses over the real problem mainframe users face: the complexity of the data structures that can exist on a mainframe. A mainframe could be running z/OS or z/VSE as its operating system; it could have a z/VM hypervisor, or there could be a Linux on System z partition. Even assuming the mainframe is running just z/OS, the data could be stored in a relational database such as DB2, a hierarchical database such as IMS, or in other database formats (such as the network model used by IDMS), or in VSAM files. Combining mainframe data with data from distributed systems now seems like the easy task; combining data from the different mainframe storage formats seems like the major hurdle.
This is where Enterprise Information Integration (EII) applies. The challenge is to make the data stored in these heterogeneous data stores appear to users as one large, easily accessible data store—in a way that doesn’t compromise data security or integrity. In order for an EII tool be able to access the data, it must have full knowledge of any proprietary storage method used, and it must be aware of the fact that the database being accessed may have its own indexing and data access method.
Let’s briefly review some of the mainframe data stores available.
IMS, available since 1968, has grown into a complex database and transaction server. Because IMS is a hierarchical database, data is arranged in a parent-child configuration (much like a family tree or an organizational chart). In contrast, distributed databases are usually relational databases. A survey by the Virtual IMS Connection (www.virtualims.com) user group found that more than 40 percent of respondents were using IMS for finance-related applications, including banking, credit cards, or insurance. Less than 11 percent used IMS for testing; more than 5 percent had manufacturing applications, a similar percentage ran billing applications, and a little more than 5 percent were running health service-related applications. Nearly 3 percent were airlines, and the other sites ran a variety of different applications on their IMS system.
VSAM files have three different ways of storing data:
• Key Storage Data Set (KSDS) files store data using a key value as an index.