arnold2@violet.berkeley.edu (mchawi) (06/05/88)
now that there are c compilers on big ibms, is there a rush of COBOL->C?...
doit@altger.UUCP (Christian Rohrmueller) (06/14/88)
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've never worked with it. Just got some information materials. Hope that helps, Christian
ubiquity@cs.utexas.edu (Richard Hoffman) (06/16/88)
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." -- ??
Chuck_M_Grandgent@cup.portal.com (06/17/88)
Having been a manager presiding over a group of software development folk used to COBOL for years, who were somewhat suddently thrown onto a UNIX-based development platform, I'd like to throw my two cents in. My first exposure to COBOL was 12 years ago in college. I hated COBOL so much I flunked it the first time. However over many years I grew to appreciate its strengths in several areas: 1) excellent file handling capabilities, unmatched by any other language I've encountered 2) excellent self-documenting characteristics due to its English-like verbosity. On a System-V platform, we went for Microfocus COBOL, which I would recommend. What we DID do, was to port a couple MSDOS "C" libraries to UNIX and then call them from the COBOL. This was seen to be a nice situation. The libraries did handy data and date/time conversion stuff, and would've been a pain in COBOL. The consensus grew to be that a nice combination of "C" and COBOL got along real well together.