Re: Differences in data description in programming languages
From: Pete Dashwood (dashwood_at_enternet.co.nz)
Date: 11/28/04
- Next message: docdwarf_at_panix.com: "Re: Need help with REDEFINES (I think)...."
- Previous message: Pete Dashwood: "Re: COMPUTE vs MOVE"
- In reply to: James J. Gavan: "Re: Differences in data description in programming languages"
- Next in thread: Alistair Maclean: "Re: Differences in data description in programming languages"
- Reply: Alistair Maclean: "Re: Differences in data description in programming languages"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 28 Nov 2004 22:24:01 +1300
"James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:H5bqd.372236$%k.327708@pd7tw2no...
> Warren Simmons wrote:
>
> > You are right about the features of the TC compiler, but
> > the 85 is their objective. In fact, in some cases they have
> > gone beyond 85, or even added extensions. AFAIK, they now
> > combine the efforts of the open Cobol group (not sure of
> > name). It appears that some users have adopted it, and
> > because the intermediate is C, more help is easier to get.
> > I believe they have made large advances. My download
> > installed in programs just like any other program. There
> > are other requirements. Burkley DB for example. They
> > support fixed and free form. There are provisions for debugging.
> > It's not the final product, but with this release, more
> > of the world will be able to speed the effort and contribute
> > to it.
> >
> That's why I asked Warren. Their objective is COBOL 85. As you well know
> I'm lousy at math - but next year their objective is to catch up with
> something which will be 20 years out-of-date.
>
> Totally ignoring OO, because that's a 'biggie' to take on - what
> features do they have actually running from the COBOL 2002 standard ?
> That doesn't mean they have to be 1,000% COBOL 2002 compliant - nobody
> else is ! For starters do they have the Intrinsic Functions .What is
> their target market with, "It's not the final product, but with this
> release.......". Are they seriously hoping to knock-off AcuCorp,
> Fujitsu, Liant or Micro Focus.
>
> I've rarely looked at this stuff, and it might have been an Open Source
> other than Tiny C., but I recall one comment at the site where it said
> something like, "Jesus Gonzalez from Argentina won't be contributing on
> a regular basis, because unfortunately there is a power shortage in the
> city, cutting off his computer supply randomly". (Either that or he
> hadn't got a nickel to put into the electricity meter). In the real
> world what sort of Mickey Mouse operations are these Open Sources -
> about as useful as our Infinite Loop threads !
>
> Jimmy
>
Gee, Jimmy, you were such a fervent advocate of Open Source a few years
back.
In fact it was your enthusiasm for it that caused me to have a look...<G>
Never mind. Time passes and we all have a right to change our minds.
While I wish TC well, I can't see it ever becoming viable or competing,
exactly as you describe.
The problem is that COBOL has had its day. The "perceived wisdom" is that
COBOL is over. Even if you could get it for free (like Open Source...) it
would be a very brave manager who would mandate development in it, in
today's climate.
Now, if there had been a free COBOL compiler in 1985, one that implemented
the COBOL '85 standard, the world today might be a different place.
In passing I'd like to note an exception.
I recently had cause to develop an application that needed to have a shared
(via the Internet) database. I found an ISP who would allow my MS ACCESS DB
to be shared on his server, using the MyODBC driver for remote access and
managing it with MySQL server (which can also accomodate ACCESS DBs...). I
was impressed with MyODBC which worked exactly as documented and implemented
facilities that MS ODBC SHOULD have had. It allowed me to define the remote
DB as a DSN and even gave me a facility to test the connection at the same
time.
MyODBC is Open Source and a free download.
My PowerCOBOL application didn't mind it at all and ran correctly, going via
this driver to the remote ACCESS DB in under 5 seconds. (A round trip of
15000 miles). Subsequent accesses were under 3 seconds. Pretty good for free
software.
I was so intriqued, I decided to convert the ACCESS database to MySQL which
was a very simple process. To my astonishment, I found that MySQL had all
the facilities of ACCESS (although it took a few days to get round the
learning curves) and ran much faster! Running it on the same server the
initial response was under 4 seconds and subsequent under 2. All of my
existing SQL ran without change (apart from one complex piece of nested SQL,
which I simply broke into simpler statements).
MySQL is Open Source and a free download.
These products are stable, supported, and in use all over the world by
hundreds of thousands of people.
So it would be unfair to classify all Open Source as "Mickey Mouse"... I
have decided to use MySQL for all future development and have found the
support forums and the products and documentation to be first class.
It would be great to see TC doing the same, but I fear it is not likely...
Pete.
- Next message: docdwarf_at_panix.com: "Re: Need help with REDEFINES (I think)...."
- Previous message: Pete Dashwood: "Re: COMPUTE vs MOVE"
- In reply to: James J. Gavan: "Re: Differences in data description in programming languages"
- Next in thread: Alistair Maclean: "Re: Differences in data description in programming languages"
- Reply: Alistair Maclean: "Re: Differences in data description in programming languages"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
