4 ms·

That sounds like they wrote a tool to convert assembly into Java.... I don't exactly have high hopes for that. Am I missing something?

happymellon 6y ago
Didn't Micro Focus already do something like this, to allow legacy systems to be retired without needing software rewrites?
redis_mlc 6y ago
Sounds ugly, but if it's important enough and you have somebody who understands all the angles, it could be possible. That excludes 99.999% of government employees, though.
- aj3 6y ago
  It’s not immediately clear what benefits that would bring though besides ticking a box of “technically a modern language”. Automated translation won’t be much more readable than assembly and it won’t magically become enterprise grade OOP either.
  - throwaway744678 6y ago
    I was wondering the same; I guess it would be easier to refactor step by step (renaming functions and variables as you work through the code)
  - redis_mlc 6y ago
    According the the article, they want to move from a local environment using assembler to Java, which apparently gives them a direction for network access, including web.
  - DFHippie 6y ago
    You don't think it's easier to develop in Java than assembly? And setting aside the development experience, it might be easier to hire Java programmers.
  - fork1 6y ago
    From experience, i have seen cobol code stashing entire copybooks into char/varchars, along with some binary switches to select the appropriate copybook. Unless you have the copybook or a translated version, it's pretty much unreadable. In general it's useful if only to interface with those old parts you don't want or can't change.
himinlomax 6y ago
I remember reading about a company writing a Cobol to Java translator to migrate their codebase over 10 years ago. It seems it was very successful. They had focused on making the conversion entirely automatic and reliable, so that they could keep on retranslating new / modified Cobol code during the transition process.
- fork1 6y ago
  We did it to replace a Cobol core-banking system. The hard part is not so much the code as all the interfaces (DB, queues, printing, etc).

happymellon 6y ago

Didn't Micro Focus already do something like this, to allow legacy systems to be retired without needing software rewrites?

redis_mlc 6y ago

Sounds ugly, but if it's important enough and you have somebody who understands all the angles, it could be possible. That excludes 99.999% of government employees, though.

aj3 6y ago
It’s not immediately clear what benefits that would bring though besides ticking a box of “technically a modern language”. Automated translation won’t be much more readable than assembly and it won’t magically become enterprise grade OOP either.
- throwaway744678 6y ago
  I was wondering the same; I guess it would be easier to refactor step by step (renaming functions and variables as you work through the code)
- redis_mlc 6y ago
  According the the article, they want to move from a local environment using assembler to Java, which apparently gives them a direction for network access, including web.
- DFHippie 6y ago
  You don't think it's easier to develop in Java than assembly? And setting aside the development experience, it might be easier to hire Java programmers.
- fork1 6y ago
  From experience, i have seen cobol code stashing entire copybooks into char/varchars, along with some binary switches to select the appropriate copybook. Unless you have the copybook or a translated version, it's pretty much unreadable. In general it's useful if only to interface with those old parts you don't want or can't change.

himinlomax 6y ago

I remember reading about a company writing a Cobol to Java translator to migrate their codebase over 10 years ago. It seems it was very successful. They had focused on making the conversion entirely automatic and reliable, so that they could keep on retranslating new / modified Cobol code during the transition process.

fork1 6y ago
We did it to replace a Cobol core-banking system. The hard part is not so much the code as all the interfaces (DB, queues, printing, etc).