|
Highlights
-
NeoData Data Mapper analyzes record definitions and sets up mappings between those definitions and selectable table models
-
NeoData File Handler works with standard COBOL VSAM statements but reads and writes the data from/to a SQL Server database – so data is stored in SQL Server but no changes are required to the COBOL code.
-
Table structure in SQL Server can be selected from a variety of models making it possible to optimize the support for each file depending on its use (e.g. high batch sequential access or high frequency of ad-hoc user queries)
-
NeoData Views enable field level access to data in SQL Server, even when a simple table model is being used with many COBOL fields combined as a single SQL binary column
-
NeoData Data Import Tool helps import VSAM data to the selected SQL Server schema
-
Friendly user interface and helpful documentation make NeoData easy to learn and quick to deliver results
Detailed
Features and Benefits
NeoData provides the components you need to determine how your VSAM data will map to SQL Server tables, load that data into the tables, access that data from unchanged COBOL programs and query the data in SQL Server. The tables below list the key features and benefits of the main NeoData components.
NeoData Mapper
NeoData File Handler
NeoData Expanded Views
NeoData Data Import Tool
Integration with Other Products
NeoData Mapper
Feature
Summary |
|
Detail
of Feature |
|
Benefit
of Feature |
Primary NeoData interface
|
|
NeoData Mapper provides the primary interface for driving NeoData and its component tools.
|
|
Focuses you on the main task required when using NeoData – determining the mapping from COBOL to SQL record/table layouts.
|
| Create maps from COBOL code |
|
The main function of the Data Mapper is to help you set up the relationship between COBOL record descriptions and the database schema that you are going to use.
Data Mapper does most of the work for you, analyzing the COBOL record definitions to present you with a record tree and guiding you through the choices you need to make.
|
|
Ability to use actual code from COBOL copybooks to present the information that the COBOL programs will expect to read, including information such as where redefinitions of record types occur.
|
| Configure maps |
|
NeoData provides the following types of mapping between COBOL data descriptions and SQL tables:
- Single Table
Basic schematization of COBOL fields to SQL columns. With this mapping type, all portions of records that potentially map to different types (redefined), are mapped to binary SQL Server columns
- Single Table with Discrimination
With this technique a single table contains the superset of all incompatible elementary columns. Discriminators are specified to determine which record types map to which columns.
- Multi-Table
Again, discriminators are used to determine the appropriate schema for each particular COBOL record, but different record schemas are mapped to different SQL tables.
|
|
Different mapping options give you flexibility in determining the right kind of mapping for each file. Certain record structures force a choice between good SQL query usability and good batch performance (typical online usage seldom presents performance issues) – having a number of mapping options allows you to select the best option for your needs. |
| Preview Schema |
|
Lets you preview and copy the actual SQL code required to create the SQL tables for the data map. |
|
Allows you to confirm you are happy with the code to be used or copy the code for use in your own programs.
|
| Show Byte Layout |
|
Displays the byte alignment of the COBOL record. |
|
Useful aid to checking or understanding the structure of the COBOL data.
|
| Extract COBOL Records |
|
Creates a COBOL record description from the NeoData map. |
|
Can be a useful layout for testing or a convenient way of obtaining a consistently formatted record layout. |
Neo Data File Handler
Feature
Summary |
|
Detail
of Feature |
|
Benefit
of Feature |
| COBOL external file handler |
|
The key component of NeoData, the external file handler receives the COBOL VSAM I/O statements and, guided by the maps created using the Data Mapper, accesses the data stored in SQL Server. The file handler supports all the standard COBOL I/O statements:
- OPEN
- READ
- WRITE
- REWRITE
- DELETE
- CLOSE
It also supports record locking.
|
|
Enables data to be migrated to SQL Server without having to change COBOL program source code. |
| Uses maps to interpret COBOL I/O in SQL terms |
|
The file handler uses the maps created using the NeoData Mapper to relate the COBOL I/O to the tables set up in the database. The architecture is sufficiently dynamic that you can switch between mapping types without having to restart the COBOL program – useful when comparing the different mapping options. |
|
The XML-based architecture combines flexibility with technical sophistication. |
NeoData Expanded Views
Feature
Summary |
|
Detail
of Feature |
|
Benefit
of Feature |
| Create SQL reports for tables with non-schematized fields |
|
Expanded Views provide the ability to access data that is stored in SQL in ways that mask the data structure to SQL (e.g. when multiple fields are stored as a single binary column). (Read-only) reports and queries can be run against the data as if it were stored in a SQL-visible way. |
|
User SQL query and reporting ability is maintained even though data is stored in SQL Server using a mapping type that would normally limit the usability of that data.
You can choose a mapping type that optimizes performance without removing your users’ ability to run queries and reports.
|
| Preview Expanded Views |
|
You can inspect and, if you wish, edit the SQL code that is generated to support Expanded Views.
|
|
Gives confidence that the users are seeing what you expect them to see. |
| Deploy Expanded Views |
|
NeoData writes Expanded Views to the database for you. |
|
All you or your user has to do to use the Expanded Views is to access them from SQL Server Management Studio.
|
| Views available to SQL queries |
|
Once the Expanded Views have been deployed they are available to standard SQL queries. |
|
Gives the data access your users frequently require. Views can be trimmed and edited to create custom views, using SQL. |
NeoData Data Import Tool
Feature
Summary |
|
Detail
of Feature |
|
Benefit
of Feature |
| Import data to SQL Server using selected schema |
|
Imports data from sequential files to SQL Server using the specified/chosen mapping type.
|
|
Aids the migration of data from its original COBOL format to SQL Server. |
| Export data from SQL Server |
|
Exports data from SQL Server tables that can be accessed by NeoData maps to sequential files. |
|
Enables moving data to other data handling tools or reschematizing by exporting using one map and importing using another map.
|
| Available in Data Mapper and from the command line |
|
Invoke Data Importer from the Data Mapper Tools menu or from the command line.
|
|
Ease of use within the Data Mapper. Ability to use import function in automated scripts. |
Integration with Other Products
Feature
Summary |
|
Detail
of Feature |
|
Benefit
of Feature |
| NetCOBOL for .NET integration |
|
NeoData works with the External File Handler Interface provided by NetCOBOL. Setting a few options and ensuring the file name points to the NeoData map file redirects I/O through NeoData to SQL Server.
|
|
Switch between standard COBOL I/O and NeoData is accomplished quickly and easily. |
| NeoKicks integration |
|
NeoData supports NeoKicks File Connector interface, which means that CICS I/O statements can be directed through the NeoData file handler to SQL Server.
|
|
Using SQL Server as an alternate file system for CICS I/O is accomplished quickly and easily. |
| NeoBatch integration |
|
NeoData files (which are represented by maps) can be cataloged for use in batch jobs. They can also be used with IDCAMS for REPROducing, etc.
|
|
Makes moving batch to NeoData a simple and natural process for those familiar with batch systems. |
| SQL Server integration |
|
NeoData integrates tightly with SQL Server making it easy for:
- Applications to connect to SQL Server
- Schema to be set up in SQL Server
- Data to be imported to SQL Server
- Expanded Views to be deployed to SQL Server
- Queries to be performed against NeoData-created tables
|
|
Working with NeoData is an effective, pleasurable experience. |
An In-Depth Look at NeoData
The following sequences of screen captures let you see some of the features of NeoData at work.
NeoData Mapper
Data Import Tool
Viewing Data from SQL Server
Watching Data Access with Visual Studio Debugger
NeoData Mapper
The NeoData Mapper guides you through the process of mapping COBOL records to SQL Server tables, letting you select from the various options available and then generates a map file and database schema for you that accomplish the mapping of COBOL I/O to SQL Server. Walk through the following steps to get a feel for the intuitive process provided by NeoData.
Create Map from Code
Provide the COBOL record description(s) to NeoData. You can insert these directly from a COBOL copy book or extract them from a COBOL file by using the Browse COBOL File function.
NeoData analyzes the record descriptions to give a tree structure on which you can work – displayed in the left hand pane of the snapshot below. The right-hand pane shows the properties for the item selected in the left-hand pane (in this case the item FJ-CUST-NO).
You then walk down the tree structure and properties, setting the required values.
Specify connection string
Enter the database connection string.
Specify target column type
For each item you can either accept the SqlColumnType determined by NeoData or select an alternate type based on your understanding of the data item.
For key items, select the key type
Specify the key items for the file by selecting the item(s) in the tree and selecting the key type from the KeyType drop down list.
Specify the discriminator field
Where there are multiple record types for the one file, or REDEFINES within the record, you can specify the field that determines which record type to use.
NeoData provides you with a list of possible discriminator fields (those common to all the record types).
Specify the discriminator type
NeoData supports a variety of ways of checking the values in the discriminator field. Select the appropriate method from the DiscriminatorType drop down list.
Check schema generated for file descriptor map
Having set the appropriate properties for this file, you can check the schema NeoData will generate to ensure that you haven’t missed any details.
Data Import Tool
With the schema and NeoData map set up you can now use the import tool to populate the tables in the database. This is a simple matter of pointing to the file and map, specifying some file details and clicking the Create Tables and Import Data button.
Viewing Data from SQL Server
Your data is then accessible from SQL Server as well as from your COBOL applications.
Watching Data Access with Visual Studio Debugger
Debugging the COBOL code looks just the same as it does when accessing data in standard VSAM files with the ability to watch record values but the data is actually being stored in SQL Server as illustrated in these snapshot
System Requirements
Software requirements
NeoData requires the following:
- Microsoft Windows XP® with Service Pack 2 (or later) or
Microsoft Windows Vista
- Microsoft SQL Server 2005 Developer’s Edition
- Microsoft .NET Framework version 2.0 or higher
Computers on which the "Make Map" function is used (in which COBOL code is analyzed to create a record tree structure) also need to have:
- Fujitsu NetCOBOL for .NET version 3.1 or higher with Microsoft Visual Studio® .NET 2005 (for developing .NET COBOL programs)
Hardware requirements (minimum)
- Intel Pentium 4 or higher, or AMD equivalents
- 1 GB RAM recommended (minimum)
Frequently Asked Questions
NeoData Features
- What types of VSAM files does NeoData emulate?
- Will I have to change much COBOL code?
- Can NeoData support any COBOL record definition?
- What SQL platforms does NeoData support?
- Can I write new programs that use SQL to access the data I’ve migrated to SQL Server using NeoData?
- What are the performance implications of moving my data to SQL Server?
- Does NeoData work for non-mainframe indexed files, such as those created by NetCOBOL or Micro Focus COBOL?
Learning and Using NeoData
- How long does it take to become proficient in using NeoData?
- How much effort is required to create the NeoData maps?
- What is involved in bringing a VSAM file from the mainframe to work with NeoData under Windows?
- Do you recommend we move all our data to NeoData/SQL Server?
- Is there a long-term requirement to recode programs in SQL?
- How do we verify NeoData’s accuracy?
NeoData Features
1. What types of VSAM files does NeoData emulate?
A: NeoData is designed to emulate indexed KSDS file types.
2. Will I have to change much COBOL code?
A: No. NeoData is designed such that code changes are not required. If a filename is embedded in code, it will need to be updated to point to a NeoData map, but otherwise there are no code changes required within a COBOL application.
3. Can NeoData support any COBOL record definition?
A: In binary mode, NeoData can support nearly any indexed COBOL record that can fit in a SQL row. Fully-schematized NeoData maps will support many COBOL records, including records with a single record-type discriminator, but it is easy to come up with cases that would be too complex to be useful in a fully-schematized map. SQL Server also has some limitations on rows over 8060 bytes.
4 What SQL platforms does NeoData support?
A: Microsoft SQL Server 2005 (with limited support for SQL Server 2000).
5. Can I write new programs that use SQL to access the data I’ve migrated to SQL Server using NeoData?
A: Certainly. Once the data is in SQL Server you can access and update it like any other SQL Server data, such as might be done with ADO.NET. If you know this is something you want to do in the future, you should use a mapping type that schematizes all your data so that it is readily accessed from other programs.
6. What are the performance implications of moving my data to SQL Server?
A: How moving from VSAM to using NeoData and SQL Server affects performance depends on the nature of the application and the mapping type used. Online applications which access the data randomly may well see performance improvements; batch applications that process all data sequentially will likely see a reduction in performance. Simple mapping types have a smaller performance overhead than complex mapping types.
It is also worth bearing in mind that there may be performance savings that can be realized indirectly. For example, some customers are finding it effective to remove Sort steps from their batch jobs because SQL Server enables them to access the data in whatever order they specify, so they do not need to use up their machine cycles forever sorting data into one order or another.
7. Does NeoData work for non-mainframe indexed files, such as those created by NetCOBOL or Micro Focus COBOL?
A:. Yes. Any indexed file application can benefit from NeoData provided the record definition is supportable and the programs work with NetCOBOL for .NET.
Learning and Using NeoData
8. How long does it take to become proficient in using NeoData?
A: Anyone familiar with COBOL record structures and SQL databases will feel comfortable operating NeoData within minutes and reach full proficiency within days.
If you are using NeoData as a means to introduce yourself as well as your data to SQL Server, then the learning curve is longer – you’ll still be able to have COBOL programs accessing SQL Server data relatively quickly, but it will take longer to reach full proficiency as that requires an understanding of how different mapping choices affect the operation of the SQL database.
9. How much effort is required to create the NeoData maps?
A: That depends on the complexity of the record. Records with no REDEFINES, no OCCURS clauses, and no data items where you want to map several items to one SQL type (e.g. mapping time-of-day/day/month/year to a DateTime type) involve negligible effort. Each addition of complexity in a record structure will require another step in the mapping process.
The NeoData Mapper helps you through these steps one at a time so the mapping process is methodical and straightforward.
10. What is involved in bringing a VSAM file from the mainframe to work with NeoData under Windows?
A: The basic steps of migrating a VSAM file are:
- unload the VSAM file to a sequential file
- transfer the sequential file from the mainframe to Windows
- convert the data from EBCDIC to ASCII using a tool like the Data Converter from Fujitsu which understands COBOL data types and can convert or not convert fields intelligently
- use the NeoData Import Data tool to populate the tables in SQL Server
11. Do you recommend we move all our data to NeoData/SQL Server?
A: That is a decision you need to make based on the nature and use of your data and benefits your organization may wish to obtain by having a single data repository. We certainly believe that NeoData provides an excellent route for making data more accessible to your end users without requiring extensive application rewrites. However, data that you do not wish users to access can reasonably stay in VSAM (or NetCOBOL indexed file) form.
12. Is there a long-term requirement to recode programs in SQL?
A: No. NeoData gives you the ability to store your data in SQL Server while maintaining the design and structure of your COBOL applications. If you want new reports, you can create those using whatever technology best fits your needs, but you will only update your COBOL programs as business needs dictate.
13. How do we verify NeoData’s accuracy?
A: One of the big attractions of NeoData is that application functions are not changed, so you can use already established tests to verify that your applications continue to work as expected.
A big challenge of using other routes to SQL Server, such as designing a database from scratch and rewriting the code to support the new database, is that applications can change in fairly fundamental ways (e.g. items use different data types, data is fetched in a different order or in different collections, actual processes are changed). Existing tests won’t work and it becomes extremely difficult to verify that the new system is giving the expected results.
|
