From Newsgroup: comp.lang.cobol

On 05/08/2018 02:44 AM, pete dashwood wrote:

On 7/05/2018 11:47 PM, Bill Gunshannon wrote:

On 05/06/2018 11:05 PM, Arnold Trembley wrote:

On 5/6/2018 9:43 AM, Bill Gunshannon wrote:

On 05/06/2018 02:39 AM, Arnold Trembley wrote:

GnuCOBOL 3.0 Release Candidate 1 for Windows (built using 32-bit
MinGW GCC) is available for download with either Oracle Berkeley
Database or VBISAM 2.0.1 for Indexed Sequential file or without any >>>>> Indexed Sequential file support.

GnuCOBOL 3.0 is the first release that includes COBOL Report Writer. >>>>>
http://www.arnoldtrembley.com/GnuCOBOL-3.0-MinGW-Build-Guide-draft.pdf >>>>>
http://www.arnoldtrembley.com/GnuCOBOL-3.0-MinGW-Build-Guide-draft.odt >>>>>
http://www.arnoldtrembley.com/GC30RC1-BDB-rename-7z-to-exe.7z

http://www.arnoldtrembley.com/GC30RC1-VBI-rename-7z-to-exe.7z

http://www.arnoldtrembley.com/GC30RC1-NODB-rename-7z-to-exe.7z

I've done some simple testing with the BDB and NODB versions to
verify the compiler runs on Windows XP.  But I normally build on
Windows 7 and run on Windows 10.

Kind regards,

On 5/6/2018 9:43 AM, Bill Gunshannon wrote:

<mostly snipped as no disagreement or comment>

I believe the long-term goal of the GnuCOBOL developers is to
eventually include all ISO standard COBOL object-oriented features.

And that I see as least needed.  The majority of COBOL in use today
doesn't use them as they brought nothing but complexity to the table.
It has long been stated that when these features were added to the
standard the existing COBOL user base rejected them.

I never thought I'd see the day when you would acknowledge that, Bill,
but as you have, "Well Done!"

Huh? This has always been my position. I have been doing in
this business since long before OO and have never been a fan.
And of all the major COBOL users I know, none of them have
ever been fans either. To mne it has always been: "The
Emperor isn't wearing any clothes at all!!"

Unless your
desire is to destroy COBOL I see no reason to waste the time and
effort.

And this attitude was not just held by you alone. The result is what we
see today: COBOL as around 40th most popular programming language in the World.

Imagine if EVERYBODY had climbed on board the OO COBOL wagon... A new
COBOL responding to a new (event activated) paradigm.

We would have COBOL programs with needless complexity that didn't
do the job they were designed to do any better.

I believe there would still have been "new" languages (I'm teaching
myself "Rust" at the moment and it really makes me smile...) but it
would have been much harder to dislodge COBOL as a top 5 contender.

At lest in this country, COBOL is not being dislodged. The smaller
numbers are not due to any decrease in COBOL lines of code but more
due to all the meaningless crap (like Candy Crush Saga :-) being
written in other languages requiring millions of lines of code to
do what a hundred lines of COBOL would have done.

  If you truly "need" objects then maybe COBOL isn't the

right language for your task.

What?!! I can't believe what I'm hearing... :-)

Again, nothing new here. It has always been my stand that the
first step in any development system is to pick the language
best suited to the job. And, like it or not, there are still
a lot of tasks where COBOL is that language.

Perhaps we are all getting old... and wiser.

I know I am.

bill

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

domingo, 6 de Maio de 2018 às 07:39:46 UTC+1, Arnold Trembley escreveu:

GnuCOBOL 3.0 Release Candidate 1 for Windows (built using 32-bit MinGW
GCC) is available for download with either Oracle Berkeley Database or VBISAM 2.0.1 for Indexed Sequential file or without any Indexed
Sequential file support.

GnuCOBOL 3.0 is the first release that includes COBOL Report Writer.

http://www.arnoldtrembley.com/GnuCOBOL-3.0-MinGW-Build-Guide-draft.pdf

http://www.arnoldtrembley.com/GnuCOBOL-3.0-MinGW-Build-Guide-draft.odt

