This is about the MUMPS 1976 standard. I'm not aware of any jobs where this is required. It's purely interesting for historical reasons. The article is part of my anniversary project (https://github.com/rochus-keller/MUMPS/). I neither think that "your career will suffer" if you do Ada, Fortran, Mumps (i.e. M/Cache/IRIS or GT.M/YottaDB), RPG or Cobol projects. Specialists are well paid, particularly with mainframe and domain experience.
I will say (if you have that first 5-10 years of experience or so), there is real value in becoming an expert in some enterprise technology that was extremely popular 20+ years ago. The COBOL consultants getting $500 an hour right before Y2K might be an exaggeration, but you can build a career on getting businesses out of legacy systems messes.
My father is an expert on the IRS-specific IBM 360 Assembly code base and their tangled webs of attempts to get off of it, and it made for a very comfortable (and well compensated) role for the last 20 years of his career.
I would definitely not suggest COBOL or MUMPS to a 20 year old, but as a niche for a 30 year old for a stable gig? Some of these legacy systems are never going away.
There is lately a lot of buzz about hiring "TENEX Engineers" so if you've got some old-school experience in TENEX, probably time to add it back in your CV!
> but as a niche for a 30 year old for a stable gig? Some of these legacy systems are never going away...
It's not as stable as you would think.
I have some acquaintances at JPMC and GS who have led internal initiatives to leverage foundation models to translate COBOL and other legacy software into more modern frameworks with decent success over the past 24 months.
What else couldn't be done by foundation models was then offshored to their dev teams in India, Poland, and Romania.
Hyperspecializing in a niche and ignoring other newer innovations is also setting yourself up for failure long term as of 2026.
If one cannot be bothered to deep dive into newer shifts in technology in order to both understand their pros and cons, it's hard to justify hiring them.
I know a caboodle/cache admin at $dayjob, and I've never heard them mention chronicles... is it more of an internal codename than an actual function of the db?
Thats kindof complicated... I remember when an EMR only needed one sysadmin and no specialist knowledge... on our old system any errors were handled by the vendor.
I wish someone made something similar for Forth. Too many times I encountered something explained about forth that itself needed explanation for operators
I have never touched Claude Code and don't have any plans to use it. This is about the history of MUMPS. No reason to dwell on this if you're not interested in the topic (and even less reason to complain about it).
You won’t be able to learn the industry best practices or the modern tools, because MUMPS predates them, and your career will suffer for it.
My father is an expert on the IRS-specific IBM 360 Assembly code base and their tangled webs of attempts to get off of it, and it made for a very comfortable (and well compensated) role for the last 20 years of his career.
I would definitely not suggest COBOL or MUMPS to a 20 year old, but as a niche for a 30 year old for a stable gig? Some of these legacy systems are never going away.
https://youtu.be/6h6dhevlb0w?si=Z9RE-HHl3ovrPy8n
It's not as stable as you would think.
I have some acquaintances at JPMC and GS who have led internal initiatives to leverage foundation models to translate COBOL and other legacy software into more modern frameworks with decent success over the past 24 months.
What else couldn't be done by foundation models was then offshored to their dev teams in India, Poland, and Romania.
Hyperspecializing in a niche and ignoring other newer innovations is also setting yourself up for failure long term as of 2026.
If one cannot be bothered to deep dive into newer shifts in technology in order to both understand their pros and cons, it's hard to justify hiring them.
I wish someone made something similar for Forth. Too many times I encountered something explained about forth that itself needed explanation for operators