Re: Thoughts on MF COBOL, Unix, and RDBMS

On May 3, 3:41=A0pm, "Pete Dashwood"
<dashw...@[EMAIL PROTECTED]
> wrote:
> "Richard" <rip...@[EMAIL PROTECTED]
> wrote in message
>
>
news:0321abee-3182-42f4-9b2f-8c36f718539d@[EMAIL PROTECTED]
> On May 3, 12:51 pm, "Pete Dashwood"
>
> <dashw...@[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
a=
nd
> > 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
th=
e
> > ISAM is C-ISAM. :-)
>
> Is that a really old compiler ?
>
> [Pete]
>
> Yes, I think so. I know NET Express supports SQL very well. I think this
i=
s
> one of the predecessors. Of course, if they're not using RDBMS they have
n=
o
> need of SQL... :-)
>
>
>
> > 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.
>
> > 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
d=
o
> > that because the MF COBOL on the platform doesn't support embedded SQL
i=
n
> > COBOL.
>
> > 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.
>
> > Maybe it should generate a .CSV or maybe an XML file (either of which
ca=
n
> > be
> > easily imported into most RDBs)
>
> > Or maybe this is not a good approach at all...
>
> > Given my unfamilairity with Unix environments I may have missed
somethin=
g
> > that is normal in that environment.
>
> There is UnixODBC that will work with PostgreSQL and MySQL and others.
> You can run your program on a Windows machine and put the data into
> the Unix Database (given ODBC for that).
>
> [Pete]
>
> Yes, I thought about that, but the program would need to read the C-ISAM
> files

C-ISAM files are easy. They are fixed length sequential with CRLF (or
just one of these) terminator. If the terminator is not CRLF (eg
x00LF) then it is a deleted record.

The index file is a separate file and can be ignored.


> and it is a Fujitsu program. There might be an ODBC driver for that as
> well... I know EasySoft have one, but it costs about 2000 UK pounds and
> that's a bit more than I want to pay if I don't have to...:-)
>
> I'd like to think there is some way using the external file handler in
> Fujitsu but I can't find much about this at the moment.
> [/Pete]
>
> A CSV file is a good option, it would also allow a manual tidy up of
> the data before =A0it is read into the DB.
>
> [Pete]
>
> Yes, that is a good option, but each field will need conversion to a
strin=
g
> before it can be put in the CSV file (or XML file, come to think of it).
> Dates are especially problematic...
>
> [/Pete]
>
> Or write the INSERT commands. Actually with templated output from the
> program it need not know nor care whether it is outputting CSV or
> INSERTs or XML, it will just read a text template and populate the
> tags with data.
>
> [Pete]
>
> I'll certainly use a templated approach, but whichever way I look there
is=

> still the spectre of field conversion to strings, and I'll probably have
t=
o
> push the known dates through a separate component for validation and
> conversion. =A0Actually, I believe I may have a component somewhere
which =
I
> wrote years ago that could help... forgotten all about that... :-)
>
> Thanks very much for the response Richard. It has helped to clarify my
> thinking and, as usual, your advice is pretty much on the money...:-)
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."