Recommended MSWindows COBOL compiler.

I work in TinyuCOBOL and OpenCOBOL on a Linux system. Together with Gvim
they make for a workable programming environment. But I worry about the
poor souls who are lost in the labyrinth of MSWindows. Gvim is available
but an Open Source COBOL compiler requires some heroic effort to install.

So now we look at commercial products, I have in my day used Ryan MacFarland
COBOL. But I am open to suggestions for a commercial compiler that is
1. Easy to install and configure.
2. Uses standard COBOL (i.e.COBOL 85 or COBOL 74.)
3. Cheap.

When making recommendations please quote street prices if you know them.
--
John Culleton
Able Indexers and Typesetters

Hi,

Here are some good COBOL compilers for the Windows platForm:

1). NetExpress 4.0  (MicroFocus Corporation)

2). PowerCOBOL  (Fujitsu Corporation)

3). NetCOBOL  (Fujitsu Corporation)

4). AcuCOBOL  (AcuCobol Corporation)

5). VisualAge COBOL  (IBM Corporation)

www.microfocus.com

http://www.adtools.com/products/windows/pcobol.htm

http://www.acucorp.com/

http://www-306.ibm.com/software/awdtools/cobol/va/

Kellie.

John Culleton wrote:
> 1. Easy to install and configure.
> 2. Uses standard COBOL (i.e.COBOL 85 or COBOL 74.)
> 3. Cheap.

Kobol from TheKompany (www.thekompany.com/products/kobol) fullfills 3
at $US60 or so.  It requires to be purchased for each machine.

Fujitsu version 3 is free but is a student edition that had no
distribution rights. You are not allowed to distributed programs
created with it.

You can also get cheap student editions from other vendors which may
limit the size of the programs and will restrict distribution.

Most commercial systems are not cheap and also require run-time
licences for each user that you sell programs to.  Typically $2000 for
a developer system and $100 to $200 for each end user of the
applications.  Fujitsu has free run-time distribution licence for some
of its products.

One major issue with the cheapies is that they are not (when I last
looked) multi-user. They have no file sharing and record locking.
While it would be possible to contrive a multi-user mechanism it may
not give adequate performance.  'The next version' of Kobol is promised
to give embedded SQL which should solve the lack of multi-user
facility.

John,
Can you give us a better idea of how you will be using the compiler?  As the
re
are LOTS of Windows (and Linux and Unix) COBOL compilers, there are some tha
t
are better for some things and some that are better for others.  Specific
questions:

1) Are you trying to create executables that will be SOLD to customers?

2) Are you producing executables that will be executed on many PCs within a
single company?  How about off a Server?

3) Do you have existing code from some other platform that you want to "port
"
(and change) on the PC?  (For example IBM mainframe code, or existing Unix C
OBOL
code)?

4) Do you expect to create "multi-language" applications?  (Mixed VB and COB
OL?
Mixed COBOL and C? Mixed COBOL and Java?)

5) Are you expecting to create ONLY interactive applications or some "batch"
 as
well?  What type of User-Interface are you expecting to create (Character? G
UI?
Other?) ?  Do you expect this to be done in COBOL?

Bottom-Line:
I don't know of any commercial COBOL product that I would recommend for ALL
users, but I can give some specific advice depending upon how you plan on us
ing
it.

--
Bill Klein
wmklein <at> ix.netcom.com
"John Culleton" <john@wexfordpress.com> wrote in message
news:p_Wdncfg1Pr1s7HeRVn-gg@adelphia.com...
>I work in TinyuCOBOL and OpenCOBOL on a Linux system. Together with Gvim
> they make for a workable programming environment. But I worry about the
> poor souls who are lost in the labyrinth of MSWindows. Gvim is available
> but an Open Source COBOL compiler requires some heroic effort to install.
>
> So now we look at commercial products, I have in my day used Ryan MacFarla
nd
> COBOL. But I am open to suggestions for a commercial compiler that is
> 1. Easy to install and configure.
> 2. Uses standard COBOL (i.e.COBOL 85 or COBOL 74.)
> 3. Cheap.
>
> When making recommendations please quote street prices if you know them.
> --
> John Culleton
> Able Indexers and Typesetters

