Sujet : Re: Bootcamp
De : arne (at) *nospam* vajhoej.dk (Arne Vajhøj)
Groupes : comp.os.vmsDate : 12. Jul 2025, 01:16:58
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <104s9hs$1p3b9$1@dont-email.me>
References : 1 2 3 4 5 6
User-Agent : Mozilla Thunderbird
On 7/11/2025 5:58 PM, Stephen Hoffman wrote:
On 2025-07-06 12:52:22 +0000, Waldek Hebisch said:
There are no indicatianos of substantial reimplementation. Official info says that new or substantially reworked code is in C. But w also have information that amount of Macro32 and Bliss did not substantially decrease. So, (almost all) old code is still in use.
It could be that small changes to old code took a lot of time. It could be that some new pieces were particularly tricky. However, you should understand that porting really means replicating exisiting behaviour on new hardware. Replicating behaviour gets more tricky if you change more parts and especially if you want to target a high level interface.
You're correct. Reworking existing working code is quite often an immense mistake.
It usually fails. If not always fails.
And bringing a source-to-source translation tooling or an LLM can be helpful, and can also introduce new issues and new bugs.
About the only way a global rewrite can succeed — absent a stratospheric-scale budget for the rewrite, and maybe not even then — is an incremental rewrite, as the specific modules need more than trivial modifications.
Large applications get rewritten all the time.
The failure rate is pretty high, but there are also lots of successes.
Two key factors for success are:
- realistic approach: realistic scope, realistic time frame and
realistic budget
- good team - latest and greatest development methodology can not
make a bad team succeed - people with skills and experience are
needed for big projects
The idea of a 1:1 port is usually bad. Yes - you can implement the
exact same flow of your Cobol application in Java/C++/Go/C#,
but that only solves a language problem not an architecture problem.
You need to re-architect the solution: from ISAM to RDBMS,
from vertical app scaling to horizontal app scaling, from 5x16 to
7x24 operations etc..
And that is the problem with the incremental rewrite - it lean
more to existing architecture than changing architecture. The
strangler pattern is rarely practical to implement.
As an example of a success story Morgan Stanley recently told
that they rewrote 9 million lines of Cobol using a LLM. But smart
people - they did not let the LLM auto-convert the code (that
would likely have resulted in a big mess) - instead they
let the LLM document the code and produce requirements for the
new code.
Reworking a project of the scale of OpenVMS — easily a decade-long freeze — and for little benefit to VSI.
True. It is difficult to see the business case for that.
Arne