Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
Newsgroups: comp.os.vms
Subject: Re: Bootcamp
Date: Fri, 11 Jul 2025 20:16:58 -0400
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <104s9hs$1p3b9$1@dont-email.me>
References: <mchom4F15kcU1@mid.individual.net>
 <mckld9Fg08sU1@mid.individual.net> <10465mq$62th$1@dont-email.me>
 <104cgf1$vk0k$1@paganini.bofh.team> <104dri4$11oku$1@paganini.bofh.team>
 <104s1f0$1ndbh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 12 Jul 2025 02:17:00 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="eddbecc7fa4c2c1c40d10e4c19408638";
	logging-data="1871209"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18WkhS7r2DkjPqnFXm9tk8+WhdvjRN16kI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:vb72AaTKyoHJED42jfO/FLt01BM=
In-Reply-To: <104s1f0$1ndbh$1@dont-email.me>
Content-Language: en-US

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