In article <11iole358e2njfb@news.supernews.com>,
HeyBub <heybubNOSPAM@gmail.com> wrote:

[snip]

>Heh! Reminds me of the old saw: "Our services are cheap, fast, and reliable
.
>Pick two."

The version I am familiar with is 'The project can be on time, on spec or
on budget.  Pick two.'

DD

John Culleton wrote:

> William M. Klein wrote:
>

>
> I am looking into Kobol for MSWin. They reveal prices (yay) and are not
> out of sight pricewise.
>
On further investigation they rely on Cygwin, which takes them out of the
"novice download and use" category. I will check out Ryan-MacFarland/Liant
next.
--
John Culleton
Able Indexers and Typesetters

> Why vendors think they can hold a prospect's attention without answering the basic
> price question is beyond me.

"""If you need to ask the price then you can't afford it."""

In most situations the price of the compiler and runtimes and the
ongoing 20% 'support and update' annual fees are just a small part of a
project's budget. If it is in-house application then the facilities of
the package will speed development and outweigh these costs. If it a
saleable package then the developer and run-time costs are a small
percentage of the total sale.

If you want to distribute source code and there to be a free/cheap/easy
compiler for others to use then Cobol may not be your best choice.

Just a personal opinion, although I was one of the STRONG advocates of addin
g
the Screen Section (and extended Accept/Display) statements into the '02 ISO
COBOL Standard (based on - but not quite identical to what was in the X/Open
Standard) - and I was "disappointed" when it was put into the "processor
dependent" (aka "optional") list, I would PERSONALLY, say that recommending
"character based" (Screen Section and Extended Accept/Display) for today's s
mall
businesses running on Windows is a NON-starter.

What I would suggest is that your (in your book) recommend ANY of the
(relatively) inexpensive '85 Standard compilers and an "add-on" for
User-Interface  (probably sp2 or ScreenIO - as the currently most popular th
at I
am familiar with).

