Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

I see that there are several COBOL 3

Status
Not open for further replies.

Dimandja

Programmer
Apr 29, 2002
2,720
US
I see that there are several COBOL compilers out there. I am curious as to what they have in common and what they do best as contrasted with other COBOL compilers. I thought this forum would be perfect for such inquiries.

Some of the areas of interest would be:

1. Supported platforms.
Does this compiler run on more than 1 platform? Which ones?

2. Cross-platform ability.
For example: can you use this compiler to code on a PC and a mainframe with minimal changes?

3. Friendliness.
For example; is it capable of using native resources of the platform? APIs, etc...

4. Outworldliness.
Can it be used in a multi tier environment? Can it call and be called by - or easily exchange data with - other processes? Does it support any Internet or Object Oriented functions?

5. Individuality.
What makes this compiler stand out from the crowd?

6. Cost.
Software and resources.

Dimandja
 
Bill Klein's FAQ has a list of available COBOL compilers, and would be a good place to start gathering information (e.g. from vendors' web sites, etc).

faq209-1605

Tom Morrison
 
Several vendors make versions of their compilers for different platforms however, when you order the compiler you must specify the platform.

I have many times moved code from the mainframe Cobol compiler to the PC compiler (intel) with only very minor changes (usually in things like the Select Clauses). There are however, extended features of Cobol compilers which may not migrate well to another platform. If your code stays within the ANSI standards for Cobol the code should migrate from one Cobol compiler to another (and therefore from one platform to another) with very little effort. One final note on this subject, the executable can not move from one platform to another. You must re-compile the code on the new platform creating a new executable.

Most Cobol compilers have the ability to call an Operating systems APIs or routines as well as modules written in another language. You would have to look at specific compilers for a more detailed answer.

Some of the Cobol compilers do support OOB Coding (Fujitsu is one) and some support multi tier and internet processing. Fujitsu supports the .NET environment, Activex, etc. (I only can speek for Fujitsu because that is the compiler I am most familiar).

Can not answer what make one compiler stand out over another however, there are many opinions on this forum, all you have to do is look for them.

As far as cost, most of the compilers that can do all the features you speek of carry a heafty price tag for an individual. There are a few freebes out there however, they are generally feature poor.

etom



 
etom -

AcuCOBOL may be the exception to your statement that you must recompile to move between platforms. AcuCOBOL is interpreted and is platform independent. The last place I used it, we compiled and tested on PCs, moved the "executable" to an RS-6000 and ran without recompiling under AIX.

Regards.

Glenn
 
Glenn,

AcuCOBOL is not the exception. RM/COBOL has been doing object and data portability since the 1970s. RM/COBOL, introduced in 1985 (at approximately the same time as the 1985 ANSI COBOL standard) actually predates the founding of AcuCOBOL/Acucorp by almost three years. (Note, as previously described in Tek-Tips thread209-721281, there was a 1974 standard version of RM/COBOL, which was also largely object and data portable.)

It is fun to hear our customers tell stories of their experiences in various (typically Unix) hardware vendors' porting labs. Our customer can arrive with a cpio or tarball tape, copy the tape to the test machine, tweak a shell script and have an application running in minutes. It creates quite a bit of cognitive dissonance for the vendors' employees, who have been trained to help people overcome porting problems. [smile]

Tom Morrison
 
Thanks for the information on platform independance. It just proves you can teach an old dog new tricks (or new information). One can never learn it all no mater how long you work in this industry. This is why I really like this forum.

etom
 
When you mention RM & ACU I feel the need to add Micro Focus to that list. Especially when portability is an issue.
A workbench on windows to develop and running your code on unix/linux is very easy.

When you develop programs with a GUI interface and you want to execute the programs on unix/linux using windows workstation then ACU cobol is the best choise. I hear rumors that soon the GUI client will be java-based. So linux on the desktop will be one step closer.

All those portabily-issues are implemented calling dedicated API's. Bye bye COBOL-ANSI standard ... Potability means from one O.S. to another O.S. using the same compiler-brand.

When you code standard ANSI-85 cobol, then you will be rewarded with a free compilers:
 
Frankly, the user interface for COBOL programs has never been a very strong part of the standard. Therefore, it is always the user interface that causes the vast majority of portability problems.

Tom Morrison
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top