Data is one of the largest assets in any business. Accelerating an organization'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 among Fortune 1000 companies, but this old favorite 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 modeled using a nested hierarchical structure, similar to how species are related in the life sciences. Unfortunately, organizational 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; customized 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
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.