4 ms·

Having worked for 20 years in fintech, I have seen many large European and Asian banks running on COBOL programs written 30 years ago, using EBCDIC. In many cas

by giamma 3y ago

Having worked for 20 years in fintech, I have seen many large European and Asian banks running on COBOL programs written 30 years ago, using EBCDIC. In many cases the sources for some of those programs are lost, due to the fact that proper version control systems did not exist at that time, and nobody dares to re-implement them because they are scared of regressions.

Intermernet 3y ago
Yep, this is true, but I spent years working on AS/400 systems dealing with this exact issue. The thing is that the data isn't stored on a standard file-system. The record definition can be updated, in most situations, without modifying the application code very much at all. This isn't like an app that most people these days have experience with. IBM did everything they could so, if you followed the guidelines when the code was written, it was minimally painful to fix stuff like this in the future. Everyone (including me) loves to give IBM shit, but they do actually know what they're doing when it comes to this stuff. There are many lessons and examples from mid-range and mainframe servers from IBM that are either ignored or re-invented in modern tech.
- giamma 3y ago
  If I remember correctly, in 2010 or so Bank of China was using EBCDIC + a specific codepage by IBM to store successfully Chinese names in COBOL systems. Communication with those systems would happen using IBM MQ Series, a message queue system. The codepage was very specific, it was not part of the standard Java JDK but it was included in the IBM Java JDK.
account-5 3y ago
I think this is a key point. Old tech running perfectly fine; if it ain't broken don't fix it. There's no way to be fully confident that what appears to be a simple update might not break the whole system. And I'd imagine this is likely what the bank is wanting to avoid rather than having to pay programmers to implement the changes. You only have to look as far as TSB for a cautionary tale.
- michh 3y ago
  > Old tech running perfectly fine; if it ain't broken don't fix it. Except it's not running perfectly fine. It's butchering customers' actual real names. That may have been acceptable in the 80s, but it isn't anymore.
  - account-5 3y ago
    [flagged]
    - michh 3y ago
      It would seem you have an axe to grind that goes beyond the issue at hand and I don't think it's worthwhile for me to engage any further with that.
      - account-5 3y ago
        Haha, and yet you did. I've no axe to grind. But I then maybe I'm butchering the situation.
- rsynnott 3y ago
  Frankly, if your bank is scared of updating its software lest it become the next TSB, you should just move _now_; it’ll happen sooner or later.
- iSnow 3y ago
  But it is broken, as it is unable to support frequent European names. There's also the case to be made that if the sources are lost, you need to rewrite from scratch, as you never know when you need to implement new functionality that business deems critical. If you only start the new implementation after business is breathing down your neck, you are in a world of hurt.
eru 3y ago
They might have been written 30 years ago when you started out. Nowadays they have been written 50 years ago. :)
- rbanffy 3y ago
  > Nowadays they have been written 50 years ago. Small nitpick: they have been maintained since 50 years ago. Very few programs written 50 years ago have spent the last 10 years without some sort of patch.
  - eru 3y ago
    Of course. But as noted above that maintenance has been very cautious, because no one wants to unduly disturb the running system. My grandfather made good money in the late 1990s patching up ancient systems for the y2k bug, before his retirement.
tyingq 3y ago
Usually, though, some more modern system is retrieving data from that legacy system. The modern system even probably already maps additional data to the records kept there, so adding real_name would be a known pattern.
perlgeek 3y ago
Imagine this continuing for another 20 or 30 years, holding back our financial institutions even longer. Maybe it's time to force the banks to replace code they cannot maintain.
deleted 3y ago
[deleted]

by giamma 3y ago

Intermernet 3y ago

Yep, this is true, but I spent years working on AS/400 systems dealing with this exact issue. The thing is that the data isn't stored on a standard file-system. The record definition can be updated, in most situations, without modifying the application code very much at all. This isn't like an app that most people these days have experience with. IBM did everything they could so, if you followed the guidelines when the code was written, it was minimally painful to fix stuff like this in the future. Everyone (including me) loves to give IBM shit, but they do actually know what they're doing when it comes to this stuff. There are many lessons and examples from mid-range and mainframe servers from IBM that are either ignored or re-invented in modern tech.

giamma 3y ago
If I remember correctly, in 2010 or so Bank of China was using EBCDIC + a specific codepage by IBM to store successfully Chinese names in COBOL systems. Communication with those systems would happen using IBM MQ Series, a message queue system. The codepage was very specific, it was not part of the standard Java JDK but it was included in the IBM Java JDK.

account-5 3y ago

I think this is a key point. Old tech running perfectly fine; if it ain't broken don't fix it. There's no way to be fully confident that what appears to be a simple update might not break the whole system. And I'd imagine this is likely what the bank is wanting to avoid rather than having to pay programmers to implement the changes. You only have to look as far as TSB for a cautionary tale.

michh 3y ago
> Old tech running perfectly fine; if it ain't broken don't fix it. Except it's not running perfectly fine. It's butchering customers' actual real names. That may have been acceptable in the 80s, but it isn't anymore.
- account-5 3y ago
  [flagged]
  - michh 3y ago
    It would seem you have an axe to grind that goes beyond the issue at hand and I don't think it's worthwhile for me to engage any further with that.
    - account-5 3y ago
      Haha, and yet you did. I've no axe to grind. But I then maybe I'm butchering the situation.
rsynnott 3y ago
Frankly, if your bank is scared of updating its software lest it become the next TSB, you should just move _now_; it’ll happen sooner or later.
iSnow 3y ago
But it is broken, as it is unable to support frequent European names. There's also the case to be made that if the sources are lost, you need to rewrite from scratch, as you never know when you need to implement new functionality that business deems critical. If you only start the new implementation after business is breathing down your neck, you are in a world of hurt.

eru 3y ago

They might have been written 30 years ago when you started out. Nowadays they have been written 50 years ago. :)

rbanffy 3y ago
> Nowadays they have been written 50 years ago. Small nitpick: they have been maintained since 50 years ago. Very few programs written 50 years ago have spent the last 10 years without some sort of patch.
- eru 3y ago
  Of course. But as noted above that maintenance has been very cautious, because no one wants to unduly disturb the running system. My grandfather made good money in the late 1990s patching up ancient systems for the y2k bug, before his retirement.

tyingq 3y ago

Usually, though, some more modern system is retrieving data from that legacy system. The modern system even probably already maps additional data to the records kept there, so adding real_name would be a known pattern.

perlgeek 3y ago

Imagine this continuing for another 20 or 30 years, holding back our financial institutions even longer. Maybe it's time to force the banks to replace code they cannot maintain.

deleted 3y ago

[deleted]