Re: Thoughts on MF COBOL, Unix, and RDBMS

On Sat, 3 May 2008 12:51:38 +1200, "Pete Dashwood"
<dashwood@[EMAIL PROTECTED]
>
wrote:

>I have some programs written in Fujitsu COBOL (generated by a tool) that
run 
>in a Windows environment, read ISAM and write a RDB using embedded SQL
and 
>ODBC.
>
>I would like to have these programs run in a Unix environment. There is a

>COBOL compiler (MicroFocus) available but it doesn't support SQL, and the

>ISAM is C-ISAM. :-)

It does support SQL, either through the MF-supported OpenESQL precompiler
or the Oracle
buggy and no longer supported PRO*COBOL. You can talk through ODBC or OCI
(Oracle Call
Interface). 

Embedded SQL on Unix is what I do every day.

>The fundamental problem is one we see here quite often; The ISAM files
were 
>created by COBOL, are "COBOL oriented" (may contain packed and binary 
>fields) and this means that accessing them with a language other than
COBOL, 
>while not impossible, is fraught with danger and problems. So, it makes 
>sense to read them with COBOL. (Especially as there is a COBOL compiler
for 
>the platform available.) COBOL definitions of the files are available.

No compiler held a gun to their head and forced them to put packed or
binary data in a
file. When we still used files, twenty years ago, my numbers were always
in display
format.

>Having got the data, the COBOL program would normally move the fields to 
>equivalent host variables and write them to the database, but it can't do

>that because the MF COBOL on the platform doesn't support embedded SQL in

>COBOL.

Yes it does. 

>So maybe the generated code should simply write the data out as strings
that 
>can be INSERTED with a script, as another step in the process.

A kludge. When you get serious, the more important question is HOW the
rows will be
loaded.  You can do it with single row inserts, which is slow, or multiple
rows with a
single SQL command. Oracle has a PL/SQL command that inserts an array of
rows. I won't
mention it because you are probably not using Oracle. You also need to
turn off logging
and rollback.

>Maybe it should generate a .CSV or maybe an XML file (either of which can
be 
>easily imported into most RDBs)

XML is the sexy way, if you don't care about speed. 

>Or maybe this is not a good approach at all...
>
>Given my unfamilairity with Unix environments I may have missed something

>that is normal in that environment.

It's not about Unix, it's about databases. 

>I'd be interested to hear suggestions, ruminations, musings, thoughts, 
>preferably helpful and constructive (but, this being Usenet, I'm not
holding 
>my breath...) on how some of you might approach this.

It depends on volume. If you're copying thousands of rows, use a utility.
If you're
copying hundreds of millions of rows, write high-performance programs to
do it and run
hundreds of them in parallel. That's how we merged Nextel into Sprint and
Bell South into
AT&T.