jroberts@attvcr.UUCP (John Roberts) (06/10/87)
A friend would like to migrate from Wang VS Cobol to C on System V,
and would prefer to use a translator first, and tweak the code later.
He's prepared, if necessary, to translate by hand to a target Cobol
first (such as MicroFocus), but Wang VS is apparently ANSI Cobol
(for what that's worth ;^}), so the translator ought to be able to
handle it. The question is: do such translators exist, and where
can he get one?
--
John M. Roberts AT&T Canada Vancouver BC
(604) 689-8911 {ihnp4!alberta,uw-beaver}!ubc-vision!attvcr!jroberts
What! Me Worry? attmail!jmrobertsbrent@rtech.UUCP (06/11/87)
in article <600@attvcr.UUCP>, jroberts@attvcr.UUCP (John Roberts) says: > > > A friend would like to migrate from Wang VS Cobol to C on System V, > and would prefer to use a translator first, and tweak the code later. > He's prepared, if necessary, to translate by hand to a target Cobol > first (such as MicroFocus), but Wang VS is apparently ANSI Cobol > (for what that's worth ;^}), so the translator ought to be able to > handle it. The question is: do such translators exist, and where > can he get one? > > -- > John M. Roberts AT&T Canada Vancouver BC > (604) 689-8911 {ihnp4!alberta,uw-beaver}!ubc-vision!attvcr!jroberts > What! Me Worry? attmail!jmroberts You're going to have SOME FUN with this one. I'm doing tons of C right now and have done tons of stuff with the Wang VS in the past, some of it in COBOL. (though don't tell my computer science friends; they'll think me a closet mainframe dinosaur instead of a sleek C programmer, the horror :-) First, some notes about Cobol to C in general: I'm speaking as a former Cobol and Wang jock who's now doing a lot of C and Unix. I'm not speaking as an expert on doing Cobol to C conversions. In my humble opinion, translating cobol to C might have some enormous problems. Depending on the application, the problems might actually turn out to be insurmountable. The main problem is the use of packed decimal versus floating point. It's not part of standard C to support use of packed decimal numerics. Wang, like most other mainframe-type architecture machines, uses packed decimal for most cobol arithmetic. You can use floating point or integer, but very few cobol programmers actually do use it, and the syntax is a little non-standard. Going to C will be a painful awakening when you start running results in floating point and discover that 2. + 2. does not necessarily equal 4.0. If you're talking about a business application, look out! On the other hand, if you're just going to convert to a MicroFocus Cobol on System V, MF might handle packed decimal on the machine you're thinking of buying -- it'd be worth a check because of all the RISC baby-mega-micro- ultra-mini-supercomputers on the market that don't do packed decimal. Another catch peculiar to Wang is the use of BCD floating point. I don't remember the syntax for using this format in the data division, but they do have an 8-byte floating point (on all but the poor ol' VS 80) that uses BCD half-digits and an exponent to give the best of both worlds -- float computation but accurate to 14 digits, like your pocket calculator. If the Cobol application uses this format, then you're still going to have a problem when you convert to C as I don't know any other machine with that nice floating point format -- you'll still have the 2.0 + 2.0 <> 4.0 problem. Other problems exist, like differences in initialization of structures, use of OCCURS clauses, use of REDEFINES clauses (clumsy using Unions in C) use of 88-level descriptive items, and so forth. These all may be handled by a high-class COBOL to C translator, but I would not be caught dead being the human handed all this mechanically-generated crap to maintain. While I'm thinking about it, there are a number of TABLE HANDLING statements intrinsic to the COBOL language itself that aren't supported in C that would be real fun. Everybody uses these in Cobol, but they could be very tricky to translate to C even by a sophisticated translator. WANG-SPECIFIC problems: Wang *does* implement Ansi Standard (74, I believe) cobol, but only about 5 out of the 10 areas. They don't have SORT/MERGE, REPORT WRITER, or any of the other goodies that MVS cobol does. About what you'd expect from a minicomputer Cobol compiler. However, they have a number of extensions to take advantage of their architecture whic could strongly nail your fanny to the wall. 1. DISPLAY AND READ statements: (For all you voyeurs out there, this is a Wang COBOL extension that allows you to do full-screen I/O to the workstation. The architecture is very similar to an IBM 3270-type block mode terminal's communication protocol, though the host language interface is infinitely simpler than, say CICS command level. It's a good feature for a DP system, but for all the computer-science types and emacs junkies, it's very bad news.) Anyway, you won't find any other COBOL with these kind of statements, or analogs even remotely close. Don't hold out hope that your Micro-focus midway compiler will gain you anything. If you're doing any screen I/O at all, write it off. 2. Indexed file handling statements. The Wang VS has as part of its operating system an indexed file handler similar to IBM's VSAM or DEC's RMS on VMS. Works pretty good, but they implement a number of extensions to the standard read indexed statement for record locking, transaction control, and so forth. If you do what the normal Wang programmer does in order to get nice features like concurrency, you'll be seriously hosed when you convert to another cobol. When you convert to C you'll have to write your own indexed file handler, take whatever the cobol translator outputs, replace all its calls, then test and debug, using the debugging capabilities of Unix, which, sad to say, aren't up to the symbolic debugging capabilities of the Wang, which are quite nice (in the league of VMS debugger). 3. Handling of file information that gets passed in to the program by the external Job Control language. The Wang's Procedure Language, which is somewhat like DCL, can be used to supply runtime file names to programs. This is a takeoff from IBM's mainframe JCL, where you might want to run the same processing programs on separate databases. The Wang has another nice hook in that if any of the filename parameters is wrong or missing, the system will stop, save your current screen image, display a screen requesting clarification of the file it needs to find, then redraw your applications screen when you supply the requested infomrmation. Because that's built into the system at the supervisor call level (c.f. Wang Operating System Services manual, services GETPARM and PUTPARM) you aren't bloody likely to find an equivalent in C; translating some of their environment division stuff to Microfocus Cobol would be hard enough. Overall assessment: Your friend has a deathwish, too much money invested in his software, or something. I don't know of a machine translator for Wang COBOL to anything or of one from vanilla COBOL to C. Because of factors mentioned above, I think that even if there were such programs, the output would not be anywhere near immediately usable. Perhaps they can have your friend's porting job added to the list of the Labors of Hercules. Any questions, feel free to send mail. -- -brent williams Relational Technology, Inc. 1080 Marina Village Parkway Alameda, CA 94501 {amdahl,sun,mtxinu,cpsc6a,hoptoad}!rtech!brent
chris@mimsy.UUCP (06/15/87)
In article <902@rtech.UUCP> brent@rtech.UUCP (Brent Williams) writes: >The main problem [with COBOL-to-C in general] is the use of packed >decimal versus floating point. It's not part of standard C to support >use of packed decimal numerics. So write a run-time library. >Other problems exist, .... Sounds like an understatement. :-) >[Many other hard things] As long as the languages are Turing-equivalent, you can simulate anything in anything else. Having done some translation myself, though, I would say that the best results are accomplished by rewriting the original program largely from scratch, borrowing only key algorithms and/or data structures. Such `translations' are expensive, of course. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
ken@rochester.arpa (Ken Yap) (06/15/87)
Having done some Cobol-Cobol translations in the past (naturally I did most of the work with a translator), I can tell you it can be worse. You may have to do data translation if you intend to continue with existing data. Cobol has a version of discriminated unions. If the alignments are different on the target machine, well what you have to do is write a program to read the records and repack the data. Which is what I did. Table driven of course, because there were several such files. I'd say rewrite the thing from scratch, if you can afford it. Ken