In article <3a932af6-237b-4990-880c-771036696292n@googlegroups.com>, abrsvc <dansabrservices@yahoo.com> writes:
> On Wednesday, August 11, 2021 at 7:58:13 AM UTC-4, Joukj wrote:
> > >=20
> > > I have always thought the worst professors were those who had=20
> > > never been anything but students and professors. Professors=20
> > > who had held real jobs in their field always seemed better to=20
> > > me.=20
> > >=20
> > Why is being a researcher/lecturer at a university not a real job?=20
> >=20
> > Jouk
> Perhaps the phrase used was not the bet, but the intent of the comment is t=
> rue and I agree with it.
>
> Those that have never worked in IT except for teaching classes don't have a=
> feel for the real world. What is stated in books is usually the "ideal" a=
> nd is never seen in actual application. This is not unique to the IT world=
> either. I was working as a manager while in college and mistakenly took =
> a management class. The "teacher" clearly had never worked as a manager at=
> a real business as the things being taught would never have worked at a re=
> al business. Similarly, methods taught in many CS courses would not work i=
> n a real environment either. With this as the premise, the statement about=
> "real jobs" references experience outside of academia where the environmen=
> t is different.

Scott Aaronson quipped that a Ph.D. in computer science left him utterly
unqualified for the job of webmaster. :-)

On Wed, 11 Aug 2021 10:58:06 -0400, Bill Gunshannon wrote:

> On 8/11/21 7:58 AM, Joukj wrote:
>>>
>>> I have always thought the worst professors were those who had never
>>> been anything but students and professors.  Professors who had held
>>> real jobs in their field always seemed better to me.
>>>
>> Why is being a researcher/lecturer at a university not a real job?
>>
>>
> Because they have no real understanding about what is involved in
> production IT. There is nothing worse than a professor saying to a
> classroom full of students: "and this is what you will find when you get
> out in the workplace " when they have never been out in the workplace
> and are totally wrong.

Well, yes and no. We sent nearly all of them on a year in industry after
year two, before their final year. Real paid job, real experience. And
they brought that back and informed/corrected their teachers.

> Why do you think they stopped teaching COBOL (and other "legacy"
> languages, but mostly COBOL) claiming it was a dead language with no one
> still using it when there were millions of lines of COBOL in use every
> day by major industries and by two of the largest ISes in the world.
> Here we are 30 years later and there is still new COBOL being written
> every day.

What we taught was computational thinking and how to program (and otyher
stuff). Knowing COBOL is just training.

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On 8/11/21 8:43 AM, abrsvc wrote:
> On Wednesday, August 11, 2021 at 7:58:13 AM UTC-4, Joukj wrote:
>>>
>>> I have always thought the worst professors were those who had
>>> never been anything but students and professors. Professors
>>> who had held real jobs in their field always seemed better to
>>> me.
>>>
>> Why is being a researcher/lecturer at a university not a real job?
>>
>> Jouk
> Perhaps the phrase used was not the bet, but the intent of the comment is true and I agree with it.
>
> Those that have never worked in IT except for teaching classes don't have a feel for the real world. What is stated in books is usually the "ideal" and is never seen in actual application. This is not unique to the IT world either. I was working as a manager while in college and mistakenly took a management class. The "teacher" clearly had never worked as a manager at a real business as the things being taught would never have worked at a real business. Similarly, methods taught in many CS courses would not work in a real environment either. With this as the premise, the statement about "real jobs" references experience outside of academia where the environment is different.
>

There is also the concept that the terms "manager" and "management"
are often totally unrelated. In a previous life I remember scanning
resumes looking for someone to fill a new position. We advertised
for a Project Manager. we got dozens of applications from people
with experience such as "managed a Foot Locker Shoe Store at the mall
when I was in high school". Or "5 years experience managing a
McDonalds". We were looking for someone to manage a networking project
at a government site with a total value of about $25,000,000.

bill

On Wednesday, August 11, 2021 at 11:31:29 PM UTC+12, Joukj wrote:
> Ever tried to buy a laptop for home use without Windows installed in order to
> run Linux? I never succeeded.

