A quick skim of the postings is finding that what they're really screaming for is somebody who's been familiar with their particular pile of toxic waste for at least four years at minimum. They're asking for people with 4+ years of COBOL, and JCL (ok, fine), and DB2, and VSAM, and "SDLC" (proto-waterfall), and, oh yeah, a four-year degree.
Heck, there's a posting asking for somebody to draw diagrams and document their existing processes, and for that they expect you to have 10 years of COBOL experience.
Okay then. This is not yet a mess that they're motivated enough to fix.
They fix nothing, then wait for somebody to need them enough, or have compassion enough to handle their mess.
Basically here, they are saying: we didn't listen to all those competent people that told us we should have cleaned this system a long time ago because one day it will bite us back. We didn't think technical debt was a thing. It has always worked. And it's virtual. And IT is always exaggerating anyway.
Now it does bite them back, and do they take responsibility ?
No. They ask for competent people to have mercy and save the day because the situation is dire. Because this is special this time, unlike the other times.
This is completely not like with the health care system that never got fixed and now the medical personal is paying for it so that the people don't suffer as much from this mismanagement.
They will not pay more. They will no fix anything. They will not respect you more, change the way things are done, or take any responsibility for this. And in fact they will probably guilt trip you into give up your health to overwork on this with less resources and for less pay because it's an emergency.
A friend of mine works in an hospital right now. She has been at work for 15 days straight. They already told her she won't get paid for the days she was not supposed to work but did.
Then as a final fuck you, if this turns out ok, if the catastrophe is avoided, they will get the reward.
The nurses or the programmers ? They will be forgotten in a week. Nothing will change.
But for the mismanagers, their superior will thank them for managing this situation well. They may even get promoted and have more responsibility.
So you have the choice between saving the money of poor people now and reinforcing the suck of the whole system, of letting people suffer for a chance of a redo and purging the ones that lead to this.
This is a terrible choice to have to make.
Especially since we have the empathy to make us discuss this, while clearly they don't.
EDIT: surprised at the downvotes. Parent asserted:
> we didn't listen to all those competent people that told us we should have cleaned this system a long time ago because one day it will bite us back.
And the historical record showed that NJ made that realization at least before 2007 (which is when the contract was awarded)
They respect nothing. Scope? No, we need to fulfill every need and some. Budget? No, of course we don't have cash, and we have to be very careful, it's the taxpayers' money! Time? It's already late! (Yet they weren't able to get it done in 10+ years.)
They have no real competency, they don't even have competency to delegate this to someone competent. And they lack the competency to manage their own inconsistency regarding these issues.
The linked tweet thread is a perfect example of this. (Rampant project mismanagement; too big to fail; they introduced some Hadoop scoring system to match inconsistent records and whatnot instead of simply throwing out all the bad data and handing the rest separately - eg hiring a bunch of unemployed people to go over them.)
A state that should be at the top of any kind of project management and procurement hierarchies wasn't able to supervise an IT system project. It's so incompetent just thinking about it will lead to spontaneous combustion.
Companies will not like it, consumers will not like it,
State budgets will not like it,
But like cobol programmers, we need to learn how to make things and build our own supply chain.
My old employer did not listen last year when I retired. Nobody was assigned to make an annual change to a REXX program. I learned it on my own because it predated me.
But the process was so rigorous because we had to be our own RACF Admin to make our own RACF I’d to get to the datasets to change, then run the programs, but they got rid of printers connected to the mainframe and tighter up FTP so much that if took days to refresh passwords and ftp print files to your pc hard drive.
Then run programs in C# that scalped off the first column and read the mainframe page skips....
Am I was suppose to teach this to a C# programmer who would not need to run this for 6 more months.
I blame management. They loved outside consultants and treated our own programmers like loading dock employees, write ups when 5 minutes late for work.
They wanted me to take a brand new high end pc with me when I retired. I left it on my desk when I left. They had 6 months to learn it.
It’s not like HP is some unknown foreign company.
Because the only thing they are specialized in is sucking tax money from the government.
> It’s not like HP is some unknown foreign company.
That's their only pedigree. In other countries they also took a lot of money and delivered crap. So people should be aware by now. But with all this corr^W lobby ...
What a terribly wrong take. If you really believe the system is that corrupted, and that horrible then you know darn well that the count of people who suffered during this emergency won't make a difference. There will be "accountability" in some form, but it won't be driven by how many people did or didn't get money for food at all.
Whether you help them or not won't change the system. So instead you're saying scores of families should go hungry so you can stay on your high horse and lecture.
But they struggle just to give each worker in this country $1200.
It is hush money. Then next year they will tell us it is taxable income. Watch.
In absolute terms, perhaps. But if you are moving away from taking jobs out of self interest, and into doing something for the public good; you might as well check out https://80000hours.org/ and pick the job that has the most positive impact.
My guess is that working any kind of 'normal' programmer job and giving 10% of your income to an effective charity would beat out enduring the bad boss in New Jersey.
You working for them would most likely not push them from failure to success. It would perhaps make success marginally more likely, or perhaps decrease schedule overruns slightly. Or perhaps make not much of a difference at all, depending on how screwed they are.
Of course, the estimate of impact also depends on how you value humans. If you value all humans fairly equally, then Americans who had a job until fairly recently (ie those eligible for unemployment insurance) are already fairly well off compared to the people who benefit from more malaria nets. Especially since their unemployment benefits would merely be delayed, not lost.
Lots of people value those closer to them higher. The most prominent example are family and friends. But valuing compatriots higher is fairly common as well.
Of course, you can give more than 10% of your income as well.
They'll probably find a few people who will give it a go. The result will probably be delays and failure. Business as usual.
If NJ have failed to maintain legacy systems that good COBOL development needs, almost by definition they have incompetent management (and a Governor who can't even pronounce COBOL). They likely don't have the dev or test boxes that they should have. They will either put up barriers to the other systems the developer needs to understand, or will throw open the doors so that my fixes get broken by everyone else's fixes.
Let them get nothing. Then they'll call for the heads of the governors, the very people who couldn't care less about the system until it stopped working. They are the ones who could have made a difference but actively chose not to because it just wasn't that important to them.
A bad boss will absolutely give you burnout, and that lasts for years. You are of course correct, but at the same time I would never ask this of someone and I wouldn't subject myself to it either. Bad bosses will destroy your quality of life in the medium-long term.
It's better to direct our limited resources to better porjects with a higher success rate and/or impact.
The job specs were 40 lines long and pay was $60,000 a year for 10 years experience.
Then there were the places that brought in consultants that were doing a big rewrite, ignored the local staff and impressed management with their dark blue suits and white shirts, and left 6 years later without the project done.
During that time the best of their own programmers left and they were left with the dregs and those a few years from retirement.
Thought about doing this but I remember how we were treated. I left a job like that in Texas, worked in a shop in Connecticut with a room full of empty cubicles, and one very old guy and one new hire who knew Access.
Even the Director of MIS was being cut there but allowed to stay a few more months to apply for other jobs without saying he was unemployed.
Isn’t it easier to verify someone’s leadership credentials than COBOL skills?
Still, in an era of movie superheroes, who knew that having 10+ years upon your CV would enable you to go, step aside good citizens, for I shall save you. COBOL man to the rescue.
If you're touchy about people gently correcting accidental unintended sexism, take a moment to think about how women like Grace Hopper and Ada Lovelace have felt about being on the receiving end of systematic intentional sexism all their lives.
The point was that there is no sexism, unintended or otherwise, in the post you are "correcting". Projecting your touchiness onto others isn't very polite or constructive.
However, it is easy to view such balance as over-balance and it can then snowball into something of which it was not, and words, like code - heck nobody writes perfect code first time, let alone wording. So you can easily get bugs, be that in the code or in how things are worded that open those words up to tangents or ambiguity that was never the intention.
Anyhow - we are all on the same page of that issue I do feel and with that, let's poor one out for Grace, who without her we would not even be having this conversation that COBOL has given us today.
We are all human after all and words are like code - bugs happen and we all operate our own unique brain-CPU's so things can and do run differently. No lines need to be read between here. Be well all and sorry, just thought I should clarify in the name of fairness for all and Don did nothing wrong in my eye's and it's all good.
Well said and an extremly valid point upon many levels, let us not forget Grace.
I perhaps should of phrased it as COBOL Human, though that may of confused others more than not, more so with the mixed superheroes conversation and that in itself had legacy baggage as do many things that are easily tripped up upon.
I'd upvote you more as detail is as always important and should never be overlooked.
COBOL human to the rescue would of been better perhaps, so again unnecessary, yet not unwelcome and with that - everyone gets some karma.
If you see any bosses with a weird scarf, back away cause they may spit corona-acid in your face!
Sure it was given the Hollywood treatment, but it'd be pretty boring if they didn't.
The 3d desktop file system navigator software running on the SGI workstation was actually a thing that SGI shipped, by Joel Sherrill <firstname.lastname@example.org>, called SGI Fusion, or FSN!
Original URL of binary distribution:
Now archived at:
>File System Navigator (fsn; pronounced "fusion") is an experimental application to view a file system in 3D, made by SGI for IRIX systems.
>Even though it was never developed to a fully functional file manager, it gained some fame after appearing in the movie Jurassic Park in 1993. In a scene in the film, the character Lex Murphy, played by Ariana Richards, finds a computer displaying the interface. She exclaims "It's a UNIX system! I know this!" and proceeds to restart the building's access control system, locking the control room's doors. After the release of the film, some perceived the visualization as an example of media misrepresentation of computers, citing the computer game-like display as being an unrealistic Hollywood mockup.
FSN – the IRIX 3D file system tool from Jurassic Park
SGI Fusion - FSN 3d File System Navigator
SGI File System Navigator, otherwise known as Fusion. Running on IRIX 6.5 on an Octane. If you have an SGI, a binary of this program is available at ftp.sgi.com
It's a unix system
"Indigo without the go." -Mark Hughes (?)
Software Usability II
1. understanding the language (COBOL)
2. IBM mainframe experience (JCL, DB2, VSAM, SDLC)
3. credentialed (4-year degree)
Note that SDLC is a layer 2 network protocol in the SNA stack:
Why do you need to pay a college to get a piece of paper to enable someone to pay you for skills you otherwise posses?
Assume the interviewer doesn't have time for a multi-day interview in which your skills are tested. Maybe the employer lost the last person with equivalent skills, so a non-technical interviewer is trying to find a replacement person.
I feel like this is a game of chicken that FAANG can win, but NJ Unemployment Office (or whatever) cannot.
The shortage isn't really cash. You could hire some bright high school students for cheap, and, given enough time, and half-supervision by an experienced dev (who doesn't even know COBOL), they could fix whatever bugs are ailing the system. You could hire a couple (again, COBOL-ignorant!) web devs at or above market rate, and they could also deliver a working system. It would take time, but they could do it.
The actual shortage is management. They don't have anyone who'd be confident fixing things if said high school students screwed up. They don't have backups, or don't know how they work. It's unlikely they know what actually needs to be done.
So what they actually need is a tech lead. But they think they just need "programmers," so they advertise for programmers (with inflated requirements, because they need them to actually be a lead) and the pay is commensurate for "programmers," rather than what they actually need.
If it referred to SNA, it should be SNA/SDLC. Not referencing that (or VTAM) means Software Development Life Cycle.
USA has the skill & unemployment to fill farming, construction, housekeeping, etc. jobs no problem. But why would companies pay 2X to hire an American that’s liable to quit at any point when they can get a foreign for X that’s legally bound to the work?
(The auction would also give politicians a nice incentive to find ways to increase the revenue received.)
ERROR IN OR NEAR CARD 1 COLUMN 1
CORE DUMP FOLLOWS:
About the only other thing I remember is:
//SYSIN DD *
JCL is just another scripting language. I found it fun. I did all the JCL for my group's production jobs and commented the hell out of the esoteric issues to help Operations triage things. A small, well-planned effort prevented a crapload of, well, crap.
One feature of JCL which I think is cool, is that whereas on Unix processes inherit file descriptors which are numeric only (and hence few applications know what to do with anything other than FDs 0-2), in JCL you instead have DDNAMEs which are 1 to 8 characters. I think, if Unix had alphabetic names for inherited streams rather than just numbers, you might see more Unix programs supporting more than three inherited streams.
Another feature I think is cool is catalogs. A database mapping dataset names (file paths basically) to the filesystem volume (disk or tape) on which the file lives. You can move a file to another disk or to tape without changing its name/path.
(Strictly speaking both of these are features of the MVS operating system as a whole, not just JCL per se, but JCL is one of the main interfaces to them.)
In the mid-80s, my first year CS professor anticipated most us ending up "in the lead mines of COBOL programming" — it was commonly assumed that we'd never manage to get rid of the dominance of COBOL.
Are references to mining common in the COBOL scene?
For me the exact opposite. 15 years ago I removed any and all reverence to my history of COBOL because I was suddenly actively being contacted for COBOL coding jobs.
Although I had a great time, as a starting coder, with COBOL jobs (transcoding COBOL to C at the time), I know one thing: ever ever again will I utter one like of COBOL code.
There are still people making very decent money doing it, but the lockin to one particular source of work just does not sound like what I could bare.
Isn't it common for job applications like this to state what they "want", even if they know that it doesn't exist? (such as 3 years of experience with an 1 year old product).
Then they just hire the person who gets the closest to what they want.
To get serious, they need to move HR aside. Many of the best techs from the '70s and 80s dropped out of college. What was called for back then was real-world experience, not slips of paper.
I seem to spend most of my working life trying not to embarrass people with 4-year degrees who can't even spell things like "COBOL".
Still, maintenance is the biggest cost of any code that has lived so long, so with that such systems overall may well be agile, you just smooth out the pain over time in a more manageable way.
Govt: We need COBOL programmers.
Techies: I am powerless to help.
But seriously some of the brightest techies I know quit their jobs to do a stint of government work which included slinging VBA and ASP Classic to remove SQL injections from VA websites and other similarly unglamorous tasks with huge impact.
If you want to be patriotic. If you want to make a difference. Government work can do that. You're probably not going to train a neural net to solve coronavirus, but you'll probably be able to stop 1000 hacks from ever happening or get help to someone who really truly needs it.
Edit: per the thread starting with vaidhy's comment.
If you thought that was exciting I can't imagine hacking on archaic COBOL codebase could be much worse in terms of quality of tooling!
There's also a much better chance you'll have a say in the replacement if you work on and understand the original.
I'd love to see it, as someone who draws and colors all over printouts for reverse engineering challenges.
And continue to incentivize politicians (and their voters) to underpay employees and delay infrastructure spending until a crisis, and then beg for more “patriotism”.
If you are in that situation, and you do not do a rewrite, you are likely to fail.
If you are in that situation, and you do a rewrite, you are likely to fail.
Sometimes there is no winning move.
Not to mention that currently their existence is almost entirely dependent on their competitor - Google.
You wrote this sentence, it talks about Firefox and implies something went wrong there?
But didn’t IBM have a system to convert COBOL to Java that the federal government was using?
Slinging COBOL for New Jersey is not going to drop more bombs in Syria, but it might just save some lives by managing government operations more efficiently in a moment when every hour and dollar counts.
Hence not all code equal and the site standards and that history as well as knowing that can make an almighty difference.
Never had copybook issues with ICL or Honeywell BULL platforms ;). That would be an IBM thang, but then, is there anything else still running - probably.
I’m newer to the mainframe industry but not that new and I’ve never seen a place that doesn’t have a source control repository. In fact, it’s required by law in every company I’ve worked for.
What's obvious in 2020 was cutting-edge and forward-thinking in 1960. The rude kids of 2080 may sneer at your best code circa 2020.
I like to edit the source code to auto-sneer-mode.el in sneer mode, so it sneers at itself! Nothing more snarky than self-sneering code. I had to manually sneer by myself while writing it, to get it bootstrapped.
We should absolutely respect the history of our field, but the mere fact that COBOL is old doesn't make it an important part of history.
I agree cobol as a language is not particularly glamorous in terms of what it brought it computer science. I say this as a cobol dev, so I’m laughing, but it’s true: cobol sucks.
One of them was METHOD/1 from Andersen Consulting (now Accenture). If you wanted to create a variable to hold, for example, a part number... you'd create an entry in the CASE tool for it and from then on, everyone was supposed to use that one. It would have validation rules, like 30 characters, alphanumeric, whatever.
The CASE tool would do code generation for screens and forms and whatnot. And.... that's about as much as I remember at the moment.
I worked for a company for little while that made extremely effective use of this approach allowing hundreds of devs to effectively work simultaneously on a single monolithic system. It was shocking. I was so impressed. I've still never seen any software organization so... organized. And they owed it largely to the protocols revolving around their use of a CASE tool.
As for standards you would see from one company to another - early days and lucky to have separate department use same standards. So payroll would have different standards than marketing, but separate ecosystems and less of an issue, beyond team cultural changes and analysts quirks.
But then, standards change over time and become usurped.
So could very well ask the same question in 20 years time as the approach is always changing. May even be a call for C programmers then.
"Teleportation" was not.
Now management will pay even more because they're desperate and end up with a rushed solution that breaks again in the next crisis.
Why do some people take joy in wallowing in ignorance. Sad.
The most shocking story was about their system for tracking Medicaid patients. Their system had a fixed-width field for the patient's ID, and they ran out of identifiers - so they just started to recycle them again from the beginning. This problem was multiplied by the fact that, to say money, they didn't have backups of the original, clean data before the recycling. Thus it became pretty much impossible to understand what benefits had been afforded (or not) to whom.
Governmental budgeting seems biased strongly in favor of labor expenses, especially those with seniority, to the detriment of the maintenance of capital assets. This is pretty much a recipe for technological debt.
I was at the top of my pay grade just under architect and only two years out of college making around 68k a year in Olympia. Olympia is not a cheap place to live. On top of that you’re basically legislates NOT to do work.
The prevalence of COBOL and other older programming languages in many parts of the world's critical infrastructure (unemployment claims here, finance, government, defense) means that the average age of someone maintaining these systems tends older. Older people tend to have more health issues. From the summaries of reports I read about COVID-19, the majority of the deaths happen among the elderly and those with other health conditions.
The idea of civilization collapsing might seem fanciful and farfetched, but the idea struck me after watching a video that was submitted here on HN and the videos it references .
 Jonathan Blow - Preventing the Collapse of Civilization (English only) - https://www.youtube.com/watch?v=pW-SOdj4Kkk
 Preventing the Collapse of Civilization [video] - https://news.ycombinator.com/item?id=19945452
 https://www.youtube.com/watch?v=OiNmTVThNEY - https://www.youtube.com/watch?v=OiNmTVThNEY
 Eric Cline | 1177 BC: The Year Civilization Collapsed - https://www.youtube.com/watch?v=hyry8mgXiTk
