[Info-vax] Any stronger versions of the LMF planned ?, was: Re: LMF Licence Generator Code

[Bill Gunshannon]

On 8/12/21 12:59 PM, Phillip Helbig (undress to reply) wrote:
> In article <471ad39c-dbd2-401a-bf3f-9eb3ab213c77n at googlegroups.com>, =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99 at gmail.com> writes:
>> On Thursday, August 12, 2021 at 2:58:11 AM UTC+12, Bill Gunshannon wrote:
>>
>>> Here we are 30 years later and there is still=20
>>> new COBOL being written every day.=20
>>
>> By whom, and for what?
> 
> It is still used in the financial industry, for instance.  And, yes,
> people are writing new COBOL code.

Banks, Insurance, Credit Card Processing, the IRS, the entire DOD
Payroll, DOD EMR, And I am sure a whole pile I have never had reason
to come across.

> 
>> What I found ironic was the premise that COBOL was written specifically for=
>>   =E2=80=9Cbusiness-oriented=E2=80=9D uses, eschewing any of that =E2=80=9Cs=
>> cientific=E2=80=9D stuff like mathematical notation and floating point, or =
>> even any decent dynamic string handling.

Math and floating point were already handled quite well by Fortan. 
Business was not well handled and thus they created COBOL.

>>
>> Then, a decade or two later, came along these things called =E2=80=9Crelati=
>> onal databases=E2=80=9D, which were enthusiastically adopted by businesses-=
>> -the very market that COBOL was supposedly optimized for.
> 
> One can use both.  Many do.

I don't understand his statement at all.  COBOL wasn't designed to be a
database.  Databases were designed to replace flat files, direct files
and ISAM/VSAM.  COBOL interfaces to relational dataabses as well as it
did files.  And has since at least the early 80's when I started doing
database access from COBOL programs.

> 
>> But it turns out the best way to interface to a relational DBMS is to gener=
>> ate SQL query strings. And for that, you need decent string handling, with =
>> facilities for format substitution, argument quoting and the like. None of =
>> which were envisaged in the original design of COBOL.
>>
>> So today, even a language like Python, Perl or (spit) PHP would be a better=
>>   fit for =E2=80=9Cbusiness needs=E2=80=9D than COBOL ...

Much of the business world doesn't agree.  :-)

> 
> Rdb SQL precompiler?
> 

Even GnuCOBOL has a precompiler for "EXEC SQL" statements.  Works like
a charm.  I have used it many times.

bill