It’s a long way from an IDE like the script kiddie generation is used to. It’s also a long way from EDT on VMS, less of a distance from LSE though. LSE (Language Sensitive Editor) didn’t have color but it did have built in language HELP. Don’t worry if you don’t like the color, I just happen to like the Solarized color scheme. You can choose your own.
The package control installation is broken. Lots of finger pointing going on between Bitbucket and the Sublime Text people. You can pull down OpenCobol support here. I haven’t paid much attention in the AGILE tools world. I don’t know if Bitbucket ate GitHub, or GitHub ate Bitbucket, or the package control install feature only works with Bitbucket, I just know it doesn’t work and they are pointing the finger at Bitbucket. I also know the OpenCobol plugin my link points to is on GitHub.
I will ass-u-me you have already installed GnuCOBOL on your system. Sadly the KDE Neon/Ubuntu repos only have
If you want the current stable release (2.2) you have to either add this PPA or build from source. We all wait with baited breath for version 3.x to come out so we can all have the COBOL report writer without having to build and use a branch.
Manual installation of the Sublime Text COBOL package requires you unzip the downloaded file into the proper directory.
Linux: ~/.config/sublime-text-3/Packages
OS X: ~/Library/Application Support/Subime Text 3/Packages
Windows: %APPDATA%\Sublime Text 3
By default, the plug-in, well, GnuCOBOL really, only supports the original 1970s COBOL fixed column layout.
According to the manuals for GnuCOBOL, much has actually changed in this format. Honestly, I think what has happened is Gnu doesn’t have the tools. The Sequence Number was never ignored back in the day. We had development tools which let us RESEQUENCE and SORT.
Vendors who shipped “changes” in source format shipped only the changed lines for each module. After you verified there were no collisions you appended the changes to the end of the existing .COB file then sorted prior to compile.
Every line had to have a unique line number and sometimes you were just hosed. The gap in line numbers wasn’t big enough for all of the lines you needed to insert. Our editors had RESEQUENCE commands which allowed you to resequence either the entire program (every line would be a multiple of 10) or just a range of existing line numbers. That last part got hairy when things were tight. Don’t worry about the six digit limit for line numbers. Most compilers of the day had an input limit you hit well before using up all possible numbers.
Column 7 is where some significant differences seem to happen.
We always had “*” for a comment and “-” for a literal or string continuation. I don’t know who added the “/” to be both a comment and listing formfeed. Gnu only honors the comment part anyway. Too few kids these days know how to use formfeed and raw ASCII files. The real shocker to me was the addition of “D” and “d” to indicate a line which will only be compiled when the program is compiled in DEBUG mode. Haven’t been following the standard since COBOL-85.
You can get single module compilation help but you really have to pick a COBOL style (and standard) then stick with it.
It may not be obvious from the screen shot but you can double click an error and be taken to it. Look at the compiler output window though. I had already set this up to use -free because I’m used to COBOL-85 and I haven’t noticed any line numbering tools with this plugin. Line numbers were great when the editor generated them for you, until you needed to insert. Most mainframe editors would let you put a star or something in the last digit of the line number you wanted lines after and it would insert a few prenumbered ones for you.
Another thing missing from the plugin is a toolbar/menu method of changing the compilation command. Once again, if you are sticking with a single style and single coding standard in your shop that isn’t a major hurt. It’s a hurt for a contractor working on multiple projects for multiple clients. You have to edit a file to change this.
The file you want is OpenCOBOL.sublime-build. I showed you the screenshot because this plugin seems to support the major COBOL systems with the exceptions of DEC/VAX COBOL, TANDEM COBOL, and Unisys COBOL.
Near the beginning of the file you will see the following:
{
"selector": "source.cobol",
"cmd": [
"cobc -fsyntax-only $file"
],
You just need to change the command switches following cobc. There are many switches. Here are some you really need to be aware of.
-x Build an executable program -std=<dialect> Compile for a specific dialect : cobol2002 Cobol 2002 cobol85 Cobol 85 ibm IBM Compatible mvs MVS Compatible bs2000 BS2000 Compatible mf Micro Focus Compatible default When not specified See config/default.conf and config/*.conf -free Use free source format -fixed Use fixed source format (default) -g Produce debugging information in the output -debug Enable all run-time error checking -o <file> Place the output into <file> -W Enable ALL warnings -Wall Enable all warnings except as noted below -Wobsolete Warn if obsolete features are used -Warchaic Warn if archaic features are used -Wredefinition Warn incompatible redefinition of data items -Wconstant Warn inconsistent constant -Wparentheses Warn lack of parentheses around AND within OR -Wstrict-typing Warn type mismatch strictly -Wimplicit-define Warn implicitly defined data items -Wcall-params Warn non 01/77 items for CALL params (NOT set with -Wall) -Wcolumn-overflow Warn text after column 72, FIXED format (NOT set with -Wall) -Wterminator Warn lack of scope terminator END-XXX (NOT set with -Wall) -Wtruncate Warn possible field truncation (NOT set with -Wall) -Wlinkage Warn dangling LINKAGE items (NOT set with -Wall) -Wunreachable Warn unreachable statements (NOT set with -Wall)
I would avoid putting -x or -o in this file. Yes, I’ve done it myself when I was working on a single source file executable, but a big part of the COBOL world is multiple source file systems.
