9 ms·

Mainframes Are Having a Moment

57 points by jbkavungal 6y ago

nulbyte 6y ago
Mainframes have been having a moment. Or, perhaps more accurately, certain enterprises are finally waking up to the fact that firing all those mainframers wasn't the best idea for the long-term. The current problem isn't the lack of interest of availability of training; both would be there if it weren't for the fact that enterprises are more interested in having their code written by consulting companies in India than by domestic employees.
- heisenbit 6y ago
  It is not only lay offs it is also retirements. And the pressure is mounting with baby boomers gone soon. I was once in a discussion taking over the maintenance of a system and the picture was grim. The crew running the system was so thin it was hard to imagine them having the time handing it over. Besides they barely understood all the details as the system had been build by people 30 years ago all gone a long time ago. A big bowl of spaghetti in a core part of their enterprise. We decided not to try to take this on - too much risk.
  - rtempaccount1 6y ago
    I was at a talk about mainframe security recently where the state of play with one company was, there were three users in their admins group for the mainframe, two had retired, and the third was past retirement age... When you combine retirements with decades of under-documented code doing critical functions, it's not a recipe for good long term success...
    - scottlocklin 6y ago
      I dunno; rewriting it in some shit tier EC2 FunNewLang framework that changes every year doesn't sound like a recipe for long term success either. When I look at how mainframes work, and how "clouds" work, I wonder at how imbecilic IBM management (or one of their competitors) must have been to not capture that value in the first place.
      - w3ll_w3ll_w3ll 6y ago
        "The Eternal Mainframe" http://www.winestockwebdesign.com/Essays/Eternal_Mainframe.html http://www.winestockwebdesign.com/Essays/Eternal_Mainframe.h...
      - rtempaccount1 6y ago
        There is a middle ground between those two extremes of course. I'm not surprised at the mainframe's lack of success at all, the barriers to entry are extreme, meaning there's an inevitable lack of activity. I've worked in environments which had mainframes deployed and even as an employee it was inordinately difficult to get any access to them. Combine that with IBM's "enterprise" sales process and it's not a mystery that they lost the fight to attract newer systems...
DebtDeflation 6y ago
The surge in demand is being driven almost entirely by state unemployment systems. Most of these systems haven't seen a surge in unemployment claims since the 2009 recession and haven't had to change the underlying rules governing eligibility in even longer. Once the systems are patched and/or the surge in new claims subsides, 90% of this sudden demand for "Cobalt programmers" will evaporate. It's one thing for retired mainframe programmers to come out of retirement and work as consultants for a few months, it's quite another to start changing CS curricula nationwide along with launching mainframe bootcamps for career changers. I'd urge caution.
- carlmr 6y ago
  Whenever you see "urgent need" in headlines it's too late to profit from this crisis. If anything learn COBOL in about 10 years for the next crisis.
  - TAForObvReasons 6y ago
    There were pre-crisis efforts to address this. NJ for example awarded a contract to Electronic Data Systems (now HP) which fell by the wayside [1]. Given the complexities of total rewrites compared to patchwork, I'd bet there will still be demand in the future. [1] https://www.nj.com/politics/2014/11/nj_ends_118_million_contract_to_boost_enrollment_in_obamacare_other_social_service_programs.html https://www.nj.com/politics/2014/11/nj_ends_118_million_cont...
  - zeckalpha 6y ago
    Maybe the 2038 problem?
    - segfaultbuserr 6y ago
      To be fair, Linux kernel devs have been working hard to solve the problem for years, with progress coming in every new kernel version. The works required at the kernel upstream is almost completed [0]. Now the ball moves to libc, and the progress is optimistic. Indeed, what happens to those already deployed legacy systems and programs are another story. [0] https://lwn.net/Articles/776435/ https://lwn.net/Articles/776435/
