VSAM can be found on almost every mainframe. In some cases it is hardly used and in other cases there are full featured mission-critical applications based on VSAM. A number of factors are driving enterprises worldwide to modernize from VSAM to Oracle.
Why Migrate From VSAM to Oracle?
The challenges of VSAM are straightforward- the business wants to leverage the data housed in VSAM, but it’s not a database. It’s a file management system. Loosely speaking, therefore, it is “closer to the disk” than the DBMS is. In fact, the DBMS is typically built on top of some kind of file manager. Thus, the user of a file management systems will be able to create and destroy stored files and perform simple retrieval and update operations on stored records in such files.
In contrast to the DBMS, file managers:
- are not aware of the internal structure of the stored records, and hence cannot handle requests that rely on a knowledge of that structure (such as “find all employees with salary less than $50,000”).
- provide little or no support for security and integrity rules
- provide little or no support for recovery and concurrency controls
- have no true data dictionary concept
- provide much less data independence than the DBMS does
What Scenarios Drive VSAM to Oracle Modernization?
In summary, Oracle’s ability to efficiently manage many concurrent users, very large databases, and high transaction rates on multiple platforms makes it a better choice than VSAM in most situations. Let’s break it down.
VSAM provides a number of data set types or data organization schemes. They are:
- Key-sequenced data set (KSDS)
- Entry-sequenced data set (ESDS)
- Relative record data set (RRDS)
- Variable-length relative record data set (VRRDS)
- Linear data set (LDS)
When we work with customers evaluating the transition from VSAM to Oracle, the top business drivers are:
- Better Data Management: The interaction between batch, online and other data exchange activities and queries is much more efficient- so performance is improved and deeper data analysis can be performed.
- Cost: Proprietary language licenses and maintenance are typically expensive. Further development of such applications can be time consuming, restrictive and expensive.
- Resource availability: It is increasingly difficult to find qualified staff with the ability to administer, maintain or indeed further develop nonrelational/hierarchical data tiers.
- Availability: The market place has over the years of course reacted to the emergence of relational databases, and now there is little or no availability of mainstream hierarchical database systems and acceptable support models.
The top technical matters driving VSAM to Oracle transition are:
- Oracle database provides high level of scalability, ranging from workstation to mainframe, and is available on a wide range of platforms. VSAM is tightly coupled with the mainframe and hence has a restricted choice of platform.
- Oracle provides a high degree of security in the sense that the unit of data that can be individually protected ranges all the way from an entire table to a specific data value at a specific row-and-column position. In VSAM the security options are fairly limited and can be only at Dataset level.
- Oracle has support of a rich suite of tools/products for the whole range of activities like administration, management, data manipulation, data replication, data warehousing, performance monitoring, archival and report generation. Â Performance of VSAM applications is heavily dependent on the initial design and there is very little scope of tuning later.
- Oracle is web-enabled with built in Java support. Oracle data can be accessed from various systems using standard TCP/IP, ODBC, X/Open CLI, JDBC and SQLJ.
- Oracle supports disaster recovery. A disaster recovery copy of data can be easily identified by Oracle. There is no separate disaster recovery mechanism for VSAM.
VSAM to Oracle Conversion Solution
The Modern Systems VSAM conversion strategy includes the generation of a new relational database to replace the functionality, redefinitions, type-of-record indicators, and other data element structures that are currently part of most VSAM files. The new target database can reside on the mainframe or off the mainframe, and can use any of the standard relational database management systems (RDBMS): Microsoft SQL Server, Oracle or IBM DB2. The VSAM transformation process is automated.
Modern Systems also handles the conversion of the applications that use the VSAM files. Modern Systems can convert COBOL, PL/1, Assembler, JCL and Procs for VSAM applications.
The Modern Systems solution provides a complete replacement for all VSAM file functionality including multi-view records, occurring fields, indexes and more:
- VSAM record layouts
- Group-level elements
- Redefined data within records
- Occurring data
- Multi-View record types
- Indexes
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.
VSAM Data Conversion
The VSAM data extract and relational load process is simple, straightforward and fast. Modern Systems can provide a number of extract variations for sites that have special requirements for a short data conversion window. Special workbenches within DB-Shuttle® provide additional capabilities for tailoring your VSAM migration so that the new database meets your needs and requirements. Deliverables include:
- DDL Syntax for the new database
- Load Syntax (optional) for use by relational database load utility
- RI Check Syntax (optional) for use by relational database utility package
- RUNSTATS Syntax (optional) for use by relational database utility package
- VSAM Data Extract programs (generated in COBOL and fully self-documented) to unload all VSAM data to the correct format for the relational database load utility
- VSAM 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
Visibility and Knowledge Building
Modern Systems also ensures that the customer teams have a full understanding of the existing VSAM file structures, as well as a full understanding of the post-conversion relational databases. DB-Shuttle generates many reports and diagrams to assist with this knowledge-building process.
Regardless of where your company is on the VSAM to Oracle conversion journey, we can help. Contact us today to learn more!
