I'm trying out the compiler (3.0rc1 under OSX) against a very large
code-base that makes constant use of text-screen layout to represent input
fields, column data, record display and report output.
However, I seem to be stuck from the outset with constant warnings and
errors along the lines of:
warning: GRAPHICAL WINDOW is not implemented
error: syntax error, unexpected SCREEN
And in related code, accepting screen input gives:
error: 'POS' is a reserved word, but isn't supported
GRAPHICAL WINDOW likely means this is old ACUCOBOL-GT code, correct?
If yes: this special ACUCOBOL-only extension isn't implemented and the code would need to be changed. If not: please provide a code sample and specify the old compiler.
POS is a reserved word which has a different meaning in different implementations. Did you specify any -std option that matches the "old compiler"?
In any case think this code part will work if you add -freserved=POS:POSITION (or if you use -std=acu correct config/acu.words to use this, RC2 will have this adjusted, I just need to check which other compilers this applies to before commiting it).
The "unexpected SCREEN" is likely a parser error that could be fixed for RC2, please provide a minimal sample showing only this part and I'll inspect it.
The CONVERSION part is currently implemented, yet. To ensure you have a numeric field in there do a MOVE FUNCTION NUMVAL (FIELD-NUMBER) TO FIELD-NUMBER, but in general the ACCEPT there iwll work.
Is GnuCOBOL not nearly as compatible as I thought [...]?
I don't know how compatible you thought it is. As there's no information about old/new in this post it is hard to guess anything...
In general: extensions to SCREEN section and ACCEPT/DISPLAY are common but very different from each implementation to the other. Part of these extensions are implemented, others not. In general we aim to not raise a "syntax error" for code that works in a different environment (when the specific flags are used). Adding runtime support for screenio extensions is not a big priority as many COBOL programs are either batch processing or use GUIs written in other languages. Patches are always welcome and inspected...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2018-06-07
Hi Simon,
That is a very detailed and helpful reply, thank you!
Yes, this codebase makes heavy use of AcuCOBOL GT Screen IO, Windowing, etc - sadly, it's such a large application, I doubt we'd want to look into re-writing all the input screen and fields, it'd be better time spent migrating to another language if it's that much work. I guess the alternitve is to implement direct ncurses calls that replace the COBOL calls, or something like that.
display window line 1 position 1 size 80 lines 24
pop-up other-lit-popup
display screen size 132 on exception
close window other-lit-popup
For interests sake, here is the output from one of our smallest data editing programs:
I was directed here by someone telling me "Oh it's basically feature complete" so had rather higher expectations than perhaps I should have! On the other hand, given where it's at now, it's pretty damn impressive, regardless of it lacking a few less common usages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I doubt we'd want to look into re-writing all the input screen and fields, it'd be better time spent migrating to another language if it's that much work. I guess the alternitve is to implement direct ncurses calls that replace the COBOL calls, or something like that.
Just sayin', but this is a free(dom) compiler. Weigh the work required to get GnuCOBOL able to compile your source code inventory against rewriting parts or the whole. It's an option, Might not be a viable option (depending on hours estimated) but it could very well be a least effort path (with all business rules intact).
I have it on good authority (eye balls on cobc/parser.y) that a whole pile of new reserved words are in GnuCOBOL 3-prerel and things like support for "GRAPHICAL WINDOW" are marked as PENDING (what you see as is not implemented. I may well be letting cats out of bags, but all you have to do is look at the sources in trunk (it's a fairly transparent bag), or I've just been away for too long and missed the memo :-) I care about these things as the FAQ is now in need of some 300+ new reserved word entries. Looking forward to updating the docs (even if the first phase is simply documenting things as "pending").
I've been away for the last 6 months, and mostly out of the loop, but this is looking very complete (in terms of lexical parse) and very cool and giddy making (in terms of future outlook).
If experiments work out as they look like they will, we'll have access to a library (libAgar) that may really accelerate providing cross platform runtime support for graphical user interface programming in GnuCOBOL. Plus, just noticed that libAgar has added Web as a core feature, pretty colours AND network application goodness.
Have good, make futures,
Blue
Last edit: Brian Tiffin 2018-06-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds like some real progress is being made. Contributing to this development is a thought, however we don't have any devs with strong C skills so that could be a hinderance.
It's safe to say we use COBOL in a way that most people do not. We run it as a distributed platform across many servers, running a UI over an ssh connection. We're keen to get out of it but with all the business logic and existing userbase... well you know how it is.
We do have some services that have no UI that could possibly work, though my first attempt at just throwing it at the compiler resulted in 102 (or so) errors before "Too many errors" kicked in.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, getting the parts that have no UI to work should be the first thing to do.
As noted GnuCOBOL can be adjusted and I may be able to do this when specific errors are specified, ideally with a minimal compilable sample.
Another part that could be done (and seems especially reasonable with your applications): get COBOL coders to split the UI programs to a "mostly UI" and "only business logic" parts.
The good thing about this:
the existing programmers can do this
they may also new what the program is intended to do
the result can (and should) be tested with the old ACU compiler/runtime
you even can start to use a non-COBOL UI for this and still test with the old compiler/runtime
In the end it may be possible to replace the UI parts but keeping the working and grown business logic as-is.
A new UI has always the potential of additional benefits for the operators (possibly needs additional COBOL programs to support new stuff, but this is a different issue).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually it is mostly missing only vendor extensions, especially ACUCOBOL-GT screen extensions - and if I'm not wrong no other compiler or migration to X will work with heavy used ACUCOBOL-GT screen extensions.
Other than the complete USAGE NATIONAL / BIT / ... (ok, we actually have more than one post COBOL 85 parts open) there's primary the OO part currently missing, but I hope we have something stable for the OO part in 2019, too.
Sadly, it's such a large application, I doubt we'd want to look into re-writing all the input screen and fields, it'd be better time spent migrating to another language if it's that much work. I guess the alternative is to implement direct ncurses calls that replace the COBOL calls, or something like that.
There's also the alternative of adding most of the missing ACUCOBOL screenio parts into the compiler and runtime - please give this a real thought and discuss it with whomever "we" is.
Side note: I just added a first draft for DISPLAY SCREEN SIZE 80/132 (including runtime support). I have to check if it also works as expected, will come back to this over the weekend.
Another note: I suggest that you compile your sources with -std=acu-strict, otherwise you have all reserved words + acu reserved words in (for the source above -fnot-reserved=NOTHING may help a little bit.
Can you post the context of the mentioned errors (other than DISPLAY SCREEN SIZE? I think at least the error in ACCEPT-YES-NO-NON-CASS SECTION shouldn't happen and would try to tweak the parser, if possible.
Concerning the CONTROL KEY not being implemented: GnuCOBOL returns the key numbers that are defined in copy/screenio.cpy, not the ACUCOBOL ones (that may be changed with "keystroke" settings in the configuration and/or runtime). We could add a translation table in libcob and depending on the compiled module translate it, but even then we'd miss the complete keystroke settings - I'm not sure if this work is worth to do - but changing the control key codes and their evaluations in the COBOL sources to the standard key codes seems to be doable...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If reporting these types of things helps, I'll do so as much as you want. I have no doubt there's a bunch more errors for the compiler to spit out on this one!
I may go on a code hacking spree and delete/change every instance of problem to avoid it simple to see if I can make it work at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These are all very interesting parts and definitively help. Even if MOVE ... WITH CONVERSION END-MOVE (!).
I'll have a look at some of these after testing the DISPLAY SCREEN SIZE (so far the sources compile but I have to check if the new runtime parts actually work). Some of this will lead only to FR/Bug tickets being opened, others will be fixed or at least be improved.
Please give the context of the "REDEFINES clause not following entry-name" message.
Note: some parts like $XFD would only have a changed warning like "$XFD directive not supported" - as there isn't much use in this I will not look at this part.
I'll happily post some more then if they help spot things others have not come across.
I managed to get one of our bigger programs compiled (by butchering anything that failed) but it's giving error 30 on opening files. I can't get the system level error as it seems "C$RERR" isn't implemented and not seeing an equivilent in the docs.
FromourCOBOLruntimedocs:
30,xx30,xx30,xx30,xxPermanenterror.Thisisanyerrornototherwisedescribed.Thesecondarycodevalueissettothehostsystem's status value that caused the error. See your operating system user manual for an explanation and C$RERR in Appendix I.
The vutil info says it's a "vision version 3" and I'm pretty sure its a standard AcuCOBOL vision file, which the docs imply are supported. The error 30 isn't terribly helpful on it's own! Or is this a case where I need VBISAM?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it a native vsam (isam) file? If so, you will need berkly or vsam... I would think. We had to rebuild all of our MicroFocs vsam files using GnuCOBOL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's an AcuCOBOL ISAM (which they call Vision) file so I think the answer is "No, it's not native ISAM/VSAM".
I did some digging and found reference to it being a proprietary file format, so I imagine there is no support for it in the opensource world.
I have come across some commercial code-converters (COBOL-to-JAVA is the example) that have native support for it, but I must assume that's been reverse engineered or something.
I suspect then my only fallback is to use vutil to dump the file to a flat file and write an importer to convert it into a format that is supported by GnuCOBOL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, MF is proprietary too (not native, silly me). We dumped the MF isam file to a flat sequential file , then read it in and wrote out as isam dynamic sequential. From then on everything worked as before.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem with that method is that we need to run both platforms at once. The headless process is a networked service, but it accesses the same files and uses the same copy files as the rest of our platform. Since we can't port the rest of the stuff as-is (due to the graphical screen nature) we need to keep the old stuff going.
The only way we could would be with a license to allow access to the hooks/drivers AcuCOBOL supply. That however seems a bit pointless!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
access the files from ACUCOBOL using ACU's EXTFH interface working with GnuCOBOLs file handler
I actually missed what you meant here. Re-reading it I realise you are saying the GnuCOBOL FH should be compatible with AcuCOBOL EXTFH. That'd be an interesting path to take, it it doesn't impact performance too much.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the vision files are a proprietary format.
The only ways of reading/writing them I know about is:
a) use EXTFH and from there call the acucobol runtime library directly to do this (should actually not have that bad overhead), but in this case you'd still need to have the acu license files (possilby for the system)
b) use EXTFH to call a socket server doing the file io, this has the benefit that you may use an old licensed installation to do the fileio only (the files would stay and completely be processed by the ACU runtime) [note: I've actually did thissome years ago to "save" acu license costs, not via EXTFH but from COBOL (which introduces overhead and more important: changes to the COBOL sources)
c) reverse engineer vision access (I think I have some reverse-engineered German documentation), could be included in libcob directly or be used by EXTFH - this is most "convenient" for a possible migration but has the highest chance of not being reliable...
Note: As this was brought up by Mickey: for Micro Focus ISAM files there is an alternative - DISAM is able to process the files - you can get an evaluation license from them and after installing it can re-configure GnuCOBOL to use it).
In general conversions from one COBOL system to another normally means: write export/import programs in COBOL for all ISAM and possibly for relative files.
Doing this instead of vutil -export has the benefit that all exported data will be USAGE DISPLAY and can be checked on export [ACUCOBOL allows any data to be saved in VISION files in PIC 9(something), GnuCOBOL with -debug will error there]. They often can be generated (it actually should be possible to write a generator reading the XFD files, if you know how to process them).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks like I'll have to read the docs around EXTFH, no idea what that is or how it works, but sounds like it could use our existing setup without too much trouble - though overhead could be a big downside, some of this code is critical path, handling thousands of requests a minute.
Basically anything that involves having to re-write all our files would sort of defeat the purpose of why I'm investigating this right now. If I could do a wholesale conversion of all code that'd be different, but that's not viable yet.
That could be offset though if GnuCOBOL is actually faster at runtime than AcuCOBOL, I can't find an entry about that in the wiki - what is the performance like vs commerical runtimes?
Also some new quirks for you:
EXITPROGRAM
doesn't exit the program. I had to change it to:
STOP RUN
and no-op paragraphs that look like this:
para-name.
.
get the redundant . reported as being in the proceeding non-no-op paragraph.
But in better news, I got the 88,489 line service program to compile at least. It just can't use any files!
Last edit: D.Jen 2018-06-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks like I'll have to read the docs around EXTFH...
I know about EXTFH in general but never used it myself. Normally EXTFH (with direct runtime access) should be quite fast.
That could be offset though if GnuCOBOL is actually faster at runtime than AcuCOBOL, I can't find an entry about that in the wiki - what is the performance like vs commerical runtimes?
I'd search for quotes about tests in the FAQ - this is likely something Brian would have added.
My personal experience when comparing GnuCOBOL with -debug to ACUCOBOL-GT with -Za (less checks but at least some) when running in "VM" mode: GnuCOBOL is faster in most areas, especially in handling big numbers or variables >32/64k (with lot less regressions for new coding).
I haven't checked ACUCOBOLs performance with "native code generation" instead of ".ACU" (or whatever you use for CODE-SUFFIX), as far as I know using this makes ACUCOBOL faster than the "VM" mode (what do you use?).
I haven't checked BDB/VBISAM performance in the last years, when doing the tests last time it was at least acceptable, maybe better than VISION.
It would definitely be good if you could benchmark this yourself (in general all benchmarks are "relative" if not done on the actual code to run).
GnuCOBOL is slower on compilation, especially if you let the compiler do more optimizations (the reason for this is that GnuCOBOL produces C intermediates with very big functions [this is on my TODO pile for long time, but hasn'ta big priority]). But compilation time is normally no big issue (especially as you don't need full optimizations during coding).
Concerning EXIT PROGRAM: it does what it is expected to do - leaves the program to the caller if the programm was CALLed, otherwise it is a no-op. GOBACK will always get back (either to the caller or to the OS), STOP RUN always exits the runtime. I'm quite sure ACUCOBOL behaves the same.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're likely right. All of our programs are run via an ROOT and LOGIN program, so EXIT PROGRAM always behaves like STOP RUN. I was introduced to COBOL in such as way that I've sort of learnt it like that! Bad habit etc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't find any examples or documention on how to use this.
It sounds like a feature where I'd need to write a file handler that hooks into the AcuCOBOL file handler/runtime, in order to allow GnuCOBOL to read Vision Files. Is that right?
I can find literally no info about (a) how to do this in GnuCOBOL and (b) nothing in the AcuCOBOL docs about how you can access files this way (if indeed they even support it!).
re: performance
Yes, there's mention of some massive cluster and it performing well, but that's not terribly relevent to our use case. It seems though that it should be pretty performant. We wouldn't care about compile time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah right, not part of the main docs. Google also failed me! Thanks :)
Are there no docs and/or examples for getting GnuCOBOL to use other file types? I saw some rough-and-ready proposed changes from a few years back about how to implement your own FH against the GnuCOBOL source, but nothing about linking to an existing external FH.
In the end, we may be able to get away with a use case where we convert the files periodically for the service I am trying to implement - at least in the short term and as a proof-of-concept.
I'm wondering how all these companies that offer commercial solutions such as "COBOL-to-JAVA" impplement their VisionFile reading, as they usually can do so natively. Is it likely it all based on reverse engineering?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying out the compiler (3.0rc1 under OSX) against a very large
code-base that makes constant use of text-screen layout to represent input
fields, column data, record display and report output.
However, I seem to be stuck from the outset with constant warnings and
errors along the lines of:
And in related code, accepting screen input gives:
The code looking like this:
And again:
Is GnuCOBOL not nearly as compatible as I thought, or am I just "using it wrong"?
Related
Wish List: #322
Last edit: Simon Sobisch 2018-06-06
Hello Anonymous and welcome to GnuCOBOL.
GRAPHICAL WINDOWlikely means this is old ACUCOBOL-GT code, correct?If yes: this special ACUCOBOL-only extension isn't implemented and the code would need to be changed. If not: please provide a code sample and specify the old compiler.
POSis a reserved word which has a different meaning in different implementations. Did you specify any-stdoption that matches the "old compiler"?In any case think this code part will work if you add
-freserved=POS:POSITION(or if you use-std=acucorrect config/acu.words to use this, RC2 will have this adjusted, I just need to check which other compilers this applies to before commiting it).The "unexpected
SCREEN" is likely a parser error that could be fixed for RC2, please provide a minimal sample showing only this part and I'll inspect it.The
CONVERSIONpart is currently implemented, yet. To ensure you have a numeric field in there do aMOVE FUNCTION NUMVAL (FIELD-NUMBER) TO FIELD-NUMBER, but in general theACCEPTthere iwll work.I don't know how compatible you thought it is. As there's no information about old/new in this post it is hard to guess anything...
In general: extensions to
SCREENsection andACCEPT/DISPLAYare common but very different from each implementation to the other. Part of these extensions are implemented, others not. In general we aim to not raise a "syntax error" for code that works in a different environment (when the specific flags are used). Adding runtime support for screenio extensions is not a big priority as many COBOL programs are either batch processing or use GUIs written in other languages. Patches are always welcome and inspected...Hi Simon,
That is a very detailed and helpful reply, thank you!
Yes, this codebase makes heavy use of AcuCOBOL GT Screen IO, Windowing, etc - sadly, it's such a large application, I doubt we'd want to look into re-writing all the input screen and fields, it'd be better time spent migrating to another language if it's that much work. I guess the alternitve is to implement direct ncurses calls that replace the COBOL calls, or something like that.
For interests sake, here is the output from one of our smallest data editing programs:
I was directed here by someone telling me "Oh it's basically feature complete" so had rather higher expectations than perhaps I should have! On the other hand, given where it's at now, it's pretty damn impressive, regardless of it lacking a few less common usages.
Just sayin', but this is a free(dom) compiler. Weigh the work required to get GnuCOBOL able to compile your source code inventory against rewriting parts or the whole. It's an option, Might not be a viable option (depending on hours estimated) but it could very well be a least effort path (with all business rules intact).
I have it on good authority (eye balls on cobc/parser.y) that a whole pile of new reserved words are in GnuCOBOL 3-prerel and things like support for "GRAPHICAL WINDOW" are marked as PENDING (what you see as is not implemented. I may well be letting cats out of bags, but all you have to do is look at the sources in trunk (it's a fairly transparent bag), or I've just been away for too long and missed the memo :-) I care about these things as the FAQ is now in need of some 300+ new reserved word entries. Looking forward to updating the docs (even if the first phase is simply documenting things as "pending").
I've been away for the last 6 months, and mostly out of the loop, but this is looking very complete (in terms of lexical parse) and very cool and giddy making (in terms of future outlook).
If experiments work out as they look like they will, we'll have access to a library (libAgar) that may really accelerate providing cross platform runtime support for graphical user interface programming in GnuCOBOL. Plus, just noticed that libAgar has added Web as a core feature, pretty colours AND network application goodness.
Have good, make futures,
Blue
Last edit: Brian Tiffin 2018-06-07
Sounds like some real progress is being made. Contributing to this development is a thought, however we don't have any devs with strong C skills so that could be a hinderance.
It's safe to say we use COBOL in a way that most people do not. We run it as a distributed platform across many servers, running a UI over an ssh connection. We're keen to get out of it but with all the business logic and existing userbase... well you know how it is.
We do have some services that have no UI that could possibly work, though my first attempt at just throwing it at the compiler resulted in 102 (or so) errors before "Too many errors" kicked in.
Yes, getting the parts that have no UI to work should be the first thing to do.
As noted GnuCOBOL can be adjusted and I may be able to do this when specific errors are specified, ideally with a minimal compilable sample.
Another part that could be done (and seems especially reasonable with your applications): get COBOL coders to split the UI programs to a "mostly UI" and "only business logic" parts.
The good thing about this:
In the end it may be possible to replace the UI parts but keeping the working and grown business logic as-is.
A new UI has always the potential of additional benefits for the operators (possibly needs additional COBOL programs to support new stuff, but this is a different issue).
Actually it is mostly missing only vendor extensions, especially ACUCOBOL-GT screen extensions - and if I'm not wrong no other compiler or migration to X will work with heavy used ACUCOBOL-GT screen extensions.
Other than the complete
USAGE NATIONAL / BIT / ...(ok, we actually have more than one post COBOL 85 parts open) there's primary the OO part currently missing, but I hope we have something stable for the OO part in 2019, too.There's also the alternative of adding most of the missing ACUCOBOL screenio parts into the compiler and runtime - please give this a real thought and discuss it with whomever "we" is.
Side note: I just added a first draft for
DISPLAY SCREEN SIZE 80/132(including runtime support). I have to check if it also works as expected, will come back to this over the weekend.Another note: I suggest that you compile your sources with
-std=acu-strict, otherwise you have all reserved words + acu reserved words in (for the source above-fnot-reserved=NOTHINGmay help a little bit.Can you post the context of the mentioned errors (other than
DISPLAY SCREEN SIZE? I think at least the error inACCEPT-YES-NO-NON-CASS SECTIONshouldn't happen and would try to tweak the parser, if possible.Concerning the
CONTROL KEYnot being implemented: GnuCOBOL returns the key numbers that are defined in copy/screenio.cpy, not the ACUCOBOL ones (that may be changed with "keystroke" settings in the configuration and/or runtime). We could add a translation table in libcob and depending on the compiled module translate it, but even then we'd miss the complete keystroke settings - I'm not sure if this work is worth to do - but changing the control key codes and their evaluations in the COBOL sources to the standard key codes seems to be doable...There is, but I doubt it's something we can engage in right now. We lack C developers and time!
Sure, here's the paragraph:
And if you are interested, some other examples from a much large headless program:
I'd sort of expect this one to be a warning, about a no-op that is being ignored by the compiler, rather than an error?
If reporting these types of things helps, I'll do so as much as you want. I have no doubt there's a bunch more errors for the compiler to spit out on this one!
I may go on a code hacking spree and delete/change every instance of problem to avoid it simple to see if I can make it work at all.
Oh and this one jumped out at me too:
These are all very interesting parts and definitively help. Even if
MOVE ... WITH CONVERSION END-MOVE(!).I'll have a look at some of these after testing the
DISPLAY SCREEN SIZE(so far the sources compile but I have to check if the new runtime parts actually work). Some of this will lead only to FR/Bug tickets being opened, others will be fixed or at least be improved.Existing tickets from a quick check:
END-IF": [feature-requests:#288]COMP-N- [feature-requests:#219] with the note "if byteorder is not important define as COMP-N=COMP-X" for example with-freserved=COMP-N:COMP-X.ACCEPT FROM CENTURY-DAY[feature-requests:#320] --> will get in very soonPlease give the context of the "REDEFINES clause not following entry-name" message.
Note: some parts like
$XFDwould only have a changed warning like "$XFD directive not supported" - as there isn't much use in this I will not look at this part.Related
Wish List: #219
Wish List:
#288Wish List: #320
Last edit: Simon Sobisch 2018-06-19
I'll happily post some more then if they help spot things others have not come across.
I managed to get one of our bigger programs compiled (by butchering anything that failed) but it's giving error 30 on opening files. I can't get the system level error as it seems "C$RERR" isn't implemented and not seeing an equivilent in the docs.
The vutil info says it's a "vision version 3" and I'm pretty sure its a standard AcuCOBOL vision file, which the docs imply are supported. The error 30 isn't terribly helpful on it's own! Or is this a case where I need VBISAM?
Is it a native vsam (isam) file? If so, you will need berkly or vsam... I would think. We had to rebuild all of our MicroFocs vsam files using GnuCOBOL.
It's an AcuCOBOL ISAM (which they call Vision) file so I think the answer is "No, it's not native ISAM/VSAM".
I did some digging and found reference to it being a proprietary file format, so I imagine there is no support for it in the opensource world.
I have come across some commercial code-converters (COBOL-to-JAVA is the example) that have native support for it, but I must assume that's been reverse engineered or something.
I suspect then my only fallback is to use vutil to dump the file to a flat file and write an importer to convert it into a format that is supported by GnuCOBOL.
Yes, MF is proprietary too (not native, silly me). We dumped the MF isam file to a flat sequential file , then read it in and wrote out as isam dynamic sequential. From then on everything worked as before.
The problem with that method is that we need to run both platforms at once. The headless process is a networked service, but it accesses the same files and uses the same copy files as the rest of our platform. Since we can't port the rest of the stuff as-is (due to the graphical screen nature) we need to keep the old stuff going.
The only way we could would be with a license to allow access to the hooks/drivers AcuCOBOL supply. That however seems a bit pointless!
You actually could do the following:
I actually missed what you meant here. Re-reading it I realise you are saying the GnuCOBOL FH should be compatible with AcuCOBOL EXTFH. That'd be an interesting path to take, it it doesn't impact performance too much.
Yes, the vision files are a proprietary format.
The only ways of reading/writing them I know about is:
a) use EXTFH and from there call the acucobol runtime library directly to do this (should actually not have that bad overhead), but in this case you'd still need to have the acu license files (possilby for the system)
b) use EXTFH to call a socket server doing the file io, this has the benefit that you may use an old licensed installation to do the fileio only (the files would stay and completely be processed by the ACU runtime) [note: I've actually did thissome years ago to "save" acu license costs, not via EXTFH but from COBOL (which introduces overhead and more important: changes to the COBOL sources)
c) reverse engineer vision access (I think I have some reverse-engineered German documentation), could be included in libcob directly or be used by EXTFH - this is most "convenient" for a possible migration but has the highest chance of not being reliable...
Note: As this was brought up by Mickey: for Micro Focus ISAM files there is an alternative - DISAM is able to process the files - you can get an evaluation license from them and after installing it can re-configure GnuCOBOL to use it).
In general conversions from one COBOL system to another normally means: write export/import programs in COBOL for all ISAM and possibly for relative files.
Doing this instead of
vutil -exporthas the benefit that all exported data will be USAGE DISPLAY and can be checked on export [ACUCOBOL allows any data to be saved in VISION files in PIC 9(something), GnuCOBOL with -debug will error there]. They often can be generated (it actually should be possible to write a generator reading the XFD files, if you know how to process them).Looks like I'll have to read the docs around EXTFH, no idea what that is or how it works, but sounds like it could use our existing setup without too much trouble - though overhead could be a big downside, some of this code is critical path, handling thousands of requests a minute.
Basically anything that involves having to re-write all our files would sort of defeat the purpose of why I'm investigating this right now. If I could do a wholesale conversion of all code that'd be different, but that's not viable yet.
That could be offset though if GnuCOBOL is actually faster at runtime than AcuCOBOL, I can't find an entry about that in the wiki - what is the performance like vs commerical runtimes?
Also some new quirks for you:
doesn't exit the program. I had to change it to:
and no-op paragraphs that look like this:
get the redundant . reported as being in the proceeding non-no-op paragraph.
But in better news, I got the 88,489 line service program to compile at least. It just can't use any files!
Last edit: D.Jen 2018-06-08
I know about EXTFH in general but never used it myself. Normally EXTFH (with direct runtime access) should be quite fast.
I'd search for quotes about tests in the FAQ - this is likely something Brian would have added.
My personal experience when comparing GnuCOBOL with
-debugto ACUCOBOL-GT with-Za(less checks but at least some) when running in "VM" mode: GnuCOBOL is faster in most areas, especially in handling big numbers or variables >32/64k (with lot less regressions for new coding).I haven't checked ACUCOBOLs performance with "native code generation" instead of ".ACU" (or whatever you use for CODE-SUFFIX), as far as I know using this makes ACUCOBOL faster than the "VM" mode (what do you use?).
I haven't checked BDB/VBISAM performance in the last years, when doing the tests last time it was at least acceptable, maybe better than VISION.
It would definitely be good if you could benchmark this yourself (in general all benchmarks are "relative" if not done on the actual code to run).
GnuCOBOL is slower on compilation, especially if you let the compiler do more optimizations (the reason for this is that GnuCOBOL produces C intermediates with very big functions [this is on my TODO pile for long time, but hasn'ta big priority]). But compilation time is normally no big issue (especially as you don't need full optimizations during coding).
Concerning
EXIT PROGRAM: it does what it is expected to do - leaves the program to the caller if the programm wasCALLed, otherwise it is a no-op.GOBACKwill always get back (either to the caller or to the OS),STOP RUNalways exits the runtime. I'm quite sure ACUCOBOL behaves the same.You're likely right. All of our programs are run via an ROOT and LOGIN program, so EXIT PROGRAM always behaves like STOP RUN. I was introduced to COBOL in such as way that I've sort of learnt it like that! Bad habit etc
I can't find any examples or documention on how to use this.
It sounds like a feature where I'd need to write a file handler that hooks into the AcuCOBOL file handler/runtime, in order to allow GnuCOBOL to read Vision Files. Is that right?
I can find literally no info about (a) how to do this in GnuCOBOL and (b) nothing in the AcuCOBOL docs about how you can access files this way (if indeed they even support it!).
Yes, there's mention of some massive cluster and it performing well, but that's not terribly relevent to our use case. It seems though that it should be pretty performant. We wouldn't care about compile time.
For EXTFH documentation in ACUCOBOL have a look at https://supportline.microfocus.com/000/Interoperability%20Guide.pdf chapter 11.6
Ah right, not part of the main docs. Google also failed me! Thanks :)
Are there no docs and/or examples for getting GnuCOBOL to use other file types? I saw some rough-and-ready proposed changes from a few years back about how to implement your own FH against the GnuCOBOL source, but nothing about linking to an existing external FH.
In the end, we may be able to get away with a use case where we convert the files periodically for the service I am trying to implement - at least in the short term and as a proof-of-concept.
I'm wondering how all these companies that offer commercial solutions such as "COBOL-to-JAVA" impplement their VisionFile reading, as they usually can do so natively. Is it likely it all based on reverse engineering?
We generate .obj files and run them with runcbl, which seems pretty performant for our heavy work loads.