Rehost your VSAM verbs and sequential files on Azure

VSAMSql allows your mainframe VSAM verbs and sequential files to be rehosted to Microsoft SQL Server and Azure SQL databases for flexibility, redundancy, and interoperability. This enables a much more robust and cloud-friendly replatforming project, as relational databases are more versatile than file systems, especially when data must be shared across applications and containers.  

This product is articulated in two parts:  

Operations  

VSAMSql is setup to be as transparent as possible: a central configuration based on wildcards defines the mapping between VSAM (and sequential) files and relational tables. The mapping is more subtle than having one SQL table for every file: multiple files with the same characteristics (file and index structures) can be stored in a single relational table.  

This central configuration is all it takes: from there on, all accesses to these “files” are rerouted transparently to the appropriate SQL table, including all read and write operations, index-related behaviors, etc. JCL utilities and application programs can operate on these “files”, reading and writing them, without ever having to be aware of the fact that they are no longer stored as plain files on a file system.   

VSAMSql is truly transparent, it does not come with ifs or buts: the existing files are imported into SQL Server tables as they are, no questions asked, no cleansing nor normalization required.  

Interoperability  

VSAMSql stores data in binary form, just as it would be stored on a mainframe VSAM or sequential file. This allows for maximal transparency: it supports all possible idiosyncrasies, exotic data types, encodings and redefines. It also allows for a timely and simplified data migration process, since the existing data is migrated as is, without processing or even analysis.  

However, in this form the data is barely usable for new applications or ad hoc queries: it can only be processed by mainframe applications and batch processes.  

To open up the data, VSAMSql comes with a tool that generates a relational view on top of the table used for storage, using a COBOL copybook or PL/I structure for the definition of the fields, their types and their physical properties (offset and size). This view, enhanced with provided SQL Server triggers, allows data to be read and written as if it were a regular SQL table, which opens it up to modern non-mainframe applications, reporting application and ad hoc queries.   

This view is a live, direct access to the original data, with guaranteed transactional integrity and none of the latencies that come with solutions based on replication.  

For cases where these views must be used on large amounts of performance-critical data, they can be generated to be schema bound (as supported by SQLServer), to avoid the impact that comes with dynamically computed views, and to allow for additional indexing if necessary.