Found a link to this article on osnews.com.

COBOL - You're Thinking About It Wrong

"...[W]hile headlines might indicate the language had fallen into disfavor,
the amount of COBOL in use continues to grow, with 800 billion lines running
in production systems daily, according to a global survey conducted last year by enterprise software firm Micro Focus. COBOL is considered strategic by 92% of survey respondents, and over half said they expect their organizations to keep running their COBOL applications for at least another 10 years.

"COBOL suffers from a 'major image problem' that stems from fundamental misperceptions. When a group of academic and industry researchers asked members of the COBOL Working Group of the Open Mainframe Project to rank the top five COBOL misperceptions, the top opinions were that the language is outdated, hard to learn and a bad career choice.

"None of that is true, the researchers wrote in the December 2022 paper... Unlike modern programming languages that require specific syntax, COBOL is relatively simple to learn. It was developed 'o be easy to read, understand, and program for programmers in the 1960s who had few explicit training opportunities,' the paper said.

The article goes on to speculate that the COBOL's perception problem stems from "IT leaders" who were familiar with COBOL longer being the ones making decisions
It also mentions how the lack of COBOL training and programmers lead to the issues that government unemployment systems had during the increased system demand caused by the pandemic.

More here: https://gcn.com/cloud-infrastructure/2023/01/cobol-youre-thinking-about-it-wrong
/381563/

https://tinyurl.com/3maz6md7


* SLMR 2.1a * A distant ship, smoke on the horizon....
--- SBBSecho 3.14-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (21:1/175)

In article <678294125@f10.n1.z7738.fidonet.org>,
Dumas Walker <Dumas.Walker@f10.n1.z7738.fidonet.org> wrote:

[snip]

"COBOL suffers from a 'major image problem' that stems from fundamental >misperceptions. When a group of academic and industry researchers asked members
of the COBOL Working Group of the Open Mainframe Project to rank the top five >COBOL misperceptions, the top opinions were that the language is outdated, hard
to learn and a bad career choice.

The one I remember went something like 'I was told that COBOL was weak, archaic, doomed to failure and best stayed away from. The next week I was
told that Neil Armstrong walked on the moon.'

DD

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Dumas!

Tuesday March 07 2023 20:37, Dumas Walker wrote to ALL:

Found a link to this article on osnews.com.

COBOL - You're Thinking About It Wrong

"COBOL suffers from a 'major image problem' that stems from
fundamental misperceptions. When a group of academic and industry researchers asked members of the COBOL Working Group of the Open
Mainframe Project to rank the top five COBOL misperceptions, the top opinions were that the language is outdated, hard to learn and a bad
career choice.

In the early 60's the programming reference manual for a IBM 1401 ran to 50 pages and that at least for me was my training tool and the only one
available more than enough for the job.

Today's manuals such as for gnuCbol which now includes training on usage
etc is over 900 pages.


Vincent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 09 Mar 2023 16:32:44 +0000, "Vincent Coen" <VBCoen@gmail.com> wrote:

Hello Dumas!

Tuesday March 07 2023 20:37, Dumas Walker wrote to ALL:

Found a link to this article on osnews.com.

COBOL - You're Thinking About It Wrong

"COBOL suffers from a 'major image problem' that stems from
fundamental misperceptions. When a group of academic and industry researchers asked members of the COBOL Working Group of the Open
Mainframe Project to rank the top five COBOL misperceptions, the top opinions were that the language is outdated, hard to learn and a bad
career choice.

In the early 60's the programming reference manual for a IBM 1401 ran to 50 >pages and that at least for me was my training tool and the only one >available more than enough for the job.

Today's manuals such as for gnuCbol which now includes training on usage
etc is over 900 pages.

Vincent

I've looked at the gnuCobol manual and find it not easy to use. I prefer the IBM style of Language Reference with only syntax and
direct usage, vs Programming Guide which dives deeper into the educational/practical usage part.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Joe!

Friday March 10 2023 11:13, Joe wrote to All:

On Thu, 09 Mar 2023 16:32:44 +0000, "Vincent Coen" <VBCoen@gmail.com>
wrote:

Hello Dumas!

Tuesday March 07 2023 20:37, Dumas Walker wrote to ALL:

Found a link to this article on osnews.com.

COBOL - You're Thinking About It Wrong

