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 ;-)