Re: How proprietary is the "COBOL file system"



"Robert" <no@xxxxxx> wrote in message
news:c9mvf3hoqs5j2fcdeqf3iq5dic1mq4tq1i@xxxxxxxxxx
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.

I am sure there are many ways to achieve what I want. But that is not "all I
want to do" (This is only one aspect of a toolset that dleivers many things)

If COBOL is not running on the machine where I want to run the output, then
it makes sense to access it remotely.

Besides, there may be many reasons I would want to compile COBOL from any
machine on the network, without buying additional COBOL licences.

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.

Yes, I already have software to do that, it's trivial. That is not the
problem. I need to analyse the COPYBOOK and generate DDL (NOT SQL) for any
one of several target RDBMS systems. This creates tables on the database and
these are normalized to 3NF, repeating groups removed, key dependencies
checked and combined. It is a lot more than simply transferring data from
ISAM to a replicated structure.


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.

And how would I get the needed DB structure from doing that?

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

No idea what you are talking about here. The conversion IS done locally
using a single integrated toolset. That toolset obtains data and compiles
COBOL whenever it needs to, and does it locally or remotely, transparently
to the user.


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.

I think you have completely misunderstood what is going on here. You keep
saying "do the conversion locally". It isn't about "conversion". It is about
creating a database and loading it. It may be done one or more files at a
time. The existing COBOL access code also has to be converted and they may
want to do that on a subsystem basis. They need ot be able to dynamically
modify their copybooks and instantly regenerate and load the affected
tables. There is much more to it than I have described here.

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.

I appreciate the imaginative solutions siggested, Robert, but you do not
have a complete problem definition here.

Pete.
--
"I used to write COBOL...now I can do anything."


.

Quantcast