http://www.arnoldtrembley.com/GC30RC1-BDB-rename-7z-to-exe.7z

http://www.arnoldtrembley.com/GC30RC1-VBI-rename-7z-to-exe.7z

http://www.arnoldtrembley.com/GC30RC1-NODB-rename-7z-to-exe.7z

I've done some simple testing with the BDB and NODB versions to verify
the compiler runs on Windows XP. But I normally build on Windows 7 and
run on Windows 10.

Kind regards,

--
http://www.arnoldtrembley.com/GnuCOBOL.htm

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

"Cobol Report Writer" in the xxi century does not look interesting and should be very little used. Embedding graphical interfaces (UI/GUI) and SQL access (more easily), seems to be much more interesting and necessary, otherwise GnuCobol does not have a great future. But working for free it´s not easy.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 05/11/2018 12:15 PM, JM wrote:

domingo, 6 de Maio de 2018 às 07:39:46 UTC+1, Arnold Trembley escreveu:

GnuCOBOL 3.0 Release Candidate 1 for Windows (built using 32-bit MinGW
GCC) is available for download with either Oracle Berkeley Database or
VBISAM 2.0.1 for Indexed Sequential file or without any Indexed
Sequential file support.

GnuCOBOL 3.0 is the first release that includes COBOL Report Writer.

http://www.arnoldtrembley.com/GnuCOBOL-3.0-MinGW-Build-Guide-draft.pdf

http://www.arnoldtrembley.com/GnuCOBOL-3.0-MinGW-Build-Guide-draft.odt

http://www.arnoldtrembley.com/GC30RC1-BDB-rename-7z-to-exe.7z

http://www.arnoldtrembley.com/GC30RC1-VBI-rename-7z-to-exe.7z

http://www.arnoldtrembley.com/GC30RC1-NODB-rename-7z-to-exe.7z

I've done some simple testing with the BDB and NODB versions to verify
the compiler runs on Windows XP. But I normally build on Windows 7 and
run on Windows 10.

Kind regards,

--
http://www.arnoldtrembley.com/GnuCOBOL.htm

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

"Cobol Report Writer" in the xxi century does not look interesting and should be very little used. Embedding graphical interfaces (UI/GUI) and SQL access (more easily), seems to be much more interesting and necessary, otherwise GnuCobol does not have a great future. But working for free it´s not easy.

I have had quite a bit of success generating HTML reports for delivery
on the web instead of killing trees (ask me some day about one of the
systems I worked on 30 years ago that killed lots of trees needlessly!!)

I have also had success doing web front ends directly from COBOL. One
of these days I will make a suggestion to the developers about a way
I think it could be made even easier.

bill


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

sexta-feira, 11 de Maio de 2018 às 18:39:44 UTC+1, Bill Gunshannon escreveu:

On 05/11/2018 12:15 PM, JM wrote:

domingo, 6 de Maio de 2018 às 07:39:46 UTC+1, Arnold Trembley escreveu:

GnuCOBOL 3.0 Release Candidate 1 for Windows (built using 32-bit MinGW
GCC) is available for download with either Oracle Berkeley Database or
VBISAM 2.0.1 for Indexed Sequential file or without any Indexed
Sequential file support.

GnuCOBOL 3.0 is the first release that includes COBOL Report Writer.

http://www.arnoldtrembley.com/GnuCOBOL-3.0-MinGW-Build-Guide-draft.pdf

http://www.arnoldtrembley.com/GnuCOBOL-3.0-MinGW-Build-Guide-draft.odt

http://www.arnoldtrembley.com/GC30RC1-BDB-rename-7z-to-exe.7z

http://www.arnoldtrembley.com/GC30RC1-VBI-rename-7z-to-exe.7z

http://www.arnoldtrembley.com/GC30RC1-NODB-rename-7z-to-exe.7z

I've done some simple testing with the BDB and NODB versions to verify
the compiler runs on Windows XP. But I normally build on Windows 7 and
run on Windows 10.

Kind regards,

--
http://www.arnoldtrembley.com/GnuCOBOL.htm

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