I have one, from System76. You can get “white box” laptops (with no OS installed) from companies like Clevo. That’s what System76 does; they then add their own hardware/BIOS tweaks (like disabling that Intel system management engine thingie), and even provide their own “Pop!OS” spin of Ubuntu as a preinstallation option.

Me, I find Debian Unstable runs on it fine. ;)

Bill Gunshannon wrote:
> On 8/11/21 6:44 AM, Joukj wrote:
>> Bill Gunshannon wrote:
>>
>> However Fortran was never abandoned. Here in the physics department,
>> the most important applications are written in Fortran, since that
>> language is very suitable for heavy calculations on multi-dimensional
>> arrays.
>
> Yes, but does your Computer Science Department still teach it or are
> the engineering students learning it on their own or through the
> engineering department?
>

First year students get a course in Python of course.

But what they should learn from that is the "basic" concepts op writing
computer programs. If you got that you can easily learn other languages
and use the language that suites best for the problem at hand.
I create my applications in a mixture of Fortran/C/C++.

Jouk

Phillip Helbig (undress to reply) wrote:
> In article <sf0cln$13c4$2@gioia.aioe.org>, Joukj <joukj@hrem.nano.tudelft.nl> writes:
>> Bill Gunshannon wrote:
>>> On 8/7/21 4:33 PM, Phillip Helbig (undress to reply) wrote:
>>>> In article <in7b49Ffdh3U1@mid.individual.net>, Bill Gunshannon
>>>> <bill.gunshannon@gmail.com> writes:
>>> You know, our legal department refused permission to sign
>>> the license for the last Edu Program offered by HP. I
>>> hardly expect they would have allowed generation of our
>>> own licenses using pakgen.c.
>>>
>> The licenses I got for the HP EDU program had no end date....
>
> But is OPENVMS-ALPHA one of them, or are they layered products only?
>

OPENVMS-ALPHA is included.

Jouk

Bill Gunshannon wrote:
> On 8/11/21 7:58 AM, Joukj wrote:
>>>
>>> I have always thought the worst professors were those who had
>>> never been anything but students and professors. Professors
>>> who had held real jobs in their field always seemed better to
>>> me.
>>>
>> Why is being a researcher/lecturer at a university not a real job?
>>
>
> Because they have no real understanding about what is involved in
> production IT. There is nothing worse than a professor saying to
> a classroom full of students: "and this is what you will find when
> you get out in the workplace " when they have never been out in
> the workplace and are totally wrong.
>
> Why do you think they stopped teaching COBOL (and other "legacy"
> languages, but mostly COBOL) claiming it was a dead language with
> no one still using it when there were millions of lines of COBOL
> in use every day by major industries and by two of the largest
> ISes in the world. Here we are 30 years later and there is still
> new COBOL being written every day.
>
At a university we do not only teach but also do research. Many of those
research projects are in collaboration with industry. So we have to look
farther than the classroom and the books. Also in my "technical"
environment I never stumbled on COBOL. What we see is that companies use
a lot of Python (since they think Matlab is too expensive). That is the
reason our university teaches Python in the first year (and not Matlab,
which we could get cheap,as we did a few years ago).

But still I think also work at the university is a "real job".

regards
Jouk

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
> new COBOL being written every day.

By whom, and for what?

What I found ironic was the premise that COBOL was written specifically for “business-oriented” uses, eschewing any of that “scientific” stuff like mathematical notation and floating point, or even any decent dynamic string handling.

Then, a decade or two later, came along these things called “relational databases”, which were enthusiastically adopted by businesses--the very market that COBOL was supposedly optimized for.

But it turns out the best way to interface to a relational DBMS is to generate 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 “business needs” than COBOL ...

