Re: How proprietary is the "COBOL file system"

On Sun, 30 Sep 2007 21:29:31 +1300, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:


The requirement is to access around 100 Fujitsu ISAM files. ...

Currently, I generate a COBOL program to read the ISAM and write the
Database. This is a reasonable solution but has led to the (now solved)
problem of having to remotely Batch compile COBOL (covered in another
thread).

If that's all you want to do, you don't need remote compilation.

1. Have your program do the copybook interpretation at execution time, build the SQL
dynamically. One compilation would handle all 100 ISAM files. I posted such a program
here. It converted any ISAM (with copybook) to comma delimited (CSV), which could then be
loaded into a spread*** or database.

2. Fujitsu shipped a tool that converts ISAM to flat file. Run that tool remotely and
transmit (FTP) the flat file. The data portion of a C-ISAM file with no deleted records is
already a flat file.

3. Transmit (FTP) the ISAM file/index and do the conversion locally.

4. Mount the remote directory on your file system and do the conversion locally. If both
machines are running Windows, they already have the software to do that: SMB. The user
knows it as Network Neighborhood and Sharing. If your end is Unix, Samba gives the same
functionality.

5. Use an ODBC driver from http://www.transoft.com/products/ts_sqlgate.htm or
http://ww2.pervasive.com/Integration/Solutions/Pages/PervasiveConnectors.aspx. Since
you're already writing a schema for the database, it would be easy to write a second
version for the driver.

It was precisely because I have no easy way to access the ISAM from anything
OTHER THAN COBOL that I had to go for a COBOL generation, and that in turn,
made me think about the "illusion" of cross platform standardization that
COBOL is supposed to provide...

Many conversion tools have been developed. There are even tools that go the other way, by
making a database look like an ISAM file so you can 'leverage your investment'. Most Cobol
programmers do that manually, converting files to tables one-for-one.

This "closed" COBOL file system has been one of the major contributors to
the decline of COBOL. I remember certain programmers feeling very smug in
the mid-80s because the corporate data resource was (apparently) locked into
COBOL and this therefore guaranteed COBOL's future. (I wonder where they are
now...)

Some are still defending that turf. They regard outsiders with better ideas as the enemy.
.

Loading