As it is mine it better not as I have not deleted it.
That program reads in the source file of one or more programs applying the copy books and then creating an updated source file.
The same code is used in cobxref, my cross referencing program and this actually produces a source file with extension of .pro.
Both are in the contrib area as well as in SF in their own right. Well cobxref is forgotten about the other - I do seem to have a number of programs and systems on it.
Last edit: Simon Sobisch 2021-01-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, did not jump out at me but looking at the source I can see it
follows COBCPY environment variable.
Still curious if EXEC SQL INCLUDE is an option for expansion.
As is no and there are reasons for this
Mostly EXEC etc uses a pre-processor which may well also do COPY
expansions but is totally DB specific.
I did consider linking it to a revisited version of the dbpre tool
having adjusted it to not only work for MySQL but Postgres and a few
others subject to params etc but just do not have the time at the moment.
Another option was to allow a link to run a pre-compiler before
finishing etc.
That might well work with a small amount of effort.
At the moment I just run it through printcbl then through a pre compiler
or more depending if there is a CICS element as well.
Vince
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mr. Coen would there be an easy to use link to find cobxref.
Search is not very friendly in finding cobxref.
The closest I could find was: https://sourceforge.net/p/gnucobol/contrib/472
But that seems to be dated 2017
Any help would be appreciated.
Thanks,
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
red, have you tried the -t filename.lst option.
The -t will put a pgm listing in whatever you call filename.lst
It does list the unsuppressed copybook, not sure about SQL..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The -t option really doesn't do it as it is a print listing, headers, footers, pages.
I am just trying to get to an expanded source listing ready for translation and db prep.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-01-05
DB2PREP requires the 64 bit version of GnuCOBOL. In addition you must us the Visual Studio "C" compiler. See: https://sourceforge.net/p/gnucobol/bugs/673/. Done numerous attempts to work with DB2PREP and the 32 bit Windows GnuCOBOL. Never was successful. Using community version of DB2 (aka DB2 Express)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to [bugs:#673] (see at the end) you can also use the GCC-based 64bit version provided by Arnold and also use the 32bit version, as long as you tell cobc to link the 32bit libraries and include the db2 headers instead of letting cobc "guess" what the function header looks like.
Can you please verify this?
You can limit the amount of listing output by the -ft... flags. cobc -T --tlines=0 -fno-theaders -fno-tmessages; but cobc doesn't handle EXEC SQL INCLUDE as all EXEC explicit should be handled by an (external) proprocessor.
Isn't the common way of doing this: dbpep, then cobc?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
here is a copy of an email I sent to bug #678. Testing was done with the Community version 11.5.4 of DB2. This testing was done mid September 2020. There have been a number of changes to the GnuCOBOL compiler where perhaps it is worth testing this again. However the two bugs #673 & #678 are still open so I would defer to Simon as to whether it is worth setting up the tests again.
I've done some additional testing.
The DB2 precompiler can generate COBOL code for a number of different dialects. I've tested with the following
db2 prep deletx.sqb bindfile target ANSI_COBOL --> this generates the calls as "CALL "sqlg" where sqlg is the DB2 module
db2 prep deletx.sqb bindfile target mfcob --> this generates the calls as "CALL DB2API"sqlg" where sqlg is the DB2 module and DB2API is set to CALL-CONVENTION 74.
for testing purposes I changed the DB2API value to 64 so that I could control static vs dynamic via compile time parameters.
So each version of the compiler has 4 variations mfcob or ANSI_COBOL and static or dynamic calls.
So there is a difference between the MinGW and Visual Studio versions of the GNUCOBOL compiler. The differences only are present when using static calls to the DB2 modules.
That being said, perhaps it's not worth pursuing why these differences exist. So if someone wants to mark this ticket as closed that would be ok with me.
Perhaps the issue with the prototype not including the parameters used in the CALL statement could potentially impact other applications which link to libraries created with MSVC, so that might we worth investigating.
Also the DB2 precompiler has an option to use "TARGET ibmcob". It generates the same output as ANSI_COBOL so no need to test that.
Chuck Haatvedt
Last edit: Simon Sobisch 2021-01-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm, I don't see that mail in one of the tickets... so I comment here.
So there is a difference between the MinGW and Visual Studio versions of the GNUCOBOL compiler.
No, the difference is in the C compiler and linker (gcc+ld vs. cl+link) and how they handle undefined stuff.
The "undefined" part here is increased because of [bugs:#678] which I did not found the time to inspect (possibly should be able to do so, sooner).
But you should be able to remove the undefined part completely by doing:
cobc -fno-gen-c-decl-static-call -A "-include C/header/file.h"
Which then leaves the 32bit failure - this should be solved by telling the compiler to use the 32bit libraries and for the dynamic part also ensure to have the 32bit libraries in COB_LIBRARY_PATH.
Simon what would the cobc command line look like to use DB2PREP for use with Arnold's 32 bit package ? Would your command line options support successful compile, link, and execution ? Please advise, I would like to re-visit using DB2PREP.
Thanks,
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that should work as long as you force-include the db2 "C" headers and specify the correct -L option(s) for the 32bit libraries - but I haven't tested that myself yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there an option to get an expanded source listing where all the COPY and EXEC SQL INCLUDE statements are resolved and expanded?
I'd like to work with precompilers and translators for DB2 and TXseries (CICS) and this would be very helpful to me.
I see mentions of printcbl.cbl in the contribs at some point but this seems to have disappeared.
Thanks.
As it is mine it better not as I have not deleted it.
That program reads in the source file of one or more programs applying the copy books and then creating an updated source file.
The same code is used in cobxref, my cross referencing program and this actually produces a source file with extension of .pro.
Both are in the contrib area as well as in SF in their own right. Well cobxref is forgotten about the other - I do seem to have a number of programs and systems on it.
Last edit: Simon Sobisch 2021-01-06
Is printcbl there? I could not find it.
Hi, I was able to find it and compile it.
Thanks for any assistance.
Last edit: red 2021-01-05
Have you read the included manual & documents ?
Last edit: Simon Sobisch 2021-01-06
Yes, did not jump out at me but looking at the source I can see it follows COBCPY environment variable.
Still curious if EXEC SQL INCLUDE is an option for expansion.
On 05/01/2021 14:49, red wrote:
As is no and there are reasons for this
Mostly EXEC etc uses a pre-processor which may well also do COPY
expansions but is totally DB specific.
I did consider linking it to a revisited version of the dbpre tool
having adjusted it to not only work for MySQL but Postgres and a few
others subject to params etc but just do not have the time at the moment.
Another option was to allow a link to run a pre-compiler before
finishing etc.
That might well work with a small amount of effort.
At the moment I just run it through printcbl then through a pre compiler
or more depending if there is a CICS element as well.
Vince
Mr. Coen would there be an easy to use link to find cobxref.
Search is not very friendly in finding cobxref.
The closest I could find was:
https://sourceforge.net/p/gnucobol/contrib/472
But that seems to be dated 2017
Any help would be appreciated.
Thanks,
Ralph
https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/cobxref/
https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/printcbl/
There is two :
In contribs :
https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/cobxref/
The .zip file is an older version so I will update or remove it today.
So use the other files.
The full product as a Project as it is :
https://sourceforge.net/projects/cobxref/files/
You want the archive file who's name starts with cobxref-
[ The one's starting with MVS is only for that platform, system and
Cobol compiler version. ]
Vince
On 06/01/2021 04:14, Ralph Linkletter wrote:
@vcoen Do you see a reason to keep an archive in svn?
Background for my question: If one visits https://sourceforge.net/p/gnucobol/contrib/887/tree/trunk/tools/cobxref/ and then clicks on "Download Snaphot" one gets an archive already (which currently contains the uploaded archive).
Done, thanks for the prompt :)
On 06/01/2021 15:09, Simon Sobisch wrote:
red, have you tried the -t filename.lst option.
The -t will put a pgm listing in whatever you call filename.lst
It does list the unsuppressed copybook, not sure about SQL..
The -t option really doesn't do it as it is a print listing, headers, footers, pages.
I am just trying to get to an expanded source listing ready for translation and db prep.
DB2PREP requires the 64 bit version of GnuCOBOL. In addition you must us the Visual Studio "C" compiler. See: https://sourceforge.net/p/gnucobol/bugs/673/. Done numerous attempts to work with DB2PREP and the 32 bit Windows GnuCOBOL. Never was successful. Using community version of DB2 (aka DB2 Express)
According to [bugs:#673] (see at the end) you can also use the GCC-based 64bit version provided by Arnold and also use the 32bit version, as long as you tell cobc to link the 32bit libraries and include the db2 headers instead of letting cobc "guess" what the function header looks like.
Can you please verify this?
Related
Bugs: #673
You can limit the amount of listing output by the
-ft...flags.cobc -T --tlines=0 -fno-theaders -fno-tmessages; but cobc doesn't handleEXEC SQL INCLUDEas allEXECexplicit should be handled by an (external) proprocessor.Isn't the common way of doing this: dbpep, then cobc?
here is a copy of an email I sent to bug #678. Testing was done with the Community version 11.5.4 of DB2. This testing was done mid September 2020. There have been a number of changes to the GnuCOBOL compiler where perhaps it is worth testing this again. However the two bugs #673 & #678 are still open so I would defer to Simon as to whether it is worth setting up the tests again.
I've done some additional testing.
The DB2 precompiler can generate COBOL code for a number of different dialects. I've tested with the following
db2 prep deletx.sqb bindfile target ANSI_COBOL --> this generates the calls as "CALL "sqlg" where sqlg is the DB2 module
db2 prep deletx.sqb bindfile target mfcob --> this generates the calls as "CALL DB2API"sqlg" where sqlg is the DB2 module and DB2API is set to CALL-CONVENTION 74.
for testing purposes I changed the DB2API value to 64 so that I could control static vs dynamic via compile time parameters.
So each version of the compiler has 4 variations mfcob or ANSI_COBOL and static or dynamic calls.
So there is a difference between the MinGW and Visual Studio versions of the GNUCOBOL compiler. The differences only are present when using static calls to the DB2 modules.
That being said, perhaps it's not worth pursuing why these differences exist. So if someone wants to mark this ticket as closed that would be ok with me.
Perhaps the issue with the prototype not including the parameters used in the CALL statement could potentially impact other applications which link to libraries created with MSVC, so that might we worth investigating.
Also the DB2 precompiler has an option to use "TARGET ibmcob". It generates the same output as ANSI_COBOL so no need to test that.
Chuck Haatvedt
Last edit: Simon Sobisch 2021-01-05
Hm, I don't see that mail in one of the tickets... so I comment here.
No, the difference is in the C compiler and linker (gcc+ld vs. cl+link) and how they handle undefined stuff.
The "undefined" part here is increased because of [bugs:#678] which I did not found the time to inspect (possibly should be able to do so, sooner).
But you should be able to remove the undefined part completely by doing:
cobc -fno-gen-c-decl-static-call -A "-include C/header/file.h"Which then leaves the 32bit failure - this should be solved by telling the compiler to use the 32bit libraries and for the dynamic part also ensure to have the 32bit libraries in
COB_LIBRARY_PATH.Related
Bugs: #678
Simon what would the cobc command line look like to use DB2PREP for use with Arnold's 32 bit package ? Would your command line options support successful compile, link, and execution ? Please advise, I would like to re-visit using DB2PREP.
Thanks,
Ralph
I think that should work as long as you force-include the db2 "C" headers and specify the correct
-Loption(s) for the 32bit libraries - but I haven't tested that myself yet.