From: Pete Dashwood on
Paul H wrote:
> Wow! I have almost no idea what you guy are arguing about (maybe a
> little). I do understand that my comment that I want to avoid
> anything that seems like assembly language caused most of this.
>
> I started my career with Autocoder on an IBM 1401, then Honeywell's
> Easycoder, then a couple others whose names I can't remember
> (something on a Data general computer?)

Ah, I have dropped word marks with the best of 'em... : - ) I remember
running 1401 Autocoder I wrote, on system 360 in compatibility mode and
thinking how wondrous life was... : - )


I used 8086 machine language
> to enable my COBOL to access serial ports, Enuf assembler!!!
>
> I conclude that no COBOL will do what I need.

Perhaps you mean "no FREE COBOL"? I don't want to pry into what you are
trying to do, but COBOL is a very powerful language.

Maybe Clarion (I
> already own version 5.5), or RealBasic, if I can find a data base
> that stays in my target price range.

Funny thing Paul, I was looking at Clarion the other day. Found (to my
astonishment) that it supports ActiveX and COM components. This makes it a
very powerful tool. You could get or build components to do what you want
and "glue" them together with Clarion... RealBasic may also be a good
option. (Visual Basic is free from MicroSoft and you can develop it in
Visual Studio Express, which is also free...)

As for database...I can personally recommend MySQL which is free. MS Access
(2000 and above) has also come a long way from its humble (and generally
poorly implemented) beginnings.

Good luck!

Pete.
--
"I used to write COBOL...now I can do anything."


From: Pete Dashwood on
Paul H wrote:
> I should have added that in the late 60's the "Journal of the ACM"
> had an article that said something to the effect that all processing
> could be driven by thorough description of data structures. That's
> why I like COBOL so much. By describing data structures, the code
> needed to deal with arithmetic or logic can ignore these details.
> The programmer is unlikely to scribble on memory outside of his data
> division. No wonder more lines of COBOL code (a quarter of a
> trillion lines?) are in use today, with billions more written every
> year.

Not intended as "punishment" (believe whatever you want to...) but:

1. The estimate of 5 billion lines of COBOL a year is suspect, but even if
it were true, the lines written in Java alone are around 5 times that. (To
be fair, these estimates are just as suspect as the COBOL ones... no-one
REALLY knows.)

2. The quarter of a trillion lines of COBOL came from a Gartner report (as
Gartner do business with a large COBOL user base it can hardly be seen as
unbiased...) that is now over 10 years old. In that time billions of lines
of that codebase have been eroded by conversion, replacement, and
retirement, and this process proceeds and accellerates every year.

The point is that it doesn't matter how many LOC are written in ANY
language; what matters is the cost of writing it and whether it can be or
needs to be, maintained.

> And consider the number of lines of lower level language that
> are needed to do what single lines of COBOL do. "string" and
> "unstring delimited by" are good examples. I dread the flaming
> responses that these comments will cause. Please, just let me
> express my opinion without being punished. Paul

There are a number of powerful constructs in COBOL and these are just two of
them. COBOL's problems were never with the power of the language.

This is not a "flaming" response, Paul, just civilized discussion and
observation... :-)

Pete.
--
"I used to write COBOL...now I can do anything."


From: HeyBub on
Paul H wrote:
> And consider the number of lines of lower level language that
> are needed to do what single lines of COBOL do. "string" and
> "unstring delimited by" are good examples. I dread the flaming
> responses that these comments will cause. Please, just let me
> express my opinion without being punished. Paul

A better example would be floating the currency symbol to the immediate left
of the most significant number or check-protecting a field. Trivial.

Conversely, computing the hyperbolic arc tangent is pretty tough in COBOL
(I've only done it once) - but just one statement in FORTRAN.


From: Paul on
On 2008-12-16 23:18:09 -0600, "Paul H" <NoSpamphobergNoSpam(a)att.net> said:

> Wow! I have almost no idea what you guy are arguing about (maybe a little).
> I do understand that my comment that I want to avoid anything that seems
> like assembly language caused most of this.
>
> I started my career with Autocoder on an IBM 1401, then Honeywell's
> Easycoder, then a couple others whose names I can't remember (something on a
> Data general computer?) I used 8086 machine language to enable my COBOL to
> access serial ports, Enuf assembler!!!
>
> I conclude that no COBOL will do what I need. Maybe Clarion (I already own
> version 5.5), or RealBasic, if I can find a data base that stays in my
> target price range.

<grin> Realbasic comes with a little old database... </grin>

I really like RealBasic. :)


>
> Thanks for your help, everybody.
>
> Paul
>
> "Paul H" <NoSpamphobergNoSpam(a)att.net> wrote in message
> news:494095a5$0$5502$bbae4d71(a)news.suddenlink.net...
> I've been using MicroFocus Net Express for many years, but now I want to
> write a small application that would sell for maybe $20.00. MF would charge
> a run-time fee to each user, so I need to select a different Compiler.
> Where can I find a list of inexpensive compilers, with ratings? Does such a
> list exist? TIA, Paul