Den 2021-08-12 kl. 08:58, skrev Lawrence D’Oliveiro:
> 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
>> new COBOL being written every day.
>
> By whom, and for what?
>
> What I found ironic was the premise that COBOL was written specifically for “business-oriented” uses, eschewing any of that “scientific” stuff like mathematical notation and floating point, or even any decent dynamic string handling.
>
> Then, a decade or two later, came along these things called “relational databases”, which were enthusiastically adopted by businesses--the very market that COBOL was supposedly optimized for.
>
> But it turns out the best way to interface to a relational DBMS is to generate SQL query strings.

No, it is not. It is inefficient (since it needs to "compile" the
SQL at each execution) and dynamical SQL statements are the source
for "SQL injection" issues.

Proper application code used fixed precompiled SQL statements
with paramater markers.

> 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.

Just totaly wrong. Cobol works perfectly together with RDBMS's.

>
> So today, even a language like Python, Perl or (spit) PHP would be a better fit for “business needs” than COBOL ...
>

On 8/12/21 2:46 AM, Joukj wrote:
> Bill Gunshannon wrote:
>> On 8/11/21 7:58 AM, Joukj wrote:
>>>>
>>>> I have always thought the worst professors were those who had
>>>> never been anything but students and professors.  Professors
>>>> who had held real jobs in their field always seemed better to
>>>> me.
>>>>
>>> Why is being a researcher/lecturer at a university not a real job?
>>>
>>
>> Because they have no real understanding about what is involved in
>> production IT.  There is nothing worse than a professor saying to
>> a classroom full of students: "and this is what you will find when
>> you get out in the workplace " when they have never been out in
>> the workplace and are totally wrong.
>>
>> Why do you think they stopped teaching COBOL (and other "legacy"
>> languages, but mostly COBOL) claiming it was a dead language with
>> no one still using it when there were millions of lines of COBOL
>> in use every day by major industries and by two of the largest
>> ISes in the world.  Here we are 30 years later and there is still
>> new COBOL being written every day.
>>
> At a university we do not only teach but also do research. Many of those
> research projects are in collaboration with industry.

That depends on the University. Many do not do research.

> So we have to look
> farther than the classroom and the books. Also in my "technical"
> environment I never stumbled on COBOL.

Not surprising as COBOL is not a "technical" language. But in
the business world , banking, credit cards, HR, EMR, insurance,
it is rampant, as it should be.

> What we see is that companies use
> a lot of Python (since they think Matlab is too expensive). That is the
> reason our university teaches Python in the first year (and not Matlab,
> which we could get cheap,as we did a few years ago).
>
> But still I think also work at the university is a "real job".

Well, I "worked" at a University. :-)

bill

On 8/12/2021 2:58 AM, Lawrence D’Oliveiro wrote:
> 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 new COBOL being
>> written every day.
>
> By whom, and for what?

Mostly business applications started more than 30 years ago.

> What I found ironic was the premise that COBOL was written
> specifically for “business-oriented” uses, eschewing any of that
> “scientific” stuff like mathematical notation and floating point, or
> even any decent dynamic string handling.
>
> Then, a decade or two later, came along these things called
> “relational databases”, which were enthusiastically adopted by
> businesses--the very market that COBOL was supposedly optimized for.
>
> But it turns out the best way to interface to a relational DBMS is to
> generate 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.

This is so wrong in many ways.

1) The STRING construct in COBOL is perfectly capable
of doing string concatenation.

2) In the context of accessing a database then the elegance/efficiency
of string concatenation is not significant.

3) The vast majority of COBOL programs accessing a relation database
use embedded SQL and the SQL is not built as a string by the
developer.

Arne

In article <471ad39c-dbd2-401a-bf3f-9eb3ab213c77n@googlegroups.com>, =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@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.

> 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.
>
> 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.

> 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 ...

Rdb SQL precompiler?

In article <sf3k2f$re3$1@gioia.aioe.org>, helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:
>In article <471ad39c-dbd2-401a-bf3f-9eb3ab213c77n@googlegroups.com>, =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@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.

I have two clients that are both writing COBOL for aerospace logistics and on
VMS too.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 8/12/21 12:59 PM, Phillip Helbig (undress to reply) wrote:
> In article <471ad39c-dbd2-401a-bf3f-9eb3ab213c77n@googlegroups.com>, =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@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