"Cobol Report Writer" in the xxi century does not look interesting and should be very little used. Embedding graphical interfaces (UI/GUI) and SQL access (more easily), seems to be much more interesting and necessary, otherwise GnuCobol does not have a great future. But working for free it´s not easy.

I have had quite a bit of success generating HTML reports for delivery
on the web instead of killing trees (ask me some day about one of the
systems I worked on 30 years ago that killed lots of trees needlessly!!)

I have also had success doing web front ends directly from COBOL. One
of these days I will make a suggestion to the developers about a way
I think it could be made even easier.

bill

If you could share your ideas / concepts with the GbuCobol community, it could be very interesting.
Regards,
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

I never saw the need for Object Orientated code in the environment I
was working in - IBM 360/370/390 on MVS in batch and CICS. This was
because the needs OO was designed for were already addressed by other mechanisms and the infrastructure was not available at the time to
make it worth while to change. It also would have required a major
management commitment. This was probably also true of the Unisys
environments and any other classic mainframes that survived. OO
probably is better once the environment is there and in one sense
probably was needed more by C/C++ than it was for COBOL. On the UNIX/LINUX/WINDOWS systems when OO penetrated it probably was a
different story for COBOL. Also there were probably no conversion
tools in the early days of OO COBOL to help get systems from old
paradigm to OO so a massive effort would have been needed even to
ready a system to take advantage of OO.

Another major difference in environments is that the IBM Mainframe and
probably the other mainframe environments are more record oriented
than string and array oriented and natively support indexed files (the
z series COBOL support is a subset of the total VSAM capabilities).
Assembler, PL1, IDCAMS, SORT and proprietary languages such as DYL280
(now Vision something or other) and Easytrieve all support VSAM - the
IBM sequential, indexed and relative record access method support.
COBOL on the UNIX/Windows platform has to interface with a package and proprietary indexed file system to have the same capability. In this environment going directly to using the data base used by all other
packages and programs running on the system makes sense. Of course
that assumes that the business / government department / academic
institution was smart enough to standardize on one DBMS be it Oracle,
DB2, whatever the Microsoft SQL database manager is or the Linux DBMS.

COBOL at best was mediocre for report writing even with the REPORT
WRITER. DYL280 (now Vision something or another), Easytrieve and
other packages were and are far superior. Putting Screen handling in
COBOL may also have been a waste of time.

While waterfall probably was the least bad method of setting up the
early systems, it carried on longer than it should have because whole bureaucracies had grown up around it. It was not the COBOL
programmers who were rigid so much as the management. Then management
has become interested in packages so COBOL is the backwater in many organizations. Now the trend is to put things in the cloud. The
common thread in all of these environments is that there is probably
not current documentation of what these various systems as customized
for the organization do and how. If we thought COBOL programs or
assembler could be inscrutable, where does that put systems that are
control table (or Windows registry) driven with mediocre front ends
for maintaining those tables. How many of the organizations test
changes to these tables before putting them in production? How well
are these tables which control some basic processing documented?

Clark Morris
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 14/10/2018 1:39 PM, Clark F Morris wrote:

I never saw the need for Object Orientated code in the environment I
was working in - IBM 360/370/390 on MVS in batch and CICS. This was
because the needs OO was designed for were already addressed by other mechanisms and the infrastructure was not available at the time to
make it worth while to change. It also would have required a major management commitment. This was probably also true of the Unisys environments and any other classic mainframes that survived.

This is very fair comment, Clark. Sites who had no intention of moving
to a Networked environment had no incentive to learn about OO,
particularly because, in a centralized mainframe environment, doing
mostly batch processing, everything works pretty well and there is
little need to rock the boat.

You may think that a mainframe running CICS is a lot like a Network with multiple client/servers, or at least is doing the same job. But such is
not the case... (CICS is just a parasite and isn't even in the same
league as mainframe TP monitors like TaskMaster or Shadow or even
IMS/DC... so the remainder of this post excludes CICS.)


OO

probably is better once the environment is there and in one sense
probably was needed more by C/C++ than it was for COBOL.

With the benefit of many years hindsight, I can agree that OO COBOL was
not essential for mainframe COBOL processing. Probably the main reason
it was important to ME was because I moved off mainframes (but not COBOL
at that point) and the "environment" as you say, was different.