My point is that this absolutely is a funding and priority issue. I work as a developer who maintains legacy FORTRAN code. It was written in an era where global variables and Go To statements were the norm. Everyone who wrote it is retired or dead. It’s a pain to work with and there are parts that I haven’t yet gathered the courage to go in and change. However, me and my team have made substantive changes to it that are robust, that we have rigorously tested. This is not impossible, but it’s also not cheap or fast. It took me a year to understand how this blob of code works.
My team is young, we’re in our 20s, with backgrounds in CS, mechanical engineering, and physics. Certainly all systems are different, but if we can understand old FORTRAN, similar people can understand old COBOL. If people made it, people can understand it. We also know how to fix many broken things and how to fix many bugs. Often were told by management “not right now” and “we don’t have funding for that.” It’s frustrating, but that’s how the world works. They at least have funding to pay us to do what we’re doing now.
The point is that you can fix legacy systems, you can hire new people to do it, but it is expensive and it takes time. The whole issue is not whether we can or can’t, we can. The issue is: who can pay for it and will they?
The problem with code is that most non technical companies don’t have a clue how this thing works. They use analogies. And for most folks the analogy is that of a machine that once built never breaks down. If you can demonstrate viscerally how bad the system is, it can help get better support.
The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk.
Obviously it's not fit for all domains, since it's a DSL for data management, but I'm often tempted to push as much business logic into the DB with PL as I'm allowed to instead of having to do things in the application code itself, and it paid off many times, as I have rarely seen a project moving from a database to another, while application code is often rewritten in many different languages for no other reason than management's whims. I probably saved some businesses millions of dollars in code porting/rewriting/migration.
> The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk.
In my experience, the biggest issue is the complete lack of code documentation, as organisations relies on a handful of developers to maintain their codebases and when these developers retire, suddenly, nobody can understand an architecture.
I can’t just switch branches and know the state of the system at the time the branch was created.
First, I'm talking about a PL "middleware" layer than does not necessarily involves restructuring the data itself (basically, instead of querying tables or views, you query stored procedures or functions).
When it comes to version control, wouldn't a migration system suffice to assess the state of that layer?
As for unit testing, I kind of agree, it's possible though, like any other programming language.
If you can data warehouse aspects off, that's great and can slowly bite away, migrate chunks bit by bit. Though one of the last will often be the database itself. Report generation is often an area that will hit resources hard and can also be easiest to migrate away towards something better using a system that periodically syncs the database onto another platform with all the latest do it yourself easy accessible tools. That allows those wanting the reports to be able to make and change that themselves removing a lot of code development and main system overhead.
With that, knowing the language is not even half the battle, the business knowledge would be the lion's share and to integrate the two skills effectively, that's where the money is.
You could have a payroll system, migrate line by line, logic by logic from COBOL to C. Yet the way the data is handled, the nuances of the way the languages round numbers, store data, formats, handle exceptions or early termination. It's not just a case of setting the right flags in the compiler and job done.
But yes, there is always a way. As always, the devil is in the detail.
Though my main point I was making is that skills get lost over time for various reasons and how later you try to rediscover those skills for various reasons. I dare say that being able to make butter would be handy in some situations, imagine being isolated and access to a cow milk easily and your local shop not having any butter in stock for a while.
I've never made butter, but I have used raw milk. And I've failed at whipping cream, by overdoing it. So from what I've seen, "making butter" is basically just agitating cream until the fat clumps, and then pressing out the whey.
Making bread, I admit, takes more skill.
My mother knew how to make blood pudding. But that's not something I miss very much.
Puerto Rico was without electricity for months. Some parts of the West will recover from the economic effect of the pandemic quickly. Others won't, without help from the center.
I love how pop culture always portrays the collapse as coming from our inability to maintain or repair some mythical machine or technology. Never once did I imagine that it was the state welfare software.
In many cases, it's literally not legal for them to do so.
For example, at the Federal level: https://en.wikipedia.org/wiki/General_Schedule_(US_civil_ser...
(These restrictions don't tend to apply to hiring one via a contractor at $250-500k/year, though. Sigh.)
If a defense contractor wants to pay someone that kind of money they generally have to pay the difference between what dcaa allows and that price out of their own overhead.
For most defence contractors, the government is the only client. They can't be passing 100% of their income to their employees. So why not charge 60k labour, 440k for overheads, and pay some of that 440k to the guy actually doing the work?
And that’s the point, it’s why you don’t see people getting paid 500k a year to work for the government - even as a contractor.
They very well may have to go that route, i.e. some greybeard independent contractor that can name their price. It's a very limited skillset and God knows this ain't the kind of work that gets the super talented motivated.
To hire someone who can do the job reasonably quick and well is really expensive no matter how you slice it. Consider it a 'job well done' if you can persuade them to:
b) Come out of said retirement to do actual work in the trenches again - as opposed to management.
In the private sector, these people have probably made the equivalent of GS-15 Step 10 for years if not decades. Good luck trying to convince them to jump back in for what is essentially a pay cut.
If you're making that kind of money, you have a lot better options than working on some ancient COBOL system that processes unemployment claims.
There's more to life than money and tech. I'm sure there are plenty of people who would be happy to work on a boring tech stack in helping to address possibly the largest public crisis many of us will see in our lifetimes vs. working with the new fad of the week in pursuit of selling ads marginally more efficiently.
Why spend the money and invest now for the future, when you can lean on people to donate their efforts in times of crisis?
First, no one said anything about donating effort...the scenario was getting paid a decent, if not quite FAANG, salary to work on an older tech stack. And sure, you _could_ take that approach. We tried it with pandemic preparation, let's see how that works out.
Just giving a frigging UBI for at least the duration of this crisis would solve all of these problems and work much better.
Maybe $0 is hyperbole, but there is no chance NJ makes good on all of its defined benefit pension promises, and I would rather just get all cash/401k as compensation.
While there are problems with lowest-bidder-win, the real issue here is that systems like this are more living and breathing than one-off; you need a teams that tend to them, not bringing in a contractor.
It is, but you can't have any joe schmoe off the street coming in and learn how to pour concrete in a day. This is something that requires practice and problem solving skills. And years of it.
Lack of foresight, lack of understanding that codebases are a living thing and are never "done". But hey, let's all work for ad companies and put our best minds at solving how we could make people see more ads!
Isn't it the power of the executive branch to requisition corporations or people in time of deep crisis in order maintain the continuity of government and its critical systems? Isn't unemployment claims such a critical system?
UI is mostly federally funded so they need to coordinate with them, and the complexity of the business rules and minimal funding during good times makes it a difficult task.
Also these systems generally work well, and it’s hard to fix things that aren’t broken. They just cannot handle the never before seen volume — it’s unlikely that a more modern enterprise system would either.
sorry but that is just false. a Properly designed modern system would handle horizontal scaling just fine.
Granted the government would likely pay a billion dollars to have a screwed up system developed by on of the "big guys" that has the same problems as they current system, most likely because it would be designed by committee and not by engineers.
However to say that modern systems could not handle this kind of problem is just wrong. There are all kinds of ways to handle a sudden increase in load.
If New Jersey landed a replacement UI system in 2010, it would be some sort of J2EE monstrosity on some outdated Websphere/JBoss/BEA/Oracle platform probably still dependent on some mainframe component.
The desperation for COBOL people is almost certainly because the (very complex) business rules are embedded in code that has been evolving for decades. Just changing anything is hard because it is a security nightmare (touches tax data, social security, dmv, and more) and regulated by all sorts of security/compliance frameworks that are difficult to implement and sometimes conflicting!
As the saying goes, Government: if you think you have problems just wait until you see our solutions
And this is a department that have billions.
It’s when you have to account for the differences between each state (50 factors!) is where the software becomes O(n^n) complex over the development of this product.
Even the best private companies struggle to build similar systems for a single entity.
I think each state should be accountable for their own programs. Avoids the “single point of failure” issue as well.
Difficulty (and/or downright hate, for many;) lies in
1. Ecosystem - obscure libraries rules and os that don't jive with posix-like mindset
2. Legacy code - having to dig into a ginormous monolithic program and figure out what some obscure pieces of code do, untouched and undocumented by anybody in your team, with ridiculous interdependencies and complexities.
So it tends to be more of "how hard is Cobol in this particular application for this specific client" :-/
open-cobol/bionic 1.1-2 amd64
When I worked at IBM not TOO long ago there were times when I had to fix a bug in WebSphere that only manifested on z/OS or zLinux and those were hands down the hardest bugs to fix. And that was a relatively modern codebase, by mainframe standards.
However, not all - I've personally been dealing peripherally with COBOL on UNIX/Linux via IBM or MicroFocus compilers for decades - and it even works on Windows :-O
There's also tiny-cobol, but the project is dead and it only targets x86-32.
>System z is a living fossil; it is computing archaeology; computing palaeontology. System z is an example of the principle "If it ain't broke, don't fix it" carried to its logical extreme. System z and its predecessors haven't broken for forty-five years: the "z" stands for "zero downtime" and some of these machines have been running continuously for decades without a reboot. Nor, therefore, have any of them ever been "fixed".
>It uses EBCDIC, a character encoding wholly incompatible with ASCII featuring such delights as non-contiguous letter sequences. It was, from 1983 to 2000, a 31-bit operating system. (Yes, thirty-one.) It does things with virtualisation of system resources and operating systems themselves that were thirty years ahead of their time, but all the interaction with z machines is still performed through an archaic green screen system from the 1970s, running in an emulator, with a 24x80 character screen. The screen is 80 characters wide because that is how many characters you could fit on a punch card.
>The output from the Job Entry System, however, is 132 characters wide, because that was how many characters you could fit on the line printer where the output came out. Nowadays, of course, the output comes to the green screen. So you always have to scroll left and right to see all of it. The keys for scrolling left and right are F7 and F8. For scrolling up and down? F10 and F11. No, Page Up and Page Down will do nothing.
>To enter a command? You hit the right Ctrl key. "Return" will do nothing. "Enter" will work, of course, but, AS YOU KNOW, "Return" and "Enter" are separate keys on your keyboard. "Return" is just above the right Shift key. "Enter" is way over next to the numeric keypad.
Just FYI, my laptop has "Enter" clearly printed on both keys.
The major issue is the code written in it. Remember, a lot of COBOL code comes from a time before a lot of programming best practices were discovered. Structured programming-- as in, actually having function calls instead of just GOTO statements everywhere-- was a novel hoity-toity concept when COBOL first existed. Relational databases? Forget about it, they won't exist for another decade and a half. You get flat files; if you're lucky there might be field separators, if you're unlucky you'll have to find the column widths in the code somewhere. And don't even think that any of it is documented.
That's the sort of thing you're taking on when you jump into a legacy COBOL system.
I saw another post claim that COBOL programs primarily used flat files and had no concept of ISAM/VSAM/DB2 or relational constructs. Nothing could be further from the truth! In the late ‘70’s COBOL became the primary langauge for processing in CICS or IMS real time transactions. Flat fileS, eh. Ha
Youdon structured design was introduced about 1976 and 1977 - by 1980 only the very smallest IT shops weren’t coding in compliance with structured programming standard that did not allow goto’s. A programmer was unlikely to find a job in a good shop without structured coding experience.
Given New Jersey only began constructing applications in the 1980’s, then evolved for 30+ years - it is very likely most of the code containing go to’s and like code that were difficult to maintain were updated and rewritten in conjunction with other enhancements. Major enhancement projects were often used to fund rewrites in this manner. I am not saying New Jersey did this, I am saying any competently managed IT organization would have done this because that was considered best practices.
Let someone who has actually examined the code tell us how bad it actually is. Heck, if they are really an SDLC shop, there may actually be documentation! Lol
They are just manual tests written up on literal, actual TPS reports (TPS = Test Procedure Specification) to be executed by humans.
And were widely used, at one point.
Where I worked, original test data was sparse and incomplete, and it avoided edge conditions. I, on the other hand, loved breaking stuff.
The hardest part for me, is IO was not handled by the application, so all your file IO was setup by the JCL job that called the cobol program, which just feels weird.
It's actually quite easy to read, and much closer to plain english than say, C.
Despite this story and others, still think I made the right call for me!
That other stuff really isn’t that hard. Most of it is copy and paste-able once someone explains it to you. It’s really easy. It could also likely be handled by someone else for a situation like this with new-comers simply writing cobol.
the language in itself is archaic but there's nothing difficult in it