We want to migrate ISAM data files created by an RM/Cobol application easily to a database format. We don't find a tool to facilitate this process and would prefer not to write for every data file a dump program to export the data into txt files to load this files into a database in a second step. Are there people having done this before, with a certain tool?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Migrating ISAM files from RM/Cobol 2
- Thread starter Patten
- Start date
Hi Patten,
I have been using Relativity for years now and must say it is a good product. It does allow you direct ODBC access to your existing Cobol Files. Just a few points about your comments above.
Cost for customers : the cost is there whatever database approach that they take, not sure what the costing is though for Relativity.
Support : You can link Access directly to the catalogue, thus allowing access directly to the cobol files.
Relativity catalogues are very easy to set up. If you are looking to convert from Cobol then buy a copy of Relativity. Set up your catalogues correctly and use that to convert all your data to SQL.
Remember that some of your customers will want to stay on the platform that they are on with no changes. We have been migrating people of Unix to Windows for over 5 years now. However if a Unix customer do have problems, we can bring their data back to the office and interogate it using Access Queries and Realtiviy.
Not sure if this lot helps.
Hammy.
I have been using Relativity for years now and must say it is a good product. It does allow you direct ODBC access to your existing Cobol Files. Just a few points about your comments above.
Cost for customers : the cost is there whatever database approach that they take, not sure what the costing is though for Relativity.
Support : You can link Access directly to the catalogue, thus allowing access directly to the cobol files.
Relativity catalogues are very easy to set up. If you are looking to convert from Cobol then buy a copy of Relativity. Set up your catalogues correctly and use that to convert all your data to SQL.
Remember that some of your customers will want to stay on the platform that they are on with no changes. We have been migrating people of Unix to Windows for over 5 years now. However if a Unix customer do have problems, we can bring their data back to the office and interogate it using Access Queries and Realtiviy.
Not sure if this lot helps.
Hammy.
Relativity adds ODBC access to your RM/COBOL indexed files. (C-ISAM is the trademark of a different indexed file system owned now by IBM. Relativity also supports C-ISAM through its support for Micro Focus, which uses C-ISAM on Unix.) As far as the customer is aware, there is no difference. Your RM/COBOL files constitute a database, one accessible through ODBC.Patten said:
Your don't have to create such programs to use Relativity. That is the concept behaind the product: drop-in ODBC access without perturbing the application at all. Regarding application releases: our customers are (almost) all COBOL application vendors, so there are special features built into Relativity to allow easy upgrades of the catalog (where the mappings between the physical and logical schema are store) when you have revisions of your file layouts, both on the development saide and at the customer side. Customer changes to the catalog are not lost. (Personal note: I helped develop Relativity after having been the development manager in a COBOL application vendor. I absolutely know how important it is to be able to deploy maintenance releases.)Patten said:
Patten said:
List price for Relativity is about 50 $US per ODBC connection, 50 connection minumum. Oracle, in a bid to become more competitive with SQL Server, has lowered its pricing to $5000 per processor and $150 per named seat. If you are a contracted partner of Liant other rates and connection minima are available, I think (I am just a development weenie, after allFrederico said:
![[bigsmile]](/data/assets/smilies/bigsmile.gif "[bigsmile] [bigsmile]")
).Tom Morrison
Tom et al,
Many people don't have a solid handle on ODBC, Indexed fiels and the like. I know there is confusion out there about using SQL syntax to access data. The whole concept of ODBC is very much misunderstood by even seasoned programmers.
The idea of using SQL syntax to access "flat" files is still not clearly explained to many. The "distinction" between Oracle and ODBC remains largely obscure to many. And so on...
I don't mean to sound patronizing or anything, but I think we need to point Patten to this information first, before telling him what tool to buy.
Dimandja
Many people don't have a solid handle on ODBC, Indexed fiels and the like. I know there is confusion out there about using SQL syntax to access data. The whole concept of ODBC is very much misunderstood by even seasoned programmers.
The idea of using SQL syntax to access "flat" files is still not clearly explained to many. The "distinction" between Oracle and ODBC remains largely obscure to many. And so on...
I don't mean to sound patronizing or anything, but I think we need to point Patten to this information first, before telling him what tool to buy.
Dimandja
Ok. Let's take it one step at time.
What is ODBC?
ODBC stands for "Open DataBase Connectivity", and was developed by Microsoft.
The idea was to be able to access any data, from any application, regardless of what database management system is hosting the data in question.
Obviously, for this to work you need a bridge (database driver, such as Relativity(?)) between the application and the database of interest. The database management system will also need to be able to talk to this driver (i.e. ODBC compliant database, such as RM/COBOl and MF files).
The job of the database driver is to translate ODBC commands into commands that the database understands and back.
(Any errors in this explanation are my own.)
Dimandja
What is ODBC?
ODBC stands for "Open DataBase Connectivity", and was developed by Microsoft.
The idea was to be able to access any data, from any application, regardless of what database management system is hosting the data in question.
Obviously, for this to work you need a bridge (database driver, such as Relativity(?)) between the application and the database of interest. The database management system will also need to be able to talk to this driver (i.e. ODBC compliant database, such as RM/COBOl and MF files).
The job of the database driver is to translate ODBC commands into commands that the database understands and back.
(Any errors in this explanation are my own.)
Dimandja
That said, let's see what Patten is asking for:
1. Patten, there is no database to move to: your existing database is already ODBC compliant.
2. Since Relativity is your ODBC driver to your existing database, what are you worried about?
1. Unless you are programming in Windows and your DBMS is Access, you will not find a free ODBC driver.
2. If your customers' ODBC drivers (if they actually have them), cannot understand your existing DBMS, what good are they?
3. Since Relativity offers you an ODBC compliant layer to a database management system that is already ODBC compliant (your "cobol" indexed files), what you need is client applications that are ODBC compliant.
If your customer tools cannot talk to Relativity, then your customers are perhaps ready to provide an ODBC driver and a DBMS their driver can talk to?
My impression so far is that without the obscurity surrounding your customer "tools", you already have:
(1) an ODBC compilant client applications: your COBOL code.
(2) an ODBC compliant database management system: your indexed files.
(3) a working ODBC driver to bridge your indexed files with any ODBC compliant client application.
(Again: any accuracies are my own)
Dimandja
1. Patten, there is no database to move to: your existing database is already ODBC compliant.
2. Since Relativity is your ODBC driver to your existing database, what are you worried about?
1. Unless you are programming in Windows and your DBMS is Access, you will not find a free ODBC driver.
2. If your customers' ODBC drivers (if they actually have them), cannot understand your existing DBMS, what good are they?
3. Since Relativity offers you an ODBC compliant layer to a database management system that is already ODBC compliant (your "cobol" indexed files), what you need is client applications that are ODBC compliant.
If your customer tools cannot talk to Relativity, then your customers are perhaps ready to provide an ODBC driver and a DBMS their driver can talk to?
My impression so far is that without the obscurity surrounding your customer "tools", you already have:
(1) an ODBC compilant client applications: your COBOL code.
(2) an ODBC compliant database management system: your indexed files.
(3) a working ODBC driver to bridge your indexed files with any ODBC compliant client application.
(Again: any accuracies are my own)
Dimandja
To conclude:
The beauty of it all is that you can open your indexed files to any ODBC compliant programs (including the "tools"), without changing anything at all - in your own COBOL programs nor in your database: simply install Relativity.![[pipe]](/data/assets/smilies/pipe.gif "[pipe] [pipe]")
Dimandja
The beauty of it all is that you can open your indexed files to any ODBC compliant programs (including the "tools"), without changing anything at all - in your own COBOL programs nor in your database: simply install Relativity.
Dimandja
Allow me to add some additional information about ODBC, and a bit also about Relativity.
According to Microsoft, ODBC is a specification for a database API, independent of any one DBMS, operating system or programming language. The ODBC API is based on the Call-Level Interface (CLI) specification from the two standards-making bodies, X/Open and ISO/IEC. You may find a copy of the ISO/IEC 9075-3:1995 Standard here. ODBC specifies not only a traditional API (such as the names of functions, their types of parameters, etc) but also an SQL grammar.
ODBC seems to have a reputation for introducing inefficiencies, probably due to the earliest implementation of some ODBC drivers for database systems already having a call-level interface. However, most of the real (as opposed to imagined) inefficiencies have been removed from modern ODBC drivers. In the present case of Relativity, one must consider the inefficiency of moving data from one database (the group of COBOL indexed files) to another as well as the inefficiencies borne by the end-user due to the loss of real-time access to live data.
Perhaps it seems incongruous to some that a set of COBOL indexed files can be represented as a relational database. Consider, however, that most relational database systems are (or have been at some time in their lifetimes) built upon indexed file systems. Examples would include Informix/C-ISAM, Pervasive SQL/Btrieve, MySQL, etc. The difference is the fact such relational database systems apply a large number of constraints to the representation of data in the physical schema that are not present in COBOL-managed indexed files. The innovation of Relativity, described in US Patent 5,826,076, consists largely of accommodating that lack of constraints.
Tom Morrison
According to Microsoft, ODBC is a specification for a database API, independent of any one DBMS, operating system or programming language. The ODBC API is based on the Call-Level Interface (CLI) specification from the two standards-making bodies, X/Open and ISO/IEC. You may find a copy of the ISO/IEC 9075-3:1995 Standard here. ODBC specifies not only a traditional API (such as the names of functions, their types of parameters, etc) but also an SQL grammar.
ODBC seems to have a reputation for introducing inefficiencies, probably due to the earliest implementation of some ODBC drivers for database systems already having a call-level interface. However, most of the real (as opposed to imagined) inefficiencies have been removed from modern ODBC drivers. In the present case of Relativity, one must consider the inefficiency of moving data from one database (the group of COBOL indexed files) to another as well as the inefficiencies borne by the end-user due to the loss of real-time access to live data.
Perhaps it seems incongruous to some that a set of COBOL indexed files can be represented as a relational database. Consider, however, that most relational database systems are (or have been at some time in their lifetimes) built upon indexed file systems. Examples would include Informix/C-ISAM, Pervasive SQL/Btrieve, MySQL, etc. The difference is the fact such relational database systems apply a large number of constraints to the representation of data in the physical schema that are not present in COBOL-managed indexed files. The innovation of Relativity, described in US Patent 5,826,076, consists largely of accommodating that lack of constraints.
Tom Morrison
- Status
Similar threads
- Locked
- Question