I have finished the Linux shell script that does the following:
Remove all lines starting with 'LABEL RECORDS' in all FD copybooks.
Changed all copybooks from LIB (fixed) to CPY (free). I modified changeformat.cbl program not to change case when converting to free format.
Changed all source programs from CBL (fixed) to COB (free), also see above.
Replace all strings RM-COBOL with GNU-COBOL in source programs.
I am now working on the Linux compile script, as I have a flaw in it, trying to compile the source code. I hope to have it fixed tonight or tomorrow, so I can move on with conversion in detail.
Trolley78
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
supported (for the lib extention - add by -ext=lib)
supported
Nice one, that could possibly be a problem because of the changed size, depends on the use. Changing from RM-COBOL to GnuCOBOL seems less error-prone.
So to double-check: all those changes are all "cosmetic" (=not needed for the conversion, possibly useful for working on the code in general), correct?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I try and get as clean a compile as possible. If I can remove something that may cause a problem later, I remove it.
In the application thera are copybooks named the same name as the source code and get overwritten by the compiler in Windows mode. Also I would like to keep things consistent, so I used CPY and not LIB in GnuCOBOL.
I like free format very much, it can make coding cleaner, my opinion.
I took your suggestion and changed the GNU-COBOL to GnuCOBOL.
I am currently working on my build script (it has a flaw). I was doing COBJAPI compiling and the script works just fine. It does not compile standard programs. If all goes well, I will be building a Makefile for this project. I assume, I can keep this post open while I continue my progress?
Trolley78
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now I am working on all the ACCEPTS and DISPLAY statements that are warnings and errors that were brought up in previous posts within the forums.
I have copies of the RM/COBOL documentation for reference. I have supported a RM/COBOL application for the last twenty years. I have the 3.0-rc2 Programmer's Guide for GnuCOBOL. I am using 3.1-dev build of the compiler. Is there a different guide I should be looking at for the Programmer's Guide?
Trolley78
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As there were no big adjustments to DISPLAY/ACCEPT other than the mouse addition I think its fine to use an older version of the Programmer's Guide. You find the latest under "manuals" above.
But again: I think it is most reasonable to check for warnings/errors, create a FR for each separate issue including a relevant documentation snip and a minimal program, then work on supporting these in GnuCOBOL, rather than changing multiple programs.
Note: the only thing that is unlikely to be added "soon" is a different set of [exception] key-codes and a different set of color values.
If there's a complete patch provided, then it will be done - but I consider this much less important than support for the general syntax [which is also much more easy to add].
Last edit: Simon Sobisch 2019-09-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The latest manual/s are for v3.2 RC? dated this month.
That said differences are very light just minor corrections but see the changes list near the front of the PG manual.
I am sure that changes can be made with new language variations but if I am not formally informed, I do not do so.
As for variations such as to allow for migration across other compilers I have not added any.
This should be a seperate document marked ups as "Migrating to the GnuCOBOL Cobol Compiler v xyz " etc.
For the moment I will leave it to others to create because if I do it, will be be produced using Libreoffice word processing and not texlive. I do like wysiwyg software where ever possible.
There is a lack of any documentation and notes regarding this, other than in the NEWS file so look at that first.
Personally I notmally use the defaults for the compiler and only use std = mf or ibm if I have a real need for moving to/from mf or IBM compilers but in any event MF compilers cover OO and GC does not so not often!
Last edit: Vincent (Bryan) Coen 2019-09-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, I have switched things up. Took some suggestions from Simon. I have renamed the .LIB to .CPY for the reason stated earlier. I have not changed the format to free. I have kept the source code with an extension of .CBL. I edit the source code to change 'RM-COBOL' to 'GnuCOBOL', then all .LIB to .CPY.
Started compiling code and gettings errors. Could someone please tell me what the difference is between '-std=rm' and '-std=rm-strict'. Thank you.
Trolley78
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please check the NEWS file and/or the manual (found in the dics directory inpdf and info format) for the difference about the dialects, quote the relevant parts here together with any questions that may be open. Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I only know what the NEWS file says and assume to know that doc/gnucobol.pdf says something about this. Where is the difference to the PG?
In general I'd say: "use -std=rm-strict to recompile programs without any change and be (likely) able to compile changed programs back on the R/M environment, use -std=rm if you want to actually work on the programs and use newer syntax not supported by R/M (and possibly get "unexpected XYZ" errors because of an extended set of reserved words) - identical for other stds. Drop -std completely if possible, to go with the GnuCOBOL defaults and all supported extensions (likely to need more testing, so maybe only do this for new/heavy adjusted sources).
Note: it would be actually useful if you have R/M compatible sources to compile them with -std=rm-strict at least once, reporting if there are any errors reported.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know that the '-c' is to compile not link. After getting the programs compiled, how do I link them together. Currently working on three programs with a main program (INSMAINT) and two sub-programs (INSADD, INSHELP).
Of course these programs are RM/COBOL source code.
Thank you in advance for any help.
Trolley78
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Chiming in here, Rich. I might have a similar challenge as you coming up. Ie, facing a possible conversion from code written for RM-Cobol-85 to GNU Cobol. Was there some open source tool(s) that you used, or just brute force? From a 100,000 ft view, what would you recommend as steps for going about this? Is this process coded or documented somewhere that can be downloaded? The possible project I'm looking at contains close to 500 cobol source modules. So, whatever (semi-)automated process(es) I can utilize (tool(s) and/or documentation(s)) would be highly appreciated. Thanks!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, I have put my RM/COBOL conversion project on hold. I had no real idea on how start myself, like you. The application I currently support runs on SCO OpenServer 5 and Windows. The Windows version screens can be reproduced using Cobjapi. The Unix version using a terminal screens, using RM/COBOL.
I would look through the forums for any bit of information that might help you. Of course, you can contact me for any questions or suggestions.
I am currently, working on a Hair Salon application using Cobjapi.
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The first and second part in whatever order you like to are:
install recent GnuCOBOL (at least 3.1.2) and compile sources with cobc -std=rm-strict -I /path/to/include1 -I /path/to/includeN -Wall *.cob - and see if there are reported syntax errors (in this case I'd suggest to report these); watch out for warnings and keep those for a later step
check about possible extensions used (especially via CALL interface) and think about how to replace those
If it already compiles you can also run the result for a first test.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Late to the conversation, but there are COUNTLESS errors compiling RM/COBOL code with rm-strict or rm. The most annoying part is you compile the first time, and it might say "4 errors." Fix them, recompile and you get "32 errors." Fix those, recompile and get another 40 errors.
Annoying things like you can't have a procedure named the same as a variable. "HIGH", "CONVERT" and more reserved words that it recognizes but aren't supported. Lots of obsolete warnings even though the manual says the reserved words are supported. It goes on and on.
Now, I'm not complaining in the least whether these are "good" errors or "bad" errors. And the code is, after all, 40 years old. My experience with GnuCOBOL is that it's pretty much right all the time. It's just frustrating that when you think you just fixed the last of 40 errors, the next compile lists 40 more! And my -fmax-errors number is 1,000.
The most curious thing for this exercise is that "rm", "rm-strict" or none doesn't seem to have any impact on the compile. Except that leaving out "rm" or "rm-strict" produces FEWER errors!
Don't need a response to this. Just my observations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes I am afraid to say with the v3.2 final release the way it processes
(or not errors or warnings) leave a lot to be desired with its behaviour
exactly as you describe - spits out a few then quits so you fix those
recompile and it does the same.
What is needed is to continue processing all such errors etc until the
defined error count is reached and that allowing for the steering
command to increase it.
Yes this is a gentile hint !
On 10/05/2024 19:06, John Ritter wrote:
Late to the conversation, but there are COUNTLESS errors compiling
RM/COBOL code with rm-strict or rm. The most annoying part is you
compile the first time, and it might say "4 errors." Fix them,
recompile and you get "32 errors." Fix those, recompile and get
another 40 errors.
Annoying things like you can't have a procedure named the same as a
variable. "HIGH", "CONVERT" and more reserved words that it recognizes
but aren't supported. Lots of obsolete warnings even though the manual
says the reserved words are supported. It goes on and on.
Now, I'm not complaining in the least whether these are "good" errors
or "bad" errors. And the code is, after all, 40 years old. My
experience with GnuCOBOL is that it's pretty much right all the time.
It's just frustrating that when you think you just fixed the last of
40 errors, the next compile lists 40 more! And my -fmax-errors number
is 1,000.
The most curious thing for this exercise is that "rm", "rm-strict" or
none doesn't seem to have any impact on the compile. Except that
leaving out "rm" or "rm-strict" produces FEWER errors!
Don't need a response to this. Just my observations.
The user-name only be usable for one type (procedure or variable) is indeed an issue for some migrations and we do have an open issue for that. I think it may was even me creating it during a migration project from ACUCOBOL-GT (very near to RM). That project was finished in every place but screenio (compiled with "pending" warnings and did not work), which was ok as the programs had a non-interactive mode which was needed and worked.
As my code is only now producing errors for my supposed updates is fairly low volume but if ANY ONE is doing newly migrated code from say another compiler and getting similar issues please include all copybooks into code, recompile and assuming you get the same error problems attach it here for @Simon to look at.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Simon:
Really appreciate the offer for assistance, but this is not critical for me. Efforts would be better spent for those who need it. Also, the code is proprietary, so I wouldn't feel comfortable sharing it.
That said, I did some experimentation with assorted compile options just to see what would happen. A side note: This program compiles with no errors using Liant's RM/COBOL85. The compiler says:
RM/COBOL Compiler - Version 6.61.00 for AT&T Unix System V R 4.
Copyright (c) 1985, 1986-1998 by Liant Software Corp. All rights reserved.
Hi All!
I have finished the Linux shell script that does the following:
I am now working on the Linux compile script, as I have a flaw in it, trying to compile the source code. I hope to have it fixed tonight or tomorrow, so I can move on with conversion in detail.
Trolley78
Just to check:
-ext=lib)RM-COBOLtoGnuCOBOLseems less error-prone.So to double-check: all those changes are all "cosmetic" (=not needed for the conversion, possibly useful for working on the code in general), correct?
Simon,
Thank you for your response.
I am currently working on my build script (it has a flaw). I was doing COBJAPI compiling and the script works just fine. It does not compile standard programs. If all goes well, I will be building a Makefile for this project. I assume, I can keep this post open while I continue my progress?
Trolley78
Sure, there is nothing that prevents a useful response even after years (if the topics match enough).
Now I am working on all the ACCEPTS and DISPLAY statements that are warnings and errors that were brought up in previous posts within the forums.
I have copies of the RM/COBOL documentation for reference. I have supported a RM/COBOL application for the last twenty years. I have the 3.0-rc2 Programmer's Guide for GnuCOBOL. I am using 3.1-dev build of the compiler. Is there a different guide I should be looking at for the Programmer's Guide?
Trolley78
As there were no big adjustments to DISPLAY/ACCEPT other than the mouse addition I think its fine to use an older version of the Programmer's Guide. You find the latest under "manuals" above.
But again: I think it is most reasonable to check for warnings/errors, create a FR for each separate issue including a relevant documentation snip and a minimal program, then work on supporting these in GnuCOBOL, rather than changing multiple programs.
Note: the only thing that is unlikely to be added "soon" is a different set of [exception] key-codes and a different set of color values.
If there's a complete patch provided, then it will be done - but I consider this much less important than support for the general syntax [which is also much more easy to add].
Last edit: Simon Sobisch 2019-09-20
The latest manual/s are for v3.2 RC? dated this month.
That said differences are very light just minor corrections but see the changes list near the front of the PG manual.
I am sure that changes can be made with new language variations but if I am not formally informed, I do not do so.
As for variations such as to allow for migration across other compilers I have not added any.
This should be a seperate document marked ups as "Migrating to the GnuCOBOL Cobol Compiler v xyz " etc.
For the moment I will leave it to others to create because if I do it, will be be produced using Libreoffice word processing and not texlive. I do like wysiwyg software where ever possible.
There is a lack of any documentation and notes regarding this, other than in the NEWS file so look at that first.
Personally I notmally use the defaults for the compiler and only use std = mf or ibm if I have a real need for moving to/from mf or IBM compilers but in any event MF compilers cover OO and GC does not so not often!
Last edit: Vincent (Bryan) Coen 2019-09-20
Okay, I have switched things up. Took some suggestions from Simon. I have renamed the .LIB to .CPY for the reason stated earlier. I have not changed the format to free. I have kept the source code with an extension of .CBL. I edit the source code to change 'RM-COBOL' to 'GnuCOBOL', then all .LIB to .CPY.
Started compiling code and gettings errors. Could someone please tell me what the difference is between '-std=rm' and '-std=rm-strict'. Thank you.
Trolley78
Please check the NEWS file and/or the manual (found in the dics directory inpdf and info format) for the difference about the dialects, quote the relevant parts here together with any questions that may be open. Thank you.
Simon,
Thank you, I found in the latest Programmer's Guide (v3.2-RC).
Trolley78
I only know what the NEWS file says and assume to know that doc/gnucobol.pdf says something about this. Where is the difference to the PG?
In general I'd say: "use
-std=rm-strictto recompile programs without any change and be (likely) able to compile changed programs back on the R/M environment, use-std=rmif you want to actually work on the programs and use newer syntax not supported by R/M (and possibly get "unexpected XYZ" errors because of an extended set of reserved words) - identical for other stds. Drop-stdcompletely if possible, to go with the GnuCOBOL defaults and all supported extensions (likely to need more testing, so maybe only do this for new/heavy adjusted sources).Note: it would be actually useful if you have R/M compatible sources to compile them with
-std=rm-strictat least once, reporting if there are any errors reported.Thanks Simon.
I know that the '-c' is to compile not link. After getting the programs compiled, how do I link them together. Currently working on three programs with a main program (INSMAINT) and two sub-programs (INSADD, INSHELP).
Of course these programs are RM/COBOL source code.
Thank you in advance for any help.
Trolley78
Hi All!
You can ignore the about post. I figured out that I just need to compile and a additional variable containing the sub-programs to the main program.
Trolley78
Chiming in here, Rich. I might have a similar challenge as you coming up. Ie, facing a possible conversion from code written for RM-Cobol-85 to GNU Cobol. Was there some open source tool(s) that you used, or just brute force? From a 100,000 ft view, what would you recommend as steps for going about this? Is this process coded or documented somewhere that can be downloaded? The possible project I'm looking at contains close to 500 cobol source modules. So, whatever (semi-)automated process(es) I can utilize (tool(s) and/or documentation(s)) would be highly appreciated. Thanks!!
Mark,
Unfortunately, I have put my RM/COBOL conversion project on hold. I had no real idea on how start myself, like you. The application I currently support runs on SCO OpenServer 5 and Windows. The Windows version screens can be reproduced using Cobjapi. The Unix version using a terminal screens, using RM/COBOL.
I would look through the forums for any bit of information that might help you. Of course, you can contact me for any questions or suggestions.
I am currently, working on a Hair Salon application using Cobjapi.
Rich Di Iulio
The first and second part in whatever order you like to are:
cobc -std=rm-strict -I /path/to/include1 -I /path/to/includeN -Wall *.cob- and see if there are reported syntax errors (in this case I'd suggest to report these); watch out for warnings and keep those for a later stepIf it already compiles you can also run the result for a first test.
Late to the conversation, but there are COUNTLESS errors compiling RM/COBOL code with rm-strict or rm. The most annoying part is you compile the first time, and it might say "4 errors." Fix them, recompile and you get "32 errors." Fix those, recompile and get another 40 errors.
Annoying things like you can't have a procedure named the same as a variable. "HIGH", "CONVERT" and more reserved words that it recognizes but aren't supported. Lots of obsolete warnings even though the manual says the reserved words are supported. It goes on and on.
Now, I'm not complaining in the least whether these are "good" errors or "bad" errors. And the code is, after all, 40 years old. My experience with GnuCOBOL is that it's pretty much right all the time. It's just frustrating that when you think you just fixed the last of 40 errors, the next compile lists 40 more! And my -fmax-errors number is 1,000.
The most curious thing for this exercise is that "rm", "rm-strict" or none doesn't seem to have any impact on the compile. Except that leaving out "rm" or "rm-strict" produces FEWER errors!
Don't need a response to this. Just my observations.
Yes I am afraid to say with the v3.2 final release the way it processes
(or not errors or warnings) leave a lot to be desired with its behaviour
exactly as you describe - spits out a few then quits so you fix those
recompile and it does the same.
What is needed is to continue processing all such errors etc until the
defined error count is reached and that allowing for the steering
command to increase it.
Yes this is a gentile hint !
On 10/05/2024 19:06, John Ritter wrote:
Please provide sample code in a bug report.
This is not the way it is expected to be!
... and without a proper bug report: "it didn't happen" :-)
The user-name only be usable for one type (procedure or variable) is indeed an issue for some migrations and we do have an open issue for that. I think it may was even me creating it during a migration project from ACUCOBOL-GT (very near to RM). That project was finished in every place but screenio (compiled with "pending" warnings and did not work), which was ok as the programs had a non-interactive mode which was needed and worked.
As my code is only now producing errors for my supposed updates is fairly low volume but if ANY ONE is doing newly migrated code from say another compiler and getting similar issues please include all copybooks into code, recompile and assuming you get the same error problems attach it here for @Simon to look at.
Simon:
Really appreciate the offer for assistance, but this is not critical for me. Efforts would be better spent for those who need it. Also, the code is proprietary, so I wouldn't feel comfortable sharing it.
That said, I did some experimentation with assorted compile options just to see what would happen. A side note: This program compiles with no errors using Liant's RM/COBOL85. The compiler says:
RM/COBOL Compiler - Version 6.61.00 for AT&T Unix System V R 4.
Copyright (c) 1985, 1986-1998 by Liant Software Corp. All rights reserved.