But to be fair this doesn’t really install COBOL on your computer. GnuCOBOL is a transpiler that parses COBOL and converts it to C before compiling it. This feels a bit like cheating.
This is curious statement, what is cheating about it? I suppose this person equates Cobol with mainframes, and wants the Real Experience. Hopefully the author doesn't go down the rat hole of setting up Hercules with a 1970's era version of MVS operating system, and tries to learn enough JCL to execute the compiler. That's truly a waste of time.
Besides, not all machines that ran Cobol were EBCDIC, there were (are) a lot of ASCII machines, including anything running GnuCobol. The key thing you're learning about with Cobol is fixed length files, and storage formats like Display, Zoned Decimal, Packed, and Binary.
Otherwise the article has some good links and solid history.
I personally think Cobol and the mainframe model of resource sandboxing has some things to teach us today, but few are interested.
JCL isn't scary. Think environment variables plus shell scripting.
In the mainframe environment where I started my career, OS JCL was sort of viewed as a black art by most of the programmers (plus an annoyance, as production JCL had to be initially submitted on cards).
I came from the system side, so I was happy to take over all the JCL issues for my group. I'd set it up how I wanted in a flat file on TSO, spool it to the JES2-connected card punch, and bingo! That also let me comment the non-intuitive elements for the computing center folks, minimizing 3AM call-ins when feeding-system issues made us improvise input checks. Literally nobody had thought of doing production JCL that way before I did.
I regularly (well, every few years) set up Hercules with MVS just to get a feel for it, and try to learn a little bit more about JCL and the likes.
Usually this lasts a few hours before I get frustrated and stop.
The problem I have is that the system is not really lending itself to exploration. I might download a tape image containing some software I want to try, but there is zero information aimed at beginners explaining how to actually get this software running.
Even figuring out how to exit the text editor in TSO took a long time, and I remember resorting to rebooting the system just to get out of it.
I assemble an assembly program once. I did it by feeding a deck directly to the reader, and seeing the result was pretty cool. Unfortunately I haven't been able to repeat that since I don't know where I found the example code that I used.
I'd love to see a tutorial that goes a bit deeper than just how to list datasets in TSO. However, the number of people like me that would appreciate it is likely in the single digits, so it's understandable that it doesn't exist.
JCL isn't scary. Think environment variables plus shell scripting.
I wager you didn't see it abused. I actually hold ignoble honor of reverse engineering and implementing a complete JCL parser, validated on a million line batch system. The most egregious thing I saw there was; there were a set of jobs that essentially processed tree data structures as flatfiles, by building flat files of sub trees and resubmitting themselves. I really lol'd when I saw that.
Speaking of ugly JCL, it was typical of my environment for production jobs to not bother with cosmetics and comments since changing anything was a manual process requiring either sitting at the keypunch or writing it out in character grid boxes for keypunch operators. This made meaningful comments rare and (when present) hard to find or read. When I redid all our jobs' JCL via ISPF, I could not only easily reformat it all for readability and clarity, but I described all the passable parameter switch options right in the JCL right in context.
Generation X had a go at it with Tuxedo and the early versions of Java EE. I'm actually looking forward to the millennials' attempt, so we're not alone in our shame.
Wasn't the first version of J2EE great? You configured the components by writing Java classes that implemented certain interfaces and dropping the .class files in a special directory.
With that in mind, the XML files that came later was a huge improvement.
> Hopefully the author doesn't go down the rat hole of setting up Hercules with a 1970's era version of MVS operating system, and tries to learn enough JCL to execute the compiler. That's truly a waste of time.
Why? Cobol, JCL, RPG, ..., run on modern IBM MVS (OS/390, z/OS), unmodified. If someone seeks to learn IBM mainframe systems internals and don't have access to modern software, Hercules-390 and MVS 3.8 it's a viable option to get started as an application or systems programmer.
IBM has its own turnkey system called z/PDT so you can run a mainframe on your laptop, something that Hercules-390 can do too.
> Despite the fact that virtually no one learns COBOL anymore
Is this true? I mean, I know coding boot camp programs aren't emphasizing in COBOL, but I graduated from University of Wisconsin-Platteville in 2010 and was required to take a COBOL class. I asked our intern this year (also from UWP) and he confirmed that it's still a required course.
I did my first internship building an operations management system for auto dealerships using AcuCOBOL. Using COBOL, particularly when binding to a GUI, was painful.
I'm a CS undergrad, and my university doesn't teach COBOL in any classes. Sometimes, professors will try to tell us about things in an old language, but then realize there are very low chances the class will be familiar with that language. Many professors have asked if anyone in the room actually knows the language (COBOL, Pascal, Fortran, Scheme, Smalltalk, or something with similar age and popularity) and I'd say there's never more than 2% of people in the class who say they have.
Companies involved in keeping COBOL-based systems working say that 95 percent of ATM transactions pass through COBOL programs, 80 percent of in-person transactions rely on them, and over 40 percent of banks still use COBOL as the foundation of their systems. “Our COBOL business is bigger than it has ever been,” said Chris Livesey, senior vice president and general manager at Micro Focus, a company that offers modern COBOL coding and development frameworks.
The whole point here is that there's no inherent connection, and so the economy can get into a weird state where COBOL programmers are being paid high six-figure salaries simply because there are too few of them; and yet universities aren't bothering to run COBOL courses, perhaps having executed market research and found that nobody would actually take such courses.
This is true, as well, of FORTRAN programmers, by the by, and has been for the last two decades.
Personally, I think the supply isn't there for reasons both a bit like the lack of supply of sewage engineers, and like the lack of supply of IT workers for the porn "vertical": like sewage, COBOL-using employers are a job environment nobody wants (e.g. stodgy old banks that don't like change); and like porn, COBOL-using employers don't look good on a CV.
Is UW-P private? It would be very odd for a CS faculty to agree to that. More likely they have one or many very senior professors who are still very much into COBOL.
UW-P is a public university in Wisconsin. And you're right: the chair of the department when I was there was a huge proponent of COBOL. I know classmates who went on to do quite well working with COBOL in finance industries. I'd never have been able to tolerate it long term, regardless of pay.
I've been playing with GNU COBOL for fun, and while it implements a lot of the language, it lacks integration with external systems.
For example, you'd expect there to be a simple way to open a network connection. I mean, doing REST calls is one of the fundamental ways you communicate with other services these days. Well, GNU COBOL has no such libraries.
Another thing COBOL is famous for is good SQL integration. As far as I understand you have language-level integration with DB2 on the mainframes. Doing the same on Linux with Postgres would be nice, but there is no database integration at all. You're limited to flat files, whose names are hardcoded in the source code.
Only reason for cloud to be popular was IBM MAINFRAME is expensive. MIPS way of billing is complexer. The way things are going cloud is a going expensive. Blue metal still rocks.
COBOL is terrible to work in. I was forced to take it in my MIS program in the 90s. We had the option of taking COBOL II or C Programming. Easiest choice I ever made (C of course).
They touted how everyone would be able to get a job fixing Y2K bugs. All I could imagine was a job like Peter Gibbons. I wanted to work in future technologies, not those of yesteryear. Thank goodness the internet was taking off by the mid 90s, so it was easy to see where things were going.
This is curious statement, what is cheating about it? I suppose this person equates Cobol with mainframes, and wants the Real Experience. Hopefully the author doesn't go down the rat hole of setting up Hercules with a 1970's era version of MVS operating system, and tries to learn enough JCL to execute the compiler. That's truly a waste of time.
Besides, not all machines that ran Cobol were EBCDIC, there were (are) a lot of ASCII machines, including anything running GnuCobol. The key thing you're learning about with Cobol is fixed length files, and storage formats like Display, Zoned Decimal, Packed, and Binary.
Otherwise the article has some good links and solid history.
I personally think Cobol and the mainframe model of resource sandboxing has some things to teach us today, but few are interested.