As I grew into the environment and OO it just made sense to discard OO
COBOL and use a language like C# which was designed for that.

I have given a lot of thought to why I consider OO so important (at
least in a Networked environment) and my conclusions are explained at: https://primacomputing.co.nz/PRIMAMetro/objectsAndLayers.aspx


On the

UNIX/LINUX/WINDOWS systems when OO penetrated it probably was a
different story for COBOL. Also there were probably no conversion
tools in the early days of OO COBOL to help get systems from old
paradigm to OO so a massive effort would have been needed even to
ready a system to take advantage of OO.

Absolutely correct! Looking at the tools now available it is a much
different picture and I have spent the last 15 years working on such
tools. Today, we can move COBOL '85 into OO COBOL with a mouse click
and, during the same process we can design, build, and load an optimized relational database to replace the indexed files, generate a modern OO
Data Access Layer to manage the new RDB, and refactor all of the COBOL
IO verbs in the legacy COBOL that address the indexed files, to be
invokes of the DAL objects... None of this was available when OO COBOL
was first released, and doing it manually would be a huge task. (I did 2
of these migrations manually and the experience prompted me to write the
tools we now have...)

Another major difference in environments is that the IBM Mainframe and probably the other mainframe environments are more record oriented
than string and array oriented and natively support indexed files (the
z series COBOL support is a subset of the total VSAM capabilities). Assembler, PL1, IDCAMS, SORT and proprietary languages such as DYL280
(now Vision something or other) and Easytrieve all support VSAM - the
IBM sequential, indexed and relative record access method support.

I would call Easytrieve a utility rather than a Language, but it is
around 30 years since I last used it so it may have been enhanced :-).

COBOL on the UNIX/Windows platform has to interface with a package and proprietary indexed file system to have the same capability.

That's true, but both Fujitsu and Micro Focus provide excellent ISAM
support with their COBOL compilers.


In this

environment going directly to using the data base used by all other
packages and programs running on the system makes sense. Of course
that assumes that the business / government department / academic
institution was smart enough to standardize on one DBMS be it Oracle,
DB2, whatever the Microsoft SQL database manager is or the Linux DBMS.

The secret here is separation and layers. (See the web pages referenced above).

There is really no problem running 2 or 3 different RDBMS as far as the applications are concerned, PROVIDED you don't go and plug Embedded SQL
into the application code. Applications see an interface and all of the
data manipulation is done by the objects in the DAL layer. (THESE
objects can have SQL in them, although nowadays, we generate LINQ
because it is many times more efficient and the source language of these objects doesn't matter because they are never maintained.(They contain
code to do every possible action against an RDB, and they are generated
with a mouse click...)

See: https://primacomputing.co.nz/PRIMAMetro/RDBandSQL.aspx

... for my thoughts about this.

COBOL at best was mediocre for report writing even with the REPORT
WRITER. DYL280 (now Vision something or another), Easytrieve and
other packages were and are far superior. Putting Screen handling in
COBOL may also have been a waste of time.

I remember when there was no other option (not even CICS... :-))

While waterfall probably was the least bad method of setting up the
early systems, it carried on longer than it should have because whole bureaucracies had grown up around it.

Amen to that! (https://dzone.com/articles/cretaceous-cobol-can-spawn)



It was not the COBOL

programmers who were rigid so much as the management. Then management
has become interested in packages so COBOL is the backwater in many organizations. Now the trend is to put things in the cloud. The
common thread in all of these environments is that there is probably
not current documentation of what these various systems as customized
for the organization do and how.

That's certainly true, but it is no longer the powerful argument it once
was. Programmers today have much better tools and it is quite possible
to analyze undocumented code and determine what it does.



If we thought COBOL programs or

assembler could be inscrutable, where does that put systems that are
control table (or Windows registry) driven with mediocre front ends
for maintaining those tables. How many of the organizations test
changes to these tables before putting them in production? How well
are these tables which control some basic processing documented?

Clark Morris

An interesting post, Clark.

Thanks,

Pete
--
I used to write COBOL; now I can do anything...
--- Synchronet 3.20a-Linux NewsLink 1.114