Question: Should I stay with this extension or move to bitlang.gnucobol?

[Smitty2018]

This isn't a bug report but a question, if this isn't the right place to ask then please point me to the correct one.

Context: A customer wants to drop his costs and asked for a gnucobol port of the application. I've found there was a "3.2 preview" release two weeks ago with claimed improved support for MF so I'll try to compile everything with "cobc -std=mf" and see where I land. I'm lucky that there is no object oriented cobol in the code, gnucobol obviously lacks this completely, this is an Oracle only application so no files need to be converted either. The code will stay "as-is" where possible and hopefully don't need too much adjustments - in every place it does conditional compilation should be used.

While I'm not sure yet how this works out, I'd like to keep the IDE support.

Questions: Do I need to wait for a newer version of bitlang.gnucobol or should I use an older version of gnucobol (3.1.2 vs. 3.2)? Would it be reasonable to move to bitlang.gnucobol for this project or stay with bitlang.cobol? Maybe I should install both, but I guess only one can be active.

Additional question: Do you have a suggestion how to use conditional compilation so that "cob" will use the code as-is and only "cobc" will use the new one?

[spgennard]

Re: context

I would recommend you & your customer consider speaking to Micro Focus about the reasons for moving away from them.

The benefits of using the Micro Focus COBOL platform are huge and worthy of further consideration.

Next, it is worth understanding that Visual Studio Code is a code editor, not an Integrated Development Environment.

Do I need to wait for a newer version of bitlang.gnucobol or should I use an older version of gnucobol (3.1.2 vs. 3.2 When 3.2 is available is GA and rolled out, I expect the bitlang.gnucobol will catch up with the support.

It is worth noting, I don't know of any gnucobol debugger that works the bitlang.gnucobol extension.

Maybe I should install both, but I guess only one can be active. You can enable/disable extensions on a per-workspace basis.

Additional question: Do you have a suggestion how to use conditional compilation so that "cob" will use the code as-is and only "cobc" will use the new one?]

Stick with Micro Focus and the problem goes away :-)

[spgennard]

@Smitty2018 - Happy with the answer?

[Smitty2018]

I'm not in the position to decide about sticking with Micro Focus, but passed the suggestion. I was told that there are some big $$$ paid for annual licenses and as Micro Focus bills only increased over the years no one believed that the account manager even has the option to cut that bill without decreasing the number of licenses...

So I'm kind of back in the original place.

Rechecking showed that the Micro Focus extension actually does provide quite a nice debugging experience. It is much easier to get started with it than with Animator; I guess there's likely some features missing of that on the other hand... not sure but as I like it I'll surely do some serious debugging with the Micro Focus extension :-)

Some testing with a debugger for GnuCOBOL showed very nice results with the gnucobol debug extension from the market place - but that extension seems to only work with simple programs / setup as it always does a recompile when clicking on debug... note: that extension suggests to use bitlang.cobol :-)

Checking more led to another debugging extension found at https://gitlab.cobolworx.com/COBOLworx/cbl-gdb-vsextension. It needs a one time recompile with the cobc wrapper cobcd; but as one can always use it (there's even no .idy as with Micro Focus and I did not found a speed difference either) that's not that big deal. This extension provides "less good but working results". You may want to test those two if you want to find out about a debugger that works with bitlang.gnucobol.

It just was... quite strange that the bitlang.cobol extension totally freaked out as long as those debugging extensions were enabled (even when I was not using them); I guess that's part of the answer to my original question and says "there is a conflict between bitlang.cobol and bitlang.gnucobol". bitlang.gnucobol also warned about duplicate functionality in bitlang.cobol; but this was just a warning instead of the "I won't work correct, so I disable myself" seen there. I have to admit that I fail to see why it doesn't work correct when there's an extension enabled that isn't used and think a warning like in the other extension would be enough.

