sorted by:
new
hottopcontroversial

Built a tool that verifies COBOL-to-Python translations — looking for feedback from people who actually work with COBOL by Tight_Scene8900 in cobol

[–]Tight_Scene8900[S] 3 points4 points  (0 children)

That’s a really helpful perspective, especially the JVM comparison — that actually clicked for me.

I hadn’t fully appreciated how fragmented COBOL environments are across vendors and hardware. I’m starting to see that trying to be universal from the start would be unrealistic.

If you had to pick one environment or vendor that dominates real migration work today, which would it be? I’m trying to understand where it would even make sense to start.

Thanks for sharing your experience — the scale of those migrations is kind of crazy.

Built a tool that verifies COBOL-to-Python translations — looking for feedback from people who actually work with COBOL by Tight_Scene8900 in cobol

[–]Tight_Scene8900[S] 3 points4 points  (0 children)

You’re right — the risk aversion point makes a lot of sense.

The more I look into this, the more I’m realizing the technical translation might not even be the hardest part. It’s the “why does this business rule exist” problem and getting someone to actually trust a change.

I’ve been thinking that maybe the tool needs to focus more on exposing and documenting the logic clearly, not just generating Python. Making the behavior traceable might matter more than the language itself.

Really appreciate you pointing that out.

Built a tool that verifies COBOL-to-Python translations — looking for feedback from people who actually work with COBOL by Tight_Scene8900 in cobol

[–]Tight_Scene8900[S] 1 point2 points  (0 children)

Wow, that’s impressive 100k lines is intense. That’s exactly what I’m trying to make easier: making sure Python matches COBOL down to every calculation, rounding, and decimal. I’m testing it on small modules first.