Then I would code my samples to compile with "ANSI" flagging turned on, and
stick to ANSI ('85 Standard - probably with Intrinsic Functions) syntax.  Th
is
will allow your readers to compile with almost any compiler (and will allow 
them
to use an add-on that uses a "CALL interface" for UI).  Personally, I would 
NOT
recommend using OO - as this simply is not standardized (in practice) and th
e
source code would not be portable across compilers.  Similarly, I would avoi
d
(Sorry about this Kellie) all calls to "operating system" and/or "windows"
API's.

In this way you could (in your book and with your examples), concentrate on
- COBOL "business logic" handling
- separating User-interface from business logic
- separating OS level interfaces

You could develop your sample code with any of the "Academic" versions of th
e
common Windows (most of which have Linux version) compilers, e.g. Micro Focu
s,
Fujitsu, AcuCOBOL, Liant, etc.  My guess is that you could get "personal use
"
versions of either sp2 or ScreenIO if you contacted the vendor (and planed o
n
giving appropriate acknowledgement in your book).

P.S.  Again personally, I would stay away from any compiler that doesn't inc
lude
"full" '85 Standard support.  Support for "common" intrinsic functions (LENG
TH,
Day/Date, and NumVal) is certainly desirable in "business applications".  I
would also (probably) stay away from most of the '02 Standard "stuff" - but 
SOME
of it is pretty common (such as free form reference format, inline comments,
GoBack statement - but almost all that is available CAN be avoided and still
code "useful" samples in '85 Standard - and portable - source code).

--
Bill Klein
wmklein <at> ix.netcom.com
"John Culleton" <john@wexfordpress.com> wrote in message
news:lI-dncWtk49QBbHenZ2dnUVZ_tOdnZ2d@adelphia.com...
> William M. Klein wrote:
> 
> Well if it helps:
>
> I am writing a little book on COBOL programs for small business. I am also
> including some programs. My native platform is Linux but many of the peopl
e
> who buy the little book will be on MsWin.
>
> I am looking for a compiler that meets 74 and at least some of 85 and 2000
.
> I do not want it for myself as such but I want to be able to recommend it
> to others with a straight face. Multiuser interface is not an issue. If th
e
> compiler will handle the SCREEN section and/or DISPLAY/ACCEPT LINE x COLUM
N
> y that would be lovely. A fancy IDE or other such extension is not needed
> nor desired. Bopth batch and interactive are needed of course.
>
> Cheap is important. If I tell someone that they have to spend $2,000 or
> $3,000 just to try out my little programs then that is a lost sale.
> TinyCOBOL which is free is adequate for my needs but compiling and
> installing it on MSWin is an adventure even for the experienced. Ditto
> OpenCOBOL. I suspect COBOL 650 is too far out of date even for me.
>
> Another listmate was kind enough to list some vendors and their sites.
> Unfortunately most of those sites do their very best to disguise pricing
> information. Hence I asked the newsgroup. Why vendors think they can hold 
a
> prospect's attention without answering the basic price question is beyond
> me.
>
> I am looking into Kobol for MSWin. They reveal prices (yay) and are not ou
t
> of sight pricewise.
>
> --
> John Culleton
> Able Indexers and Typesetters

The other thing to remember is that the "web is worldwide" - prices (for alm
ost
all compilers) VARY from country to country (along with the support that is
available).  All of them (probably) tell you how you can contact a "sales
representative" (via phone or email) to get further information.  Often it h
elps
to tell WHY you want the compiler (to develop a book may get you a different
price with a different set of restrictions) than to develop commercial softw
are.

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1127005074.523243.252230@g47g2000cwa.googlegroups.com... 
>
> """If you need to ask the price then you can't afford it."""
>
> In most situations the price of the compiler and runtimes and the
> ongoing 20% 'support and update' annual fees are just a small part of a
> project's budget. If it is in-house application then the facilities of
> the package will speed development and outweigh these costs. If it a
> saleable package then the developer and run-time costs are a small
> percentage of the total sale.
>
> If you want to distribute source code and there to be a free/cheap/easy
> compiler for others to use then Cobol may not be your best choice.
>

On Sat, 17 Sep 2005 18:24:54 +0000, John Culleton
<john@wexfordpress.com> wrote:
>
>I am writing a little book on COBOL programs for small business. I am also
>including some programs. My native platform is Linux but many of the people
>who buy the little book will be on MsWin.
>
>I am looking for a compiler that meets 74 and at least some of 85 and 2000.
>I do not want it for myself as such but I want to be able to recommend it
>to others with a straight face. Multiuser interface is not an issue. If the
>compiler will handle the SCREEN section and/or DISPLAY/ACCEPT LINE x COLUMN
>y that would be lovely. A fancy IDE or other such extension is not needed
>nor desired. Bopth batch and interactive are needed of course.
>
>Cheap is important. If I tell someone that they have to spend $2,000 or
>$3,000 just to try out my little programs then that is a lost sale.
>TinyCOBOL which is free is adequate for my needs but compiling and
>installing it on MSWin is an adventure even for the experienced. Ditto
>OpenCOBOL. I suspect COBOL 650 is too far out of date even for me.

As this is for a book I would consider Fujitsu V3 (free)


If you wish to include this compiler with your book you will need to
speak with Fujitsu and on that case I would also speak with MicroFocus
and see if either of them still supply a free version of their
compiler for this particular purpose.


But main thing for your examples is, as Bill Klein mentioned, to stick
with strict ANSI flagging.
Following Bill's advice given on his last post will definitely help
you in your book.




Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com