TEST.exe is a medium size program testing routines for ACCEPT compatibility and doing RM CONVERT functions. It executes properly as /usr/nova/objc/TEST.exe in my testing of many program changes and iterations. It is compiled -x.
I get the not found error with cobcrun TEST.exe, with using the full path, with just TEST and many variations. cobcrun -r shows the objc path both places ($LD_..., $COB_L...). It is also in $PATH.
I started a topic because the other similar problems are all CALL's and did not seem to help me. I know it is my novice capability in C compile and execution. I'm very impressed with your various COBOL language provisions/compatibilities. I don't understand why cobcrun can't find a full path executable. Please advise me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
TEST.exe is a medium size program testing routines for ACCEPT
compatibility and doing RM CONVERT functions. It executes properly as
/usr/nova/objc/TEST.exe in my testing of many program changes and
iterations. It is compiled -x.
I get the not found error with |cobcrun TEST.exe|, with using the full
path, with just TEST and many variations. |cobcrun -r| shows the objc
path both places ($LD_..., $COB_L...). It is also in $PATH.
I started a topic because the other similar problems are all CALL's
and did not seem to help me. I know it is my novice capability in C
compile and execution. I'm very impressed with your various COBOL
language provisions/compatibilities. I don't understand why cobcrun
can't find a full path executable. Please advise me.
If you built the program as cobc -x test.cbl etc then just run :
./test
OR
cobc -xj test.cbl
compile and runs
IF there are args for test just add them at the end of the line.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you so much for your two replies. I do understand -x main vs. -m subprograms and why ./TEST works. I understand static vs. dynamic linking and only want to do dynamic linking. I execute several good-sized test programs successfully now. I'm very impressed with GNU COBOL features.
But I am still a newbie in GNU and C. i do Unix/Linux only, COBOL's only, for 50 plus years. My company wrote and sold financial "enterprise" systems for credit unions. I am converting a suite of my RM COBOL command line utilities to GNU. Most of my work has been with ACCEPT because of CONVERT and because it doesn't do COL 0 or otherwise default to the last screen position. I've handled that. I ask:
1. Do I really need cobcrun for linking or any other reason?
2. Do the extensions .cob, .exe, etc. have significance in my situation?
3. Even if I don't need cobcrun the "not found" error still exists and puzzles me. In my initial tests of linking I get it there too. Again, I think it is a basic newbie lack of knowledge. I have listed my cobcrun -r output attached.
Your COB_LIBRARY_PATH is quite big and contains system library paths.
As a rule of thumb: when linking explicit against a library cobc -llibname then you often want to do "static linking" of the libraries' entry points, either with CALL STATIC "libentrypoint" or with cobc -K libentrypoint or "all literals" with cobc --static; you then use the system setup (commonly LD_LIBRARY_PATH (or on win32 PATH) to let the system resolve the libraries at run time - only COBOL modules' directory go to COB_LIBRARY_PATH.
Do I really need cobcrun for linking or any other reason?
As noted before cobcrun is only a way to start COBOL programs from the command line that were not compiled as executable, and that can setup some of the variable you see with cobcrun -r (you can set them manually instead).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am converting a suite of my RM COBOL command line utilities to GNU. Most of my work has been [...] because it doesn't do COL 0 or otherwise default to the last screen position.
That's a non-standard thing to do, but supported with GnuCOBOL, if you use a dialect that handles it that way.
After checking the RM Language Manual I think that until now rm(-strict) falsely did not ship with that option, but you can fix that in the config directory - or specify -fline-col-zero-default on the command line that should work.
Can you please recheck?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For CONVERT - something that would be relative easy to implement when cobc passes an option for that to libcob - we finally have a wish-list item to track that with [feature-requests:#433].
All these questions can be answered via the Programmers Guide but:
1. No if you compile using cobc -x ..... it creates an executable so just run by name.
2. Yes, .cob .COB, .cbl & .CBL are the normal extension names given for Cobol sources. Note that .scb and .SCB are for SQL included sources that go through a SQL precompiler before passing to gnuCobol. .EXE or .exe etc are for Windows executables and the extension is important.
3. Ignoring the cobcrun used to execute a program compiled with cobc -m ONLY the not found means that a sub modules was not linked into the primary program for examples :
placing them all your ~bin directory which is in your PATH then running main will process correctly
However if you have other dependences such as special libraries that are called within progs then you need to link them in at compile time at least for main, see -L and -I kine commands to the compiler.
That it in a nutshell
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-03-22
How many pages is the Programmers Guide ?
I hear that often on this web site.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many, and increasing.
... but that's a good thing, because you only have to look at what you're interested, in this case cobc/cobcrun and linking.
I hear that often on this web site.
Because it is a free and very good resource to learn about both COBOL and GnuCOBOL, and as it is available digital in several formats you can easily search in that, too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you all. I want you to know that I do study the Programmers Guide. It has answered many questions I didn't have to ask here. It's large, that's good. Many page number references are "off". I'm sure that relates to updates. I use the search feature which is great.
As an example and related to my ACCEPT COL 0 and CONVERT program conversions I found how to retrieve the screen position registers and found FUNCTION NUMVAL, both of which are new to me. I will try -fline-col-zero-default for an even better solution/fewer changes. There is a great library of C$ and CBL_ and COB_ embedded functions, and of FUNCTION directives.
I see I don't need cobcrun to link. From the start I set up my own RUNC with all the COB_ runtime variables from runtime.cfg. That is what you saw in the cobcrun -r attachment a.
Thank you for the linking information. It's very straight-forward and specific but is still unclear to me in application. Maybe it's just the -l cobc parameter. I'll try and report.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Re: -fline-col-zero-default it works for DISPLAY, fails for ACCEPT. The option is also in rm-strict.conf. I had modified it there before my first compiles and tests.
DISPLAY 'Key transaction amount $' LINE 5 COL 10.
ACCEPT DOLLARS-ALPHA.
or ACCEPT DOLLARS-ALPHA LINE 0 COL 0.
then I use FUNCTION NUMVAL to convert to numeric
but it does the ACCEPT at line 1 col 1
I understand that I am a dinosaur in not using SCREEN, and many ways. The RM programs I am converting have hundreds of COL 0 ACCEPT's. it would be a big job to calculate and test hundreds of screen positions to start the ACCEPT's. As I wrote above I found the registers and solved my problem that way. I only write this to inform you of the situation. -fline-col-zero-default in man cobc is correct. It only specifies DISPLAY. But rm-strict.conf says the option pertains to ACCEPT and DISPLAY which is wrong.
Thank you all again for your continued help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
TEST.exe is a medium size program testing routines for ACCEPT compatibility and doing RM CONVERT functions. It executes properly as /usr/nova/objc/TEST.exe in my testing of many program changes and iterations. It is compiled -x.
I get the not found error with
cobcrun TEST.exe, with using the full path, with just TEST and many variations.cobcrun -rshows the objc path both places ($LD_..., $COB_L...). It is also in $PATH.I started a topic because the other similar problems are all CALL's and did not seem to help me. I know it is my novice capability in C compile and execution. I'm very impressed with your various COBOL language provisions/compatibilities. I don't understand why cobcrun can't find a full path executable. Please advise me.
because it is a "main" executable
because cobcrun is a "module runner" it runs DLLs
compile with
-mand you can both useCALLandcobcrunto start it.On 03/03/2023 21:33, W. Burke Cabaniss wrote:
If you built the program as cobc -x test.cbl etc then just run :
./test
OR
cobc -xj test.cbl
compile and runs
IF there are args for test just add them at the end of the line.
Thank you so much for your two replies. I do understand -x main vs. -m subprograms and why ./TEST works. I understand static vs. dynamic linking and only want to do dynamic linking. I execute several good-sized test programs successfully now. I'm very impressed with GNU COBOL features.
But I am still a newbie in GNU and C. i do Unix/Linux only, COBOL's only, for 50 plus years. My company wrote and sold financial "enterprise" systems for credit unions. I am converting a suite of my RM COBOL command line utilities to GNU. Most of my work has been with ACCEPT because of CONVERT and because it doesn't do COL 0 or otherwise default to the last screen position. I've handled that. I ask:
1. Do I really need cobcrun for linking or any other reason?
2. Do the extensions .cob, .exe, etc. have significance in my situation?
3. Even if I don't need cobcrun the "not found" error still exists and puzzles me. In my initial tests of linking I get it there too. Again, I think it is a basic newbie lack of knowledge. I have listed my
cobcrun -routput attached.Your
COB_LIBRARY_PATHis quite big and contains system library paths.As a rule of thumb: when linking explicit against a library
cobc -llibnamethen you often want to do "static linking" of the libraries' entry points, either withCALL STATIC "libentrypoint"or withcobc -K libentrypointor "all literals" withcobc --static; you then use the system setup (commonlyLD_LIBRARY_PATH(or on win32PATH) to let the system resolve the libraries at run time - only COBOL modules' directory go toCOB_LIBRARY_PATH.As noted before
cobcrunis only a way to start COBOL programs from the command line that were not compiled as executable, and that can setup some of the variable you see withcobcrun -r(you can set them manually instead).That's a non-standard thing to do, but supported with GnuCOBOL, if you use a dialect that handles it that way.
After checking the RM Language Manual I think that until now rm(-strict) falsely did not ship with that option, but you can fix that in the config directory - or specify
-fline-col-zero-defaulton the command line that should work.Can you please recheck?
For
CONVERT- something that would be relative easy to implement when cobc passes an option for that to libcob - we finally have a wish-list item to track that with [feature-requests:#433].Related
Wish List: #433
All these questions can be answered via the Programmers Guide but:
1. No if you compile using cobc -x ..... it creates an executable so just run by name.
2. Yes, .cob .COB, .cbl & .CBL are the normal extension names given for Cobol sources. Note that .scb and .SCB are for SQL included sources that go through a SQL precompiler before passing to gnuCobol. .EXE or .exe etc are for Windows executables and the extension is important.
3. Ignoring the cobcrun used to execute a program compiled with cobc -m ONLY the not found means that a sub modules was not linked into the primary program for examples :
Method 1:
cobc -x main.cbl sub1.cbl sub2.cbl (etc)
cobc -m sub1.cbl - produces sub1.so
cobc -m sub2.cbl - produces sub2.so
cobc -x main.cbl - produces main
placing them all your ~bin directory which is in your PATH then running main will process correctly
However if you have other dependences such as special libraries that are called within progs then you need to link them in at compile time at least for main, see -L and -I kine commands to the compiler.
That it in a nutshell
How many pages is the Programmers Guide ?
I hear that often on this web site.
Many, and increasing.
... but that's a good thing, because you only have to look at what you're interested, in this case cobc/cobcrun and linking.
Because it is a free and very good resource to learn about both COBOL and GnuCOBOL, and as it is available digital in several formats you can easily search in that, too.
Thank you all. I want you to know that I do study the Programmers Guide. It has answered many questions I didn't have to ask here. It's large, that's good. Many page number references are "off". I'm sure that relates to updates. I use the search feature which is great.
As an example and related to my ACCEPT COL 0 and CONVERT program conversions I found how to retrieve the screen position registers and found FUNCTION NUMVAL, both of which are new to me. I will try -fline-col-zero-default for an even better solution/fewer changes. There is a great library of C$ and CBL_ and COB_ embedded functions, and of FUNCTION directives.
I see I don't need cobcrun to link. From the start I set up my own RUNC with all the COB_ runtime variables from runtime.cfg. That is what you saw in the cobcrun -r attachment a.
Thank you for the linking information. It's very straight-forward and specific but is still unclear to me in application. Maybe it's just the -l cobc parameter. I'll try and report.
Re: -fline-col-zero-default it works for DISPLAY, fails for ACCEPT. The option is also in rm-strict.conf. I had modified it there before my first compiles and tests.
DISPLAY 'Key transaction amount $' LINE 5 COL 10.
ACCEPT DOLLARS-ALPHA.
or ACCEPT DOLLARS-ALPHA LINE 0 COL 0.
then I use FUNCTION NUMVAL to convert to numeric
but it does the ACCEPT at line 1 col 1
I understand that I am a dinosaur in not using SCREEN, and many ways. The RM programs I am converting have hundreds of COL 0 ACCEPT's. it would be a big job to calculate and test hundreds of screen positions to start the ACCEPT's. As I wrote above I found the registers and solved my problem that way. I only write this to inform you of the situation. -fline-col-zero-default in
man cobcis correct. It only specifies DISPLAY. But rm-strict.conf says the option pertains to ACCEPT and DISPLAY which is wrong.Thank you all again for your continued help.