info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
COBOL: You're Thinking Ab
63 views
Skip to first unread message
Dumas Walker
Mar 8, 2023, 11:15:10 AM3/8/23
to
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....
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....
docd...@panix.com
Mar 8, 2023, 12:02:25 PM3/8/23
to
In article <6782...@f10.n1.z7738.fidonet.org>,
Dumas Walker <Dumas....@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
Dumas Walker <Dumas....@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.
archaic, doomed to failure and best stayed away from. The next week I was
told that Neil Armstrong walked on the moon.'
DD
Vincent Coen
Mar 9, 2023, 11:37:29 AM3/9/23
to
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
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
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
> 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.
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
Joe
Mar 10, 2023, 6:13:48 AM3/10/23
to
direct usage, vs Programming Guide which dives deeper into the educational/practical usage part.
Vincent Coen
Mar 10, 2023, 9:48:29 AM3/10/23
to
Hello Joe!
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
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
Joe
Mar 11, 2023, 7:07:17 AM3/11/23
to
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.....
Vincent Coen
Mar 13, 2023, 6:33:53 PM3/13/23
to
Hello Joe!
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
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.
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 ;-)
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.....
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
Joe
Mar 17, 2023, 9:10:00 AM3/17/23
to
again ;-)
0 new messages