I am trying to re-learn using DB with COBOL. I have spent sometime in the forum looking for help. I updated my version of 'contrib'. I am wondering which pre-SQL I should use; ESQL or JC (presql2)?
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying to re-learn using DB with COBOL. I have spent sometime in
the forum looking for help. I updated my version of 'contrib'. I am
wondering which pre-SQL I should use; ESQL or JC (presql2)?
Rich Di Iulio
JC does NOT use standard sql statements i.e., SQL EXEC etc but a
variation however it does offer extra features in FD & WS areas as well
as allowing a print out listing of all data streams you have defined
within Mysql / mariadb. This feature I found very useful but must admit
only produced the listing once or twice.
Clearly by using non standard SQL statements means it is only for this
DB but otherwise works very well.
I was considering expanding this tool to allow for the std SQL
statements and leave the existing function still available but was
waiting for comments from users regarding this but to date I have not
received any so have not added to the feature list as it does for me and
the ACAS product (also available on SF).
Another tool is dbpre which uses standard SQL and even its own routines
in source for error handling but my testing of it these I found non
compatible with the way I needed it to operate.Also at that time it did
not support the cobol free format (which ACAS is written to) but it
does now so if I was doing the migration to create DAL units I might
well be using it.
If you pull down ACAS v3.02 (test) version you can see these Cobol
modules in the common directory.
This is kept up to date at midnight (UTC) if there are any changes to
the source code set.
Note that ACAS can use both MySQL or standard Cobol ISAM files so there
are two modules for each files -> tables.
The programs call the specific file Cobol file handler (DL) that in turn
will call the DAL if the system parameters are set to use the DB over
the cobol files.
This way creating support for another DB system is fairly straight
forward and not too time consuming.as there are only 24 odd files and
tables used so only the first one takes up time and the rest would use
the same coding with only minor changes for the table used.
Vince
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With your "likely moving DB target" esql from contrib or GixSQL are the only reasonable options if you don't want to potentially need to adjust your source code again to match a different preprocessor. Both are the only free/libre ones (so you can actually adjust where necessary) preprocessors I now of that allow to target different DB environments (the first with ODBC only, the second one with either ODBC or switch to "native" PostgreSQL).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wrote some POC DB2 programs but those worked only with specific version(s) both in Windows and Linux.
I also did some with esql (https://github.com/opensourcecobol/Open-COBOL-ESQL) + Postgres and found that combination far more stable than DB2's pre-processor.
I had the intention on writing my own pre processor for ODBC - just for fun - but have been too busy to do so.
Bottom line: You choose well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, thanks for the replies. I will probably use ESQL. I am going to use first for a DB is MySQL on Linux (Linux Mint). As I have a far amount of books on the topic. As I have questions, I will post here.
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All!
I am trying to re-learn using DB with COBOL. I have spent sometime in the forum looking for help. I updated my version of 'contrib'. I am wondering which pre-SQL I should use; ESQL or JC (presql2)?
Rich Di Iulio
On 13/11/2021 03:03, Rich Di Iulio wrote:
Clearly by using non standard SQL statements means it is only for this
DB but otherwise works very well.
I was considering expanding this tool to allow for the std SQL
statements and leave the existing function still available but was
waiting for comments from users regarding this but to date I have not
received any so have not added to the feature list as it does for me and
the ACAS product (also available on SF).
Another tool is dbpre which uses standard SQL and even its own routines
in source for error handling but my testing of it these I found non
compatible with the way I needed it to operate.Also at that time it did
not support the cobol free format (which ACAS is written to) but it
does now so if I was doing the migration to create DAL units I might
well be using it.
If you pull down ACAS v3.02 (test) version you can see these Cobol
modules in the common directory.
You can also grab a copy of v3.02 via my nightly builds at
http://www.applewood.linkpc.net/files/acas/nightlybuilds/
and select the file ACAS-Nightly.rar
http://www.applewood.linkpc.net/files/acas/nightlybuilds/ACAS-Nightly.rar
This is kept up to date at midnight (UTC) if there are any changes to
the source code set.
Note that ACAS can use both MySQL or standard Cobol ISAM files so there
are two modules for each files -> tables.
The programs call the specific file Cobol file handler (DL) that in turn
will call the DAL if the system parameters are set to use the DB over
the cobol files.
This way creating support for another DB system is fairly straight
forward and not too time consuming.as there are only 24 odd files and
tables used so only the first one takes up time and the rest would use
the same coding with only minor changes for the table used.
Vince
We recently went thru the process of figuring out what we will use.
We settled on esql build from the gnu cobol contrib folder.
Our use case is migrating DB2 COBOL from z/OS to Linux.
The eventual target is Postgres but we are are starting doing z/OS/DB2 -> Linux/DB2.
After get some success with that we will try -> Linux/Postgres.
We are making minor changes that we intend to contribute back.
It would not hurt my feelings if someone told me we picked poorly.
With your "likely moving DB target" esql from contrib or GixSQL are the only reasonable options if you don't want to potentially need to adjust your source code again to match a different preprocessor. Both are the only free/libre ones (so you can actually adjust where necessary) preprocessors I now of that allow to target different DB environments (the first with ODBC only, the second one with either ODBC or switch to "native" PostgreSQL).
I wrote some POC DB2 programs but those worked only with specific version(s) both in Windows and Linux.
I also did some with esql (https://github.com/opensourcecobol/Open-COBOL-ESQL) + Postgres and found that combination far more stable than DB2's pre-processor.
I had the intention on writing my own pre processor for ODBC - just for fun - but have been too busy to do so.
Bottom line: You choose well.
Just to make that clear: the esql noted in the referenced post is about esql-oc from https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/esql/ , not the unmaintained Open-COBOL-ESQL one you referenced.
Additional Note: GixSQL https://github.com/mridoni/gix/blob/main/doc/gixsql.md is an enhanced and fixed (and maintained) fork of Open-COBOL-ESQL.
First, thanks for the replies. I will probably use ESQL. I am going to use first for a DB is MySQL on Linux (Linux Mint). As I have a far amount of books on the topic. As I have questions, I will post here.
Rich Di Iulio