On 8/12/2021 1:32 PM, Bill Gunshannon wrote:
> On 8/12/21 12:59 PM, Phillip Helbig (undress to reply) wrote:
>> In article <471ad39c-dbd2-401a-bf3f-9eb3ab213c77n@googlegroups.com>,
>> =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> writes:
>>> 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.

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

Wouldn't it be more accurate to say that a precompiler for
PostgreSQL and GNUCobol are available?

Arne

On Thursday, August 12, 2021 at 7:15:02 PM UTC+12, Jan-Erik Söderholm wrote:
>
> Den 2021-08-12 kl. 08:58, skrev Lawrence D’Oliveiro:
>
>> But it turns out the best way to interface to a relational DBMS is to generate
>> SQL query strings.
>
> No, it is not. It is inefficient (since it needs to "compile" the
> SQL at each execution) and dynamical SQL statements are the source
> for "SQL injection" issues.

Ah, the mindless knee-jerk reaction yet again. No, the source of embedded-language issues is improper quoting of embedded parameter values. I see this a lot in PHP code that I am called upon to fix! All the good DBMS APIs I have come across offer a “format_sql_value()” function, or equivalent, to address precisely this problem.

On Friday, August 13, 2021 at 5:32:09 AM UTC+12, Bill Gunshannon wrote:
>
> I don't understand his statement at all. COBOL wasn't designed to be a
> database.

Strawman, much?

I said COBOL was (supposedly) designed specifically for “business” needs. But those “business” needs soon came to include database-intensive applications, for which COBOL was, and remains, completely unsuited.

For an example of what I mean, how would you do the COBOL equivalent of what I can express in a single Python statement:

filter_clause = " and ".join \
(
"%s = %s" % (field_name, format_sql_value(params[field_name]))
for field_name in field_names
if params[field_name] != ""
)

(That is, filter the query on fields where the user entered a value, not on those where the value was left blank.)

On 8/12/2021 7:46 PM, Lawrence D’Oliveiro wrote:
> On Thursday, August 12, 2021 at 7:15:02 PM UTC+12, Jan-Erik Söderholm
> wrote:
>> Den 2021-08-12 kl. 08:58, skrev Lawrence D’Oliveiro:
>>> But it turns out the best way to interface to a relational DBMS
>>> is to generate SQL query strings.
>>
>> No, it is not. It is inefficient (since it needs to "compile" the
>> SQL at each execution) and dynamical SQL statements are the source
>> for "SQL injection" issues.
>
> Ah, the mindless knee-jerk reaction yet again. No, the source of
> embedded-language issues is improper quoting of embedded parameter
> values. I see this a lot in PHP code that I am called upon to fix!
> All the good DBMS APIs I have come across offer a
> “format_sql_value()” function, or equivalent, to address precisely
> this problem.

You should not use such a function in PHP.

PDO: call prepare with placeholders and execute with parameter array.

mysqli: call prepare with placeholders, bind_param with parameters and
execute.

pgsql: call prepare with placeholders and execute with parameter array.

Arne

On 8/12/2021 7:52 PM, Lawrence D’Oliveiro wrote:
> I said COBOL was (supposedly) designed specifically for “business”
> needs. But those “business” needs soon came to include
> database-intensive applications, for which COBOL was, and remains,
> completely unsuited.
COBOL is probably one of those languages with the highest percentage
using a database.

If we adjust the above to be relational databases, then COBOL is still
very much used.

It works.

> For an example of what I mean, how would you do the COBOL equivalent of what I can express in a single Python statement:
>
> filter_clause = " and ".join \
> (
> "%s = %s" % (field_name, format_sql_value(params[field_name]))
> for field_name in field_names
> if params[field_name] != ""
> )
>
> (That is, filter the query on fields where the user entered a value, not on those where the value was left blank.)

You are mixing two issues here:
1) handling a variable number of conditions in the SQL
2) handling the values

Re 2)

