Xref: utzoo comp.lang.c:10742 comp.unix.questions:7617
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!bloom-beacon!tut.cis.ohio-state.edu!cs.utexas.edu!ubiquity
From: ubiquity@cs.utexas.edu (Richard Hoffman)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: C/IBM
Summary: COBOL -> C ("Oh Happy Day...")
Message-ID: <2872@cs.utexas.edu>
Date: 16 Jun 88 04:52:09 GMT
References: <10565@agate.BERKELEY.EDU> <768@altger.UUCP>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 26

In article <768@altger.UUCP>, doit@altger.UUCP (Christian Rohrmueller) writes:
> In article <10565@agate.BERKELEY.EDU> arnold2@violet.berkeley.edu (mchawi) writes:
> >now that there are c compilers on big ibms, is there a rush of COBOL->C?...
> 
> Yes. It's from RAPITECH SYSTEMS INC. in Suffern , NY 10901
> Montebello Corporate Park.
  
I think he meant "are a lot of shops trying to convert from COBOL to C?"
rather than "are there COBOL->C conversion tools?".  If so, from what I
have seen in the Oil Industry, the answer is Zip.  The big conversion
contraversy is whether to go from COBOL to PL/I.  Not only are there a lot
of COBOL programs out there, there are a lot of COBOL programmers out
there, who have little interest in learning C and whose managers have
little interest in paying them to do it.

Another problem is that most COBOL programs depend on data types such
as zoned and packed decimal, which are not typically available in C.

As far as automatic conversion goes, I would think that, with the addition
of some packed decimal typedefs and conversion routines, COBOL->C could
be completely automated.  The results would make pretty awful reading,
though.
-- 
Richard Hoffman / 5751 Valkeith / Houston, TX 77096 / (713) 729-5716
  +- / 12166 Metric Blvd., #122 / Austin,  TX 78757 / (512) 823-1822

"Malt does more than Milton can / To justify God's ways to Man." -- ??