Re: How proprietary is the "COBOL file system"
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 1 Oct 2007 09:40:41 +1300
"Richard" <riplin@xxxxxxxxxxxx> wrote in message
news:1191182351.443023.186010@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Sep 30, 8:29 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
--
"I used to write COBOL...now I can do anything.""Robert" <n...@xxxxxx>
wrote in message
news:a8huf3ppubdf9pd0gmtuiiv3s5efn19r0b@xxxxxxxxxx
On Sun, 30 Sep 2007 17:18:10 +1300, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Can anyone tell me if MicroFocus COBOL can read Fujitsu ISAM files, and
vice
versa? What about Realia?
Obviously, at the source code level (SELECT and FD/01) the code is
compatible, but what about object level?
Is there a single PC ISAM system, or do all the COBOL vendors have
their
own
proprietary indexed system which is delivered with their COBOL
compiler?
I know what I THINK the answer is, but would be gald to hear any other
facts/opinions about this.
Let's assume you have a Fujitsu program that wants to access Micro
Focus
files.
1. Write a file access program, compile under MF to a .dll, call it
from
Fujitsu.
2. The MF extfh functions are well defined. Call them directly from
Fujitsu.
3. Use ODBC.
The requirement is to access around 100 Fujitsu ISAM files. ODBC is not
an
option. (I don't believe they provide a driver for their ISAM anyway, and
even if they did, it would be too unwieldy to set up every file on ODBC.
I
do use ODBC for access to RDB and find it very useful, especially for
moving
RDBMS)
Fujitsu on Linux provides a Callable File Handler that can be called
from C (or compatible) to access all Fujitsu files. It should be
possible to call this from MF.
Thanks Richard, I didn't know that.
However, MF is not involved in this anywhere and I have no intention of
buying any further products from Fujitsu. They did me a favour by giving me
the kick I needed to move off COBOL, and that is the end of the relationship
as far as I'm concerned.
This is also available in Windows, see 'File Access Subroutine Guide'.
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).
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...
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...)
Thanks for your response.
Pete.
--
"I used to write COBOL...now I can do anything."
.
- References:
- How proprietary is the "COBOL file system"
- From: Pete Dashwood
- Re: How proprietary is the "COBOL file system"
- From: Robert
- Re: How proprietary is the "COBOL file system"
- From: Pete Dashwood
- Re: How proprietary is the "COBOL file system"
- From: Richard
- How proprietary is the "COBOL file system"
- Prev by Date: Re: How proprietary is the "COBOL file system"
- Next by Date: Re: How proprietary is the "COBOL file system"
- Previous by thread: Re: How proprietary is the "COBOL file system"
- Next by thread: Re: How proprietary is the "COBOL file system"
- Index(es):
Relevant Pages
|
