Jan 18 ’13

IMS: Stretching Across Computing Platforms and Applications

by Trevor Eddolls in Enterprise Tech Journal

IBM’s Information Management System (IMS) has been an important part of the computing environment for more than 40 years, yet it’s still able to make use of the latest computing ideas and technology. The first “IMS READY” message appeared on an IBM 2740 terminal on Aug. 14, 1968, and the first mission of the IMS system was to inventory a massive Bill of Materials for the Saturn V rocket and Apollo space vehicle.

Today, IMS is more closely associated with financial institutions; they use it to access and process massive amounts of data quickly. Almost 90 percent of Fortune 1000 companies currently use IMS, and more than $3 trillion of transactions go through it daily.

But while processing huge numbers of transactions and quickly accessing data is good, it still leaves IMS as an island of technology inside an IBM mainframe environment. What people need in these days of hybrid mainframes and mixed platform data centers is some way to make the IMS data and transactions available to everyone, everywhere. The first destination might be other islands of mainframe technology, such as DB2, CICS and WebSphere MQ, and then users working on a laptop, tablet, or smartphone.

IMS for Everyone

It might be helpful to have IMS data easily available in a mash-up, a new application combining data from different sources. We need to be able to share with Oracle and SAP and similar systems. We will also want data available on Windows platforms—perhaps turning up in an Excel spreadsheet, but more likely talking with SharePoint. We may even want our IMS system to provide cloud computing facilities for some users. We need IMS to be as up-to-date and youthful as any other software out there!

The database part of IMS is often referred to as IMS DB; the transaction manager part is IMS TM.
IMS TM can use DB2 as its database instead of IMS DB, so in one sense, the IMS island can already talk to the DB2 island. However, the reality for many users is that they have data in DB2 and in IMS DB, and they want to be able to share this data.

Why would sites want to share their IMS data with DB2? There are several site-specific answers. Many sites need to provide users a way to interrogate their data outside the IMS environment. Reporting programs can change frequently as the business needs different information on which to make decisions; using DB2 as a source can provide greater flexibility. Some sites may want to incorporate the data in a Business Intelligence (BI) system or use it in their data warehousing application. For some sites, moving IMS data to DB2 provides a way of allowing vital, existing IMS transactions to continue to work while letting that data coexist elsewhere for use in newer applications.

Meeting the Challenges

Anyone who has tried the seemingly simple process of moving IMS data to DB2 knows that several challenges must be overcome. There can be issues with keys, data field challenges, redefined segments and fields, repeating groups, and non-keyed segments. In terms of data fields, you must consider invalid data, dates, text or comment fields, and binary or special fields. Within those, there can be complications with invalid data, non-numeric data in numeric fields, binary zeros in packed fields (or any field), or invalid data in character fields. Dates must be decoded or validated if the target column is DATE or TIMESTAMP. Many dates were complicated by the work carried ahead of Y2K, so finding someone with knowledge of that can be useful.

If a site has both IMS and CICS, there may be a time when a user needs to make a decision using information from transactions running on both systems. The obvious solution is to run two separate transactions on the two different systems, then separately combine the results to get the desired information. But this is where things become complicated because business logic and business units of work don’t easily map to the way the transactions were written. What’s needed is some way to seamlessly combine transactions running in the separate subsystems and make them appear to the user as a single, cohesive system.

A Single, Cohesive System

There are ways to achieve this, and by stepping down this road, sites are expanding what they can do with their transactions and how users can gain controlled access to the information they need. Web services, a method of communication between two devices over the Internet, facilitate this.

According to the Wordwide Web Consortium (W3C), a Web service is a software system designed to support interoperable machine-to-machine interaction over a network. To make this work, you need some lingua franca that all Web services can use. Web Services Description Language (WSDL) performs this job. The interaction with the Web service uses Simple Object Access Protocol (SOAP) messages. There are two classes of Web services: Representational State Transfer (REST)-compliant Web services using stateless operations and arbitrary Web services.

With REST, there are no objects or methods; everything is a resource. In a RESTful system, an agent communicates with a resource using its location, a verb describing the operation, and a representation of the desired state. In addition, there’s JavaScript Object Notation (JSON), which is a lightweight, data-interchange format that’s meant to be easy for people to read and write and easy for machines to parse and generate.

