←back to thread

127 points Anon84 | 1 comments | | HN request time: 0.219s | source
Show context
alexwasserman ◴[] No.38510747[source]
Having had to support and migrate COBOL in a big financial the problems weren’t really related to the COBOL, but instead were:

1. The mainframe costs and support. These can be mitigated with migration to a platform like Microfocus to emulate it, but be careful you don’t replace your ultra reliable mainframe with some flakey Windows servers.

2. The embedded business logic. Within the 50-60 years of code there’s a ton a specific edge cases encoded for long forgotten business reasons. These make rewrites really hard as bugs and edge cases have long since become features or behaviors dependent apps are coded to rely on. It takes a ton of extra analysis work to understand what to keep and what to trash.

3. The cobol apps run in a challenging environment that’s also not well understood today. All the jobs in JCL, ISPF to manage things, and a system like CICS for input/output. It’s a huge change beyond just writing code in a regular IDE.

replies(2): >>38511269 #>>38520216 #
1. octokatt ◴[] No.38520216[source]
I worked at an insurance company where a giant COBOL mainframe squatted in the middle of their data systems like a toad*.

During the last major attempt to remove the system, they got close. A team of good engineers worked over two years painstakingly updating documentation, transferring and rebuilding systems, and got to the Go-No-Go meeting. They explained everything to the single SME in their 60's who knew best where the bodies were buried, and she seemed satisfied.

When they got to the end of the Go-No-Go, she asked, "Where did you put our payroll?"

COBOL literally sent everyone their paychecks. It was enough of a deathblow to find something that important had been overlooked, the project was abandoned.

*Oracle Toad was in there too, but it felt snappy instead of squatty compared to the COBOL.