eggy 6y ago
I used to work at an environmental law firm in downtown Manhattan and accounting and other core financial systems were running on a VAX OpenVMS mainframe, and the document creation and storage was on PCs over a Token Ring, Banyan VINES network. The DOD was using VINES at the time. Memories of playing DOOM in 1994 downloaded from an FTP server somewhere while working the night shift to make backups on huge tape cartridges. The VAX system was pretty reliable and easy to deal with IIRC. A good thing from a hardware/help desk angle is that you didn't really need to troubleshoot terminals; they broke (keys or monitor) and required replacing. The mainframe was in the climate-controlled room, all in one place for any hardware servicing. I think Token Ring primarily was replaced because cheap, twisted-pair wiring made Ethernet less expensive. Token Ring had these twist-on bulky connectors. In a way we almost went there with Chromebooks basically being pared-down PCs and being served by a virtual mainframe, the cloud ("Spenser Confidential" movie "Give me the cloud scene" is hilarious).
- tgflynn 6y ago
  VAX's were minicomputers, not mainframes.
  - m463 6y ago
    You're correct, although they did frequently have some of the hallmarks of "mainframes" like raised floors/cooling. It's amusing to look up "mainframe" on wikipedia and see what appears to be compact server racks. Shouldn't a mainframe take up a room, or even a whole floor?
  - Zenst 6y ago
    https://en.wikipedia.org/wiki/VAX_9000 https://en.wikipedia.org/wiki/VAX_9000 "The VAX 9000, code named Aridus or Aquarius, was a family of supercomputer and mainframe computers developed and manufactured by Digital Equipment Corporation (DEC) using processors implementing the VAX instruction set architecture (ISA)."
    - tgflynn 6y ago
      I never heard of that model. I suspect it probably wasn't very successful because DEC started to move to the Alpha architecture not many years later. I worked with a lot of VAXen back in the day but I never heard anyone refer to them as "mainframes".
djohnston 6y ago
is the inertia of rewriting these systems in a modern stack so great that it's cheaper to keep finding COBOL specialists forever? why not just sit down and rewrite these systems?
- cultus 6y ago
  COBOL is unstructured. It doesn't even have functions. When you've got some million+ line tangled mass that has all kinds of undocumented behavior, it's really better just to add more duct tape and punt it off to the poor bastard who actually has to fix it in 20 years.
  - neverartful 6y ago
    COBOL for IBM mainframe running z/OS does have subroutines. (I don't know if you're making a distinction between procedures and functions.)
  - pjmlp 6y ago
    Since 1985 that COBOL can be structured, and since 2002 object oriented as well, with the latest ISO update being done in 2014 Besides compiling to native code, there are compilers that target JVM and CLR as well.
    - jimbokun 6y ago
      > there are compilers that target JVM and CLR So could you wrap it and slowly add new features and replace pieces with Java code over time, using JVM for interop?
      - pjmlp 6y ago
        Yes, it is possible, for example check Visual Cobol from Micro Focus. https://www.microfocus.com/en-us/products/visual-cobol/overview https://www.microfocus.com/en-us/products/visual-cobol/overv...
    - cultus 6y ago
RickJWagner 6y ago
COBOL is living proof of the power of incumbency. Once technology is entrenched, it becomes self-sufficient and very, very difficult to replace. I remember when mainframe/COBOL apps were being re-written for the client/server era, often using tools like Tuxedo/c++ for the backend and Visual Basic for the front-end. Where are those re-writes now? (Probably replaced a couple of times again, where the COBOL-remainers are still in place.) I think the days of higher-paying COBOL gigs are still ahead of us. When the greybeards actually go away, there will be a strong need to fill.
- m463 6y ago
  COBOL might just be software properly amortized.
wyldfire 6y ago
IMO the hard part isn't learning COBOL -- that's just another programming language. It's learning the whole operating environment that comes with it -- mainframes. Stuff like JCL, EBCDIC, PDS. I did this for a year or so back in 1999. It felt very ancient back then. If you invest your time in gaining expertise with these technologies, you are not doing your career any favors.
- 0x445442 6y ago
  Depends on your point of reference. If you buy into the ecology you could build a sane career where experience actually meant something instead of being level set every two years by the new shiny tech stack that's going to save the industry.
