[HN Gopher] Learning COBOL: A Journey for the Modern Programmer ...
___________________________________________________________________
Learning COBOL: A Journey for the Modern Programmer (2021)
Author : rbanffy
Score : 54 points
Date : 2023-04-27 11:26 UTC (2 days ago)
(HTM) web link (monadical.com)
(TXT) w3m dump (monadical.com)
| tapland wrote:
| Been doing COBOL for the past five years, so it's been my main
| thing since leaving school.
|
| A on of insurance companies, banks, telcos, airlines and old
| government systems for anything related to healthcare and taxes
| still use it and it's not all IBM Mainframes. I think IKEA just
| recently migrated away from it but a lot of companies with old
| inventory systems still do use COBOL.
|
| The language is easy, systems and products gigantic, your mentors
| write their code (incl. Java) in a 55x132 char terminal and
| sometimes there is even more than absolutely no documentation!
|
| It's fun but I'll probably want to do something more modern for a
| while before maybe returning to the old systems.
|
| For anyone interested to learn, I've recommended think Jan
| Sadek's mainframe playground before (
| https://mainframeplayground.neocities.org/ ).
|
| Keep an eye on IBM's "Master the Mainframe" and hobbyist licenses
| for OpenVMS. I found setting up GnuCOBOL in a nice way was too
| much of a hassle to recommend.
| sgt wrote:
| > Jan Sadek
|
| Random question. Will that weird looking 'a' render on a
| mainframe? EBCDIC?
| Hnus wrote:
| Whats the salary in comparison to lets say full-stack webdev.
| ecshafer wrote:
| FWIW when I worked in a Finance company with a lot of Cobol +
| JCL + DB2 devs (including in management so I could see more
| info) their salaries were on average similar to Full Stack
| but possibly lower, especially as we put more AWS emphasis
| which those people started getting more premium salaries.
| Some banks I hear give cobol premium but it seems to be more
| specifically very specific mainframe systems experience +
| cobol.
| fredsmith219 wrote:
| Learning COBOL is easy. If you want a good skill for those rare
| low-paying COBOL jobs, learn JCL. That is the secret sauce that
| glues together IBM Mainframe databases, COBOL programs, and user
| interfaces. Any legacy application will be a chain of JCL jobs
| linking input and output from several COBOL programs. This only
| applies to IBM mainframes. The State of Michigan uses
| Burroughs/Unisys mainframes running COBOL, but I don't know what
| those use to control job flow and input/output.
| DanHulton wrote:
| We learned COBOL, CICS, and JCL in college (in the early
| aughts), because we had a lot of industries in our town that
| still relied on them, so they were churning out programmers
| that could actually apply for those jobs as the older
| programmers were retired.
|
| COBOL was fine, ultimately. Clunky, but functional. CICS was
| less fine, but still something you could adapt to. JCL was
| _miserable._ I honestly cannot remember why, I've blocked as
| much of it from my mind as I could, I suppose, but I remember
| every part of JCL being awful and no fun to work with.
| fredsmith219 wrote:
| Your memories are correct lol! JCL is absolutely miserable.
| But essential if you are going to be working on IBM
| mainframes.
| mikece wrote:
| Is there an estimate on how many COBOL jobs are out there still?
| And are there still apprenticeship/training programs for learning
| COBOL?
| fatneckbeard wrote:
| i know a system that runs cobol.
|
| but there are like 4 or 5 other systems on top of it, some of
| them use XML, some html, some asp, some java, some vba, some
| c#.
|
| i dont really understand the concept of a "x language job".
| like jobs tend to need people to learn systems and domain
| language, and be problem solvers, and communicators,
| coordinators, testers, the actual computer language is kind of
| irrelevant. like i cannot fathom there is a job out there where
| someone just hacks cobol all day and thats all they do.
| NikolaNovak wrote:
| That's my experience. I've actually been around systems that
| use Cobol amongst other things for 20 years (only did tiniest
| bit myself) but the developers tend to be experts in business
| as well - like, this set of Cobol programs are for payroll,
| and the developers understand payroll processing. They can
| discuss legislative nuances and taxation and benefits and
| deductions with functional analysts.
|
| Basically, all Cobol I've ever seen is firmly performing a
| business / functional task. I guess it's in the name :-)
| kjs3 wrote:
| No idea how many jobs. Places that use it extensively usually
| have apprenticeships and/or training. $DAYJOB does (big
| financial firm). There are even some mainframe/COBOL college
| programs.
| rbanffy wrote:
| I always find it amusing that the least sexy of languages
| runs on the sexiest systems.
|
| A modern mainframe is a thing to behold.
| pagnol wrote:
| Do you mind expanding a bit?
| tapland wrote:
| https://www.thegreengrid.org/ja/newsroom/blog/making-ibm-
| mag...
|
| https://www.ibm.com/z
|
| https://en.wikipedia.org/wiki/Mainframe_computer
| rbanffy wrote:
| They lost a bit of their glam when moved from 24" racks
| to 19" ones so that the datacenter people could hide
| these beauties in warehouse sized facilities instead of
| being proudly displayed at corporate headquarters ;-)
| kragen wrote:
| tianhe-1, cerebras, the ga144, and the ambiq apollo4 do not
| generally run cobol
| rbanffy wrote:
| Meh. None of those has the weird multi-gigabyte L4 caches
| of a Telum. And none of them will continue working during
| an earthquake.
| kragen wrote:
| > _Very few resources explain this, but having the code in strict
| positions was what allowed old computers to read the instructions
| on punched cards. On punched cards, a certain COBOL statement,
| let's say an IF statement, is mapped to a pattern of holes. If
| you know that a statement starts at a certain column (12-72 in
| COBOL), it is easier for the hardware to read (this was done by
| passing a light through the card)._
|
| i think it would be more accurate to say that dividing punched
| cards into predefined fields was a pre-existing practice (dating
| back to the census of 01890) which was unthinkingly copied when
| punched cards were adapted to applications for which it is a
| stupid idea, such as programming
|
| it's true that iterating over the leading blanks on a free-form
| card to find the first nonblank character takes more cpu time
| than just looking at column 8, but those cpu savings are so minor
| as to be lost the first time a compiler run has to be aborted
| because someone accidentally punched their statement starting in
| column 7
|
| cobol, being a dod initiative, didn't care much about whether
| ideas were stupid as long as they could be made to work, and hci
| (and even ergonomics) was still in its infancy
|
| (what would i know about unthinking copying? well, just last
| night i formatted my code to fit within 80 columns, ultimately
| because that was the width of ibm cards, and therefore of many
| printers, terminals, and character generators, and is still the
| default width of many terminal emulators)
| santoshalper wrote:
| When I was new to engineering management, I took over a project
| where one of the large components, a claims processing rules
| engine, was written entirely in SQL. Apparently, the previous
| manager had assigned that component to a DBA to build and by the
| time they found out, it was too late in the project to re-write.
|
| Anyway... years later my scope had increased to include some
| mainframe teams working in COBOL. I have always been a big
| believer that you can't effectively lead a team if you can't do
| the job, so I dove in and learned COBOL. Now, I am not saying
| that COBOL and SQL are syntactically similar, but the experience
| of building in COBOL was very similar to building application
| logic in SQL. None of the abstractions we are used to, and no
| real concept of separation of concerns. It was fairly easy to
| build in, but an absolute nightmare to maintain.
___________________________________________________________________
(page generated 2023-04-29 23:00 UTC)