Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= 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: <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