Escape function is not a good solution. Always parameters.
And Python DB API 2.0 supports parameters fine - execute
with placeholders in SQL and an array with parameters.

Re 1)

There are two well known solutions.

Single static SQL using the coalesce trick and sending over
NULL for not used parameters.

Building dynamic SQL with placeholders and just sending
over the parameters used.

(COBOL embedded SQL may lean heavily toward the first
solution)

Arne

On Friday, August 13, 2021 at 1:18:36 PM UTC+12, Arne Vajhøj wrote:
>
> On 8/12/2021 7:52 PM, Lawrence D’Oliveiro wrote:
>>
>> filter_clause = " and ".join \
>> (
>> "%s = %s" % (field_name, format_sql_value(params[field_name]))
>> for field_name in field_names
>> if params[field_name] != ""
>> )
>
> There are two well known solutions.
>
> Single static SQL using the coalesce trick and sending over
> NULL for not used parameters.
>
> Building dynamic SQL with placeholders and just sending
> over the parameters used.

I like the way you don’t offer any actual code, just some vague hand-waving arguments. Go on, then: let’s see how you address an actual business need by actually thinking about the problem, rather than just mindlessly regurgitating something you read on Stack Overflow.

Then we can compare the quality of your solution versus mine.

On 8/12/2021 10:04 PM, Lawrence D’Oliveiro wrote:
> On Friday, August 13, 2021 at 1:18:36 PM UTC+12, Arne Vajhøj wrote:
>> On 8/12/2021 7:52 PM, Lawrence D’Oliveiro wrote:
>>> filter_clause = " and ".join \ ( "%s = %s" % (field_name,
>>> format_sql_value(params[field_name])) for field_name in
>>> field_names if params[field_name] != "" )
>>
>> There are two well known solutions.
>>
>> Single static SQL using the coalesce trick and sending over NULL
>> for not used parameters.
>>
>> Building dynamic SQL with placeholders and just sending over the
>> parameters used.
>
> I like the way you don’t offer any actual code, just some vague
> hand-waving arguments. Go on, then: let’s see how you address an
> actual business need by actually thinking about the problem, rather
> than just mindlessly regurgitating something you read on Stack
> Overflow.

Actually I provided an precise solution just described in English.

Building dynamic SQL with placeholders and just sending over the
parameters used means to build an SQL string with:

.... WHERE field2 = ? AND field5 = ? ...

and send over the value2, value5, ... as parameters.

In Python something like:

sqlstr = 'SELECT name1,name2 FROM pairs'
param = []
if any(activeconditions):
sqlstr = sqlstr + ' WHERE ' + ' AND '.join(map(lambda item:
item[0] + '=?', activeconditions))
param = list(map(lambda item: item[1], activeconditions))
c.execute(sqlstr, param)

Single static SQL using the coalesce trick and sending over NULL
for not used parameters means to use a fixed SQL string like:

.... WHERE field1 = COLALESCE(?,field2) AND field2 = COLALESCE(?,field2) ...

and send over values for all fields but NULL for those fields not to be
used.

In Python something like:

sqlstr = 'SELECT name1,name2 FROM pairs WHERE name1 =
COALESCE(?,name1) AND name2 = COALESCE(?,name2)'
allfields = ['name1', 'name2']
param = []
for f in allfields:
param.append(conditions[f])
c.execute(sqlstr, param)

In VMS COBOL something like:

01 NAME1 PIC X(32).
01 NAME2 PIC X(32).
01 NAME1PRES PIC S9.
01 FINDNAME1 PIC X(32).
01 NAME2PRES PIC S9.
01 FINDNAME2 PIC X(32).
EXEC SQL DECLARE curs CURSOR FOR SELECT name1,name2 FROM pairs WHERE
name1 = COALESCE(:findname1:name1pres,name1) AND name2 =
COALESCE(:findname2:name2pres,name2) END-EXEC.
....
EXEC SQL OPEN curs END-EXEC
...
EXEC SQL CLOSE curs END-EXEC.

All pretty standard.

Arne

