Do we know of anyone using ProCOBOL for MySQL database on a Windows system? I've dowloaded the "package" from Oracle but there are no installation instructions and no setup.exe. The programmer's guide talks about the package coming with the universal installer which was not included in mine. Some guidance would be greatly appreciated as Oracle will tell me nothing unless I have a support agreement.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ProCobol is for Oracle or at least it has been and I have not seen any
announcements that it has been reworked to handle any other rdb.
As Mysql is another vendors product it could be considered unlikely but
there again . . .
On 02/06/2020 10:31, Alan Honeyman wrote:
Do we know of anyone using ProCOBOL for MySQL database on a Windows
system? I've dowloaded the "package" from Oracle but there are no
installation instructions and no setup.exe. The programmer's guide
talks about the package coming with the universal installer which was
not included in mine. Some guidance would be greatly appreciated as
Oracle will tell me nothing unless I have a support agreement.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does Oracle claim procobol works with MySQL? (Documentation link would be welcome.)
The esql project in the contrib repository claims to work with MySQL, and there's a FAQ entry that, at least at one time, showed it to work.
I have tested esql with Microsoft's ODBC driver, and adapted the FAQ example to work with it. My work was done on Linux.
When you don't have support agreement, and the vendor offers no documentation, you're pretty much guaranteed to have better support for free software from the community. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bryan, MySQL is definately an Oracle product and the comprehensive ProCOBOL Programmer's Guide explains how it works with MySQL. James, I agree with your comment about the lack of installation documentation and I'll check out the esql project - thanks for the link.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just been on the Oracle website but cannot find any references to
Pro*Cobol and MySQL.
That was looking at the PC manual and docs for MySQL.
Can you point me to the right docs ?
Vince
On 02/06/2020 15:56, Alan Honeyman wrote:
Bryan, MySQL is definately an Oracle product and the comprehensive
ProCOBOL Programmer's Guide explains how it works with MySQL. James, I
agree with your comment about the lack of installation documentation
and I'll check out the esql project - thanks for the link.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-06-02
Oracle Pro*COBOL Precompiler is a programming tool that enables you to embed SQL statements in a host COBOL program. [...] the precompiler accepts the host program as input, translates the embedded SQL statements into standard Oracle run-time library calls, and generates a source program that you can compile, link, and execute in the usual way.
That's only a mirror, you find the actual project at https://sourceforge.net/projects/dbpre/; if you use the ODBC interface you should be able to use ESQL from contrib tree, too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm...the ProCobol Programmer's Guide doesn't say whether does or doesn't support it. Certainly, MySQL is not listed in the Index. I guess I was assuming that all Oracle DB's would be supported.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DBPre was announced over 2 years ago and it is in the contrib area some
where.
How ever there are issues with it other than it is no longer supported.
One I remember is that it only supports Fixed Cobol sources and has
limited functionality.
This tool is written in C.
I issued Jim Currey's pre-compiler with a lot of changes, that does both
fixed and free format and has many extra functions but it does not use
EXEC SQL statements but in the manual I did say I would consider adding
them if I got requests but I have not.
I use it in the ACAS O/S accounting software that is also on SF and
nightly builds via my site.
This processor will work on any platform that supports GnuCobol compiler
as it is written in Cobol.
It is available from the contrib Tools area.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I issued Jim Currey's pre-compiler with a lot of changes, that does both
fixed and free format and has many extra functions but it does not use
EXEC SQL statements but in the manual I did say I would consider adding
them if I got requests but I have not
Vincent, it would be nice if you add the EXEC SQL statements, i didn't know that you could change it if requested.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IissuedJimCurrey's pre-compiler with a lot of changes, thatdoes bothfixed and free format and has many extra functions but it does not useEXEC SQL statements but in the manual I did say I would consideraddingthem if I got requests but I have not
Vincent, it would be nice if you add the EXEC SQL statements, i didn't
know that you could change it if requested.
A comment to this effect is in place in the documentation of the JC
precompiler (which is in the contrib/tools area).
I will add it to my list of TODO's but you are the only one to request
it so far.
I will need user's to help supply (on request examples of pre-compiler
Cobol code that uses as many of the EXEC options as possible along with
the same as output from an existing pre compiler tool showing the
correct results for each.
The source does NOT need to be a fully working application only a method
to help test the pre compiler and may be check the generated code where
possible.
I cannot install a lot of different rdbms systems if I attempt to do
this for other O/S type rdbms systems i.e., not say for Oracle just in
case they get uppity :).
@Simon , can we have some extra functions for Bugs and Feature requests
for the Contrib area may be where a user can add a tool to the Group
section ?
That way we all can add items as at the moment there is no way to
provide such requests or Bug reporting.
Also can we clean up the lists of items shown for Bugs and features
where the list automatically ignores closed, won't fixed etc items for
all areas and Groups.
Vince.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I'm doing Oracle a mis-service. I thought I had the ProCOBOL package but it seems I only have some updates and that would be why there are no installation instructions. I need the CD-ROM which has the entire product including setup instructions but I'm unable to verify whether it works with MySQL. It's part of their "Additional tools and libraries".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I'm doing Oracle a mis-service. I thought I had the ProCOBOL
package but it seems I only have some updates and that would be why
there are no installation instructions. I need the CD-ROM which has
the entire product including setup instructions but I'm unable to
verify whether it works with MySQL. It's part of their "Additional
tools and libraries".
It comes with instantclient sub package but it does need the main
package as well.
There are some tweeks needed for running with GC.
.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Vince, when I was last coding in Cobol, we interacted with the DB via subroutines ie DBOpen, DBFind, DBGet, DBUpdate etc. Is this an appropriate route for GnuCobol to take?
I should also explain my interest in GnuCobol. It comes from a project I created to satify my retired person programming urges by converting a system I wrote a few years ago for a small company (AS2 under ColdFusion using Oracle MySQL db) to Cobol.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm only hinting now, as I have not yet read the documentation to try and complete an entry for the FAQ.
Ron added an option for extended SQL FD's (is that even the right terminology?) in GnuCOBOL.
New configure switch --with-odbc. Allows access to SQL relational datasets from READ/WRITE and xfd's.
I'm sadly talking on rumour here, as I haven't taken the time to setup a trial, and will repeat that this is all clueless reporting. Just reporting that there is news of a new feature for everyone that needs access to relational datasets, without need of a preprocessor (but there is an external layer to ODBC) so, some setup required, And source code directives. And... ??? Then, free and easy access to SQL via ODBC, from COBOL. I think, easy. :-)
I saw a thing, tried to wave poms poms, tried to figure out a few things, have yet to actually build the trial and can't back up the claims with a FAQ sample. Yet. Someone should, seems like a nifty power for READ/WRITE and SELECT/INSERT interop.
Have good,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
New configure switch --with-odbc. Allows access to SQL relational datasets from READ/WRITE and xfd's.
I'm on an "ODBC tour" with the esql tool from the contrib reposistory. I've had success with Microsoft SQL server and Postgres, using identical Cobol and table definitions. (SQL DBMSs differ on how databases and users are defined and created.)
I'll add --with-ODBC to my TODO list. If it works equally well, that would be one reason to release 3.2 later this year (provided 3.1 actually happens in June, as promised).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, please do so - but to not get a false impression: 3.2 (if we create it) won't have XFD+ODBC/OCI support, that's definitely a 4.0 feature (and yes, I plan to do a preview release for this one in 2020).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
New configure switch --with-odbc. Allows access to SQL relational
datasets from READ/WRITE and xfd's.
I'm on an "ODBC tour" with the |esql| tool from the contrib
reposistory. I've had success with Microsoft SQL server and Postgres,
using identical Cobol and table definitions. (SQL DBMSs differ on how
databases and users are defined and created.)
I'll add |--with-ODBC| to my TODO list. If it works equally well, that
would be one reason to release 3.2 later this year (provided 3.1
actually happens in June, as promised).
I will take that with a pinch of salt!
ODBC is ok for light usage but not much more as it has a heavy overhead
that makes it slow.
OK, for 1/2 users but beyond that, slow so for home use acceptable for
business not so.
Vince
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ODBC is ok for light usage but not much more as it has a heavy overhead that makes it slow.
Nonsense. If you have data to support that claim, I'll be happy to debunk it.
I have spent years in this space. I maintained FreeTDS for a decade. I studied every published DBMS wire protcocol. I wrote a C++ library to standardize database access, and examined a half-dozen others in detail first.
The overwhelming factor in performance for DBMS applications is database design and application design. Poor designs, corrected, frequently exhibit 1-3 orders of magnitude in improvement.
Sometimes, it's as simple as adding an index on the server. On the client, applications need to minimize trips to the server, and provide the maximum amount information, so as to minimize the amount returned.
(For those following along at home, an explanation. It's not always intuitively obvious why sending more information results in less being returned. The "more" sent makes the query more specific, meaning fewer rows qualify to be returned. It's the same difference as between ls
and ls *.doc.)
Once stupidity is eliminated, the second largest factor is I/O, both disk throughput and network bandwidth. I have seen database-loading applications limited by the speed of the network, and by the speed of the "disk" (which is really a storage stratum these days). If query performance on a well designed database is unacceptable, the perfect elixir is often RAM, and lots of it. RAM is what you need to sort, and sort is what a DBMS does, all the time.
Features outside the user's control are wire-protocol efficiency and driver efficiency. Both matter, but for major DBMS providers they have been pretty well optimized.
The "knock" on ODBC is that, as a wrapper, it introduces an extra level to the call stack. That's supposed to be inefficient. Against the above concerns, though, in terms of performance that extra layer is invisible,. Like so much about performance, the obvious turns out to be wrong.
Some vendors, notably IBM, adopted ODBC as their native client-library API. That means, first of all, that the "wrapper" argument isn't even true. Second, it means -- going back to application design -- that judicious use of block cursors can have an enormous impact on performance.
None of this means I admire ODBC. I don't. Some of it is terrible, some mediocre. Its biggest problem is complexity. Because it explicitly standardizes different DBMS prototocols and messages, the user is forced to know both the behavior & requirements of the underlying system, and ODBC's representation of it. It's a textbook example of Joel Spolsky's leaky abstractions.
ODBC also often "standardizes" by not standardizing. For example, SQLConnect connects to the DBMS. What identifies server and user? A veritable sublanguage, a bunch of name=value pairs, where the names and domains of the values are up to the driver. It's also often poorly documented, too, as in the case of Postgres ODBC, for example.
For the GnuCOBOL programer, that's only the beginning of his troubles. None of the mechanisms I have found for SQL access have any significant documentation. The embedded SQL preprocessors say nothing about the semantics. Talk about "lightweight"! How is a professional programmer expected to use something that doesn't begin to try to explain what it does?
I recently tried to help a poor soul understand an error message that I think was caused by misusing the connection to a Microsoft SQL Server. Is he allowed to use one connection for two queries in an overlapped fashion? He could be; that depends on whether it's using a "MARS" connection. Is it using a cursor? If so, is it a server-side or client-side cursor? Three guesses as to whether or not that was stated anywhere. Anywhere.
Every DBMS access framework (ORM, often) I've ever examined -- Ruby on Rails, Java hibernation, Python sqlalchemy, Microsoft's framework-of-the-week -- is simplistic. Every one ultimately interferes with exploiting the DBMS's capacity, often disasterously. By hiding SQL from the novice, they inevitably prevent the expert from exercising his ability.
I am sure the same shortcomings apply to esql; I just don't have proof yet. In time, we'll see what they are, and what can be done about it. Before we can do that, we have to know what they actually do. Meanwhile, one thing we know for sure is that the presence and performance of ODBC is the least of our concerns.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do we know of anyone using ProCOBOL for MySQL database on a Windows system? I've dowloaded the "package" from Oracle but there are no installation instructions and no setup.exe. The programmer's guide talks about the package coming with the universal installer which was not included in mine. Some guidance would be greatly appreciated as Oracle will tell me nothing unless I have a support agreement.
ProCobol is for Oracle or at least it has been and I have not seen any
announcements that it has been reworked to handle any other rdb.
As Mysql is another vendors product it could be considered unlikely but
there again . . .
On 02/06/2020 10:31, Alan Honeyman wrote:
Does Oracle claim procobol works with MySQL? (Documentation link would be welcome.)
The esql project in the contrib repository claims to work with MySQL, and there's a FAQ entry that, at least at one time, showed it to work.
I have tested esql with Microsoft's ODBC driver, and adapted the FAQ example to work with it. My work was done on Linux.
When you don't have support agreement, and the vendor offers no documentation, you're pretty much guaranteed to have better support for free software from the community. :-)
Bryan, MySQL is definately an Oracle product and the comprehensive ProCOBOL Programmer's Guide explains how it works with MySQL. James, I agree with your comment about the lack of installation documentation and I'll check out the esql project - thanks for the link.
Just been on the Oracle website but cannot find any references to
Pro*Cobol and MySQL.
That was looking at the PC manual and docs for MySQL.
Can you point me to the right docs ?
Vince
On 02/06/2020 15:56, Alan Honeyman wrote:
Oracle Pro*COBOL Precompiler is a programming tool that enables you to embed SQL statements in a host COBOL program. [...] the precompiler accepts the host program as input, translates the embedded SQL statements into standard Oracle run-time library calls, and generates a source program that you can compile, link, and execute in the usual way.
https://docs.oracle.com/en/database/oracle/oracle-database/20/lnpcb/introduction.html#GUID-1573627A-085C-42AD-9B99-8367167DEF24
Is this way of accessing Oracle's MySQL (or the non-Oracle version MariaDB) still an option ?
https://github.com/Martinfx/DBPRE/tree/master/Cobol
As far as I know the Pro*COBOL precompiler is only available for Oracle DB .
That's only a mirror, you find the actual project at https://sourceforge.net/projects/dbpre/; if you use the ODBC interface you should be able to use ESQL from contrib tree, too.
Vince, go to www.mysql.com and scroll to the very bottom of the page. For procobol, seach for "oracle pro*cobol" .
On 03/06/2020 01:08, Alan Honeyman wrote:
Did that and it doesn't.
As I thought Pro*Cobol is only for mysql or even mariadb.
As the pre-processor generates calls from SQL EXEC statement etc it
produces one's for MySQL there is no options for secondary systems.
Unless you KNOW better.
Hmm...the ProCobol Programmer's Guide doesn't say whether does or doesn't support it. Certainly, MySQL is not listed in the Index. I guess I was assuming that all Oracle DB's would be supported.
https://github.com/Martinfx/DBPRE/tree/master/Cobol looks interesting but currently set up for use on linux.
I asked The Piper about using DBPRE on windows and got the following reply:
I havent compiled it for Windows, but using Bloodshed's Dev-Cpp to
compile it, might be a solution.
https://www.bloodshed.net/devcpp.html
With that you can compile unix sourcecode for windows, so no need to do windows related changes.
I have tried it for some other stuff, it might work for dbpre too.
Last edit: Alan Honeyman 2020-06-04
On 03/06/2020 06:48, Alan Honeyman wrote:
DBPre was announced over 2 years ago and it is in the contrib area some
where.
How ever there are issues with it other than it is no longer supported.
One I remember is that it only supports Fixed Cobol sources and has
limited functionality.
This tool is written in C.
I issued Jim Currey's pre-compiler with a lot of changes, that does both
fixed and free format and has many extra functions but it does not use
EXEC SQL statements but in the manual I did say I would consider adding
them if I got requests but I have not.
I use it in the ACAS O/S accounting software that is also on SF and
nightly builds via my site.
This processor will work on any platform that supports GnuCobol compiler
as it is written in Cobol.
It is available from the contrib Tools area.
Vincent, it would be nice if you add the EXEC SQL statements, i didn't know that you could change it if requested.
On 03/06/2020 18:14, thom wrote:
I will add it to my list of TODO's but you are the only one to request
it so far.
I will need user's to help supply (on request examples of pre-compiler
Cobol code that uses as many of the EXEC options as possible along with
the same as output from an existing pre compiler tool showing the
correct results for each.
The source does NOT need to be a fully working application only a method
to help test the pre compiler and may be check the generated code where
possible.
I cannot install a lot of different rdbms systems if I attempt to do
this for other O/S type rdbms systems i.e., not say for Oracle just in
case they get uppity :).
@Simon , can we have some extra functions for Bugs and Feature requests
for the Contrib area may be where a user can add a tool to the Group
section ?
That way we all can add items as at the moment there is no way to
provide such requests or Bug reporting.
Also can we clean up the lists of items shown for Bugs and features
where the list automatically ignores closed, won't fixed etc items for
all areas and Groups.
Vince.
Comment from the_piper:
I havent compiled it for Windows, but using Bloodshed's Dev-Cpp to
compile it, might be a solution.
https://www.bloodshed.net/devcpp.html
With that you can compile unix sourcecode for windows, so no need to do windows related changes.
I have tried it for some other stuff, it might work for dbpre too.
OK, I'm doing Oracle a mis-service. I thought I had the ProCOBOL package but it seems I only have some updates and that would be why there are no installation instructions. I need the CD-ROM which has the entire product including setup instructions but I'm unable to verify whether it works with MySQL. It's part of their "Additional tools and libraries".
On 03/06/2020 08:26, Alan Honeyman wrote:
It comes with instantclient sub package but it does need the main
package as well.
There are some tweeks needed for running with GC.
.
Vince, when I was last coding in Cobol, we interacted with the DB via subroutines ie DBOpen, DBFind, DBGet, DBUpdate etc. Is this an appropriate route for GnuCobol to take?
I should also explain my interest in GnuCobol. It comes from a project I created to satify my retired person programming urges by converting a system I wrote a few years ago for a small company (AS2 under ColdFusion using Oracle MySQL db) to Cobol.
I'm only hinting now, as I have not yet read the documentation to try and complete an entry for the FAQ.
Ron added an option for extended SQL FD's (is that even the right terminology?) in GnuCOBOL.
New configure switch
--with-odbc. Allows access to SQL relational datasets from READ/WRITE and xfd's.I'm sadly talking on rumour here, as I haven't taken the time to setup a trial, and will repeat that this is all clueless reporting. Just reporting that there is news of a new feature for everyone that needs access to relational datasets, without need of a preprocessor (but there is an external layer to ODBC) so, some setup required, And source code directives. And... ??? Then, free and easy access to SQL via ODBC, from COBOL. I think, easy. :-)
https://sourceforge.net/p/open-cobol/discussion/cobol/thread/7dc2941f/?page=4&limit=25#62ac
I saw a thing, tried to wave poms poms, tried to figure out a few things, have yet to actually build the trial and can't back up the claims with a FAQ sample. Yet. Someone should, seems like a nifty power for READ/WRITE and SELECT/INSERT interop.
Have good,
Blue
I'm on an "ODBC tour" with the
esqltool from the contrib reposistory. I've had success with Microsoft SQL server and Postgres, using identical Cobol and table definitions. (SQL DBMSs differ on how databases and users are defined and created.)I'll add
--with-ODBCto my TODO list. If it works equally well, that would be one reason to release 3.2 later this year (provided 3.1 actually happens in June, as promised).Yes, please do so - but to not get a false impression: 3.2 (if we create it) won't have XFD+ODBC/OCI support, that's definitely a 4.0 feature (and yes, I plan to do a preview release for this one in 2020).
Please provide the findings of your "ODBC tour" with ESQL. Maybe start with a topic here in the contributions board and update it along the way?
On 04/06/2020 15:34, James K. Lowden wrote:
ODBC is ok for light usage but not much more as it has a heavy overhead
that makes it slow.
OK, for 1/2 users but beyond that, slow so for home use acceptable for
business not so.
Vince
Nonsense. If you have data to support that claim, I'll be happy to debunk it.
I have spent years in this space. I maintained FreeTDS for a decade. I studied every published DBMS wire protcocol. I wrote a C++ library to standardize database access, and examined a half-dozen others in detail first.
The overwhelming factor in performance for DBMS applications is database design and application design. Poor designs, corrected, frequently exhibit 1-3 orders of magnitude in improvement.
Sometimes, it's as simple as adding an index on the server. On the client, applications need to minimize trips to the server, and provide the maximum amount information, so as to minimize the amount returned.
(For those following along at home, an explanation. It's not always intuitively obvious why sending more information results in less being returned. The "more" sent makes the query more specific, meaning fewer rows qualify to be returned. It's the same difference as between
lsand
ls *.doc.)Once stupidity is eliminated, the second largest factor is I/O, both disk throughput and network bandwidth. I have seen database-loading applications limited by the speed of the network, and by the speed of the "disk" (which is really a storage stratum these days). If query performance on a well designed database is unacceptable, the perfect elixir is often RAM, and lots of it. RAM is what you need to sort, and sort is what a DBMS does, all the time.
Features outside the user's control are wire-protocol efficiency and driver efficiency. Both matter, but for major DBMS providers they have been pretty well optimized.
The "knock" on ODBC is that, as a wrapper, it introduces an extra level to the call stack. That's supposed to be inefficient. Against the above concerns, though, in terms of performance that extra layer is invisible,. Like so much about performance, the obvious turns out to be wrong.
Some vendors, notably IBM, adopted ODBC as their native client-library API. That means, first of all, that the "wrapper" argument isn't even true. Second, it means -- going back to application design -- that judicious use of block cursors can have an enormous impact on performance.
None of this means I admire ODBC. I don't. Some of it is terrible, some mediocre. Its biggest problem is complexity. Because it explicitly standardizes different DBMS prototocols and messages, the user is forced to know both the behavior & requirements of the underlying system, and ODBC's representation of it. It's a textbook example of Joel Spolsky's leaky abstractions.
ODBC also often "standardizes" by not standardizing. For example,
SQLConnectconnects to the DBMS. What identifies server and user? A veritable sublanguage, a bunch ofname=valuepairs, where the names and domains of the values are up to the driver. It's also often poorly documented, too, as in the case of Postgres ODBC, for example.For the GnuCOBOL programer, that's only the beginning of his troubles. None of the mechanisms I have found for SQL access have any significant documentation. The embedded SQL preprocessors say nothing about the semantics. Talk about "lightweight"! How is a professional programmer expected to use something that doesn't begin to try to explain what it does?
I recently tried to help a poor soul understand an error message that I think was caused by misusing the connection to a Microsoft SQL Server. Is he allowed to use one connection for two queries in an overlapped fashion? He could be; that depends on whether it's using a "MARS" connection. Is it using a cursor? If so, is it a server-side or client-side cursor? Three guesses as to whether or not that was stated anywhere. Anywhere.
Every DBMS access framework (ORM, often) I've ever examined -- Ruby on Rails, Java hibernation, Python sqlalchemy, Microsoft's framework-of-the-week -- is simplistic. Every one ultimately interferes with exploiting the DBMS's capacity, often disasterously. By hiding SQL from the novice, they inevitably prevent the expert from exercising his ability.
I am sure the same shortcomings apply to
esql; I just don't have proof yet. In time, we'll see what they are, and what can be done about it. Before we can do that, we have to know what they actually do. Meanwhile, one thing we know for sure is that the presence and performance of ODBC is the least of our concerns.