Ms Cobol Compiler Free Download

[Heidi Hall]

Inmy university, we're being taught COBOL, and I'm trying to get a head start and learn COBOL, C++, and Java before I get into the classes next year.

Problem is; COBOL is so old, it's hard to grab support for it in mac (my laptop is a mac). I understand it runs fine on Mac, but finding someone who can explain how to set up the compiler is another story.

COBOL-IT is an efficient, open-source based COBOL compiler and runtime system, available for Windows and Linux. With modern development tools based around Eclipse and Enterprise support delivered by the industry experts in COBOL, COBOL-IT is the only credible open source COBOL provider for Enterprise applications.

The IBM COBOL compilers support IBM z/OS, IBM AIX and Linux operating systems. You get the tools to amplify your program development and use your existing applications. You can strategically position your application development process for today's rapidly changing marketplace.

I've renamed the thread so that interested folks might see it.I think there are a bunch of somewhat conflated here and it's probably

worth unpicking them a bit. They seem to be: - Is anyone interested in writing a COBOL front end for LLVM?

- Would a COBOL front end be considered for integration with the LLVM

repository?

- Would projects to work on an LLVM COBOL front end be considered for

the GSoC or similar?I can take a stab at answering these: - There are almost certainly some people interested in COBOL. Most

folks on this list probably don't care about Fortran, but that hasn't

prevented flang from being written and integrated into the repository.

Some of the IBM people might be interested. I think the main question

is what the differentiation is from gnucobol. From a quick skim,

gnucobol translates COBOL to C, so you can presumably already use it

with clang and get an LLVM back end. Writing a new front-end is a

nontrivial task and so you'd have to explain what the benefit is of a

new one. Most of the codegen-related benefits don't apply (presumably

you can already use clang + gnucobol to compile COBOL to IR and do LTO

with it and C/C++/Fortran/Whatever code). Would you want to reuse

Clang's diagnostic infrastructure and provide better error messages? Is

it just a question of the license? - There's a difference of opinion in the community about the

importance of being in-tree. I'd personally prefer that clang and flang

were both moved out of the monorepo to force us to think more about

library interfaces. The more LLVM developers are also working on

out-of-tree projects, the better our libraries become. That said, if

you want a project to be considered for eventual inclusion in the tree,

then making sure that the license is the same as the rest of the project

and that the coding style is the same is a good first step. You can

then defer this decision until the front end is more mature and you see

some clear benefit in being upstream. - For a project to be considered for the GSoC, the only real

requirement is finding someone willing to mentor it. That means that

you need to find someone who is an existing LLVM contributor who is

interested in COBOL and you need to provide a good answer to the 'why

isn't gnucobol good enough?' question.David

>

> As for who's interested in a COBOL front-end:

> The OpenVMS people (vmssoftware.com) are definitely headed in the direction

> of a native LLVM-speaking COBOL frontend, although I'm sure it would remain

> proprietary. That direction would presumably include adding DIBuilder

> features for the COBOL data types, and getting LLVM to emit the proper DWARF

> descriptions. Haven't seen any signs of that happening upstream, though.

>

> --paulr

>

Yes, we have our Digital legacy COBOL frontend hooked to LLVM. That

frontend generates our legacy GEM IR which is then converted to LLVM IR.

It is currently an Itanium-hosted cross-compiler but we're bootstrapping

our compilers to native OpenVMS x86 right now (we have clang "working"

on OpenVMS x86 on Virtual Box today).The frontend (and much of the companion library to process the DEC4/DEC8

datatypes) still has Digital copyrights which are own owned by HPE and

licensed to us. I would be unable to opensource it without their

permission. And you'd get a nice vintage COBOL 85 compiler written in

BLISS. :) :) :)As for the DIBuilder COBOL support, since our cross-compilers are based

on an ancient LLVM 3.4.2 (due to the ancient Itanium C++ we have on our

host systems), we have to refresh all of that with our native

bootstrapping before I could even consider upstreaming any of that. And

we are just starting on our symbolic debugger so I don't know if

anything we've done even works yet. And I haven't even explained level

88 condition names to the debugger engineers yet. :)For those keeping score at home, what we have so far is our legacy

compilers for BASIC, BLISS, C, COBOL, Fortran95, Macro-32 VAX assembly,

and Pascal. All but BASIC are in good shape. BASIC and its RTL do some

un-natural acts. And now we just bootstrapped clang 10 (we had to pick

something to start) by compiling on Linux using a mixture of OpenVMS and

Linux headers and then moving the objects to OpenVMS for linking (using

the OpenVMS linker of course).This e-mail (including any attachments) may contain privileged, confidential, proprietary, private, copyrighted, or other legally protected information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient (even if the e-mail address above is yours), please notify us by return e-mail immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited.

--------

Regards,

Ronald. RE: Why Are Cobol Compilers Sooo Expensive? gregsimpson (Programmer)15 May 02 05:43 _win_dev.html has a free compiler

or

; contains loads of links to cobol compile sites. Many of which are free.

RE: Why Are Cobol Compilers Sooo Expensive? k5tm (Programmer)15 May 02 10:52Taking a hint from Microsoft...

Visual Studio .NET (what Visual Basic has become)

Enterprise Architect

Full Packaged Product $2,499 US

Version Upgrade $1,799 US

Enterprise Developer

Full Packaged Product $1,799 US

Version Upgrade $1,079 US

(And note that this pricing is in the face of Microsoft's clear incentive to provide tools that support the company's mainline os and office suite products.)

...or Borland Delphi (what Turbo Pascal has become)

Delphi 6 Enterprise $2,999 US