>-----Original Message-----
>From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of VAXman---- via
>Info-vax
>Sent: August-12-21 2:10 PM
>To: info-vax@rbnsn.com
>Cc: VAXman-@SendSpamHere.ORG
>Subject: Re: [Info-vax] Any stronger versions of the LMF planned ?, was:
Re:
>LMF Licence Generator Code
>
>In article <sf3k2f$re3$1@gioia.aioe.org>, helbig@asclothestro.multivax.de
>(Phillip Helbig (undress to reply)) writes:
>>In article <471ad39c-dbd2-401a-bf3f-9eb3ab213c77n@googlegroups.com>,
>=?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@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.
>
>I have two clients that are both writing COBOL for aerospace logistics and
on
>VMS too.
>
>--
>VAXman- A Bored Certified VMS Kernel Mode Hacker
>VAXman(at)TMESIS(dot)ORG
>
>I speak to machines with the voice of humanity.

Yep, I know of one US-Canada Customs 24x7 critical environment that is based
on OpenVMS Cobol and Oracle Rdb.

If the App is down, trucks stop at the border.

Mostly mainframe, but seems like lots of Cobol:
https://www.adzuna.ca/search?q=cobol&w=Canada

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG.
https://www.avg.com

On 8/15/2021 1:28 PM, kemain.nospam@gmail.com wrote:
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of VAXman---- via
>> Info-vax
>> In article <sf3k2f$re3$1@gioia.aioe.org>, helbig@asclothestro.multivax.de
>> (Phillip Helbig (undress to reply)) writes:
>>> It is still used in the financial industry, for instance. And, yes,
>>> people are writing new COBOL code.
>>
>> I have two clients that are both writing COBOL for aerospace logistics and
> on
>> VMS too.
>>
>> --
>> VAXman- A Bored Certified VMS Kernel Mode Hacker
>> VAXman(at)TMESIS(dot)ORG
>>
>> I speak to machines with the voice of humanity.
>
> Yep, I know of one US-Canada Customs 24x7 critical environment that is based
> on OpenVMS Cobol and Oracle Rdb.
>
> If the App is down, trucks stop at the border.

It is probably a general characteristics for Cobol
applications today that:
1) they were created many decades ago
2) they do something really impotant

> Mostly mainframe, but seems like lots of Cobol:
> https://www.adzuna.ca/search?q=cobol&w=Canada

101 Cobol jobs in Canada.

(but for comparison 6392 PHP, 6328 Python, 6146 Java,
3088 C#, 2856 C++, 341 Kotlin, 242 Groovy, 151 Rust,
71 VB.NET, 11 Fortran, 5 PL/I)

Arne

>-----Original Message-----
>From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj via
>Info-vax
>Sent: August-15-21 3:02 PM
>To: info-vax@rbnsn.com
>Cc: Arne Vajhøj <arne@vajhoej.dk>
>Subject: Re: [Info-vax] Any stronger versions of the LMF planned ?, was:
Re:
>LMF Licence Generator Code
>
>On 8/15/2021 1:28 PM, kemain.nospam@gmail.com wrote:
>>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of VAXman----
>>> via Info-vax In article <sf3k2f$re3$1@gioia.aioe.org>,
>>> helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
>>> writes:
>>>> It is still used in the financial industry, for instance. And, yes,
>>>> people are writing new COBOL code.
>>>
>>> I have two clients that are both writing COBOL for aerospace
>>> logistics and
>> on
>>> VMS too.
>>>
>>> --
>>> VAXman- A Bored Certified VMS Kernel Mode Hacker
>>> VAXman(at)TMESIS(dot)ORG
>>>
>>> I speak to machines with the voice of humanity.
>>
>> Yep, I know of one US-Canada Customs 24x7 critical environment that is
>> based on OpenVMS Cobol and Oracle Rdb.
>>
>> If the App is down, trucks stop at the border.
>
>It is probably a general characteristics for Cobol applications today that:
>1) they were created many decades ago
>2) they do something really impotant
>
>> Mostly mainframe, but seems like lots of Cobol:
>> https://www.adzuna.ca/search?q=cobol&w=Canada
>
>101 Cobol jobs in Canada.
>
>(but for comparison 6392 PHP, 6328 Python, 6146 Java,
>3088 C#, 2856 C++, 341 Kotlin, 242 Groovy, 151 Rust,
>71 VB.NET, 11 Fortran, 5 PL/I)
>
>Arne
>