You’re most likely familiar with Service Oriented Architecture (SOA), which is an architecture for creating SOAP and WSDL from CICS and IMS transactions. Using SOA, it’s possible to make a transaction available from a browser, not just from a specially dedicated terminal. Once you Web-enable an application, it makes combining the transactions much easier.

An Enterprise Service Bus (ESB) provides a way to link what would otherwise be disparate systems—such as IMS and CICS. It can take one message type from one source and translate it to the message type the receiver requires. It can reverse the process when a response comes back. So the ESB monitors and controls the routing of message exchanges between services and deals with issues such as event handling and event choreography, data transformation and mapping, message and event queueing and sequencing, security or exception handling, protocol conversion, and enforcing communication service quality.

Using WebSphere MQ, you can connect to IMS and CICS. Messages are sent to and received from the appropriate MQ bridge. An ESB is connected to IMS and CICS services using MQ. Information can be carried in the MQIIH for IMS or the MQCIH for CICS, and is defined in this header region by the MQ CICS bridge. The Custom Mediation primitive or the MQ Header Setter mediation primitive provide access to this information. Users can create and modify the header information.

IBM provides the IMS Enterprise Suite SOAP Gateway, which it claims allows IMS applications to “send business event data to business event processing and monitoring engines such as IBM WebSphere Business Events.” The product lets a variety of applications, including .NET, Java, and most other sources, submit SOAP requests into IMS. IBM’s IMS Connect improves IMS TCP/IP access, making it easier to access IMS from the Internet. This is useful when connecting to TCP/IP clients and local z/OS clients.

IBM describes its IMS Universal drivers as “a set of SMP/E-installable Java drivers and resource adapters that enable access to IMS from z/OS and distributed (non-z/OS) platforms.” This can be local connectivity to IMS databases on the same Logical Partition (LPAR) or distributed connectivity through TCP/IP. This provides a way for IMS to be accessed from WebSphere Application Server (WAS), CICS, and other IMS systems.

IBM’s IMS XML DB lets applications access IMS DB while making it appear to be an XML database. There’s work involved here because the IMS DLIModel utility must create the IMS-to-XML mapping. This Java application can run in IMS, CICS, DB2, or WebSphere using the retrieveXML() and storeXML() User-Defined Function (UDF) extensions to the IMS Java Database Connectivity (JDBC) driver.

Many IMS TM users may be using the IMS Message Format Service (MFS), which handles formatting of messages sent between terminals and IMS. This extra layer means the IMS applications don’t need to handle device-specific characteristics in messages. Using IMS MFS SOA support (a combination of Rational Application Developer and IBM Integrated Designer), you can Web-enable existing business logic.

There are also several third-party software products that can help make IMS applications available on the Web.

Once a transaction is Web-enabled, users can access it from any browser on any platform. That opens up the possibility of making IMS data available to users sitting in front of PCs as well as people using tablets or smartphones. To see IMS in action, go to http://www.youtube.com/watch?v=c2bGHjCQQZo to see “Invoking z/OS IMS using iPhone, using Web 2.0 and Web services.”

While that has a huge “wow” factor, for IMS sites, it introduces security concerns about who has access to your data and who might see some sensitive information on someone else’s iPhone as they wait at the airport or travel by train. As an aside, there was always a security risk with people reading “sensitive” documents over someone’s shoulder. Some laptops are designed so they can be best seen from the front and anyone looking from the side won’t see very much. But tablets and smartphones are designed for visibility from all directions and this can be an issue.

Broadening IMS’ Multi-Platform Reach

It’s possible to combine IMS data and transactions with DB2 and CICS, and make them accessible from a browser. The next stage to enrich the users’ experience and make that information even more useful is to mash-up the data, combining more than one source of information to provide better information.

The IBM Mashup Center provides a host of IMS resources, letting users customize IMS transactions without modifying the original application. There’s also the opportunity to create more traditional mash-ups with Web-enabled IMS information being combined with information from other sources. Provided there’s an easy-to-use interface, and it provides insights not available elsewhere, people will use it. While mash-ups originated as a hobbyist-type activity, major commercial enterprises have been embracing the technology.

