VSAM to RDBMS Migration

Migrating VSAM to RDBMS

Many large organizations today still store gigabytes of mission-critical data in VSAM data sets on platforms such as z/OS and BS2000/OSD. Often, these environments will have a variety of software applications (often built in-house or custom made) that access and manipulate the data in these files through different VSAM Data Access Techniques. Frequently, these VSAM-based applications are written in the COBOL programming language.

To help organizations with large amounts of data, database vendors like Microsoft, IBM and Oracle have invested huge sums of money in the development of database management systems, and large open source products such as MySQL and PostgreSQL, which have gained in features and popularity a lot. These products serve as a "layer" or platform that aid organizations in the better and easier management of their data.

Generally branded as an RDBMS (Relational DataBase Management System), these products take the concept of "data storage and access" and package it with advanced functionality. But despite these numerous attempts to replace relational databases with these new tools, they are still the working horse of all major corporations.

Understanding the technical barriers of migrating VSAM to RDBMS

Simply planning and executing the switchover of data from VSAM file storage to RDBMS hosting can be a difficult task in and of itself. Not only do large amounts of data need to be migrated, but the applications themselves need to be adapted and tested in order to ensure compatibility with the new RDBMS.

The adaptation and testing of large amounts of COBOL code for this purpose can be a lengthy process.

This white paper explores how using the right migration approach and methodology can help enterprises to retarget from VSAM to RDBMS.

White Paper Overview

• Data Structure
• OCCURS Mechanism
• COBOL REDEFINES Clause
• Index-Based versus Cursor-Based Program Flow
• Retargeting Issues

Get a copy of our white paper and contact our team to learn more.