4 ms·

Not a COBOL developer, but working at a sizeable bank I witnessed the phasing out of their mainframes and AS400 systems. They ran some critical systems, both in

Not a COBOL developer, but working at a sizeable bank I witnessed the phasing out of their mainframes and AS400 systems. They ran some critical systems, both in retail and wholesale banking. They either converted to java, and optimized that code, but some COBOL code from the mainframe, and all of the AS400 stuff was converted into Micro Focus COBOL, which runs on Windows, which could be hosted on our Private Cloud. I worked on helping them migrate to our cloud infra, which was an interesting exercise. There was a very tangible cultural gap between the people maintaining and developing these applications and the rest of the organization.

datpuz 1y ago
Can you describe the cultural gap? I haven't really met these folks in the wild, so I'm curious what the programmers of yore were like.
- isbvhodnvemrwvn 1y ago
  When I worked for a retailer whose logistics ran on IBM mainframes, one of the milestones was getting COBOL devs to use version control.
- breakingrules3 1y ago
  [dead]
- FL410 1y ago
  In my experience, it's usually lack of awareness about modern security risks, and lack of familiarity with modern infrastructure paradigms. The latter really isn't a problem since these systems are usually standalone, but the former does become a problem - they often are from a time where this just wasn't something to consider. As a result, these legacy systems are often using default passwords, have tons of crazy stuff exposed to the network, and are comprised of custom code written specifically for the business purpose (so the documentation is only as good as what they made). On the other hand, these guys generally write pretty neat, lean code that is quick, reliable, and directly responsive to the business. The really fun thing is watching the users fly through the keyboard-only screens, sometimes with muscle memory that is faster than the terminal emulator can update - they're literally working ahead of the screens.
  - mvdwoord 1y ago
    Oh yes, I remember that when we swapped out a bunch of terminals at an airline.. The users complained it was all way too slow on the new Windows machines with MS SNA server in between... I was wondering what it was all about, as a young and very naive dropout from uni on his first IT job. When I came down, this dude was banging on his keyboard and after some time stopped, pointed at the screen and you could see it slowly catching up, screen by screen.. He showed me the directly connected version next. I learned something that day.
    - datpuz 1y ago
      That's awesome. I set up Arch Linux a while ago, and despite working in Linux shops for more than a decade, let's just say I was very out of my element...
  - justin66 1y ago
    In my experience mainframes at financial institutions are hidden behind IBM middleboxes that are specifically designed to obviate the infrastructure risks. It's a classic example of a company selling you both the problem and solution.
    - ASalazarMX 1y ago
      That's just an example of incremental improvement. Mainframes and midranges adapt with the times without losing what works. Modern midranges, for example, can run C, Python, bash, and web servers.
  - james_marks 1y ago
    Reminds of the DOS order management software I used in the 90’s. ASCII tables, text only, with F key shortcuts. Hard to learn but blazing fast once you did. Nothing modern approaches it.
    - deepsun 1y ago
      Reminds me of modern IDEs -- developers, both old and new, are too lazy to learn a complex IDE to speed up their work, even though it's their main tool for making money.
- mvdwoord 1y ago
  I would say these people were in a relationship with the mainframe, if that makes sense. And also having worked at IBM in the past where I sat adjacent to the mainframe support team for Business Services, I totally get it. Mainframes are awesome if you ask me, and in a sense we have been trying to reinvent a lot of its goodness with "commodity" x86 hardware. From a technical-cultural perspective it was mostly sulkiness, and a complete and utter lack of embracing the paradigms of distributed computing. Also, like most internal clouds, there were plenty of issues as it was. Initially they just tried to replace mainframe application components 1:1 onto VMs in whatever way and whenever anything was <100% reliable they complained that our cloud was not able to do it. I had to explain in a very harsh way, under a lot of pressure (I believe not hitting the deadline of switching off the mainframes meant renewal for a year at 40 Mil.. or thereabouts) the realities of "cloud". The developers I spoke with in that time though, were very much the opposite of the move fast breaking things crowd. Intelligent, but also narrow minded I would say.

datpuz 1y ago

Can you describe the cultural gap? I haven't really met these folks in the wild, so I'm curious what the programmers of yore were like.

isbvhodnvemrwvn 1y ago
When I worked for a retailer whose logistics ran on IBM mainframes, one of the milestones was getting COBOL devs to use version control.
breakingrules3 1y ago
[dead]
FL410 1y ago
In my experience, it's usually lack of awareness about modern security risks, and lack of familiarity with modern infrastructure paradigms. The latter really isn't a problem since these systems are usually standalone, but the former does become a problem - they often are from a time where this just wasn't something to consider. As a result, these legacy systems are often using default passwords, have tons of crazy stuff exposed to the network, and are comprised of custom code written specifically for the business purpose (so the documentation is only as good as what they made). On the other hand, these guys generally write pretty neat, lean code that is quick, reliable, and directly responsive to the business. The really fun thing is watching the users fly through the keyboard-only screens, sometimes with muscle memory that is faster than the terminal emulator can update - they're literally working ahead of the screens.
- mvdwoord 1y ago
  Oh yes, I remember that when we swapped out a bunch of terminals at an airline.. The users complained it was all way too slow on the new Windows machines with MS SNA server in between... I was wondering what it was all about, as a young and very naive dropout from uni on his first IT job. When I came down, this dude was banging on his keyboard and after some time stopped, pointed at the screen and you could see it slowly catching up, screen by screen.. He showed me the directly connected version next. I learned something that day.
  - datpuz 1y ago
    That's awesome. I set up Arch Linux a while ago, and despite working in Linux shops for more than a decade, let's just say I was very out of my element...
- justin66 1y ago
  In my experience mainframes at financial institutions are hidden behind IBM middleboxes that are specifically designed to obviate the infrastructure risks. It's a classic example of a company selling you both the problem and solution.
  - ASalazarMX 1y ago
    That's just an example of incremental improvement. Mainframes and midranges adapt with the times without losing what works. Modern midranges, for example, can run C, Python, bash, and web servers.
- james_marks 1y ago
  Reminds of the DOS order management software I used in the 90’s. ASCII tables, text only, with F key shortcuts. Hard to learn but blazing fast once you did. Nothing modern approaches it.
  - deepsun 1y ago
    Reminds me of modern IDEs -- developers, both old and new, are too lazy to learn a complex IDE to speed up their work, even though it's their main tool for making money.
mvdwoord 1y ago
I would say these people were in a relationship with the mainframe, if that makes sense. And also having worked at IBM in the past where I sat adjacent to the mainframe support team for Business Services, I totally get it. Mainframes are awesome if you ask me, and in a sense we have been trying to reinvent a lot of its goodness with "commodity" x86 hardware. From a technical-cultural perspective it was mostly sulkiness, and a complete and utter lack of embracing the paradigms of distributed computing. Also, like most internal clouds, there were plenty of issues as it was. Initially they just tried to replace mainframe application components 1:1 onto VMs in whatever way and whenever anything was <100% reliable they complained that our cloud was not able to do it. I had to explain in a very harsh way, under a lot of pressure (I believe not hitting the deadline of switching off the mainframes meant renewal for a year at 40 Mil.. or thereabouts) the realities of "cloud". The developers I spoke with in that time though, were very much the opposite of the move fast breaking things crowd. Intelligent, but also narrow minded I would say.