Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Has anyone here learned COBOL for fun?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 82 posts

Re: Ask HN: Has anyone here learned COBOL for fun?

#21

Post by mkesper »

CraigRo wrote: post #4

Yes, somewhat for fun and somewhat for work. There are online cobol fiddle environments that can help you. Data is stored in something like a c Union on a buffer, and the programming style is pre-procedural, sort of like a very easy assembly language. The language is very wordy, and there aren't a lot of standard libraries. It is ok for storing and updating records, but writing complex algorithms would be slow

Only very old editions of COBOL were pre-procedural. Not saying I would want to learn it "for fun". The only fun I had was trying to calculate in Input/Output storage (must be treated as write-only...) or maybe the many ways you could format your numbers. Modern Cobol could even be bearable (while wordy) but the environment in which it is normally used absolutely not: JCL lacks any unixy feel and everything on OS/390 is it's own special tool. Lucky if you even got DB2, not so lucky when having to do with VSAM...

Re: Ask HN: Has anyone here learned COBOL for fun?

#23

Post by queuebert »

smackeyacky wrote: post #8

Assembler is more rewarding as an intellectual exercise. Unless you really want to do rote record processing, in which case knock yourself out.

I agree, but getting to know some of the environments and JCLs in the Cobol world is useful breadth of knowledge to fight the Microsoft monoculture.

Re: Ask HN: Has anyone here learned COBOL for fun?

#24

Post by kimi »

pixl97 wrote: post #17

I've actually seen some of the COBOL that underpins these financial entities. Typically the code base and writing style has morphed into a number of nearly incompatible dialects over the decades it has ran at these places. I've never really learned enough about it to understand copybooks and the other functions/file types it has.

Decade? My team once happened to maintain a file that was originally checked-in in the 1970s... (edit: Not sure if I'm more in awe of the fact that the procedure was still used or because mainframe code was under version control in the 70s and you still can see who did what and why).

Re: Ask HN: Has anyone here learned COBOL for fun?

#26

Post by zoomablemind »

taway32r41 wrote: post #15

Like with most languages, learning the language is easy. Learning all the libraries, especially the undocumented proprietary ones, is the hard part.

I'd add that with legacy codebase the hardest thing is to untangle the business logic buried in. Some of it is likely still the core of the business but not many people, if at all, clearly know it and the docs are often dated and no longer in sync with the code.

In one word - minefield!

Re: Ask HN: Has anyone here learned COBOL for fun?

#27

Post by GianFabien »

There are lots of things that I would rather do for fun than program in COBOL.

I have programmed in COBOL on ICL and IBM computers. You don't just program in COBOL, you need to learn SQL, JCL, TSO, CICS, etc. Maybe it is simpler with MicroFocus (or similar) COBOL on Linux, haven't ventured there.

Re: Ask HN: Has anyone here learned COBOL for fun?

#28

Post by tyingq »

giaour wrote: post #10

I had to deal with a bunch of mainframes in a previous job and tried to learn a bit of COBOL. One interesting thing I learned early on was that programs are almost never written exclusively in COBOL. The language isn't Turing complete (by design), so a significant portion of a program's logic will be captured in the JCL (Job Control Language) script that configures how the program will run and orchestrates multiple p…

I'm with you on the idea that mainframe COBOL is typically only part of the actual program. But COBOL not being Turing complete sounds...not right.

Re: Ask HN: Has anyone here learned COBOL for fun?

#29

Post by theodpHN »

giaour wrote: post #10

I had to deal with a bunch of mainframes in a previous job and tried to learn a bit of COBOL. One interesting thing I learned early on was that programs are almost never written exclusively in COBOL. The language isn't Turing complete (by design), so a significant portion of a program's logic will be captured in the JCL (Job Control Language) script that configures how the program will run and orchestrates multiple p…

While much-maligned, what JCL (and software like CLISTs and REXX for interactive processing) brings to the table in the mainframe world is a STANDARD way for programmers to not only decouple code and the data resources the code will process, but also a wealth of other functionality, including job accounting, priority, job classes, network routing of jobs & resources, conditional execution, run-time library management, resource caps, output management, catalog management & file disposition, real temporary files, file versioning (GDGs), storage & device management including tape, procedures, includes, symbolic variables, checkpoint restarts, etc.).

In non-mainframe realms, while the good news is that there's no JCL, the bad news is that individuals and companies have pretty much reinvented the JCL wheel over and over again, creating their own hodgepodge of unique, non-standard efforts to deliver smidgeons of similar functionality hacked together from a mix of shell scripting, environment variables, YAML, JSON, other config files, manual prompting, third-party libraries and software, and even hard-coding resources in programs.

Grass is always greener, as they say. :-)

https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pag...

Post reply on HN