VSAM can be found on almost every mainframe out there, and yet, in some cases it is hardly used. In other cases, there are full featured mission-critical applications based on VSAM. As organisations are under increasing pressure to modernise their legacy environments, there’s a powerful case for Automated VSAM Migration, moving data to a relational database management system (RDBMS), such as Microsoft SQL Server, Oracle or IBM Db2.
Why move data from VSAM?
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 database management system (DBMS) is. In fact, the DBMS is typically built on top of some kind of file manager. Thus, the user of a file management system 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 £40,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 modernisation?
A relational database system’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 organisation 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)
The top business drivers for organisations looking to evaluate the transition from VSAM to an RDBMS typically include the following:
- A need to improve 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.
- Exorbitant costs: Proprietary language licences and maintenance are typically expensive. Further development of such applications can be time-consuming, restrictive and expensive.
- Diminishing resources: It is increasingly difficult to find qualified staff with the ability to administer, maintain or further develop non-relational / hierarchical data tiers.
- Lack of availability: The emergence of relational databases has left customers with little-to-no availability of mainstream hierarchical database systems and acceptable support models.
- A desire to take advantage of hybrid Cloud support: letting DBAs run databases on a combination of on-premises systems and Public Cloud services to reduce IT costs.
The top technical matters driving VSAM migration are that an RDBMS:
- Provides a high level of scalability. VSAM is tightly coupled with the mainframe and hence has a restricted choice of platform.
- 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.
- 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.
- Is web-enabled with built in Java support. The RDBMS data can be accessed from various systems using standard TCP/IP, ODBC, X/Open CLI, JDBC and SQLJ.
- Supports disaster recovery. A disaster recovery copy of data can be easily identified by the RDBMS. There is no separate disaster recovery mechanism for VSAM.
Our Automated VSAM Migration solution
Our Automated VSAM Migration solution 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 / off the mainframe and can use any of the standard relational database management systems: SQL Server, Oracle, Db2 or PostgreSQL.
If you’re looking to modernise, you should look to solution providers who offer an Automated Refactoring solution for the applications and languages that use the VSAM files. For example, our solution refactors COBOL, PL/I, Assembler, JCL and Procs for VSAM applications.
Additionally, we provide a complete replacement for all VSAM file functionality including multi-view records, occurring fields, indexes and more, such as:
- 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 Migration
The VSAM data extract and relational load process is simple, straightforward and fast. We can provide a number of extract variations for sites that have special requirements for a short data conversion window. Special workbenches within our Automated VSAM Migration solution provide additional capabilities for tailoring the migration so that the new database meets each organisation’s 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; 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
Future proofing with added visibility and knowledge
Ensuring 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 is essential. Our ModPaaS (Modernisation Platform as a Service) solution generates many reports and diagrams to assist with this knowledge-building process. Regardless of where your company is on the VSAM to relational journey, we can help. Contact us to learn more about our processes, technologies and experience with VSAM.
Further resources
- On-demand webinar: Know the details, reduce the risk: How to begin your mainframe modernisation journey
- On-demand webinar: Rehosting mainframe applications
- Whitepaper: Liberate legacy data