[lokedhs]

I agree. I have attempts to learn COBOL on a few occasions, but it's always stopped by the fact that there are, as far as I can tell, only three ways to do it without investing sometimes insurmountable amounts of money:

The first is GNU Cobol. It's quite functional for its intended purpose: To port mainframe applications to Linux. However, when writing a new application on Linux you usually want to do things like access arbitrary files (without hardcoding the filename in the source) or make network connections. It does have nice interactive screen support though.

The other option is to run MVS 3.8j in Hercules. This is a predecessor to the current z/OS which runs on mainframes today. The problem with this is that it's stuck in the 70's (which is when the last free version of MVS was released). A lot of work has been done by the community to keep it up to date, but the Cobol compiler is the language of 40 years ago, not modern Cobol.

None of the above options are really appealing unless you're like me and have a thing for messing around with stuff in their non-native environment.

The third option is: http://mtm2019.mybluemix.net/

When signing up, it gives you access to a z/OS account where you have a surprising level of access. It's probably running on an emulator (it's quite slow) but it does give you access to modern software, including compilers for Cobol, C, Java etc. It also has DB2 installed.

However, the purpose of this option it to learn z/OS, not necessarily learn Cobol. And developing using the ISPF editor isn't particularly nice. They do give you ssh access to the Unix-compatibility environment though so maybe it's possible to edit files using Tramp in Emacs locally. I haven't tried that.

In any case, what is needed is a proper Cobol development environment that you can run locally on your workstation. As far as I understand, that's how Cobol developers normally work. IBM would do well by releasing such a product for free. However, I'm not having high hopes given the fact that the mainframe division seem to be actively hostile to any free software (look into the difficulty the community has to get even the smallest community-made improvements accepted by z/OS, or releasing some small tool for the MVS community).

[YeGoblynQueenne]

>> They do give you ssh access to the Unix-compatibility environment though so maybe it's possible to edit files using Tramp in Emacs locally.

It's a UNIX shell. You can always use ed :)

[lokedhs]

You can actually ssh into it and use vi. That's probably the easiest way to do it. However, the edit-compile-test cycle is somewhat complicated.

You need to first edit the file, fine, you can use vi. Then you need to go into ISPF (or TSO) on a 3270 terminal to submit the batch job that compiles the code (and possible runs it). Then you need to go into SDSF to view the results of the compilation.

Back in the 70's this was an acceptable way of working, but not what a modern programmer would expect.

[SuperPaintMan]

You can submit jobs to JES2 from USS with a shell script. Easiest way I found was to fuse-mount a working directory, edit everything with VSCode/Vim With COBOL Extensions and have two shells, one constantly reading the output data file and another for submitting job cards.

[lokedhs]

Thanks for the information. I assume actual mainframe developers do these things. But can you do that from the environment provided to me you by master the mainframe?

On the MVS 3.8j side, I can submit a job directly via the virtual card reader and then read the results directly from the printer and feed it into Emacs. That's the most efficient way to work with Hercules but you'll be stuck with a very old version of Cobol.

[YeGoblynQueenne]

>> You need to first edit the file, fine, you can use vi. Then you need to go into ISPF (or TSO) on a 3270 terminal to submit the batch job that compiles the code (and possible runs it). Then you need to go into SDSF to view the results of the compilation.

Well, I don't know how you can avoid that part, i.e. submitting a batch job and looking at the results separately. SuperPaintMan describes an alternative but I'm not sure how this works. When I was working on a mainframe, it was like you say, except I couldn't edit files remotely with vi - because big financial corporation security :)

To be fair, I didn't try. There probably was a way. I didn't mind the editor I had on ISDF, EZY editor. The only annoying thing was that, if I understand this correctly, EBCDIC doesn't have an end-of-line character so I couldn't just control-End to go to the end of a line, I had to use the arrow keys or touch the mouse (yuck!).

[selimthegrim]

This sounds like university HPC today