But not all the data in the world is stored in IBM databases. One of the most popular non-IBM choices is Oracle, which has been around since 1978. In terms of connectivity, Oracle has Oracle Access Manager for IMS TM applications, which is based on the IMS External Subsystem Attachment Facility (ESAF), and allows communication to mainframe-based Oracle systems. An alternative is to install and configure the Oracle Connect for IMS Gateway.

Newer versions of Oracle won’t run on native z/OS, but many sites run Oracle systems under Linux for System z. This gives sites the familiarity of an Oracle environment with the power of System z. They could use the Oracle Tuxedo Application Runtime for IMS, which runs IMS applications using Oracle Tuxedo. It’s a way of moving the application off the standard mainframe, if that’s desirable, and into Linux on System z or other environments.

For sites looking for partial rehosting of IMS applications, mainframe connectivity is maintained using Tuxedo Mainframe Adapters (TMA). TMA offers transactional connectivity to IMS TM and CICS. The rehosted components look like a remote IMS region to the mainframe. There’s also the Oracle Java CAPS Adapter for IMS. This IMS adapter enables the Oracle Java CAPS ESB to connect to IMS TM applications using IMS Connect. The adapter provides access to the input and output descriptors of the IMS applications without changing the application.

Using the IMS SOA Integration Suite provides access to SAP and other systems. Third-party products can also help by using the WSDL, discussed earlier, as a way of integrating IMS with non-mainframe systems. Although, again, SAP could be running under Linux on System z.

With so many Windows PCs and data centers using Windows servers to drive computing in those environments, it’s useful for IMS to be able to reach out to the Microsoft platforms, especially SharePoint, Microsoft’s Web application platform for intranet content management and document management. It has a similar look-and-feel to Microsoft Office and provides intranet portals, document and file management, collaboration, social networks, extranets, Websites, enterprise search, and BI. SharePoint provides central management, governance, and security controls; an estimated 78 percent of Fortune 500 companies have it installed.

Third-party suppliers can offer ASP.NET terminal emulation software, which allows the screen views from IMS TM to be available to SharePoint users and for those users to interact with the data. IBM has the Windows SharePoint Services connector, which enables its Content Integrator to connect to and access content from Windows SharePoint. IBM’s Content Integrator integrates images, documents, and workflow processes. It uses a set of Application Program Interfaces (APIs) to create applications.

IBM Content Collector for Microsoft SharePoint (formerly InfoSphere Content Collector for SharePoint) is an IBM Enterprise Content Management system that now includes SharePoint users. It provides collection and archiving of SharePoint content. Microsoft BizTalk Server contains adapters that let data be exchanged between BizTalk Servers and IMS and CICS. Biztalk and SharePoint are separate things, but can be integrated. Using Open Database Connectivity (ODBC), and for ease, third-party software, it’s possible to make IMS data available in Excel spreadsheets, and take data from Excel and integrate it into IMS DB.

For many organizations, using cloud computing is seen as the way forward; the newer large IBM processors, such as the new zEC12, make it easy for the mainframe to effectively run a private cloud for users. With cloud computing, users don’t care where applications are sourced or where their data is stored; they just know it’s somewhere in the cloud. With SOA, IMS applications become available as Web services and users can interact from anywhere. We’ve mentioned techniques using WSDL, SOAP, REST, and JSON you can use to move to cloud-like, everything-as-a-service, computing.


IMS is no longer an island of computing excellence separated from other islands on a mainframe. IMS subsystems can communicate with other IMS subsystems whether on the same mainframe or a connected one. IMS can communicate in both directions with CICS and DB2. Together, they can create a single business unit of work. Using SOA techniques, IMS becomes available from any platform that can run a browser; users don’t need to be on an attached terminal. Using those techniques and others, IMS can share information with Oracle and SAP, and can be integrated with Windows platforms. In fact, you might say, 44-year-old IMS is pretty ubiquitous—it’s a metaphorical high-performing spider in a web that stretches across computing platforms and applications. It’s the essence of modern software.