As I now have the Micro Focus extension active I've thought that bitlang.cobol isn't needed anymore in the Micro Focus environment, but from the documentation "go to" and friends need VC8 - and there is only VC7 installed. Using bitlang.cobol for view/edit and the Micro Focus extension for debugging does work quite well, so that's no problem.

As noted above I'm still not sure what the answer to my question is. Maybe I need to create a second vscode installation using "portable mode" https://code.visualstudio.com/docs/editor/portable for the gnucobol experiment and only install the bitlang.gnucobol and cbl-gdb in there?

[spgennard]

One of the disadvantages of vscode is the way it handles languages, if you have multiple extensions that work on the same language, you either get missing, duplicate or recursive events or it simply uses the wrong extension (due to the extensions registering different languages id for the same file extension)... then comes the problem of ensuring the visualisation of code matches the debugger and breakpoints can set etc..

Given these numerous problems, I have found the best thing was to try and guide/find mismatches between various extensions and warn or disable this extension.

With this extension, I try to ensure it will work as well as it can with the "real" Micro Focus COBOL extension, especially the debugging support, so I am glad you find it useful.

Have you or your customer considered speaking to someone other than pre-sales/sales? If, so I would contact: Scot Nielsen, feel free to mention me, "Stephen Gennard", as Scot knows me :-)

[github-actions[bot]]

Stale issue message

[Smitty2018]

Have you or your customer considered speaking to someone other than pre-sales/sales? If, so I would contact: Scot Nielsen, feel free to mention me, "Stephen Gennard", as Scot knows me :-)

I'm not the one speaking to Micro Focus, but I've only heard of sales contacts so far. I don't think that anyone has considered speaking to someone else but sales about the license topic. I'll drop that note and see where this is going to and think this suggestion will help others, too.

Until my project is changed (I'm still tasked with the evaluation, did not found much time for that in the last week), I'm going with a single vscode installation (just updated to 1.73) using two code-workspace approach. One workspace is used for Micro Focus using their extension and bitlang.cobol [especially for debugging] and the other one is used with COBOLworx.cbl-gdb and bitlang.gnucobol as using "deactivate in this workspace" for the other extensions works well.

Note: the gnucobol extension seems to miss some parts, for example the IntelliSense example given in bitlang.cobol does not work ("add 1 to" shows the alphanumeric variables first) and the "peek definition" command is missing as well as the copybook extension setting. Should I detail these as issues in https://github.com/spgennard/vscode_cobol4gnucobol or better request a "don't check for incompatible addons" here? (bitlang.cobol seems to work much better than bitlang.gnucobol but deactivates itself when the other debugging extension is enabled)

[Smitty2018]

I should also said that Micro Focus also provide the COBOL-IT product, which includes an eclipse environment and a debugger.

 

Thanks for pointing out more possible alternatives!

 

So you say I should ask to possibly switch to COBOL-IT instead of GnuCOBOL if this experiment doesn't work out? For using COBOL-IT along with vscode, I'd then stay with bitlang.cobol, but there isn't a debugging frontend for vscode available yet, correct?

 

The website https://www.cobol-it.com is currently down - Do you know if ít has current updates and plans to support vscode?

And most important: Should it be possible to switch from Micro Focus COBOL to COBOL-IT without changes / with less changes than GnuCOBOL?

I have not found anything but different command line options and the need to set some runtime options in GnuCOBOL so far, but I've not compiled the complete source either, much less ran more than some smaller programs.

[github-actions[bot]]

Stale issue message

[Smitty2018]

Just an update on the side issue - the COBOL-IT website is back, now forwarding to https://www.microfocus.com/en-us/cobol-it. That seems like an option if the "leave" is already fixed. As noted I'll keep that in mind (and have now found that this is Eclipse centered without any note on possible updates for vscode support; with portlist from 2016!). So it is more likely to either stay with MF or move to gnu.

Concerning the original "question issue" - this is solved for me so I'm closing it now. Thank you for all the pointers you've shared! I'll create a "real issue" for the other point next.