3 ms·

I work at a company that is in the middle of a massive COBOL -> Java migration project. The core transaction processing system has 1.3 million lines of HP3000

by kyllo 12y ago

I work at a company that is in the middle of a massive COBOL -> Java migration project. The core transaction processing system has 1.3 million lines of HP3000 COBOL that is pre-compiled to 13 million lines of Micro Focus COBOL, so that code can be compiled to run on UNIX hardware (using a mainframe emulator framework). So although I'm not a COBOL dev myself, I deal with the issue you describe constantly. Want to give an inventory item an identifier that's longer than 36 characters? Too bad! That field in the legacy system is PIC X(36) so it will get truncated to that length if it's longer (and of course, padded with spaces if it's shorter, so there are lots of String.trim() calls in our Java code).

Ovid 12y ago
Damn it! I totally feel your pain. Migrating COBOL to Java has long been one of my pet peeves. The former is procedural with all variables being global and fixed-width and the later is OO (sort of) with lexical variables of variable size. The two do not mix and match well. Trying to get away from COBOL is actually a three-way problem: technological (as we've alluded to), business (hey, we gotta stop using this shit!), and social (hey, I don't want to touch this shit!). Unfortunately, virtually every solution I've seen focuses on the business or technical issue in isolation, but ignores the others. I've actually found a solution that solves all of the issues and would make new developers excited to work in COBOL shops, but it's on hold until some technical challenges are surmounted. Frustrating as hell!
- kyllo 12y ago
  Right, there's a huge impedance mismatch between COBOL and Java, but couldn't you say the same for any other modern PL? I don't see how migrating COBOL to Python or Clojure or Haskell would be much easier than migrating it to Java. But yes, no one wants to touch the 30 year-old COBOL codebase with a ten foot pole. It's career kryptonite. I'd be curious to learn about the solution you're describing for this problem, is it something you can disclose in any detail?

by kyllo 12y ago

Ovid 12y ago

Damn it! I totally feel your pain. Migrating COBOL to Java has long been one of my pet peeves. The former is procedural with all variables being global and fixed-width and the later is OO (sort of) with lexical variables of variable size. The two do not mix and match well. Trying to get away from COBOL is actually a three-way problem: technological (as we've alluded to), business (hey, we gotta stop using this shit!), and social (hey, I don't want to touch this shit!). Unfortunately, virtually every solution I've seen focuses on the business or technical issue in isolation, but ignores the others. I've actually found a solution that solves all of the issues and would make new developers excited to work in COBOL shops, but it's on hold until some technical challenges are surmounted. Frustrating as hell!

kyllo 12y ago
Right, there's a huge impedance mismatch between COBOL and Java, but couldn't you say the same for any other modern PL? I don't see how migrating COBOL to Python or Clojure or Haskell would be much easier than migrating it to Java. But yes, no one wants to touch the 30 year-old COBOL codebase with a ten foot pole. It's career kryptonite. I'd be curious to learn about the solution you're describing for this problem, is it something you can disclose in any detail?