Thanks guys I will try testing the procedure tomorrow evening.
On Sunday, April 30, 2023 at 04:01:14 PM CDT, Simon Sobisch sf-mensch@users.sourceforge.net wrote:
Additional to what Mickey said: you can call a module "like a main
program" when using the module runner cobcrun:
cobc -m HELLO.cob
cobcrun HELLO
... which should also be noted int the programmer's guide.
-x is executable -m is called....
From the programmers Guide gnucobpg-letter.pdf (in the manuals and guide section) 10.1.1. cobc - The GnuCOBOL Compiler
-x build an executable program
-m build a dynamically loadable module (default)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As you probably know RMCobol (.cob) programs are not really machine
executable code. Their code section is comprised of 'pseudo code' which
is not executable by any program except 'runcobol'. This allows '.cob'
code the ability to be called by 'runcobol' or to be called by another
'.cob' program. This flexibility also allows any RMCobol '.cob' program
to have a LINKAGE SECTION unlike GNUCobol programs compiled with 'cobc -x'.
You have found out that as of this time GNUCobol only allows LINKAGE
SECTION in a CALLed module compiled with 'cobc -m" and not in a program
that can be invoked directly from the commandline or a script. This
restriction is a decendent from some decisions made by the original GC
authors. As far as I know the reasons for this tactic have been lost in
the mists of time. This was discussed a bit in this thread:
If you peruse that thread you will find that in the next major release
(GCr4), the powers that be are considering lifting the LINKAGE SECTION
restriction so that all GC programs have LINKAGE SECTION support. While I
would suppose that support for the 'cobc -m' vs 'cobc -x' options will
continue, the 'cobc -m' option will no longer be needed. Execution of
'cobc -x' will result in LINKAGE SECTION support if that section is
included in the source code.
How much that support will resemble the RMC approach is unknown to me but
the RMC way is a good model. Of course there may be other things to
consider when invoking a 'cobc -x' program although I cannot conjure up
any reasonable ideas on that.
For now we must follow the 'cobc -x / cobc -m' model. It does require
some retooling when one is migrating from RMCobol to GC but I have found
that moving called programs into library modules (*.so) is helpful.
Gregory
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have absolutely no idea if that is the case. I am just a GC user hanging around the outer edges of the GC nebula. I am not part of the group that is making those decisions.
IMHO including LINKAGE SECTION support in programs that are called by command line or script invocation doesn't seem to require changes that would impact other sections of executable code. LINKAGE SECTION processing is usually performed early in an invocation and should not impact other code. Currently if command line arguments are needed for a primary program, the ACCEPT FROM COMMAND-LINE verb will ingest the needed parameters. In GCr4 that probably would not change from a coders point of view. Internally however I would expect that any command line arguments would have already been acquired from the command line and would be available from an internal area. It may actually be easier than that by simply managing some pointers. I really don't know.
So backwards compatible? I would expect so for the most part. Recompiling everything? I would do so simply so I could do testing for breakage. There is always something lurking around waiting to bite you in the posterior in any major release of any software. My systems manage other peoples money - I cannot make mistakes that impact the customer's assets. So I am very careful.
Gregory
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Standard practice for a new compiler version is by default to recompile
all code.
If for no other reason than JIC.
V4 is not a drop in replacement for v3 and so does require recompiles
but see first rule .
Or in other words, if in doubt recompile and I have many hundreds that I
do this for across different suites and applications.
It is only a bit of computer time. and the running of prefixed scripts /
JCL etc at a defined time of day which does the compiles and copies over
the executables to the correct system folders on the right system/s.
Done and dusted well within 15 minutes.
On 01/05/2023 13:54, Mickey White wrote:
Greg, it is my understanding that GCr-4 is not backwards compatible
with 3 and we will have to recompile everything. Is that correct?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The concern you guys are showing makes my effort really joyful and I thank you so much.
Team I feel like I am getting ahead of myself and I don't want to do that.
I have not completed the conversion of my program jctprwwp from rmcobol to gnucobol
I want to get a clean and execution output of my print program jctprwwp before I try to work on another program.
Here is my situation so far. I compiled my program as cobc -x jctprwwp.cbl
I got a clean compile then I executed my program by entering jctprwwp at the command line.
The program displays a screen the 1st field of the screen f01 month the dashes are missing the next fields are okay .THE CURSOR is position at the 1st field so I can enter the month e.g. MAY then it automatically advance to the next field e. g. f02 day ___ the cursor does not advance to the other fields.
How can I fix this problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is my situation so far. I compiled my program as cobc -x jctprwwp.cbl
I got a clean compile then I executed my program by entering jctprwwp at the command line.
On exe of the program it will display a screen . The 1st field of the screen i.e, f01 month the dashes are missing the next fields are okay .THE CURSOR is position at the 1st field so I can enter the month e.g. MAY then it automatically advance to the next field e. g. f02 day ___ the cursor does not advance to the other fields. How can I fix this problem? all help is needed ...Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Without seeing the code it is somewhat difficult to say exactly the problem BUT do you have any of these fields defined as FILLER ?
If so they may well NOT display or accept data via screen section.
Any such field that you want to display or have as accepting data must have a field name.
If this is not the case then it might help for you to show the source as a small example of the problem that will compile.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
guys I don't know where to go from here. The problem is beyond my access.
It works on rmcobol and I checked the code and screen i/o
Is there a y thing else I can do keep moving forward
Please Help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The code above is one text file (originally uploaded as .odt) that seems to be 1 program with two of its copybooks at the end. When trying to compile on gets some "file not found" errors on the COPY statements and then a bunch of "not defined" errors in consequence.
Using the current GC 3.2 snapsnot there are no other errors.
So... what is the actual current question / issue?
If you want others to have a look at this, then provide either (preferably) a complete code listing (adding -T problem.lst -tlines=0 -ftcmd) or (alternative) pre-processed output --save-temps -> the ".i" file you get along with the command line used. The first option will also include all diagnostics and the compiler version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
simon I am sending you the complete program with all copybooksI am using email because the forum only allow 1 attachment
I will be sending multiple emails due to the size of the files here is the list of filesjctprwwp.cbl zzwsf.cpy zztblesf.cpy zzwspxzf.cpy zzwsrtdf.cpy zzwsself.cpythe ws section now screen section zzblank.cpy zzkeyssf.cpyproc section zzkeys3f.cpy zzcrtnf.cpy zztimecf.cpy
Actually you've answered by mail and got a forum post with all the attachments :-)
Compiling the last program posted here with the attached copybook and -std=rm results in:
JCTPRWWP.CBL: in paragraph '1010M':
JCTPRWWP.CBL:102: error: '8JC' is not defined
JCTPRWWP.CBL:102: error: '8JCE' is not defined
JCTPRWWP.CBL:110: error: '9000C' is not defined
JCTPRWWP.CBL: in paragraph '2510-READ':
JCTPRWWP.CBL:404: error: '2525-READ' is not defined
Compiling the first version posted here (the "prod" version) results in
Simon, compiling with -std=rm create errors that does not exist could you and your team
look my situation and give me your thoughts on what I should try to do?
Using Gnucobol 3.2.0 (Feb 13 2023 18:10:02) (mingw) '9.2.0"
Gmp 6.2.1 Cjson 1.7.14 Pdcurses mod 4.3.5 bdb18.1.40
c:\gc32\exe > I enter cobc -x jctprwwp.cbl I get a clean compile
then I exe the program by entering jctprwwp and I will get a Screen Displayed
everything on the screen is displayed correctly except the field F01 month does not show
_ _ _ for the month.
When I start to enter the data for the month eg, JUN the cursor does no auto-advance
to the next data entry field ie f02 day
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not completely sure but guess there is a dialect option that may help you with the issue you see, so apart from quoting the errors you may want to check config/rm.conf and have a look if something sounds helpful, then add only this on the command line with a prefix of -f
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Simon , this is my best shot Please take a very careful look
the pattern I have notice is that the errors the compiler said is not define or
don't exist the line above that statement is commented out
I know it may seem crazy but
the commented line 0r lines prior to the instruction or paragraph is causing the problem
please take a look at the attachment
If a commented line is causing a problem (now: one problem is definitely that a cobybook cannot be found - possibly an issue with case sensitive file system?), then I guess the asterisk is not on column 7 / a tab stop is used and its width is not setup in cobc.
Note: ideally create a listing with -t problem.lst - this way we'd have all the code the computer sees, along with the diagnostic messages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you compile a called program e.g, cobc -x zzrewcrp.cbl the same way you would a main program. all help is appreciated
Julius
Additional to what Mickey said: you can call a module "like a main
program" when using the module runner
cobcrun:... which should also be noted int the programmer's guide.
Simon
Thanks guys I will try testing the procedure tomorrow evening.
On Sunday, April 30, 2023 at 04:01:14 PM CDT, Simon Sobisch sf-mensch@users.sourceforge.net wrote:
Additional to what Mickey said: you can call a module "like a main
program" when using the module runner cobcrun:
cobc -m HELLO.cob
cobcrun HELLO
... which should also be noted int the programmer's guide.
Simon
rm/cobol compile errors
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gnucobol/discussion/help/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
-x is executable -m is called....
From the programmers Guide gnucobpg-letter.pdf (in the manuals and guide section) 10.1.1. cobc - The GnuCOBOL Compiler
-x build an executable program
-m build a dynamically loadable module (default)
Julias,
As you probably know RMCobol (.cob) programs are not really machine
executable code. Their code section is comprised of 'pseudo code' which
is not executable by any program except 'runcobol'. This allows '.cob'
code the ability to be called by 'runcobol' or to be called by another
'.cob' program. This flexibility also allows any RMCobol '.cob' program
to have a LINKAGE SECTION unlike GNUCobol programs compiled with 'cobc -x'.
You have found out that as of this time GNUCobol only allows LINKAGE
SECTION in a CALLed module compiled with 'cobc -m" and not in a program
that can be invoked directly from the commandline or a script. This
restriction is a decendent from some decisions made by the original GC
authors. As far as I know the reasons for this tactic have been lost in
the mists of time. This was discussed a bit in this thread:
https://sourceforge.net/p/gnucobol/discussion/cobol/thread/f6b6f5fe91/?limit=25#a264/affa/16fb/b386
If you peruse that thread you will find that in the next major release
(GCr4), the powers that be are considering lifting the LINKAGE SECTION
restriction so that all GC programs have LINKAGE SECTION support. While I
would suppose that support for the 'cobc -m' vs 'cobc -x' options will
continue, the 'cobc -m' option will no longer be needed. Execution of
'cobc -x' will result in LINKAGE SECTION support if that section is
included in the source code.
How much that support will resemble the RMC approach is unknown to me but
the RMC way is a good model. Of course there may be other things to
consider when invoking a 'cobc -x' program although I cannot conjure up
any reasonable ideas on that.
For now we must follow the 'cobc -x / cobc -m' model. It does require
some retooling when one is migrating from RMCobol to GC but I have found
that moving called programs into library modules (*.so) is helpful.
Gregory
Greg, it is my understanding that GCr-4 is not backwards compatible with 3 and we will have to recompile everything. Is that correct?
Not Greg here, but definitely: yes.
Mickey,
I have absolutely no idea if that is the case. I am just a GC user hanging around the outer edges of the GC nebula. I am not part of the group that is making those decisions.
IMHO including LINKAGE SECTION support in programs that are called by command line or script invocation doesn't seem to require changes that would impact other sections of executable code. LINKAGE SECTION processing is usually performed early in an invocation and should not impact other code. Currently if command line arguments are needed for a primary program, the ACCEPT FROM COMMAND-LINE verb will ingest the needed parameters. In GCr4 that probably would not change from a coders point of view. Internally however I would expect that any command line arguments would have already been acquired from the command line and would be available from an internal area. It may actually be easier than that by simply managing some pointers. I really don't know.
So backwards compatible? I would expect so for the most part. Recompiling everything? I would do so simply so I could do testing for breakage. There is always something lurking around waiting to bite you in the posterior in any major release of any software. My systems manage other peoples money - I cannot make mistakes that impact the customer's assets. So I am very careful.
Gregory
First Rule :
Standard practice for a new compiler version is by default to recompile
all code.
If for no other reason than JIC.
V4 is not a drop in replacement for v3 and so does require recompiles
but see first rule .
Or in other words, if in doubt recompile and I have many hundreds that I
do this for across different suites and applications.
It is only a bit of computer time. and the running of prefixed scripts /
JCL etc at a defined time of day which does the compiles and copies over
the executables to the correct system folders on the right system/s.
Done and dusted well within 15 minutes.
On 01/05/2023 13:54, Mickey White wrote:
The concern you guys are showing makes my effort really joyful and I thank you so much.
Team I feel like I am getting ahead of myself and I don't want to do that.
I have not completed the conversion of my program jctprwwp from rmcobol to gnucobol
I want to get a clean and execution output of my print program jctprwwp before I try to work on another program.
Here is my situation so far. I compiled my program as cobc -x jctprwwp.cbl
I got a clean compile then I executed my program by entering jctprwwp at the command line.
The program displays a screen the 1st field of the screen f01 month the dashes are missing the next fields are okay .THE CURSOR is position at the 1st field so I can enter the month e.g. MAY then it automatically advance to the next field e. g. f02 day ___ the cursor does not advance to the other fields.
How can I fix this problem?
Here is my situation so far. I compiled my program as cobc -x jctprwwp.cbl
I got a clean compile then I executed my program by entering jctprwwp at the command line.
On exe of the program it will display a screen . The 1st field of the screen i.e, f01 month the dashes are missing the next fields are okay .THE CURSOR is position at the 1st field so I can enter the month e.g. MAY then it automatically advance to the next field e. g. f02 day ___ the cursor does not advance to the other fields.
How can I fix this problem? all help is needed ...Thanks
Without seeing the code it is somewhat difficult to say exactly the problem BUT do you have any of these fields defined as FILLER ?
If so they may well NOT display or accept data via screen section.
Any such field that you want to display or have as accepting data must have a field name.
If this is not the case then it might help for you to show the source as a small example of the problem that will compile.
Thanks Vincent! I'll try to send you the program and copy files tomorrow 5/12/ 2023
Vincent this is the code being exe. Please keep in mind this program works using rmcobol
this code displays a screen and accept keyboard data entry.
your help and others ... greatly appreciated
Last edit: Simon Sobisch 2023-05-19
guys I don't know where to go from here. The problem is beyond my access.
It works on rmcobol and I checked the code and screen i/o
Is there a y thing else I can do keep moving forward
Please Help!
I have no clue where you currently are...
The code above is one text file (originally uploaded as .odt) that seems to be 1 program with two of its copybooks at the end. When trying to compile on gets some "file not found" errors on the
COPYstatements and then a bunch of "not defined" errors in consequence.Using the current GC 3.2 snapsnot there are no other errors.
So... what is the actual current question / issue?
If you want others to have a look at this, then provide either (preferably) a complete code listing (adding
-T problem.lst -tlines=0 -ftcmd) or (alternative) pre-processed output--save-temps-> the ".i" file you get along with the command line used. The first option will also include all diagnostics and the compiler version.simon I am sending you the complete program with all copybooksI am using email because the forum only allow 1 attachment
I will be sending multiple emails due to the size of the files here is the list of filesjctprwwp.cbl zzwsf.cpy zztblesf.cpy zzwspxzf.cpy zzwsrtdf.cpy zzwsself.cpythe ws section now screen section zzblank.cpy zzkeyssf.cpyproc section zzkeys3f.cpy zzcrtnf.cpy zztimecf.cpy
Last edit: Simon Sobisch 2023-05-21
Actually you've answered by mail and got a forum post with all the attachments :-)
Compiling the last program posted here with the attached copybook and
-std=rmresults in:Compiling the first version posted here (the "prod" version) results in
Note: if attaching multiple sources don't work, then just post one, then "edit" your post and add the attachments then.
Last edit: Simon Sobisch 2023-05-21
Simon, compiling with -std=rm create errors that does not exist could you and your team
look my situation and give me your thoughts on what I should try to do?
Using Gnucobol 3.2.0 (Feb 13 2023 18:10:02) (mingw) '9.2.0"
Gmp 6.2.1 Cjson 1.7.14 Pdcurses mod 4.3.5 bdb18.1.40
c:\gc32\exe > I enter cobc -x jctprwwp.cbl I get a clean compile
then I exe the program by entering jctprwwp and I will get a Screen Displayed
everything on the screen is displayed correctly except the field F01 month does not show
_ _ _ for the month.
When I start to enter the data for the month eg, JUN the cursor does no auto-advance
to the next data entry field ie f02 day
What strange errors does std=rm create?
I'm not completely sure but guess there is a dialect option that may help you with the issue you see, so apart from quoting the errors you may want to check config/rm.conf and have a look if something sounds helpful, then add only this on the command line with a prefix of -f
Simon, I think I know why the errors occurs give me another day to double check some errors
and I will give you a write-up
Thanks, I'm looking forward to this.
Simon , this is my best shot Please take a very careful look
the pattern I have notice is that the errors the compiler said is not define or
don't exist the line above that statement is commented out
I know it may seem crazy but
the commented line 0r lines prior to the instruction or paragraph is causing the problem
please take a look at the attachment
If a commented line is causing a problem (now: one problem is definitely that a cobybook cannot be found - possibly an issue with case sensitive file system?), then I guess the asterisk is not on column 7 / a tab stop is used and its width is not setup in cobc.
Note: ideally create a listing with -t problem.lst - this way we'd have all the code the computer sees, along with the diagnostic messages.
Simon, please refer to attached about gnucobol compile