Interesting article on COBOL from 2017:
<https://www.eweek.com/it-management/why-new-ceo-will-keep-cobol-a-key-focus
-of-micro-focus/>
"“Forty years ago, Micro Focus had COBOL, predominately mainframe COBOL, and
helped in the development of COBOL applications,” Hsu said. “Today, COBOL is
still one of the largest assets in the portfolio, and it’s growing.

“Mission-critical applications in COBOL still run most of the major at-scale
transaction systems, such as credit-card processing, large travel logistics,
and so on. What Micro Focus has done is innovate in COBOL to make it
mobile-accessible, cloud deployable and deployable in a distributed model.”

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG.
https://www.avg.com

On 8/15/2021 3:58 PM, kemain.nospam@gmail.com wrote:
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj via
>> Info-vax
>> Sent: August-15-21 3:02 PM
>> To: info-vax@rbnsn.com
>> Cc: Arne Vajhøj <arne@vajhoej.dk>
>> Subject: Re: [Info-vax] Any stronger versions of the LMF planned ?, was:
> Re:
>> LMF Licence Generator Code
>>
>> On 8/15/2021 1:28 PM, kemain.nospam@gmail.com wrote:
>>>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of VAXman----
>>>> via Info-vax In article <sf3k2f$re3$1@gioia.aioe.org>,
>>>> helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
>>>> writes:
>>>>> It is still used in the financial industry, for instance. And, yes,
>>>>> people are writing new COBOL code.
>>>>
>>>> I have two clients that are both writing COBOL for aerospace
>>>> logistics and
>>> on
>>>> VMS too.
>>>>
>>>> --
>>>> VAXman- A Bored Certified VMS Kernel Mode Hacker
>>>> VAXman(at)TMESIS(dot)ORG
>>>>
>>>> I speak to machines with the voice of humanity.
>>>
>>> Yep, I know of one US-Canada Customs 24x7 critical environment that is
>>> based on OpenVMS Cobol and Oracle Rdb.
>>>
>>> If the App is down, trucks stop at the border.
>>
>> It is probably a general characteristics for Cobol applications today that:
>> 1) they were created many decades ago
>> 2) they do something really impotant
>>
>>> Mostly mainframe, but seems like lots of Cobol:
>>> https://www.adzuna.ca/search?q=cobol&w=Canada
>>
>> 101 Cobol jobs in Canada.
>>
>> (but for comparison 6392 PHP, 6328 Python, 6146 Java,
>> 3088 C#, 2856 C++, 341 Kotlin, 242 Groovy, 151 Rust,
>> 71 VB.NET, 11 Fortran, 5 PL/I)
>>
>> Arne
>>
>
> Interesting article on COBOL from 2017:
> <https://www.eweek.com/it-management/why-new-ceo-will-keep-cobol-a-key-focus
> -of-micro-focus/>
> "“Forty years ago, Micro Focus had COBOL, predominately mainframe COBOL, and
> helped in the development of COBOL applications,” Hsu said. “Today, COBOL is
> still one of the largest assets in the portfolio, and it’s growing.
>
> “Mission-critical applications in COBOL still run most of the major at-scale
> transaction systems, such as credit-card processing, large travel logistics,
> and so on. What Micro Focus has done is innovate in COBOL to make it
> mobile-accessible, cloud deployable and deployable in a distributed model.”

I may have mentioned before, software does not wear out. It keeps
working. To which I often get replies that things change and therefore
the software is "worn out".

Maybe so, but software can be maintained. It does not surprise me that
there is plenty of older software out there still running things.

If it works, work it ..
If it ain't broke, don't fix it ..

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486