I'm working on a way to migrate one application from Microfocus Cobol to GnuCobol.
The current setup is:
One Production server with IBM AIX OS, Microfocus Cobol Runtime Environment and Oracle Database 10g
One Development server with IBM AIX, Microfocus Cobol Development/Debug Environment and Oracle Database 10g
The pretended Setup is:
One Production server with RHEL OS and GnuCobol Runtime Environment
One Production serverv with RHEL OS and Oracle Database 12c
One Development server with RHEL OS and GnuCobol Development/Debug Environment
One Development server with RHEL OS and Oracle Database 12c
So, my questions are:
- Is GnuCobol suitable for this setup?
- Is there a step-by-step guide (or someting like that) with the main diferences between MF Cobol and GnuCobol?
- In therms of performance, is there differences between MF and GnuCobol?
- I saw somwhere that the debugging is in C instead of Cobol. Is this true?
Thank you in advance :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Having been involved in migrating projects from both MF and m/f to Gnu
Cobol I have a little experience in this:
Issues:
Validate GC to dev. systems, ensuring all tests complete correctly
including the NIST testing.
Break down MF sources into:
A. Batch programs that do not utilise screen processing (accept,
display) other than error messages etc.
B. Programs that use the Forms or dialog sub systems or similar -
These will require you to work out what form of migrations
procedures you will use in place of dialog / forms e.g., use
normal terminal interface or build one using any of
the other options.
C. If using CICS re-look at B.
D. Install Oracle dev tools including procob for all SQL included
programs.
E. Create programs that convert MF non Line sequential Cobol files
to L. sequential (non binary numeric fields).
F. Do the same as E but for GC file load programs.
G. Convert as needed all copy books to GC - this should be fairly
minor in nature but can be a lot more.
H. Run all primary program source through GC looking for warning
and error messages (make sure you have the extra
warning flags set for GC when compiling.
For any errors fix the test primary program/s and pass the
faults and fixes to all other programs sources as needed.
Do the same for warning if needed - many warning may not be needed.
J. Do NOT change any aspect of program functionality even if known
bugs exist within the original code base.
Make notes of required change by program if needed - This is
needed for running parallel testing.
K. Compile full project including the oracle steps.
L. Migrated all Cobol files from MF systems.
Likewise same for Oracle having migrated v10 to 12
N. Start base testing and when complete against your test plans and
scripts
P. Run Parallel testing using your test plans and scripts to
confirm matching results.
Where differences exists such as rounding validate if
acceptable or change rounding method used.
Other than the obvious differences in screen handling, CICS etc you
should find that there are a minimum of MF functionality that does not
migrate over but some calls to named and number functions may not be
implemented in GC, however in most case they are other ways of doing it
- BUT no doubt NOT ALL.
In my migrations I found very little if any but it does depend on how
old the original source code is and what compiler it was developed
for. In my cases some went back to MF Workbench v3 and even earlier
(CIS Cobol).
Performance you should find that running with GC objects the processes
are quicker (in some cases by a lot) assuming a like for like hardware
platforms and similar DASD.
Debugging - as there is no IDE system any uses the standard Cobol debug system.
If you need to get down to basics then it is using the C debuggers but I
found this was never required.
Running GC with Oracle or any other secondary tool it would be wise to
run some specific test programs (not from the project possible) to
validate access to dbms system using GC - just to make sure you have
everything in place before any project migration and testing just in
case some modifications are required to the project sources.
Working with Oracle for me is a current early days process.
Enough?
Could go on but that is the basics.
Vince
Last edit: Simon Sobisch 2015-08-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Watch out for small changes for Cobol flat file processing in:
Select statements differences - minor but STATUS KEY clauses must be
changed for standard Cobol error processing as MF uses 2 bytes where
first is 9 but other is binary. GC uses the standard 99 error values.
so this will involve changes to SELECT, working storage and the error
processing routines but if these are in copy books should be able to
keep modifications to a minimum.
FD - minor mostly cosmetic but can produce warning message depending on
what flags you have set when compiling.
LABEL RECORDS
BLOCK CONTAINS etc.
If all is using rdbms then the above will not be an issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Very likely. I think you use the Oracle COBOL precompiler, others can help for possible issues with GC and the SQL precompiler. This is an in-house-only COBOL application, isn't it? I assume that you don't use the ISAM files, do you?
Is there a step-by-step guide (or someting like that) with the main diferences between MF Cobol and GnuCobol?
There isn't that much difference, MF specific extensions may not work. Some will be seen during compile, missing system libraries fail on runtime but you can check cobc --list-system beforehand.
I'd do the following steps:
download latest GC 2.0 tarball (prepare to update GC and recompile before you actually do the final run tests); if you need split-key support do an svn-checkout of report-writer branch
build GC, may need some additional headers/libraries, but these are checked during ./configure (see README for instructions)
check that GC actually works in your environment by doing make check (skipped tests are fine)
check that MFs system libraries you use are already in [if needed do a grep -i CALL * in your source folders], prepare for possible change if not or better: add these to GC and provide a patch for not need to do this again if you update GC later
check that your sources will compile with cobc -std=mf -debug and investigate first issues - if you have a lot of sources you may want to do add -fsyntax-only for the first run; depending on how much you need the support for mf-specific parts I'd suggest to at least check if it's possible to ommit -std=mf
if you need the ISAM data from MF isam files unload them with MF and load them to fresh created ISAM files with GC
fix issues in your code, compile it and begin the real tests
In therms of performance, is there differences between MF and GnuCobol?
As far as I was told GC is often faster.
I saw somwhere that the debugging is in C instead of Cobol. Is this true?
Currently yes, will change to a COBOL source level debugger in GC. In the meantime XOVOL developers use tracing (see the FAQ) and/or DISPLAY UPON SYSERR and CALL 'CBL_OCDUMP' using yourvar
@Brian: You're invited to better the list and include it in the FAQ.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "Help getting started" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi,
I'm working on a way to migrate one application from Microfocus Cobol to GnuCobol.
The current setup is:
One Production server with IBM AIX OS, Microfocus Cobol Runtime Environment and Oracle Database 10g
One Development server with IBM AIX, Microfocus Cobol Development/Debug Environment and Oracle Database 10g
The pretended Setup is:
One Production server with RHEL OS and GnuCobol Runtime Environment
One Production serverv with RHEL OS and Oracle Database 12c
One Development server with RHEL OS and GnuCobol Development/Debug Environment
One Development server with RHEL OS and Oracle Database 12c
So, my questions are:
- Is GnuCobol suitable for this setup?
- Is there a step-by-step guide (or someting like that) with the main diferences between MF Cobol and GnuCobol?
- In therms of performance, is there differences between MF and GnuCobol?
- I saw somwhere that the debugging is in C instead of Cobol. Is this true?
Thank you in advance :)
Hi;
Having been involved in migrating projects from both MF and m/f to Gnu
Cobol I have a little experience in this:
Issues:
Validate GC to dev. systems, ensuring all tests complete correctly
including the NIST testing.
Break down MF sources into:
A. Batch programs that do not utilise screen processing (accept,
display) other than error messages etc.
B. Programs that use the Forms or dialog sub systems or similar -
These will require you to work out what form of migrations
procedures you will use in place of dialog / forms e.g., use
normal terminal interface or build one using any of
the other options.
C. If using CICS re-look at B.
D. Install Oracle dev tools including procob for all SQL included
programs.
E. Create programs that convert MF non Line sequential Cobol files
to L. sequential (non binary numeric fields).
F. Do the same as E but for GC file load programs.
G. Convert as needed all copy books to GC - this should be fairly
minor in nature but can be a lot more.
H. Run all primary program source through GC looking for warning
and error messages (make sure you have the extra
warning flags set for GC when compiling.
For any errors fix the test primary program/s and pass the
faults and fixes to all other programs sources as needed.
Do the same for warning if needed - many warning may not be needed.
J. Do NOT change any aspect of program functionality even if known
bugs exist within the original code base.
Make notes of required change by program if needed - This is
needed for running parallel testing.
K. Compile full project including the oracle steps.
L. Migrated all Cobol files from MF systems.
Likewise same for Oracle having migrated v10 to 12
N. Start base testing and when complete against your test plans and
scripts
P. Run Parallel testing using your test plans and scripts to
confirm matching results.
Where differences exists such as rounding validate if
acceptable or change rounding method used.
Other than the obvious differences in screen handling, CICS etc you
should find that there are a minimum of MF functionality that does not
migrate over but some calls to named and number functions may not be
implemented in GC, however in most case they are other ways of doing it
- BUT no doubt NOT ALL.
In my migrations I found very little if any but it does depend on how
old the original source code is and what compiler it was developed
for. In my cases some went back to MF Workbench v3 and even earlier
(CIS Cobol).
Performance you should find that running with GC objects the processes
are quicker (in some cases by a lot) assuming a like for like hardware
platforms and similar DASD.
Debugging - as there is no IDE system any uses the standard Cobol debug system.
If you need to get down to basics then it is using the C debuggers but I
found this was never required.
Running GC with Oracle or any other secondary tool it would be wise to
run some specific test programs (not from the project possible) to
validate access to dbms system using GC - just to make sure you have
everything in place before any project migration and testing just in
case some modifications are required to the project sources.
Working with Oracle for me is a current early days process.
Enough?
Could go on but that is the basics.
Vince
Last edit: Simon Sobisch 2015-08-24
Almost forgot;
Watch out for small changes for Cobol flat file processing in:
Select statements differences - minor but STATUS KEY clauses must be
changed for standard Cobol error processing as MF uses 2 bytes where
first is 9 but other is binary. GC uses the standard 99 error values.
so this will involve changes to SELECT, working storage and the error
processing routines but if these are in copy books should be able to
keep modifications to a minimum.
FD - minor mostly cosmetic but can produce warning message depending on
what flags you have set when compiling.
LABEL RECORDS
BLOCK CONTAINS etc.
If all is using rdbms then the above will not be an issue.
Very likely. I think you use the Oracle COBOL precompiler, others can help for possible issues with GC and the SQL precompiler. This is an in-house-only COBOL application, isn't it? I assume that you don't use the ISAM files, do you?
There isn't that much difference, MF specific extensions may not work. Some will be seen during compile, missing system libraries fail on runtime but you can check
cobc --list-systembeforehand.I'd do the following steps:
./configure(see README for instructions)make check(skipped tests are fine)grep -i CALL *in your source folders], prepare for possible change if not or better: add these to GC and provide a patch for not need to do this again if you update GC latercobc -std=mf -debugand investigate first issues - if you have a lot of sources you may want to do add-fsyntax-onlyfor the first run; depending on how much you need the support for mf-specific parts I'd suggest to at least check if it's possible to ommit-std=mffix issues in your code, compile it and begin the real tests
In therms of performance, is there differences between MF and GnuCobol?
As far as I was told GC is often faster.
Currently yes, will change to a COBOL source level debugger in GC. In the meantime XOVOL developers use tracing (see the FAQ) and/or
DISPLAY UPON SYSERRandCALL 'CBL_OCDUMP' using yourvar@Brian: You're invited to better the list and include it in the FAQ.
I am creating a transpiler to fix the Cobol code to pass the READ writes to SQL statements, make automatic changes that facilitate the migration, etc.
There is a version 0.1 of transpiler.awk underway and the documentation for it can be found here:
https://docs.google.com/document/d/1n2-62EtM9IiUj-4LN-Er1dOJRahvRrt2zXNa7b8kNhQ/edit?usp=sharing
The transpiler is very flexible and is prepared to transpile between languages Cobol -> Java, COBOL -> C etc, COBOL --> SQL etc.
If anyone is interested in the project, you can contact me.