6 ms·

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 fee

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.

emersonrsantos 8y ago
> 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.
gaius 8y ago
has some things to teach us today, but few are interested The mainframe style is being reinvented in half-arsed way as “microservices”, they are super fashionable right now. I shudder to think what monstrosity the full stack crowd will come up with when they try to reinvent CICS too...
- twic 8y ago
  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.
  - lokedhs 8y ago
    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.
DrScump 8y ago
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.
- le-mark 8y ago
  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.
  - DrScump 8y ago
    Somebody had an IEBGENER fetish, maybe? 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.
- lokedhs 8y ago
  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.

emersonrsantos 8y ago

> 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.

gaius 8y ago

has some things to teach us today, but few are interested The mainframe style is being reinvented in half-arsed way as “microservices”, they are super fashionable right now. I shudder to think what monstrosity the full stack crowd will come up with when they try to reinvent CICS too...

twic 8y ago
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.
- lokedhs 8y ago
  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.

DrScump 8y ago

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.

le-mark 8y ago
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.
- DrScump 8y ago
  Somebody had an IEBGENER fetish, maybe? 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.
lokedhs 8y ago
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.