annoyingnoob 6y ago
Mainframes - the original cloud computers. I started on mini-mainframes but then worked mostly with networks of PCs. The old mainframes guys used to say 'just you wait the pendulum will swing back to centralized computing'. In the age of cloud computing they were right, and those mainframes are still there too.
dfboyd 6y ago
I think this is just an IBM PR piece. It ticks all the boxes: quotes from IBM customers, quotes from IBM staff, mentions the "Master the Mainframe" contest. You can tell because when it says "mainframe" it doesn't mean "any large computer", it means "Something descended from the IBM 360".
- tgflynn 6y ago
  Yes, because that's what the word "mainframe" means today, simply because all other machine architectures that were considered mainframes are now extinct. I'm not saying it's not IBM PR, though.
  - AnimalMuppet 6y ago
    Unisys's ClearPath series are considered to be mainframes (or so says Wikipedia). The most recent ClearPath Dorado model was introduced in 2015. As for the article: This may be what Paul Graham called a "submarine".
    - pinewurst 6y ago
      Unisys represents two different mainframe families - those descending from Univac/Sperry 1100 and those descending from the Burroughs mainframes. Both are purely emulated on x64 these days. Personally I think the latter are especially interesting, much more so than IBM! IBM is really going with whatever positive publicity they can muster trying to obscure the profoundly awful age discrimination that they’re guilty of. It’s brutally ironic that the same people who are preaching “young people need to do mainframe” are the same who are aggressively ditching their own senior, experienced, expensive mainframe people.
      - skissane 6y ago
        There are more surviving mainframe families than just IBM and Unisys: - Groupe Bull still supports GCOS mainframes (descended from General Electric GECOS) - NEC still supports ACOS mainframes (also descended from General Electric GECOS, but a different fork from Bull's) – only sold/used in Japan now, although in past decades NEC did attempt to sell them outside of Japan (not sure if anyone bought them though) - Fujitsu still supports ICL VME mainframes (still used by some UK government agencies) and BS2000/OSD (still used in Germany mainly) - I think some Fujitsu MSP and Hitachi VOS3 systems survive in Japan. (These are less than 100% compatible forks of IBM MVS.) They also used to exist in some other countries–e.g. here in Australia, although I doubt any are left here.
qwerty456127 6y ago
Unemployment applications are fairly small structured text records requiring some rather simple logic to process. I believe a single server built on a most powerful x86 CPU available today running an MS SQL Server instance (or Postrges perhaps, but I don't have experience with it) is more than enough to process all the unemployment applications on the whole fereakin planet. Why do they insist on using an ancient mainframe? That sounds fun but bizarrely irrational.
louiechristie 6y ago
COBOL in 100 seconds: https://www.youtube.com/watch?v=7d7-etf-wNI https://www.youtube.com/watch?v=7d7-etf-wNI

57 points by jbkavungal 6y ago

Mainframes have been having a moment. Or, perhaps more accurately, certain enterprises are finally waking up to the fact that firing all those mainframers wasn't the best idea for the long-term. The current problem isn't the lack of interest of availability of training; both would be there if it weren't for the fact that enterprises are more interested in having their code written by consulting companies in India than by domestic employees.

heisenbit 6y ago
It is not only lay offs it is also retirements. And the pressure is mounting with baby boomers gone soon. I was once in a discussion taking over the maintenance of a system and the picture was grim. The crew running the system was so thin it was hard to imagine them having the time handing it over. Besides they barely understood all the details as the system had been build by people 30 years ago all gone a long time ago. A big bowl of spaghetti in a core part of their enterprise. We decided not to try to take this on - too much risk.
- rtempaccount1 6y ago
  I was at a talk about mainframe security recently where the state of play with one company was, there were three users in their admins group for the mainframe, two had retired, and the third was past retirement age... When you combine retirements with decades of under-documented code doing critical functions, it's not a recipe for good long term success...
  - scottlocklin 6y ago
    I dunno; rewriting it in some shit tier EC2 FunNewLang framework that changes every year doesn't sound like a recipe for long term success either. When I look at how mainframes work, and how "clouds" work, I wonder at how imbecilic IBM management (or one of their competitors) must have been to not capture that value in the first place.
    - w3ll_w3ll_w3ll 6y ago
      "The Eternal Mainframe" http://www.winestockwebdesign.com/Essays/Eternal_Mainframe.html http://www.winestockwebdesign.com/Essays/Eternal_Mainframe.h...
    - rtempaccount1 6y ago
      There is a middle ground between those two extremes of course. I'm not surprised at the mainframe's lack of success at all, the barriers to entry are extreme, meaning there's an inevitable lack of activity. I've worked in environments which had mainframes deployed and even as an employee it was inordinately difficult to get any access to them. Combine that with IBM's "enterprise" sales process and it's not a mystery that they lost the fight to attract newer systems...

DebtDeflation 6y ago

The surge in demand is being driven almost entirely by state unemployment systems. Most of these systems haven't seen a surge in unemployment claims since the 2009 recession and haven't had to change the underlying rules governing eligibility in even longer. Once the systems are patched and/or the surge in new claims subsides, 90% of this sudden demand for "Cobalt programmers" will evaporate. It's one thing for retired mainframe programmers to come out of retirement and work as consultants for a few months, it's quite another to start changing CS curricula nationwide along with launching mainframe bootcamps for career changers. I'd urge caution.

carlmr 6y ago
Whenever you see "urgent need" in headlines it's too late to profit from this crisis. If anything learn COBOL in about 10 years for the next crisis.
- TAForObvReasons 6y ago
  There were pre-crisis efforts to address this. NJ for example awarded a contract to Electronic Data Systems (now HP) which fell by the wayside [1]. Given the complexities of total rewrites compared to patchwork, I'd bet there will still be demand in the future. [1] https://www.nj.com/politics/2014/11/nj_ends_118_million_contract_to_boost_enrollment_in_obamacare_other_social_service_programs.html https://www.nj.com/politics/2014/11/nj_ends_118_million_cont...
- zeckalpha 6y ago
  Maybe the 2038 problem?
  - segfaultbuserr 6y ago
    To be fair, Linux kernel devs have been working hard to solve the problem for years, with progress coming in every new kernel version. The works required at the kernel upstream is almost completed [0]. Now the ball moves to libc, and the progress is optimistic. Indeed, what happens to those already deployed legacy systems and programs are another story. [0] https://lwn.net/Articles/776435/ https://lwn.net/Articles/776435/

eggy 6y ago

I used to work at an environmental law firm in downtown Manhattan and accounting and other core financial systems were running on a VAX OpenVMS mainframe, and the document creation and storage was on PCs over a Token Ring, Banyan VINES network. The DOD was using VINES at the time. Memories of playing DOOM in 1994 downloaded from an FTP server somewhere while working the night shift to make backups on huge tape cartridges. The VAX system was pretty reliable and easy to deal with IIRC. A good thing from a hardware/help desk angle is that you didn't really need to troubleshoot terminals; they broke (keys or monitor) and required replacing. The mainframe was in the climate-controlled room, all in one place for any hardware servicing. I think Token Ring primarily was replaced because cheap, twisted-pair wiring made Ethernet less expensive. Token Ring had these twist-on bulky connectors. In a way we almost went there with Chromebooks basically being pared-down PCs and being served by a virtual mainframe, the cloud ("Spenser Confidential" movie "Give me the cloud scene" is hilarious).

tgflynn 6y ago
VAX's were minicomputers, not mainframes.
- m463 6y ago
  You're correct, although they did frequently have some of the hallmarks of "mainframes" like raised floors/cooling. It's amusing to look up "mainframe" on wikipedia and see what appears to be compact server racks. Shouldn't a mainframe take up a room, or even a whole floor?
- Zenst 6y ago
  https://en.wikipedia.org/wiki/VAX_9000 https://en.wikipedia.org/wiki/VAX_9000 "The VAX 9000, code named Aridus or Aquarius, was a family of supercomputer and mainframe computers developed and manufactured by Digital Equipment Corporation (DEC) using processors implementing the VAX instruction set architecture (ISA)."
  - tgflynn 6y ago
    I never heard of that model. I suspect it probably wasn't very successful because DEC started to move to the Alpha architecture not many years later. I worked with a lot of VAXen back in the day but I never heard anyone refer to them as "mainframes".

djohnston 6y ago

is the inertia of rewriting these systems in a modern stack so great that it's cheaper to keep finding COBOL specialists forever? why not just sit down and rewrite these systems?

cultus 6y ago
COBOL is unstructured. It doesn't even have functions. When you've got some million+ line tangled mass that has all kinds of undocumented behavior, it's really better just to add more duct tape and punt it off to the poor bastard who actually has to fix it in 20 years.
- neverartful 6y ago
  COBOL for IBM mainframe running z/OS does have subroutines. (I don't know if you're making a distinction between procedures and functions.)
- pjmlp 6y ago
  Since 1985 that COBOL can be structured, and since 2002 object oriented as well, with the latest ISO update being done in 2014 Besides compiling to native code, there are compilers that target JVM and CLR as well.
  - jimbokun 6y ago
    > there are compilers that target JVM and CLR So could you wrap it and slowly add new features and replace pieces with Java code over time, using JVM for interop?
    - pjmlp 6y ago
      Yes, it is possible, for example check Visual Cobol from Micro Focus. https://www.microfocus.com/en-us/products/visual-cobol/overview https://www.microfocus.com/en-us/products/visual-cobol/overv...
  - cultus 6y ago

RickJWagner 6y ago

COBOL is living proof of the power of incumbency. Once technology is entrenched, it becomes self-sufficient and very, very difficult to replace. I remember when mainframe/COBOL apps were being re-written for the client/server era, often using tools like Tuxedo/c++ for the backend and Visual Basic for the front-end. Where are those re-writes now? (Probably replaced a couple of times again, where the COBOL-remainers are still in place.) I think the days of higher-paying COBOL gigs are still ahead of us. When the greybeards actually go away, there will be a strong need to fill.

m463 6y ago
COBOL might just be software properly amortized.

wyldfire 6y ago

IMO the hard part isn't learning COBOL -- that's just another programming language. It's learning the whole operating environment that comes with it -- mainframes. Stuff like JCL, EBCDIC, PDS. I did this for a year or so back in 1999. It felt very ancient back then. If you invest your time in gaining expertise with these technologies, you are not doing your career any favors.

0x445442 6y ago
Depends on your point of reference. If you buy into the ecology you could build a sane career where experience actually meant something instead of being level set every two years by the new shiny tech stack that's going to save the industry.

annoyingnoob 6y ago

Mainframes - the original cloud computers. I started on mini-mainframes but then worked mostly with networks of PCs. The old mainframes guys used to say 'just you wait the pendulum will swing back to centralized computing'. In the age of cloud computing they were right, and those mainframes are still there too.

dfboyd 6y ago

I think this is just an IBM PR piece. It ticks all the boxes: quotes from IBM customers, quotes from IBM staff, mentions the "Master the Mainframe" contest. You can tell because when it says "mainframe" it doesn't mean "any large computer", it means "Something descended from the IBM 360".

tgflynn 6y ago
Yes, because that's what the word "mainframe" means today, simply because all other machine architectures that were considered mainframes are now extinct. I'm not saying it's not IBM PR, though.
- AnimalMuppet 6y ago
  Unisys's ClearPath series are considered to be mainframes (or so says Wikipedia). The most recent ClearPath Dorado model was introduced in 2015. As for the article: This may be what Paul Graham called a "submarine".
  - pinewurst 6y ago
    Unisys represents two different mainframe families - those descending from Univac/Sperry 1100 and those descending from the Burroughs mainframes. Both are purely emulated on x64 these days. Personally I think the latter are especially interesting, much more so than IBM! IBM is really going with whatever positive publicity they can muster trying to obscure the profoundly awful age discrimination that they’re guilty of. It’s brutally ironic that the same people who are preaching “young people need to do mainframe” are the same who are aggressively ditching their own senior, experienced, expensive mainframe people.
    - skissane 6y ago
      There are more surviving mainframe families than just IBM and Unisys: - Groupe Bull still supports GCOS mainframes (descended from General Electric GECOS) - NEC still supports ACOS mainframes (also descended from General Electric GECOS, but a different fork from Bull's) – only sold/used in Japan now, although in past decades NEC did attempt to sell them outside of Japan (not sure if anyone bought them though) - Fujitsu still supports ICL VME mainframes (still used by some UK government agencies) and BS2000/OSD (still used in Germany mainly) - I think some Fujitsu MSP and Hitachi VOS3 systems survive in Japan. (These are less than 100% compatible forks of IBM MVS.) They also used to exist in some other countries–e.g. here in Australia, although I doubt any are left here.

qwerty456127 6y ago

Unemployment applications are fairly small structured text records requiring some rather simple logic to process. I believe a single server built on a most powerful x86 CPU available today running an MS SQL Server instance (or Postrges perhaps, but I don't have experience with it) is more than enough to process all the unemployment applications on the whole fereakin planet. Why do they insist on using an ancient mainframe? That sounds fun but bizarrely irrational.

louiechristie 6y ago

COBOL in 100 seconds: https://www.youtube.com/watch?v=7d7-etf-wNI https://www.youtube.com/watch?v=7d7-etf-wNI