If I may ask: how do you use AI for COBOL to Java migration when the bank forbids internet?
Kazuhiro Yamamoto@yamamoto_kaz
Good evening. I am sorry for my poor English. I am system engineer at an SIer in Osaka and our project is the migration of a regional bank system from COBOL to Java. About 1.8 million lines of COBOL, the oldest parts written in 1987.
Many people on this site and in the news say "just use AI for legacy migration". I would like to try, but I have some conditions:
- The bank does not allow source code to leave the building. No cloud AI service is permitted.
- The design documents are in Excel, with screenshots pasted inside the cells. Some are from the 1990s and do not match the code.
- Our output is reviewed by the customer line by line, and every change needs an approval stamp (hanko) from three managers.
If I may ask one question: has anyone really used AI in this kind of situation? What did it help with, and what did it not help with? A local model running on our own server is maybe possible, but I do not know which tasks are realistic.
Thank you very much for reading.
Accepted answer
Walt here, 30-odd years on mainframes. Honest answer: AI is useful for the part nobody wants to do, and useless for the part that matters.
Useful: explaining a single paragraph of COBOL in plain language, drafting Java for a self-contained calculation, writing test cases from a copybook, summarising what a JCL job does. A local model can do that fine. I tried a small one on an air-gapped box last year.
Not useful: knowing why the interest rounding on line 40,212 is different from the one on line 12,007. That is a business rule from 1994 that somebody's manager decided on a phone call. It is not in the comments and it is not in your Excel. The only way to find it is parallel runs: old system and new system on the same input, compare every output field, every night, for months.
If you take one thing: build the comparison harness first. The AI can help you write it, ironically.
Get the best of #ai_hype_check weekly
One email each Monday with the most useful posts. No spam; unsubscribe in one click.
Comments
Sign in to join the conversation.
Sign in to commentAccepted answer
Walt Hendricks@walt_mainframe
Walt here, 30-odd years on mainframes. Honest answer: AI is useful for the part nobody wants to do, and useless for the part that matters.
Useful: explaining a single paragraph of COBOL in plain language, drafting Java for a self-contained calculation, writing test cases from a copybook, summarising what a JCL job does. A local model can do that fine. I tried a small one on an air-gapped box last year.
Not useful: knowing why the interest rounding on line 40,212 is different from the one on line 12,007. That is a business rule from 1994 that somebody's manager decided on a phone call. It is not in the comments and it is not in your Excel. The only way to find it is parallel runs: old system and new system on the same input, compare every output field, every night, for months.
If you take one thing: build the comparison harness first. The AI can help you write it, ironically.
Kazuhiro Yamamoto@yamamoto_kaz
Thank you very much for your kind and detailed explanation. The rounding is exactly our problem. We already found 4 different rounding methods for the same interest calculation. Parallel run comparison is in our plan, but not budgeted until phase 3. I will propose to move it earlier. (^_^)
Dana Kowalski@dana_ml
To add to Walt's answer from the evaluation side: whatever you use it for, measure it on your code, not on a demo. Take 50 COBOL paragraphs your team has already translated and reviewed, run them through the local model, and have your reviewers grade the output without knowing which is which. You will know in two days whether it saves time on your codebase. My guess is it helps most with explanation and test generation and least with direct translation, but that is a guess, and your 50 paragraphs are the answer.
Kazuhiro Yamamoto@yamamoto_kaz
Thank you very much. Blind grading is a very good idea. In my company the reviewer always knows who wrote the code, so blind review will be new culture. I will explain it as an "experiment".
Graham Whitfield@greybeard_graham
Kazuhiro, I did a smaller version of this in 2004, RPG to Java for an insurer. Walt is right. The code was the easy part; the undocumented behaviour the business depended on was the project. We found one batch job that existed only to correct the output of another batch job. Nobody alive knew why. Be patient, keep a list of every surprise, and never let anyone switch the old system off early.
Cheers, G.
Rodel Bautista@rodel_java
Java dev from Manila, we did a smaller COBOL migration for a cooperative bank. Tip: generate Java that looks a bit like the COBOL at first (same names, same structure). Reviewers who know the COBOL can compare side by side. Pretty Java can come later, after the parallel runs pass. Our customer review went 3x faster once we stopped "improving" things during translation.
Kazuhiro Yamamoto@yamamoto_kaz
This is very practical advice. Our team leader wants "modern clean Java" from the beginning. I will share your experience with him, politely.
Ryan Goh@ai_maxi_ryan
bro just throw the whole codebase into an agent and let it rip. 1.8M lines is like a weekend with the right setup 🚀 the hanko thing is the real bottleneck tbh, automate the approvals
Kazuhiro Yamamoto@yamamoto_kaz
Thank you for your opinion. If I may ask, which agent and which setup did you use for 1.8 million lines without internet? My managers will want to know the product name and the result of the parallel run.
Graham Whitfield@greybeard_graham
'Ship and iterate' on a bank's interest calculation. Remarkable.
Cheers, G.
Walt Hendricks@walt_mainframe
Son, the hanko is the only thing standing between that weekend and a regional bank paying the wrong interest to 400,000 people.