I am trying to migrate a COBOL application from 32-bit AIX & Micro Focus COBOL => 64-bit Linux & GNUCobol. I am pleasantly surprised by how easy GNUCobol has made this so far! Our setup is:
App gets precompiled by Oracle's Pro*COBOL Precompiler.
App gets compiled by COBOL compiler. Previously Micro Focus COBOL, now GNUCobol.
App gets run with Oracle's rtsora <application>. But upon doing so on the new Linux machine I get this error:
Because compilation is correctly happening and the error only seems to happen when running rtsora, I think my question is technically not related to GNUCobol itself, but that rtsora cannot run because it is missing a shared library (maybe multiple libraries).
Because of OS & 32-bit vs. 64-bit differences, our new setup also involves a newer Oracle client version. I see some Oracle docs about relinking precompiler executables, but I don't see any file named libcobrts* on my system at all. So I'm not sure if relinking alone will fix things. I also think the bug is not about setting LD_LIBRARY_PATH/LIBPATH - instead it's about finding and downloading the library. Curious if y'all think I am on the right track so far.
Is there any way to get this shared library from GNUCobol? Would this file need to come from a Micro Focus server installation? One of the big draws of moving to GNUCobol is to avoid needing to pay for runtime libraries. This thread suggests COBOL-IT may also work?
Would appreciate any pointers that people have! Excited of the prospect of being able to use GnuCOBOL.
Last edit: Golf Sinteppadon 2023-03-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Micro Focus Visual COBOL 2.2 is mentioned here, along with MicroFocus Server Express here. This leads me to believe that I'd need to still purchase something from Micro Focus. I am hoping there could be some way to get this setup without needing to purchase Micro Focus software but I'm not sure if that's realistic
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-12-05
il faut passer par relink de rtsora
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
to see just where it is BUT you will need to include this lib into the compiled programs at time of - yep, compiling. Have to do the same for mysql libs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just one note: instead of including this on any compile you may opt to use COB_PRE_LOAD instead; but the most likely issue here is that you should place this file into LD_LIBRARY_PATH when running.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Totally, it is an os-specific separated list (: for everything but DOS/Windows which uses ;), similar to COB_LIBRARY_PATH (where you need to add the path of the library to preload, if you don't symlink it into one that already is in).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, I have my cobol dynamic objects collected in mw.so I have this defined export COB_PRE_LOAD=$HOME/lib/mwoc.soThe lib only has one .SO in it. SO does COB_PRE_LOAD point to libraries or specific .SO's ? If just libraires then I don't need the specific .SO?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It appears that it is modules. and not at the library level. So if true? I should use LD_LIBRARY_PATH for whole libraries but still keep Pre-Load fro my cbl SO ?
I guess if you have many modules in other .SO's the LD is the way to go?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sadly sudo find / -iname "libcobrts64_t.*" does not find anything on my system. I think that is the crux of my issue which is that I'm not sure where it should come from. Googling around shows Micro Focus Visual COBOL 2.2 is mentioned here, along with MicroFocus Server Express here. I am hoping it is possible to get this file in a way that does not involve not purchasing new Micro Focus software.
I tried installing our very old versions of (from the 90's) Micro Focus Object Cobol and Micro Focus Application Server, but those did not seem to populate this file either
Last edit: Golf Sinteppadon 2023-03-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You do NOT need anything other than gnuCobol and the libraries and packages for Oracle and do not forget the devel elements for Oracle and this is possibly where the missing lib is.
Sorry it has been a few years since I did any Cobol, gnuCobol and Oracle, but I still have the demo program I used to test the installation. prog nane is procobdemo.cob
I think this was supplied with the Oracle package,.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-03-15
Good to hear you think it should be from Oracle. I think I've gone through every download in Oracle's downloads page, including the development section, but I do not see any libcobrts*.
I do notice now that Oracle providse a procobdemo.pco demo program in their "Precompiler package", which I think is the file you are mentioning. I will find time to try this out to see if I run into the same issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just taken a look at the download section at oracle and downloaded the instantclient zip file for precob and ask if you READ the readme file (PRECOMP_README) included (as well as any in the base package and followed them. I grabbed 12.1
I did not get the latest as they need specific versions of glib and others? and as I am running Mageia v8 have to assume that 'the' latest is not in use here.
Again when I tested Oracle against gnucobol some time ago, like 3-4 years ago I was able to run Cobol source through precob and then build the demo program and then run it having built any tables needed following the readme type files.
I did create a sample DAL for my ACAS system and created a table and run it successfully but limited within the Cobol code created - it was only a basic test to prove do-able.
In the end I decided not to continue with building a version of the DAL's for Oracle as no one has asked for it and my time is somewhat limited for doing unneeded prototyping of DAL objects etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rechecked:
precompile with procob then link with cobc -L$ORACLE_HOME/lib -Q -Wl,--no-as-needed $ORACLE_HOME/precomp/lib/cobsqlintf.o -lclntsh yourprog.cob should work fine.
To execute that later you either have to have $ORACLE_HOME/lib in LD_LIBRARY_PATH or additional pass -Q -Wl,-rpath=$ORACLE_HOME/lib(but in this case you need to recompile when changing the Oracle version).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@minigolf2000 Did you solve this issue? As noted: you don't need any rtsora, that's a linked Micromocus runtime that needs the matching libraries and licenses.
Either link an "cobrunora" to match that old one or link each program with the libraries as mentioned above (most reasonable for a quick check/start), or create a wrapper library with this link that you place into COB_PRE_LOAD and use cobcrun (or the executable binaries) as without Oracle.
Side note: my employer has migrated from AIX and Solaris using Microfocus and Oracle Pro*COBOL to GNU/Linux and GnuCOBOL and Pro*COBOL - works quite well (but faster ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We had previously purchased Manhattan Associates' COBOL warehouse management system, so LOC was enormous, I'm guessing over 1 million (most of it having been written by Manhattan Associates)? We attempted to port this to GnuCOBOL, but eventually decided to completely rewrite the application in Ruby/Sinatra/Typescript. It was a lengthy project but are happy with the results so far, given how our company uses it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the information and nice to hear that you found a solution, even when it was to get out COBOL completely.
That rewrite would be an interesting free software donation, just something to think about.
Does your original purchase allow to resale that? If yes I'd be interesting in buying it for 1USD to check and work on GnuCOBOL's migration capabilities.
Please check that and send me a note to my @gnu mail address (seen in any Changelog).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello @sf-mensch unfortunately the original purchase does not allow resale. Manhattan Associates' also has a newer version of this software called WMS
Wrt our rewrite, as-is our new software is quite specific to us. I do wish it were generalizable, but there are just many many potential warehouse management features in the world. We only use a tiny subset, and that subset is heavily tailored to our use case.
I've heard that usually when warehouse management software is purchased there is quite significant integration cost, involving heavy customization and involving consultants to write code. Even the warehouse down the road has a completely different setup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying to migrate a COBOL application from 32-bit AIX & Micro Focus COBOL => 64-bit Linux & GNUCobol. I am pleasantly surprised by how easy GNUCobol has made this so far! Our setup is:
rtsora <application>. But upon doing so on the new Linux machine I get this error:How do I fix this error?
Because compilation is correctly happening and the error only seems to happen when running rtsora, I think my question is technically not related to GNUCobol itself, but that rtsora cannot run because it is missing a shared library (maybe multiple libraries).
Because of OS & 32-bit vs. 64-bit differences, our new setup also involves a newer Oracle client version. I see some Oracle docs about relinking precompiler executables, but I don't see any file named libcobrts* on my system at all. So I'm not sure if relinking alone will fix things. I also think the bug is not about setting
LD_LIBRARY_PATH/LIBPATH- instead it's about finding and downloading the library. Curious if y'all think I am on the right track so far.Is there any way to get this shared library from GNUCobol? Would this file need to come from a Micro Focus server installation? One of the big draws of moving to GNUCobol is to avoid needing to pay for runtime libraries. This thread suggests COBOL-IT may also work?
Would appreciate any pointers that people have! Excited of the prospect of being able to use GnuCOBOL.
Last edit: Golf Sinteppadon 2023-03-06
Did google search bring any places that the libcobrts64_t.so.3 exists ?
Micro Focus Visual COBOL 2.2 is mentioned here, along with MicroFocus Server Express here. This leads me to believe that I'd need to still purchase something from Micro Focus. I am hoping there could be some way to get this setup without needing to purchase Micro Focus software but I'm not sure if that's realistic
il faut passer par relink de rtsora
Do sudo find / -iname "libcobrts64_t.*"
to see just where it is BUT you will need to include this lib into the compiled programs at time of - yep, compiling. Have to do the same for mysql libs.
Just one note: instead of including this on any compile you may opt to use
COB_PRE_LOADinstead; but the most likely issue here is that you should place this file intoLD_LIBRARY_PATHwhen running.Can you have more than one Object or Library in COB_PRE_LOAD ? As that is where I have my .SO for my Dynamic Called Library.
Totally, it is an os-specific separated list (
:for everything but DOS/Windows which uses;), similar toCOB_LIBRARY_PATH(where you need to add the path of the library to preload, if you don't symlink it into one that already is in).So, I have my cobol dynamic objects collected in mw.so I have this defined
export COB_PRE_LOAD=$HOME/lib/mwoc.soThe lib only has one .SO in it. SO does COB_PRE_LOAD point to libraries or specific .SO's ? If just libraires then I don't need the specific .SO?What is your answer to that question if you look at https://sourceforge.net/p/gnucobol/code/HEAD/tree/tags/gnucobol-3.1.2/config/runtime.cfg#l188 ?
It appears that it is modules. and not at the library level. So if true? I should use LD_LIBRARY_PATH for whole libraries but still keep Pre-Load fro my cbl SO ?
I guess if you have many modules in other .SO's the LD is the way to go?
So can i load other modules in different libraries with pre-load ? like
export COB_PRE_LOAD=/home/mickeyw/lib/mwoc.so:/home/otherlib/othr.soDo sudo find / -iname "libcobrts64_t.*"
If you find the library libcobrts64_t.so.2 you can make soft link
ln -s libcobrts64_t.so.2 libcobrts64_t.so.3
Sadly
sudo find / -iname "libcobrts64_t.*"does not find anything on my system. I think that is the crux of my issue which is that I'm not sure where it should come from. Googling around shows Micro Focus Visual COBOL 2.2 is mentioned here, along with MicroFocus Server Express here. I am hoping it is possible to get this file in a way that does not involve not purchasing new Micro Focus software.I tried installing our very old versions of (from the 90's) Micro Focus Object Cobol and Micro Focus Application Server, but those did not seem to populate this file either
Last edit: Golf Sinteppadon 2023-03-15
You do NOT need anything other than gnuCobol and the libraries and packages for Oracle and do not forget the devel elements for Oracle and this is possibly where the missing lib is.
Sorry it has been a few years since I did any Cobol, gnuCobol and Oracle, but I still have the demo program I used to test the installation. prog nane is procobdemo.cob
I think this was supplied with the Oracle package,.
Good to hear you think it should be from Oracle. I think I've gone through every download in Oracle's downloads page, including the development section, but I do not see any libcobrts*.
I do notice now that Oracle providse a procobdemo.pco demo program in their "Precompiler package", which I think is the file you are mentioning. I will find time to try this out to see if I run into the same issue.
I have just taken a look at the download section at oracle and downloaded the instantclient zip file for precob and ask if you READ the readme file (PRECOMP_README) included (as well as any in the base package and followed them. I grabbed 12.1
I did not get the latest as they need specific versions of glib and others? and as I am running Mageia v8 have to assume that 'the' latest is not in use here.
Again when I tested Oracle against gnucobol some time ago, like 3-4 years ago I was able to run Cobol source through precob and then build the demo program and then run it having built any tables needed following the readme type files.
I did create a sample DAL for my ACAS system and created a table and run it successfully but limited within the Cobol code created - it was only a basic test to prove do-able.
In the end I decided not to continue with building a version of the DAL's for Oracle as no one has asked for it and my time is somewhat limited for doing unneeded prototyping of DAL objects etc.
Rechecked:
precompile with procob then link with
cobc -L$ORACLE_HOME/lib -Q -Wl,--no-as-needed $ORACLE_HOME/precomp/lib/cobsqlintf.o -lclntsh yourprog.cobshould work fine.To execute that later you either have to have
$ORACLE_HOME/libinLD_LIBRARY_PATHor additional pass-Q -Wl,-rpath=$ORACLE_HOME/lib(but in this case you need to recompile when changing the Oracle version).@minigolf2000 Did you solve this issue? As noted: you don't need any rtsora, that's a linked Micromocus runtime that needs the matching libraries and licenses.
Either link an "cobrunora" to match that old one or link each program with the libraries as mentioned above (most reasonable for a quick check/start), or create a wrapper library with this link that you place into
COB_PRE_LOADand usecobcrun(or the executable binaries) as without Oracle.Side note: my employer has migrated from AIX and Solaris using Microfocus and Oracle Pro*COBOL to GNU/Linux and GnuCOBOL and Pro*COBOL - works quite well (but faster ;-)
Hello, thanks for the response. We ended up rewriting our application instead of doing GnuCOBOL.
So you've gone from COBOL to ??? How much LOC did your COBOL application had?
Hi Simon,
We had previously purchased Manhattan Associates' COBOL warehouse management system, so LOC was enormous, I'm guessing over 1 million (most of it having been written by Manhattan Associates)? We attempted to port this to GnuCOBOL, but eventually decided to completely rewrite the application in Ruby/Sinatra/Typescript. It was a lengthy project but are happy with the results so far, given how our company uses it.
Thank you for the information and nice to hear that you found a solution, even when it was to get out COBOL completely.
That rewrite would be an interesting free software donation, just something to think about.
Does your original purchase allow to resale that? If yes I'd be interesting in buying it for 1USD to check and work on GnuCOBOL's migration capabilities.
Please check that and send me a note to my @gnu mail address (seen in any Changelog).
Hello @sf-mensch unfortunately the original purchase does not allow resale. Manhattan Associates' also has a newer version of this software called WMS
Wrt our rewrite, as-is our new software is quite specific to us. I do wish it were generalizable, but there are just many many potential warehouse management features in the world. We only use a tiny subset, and that subset is heavily tailored to our use case.
I've heard that usually when warehouse management software is purchased there is quite significant integration cost, involving heavy customization and involving consultants to write code. Even the warehouse down the road has a completely different setup.
Thanks for checking (not: the idea was not about using the possible result, it was only about working on free software).