Re: Thoughts on MF COBOL, Unix, and RDBMS

On Sat, 3 May 2008 19:31:47 +1200, "Pete Dashwood"
<dashwood@[EMAIL PROTECTED]
>
wrote:

>
>
>"Robert" <no@[EMAIL PROTECTED]
> wrote in message 
>news:dstn14pta7o7oou3h872mfmkkeasb5pq8f@[EMAIL PROTECTED]
>> 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.
>
>I think it is an old compiler, Robert. It might even be the same one that

>was rebadged and sold as "MicroSoft COBOL"... I have been assured that it

>doesn't support SQL, but there may be a lack of understanding. Can
OpenESQL 
>work with old MF stuff? Would we need to buy Open ESQL or is it free?

OpenESQL is not free. It is sold packaged with Cobol compilers, not as a
separate product.

Precompilers translate EXEC SQL statements into CALLS and MOVES that can
be compiled by
any Cobol compiler. The problem comes at execution time. Old MF compilers
produce GNTs
that run under a COBRUN. They cannot call ELF-format libraries. The
library code has to be
linked into a custom COBRUN. Building one is a pain. 

>>>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.

On second thought, since volume is low, I'd have the Cobol program write
SQL INSERT
statements: 
INSERT INTO table VALUES ("string", 123, 456, ...);

You could pipe the file into a tool like isql or sqsh. 

>Yes, we are not using Oracle in this case. The target is SQL Server (user

>request; I have no preference personally...).

>>>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.
>
>Yes, but for all I know there may be packages, tools and utilities in the

>Unix environment, that I'm simply not aware of and that could suggest a 
>completely different approach... Just trying to cover the bases.

SQL Server doesn't run on Unix. Why are we talking about Unix? I'd do the
file conversion
on Windows, using MF or Fujitsu Cobol. There are many Windows tools to
load a database.
MSQUERY is one that everyone has because it comes free with Excel. 

>Is there a Unix environment utility that will read ISAM and write SQL 
>Server? That would certainly be another option. The code I have will do
so 
>in a Windows environment using Fujitsu ISAM. I need it for a Unix 
>environment using C-ISAM.

C-ISAM is super easy. The data is in a flat file with fixed length
records. I'd FTP it to
Windows and do the conversion there. Better yet, read the file through a
SAMBA connection.