Re: MultiUser File Access using MS COBOL Version 2.20 on Windows Server


"Rob" <rthomson@xxxxxxxxxx> wrote in message
news:1158961230.630617.108050@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Our company wants to upgrade from a Novel Client network to a pure
windows server. Unfortunately multi user indexed file access stops
working on our legacy software: (DOS COBOL.EXE - Microsoft COBOL
Compiler Version 2.20 (C)Copyright Microsoft Corp. 1982-87), which runs
under ISAM: (NISAM.EXE - MS-ISAM (C) Copyright 1984, 1987 by Microsoft
Corp Version 3.12)

Is there a newer NISAM.EXE out there that might work? We dont want to
upgrade the complier itself too far or we will have to convert all our
existing code (which will be rewritten again in c# sometime after we
are on the windows server).

Does anyone know of patches, have access to more recent NISAM''s, or
know server settings that might allow multi user cobol under windows
server to work?

No. Sorry.

Here are your options as I see them:

1. Upgrade your COBOL system, recompile the source, and copy the existing
data to the new COBOL file system. This is nowhere near as daunting as you
seem to think; COBOL hasn't changed much for 20 years and newer
implementations are backwards compatible. Both Fujitsu and MicroFocus
implementations support multi-user and multi-threading. Your MicroSoft COBOL
is an early rebadged MicroFocus implementation.

2. It MIGHT be possible to use the EXTFH (External file handler) interface
in your existing COBOL, or to find an ODBC driver that would allow you to
deploy a newer ISAM system (C-ISAM, maybe?). You would still need to modify
the source code extensively and recompile it, and, when you have finished,
you are still locked in to the ISAM system.

3. If you really have your heart set on converting to C# (and I can
understand why you would...) then you will probably spend a considerable
amount of time (and money) converting the code.

Why not convert the file access to Relational Database at the same time?

The data structure conversion can be fully automated, and the access calls
can be converted semi-automatically, during the conversion to C#.

Given that you have the COBOL source code, I can let you have tools to
convert the file system to RDB. I have tools I wrote to help me do this
years ago.

ISAM2RDB analyses your COBOL file definitions (source COBOL) and creates
equivalent structures in RDB, in 3rd normal form. Automating this task
removes much of the source of errors in doing it. The end result is not a
perfect RDB system, but it is at least as good as what you have currently,
and it is pretty easy to optimise once you have everything converted. All
relationships, indexes, repeating groups (COBOL 'OCCURS') and COBOL record
layouts are automatically converted to RDB tables with the appropriate
database types, based on the COBOL PICTUREs.

If you want to outsource this task, I'll quote you for doing it for you.
(Depends on how many files you have and how complex they are...) If it is
less than 20 files you should simply use ISAM2RDB and do it yourself. The
last time this tool was deployed it took a couple of days to convert 60 ISAM
files to a single integrated Relational database. This was done by people (2
COBOL programmers) who had never used the tool, had minimal SQL and RDB
knowledge, and included loading and testing the converted DB.

Given that you have converted your ISAM files to RDB (I also have tools that
will read your existing structures and load them to the converted RDB), the
focus can then move to the code conversion. It is fairly simple to catch
each access to the ISAM system and convert it to SQL. This can be
'semi-automated' although I don't have anything that can do it 100%.

It seems to me that if you are going to 'modernise' your code, there is
little point in keeping it tied to an antiquated, locked in, file system,
that requires a COBOL program to be written every time you want data from
it.

Mail me privately if you are interested.

Pete.


.

Relevant Pages

  • Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?
    ... > restructure, it will definitely be cheaper to use a good tool. ... > Enterprise COBOL for z/OS. ... > dead code that it could not generate to the output program. ... > work through the panels to set my options and start a conversion ...
    (comp.lang.cobol)
  • Re: [OT] System Conversion - An Overview
    ... conversion... ... with the present process (what the COBOL system does) as well as those who ... SAP and 20% ABAP, but the vanilla SAP could not do even 60%. ...
    (comp.lang.cobol)
  • Re: ODBC
    ... >> I have a copy of the folder that contains the COBOL source and data. ... the data file is probably ISAM. ... > Our costs were a conversion program - we gained access to the ... I overlooked your statement that you had the original source. ...
    (comp.lang.cobol)
  • Re: "Every Shop Has Some Assembler Somewhere" - course update
    ... Having been involved in porting some programs from IBM COBOL to now totally ... A truely automated conversion, much less a "no source code ... For one thing, both vendors have vendor ...
    (comp.lang.cobol)
  • Opinions on approach, please...
    ... I'm currently looking at automated code conversion for migrating COBOL ... applications that use Indexed files to RDB. ...
    (comp.lang.cobol)