IBM Rallies COBOL Engineers To Save Overloaded Unemployment Systems (medium.com) 116
As millions file for unemployment benefits in the United States every week, states' aging computer systems simply cannot keep up. States like New Jersey and Connecticut have said they are desperate for programmers who are still familiar with COBOL, a programming language that debuted in 1960 and is still used in critical computer systems like unemployment databases and banks. But there aren't many who know COBOL programming anymore. IBM, the leading provider of mainframes typically used to compile and run COBOL code, is trying to help bridge that gap. From a report: On Friday, IBM announced it was launching a free training program to teach coders COBOL as well as new forums to match those who know the language with those who need help maintaining their critical systems. The COBOL course will teach coders how to use the language in Microsoft's popular VSCode software and will be available next week. Next month, IBM says it will release a more fully fledged video COBOL course on online learning platforms like Coursera. The two forums that IBM has launched live on the Linux Foundation's Open Mainframe Project website. One of the forums, Calling all COBOL Programmers, has had dozens of engineers sign up in the last 24 hours from around the world. The other forum is more technical in nature, where coders can pose specific COBOL questions and work through projects with experts.
Nice (Score:2)
How many layers does this irony have?
Re: (Score:2)
Re:Nice (Score:5, Insightful)
Re:Nice (Score:5, Funny)
The kicker will be when people realize COBOL is more concise and flexible than Java or C#.
Really. Cobol is not difficult. A competent coder can learn enough to get work done in a week. It was specifically designed so that business people can understand it.
This all brings back fond memories. Years ago there was a company called Ryan-McFarland that made a Cobol compiler called "RM/Cobol". So the business folks would ask the nerds how to run it, and we would tell them to just type "rm <source-code>". Hee hee. Good times in cubeville.
Re:Nice (Score:5, Insightful)
A competent coder can learn enough to get work done in a week.
Yeah the problem here though is that we're not trying to get work done. We're trying to debottleneck failing aging systems coded by someone else. For that you're going to need someone with a little more understanding.
Re: (Score:1)
Deducing business rules from any program is difficult. Especially since they're unlikely to have been properly captured.
The information density of a Cobol program is quite low. The upside is that it's nearly impossible to obfuscate. It resists any attempts to display cleverness. If you've programmed in any declarative language, Cobol is a trivial (but unattractive) detour. The arcane data declarations will take awhile to get used to though. If the program is organized into overlays, that's another small me
Re: (Score:2)
Deducing business rules from any program is difficult. Especially since they're unlikely to have been properly captured.
As someone who's been working on such systems for decades, I've never once seen them captured and have my doubts they are anywhere given the way software is modified over time. People don't keep central design docs then modify those before the code - that would require business people who are competent enough to understand the whole system, which is not a thing. Business people like to say "we should modify this to do x instead of y" then create change requests from that, as a result old systems are all g
Re: (Score:2)
Re: (Score:2)
Re:Nice (Score:4, Interesting)
Really. Cobol is not difficult.
It really isn't: it's mostly some conditional and looping logic and decimal arithmetic.
However, most mainframe COBOL programs aren't just COBOL: the COBOL just wraps around macros for accessing databases or interacting with the teleprocessing environment (which queued up the inputs from the terminals, dispatched the appropriate bits of code and then returned the output from the right work unit to the right terminal). Depending on the age of the application, there's probably more of a requirement to understand CICS [wikipedia.org] or IMS [wikipedia.org]. That's where the expertise is likely to be thinner on the ground
Re:Nice (Score:4, Informative)
concise? i would say cobol is probably the most verbose language in existence. intentionally so, since it was an attempt at mimicking natural language to make it more "user friendly".
further, what you can express in cobol is not really much, its domain is very narrow: process registers, compute values, sort, collate, output registers. it was designed to handle punched cards. not really flexible.
it doesn't even compare to a general purpose language like java or c#, it's more in the area of appliances, like report generators.
Re: Nice (Score:2)
Re: (Score:2)
dig accepted. :)
Re:Nice (Score:5, Insightful)
furthermore: the problem here isn't to grasp cobol's "syntax", but to learn to move around in its environment, which are mainframes, terminals and likely huge chains of batch jobs, to fix decades old legacy code with a nightmare of layers of business rules most likely undocumented. plus you'll be lucky if you get a relational database.
those few ibm courses won't be of much help.
Re: (Score:3, Insightful)
Back when I was writing COBOL for mainframes one of the worst aspects was trying to edit code on a terminal. Even back then we were used to GUI editors or at least the ability to move the cursor around freely and insert text in the middle of lines etc.
I wasn't there long so never got to investigating if there was a better option but the guys who had been there for years didn't seem to think so.
Despite all the hype there isn't much money to be made in COBOL, at least not around here.
Re: (Score:3)
You take your hand off the keyboard to manipulate the mouse to move the cursor........
or you keep your hands on the keyboard and use up, down, left, right, shift-up, shift-down, pgup, pgdn, tab, shift-tab, etc.
I learned to code on 24x80, I wouldn't call GUI editors faster - but I accept that those who learned to code on them would find a text-mode screen frustratingly slow.
Re: Nice (Score:1)
IntelliJ + VI-keys FTW!
Re: (Score:1)
It's so long ago I can't remember exactly why it was such a pain... I think it was basically a line editor so going back was possible but very fiddly.
Anyway what I do remember is that the guy showing me how it worked on day one managed to accidentally wipe half his example code while trying to edit it by getting confused as to where in the file he was and entering a load of blank lines.
Re:Nice (Score:4, Funny)
I thought everyone knew how to inset text in the middle of a line: you inset the old card before a blank one in a copying card punch, copy the first bit, then press hard on the old card while typing the insert, and then copy the rest. Pressing on the old card stopped the pinch wheel moving it on, so it remains in place for the second copy part. But don't do it when the IBM engineer is watching; he'll hate you for putting a flat on the pinch wheel.
Re: (Score:3)
Re: (Score:2)
Despite all the hype there isn't much money to be made in COBOL, at least not around here.
This is the problem.....they want volunteers.
Re: (Score:2)
Oh, you can be sure it will be documented. It may be hard to find, dusty and out of date, but it will be documented. Old school IT shops did process, not agile.
Re: (Score:3)
I see a lot of people making a lot of really bad assumptions.
First, there are TWO seperate issues. One is an issue of system capacity, and the other is an issue of system function.
As to capacity: there are two methods used to price mainframe software. One is workload-based - you pay by how much you use it. This is the method IBM uses for their software. The other method is capacity-based - you pay by how large of a system you have. Many third-party software houses use this method.
Because of capacity-b
Re: (Score:2)
i would say cobol is probably the most verbose language in existence.
with the obvious exception of German.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Most code I have seen over the yeas has been COBOL in drag.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Coders vs Scaling (Score:5, Insightful)
Isn't the issue that the systems aren't handling the load?
Not necessarily. There may be assumptions in the code about transactions per day. Or data accesses may not be reentrant. There are plenty of reasons software doesn't scale other than slow hardware.
Surely the solution is some good old fashioned scaling, presumably vertically in the case of these old systems.
You can't take an old system that was never designed to scale and magically scale it just by throwing hardware at it.
Optimize 50-year-old code to make it handle the load on the existing hardware? I fucking doubt it.
You shouldn't doubt it. In the last 50 years, America's population has gone up 50%. Meanwhile computing capacity has gone up a million-fold. It is unlikely the problem root problem is slow hardware.
Re: (Score:3)
There comes a point - at least for the IBM minicomputers I used to deal with - where annual maintenance costs become uneconomical, i.e. it's cheaper to move up to the latest iteration of the machine than it is to keep paying maintenance on that old monster.
I imagine it's the same for mainframe systems. IBM want people buying or leasing the latest and greatest, so they structure annual maintenance accordingly. Trouble is, those systems are incredibly resilient and long-lived. We used to joke about having for
Re: (Score:1)
Yes there is a point where the economics change, unfortunately it's not just a hardware change. In the time that has elapsed politics and requirements change a lot as well, so it's no longer a re-implemenation - it's a new system and migration.
In the UK we have been replacing several "uneconomical" benefit systems (health, housing, employment etc) into one system: "Universal Credit" that helps people see their benefit records online.
It's already several years late, with a budget that has ballooned from
Re: (Score:2)
Sounds like the move in Oz to move as much as possible online, under one end-user login to access multiple govt services.
I can appreciate the scale of effort needed - centrelink (unemployment benefits, student allowances, parenting payment, etc), tax, medicare, child support, and others all under one portal. You can scan or photograph and upload a benefits application form (with a few exceptions), and have it all processed without visiting a centrelink office - which IME isn't nearly as painful as trying to
Re: (Score:2)
Yes, it looks similar in scope. I marvel at countries like Estonia where they've been using such services for years. Most people file tax returns online now, and it works pretty smoothly to its credit.
One of the "funniest" parts of the documentary was seeing all the story cards on a 20 metre long wall. One of them read:
"Pay people the right amount, on time"
Project MD's comment: "we've been trying to do that for 30 years"
Re: (Score:2)
You can't take an old system that was never designed to scale and magically scale it just by throwing hardware at it.
In case of code written thirty or more years ago, you often probably can. The machines that IBM has now are orders of magnitude faster than they had when this software was written. And the tapes and disks are now flash memories instead. So it many cases, it *should* work, as long as only the transaction volume is the problem.
Re: (Score:1)
You can't take an old system that was never designed to scale and magically scale it just by throwing hardware at it
Sure you can. Just buy some more sorters, and hire some more comptometer operators. (I go waaay back.)
Re: (Score:2)
I'm guessing the need for COBOL developers is mostly related to changes in business logic. Lots of states have changed eligibility rules, deadlines, disbursement schedules, etc. and that logic now needs to be implemented in software.
Re: (Score:2)
Isn't the issue that the systems aren't handling the load?
The issue is mainly the $600/week from the federal government.
Re: (Score:2)
IBM's new mainframes will still run native binaries from the S/360 era.
Re: (Score:1)
IBM's new mainframes will still run native binaries from the S/360 era.
As will Raspberry Pi and everything else, if using Hercules.
Re:Coders vs Scaling (Score:4, Insightful)
Much as I love my RPi, running S/360 (or later) binaries doesn't mean anything beyond curiosity value. It's not a valid comparison.
Once again - there are reasons that certain industries still use mainframe technology. Within those industries, ARM and x86-based systems simply can't compete. Otherwise, why haven't the folk that still use mainframes moved to cheaper commodity x86 hardware? It can't do the job for a competitive price.
Re: (Score:2)
Re: (Score:2)
Why?
Re:Coders vs Scaling (Score:5, Insightful)
Because the sheer amount of data, and transactions on those data, can't be performed by x86 within the time constraints required at a competitive price.
x86 is all about the CPU, and not about the most efficient movement of data into and out of that CPU. We've seen the comparatively recent introduction of L1, L2, and L3 cache for x86 (I also mean x86-64, here). Mainframes are designed like that, from the ground up, not as an add-in or enhancement or improvement. Many of the x86 feature announcements over the last 2 or 3 decades were ho-hum to mid-range and mainframe people.
I worked AS/400s in the 1980s and 1990s. It was a 32-bit multi-user, multi-tasking system when the x86 world was just discovering 32-bit - the 80386. There's a price/performance point where x86 runs out of puff.
Car analogy time:
It's like pulling loads with cars. At some point, it's simply cheaper to buy a truck.
your bugs stay around (Score:3)
It is rather unlikely that Cobol will be around by the end of the decade.
--Anonymous, June 1960
Bring out your COBOL programmers... (Score:3)
Re: (Score:2)
Get into your time machine!
What a nice donation! (Score:1)
All these _volunteer_ Cobol programmers for these states that are desperate for volunteer maintainers!
Provided for so generously by IBM!
Re: (Score:2)
I would consider joining, given Universal Basic Income. If it's new times, then be it.
Re:What a nice donation! (Score:4, Funny)
Re: (Score:1)
Can do: whoever wants to qualify for unified income, gets trough COBOL course, and, starting here miserably, you might actually end with a surplus of COBOL professionals, willing to volunteer for New Jersey or Connecticut. Way to go.
Re: (Score:2)
They want unpaid labor--yes, your unpaid labor! (Score:3)
That's what the actual web form asks--how qualified you are, and if you are willing to work for free.
They are claiming that they don't have the time right now to go through the process of appropriating money to spend to keep this system running--so they want people to do it for no pay.
Re: (Score:2)
I hear they're very much NOT cheapskate at tax time....They're great at collecting your money, and good at boondoggles as a bonus.
Re: (Score:1)
FFS update your systems! (Score:1)
If IBM really wants to help (Score:5, Interesting)
preserving the old mainframe skills, they should be more friendly to the hobbyists. They should allow licensing their mainframe software for cheap or free to individuals for running on emulated hardware for non-production use. They already make lots of the old documentation accessible for free, which is a good first step.
Re: (Score:2)
And they should stop axing older workers.
Re: (Score:2)
And they should stop axing older workers.
They don't want you till they need you.
Re: (Score:1)
And they should stop axing older workers.
Sorry if this sound cynical, but relying indefinitely on older workers only isn't a sustainable solution. BTW, I'm an "older worker" myself. And my brain just can't click quite as fast as it did 30 years ago.
"aren't many who know COBOL programming anymore" (Score:2)
It would be more of a challenge to learn the arcane and baroque mainframe they run on. And that's probably where the performance issues lie, more so some dumb batch job written in COBOL that turns an input into an output.
Re: (Score:3)
"learn the arcane and baroque mainframe they run on"
That's not the programmer's job. It's the sysadmin/operator's job.
Programmer - "Here - this program needs to run nightly, after program A but before program B"
Sysadmin - "Got it. I'll schedule it accordingly."
Re: (Score:2)
No, the programmer has to understand the system as well, since the JCL required to run the code is very hardware specific.You need to know very specific details of all the parameters or you will abend pretty harshly.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Congratulations! In an article full of ignorant posts, yours is the most ignorant. S/360 and its successors are not widely adopted? Is that why most of the world's largest companies and governments still use it? It is not 'very immediate/interactive'? Is that why virtually all credit card transactions are processed by it?
And btw, S/360 and successors are HARDWARE. Hardware that quite happily runs Linux.
Re: (Score:2)
Re: (Score:1)
It's not about getting outlook of the language commands, it is about getting into the structures of the application theme and existing code competently, changing and adding as an expert.
How many millions was IBM promised? (Score:2)
Must be a lot and none of it will trickle down to the actual programmers.
Making IBM look good while helping themselves (Score:5, Interesting)
While it's good to see the immediate problems with processing unemployment claims getting solved, don't for a moment think that IBM is doing this out of the goodness of their hearts. It would be very bad for IBM if people started to realize they needed to modernize old business applications like this unemployment claim processing system. IBM makes an obscene amount of money providing computers that can run software written in the 1960s/1970s.
Considering hardware alone, performance per $ on commodity Xeon/EYPC x86 servers cost about 90% less than a IBM z mainframe. Don't forget that IBM charges an arm and a leg for software licenses on mainframe vs. inexpensive Linux on x86. The high availability of mainframes isn't a differentiator anymore either. You can get 99.999% uptime on x86 with virtualization, clustering, microservices, docker, kubernetes, etc. AWS is living proof of that. The only reason to spend $300,000 on a small z series instead of $30,000 on a small x86 rack is because hiring 10-20 software engineers for 5 years to modernize your business software costs ~$10,000,000 fully burdened. Software like this tends to be so tightly customized to a specific business workflow that lots of custom code is involved and updating the system is non-trival.
Re: (Score:2)
That must be why banks, insurance companies, stock traders, and airlines are moving away from mainframes.
And they have been for 20 years.
Real soon now.
Re: (Score:3)
A whole lot of bullshit in there. IBM has been trying to move customers off the old software for quite a while. Yes, they still support 24 and 31 bit COBOL applications, but keeping that support adds to the cost of mainframes. Are you aware that the price of an 'engine' that runs only Java applications is about HALF the cost of one that runs COBOL? Or that an IFL (Linux) engine is priced similar to a Java engine? More that half of the mainframe capacity in use is LINUX. They even sell Z series machines
Re: (Score:2)
JCL. The horror..... the horror....
This thread is a thirst trap for low UID users... (Score:5, Funny)
Re: (Score:2)
Don't look at me... COBOL was already considered to be an obsolete language when I was in college. Java was the new hotness at the time, so they taught that as well.
I never wrote a line of commercial COBOL code in my life, though.
Understanding COBOL is easy. (Score:2)
Understanding programs written in COBOL is a bitch. That's why there's so much legacy COBOL; it's stuff that works but the cost of understanding what it does is prohibitive.
COBOL was designed by a bunch of programmers, and had for its time a number of interesting features, but it was designed to make writing programs easier. At that very early date they didn't really understand how important communicating your intent to other programmers (including your future self) was. The computer itself doesn't care wh
Re: (Score:3)
You have this completely backwards. COBOL wasn't written to make it easier for 'novice programmers' to WRITE programs, it was to make it easier for the owners of the business processes (accountants, auditors, etc) to READ the programs to make sure the logic was implemented correctly.
Understanding the reasoning for the business logic is pretty much language independant. No kid who learned Python last week is going to know that the reason this line of code exists (and must not be removed) is because the tax
Re: (Score:2)
I've been hearing COBOL defenders for decades talk about its supposed self-documenting properties, but I don't see it. Its resemblance to natural language -- even supposing that *was* a good thing -- is only superficial. It uses more or less the same procedural programming constructs as every other other programming language.
Re: (Score:2)
Really? Let's take some trivial examples.
x = x + 1
balance = balance - withdrawal
What do those two statements mean? If you are a normally educated person who has never seen a computer program (like virtually everyone in the early 1960s), the first statement is clearly an error, since it solves to 0=1. The second statement solves to withdrawal = 0.
But if you are a programmer, those statements mean something completely different: add 1 to x, and subtract withdrawal from balance.
Now, how could you write those
Re: (Score:2)
Re: (Score:2)
It should be advised.. (Score:2)
To read your whole COBOL code in a robotic voice.
If there is a language that sounds like a sci-fi robot, it's COBOL.
do you want my help? (Score:2)
pay me.
Re: (Score:2)
Want it fixed quickly and properly? Pay me more than the prevailing average, a lot more. I'm willing to fix your shit, but I need to wash the smell off too. These old systems run on expensive maintenance plans and dishwasher wage workers - that is backwards and has caused the problem.
Everything old is new again... (Score:2)
I've mentioned this in previous posts but COBOL is still widely used. The problem is that it's not taught in schools anymore so none of the young-ins are learning it. If you happen to land a job with a place like IBM they will train you on it.
Learning COBOL is not terribly difficult but it's a very verbose language. It takes thousands of lines of code to produce a relatively simple program. It is similar to SQR, if any of you have used that before. At least when I used it last, it was largely a procedural l
COBOL is the easiest part (Score:2)
When you start a new job doing software maintenance, the problem isn't learning whatever language it's written in. People can learn a language itself, quickly and easily. But then there's the batteries-included libraries and frameworks (which some might see as part of the language, but it depends), the batteries-not-included libraries, and then all the application code (which can be enormous and spread out, some well-traveled and some covered in cobwebs), how it's organized, wtf it does (which is probably t
COBOL - not the problem here (Score:2)
Are they giving you COBOL tutorials and some lab-scale problems? Great. But, I can also pick up a 1980 Cobol textbook from any mid-size University library and get the same.
Are they giving away virtual 3270 sessions to a machine with MVS or VM/CMS, CICS, JCL, IMS, DB2, and some large existing codebases to study and decently large fixture data sets to work with and learn from?
Definitely not. The only way you're getting any of that second set is by working in a mainframe shop. Someone who has the former an
Why is this necessary? (Score:2)
These systems have been around for a very long time. Are they broken now? Still have bugs in them? Or do the current crop of bureaucrats insist on changing stuff that wasn't broken?
Re: (Score:2)
Sad to so much misinformation on /. (Score:2)
Really. You *guys* should be ashamed.
First off, whoever said that you don't get much performance by improving the hardware: I worked an Rdb/ACMS optimation for DEC in the mid 90's. The end result? The customer pitched our work, and threw more money at memory and disc. Remember the RSTS/E OOM message? "Buy more memory..." Seeing that on an LA-120 for 2 hrs. brings back fond memories. But I digress.
Second off: There are classic Knuth sorting/searching jobs. Some of them can be refactored. The bitch is that Co
Re: (Score:2)
You are making the same mistake as many others on here. The performance problems are simply overloaded hardware. Mainframes are typically sized to run at very high utilization, so when usage suddenly jumps there is not enough capacity. Adding capacity to these is trivial, and can be done with no outages. That is not why programmers are needed.
The programmers are required for a completely separate issue. The rules for getting unemployment have changed, and someone has to make those changes. Throwing ha
Re: (Score:2)
Re: (Score:2)
You spew misinformation. Compiled COBOL is as fast as C. COBOL can do any sort as fast as C can. The mainframes that run COBOL use POWER derived architecture that blows x86 wintel crap away.
Re: (Score:2)
Close, except that mainframes do not use POWER derived architecture.
Re: (Score:2)
yes they do, they are cousins.
"The z10 processor was co-developed with and shares many design traits with the POWER6 processor, such as fabrication technology, logic design, execution unit, floating-point units, bus technology (GX bus) and pipeline design style, i.e., a high frequency, low latency, deep (14 stages in the z10), in-order pipeline." -- wikipedia
Re: (Score:2)
None of that stuff is POWER architecture. That is some components and implementation details for a processor. Those same details may be used on multiple processors, but that does not mean one processor is based on the other. If you are going to use the fact that they use some of the same components to say one is based on the other, then you could just as easily say POWER processors are based on Z Architecture.
And if you are going to quite Wikipedia, at least continue to the next paragraph which points out
Re: (Score:2)
There are common design elements unique to POWER/Z10 and not to any other processor on earth, they were designed in parallel. I know people that worked on them.
Yes, there are differences too, that's what the next paragraph is about.
Re: (Score:2)
Yes, I understand that. The problem is, when people say 'mainframes use POWER derived architecture' is gives the impression that somewhere in the design of a Z processor is a POWER processor, and there is not.
Look up what defines 'POWER architecture'. It is things like instruction set, coprocessor attachments, etc. And absolutely NONE of that architecture appears in any Z processor. What is explicitly EXCLUDED from the definition of POWER architecture is things like "fabrication technology, logic design,
Re: (Score:2)
And with the fine assistance of Wipro, Deloitte, IBM, Infosys, CGI, Perspecta, and Tata consultants, it will be 5 years away 25 years from now.