Path: csiph.com!eternal-september.org!feeder.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.os.vms Subject: Re: Semper VMS - Nuclear Mode Date: Mon, 27 Oct 2025 14:05:44 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <10dnu7o$788$1@reader2.panix.com> References: <10dfric$2j5ee$1@dont-email.me> <10dmjj5$e6ef$1@dont-email.me> <10dnh49$1k7$3@reader2.panix.com> <10dnko9$32dsd$1@paganini.bofh.team> Injection-Date: Mon, 27 Oct 2025 14:05:44 -0000 (UTC) Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="7432"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Xref: csiph.com comp.os.vms:377995 In article <10dnko9$32dsd$1@paganini.bofh.team>, Waldek Hebisch wrote: >Dan Cross wrote: >> In article <10dmjj5$e6ef$1@dont-email.me>, >> Dave Froble wrote: >>>On 10/24/2025 2:10 PM, Dan Cross wrote: >>>> In article <10dgc4a$2nvpo$1@dont-email.me>, >>>> Simon Clubley wrote: >>>>> On 2025-10-24, Subcommandante XDelta wrote: >>>>>> Carry on, regardless. >>>>>> >>>>>> Careful with those Dongles, Eugene... >>>>>> >>>>>> How Charon-AXP Saved a Nuclear Power Plant from Shutdown >>>>>> >>>>>> https://www.stromasys.com/wp-content/uploads/2023/06/Tai_Power_vax_case_study_20200622_A4.pdf >>>>> >>>>> The word "VMS" is not mentioned once in that document. >>>>> >>>>> Given the obvious real-time monitoring requirements, how do we know this >>>>> is not some specialised RTOS ? It could also be some other general purpose OS. >>>> >>>> I think that's unlikely. >>>> >>>> My read of this was that the Alpha system was used as the >>>> backend for the data collection pipeline, probably handling >>>> overall management of the monitoring data, and possibly hosting >>>> some analysis. That is, the Alphas are the repository of >>>> whatever information is being generated by realtime monitoring >>>> systems, but not taking that data themselves. >>>> >>>> My guess would be that they are/were running VMS, but who knows? >>> >>>It is amusing the hoops some are attempting to jump thru to declare it isn't >>>VMS, when is sure seems VMS is the most likely environment. >>> >>>:-) >> >> Sure seems that way. There are enough breadcrumbs to follow in >> the document: when they started mentioning IT staff training and >> so on, an RTOS seemed a lot less likely. And if were something >> Unix-y, they could _probably_ port to something else that was >> similarly Unix-y, but, that doc left out a lot of details, so I >> can see why folks want to speculate. > >The document does not consider porting as an alternative. It does; or, rather, it talks about a rewrite, but it says that the cost to would be prohibitively expensive and taken a significant amount of time: NT $100m over two years, plus retraining and documentation costs. >They apparently they wanted to use "the same" system, that >is did not want changes to functionality, so probably there >was some serious obstacle to porting. Most likely, they had >no sources, for example software was developed by an outside >vendor and they only received binaries. Possibly. Or perhaps they were locked onto a single source platform and did not have a good migration path to something more open (note that, when discussing migration to a different platform, the document mentions a "new operation system"). It could also be that there are regulatory issues requiring certification of a new platform, whereas virtualizing it is ok; possibly Stromasys had already checked that box. This is all somewhat reminscent of the Melbourne commuter rail control system thing that was making the rounds a decade or so ago, but on Alpha instead of PDP-11: https://www.webinfo.uk/webdocssl/irse-kbase/PDFreader.aspx?RefNo=1559669757&document=2.10%20Strangaric%20-%20Legacy%20train%20control%20system%20stabilisation.PDF&id=90&PDFC=DP&App=Knowledge%20Base&Title= - Dan C.