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