Hello
I'm considering a migration of an application that runs on 'SCO OpenServer (TM) Release 5' and is developed with 'Micro Focus COBOL/2 v1.2 Revision 000 51' to OpenCobol on GNU/Linux.
I'm not the world cobol (not read cobol), so I'm pond in from scratch and I'm a bit lost ...
That bawtry report is a nice link. Hits on trouble spots nicely, and highlights a few places were we have to improve the compiler, especially in regards to an issue close to Sergey's heart, proper arithmetics.
Anyone reading it, it sounds pretty negative, as it's a difference report, but look to the preamble and " Inevitably, this report focuses on the differences - this may give a false impression." ... "have found OpenCOBOL to be well-featured, well-documented, robust and suitable for our production needs."
Thanks for the link Flako.
Umm, not that I'm helping with your problem, but nice link anyway.
Cheers,
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2013-05-29
Brian I found the link in the old forum opencobol :)
should be a 'thank you' to the community/team.
The link is good because it shows that things can be found in a migration, conclude that OpenCobol problem is stupid, but there are many stupid people out there :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just from checking the report: most of the issues mentioned there should exist no longer (at least with -std=mf).
... and if you want to get rid of warnings use -w or, much better, suppress specific warnings after inspecting them like -Wno-dialect to suppress " warning: optional period used").
The most interesting items are the ones about numeric DISPLAY/COMP/COMP-3 data-items containing invalid data (spaces and zeroes). Many of those should work now, but there are likely edge cases for that. Maybe someone has the test-5-5.cbl source so we can check?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-09-30
I attempted converting MF Cobol Express V4.1 on SCO to Linux GNUCobol, and eventually gave up as the screen handling in MF cobol uses an assembly language program (adisctrl) to interface between the screen/keyboard and the cobol program. In the end I found it faster to remove all the screen sections and use an html interface.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many years back I migrated over a complete accounting system (ACAS) over from MF Cobol going back to CIS Cobol and Workbench to GC. Yes one or more used adis as the tool to process data to/from the screen but that was introduced prior to screen section.
That does NOT mean that SS with GC is that great at least dealing with numbers both edited or not and this is down to the fact that GC does not have a full interface for doing so and has been like that since the year dot.
Examples here - such as pic 9(5).99 or even 9(5)v99 as you have to use the cursor to move to the correct char position to add or change values.
The same applies to directly using ACCEPT on such a field.
One of GC contributors - Chuck is hopefully working on a solution that is called to handle such and after some testing be converted to a callable library element via the compiler itself when ever the compiler encounter such a a field.
I do not know how this is progrssing so there is no kind of timeframe for it - remember most developers working on the compiler do so in their spare time.
The only way around it it to define EACH numeric field both as a numeric sitting under a group field such as :
03 Field-type-1x.
05 Field-Type-1 pic 9(5)v.99
Then accept into the group (Field-Type-1x), check it for content such as numeric, period and (if signed a -) - may be using TEST-NUMVAL then run function NUMVAL against it to a numeric field.
Of course you cannot do this within a SS accept expect one at a time.
Another option which I have tried only a month or so back was to use a CALL "CBL_READ_KBD_CHAR" but that has some limitations bsed on my minor experiment.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello
I'm considering a migration of an application that runs on 'SCO OpenServer (TM) Release 5' and is developed with 'Micro Focus COBOL/2 v1.2 Revision 000 51' to OpenCobol on GNU/Linux.
I'm not the world cobol (not read cobol), so I'm pond in from scratch and I'm a bit lost ...
I was reading and based on http://www.bawtry.net/image/bawtry/port-report.html, there seems to be an impossible project (although you have to change the code enough)
After reading it I wondered if now, there is a tool to reduce the migration effort?
or any parameter to make compatible with Micro Focus OpenCobol?
Thanks, will forgive the post storm, as well translate.google have used to write this :)
That bawtry report is a nice link. Hits on trouble spots nicely, and highlights a few places were we have to improve the compiler, especially in regards to an issue close to Sergey's heart, proper arithmetics.
Anyone reading it, it sounds pretty negative, as it's a difference report, but look to the preamble and " Inevitably, this report focuses on the differences - this may give a false impression." ... "have found OpenCOBOL to be well-featured, well-documented, robust and suitable for our production needs."
Thanks for the link Flako.
Umm, not that I'm helping with your problem, but nice link anyway.
Cheers,
Brian
Brian I found the link in the old forum opencobol :)
should be a 'thank you' to the community/team.
The link is good because it shows that things can be found in a migration, conclude that OpenCobol problem is stupid, but there are many stupid people out there :)
Just stumbled over this. The migration report is now only available in the Internet archive at https://web.archive.org/web/20130615072321/http://www.bawtry.net:80/image/bawtry/port-report.html - sadly the COBOL test programs/instructions are not available. If anyone still has them somewhere, then it would be nice to re-inspect those, too.
Just from checking the report: most of the issues mentioned there should exist no longer (at least with
-std=mf).... and if you want to get rid of warnings use
-wor, much better, suppress specific warnings after inspecting them like-Wno-dialectto suppress " warning: optional period used").The most interesting items are the ones about numeric
DISPLAY/COMP/COMP-3data-items containing invalid data (spaces and zeroes). Many of those should work now, but there are likely edge cases for that. Maybe someone has the test-5-5.cbl source so we can check?I attempted converting MF Cobol Express V4.1 on SCO to Linux GNUCobol, and eventually gave up as the screen handling in MF cobol uses an assembly language program (adisctrl) to interface between the screen/keyboard and the cobol program. In the end I found it faster to remove all the screen sections and use an html interface.
Many years back I migrated over a complete accounting system (ACAS) over from MF Cobol going back to CIS Cobol and Workbench to GC. Yes one or more used adis as the tool to process data to/from the screen but that was introduced prior to screen section.
That does NOT mean that SS with GC is that great at least dealing with numbers both edited or not and this is down to the fact that GC does not have a full interface for doing so and has been like that since the year dot.
Examples here - such as pic 9(5).99 or even 9(5)v99 as you have to use the cursor to move to the correct char position to add or change values.
The same applies to directly using ACCEPT on such a field.
One of GC contributors - Chuck is hopefully working on a solution that is called to handle such and after some testing be converted to a callable library element via the compiler itself when ever the compiler encounter such a a field.
I do not know how this is progrssing so there is no kind of timeframe for it - remember most developers working on the compiler do so in their spare time.
The only way around it it to define EACH numeric field both as a numeric sitting under a group field such as :
03 Field-type-1x.
05 Field-Type-1 pic 9(5)v.99
Then accept into the group (Field-Type-1x), check it for content such as numeric, period and (if signed a -) - may be using TEST-NUMVAL then run function NUMVAL against it to a numeric field.
Of course you cannot do this within a SS accept expect one at a time.
Another option which I have tried only a month or so back was to use a CALL "CBL_READ_KBD_CHAR" but that has some limitations bsed on my minor experiment.