Version Upgrade $1,899 US

What usually fuels this question/argument (enough times to warrant a FAQ? ) is the desire of an individual or small enterprise to acquire minimalist development tools. Most COBOL compiler vendors have tried at one time or another to respond to this aspect of the demand for COBOL development tools without compromising the support level demanded by the larger customers that have a "bet the business" investment/relationship with their chosen COBOL vendor. Tom Morrison RE: Why Are Cobol Compilers Sooo Expensive? StephenJSpiro (Programmer)17 May 02 00:04The COBOL Compilers are so expensive because COBOL, far and away, is the most feature-rich programming language in the entire industry. And with the new standard, it moves from being the most feature-rich, versatile business programming language, to being the most feature-rich, versatile all-around programming language in the world.

Stephen J Spiro

ANSI COBOL Standards Committee RE: Why Are Cobol Compilers Sooo Expensive? RonaldB (Programmer)17 May 02 09:14... and one of the very few (or even the only one?!!) with an internationally accepted industry standard behind it. --------

Regards,

Ronald. RE: Why Are Cobol Compilers Sooo Expensive? Guest (visitor)17 May 02 17:23Interesting timing. Our company (theKompany.com) just released today what we call KOBOL for $39.95 download and $49.95 CD. For that one price you get the application on both Linux and Windows, an IDE with a syntax highlighting text editor, and a native compiler. No run time costs and free updates. You can read all about it and get a free demo from www.thekompany.com/products/kobol. RE: Why Are Cobol Compilers Sooo Expensive? AustinOne (Programmer)19 May 02 23:30Seems to me that there are one or two "almost free" Cobol compilers on CD's bundled with some of those teach-yourself COBOL books..., Learn Cobol in 24 Seconds/Minutes/Hours/ Days, Cobol Unleashed, etc. My mind goes numb after visiting the local Borders book store. Of course, $59.95 ain't free.

To combat the marketplace and all of its mixed signals, I believe the mainline COBOL companies such as AcuCobol, etc., should consider putting out a personal almost-free vanilla COBOL85 compiler for Windows and Linux that is otherwise dumbed down from the enterprise / commercial versions that have all the real bells and whistles.

RE: Why Are Cobol Compilers Sooo Expensive? Gerbelem (Programmer)21 May 02 06:22The beauty about the cobol platform for professional developers is that we are not tied up to a single development platform. With just a new runtime my programs will run on a just about every platform available from unix to IBM mainframes, Linux ( btw there is a pretty good Cobol runtime for Linux from AcuCobol ). Microsoft has stepped up prices almost to the other guys and they already talking of having runtimes in future...I just do not want to be tied up to any of the Microsoft products or to anybody else as a matter of fact ! RE: Why Are Cobol Compilers Sooo Expensive? k5tm (Programmer)21 May 02 10:08"Microsoft (is) already talking of having runtimes in future"

In the future? Microsoft gets a 'runtime fee' on just about every PC sold. Their marketing term for their current 'runtime' is Windows XP, the latest graphical version of their first runtime, MS-DOS.

Tom Morrison RE: Why Are Cobol Compilers Sooo Expensive? Guest (visitor)23 May 02 06:05Fujitsu have allowed people to download Version 3.0 of their PC COBOL compiler... and it has appeared on CDROMs bundled with COBOL books e.g. COBOL for Dummies. RE: Why Are Cobol Compilers Sooo Expensive? Dimandja (Programmer)(OP)27 Jun 02 09:24I just bought Visual Basic.NET for $100. I would be very happy to obtain a COBOL compiler for that price that packs the same "minimalistic" development tools and features. RE: Why Are Cobol Compilers Sooo Expensive? Dimandja (Programmer)(OP)28 Nov 02 12:46It looks like we have a winner here

Assuming that everything promised is delivered (it looks that way so far), KOBOL is definitely the winner in COBOL compiler prices (and performance).

Good:

1. No expensive run-time costs to worry about, just compile your program on the target platform (like C).

2. Integrated IDE for code development and project management (like many other IDEed compilers).

3. Fully Object Oriented (like C++).

4. It is fully ANSI COBOL.

5. And the price! $59.95 (Download Version). Not a 'bargain' $3,000 and up as we have been told by other manufacturers.

Bad:

1. The name KOBOL! Why not tastefully KOmpany COBOL?

Dimandja RE: Why Are Cobol Compilers Sooo Expensive? dallasdino (Programmer)28 Nov 02 20:17I did not see a debugger to step through code in the demo. Am I missing something? RE: Why Are Cobol Compilers Sooo Expensive? GoAS400 (IS/IT--Management)30 Nov 02 03:34I have purchased Fujitsu Cobol for Windows Standard Edition for $750. I love it. I don't do any GUI with it but the project manager is easy to use, and the debugging is actually understandable. Works like a champ.

It's a better investment than any Microsoft software I've every bought :o

John RE: Why Are Cobol Compilers Sooo Expensive? ShadowFox333 (Programmer)4 Dec 02 17:05Here is a case study that Rm did on our conversion

from mainframes to pc environment. We do a lot of printing

And I was able to do duplexing and print inverted on the second half of the duplexed page, all in cobol. (I swear).

I think we only paid about $2000.00 at the time, but what it saved us was much more.

I am the first case study for international Computer on the page.

Enjoy Bob googletag.cmd.push(function() googletag.display('div-gpt-ad-1406030581151-2'); ); Red Flag This PostPlease let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

CancelRed Flag SubmittedThank you for helping keep Tek-Tips Forums free from inappropriate posts.

The Tek-Tips staff will check this out and take appropriate action.

3a8082e126