"COBOL suffers from a 'major image problem' that stems from
fundamental misperceptions. When a group of academic and industry
researchers asked members of the COBOL Working Group of the Open
Mainframe Project to rank the top five COBOL misperceptions, the

top

opinions were that the language is outdated, hard to learn and a

bad

career choice.

In the early 60's the programming reference manual for a IBM 1401 ran
to 50 pages and that at least for me was my training tool and the
only one available more than enough for the job.

Today's manuals such as for gnuCbol which now includes training on
usage etc is over 900 pages.


Vincent

I've looked at the gnuCobol manual and find it not easy to use. I
prefer the IBM style of Language Reference with only syntax and direct usage, vs Programming Guide which dives deeper into the educational/practical usage part.

Agreed, this is why I have created a Programming Reference manual but it
very much a work in progress in order to remove all the training materials
the current copy uses exactly the text for the Guide so I have to make
copies of each section removing such material and renaming these new
documents - a right pain in the ****.
It really means that any change in the PG has to also be made in the PR if
it relates to reference material - just doubles the work load so I am
trying to work out a way of splitting the text in to 2 elements and just include all the training stuff as and where it is used - it is a long
process.

On top of which I do not know how well this process and the Programming Reference will go down with GC users :(

Vincent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Mar 2023 14:43:03 +0000, "Vincent Coen" <VBCoen@gmail.com> wrote:

Hello Joe!

Friday March 10 2023 11:13, Joe wrote to All:

On Thu, 09 Mar 2023 16:32:44 +0000, "Vincent Coen" <VBCoen@gmail.com> wrote:

Hello Dumas!

Tuesday March 07 2023 20:37, Dumas Walker wrote to ALL:

Found a link to this article on osnews.com.

COBOL - You're Thinking About It Wrong

"COBOL suffers from a 'major image problem' that stems from
fundamental misperceptions. When a group of academic and industry
researchers asked members of the COBOL Working Group of the Open
Mainframe Project to rank the top five COBOL misperceptions, the

top

opinions were that the language is outdated, hard to learn and a

bad

career choice.

In the early 60's the programming reference manual for a IBM 1401 ran
to 50 pages and that at least for me was my training tool and the
only one available more than enough for the job.

Today's manuals such as for gnuCbol which now includes training on
usage etc is over 900 pages.


Vincent

I've looked at the gnuCobol manual and find it not easy to use. I
prefer the IBM style of Language Reference with only syntax and direct usage, vs Programming Guide which dives deeper into the educational/practical usage part.

Agreed, this is why I have created a Programming Reference manual but it
very much a work in progress in order to remove all the training materials >the current copy uses exactly the text for the Guide so I have to make
copies of each section removing such material and renaming these new >documents - a right pain in the ****.
It really means that any change in the PG has to also be made in the PR if
it relates to reference material - just doubles the work load so I am
trying to work out a way of splitting the text in to 2 elements and just >include all the training stuff as and where it is used - it is a long >process.

On top of which I do not know how well this process and the Programming >Reference will go down with GC users :(

Vincent

I appreciate the work y'all do & hope one day things will come together.

Several years ago I've set up some (back then) OpenCobol programs but the difficulty of using an SQL interface with unknown
reliability and the (then) lack of easy MQ support have made me go in the Python direction.

To be honest, I've glanced at the manuals and the things I could find but am not convinced those issues have been sufficiently
addressed yet - or I've missed things.

I've been in the IBM Cobol system since whenever, using al databases they've ever used, using CICS command level up to the current
sysplex solutions. Even created interactive CLIST/REXX bussiness applications in places where CICS was not used ;-)

Maybe I'm spoiled but to survive in the current flood of new languages, frameworks, whatever, thorough reliable database interfaces
to MySQL, MariaDB, Postgress, forms of MQTT 3 and 5 including quality level 2 are needed. As I'm not a language developer and
retirement is getting closer, I now want faster results (not to be seen as instant gratification....) instead of having to find
separate components and or C/Java interfaces.

It's not a rant - I sincerely hope Cobol gets back on the agenda as it is a fantastic language. I just don't think were there yet -
and IBM will not support a flagship product for broad and (almost) free use.....

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Joe!

Saturday March 11 2023 12:07, Joe wrote to All:

On Fri, 10 Mar 2023 14:43:03 +0000, "Vincent Coen" <VBCoen@gmail.com>
wrote:

Hello Joe!

Friday March 10 2023 11:13, Joe wrote to All:

On Thu, 09 Mar 2023 16:32:44 +0000, "Vincent Coen"

<VBCoen@gmail.com>

wrote:

Hello Dumas!

Tuesday March 07 2023 20:37, Dumas Walker wrote to ALL:

Found a link to this article on osnews.com.

COBOL - You're Thinking About It Wrong

"COBOL suffers from a 'major image problem' that stems from
fundamental misperceptions. When a group of academic and

industry

researchers asked members of the COBOL Working Group of the

Open

Mainframe Project to rank the top five COBOL misperceptions,

the

top

opinions were that the language is outdated, hard to learn and

a

bad

career choice.

In the early 60's the programming reference manual for a IBM 1401

ran

to 50 pages and that at least for me was my training tool and the
only one available more than enough for the job.

Today's manuals such as for gnuCbol which now includes training

on

usage etc is over 900 pages.


Vincent

I've looked at the gnuCobol manual and find it not easy to use. I
prefer the IBM style of Language Reference with only syntax and

direct

usage, vs Programming Guide which dives deeper into the
educational/practical usage part.

Agreed, this is why I have created a Programming Reference manual but
it very much a work in progress in order to remove all the training
materials the current copy uses exactly the text for the Guide so I
have to make copies of each section removing such material and
renaming these new documents - a right pain in the ****. It really
means that any change in the PG has to also be made in the PR if it
relates to reference material - just doubles the work load so I am
trying to work out a way of splitting the text in to 2 elements and
just include all the training stuff as and where it is used - it is a
long process.

On top of which I do not know how well this process and the
Programming Reference will go down with GC users :(

Vincent

I appreciate the work y'all do & hope one day things will come
together.

Several years ago I've set up some (back then) OpenCobol programs but
the difficulty of using an SQL interface with unknown reliability and
the (then) lack of easy MQ support have made me go in the Python
direction.

SQL and gnuCobol ?
Not a problem, I run ACAS all in Cobol and uses GC (gnuCobol) compiler that uses Mysql (Or Mariadb) with no problems what so ever. Other run :
Oracle, DB/2, Postgres, SQLlite, DMS etc.
Just a case of finding the pre compiler and running against GC having made
any needed changes for X64 etc.

Note that Open Cobol was renamed gnuCobol some years ago when taken in to
and under the GNU banner.

To be honest, I've glanced at the manuals and the things I could find
but am not convinced those issues have been sufficiently addressed yet
- or I've missed things.

Should also have looked at the FAQ on SF for the needed topics to find out
how and of course the various forums again on SF.

I've been in the IBM Cobol system since whenever, using al databases
they've ever used, using CICS command level up to the current sysplex solutions. Even created interactive CLIST/REXX bussiness applications
in places where CICS was not used ;-)

KICS is not in the eco system yet, mostly because the only one I know of is still under closed beta testing although there might well be others out
there.

Maybe I'm spoiled but to survive in the current flood of new
languages, frameworks, whatever, thorough reliable database interfaces
to MySQL, MariaDB, Postgress, forms of MQTT 3 and 5 including quality
level 2 are needed. As I'm not a language developer and retirement is getting closer, I now want faster results (not to be seen as instant gratification....) instead of having to find separate components and
or C/Java interfaces.

It's not a rant - I sincerely hope Cobol gets back on the agenda as it
is a fantastic language. I just don't think were there yet - and IBM
will not support a flagship product for broad and (almost) free
use.....

As I said these components are available and usable. I have run a small
variant of ACAS using DB/2, Oracle and some others (but not SQLlite - no
point) but mostly for testing if they worked under Linux X64.

I did not continue with these despite saying in the ACAS docs that others (other than MySQL/Mariadb) was possible subject to requests - there has not been any, so have to assume any one interested has done it themselves as
the controlling Cobol modules for dealing as a DAL was already written.

All Cobol programs and modules that required access to Cobol Files / SQL
tables called a FH (File Handler) for each file which in turn if tables
are in use would call the specific DAL (Data Access Layer) that would
access the correct table.

A bit long winded in initial development but makes it easy for using other RDBMS systems.

Vincent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 13 Mar 2023 22:16:51 +0000, "Vincent Coen" <VBCoen@gmail.com> wrote:

Hello Joe!

Saturday March 11 2023 12:07, Joe wrote to All:

On Fri, 10 Mar 2023 14:43:03 +0000, "Vincent Coen" <VBCoen@gmail.com> wrote:

Hello Joe!

Friday March 10 2023 11:13, Joe wrote to All:

On Thu, 09 Mar 2023 16:32:44 +0000, "Vincent Coen"

<VBCoen@gmail.com>

wrote:

Hello Dumas!

Tuesday March 07 2023 20:37, Dumas Walker wrote to ALL:

Found a link to this article on osnews.com.

COBOL - You're Thinking About It Wrong

"COBOL suffers from a 'major image problem' that stems from
fundamental misperceptions. When a group of academic and

industry

researchers asked members of the COBOL Working Group of the

Open

Mainframe Project to rank the top five COBOL misperceptions,

the

top

opinions were that the language is outdated, hard to learn and

a

bad

career choice.

In the early 60's the programming reference manual for a IBM 1401

ran

to 50 pages and that at least for me was my training tool and the
only one available more than enough for the job.

Today's manuals such as for gnuCbol which now includes training

on

usage etc is over 900 pages.


Vincent

I've looked at the gnuCobol manual and find it not easy to use. I
prefer the IBM style of Language Reference with only syntax and

direct

usage, vs Programming Guide which dives deeper into the
educational/practical usage part.

Agreed, this is why I have created a Programming Reference manual but
it very much a work in progress in order to remove all the training
materials the current copy uses exactly the text for the Guide so I
have to make copies of each section removing such material and
renaming these new documents - a right pain in the ****. It really
means that any change in the PG has to also be made in the PR if it
relates to reference material - just doubles the work load so I am
trying to work out a way of splitting the text in to 2 elements and
just include all the training stuff as and where it is used - it is a
long process.

On top of which I do not know how well this process and the
Programming Reference will go down with GC users :(

Vincent

I appreciate the work y'all do & hope one day things will come
together.

Several years ago I've set up some (back then) OpenCobol programs but
the difficulty of using an SQL interface with unknown reliability and
the (then) lack of easy MQ support have made me go in the Python
direction.

SQL and gnuCobol ?
Not a problem, I run ACAS all in Cobol and uses GC (gnuCobol) compiler that >uses Mysql (Or Mariadb) with no problems what so ever. Other run :
Oracle, DB/2, Postgres, SQLlite, DMS etc.
Just a case of finding the pre compiler and running against GC having made >any needed changes for X64 etc.

Note that Open Cobol was renamed gnuCobol some years ago when taken in to
and under the GNU banner.

To be honest, I've glanced at the manuals and the things I could find
but am not convinced those issues have been sufficiently addressed yet
- or I've missed things.

Should also have looked at the FAQ on SF for the needed topics to find out >how and of course the various forums again on SF.

I've been in the IBM Cobol system since whenever, using al databases they've ever used, using CICS command level up to the current sysplex solutions. Even created interactive CLIST/REXX bussiness applications
in places where CICS was not used ;-)

KICS is not in the eco system yet, mostly because the only one I know of is >still under closed beta testing although there might well be others out >there.

Maybe I'm spoiled but to survive in the current flood of new
languages, frameworks, whatever, thorough reliable database interfaces
to MySQL, MariaDB, Postgress, forms of MQTT 3 and 5 including quality
level 2 are needed. As I'm not a language developer and retirement is getting closer, I now want faster results (not to be seen as instant gratification....) instead of having to find separate components and
or C/Java interfaces.

It's not a rant - I sincerely hope Cobol gets back on the agenda as it
is a fantastic language. I just don't think were there yet - and IBM
will not support a flagship product for broad and (almost) free
use.....

As I said these components are available and usable. I have run a small >variant of ACAS using DB/2, Oracle and some others (but not SQLlite - no >point) but mostly for testing if they worked under Linux X64.

I did not continue with these despite saying in the ACAS docs that others >(other than MySQL/Mariadb) was possible subject to requests - there has not >been any, so have to assume any one interested has done it themselves as
the controlling Cobol modules for dealing as a DAL was already written.

All Cobol programs and modules that required access to Cobol Files / SQL >tables called a FH (File Handler) for each file which in turn if tables
are in use would call the specific DAL (Data Access Layer) that would
access the correct table.

A bit long winded in initial development but makes it easy for using other >RDBMS systems.

Vincent

Thanks for the extra info and your extensive explanations, appriciated! I'll have to get myself updated on the various options
again ;-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)