IMS to Db2 Conversion: How It Works
Blog //09-02-2022

IMS to Db2 Conversion: How It Works

by Rob Anderson, Vice President of Marketing and Product for Application Modernization

Data is one of the largest assets in any business. Accelerating an organisation's ability to share and deliver trusted information is essential to the success of that business. IMS still is one of the most popular databases amongst Fortune 1000 companies, but this old favourite is now squarely in the crosshairs of a big data rivalry.

Why Leave IMS? It Just Works!

IMS, created in 1966, is literally the granddaddy of all transaction management and database systems. It is made up of a hierarchical database and an online transaction processing system. IMS works with traditional mainframe languages like COBOL, Assembler, and PL/I. According to IBM, IMS processes more than 50 billion transactions per day. So why rock the boat?

The IMS data model is based on the premise that data can be modelled using a nested hierarchical structure, similar to how species are related in the life sciences. Unfortunately, organisational data does not follow pure hierarchical relationships. Although simple and powerful, the limitation of hierarchies (each data node has only one parent) has allowed IMS and other hierarchical systems to be surpassed by more versatile technologies like IBM's Db2. When we work with customers evaluating the transition from IMS to relational Db2, the top business drivers for change are:

  • Better Data Management: Time-to-reporting is faster and deeper data analysis can be performed.
  • Cost: Mainframe licenses and maintenance are typically expensive. Further development of such applications can be time-consuming, restrictive, and expensive.
  • Resource availability: It is becoming increasingly difficult to find qualified staff with the ability to administer, maintain, or indeed further develop non-relational/hierarchical data tiers.
  • Availability: It's no surprise that the marketplace has reacted over time to the emergence of relational databases. Nowadays, there are very few if any - mainstream hierarchical database systems and acceptable support models.

 

How To: IMS to Db2 Refactoring and Migration

The Advanced IMS Refactoring strategy includes the generation of a new relational database to replace the functionality, parent-child relationships, and other data structures that are currently part of the IMS hierarchical database. The new target database can reside on or off the mainframe and can use any of the standard relational database management systems (RDBMS): Microsoft SQL Server, Oracle, or relational Db2. The IMS transformation process is automated. Advanced also handles the conversion of the applications that use the IMS databases. Advanced can convert COBOL, Assembler, Easytrieve, JCL and Procs for IMS applications. The goal is to provide a complete replacement for all IMS database functionality; including multi-view records, parent-child relationships, indexes and more.

The resulting database is fully relational. Primary keys and index definitions are automatically created. All constraints are generated into the resulting DDL. Table spaces, indexes, table names and column names are all generated according to your naming standards. The resulting relational database is fully relational. Primary keys, foreign keys and index definitions are automatically created. All constraints are generated into the resulting DDL. Table spaces, indexes, table names and column names are all generated according to your naming standards. As part of the delivery process, the following component types are available for installation in the new relational database processing environment:

  • Data Definition Language (DDL) Syntax for the new database
  • Load Syntax (optional) for use by the relational database load utility
  • RI Check Syntax (optional) for use by the relational database utility package
  • RUNSTATS Syntax (optional) for use by relational database utility package
  • IMS Data Extract programs (generated in COBOL and fully self-documented) to unload all IMS data into the correct format for the relational database load utility
  • IMS Data Extract JCL (optional; customised to your environment) to execute the extracts and other key-processing utilities
  • DCLGEN syntax (optional) to define COBOL layouts of the tables for replacement applications

Special workbenches provide additional capabilities for tailoring your IMS to Db2 migration so that it better meets your needs and requirements:

  • Rename Workbenches to allow full naming of all tables, columns, table spaces and indexes using a rules basis or a full-name basis
  • Data Cleansing Workbench to provide rule-based data cleansing during the IMS data extraction process
  • Date Conversion Workbench to allow DATE type columns in the new relational databases (all date formats are supported)
  • Element Rename Workbench, which allows selection of group level or elementary IMS fields for use as columns in the relational database
  • Record Re-Definition Workbench to allow changes to field types and lengths during the refactoring process
  • Segment workbench, where copybook or hard-code record layouts are associated to the IMS database segments
  • Multi-view workbench processing to allow the specification of multiple data layouts for a single IMS record so that the conversion can include multiple tables to replace the multi-function IMS record

Conclusion

Hierarchical and relational databases have grown up as separate data management solutions and provide different roles. Hierarchical systems are best used for mission-critical work and for that which requires the utmost in performance. Hierarchical data structure relationships are predefined having access paths distinct and ready to be used by the application. Relational is best used for decision support, and data elements are joined during database calls - producing on-the-fly result sets for immediate analysis.

Further Resources

Blog Application Modernisation Application Modernisation and Migration Application Understanding Assessment Application Modernisation Application Modernisation and Migration Application Modernisation Strategy Application Re-architected and Reintegration Application Understanding
Rob Anderson

Rob Anderson

PUBLISHED BY

Vice President of Marketing and Product for Application Modernization

Rob Anderson is Vice President of Marketing and Product for Application Modernization. He has spent the better part of the past decade developing, marketing, and selling mainframe modernization solutions, and has had a front-row seat in the transformation of the industry and its surrounding ecosystem.

Read published articles