• Semper VMS - Nuclear Mode

    From Subcommandante XDelta@vlf@star.enet.dec.com to comp.os.vms on Fri Oct 24 23:31:05 2025
    From Newsgroup: comp.os.vms

    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

    :
    :

    Bare Metal VMS, VSI? - Quo Vadis...
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Fri Oct 24 08:49:36 2025
    From Newsgroup: comp.os.vms

    On 10/24/2025 8:31 AM, Subcommandante XDelta wrote:
    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

    Good story.

    Eventually they would need to migrate from VMS Alpha to VMS x86-64
    though.

    But plenty of runway with VSI supporting VMS Alpha 8.4-2Ln until
    end of 2035.

    The migration to VMS x86-64 may depend on required stuff being
    available. A nuclear power plant is one of those customers that
    could be using Ada.

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Michael S@already5chosen@yahoo.com to comp.os.vms on Fri Oct 24 16:58:21 2025
    From Newsgroup: comp.os.vms

    On Fri, 24 Oct 2025 23:31:05 +1100
    Subcommandante XDelta <vlf@star.enet.dec.com> 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

    :
    :

    Bare Metal VMS, VSI? - Quo Vadis...

    There is a good chance that VSI VMS-x86-64 was not considered as a
    candidate for replacement of original system because original system was
    not running on VMS.
    Although even more likely scenario is that it was running on VMS, but
    source code and/or build process directives of application software
    were lost.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Fri Oct 24 09:07:30 2025
    From Newsgroup: comp.os.vms

    On 10/24/2025 9:58 AM, Michael S wrote:
    On Fri, 24 Oct 2025 23:31:05 +1100
    Subcommandante XDelta <vlf@star.enet.dec.com> wrote:
    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

    There is a good chance that VSI VMS-x86-64 was not considered as a
    candidate for replacement of original system because original system was
    not running on VMS.
    Although even more likely scenario is that it was running on VMS, but
    source code and/or build process directives of application software
    were lost.

    A more simple explanation is timing.

    VMS x86-64 9.2 became available in 2022.

    The document seems to be uploaded in 2023, but the PDF name indicate
    that it could have been written in 2020.

    From decision is made until successful go live that a vendor
    may want to use as a success story there may easily go 2 years
    even for a such a relative simple migration.

    I don't think VMS x86-64 was available or close to being available
    for production, when they had to make the decision.

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From bill@bill.gunshannon@gmail.com to comp.os.vms on Fri Oct 24 10:45:18 2025
    From Newsgroup: comp.os.vms

    On 10/24/2025 8:49 AM, Arne Vajh|+j wrote:
    On 10/24/2025 8:31 AM, Subcommandante XDelta wrote:
    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

    Good story.

    Eventually they would need to migrate from VMS Alpha to VMS x86-64
    though.

    But plenty of runway with VSI supporting VMS Alpha 8.4-2Ln until
    end of 2035.

    The migration to VMS x86-64 may depend on required stuff being
    available. A nuclear power plant is one of those customers that
    could be using Ada.


    Last I heard some of them are still using PDP-11's. I think that
    rules out Ada. :-)

    bill


    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Simon Clubley@clubley@remove_me.eisner.decus.org-Earth.UFP to comp.os.vms on Fri Oct 24 17:13:46 2025
    From Newsgroup: comp.os.vms

    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    Simon.
    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Simon Clubley@clubley@remove_me.eisner.decus.org-Earth.UFP to comp.os.vms on Fri Oct 24 17:16:33 2025
    From Newsgroup: comp.os.vms

    On 2025-10-24, bill <bill.gunshannon@gmail.com> wrote:
    On 10/24/2025 8:49 AM, Arne Vajhoj wrote:
    On 10/24/2025 8:31 AM, Subcommandante XDelta wrote:
    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

    Good story.

    Eventually they would need to migrate from VMS Alpha to VMS x86-64
    though.

    But plenty of runway with VSI supporting VMS Alpha 8.4-2Ln until
    end of 2035.

    The migration to VMS x86-64 may depend on required stuff being
    available. A nuclear power plant is one of those customers that
    could be using Ada.


    Last I heard some of them are still using PDP-11's. I think that
    rules out Ada. :-)


    Huh ? Just because a few systems can't run Ada code, it doesn't mean
    other systems are not using it.

    Simon.
    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Simon Clubley@clubley@remove_me.eisner.decus.org-Earth.UFP to comp.os.vms on Fri Oct 24 17:30:25 2025
    From Newsgroup: comp.os.vms

    On 2025-10-24, Arne Vajhoj <arne@vajhoej.dk> wrote:
    On 10/24/2025 8:31 AM, Subcommandante XDelta wrote:
    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

    Good story.

    Eventually they would need to migrate from VMS Alpha to VMS x86-64
    though.


    Are you seeing something I am not ? There's no mention of VMS in
    that document.

    But plenty of runway with VSI supporting VMS Alpha 8.4-2Ln until
    end of 2035.

    The migration to VMS x86-64 may depend on required stuff being
    available. A nuclear power plant is one of those customers that
    could be using Ada.


    Elsewhere, in some other company, clueless management could say:
    "Just vibe code a solution". :-)

    Obviously these people did the right and expected thing, and you would
    hope all safety-critical people would, but I can't believe in general
    how elsewhere "vibe coding" could actually be a thing instead of getting
    you fired for not doing your job properly.

    Simon.
    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Fri Oct 24 13:34:39 2025
    From Newsgroup: comp.os.vms

    On 10/24/2025 1:13 PM, Simon Clubley wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    We don't know for sure.

    But what OS are supported on Alpha today besides VMS?

    Tru64 went out of support in 2012.

    And it seems like a case where support does matter.

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Fri Oct 24 13:42:36 2025
    From Newsgroup: comp.os.vms

    On 10/24/2025 1:30 PM, Simon Clubley wrote:
    On 2025-10-24, Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/24/2025 8:31 AM, Subcommandante XDelta wrote:
    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

    Good story.

    Eventually they would need to migrate from VMS Alpha to VMS x86-64
    though.

    Are you seeing something I am not ? There's no mention of VMS in
    that document.

    True.

    But what other OS are still supporting Alpha? Not Tru64. Not WinNT.

    And which other OS on Charon are supported by Stromasys?

    Probability of being VMS is high.

    But plenty of runway with VSI supporting VMS Alpha 8.4-2Ln until
    end of 2035.

    The migration to VMS x86-64 may depend on required stuff being
    available. A nuclear power plant is one of those customers that
    could be using Ada.

    Elsewhere, in some other company, clueless management could say:
    "Just vibe code a solution". :-)

    Obviously these people did the right and expected thing, and you would
    hope all safety-critical people would, but I can't believe in general
    how elsewhere "vibe coding" could actually be a thing instead of getting
    you fired for not doing your job properly.

    My impression is that vibe coding is not really a thing in
    companies for doing IT, but mostly a thing for companies
    wanting to sell software/training/AI access to other companies.

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Chris Townley@news@cct-net.co.uk to comp.os.vms on Fri Oct 24 18:46:16 2025
    From Newsgroup: comp.os.vms

    On 24/10/2025 18:34, Arne Vajh|+j wrote:
    On 10/24/2025 1:13 PM, Simon Clubley wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    We don't know for sure.

    But what OS are supported on Alpha today besides VMS?

    Tru64 went out of support in 2012.

    And it seems like a case where support does matter.

    Arne

    Even NetBSD dropped Alpha support quite a while back
    --
    Chris
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Fri Oct 24 13:51:29 2025
    From Newsgroup: comp.os.vms

    On 10/24/2025 1:46 PM, Chris Townley wrote:
    On 24/10/2025 18:34, Arne Vajh|+j wrote:
    On 10/24/2025 1:13 PM, Simon Clubley wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    We don't know for sure.

    But what OS are supported on Alpha today besides VMS?

    Tru64 went out of support in 2012.

    And it seems like a case where support does matter.

    Even NetBSD dropped Alpha support quite a while back

    Linux kernel still has support for Alpha (at least for newer
    Alpha's) I believe.

    But that does not matter. Redhat, SUSE, Canonical etc.
    dropped support a long time ago.

    Arne



    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Fri Oct 24 18:10:38 2025
    From Newsgroup: comp.os.vms

    In article <10dgc4a$2nvpo$1@dont-email.me>,
    Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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?

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Fri Oct 24 18:18:04 2025
    From Newsgroup: comp.os.vms

    In article <10dge18$2ok59$1@dont-email.me>,
    Chris Townley <news@cct-net.co.uk> wrote:
    On 24/10/2025 18:34, Arne Vajh|+j wrote:
    On 10/24/2025 1:13 PM, Simon Clubley wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    We don't know for sure.

    But what OS are supported on Alpha today besides VMS?

    Tru64 went out of support in 2012.

    And it seems like a case where support does matter.

    Even NetBSD dropped Alpha support quite a while back

    Oh no. Troll is going to come in crowing about how Linux still
    supports Alpha. So does OpenBSD, though. I wonder when FreeBSD
    dropped it.

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From jgd@jgd@cix.co.uk (John Dallman) to comp.os.vms on Fri Oct 24 21:02:40 2025
    From Newsgroup: comp.os.vms

    In article <10dgdqc$2n2kl$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhoj) wrote:

    My impression is that vibe coding is not really a thing in
    companies for doing IT, but mostly a thing for companies
    wanting to sell software/training/AI access to other companies.

    It's also popular among people who are trying to become "IT experts" via
    social media postings, without any actual computer skills.

    John
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.os.vms on Fri Oct 24 20:53:11 2025
    From Newsgroup: comp.os.vms

    On Fri, 24 Oct 2025 23:31:05 +1100, Subcommandante XDelta wrote:

    Carry on, regardless.

    That was one of the more amusing ones, I felt <https://www.imdb.com/title/tt0054727/>.

    I remember Kenneth Connor and the complete misunderstanding over the
    cryptic phone call from the Fat Man ... and the resulting wild-goose chase
    on the train to Scotland ...
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.os.vms on Fri Oct 24 20:59:30 2025
    From Newsgroup: comp.os.vms

    On Fri, 24 Oct 2025 16:58:21 +0300, Michael S wrote:

    Although even more likely scenario is that it was running on VMS, but
    source code and/or build process directives of application software were lost.

    If thatrCOs typical of the software quality control in the nuclear power-
    plant industry ...
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.os.vms on Fri Oct 24 21:02:06 2025
    From Newsgroup: comp.os.vms

    On Fri, 24 Oct 2025 09:07:30 -0400, Arne Vajh|+j wrote:

    The document seems to be uploaded in 2023, but the PDF name indicate
    that it could have been written in 2020.

    acrid <https://gitlab.com/ldo/acrid> reports:

    "/CreationDate": "D:20200622092448-04'00'",
    "/Title": "Tai-Power-vax-case study-20200622-A4",
    "/Trapped": "/False",
    "/Producer": "Adobe PDF library 15.00",
    "/Creator": "Adobe Illustrator 24.1 (Macintosh)",
    "/ModDate": "D:20200622092448-04'00'",

    It also has XMP metadata, but I wonrCOt bore you with that ...
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.os.vms on Fri Oct 24 21:05:46 2025
    From Newsgroup: comp.os.vms

    On Fri, 24 Oct 2025 13:51:29 -0400, Arne Vajh|+j wrote:

    Linux kernel still has support for Alpha (at least for newer Alpha's) I believe.

    While it does, the article mentioned moving to an rCLemulatorrCY.

    <https://packages.debian.org/trixie/qemu-system-misc>
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From bill@bill.gunshannon@gmail.com to comp.os.vms on Fri Oct 24 21:35:30 2025
    From Newsgroup: comp.os.vms

    On 10/24/2025 1:34 PM, Arne Vajh|+j wrote:
    On 10/24/2025 1:13 PM, Simon Clubley wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    We don't know for sure.

    But what OS are supported on Alpha today besides VMS?

    Tru64 went out of support in 2012.

    And it seems like a case where support does matter.


    The last mention of the PDP-11 in this kind of work was looking
    for people with MACRO-11 experience. It would not surprise me
    to find out that no commercial OS is involved (possible no OS at
    all, just running an application on bare metal), A VAX in the
    same environment could do the same.

    bill


    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From bill@bill.gunshannon@gmail.com to comp.os.vms on Fri Oct 24 21:38:31 2025
    From Newsgroup: comp.os.vms

    On 10/24/2025 2:10 PM, Dan Cross wrote:
    In article <10dgc4a$2nvpo$1@dont-email.me>,
    Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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?


    Hmmm. Maybe it's a backend for a PDP-11 frontend? :-)

    bill


    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Johnny Billquist@bqt@softjar.se to comp.os.vms on Sun Oct 26 11:40:22 2025
    From Newsgroup: comp.os.vms

    On 2025-10-24 19:46, Chris Townley wrote:
    On 24/10/2025 18:34, Arne Vajh|+j wrote:

    We don't know for sure.

    But what OS are supported on Alpha today besides VMS?

    Tru64 went out of support in 2012.

    And it seems like a case where support does matter.

    Arne

    Even NetBSD dropped Alpha support quite a while back

    Say what? When did NetBSD stopped supporting Alpha? It's still listed on
    the webpage, along with VAX (gee, anyone heard of that architecture?).

    Yes, Alpha is no longer "Tier 1" at NetBSD, but that is not the same as "dropped support".

    https://wiki.netbsd.org/ports/

    Johnny

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Johnny Billquist@bqt@softjar.se to comp.os.vms on Sun Oct 26 11:42:00 2025
    From Newsgroup: comp.os.vms

    On 2025-10-25 03:35, bill wrote:
    On 10/24/2025 1:34 PM, Arne Vajh|+j wrote:
    On 10/24/2025 1:13 PM, Simon Clubley wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    We don't know for sure.

    But what OS are supported on Alpha today besides VMS?

    Tru64 went out of support in 2012.

    And it seems like a case where support does matter.


    The last mention of the PDP-11 in this kind of work was looking
    for people with MACRO-11 experience.-a It would not surprise me
    to find out that no commercial OS is involved (possible no OS at
    all, just running an application on bare metal),-a A VAX in the
    same environment could do the same.

    You need some PDP-11 OS running in order to use Macro-11. And unless I remember wrong, at least Ontario Hydroelectric was/is running RSX.

    Johnny

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From bill@bill.gunshannon@gmail.com to comp.os.vms on Sun Oct 26 08:35:39 2025
    From Newsgroup: comp.os.vms

    On 10/26/2025 6:42 AM, Johnny Billquist wrote:
    On 2025-10-25 03:35, bill wrote:
    On 10/24/2025 1:34 PM, Arne Vajh|+j wrote:
    On 10/24/2025 1:13 PM, Simon Clubley wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    We don't know for sure.

    But what OS are supported on Alpha today besides VMS?

    Tru64 went out of support in 2012.

    And it seems like a case where support does matter.


    The last mention of the PDP-11 in this kind of work was looking
    for people with MACRO-11 experience.-a It would not surprise me
    to find out that no commercial OS is involved (possible no OS at
    all, just running an application on bare metal),-a A VAX in the
    same environment could do the same.

    You need some PDP-11 OS running in order to use Macro-11. And unless I remember wrong, at least Ontario Hydroelectric was/is running RSX.


    To do the development maybe. But one can create programs in Macro-11
    that run all by themselves on bare iron. Fig Forth?

    bill


    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Sun Oct 26 10:55:48 2025
    From Newsgroup: comp.os.vms

    On 10/26/2025 8:35 AM, bill wrote:
    On 10/26/2025 6:42 AM, Johnny Billquist wrote:
    On 2025-10-25 03:35, bill wrote:
    On 10/24/2025 1:34 PM, Arne Vajh|+j wrote:
    And it seems like a case where support does matter.

    The last mention of the PDP-11 in this kind of work was looking
    for people with MACRO-11 experience.-a It would not surprise me
    to find out that no commercial OS is involved (possible no OS at
    all, just running an application on bare metal),-a A VAX in the
    same environment could do the same.

    You need some PDP-11 OS running in order to use Macro-11. And unless I
    remember wrong, at least Ontario Hydroelectric was/is running RSX.

    To do the development maybe.-a But one can create programs in Macro-11
    that run all by themselves on bare iron.-a Fig Forth?

    Like VAXELN?

    Arne


    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Alexander Schreiber@als@usenet.thangorodrim.de to comp.os.vms on Sun Oct 26 15:36:11 2025
    From Newsgroup: comp.os.vms

    Johnny Billquist <bqt@softjar.se> wrote:
    On 2025-10-24 19:46, Chris Townley wrote:
    On 24/10/2025 18:34, Arne Vajh|+j wrote:

    We don't know for sure.

    But what OS are supported on Alpha today besides VMS?

    Tru64 went out of support in 2012.

    And it seems like a case where support does matter.

    Arne

    Even NetBSD dropped Alpha support quite a while back

    Say what? When did NetBSD stopped supporting Alpha? It's still listed on
    the webpage, along with VAX (gee, anyone heard of that architecture?).

    Hey, some of us are in fact running NetBSD/vax, albeit in SIMH due to
    lack of (or rather: lack of space and power budget for) real hardware.

    Yes, Alpha is no longer "Tier 1" at NetBSD, but that is not the same as "dropped support".

    https://wiki.netbsd.org/ports/

    Works Just Finerao, can confirm. Although some software tends to go
    "What the [censored] is this?" when it encounters VAX floating point ;-)

    Kind regards,
    Alex.
    --
    "Opportunity is missed by most people because it is dressed in overalls and
    looks like work." -- Thomas A. Edison
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Michael S@already5chosen@yahoo.com to comp.os.vms on Sun Oct 26 17:37:07 2025
    From Newsgroup: comp.os.vms

    On Fri, 24 Oct 2025 09:07:30 -0400
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/24/2025 9:58 AM, Michael S wrote:
    On Fri, 24 Oct 2025 23:31:05 +1100
    Subcommandante XDelta <vlf@star.enet.dec.com> wrote:
    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


    There is a good chance that VSI VMS-x86-64 was not considered as a candidate for replacement of original system because original
    system was not running on VMS.
    Although even more likely scenario is that it was running on VMS,
    but source code and/or build process directives of application
    software were lost.

    A more simple explanation is timing.

    VMS x86-64 9.2 became available in 2022.

    The document seems to be uploaded in 2023, but the PDF name indicate
    that it could have been written in 2020.

    The name of PDF suggests that VAX computers were involved. The content
    suggests otherwise. The whole article has a heavy smell of marketing. I
    would not be surprised that all technical details are wrong.
    The only thing I am sure of is that Stromasys was paid.
    From decision is made until successful go live that a vendor
    may want to use as a success story there may easily go 2 years
    even for a such a relative simple migration.

    I don't think VMS x86-64 was available or close to being available
    for production, when they had to make the decision.

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From drb@drb@ihatespam.msu.edu (Dennis Boone) to comp.os.vms on Sun Oct 26 15:56:16 2025
    From Newsgroup: comp.os.vms

    My impression is that vibe coding is not really a thing in
    companies for doing IT, but mostly a thing for companies
    wanting to sell software/training/AI access to other companies.

    A friend who works in IT at a bank has a boss who is all in on
    vibe coding. *visceral response*

    De
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Sun Oct 26 17:44:14 2025
    From Newsgroup: comp.os.vms

    On 10/24/2025 1:34 PM, Arne Vajh|+j wrote:
    On 10/24/2025 1:13 PM, Simon Clubley wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    We don't know for sure.

    But what OS are supported on Alpha today besides VMS?

    Tru64 went out of support in 2012.

    And it seems like a case where support does matter.

    Did a little googling.

    It seems that the last version of VxWorks to support Alpha
    was 5.5 released 2002 and EOL 2018.

    That was what the net said. I don't know much about VxWorks.
    I did not even know that they had supported Alpha.

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Dave Froble@davef@tsoft-inc.com to comp.os.vms on Sun Oct 26 20:45:35 2025
    From Newsgroup: comp.os.vms

    On 10/24/2025 8:49 AM, Arne Vajh|+j wrote:
    On 10/24/2025 8:31 AM, Subcommandante XDelta wrote:
    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


    Good story.

    Eventually they would need to migrate from VMS Alpha to VMS x86-64
    though.

    But plenty of runway with VSI supporting VMS Alpha 8.4-2Ln until
    end of 2035.

    The migration to VMS x86-64 may depend on required stuff being
    available. A nuclear power plant is one of those customers that
    could be using Ada.

    Arne



    Or, could be using Basic ...

    :-)
    --
    David Froble Tel: 724-529-0450
    Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
    DFE Ultralights, Inc.
    170 Grimplin Road
    Vanderbilt, PA 15486
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From bill@bill.gunshannon@gmail.com to comp.os.vms on Sun Oct 26 21:56:55 2025
    From Newsgroup: comp.os.vms

    On 10/26/2025 10:55 AM, Arne Vajh|+j wrote:
    On 10/26/2025 8:35 AM, bill wrote:
    On 10/26/2025 6:42 AM, Johnny Billquist wrote:
    On 2025-10-25 03:35, bill wrote:
    On 10/24/2025 1:34 PM, Arne Vajh|+j wrote:
    And it seems like a case where support does matter.

    The last mention of the PDP-11 in this kind of work was looking
    for people with MACRO-11 experience.-a It would not surprise me
    to find out that no commercial OS is involved (possible no OS at
    all, just running an application on bare metal),-a A VAX in the
    same environment could do the same.

    You need some PDP-11 OS running in order to use Macro-11. And unless
    I remember wrong, at least Ontario Hydroelectric was/is running RSX.

    To do the development maybe.-a But one can create programs in Macro-11
    that run all by themselves on bare iron.-a Fig Forth?

    Like VAXELN?


    I doubt VAXELN will run MACRO-11 or that it will run on a PDP-11.

    bill


    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Dave Froble@davef@tsoft-inc.com to comp.os.vms on Sun Oct 26 21:57:15 2025
    From Newsgroup: comp.os.vms

    On 10/24/2025 2:10 PM, Dan Cross wrote:
    In article <10dgc4a$2nvpo$1@dont-email.me>,
    Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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?

    - Dan C.


    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.

    :-)
    --
    David Froble Tel: 724-529-0450
    Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
    DFE Ultralights, Inc.
    170 Grimplin Road
    Vanderbilt, PA 15486
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Sun Oct 26 22:09:13 2025
    From Newsgroup: comp.os.vms

    On 10/26/2025 9:56 PM, bill wrote:
    On 10/26/2025 10:55 AM, Arne Vajh|+j wrote:
    On 10/26/2025 8:35 AM, bill wrote:
    On 10/26/2025 6:42 AM, Johnny Billquist wrote:
    On 2025-10-25 03:35, bill wrote:
    On 10/24/2025 1:34 PM, Arne Vajh|+j wrote:
    And it seems like a case where support does matter.

    The last mention of the PDP-11 in this kind of work was looking
    for people with MACRO-11 experience.-a It would not surprise me
    to find out that no commercial OS is involved (possible no OS at
    all, just running an application on bare metal),-a A VAX in the
    same environment could do the same.

    You need some PDP-11 OS running in order to use Macro-11. And unless
    I remember wrong, at least Ontario Hydroelectric was/is running RSX.

    To do the development maybe.-a But one can create programs in Macro-11
    that run all by themselves on bare iron.-a Fig Forth?

    Like VAXELN?

    I doubt VAXELN will run MACRO-11 or that it will run on a PDP-11.

    Of course not.

    But it sounds like the same deployment model.

    My understanding about VAXELN (based on what I have been told - no
    personal experience) is that you link the OS into the application
    and deploy the application (with embedded OS) directly on
    the VAX.

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Mon Oct 27 10:16:08 2025
    From Newsgroup: comp.os.vms

    In article <10dmk89$bj46$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/26/2025 9:56 PM, bill wrote:
    On 10/26/2025 10:55 AM, Arne Vajh|+j wrote:
    On 10/26/2025 8:35 AM, bill wrote:
    On 10/26/2025 6:42 AM, Johnny Billquist wrote:
    On 2025-10-25 03:35, bill wrote:
    On 10/24/2025 1:34 PM, Arne Vajh|+j wrote:
    And it seems like a case where support does matter.

    The last mention of the PDP-11 in this kind of work was looking
    for people with MACRO-11 experience.-a It would not surprise me
    to find out that no commercial OS is involved (possible no OS at
    all, just running an application on bare metal),-a A VAX in the
    same environment could do the same.

    You need some PDP-11 OS running in order to use Macro-11. And unless >>>>> I remember wrong, at least Ontario Hydroelectric was/is running RSX.

    To do the development maybe.-a But one can create programs in Macro-11 >>>> that run all by themselves on bare iron.-a Fig Forth?

    Like VAXELN?

    I doubt VAXELN will run MACRO-11 or that it will run on a PDP-11.

    Of course not.

    But it sounds like the same deployment model.

    My understanding about VAXELN (based on what I have been told - no
    personal experience) is that you link the OS into the application
    and deploy the application (with embedded OS) directly on
    the VAX.

    VAXELN is closer to VxWorks than to what Bill described. You
    do development on a computer running a general purpose OS, and
    link against their libraries and so on to generate an image you
    load onto the target machine, but the environment provides a
    small executive to handle task switching, event management, and
    so forth.

    I interpreted what Bill wrote as more like treating a PDP-11 as
    a glorified microcontroller: perhaps there's a very small boot
    loader in firmware, but after that, you're on your own; any
    support for multiple tasks that your application has is
    something that you provided; more generally, whatever
    abstractions you use are ones you provided yourself. You're
    writing your own interrupt handlers, and so.

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Mon Oct 27 10:17:49 2025
    From Newsgroup: comp.os.vms

    In article <68fe962e$0$666$14726298@news.sunsite.dk>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/24/2025 1:34 PM, Arne Vajh|+j wrote:
    On 10/24/2025 1:13 PM, Simon Clubley wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    We don't know for sure.

    But what OS are supported on Alpha today besides VMS?

    Tru64 went out of support in 2012.

    And it seems like a case where support does matter.

    Did a little googling.

    It seems that the last version of VxWorks to support Alpha
    was 5.5 released 2002 and EOL 2018.

    That was what the net said. I don't know much about VxWorks.
    I did not even know that they had supported Alpha.

    VAXELN was not ported to Alpha; instead, DEC partnered with Wind
    River to do a port of VxWorks to Alpha, and provided a VAXELN
    compatibility library to assist porting.

    Still, I doubt that's what these folks in Taiwan were using.

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Mon Oct 27 10:22:01 2025
    From Newsgroup: comp.os.vms

    In article <10dmjj5$e6ef$1@dont-email.me>,
    Dave Froble <davef@tsoft-inc.com> wrote:
    On 10/24/2025 2:10 PM, Dan Cross wrote:
    In article <10dgc4a$2nvpo$1@dont-email.me>,
    Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From antispam@antispam@fricas.org (Waldek Hebisch) to comp.os.vms on Mon Oct 27 11:23:55 2025
    From Newsgroup: comp.os.vms

    Dan Cross <cross@spitfire.i.gajendra.net> wrote:
    In article <10dmjj5$e6ef$1@dont-email.me>,
    Dave Froble <davef@tsoft-inc.com> wrote:
    On 10/24/2025 2:10 PM, Dan Cross wrote:
    In article <10dgc4a$2nvpo$1@dont-email.me>,
    Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.
    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.
    --
    Waldek Hebisch
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Mon Oct 27 14:05:44 2025
    From Newsgroup: comp.os.vms

    In article <10dnko9$32dsd$1@paganini.bofh.team>,
    Waldek Hebisch <antispam@fricas.org> wrote:
    Dan Cross <cross@spitfire.i.gajendra.net> wrote:
    In article <10dmjj5$e6ef$1@dont-email.me>,
    Dave Froble <davef@tsoft-inc.com> wrote:
    On 10/24/2025 2:10 PM, Dan Cross wrote:
    In article <10dgc4a$2nvpo$1@dont-email.me>,
    Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
    On 2025-10-24, Subcommandante XDelta <vlf@star.enet.dec.com> 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.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From jayjwa@jayjwa@atr2.ath.cx.invalid to comp.os.vms on Mon Oct 27 15:55:28 2025
    From Newsgroup: comp.os.vms

    Arne Vajh|+j <arne@vajhoej.dk> writes:

    I doubt VAXELN will run MACRO-11 or that it will run on a PDP-11.
    This is what the ICP claims to support:

    Do you want to build an ICP for an rtVAX 1000 or MicroVAX I, II, 3200,
    3300, 3400, 35NN, 36NN, 3800, 3900, 4000 [NO] ? yes
    Do you want to build an ICP for MicroVAX 3100 Model 30,40,80 [NO] ?
    Do you want to build an ICP for MicroVAX 2000, MicroVAX 3100 [NO] ?
    Do you want to build an ICP for KAV30 [NO] ?
    Do you want to build an ICP for 6000-2NN, 6000-3NN [NO] ?
    Do you want to build an ICP for 6000-4NN [NO] ?
    Do you want to build an ICP for 6000-5NN [NO] ?
    Do you want to build an ICP for 6000-6NN [NO] ?
    Do you want to build an ICP for 9000 [NO] ?
    Do you want to build an ICP for VAXstation II/GPX, VAXstation 3200 [NO] ?
    Do you want to build an ICP for VAXstation II [NO] ?
    Do you want to build an ICP for GPX VAXstation 2000, VAXstation 3100 [NO] ?
    Do you want to build an ICP for monochrome VAXstation 2000, VAXstation 3100 [NO] ?
    Do you want to build an ICP for SPX VAXstation 3100 [NO] ?
    Do you want to build an ICP for VAXstation 4000 Model 60,VLC [NO] ?

    My understanding about VAXELN (based on what I have been told - no
    personal experience) is that you link the OS into the application
    and deploy the application (with embedded OS) directly on
    the VAX.
    It's an SDK but no one calls it that. It would be much easier to
    understand if they did. One creates an application in C or Pascal. Then
    you compile/link it with ELN libraries. Maybe it supports other
    languages but the docs mention C and Pascal.

    $ cc program.c + ELN$:VAXELNC/LIB
    $ link program.obj + ELN$:RTLSHARE/LIB + RTL/LIB
    Then a .SYS gets create with ebuild.
    $ ebuild program

    This .SYS is then downline loaded on a supported system from the VMS
    node ELN is on.

    $ copy SAMPLE.SYS SYS$COMMON:[MOM$SYSTEM]
    $ dir SYS$COMMON:[MOM$SYSTEM]

    Directory SYS$COMMON:[MOM$SYSTEM]

    READ_ADDR.SYS;10 SAMPLE.SYS;5

    Total of 2 files.

    Set the node to load this file on the target. SIMH has an rtvax1000 that
    will work. Note that it is diskless and boots off the network.

    $ ncp set node 1.16 load file SAMPLE.SYS

    $ ncp show node 1.16 char
    Node Volatile Characteristics as of 18-DEC-2023 20:35:21
    Remote node = 1.16
    Service circuit = QNA-0
    Hardware address = AA-00-04-00-10-04
    Load file = SAMPLE.SYS

    ...
    set xq mac=aa:00:04:00:10:04
    set xq ena
    att xq tap:tap6
    boot cpu

    rtVAX1000 (KA620) simulator V4.0-0 Current git commit id: f4f30298 Logging to file "/opt/simulations/rtvax1000/install_rtvax1000.log" ./rtvax1000.ini-66> att xq tap:tap6
    %SIM-INFO: Eth: opened OS device tap6
    ./rtvax1000.ini-70> boot cpu
    %SIM-INFO: Loading boot code from internal ka620.bin

    KA620-A.V1.1

    Performing normal system tests.

    5..4..3..

    Tests completed.


    boot xqa0

    2..1..0..



    %VAXELN system initializing

    VAXELN V4.6 QBUS


    Hello!

    From the host side (one year is wrong for some reason):

    $
    %%%%%%%%%%% OPCOM 18-DEC-2023 20:35:32.35 %%%%%%%%%%%
    Message from user DECNET on KUSHAL
    DECnet event 0.3, automatic line service
    From node 1.12 (KUSHAL), 1-JAN-2041 00:00:00.00
    Circuit QNA-0, Load, Requested, Node = 1.16, File = SAMPLE.SYS
    Operating system, Ethernet address = AA-00-04-00-10-04

    $
    %%%%%%%%%%% OPCOM 18-DEC-2023 20:35:37.33 %%%%%%%%%%%
    Message from user DECNET on KUSHAL
    DECnet event 0.3, automatic line service
    From node 1.12 (KUSHAL), 1-JAN-2041 00:00:00.00
    Circuit QNA-0, Load, Successful, Node = 1.16, File = SAMPLE.SYS
    Operating system, Ethernet address = AA-00-04-00-10-04
    --
    PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
    "The Internet should always be the Wild West!"
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Rich Alderson@news@alderson.users.panix.com to comp.os.vms on Mon Oct 27 18:06:07 2025
    From Newsgroup: comp.os.vms

    cross@spitfire.i.gajendra.net (Dan Cross) writes:

    [ snip snip snip ]

    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.

    Back in the 1990s (so probably cool to talk about), Lockheed-Martin Data Services
    was responsible (under government contract) for keeping track of all the plutonium
    that had ever been produced. They did this on a group of 14 DECsystem-10s (KL-10 based), 12 redundant and 2 hot spares.

    They approached my then PoE, where one of the hats I wore was pre- and post-sales
    customer support, informally before issuing an RPQ. We only supported TOPS-20 on
    our expanded clone platform, but for that large a sale we were willing to do the
    port of Tops-10.

    The reason they approached us was that we produced real, honest to $DEITY, hardware
    rather than an emulator (which DEC was offering at the time, running on an Alpha
    under VMS). (If they chose the emulator, or ported their database system to a different architecture, an audit would be triggered of all the plutonium storage
    facilities overseen by DoE/DoD, which no one wanted to have happen for reasons.)
    Because our hardware qualified as a drop-in replacement, no audit trigger arose.

    We did the port of Tops-10 in short order, based on a previous request that had gone away in favor of TOPS-20 before completion, and I contacted the gent with whom I had been in contact about getting that RPQ generated, only to be told that
    their entire program had been defunded in the new budget being passed at that moment in DC.

    Sic transit gloria mundi. (Gloria threw up in the bus on Monday.)

    I suspect that the VMS system under discussion is this thread is in similar straits.
    --
    Rich Alderson news@alderson.users.panix.com
    Audendum est, et veritas investiganda; quam etiamsi non assequamur,
    omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
    --Galen --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Mon Oct 27 19:37:07 2025
    From Newsgroup: comp.os.vms

    On 10/27/2025 7:23 AM, Waldek Hebisch wrote:
    The document does not consider porting as an alternative.
    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.

    They can also have had sources but the compiler was not
    available on VMS Itanium. Ada, PL/I etc.. Ada sounds
    more likely than PL/I to me given the domain.

    But given the timing, then porting may not have
    been attractive even if they could port.

    If this project was done in 2020, then options
    (assuming that they wanted to stay on VMS) were:
    * stay on VMS Alpha and move to Alpha emulators, which
    both had long term support
    * migrate to VMS Itanium, but facing the problem
    that Itanium was officially dead (no new HW and no
    emulators) and HPE would soon end HW support
    * wait years for VSI to get VMS x86-64 product ready,
    while existing HW started to fail

    Easy choice.

    But they just need to realize that eventually VMS Alpha
    will come to an end. That means another migration project
    (with associated costs) before 2035. But in 2020 then VMS Alpha
    may have been the only viable choice.

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Tue Oct 28 12:58:56 2025
    From Newsgroup: comp.os.vms

    In article <873474p1an.fsf@atr2.ath.cx>,
    jayjwa <jayjwa@atr2.ath.cx.invalid> wrote:
    Arne Vajh|+j <arne@vajhoej.dk> writes:
    [snip]
    My understanding about VAXELN (based on what I have been told - no
    personal experience) is that you link the OS into the application
    and deploy the application (with embedded OS) directly on
    the VAX.

    It's an SDK but no one calls it that. It would be much easier to
    understand if they did. One creates an application in C or Pascal. Then
    you compile/link it with ELN libraries. Maybe it supports other
    languages but the docs mention C and Pascal.

    According to the VAXELN Technical Summary, it also contains a
    runtime component that includes the kernel, which manages tasks
    and provides synchronization/concurrency primitives, and little
    else. Even drivers are userspace processes; it's very
    microkernelesque.
    https://archive.org/details/h42_DEC_VAXELN_Technical_Summary/

    I suspect something that throws people unfamiliar with embedded
    and/or real-time systems for a loop is that the system is
    statically configured at build time. That is, one builds a
    system configured with exactly those services, drivers, programs
    etc, that are actually going to run on the target system. And
    yet there still is a real kernel there, unlike a pure "bare
    metal" program written by an end user that has, essentially, no
    runtime at all other than one the programmer provides.

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Simon Clubley@clubley@remove_me.eisner.decus.org-Earth.UFP to comp.os.vms on Tue Oct 28 13:09:48 2025
    From Newsgroup: comp.os.vms

    On 2025-10-26, Dennis Boone <drb@ihatespam.msu.edu> wrote:
    My impression is that vibe coding is not really a thing in
    companies for doing IT, but mostly a thing for companies
    wanting to sell software/training/AI access to other companies.

    A friend who works in IT at a bank has a boss who is all in on
    vibe coding. *visceral response*


    I think a quiet word with that bank's directors may be in order. :-(

    Not joking.

    Simon.
    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Simon Clubley@clubley@remove_me.eisner.decus.org-Earth.UFP to comp.os.vms on Tue Oct 28 13:16:18 2025
    From Newsgroup: comp.os.vms

    On 2025-10-24, John Dallman <jgd@cix.co.uk> wrote:
    In article <10dgdqc$2n2kl$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhoj) wrote:

    My impression is that vibe coding is not really a thing in
    companies for doing IT, but mostly a thing for companies
    wanting to sell software/training/AI access to other companies.

    It's also popular among people who are trying to become "IT experts" via social media postings, without any actual computer skills.


    Oh, you mean the people who now somehow think they are entitled to be
    called something, without actually having to do the boring and hard
    work to become that something for real ?

    I wonder if there's a way to prosecute the social media owners for
    their crimes against humanity in the name of profit ?

    Simon.
    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Simon Clubley@clubley@remove_me.eisner.decus.org-Earth.UFP to comp.os.vms on Tue Oct 28 13:54:01 2025
    From Newsgroup: comp.os.vms

    On 2025-10-27, jayjwa <jayjwa@atr2.ath.cx.invalid> wrote:
    It's an SDK but no one calls it that. It would be much easier to
    understand if they did. One creates an application in C or Pascal. Then
    you compile/link it with ELN libraries. Maybe it supports other
    languages but the docs mention C and Pascal.


    Also supports Ada.

    [snip]


    From the host side (one year is wrong for some reason):

    $
    %%%%%%%%%%% OPCOM 18-DEC-2023 20:35:32.35 %%%%%%%%%%%
    Message from user DECNET on KUSHAL
    DECnet event 0.3, automatic line service
    From node 1.12 (KUSHAL), 1-JAN-2041 00:00:00.00
    Circuit QNA-0, Load, Requested, Node = 1.16, File = SAMPLE.SYS
    Operating system, Ethernet address = AA-00-04-00-10-04

    $
    %%%%%%%%%%% OPCOM 18-DEC-2023 20:35:37.33 %%%%%%%%%%%
    Message from user DECNET on KUSHAL
    DECnet event 0.3, automatic line service
    From node 1.12 (KUSHAL), 1-JAN-2041 00:00:00.00
    Circuit QNA-0, Load, Successful, Node = 1.16, File = SAMPLE.SYS
    Operating system, Ethernet address = AA-00-04-00-10-04


    This may be because the 15-bit date offset boundary for the
    DECnet Phase IV event timestamp (as defined by the specification)
    was passed several years ago and therefore the system may be placing
    junk in that field. Current VMS itself uses the full 16-bits available,
    hence there is no problem on VMS itself.

    I came across this when I was probing EVL a few years ago and found that contrary to the specs it was still OK on current VMS systems. I think it
    was Rob who made that change to VMS but I can't remember for sure.

    Simon.
    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Robert A. Brooks@FIRST.LAST@vmssoftware.com to comp.os.vms on Tue Oct 28 12:15:58 2025
    From Newsgroup: comp.os.vms

    On 10/28/2025 09:54, Simon Clubley wrote:
    On 2025-10-27, jayjwa <jayjwa@atr2.ath.cx.invalid> wrote:

    %%%%%%%%%%% OPCOM 18-DEC-2023 20:35:37.33 %%%%%%%%%%%
    Message from user DECNET on KUSHAL
    DECnet event 0.3, automatic line service
    From node 1.12 (KUSHAL), 1-JAN-2041 00:00:00.00
    Circuit QNA-0, Load, Successful, Node = 1.16, File = SAMPLE.SYS
    Operating system, Ethernet address = AA-00-04-00-10-04


    This may be because the 15-bit date offset boundary for the
    DECnet Phase IV event timestamp (as defined by the specification)
    was passed several years ago and therefore the system may be placing
    junk in that field. Current VMS itself uses the full 16-bits available,
    hence there is no problem on VMS itself.

    I came across this when I was probing EVL a few years ago and found that contrary to the specs it was still OK on current VMS systems. I think it
    was Rob who made that change to VMS but I can't remember for sure.

    [EVL]EVLJULIAN.B32
    X-4 RAB0249 Robert A. Brooks 17-Nov-2022
    Fix for Jira DV-13/NetSuite 2057 -- "DECnet Phase IV"
    NICE event date issue"

    From a customer-sent mail message

    "Events are time-stamped when they are generated with a
    2-byte field holding the number of half julian days
    since Jan-1 1977. The spec (Network Management 4.0.0,
    page 170/171) implies that these 2 bytes should be treated
    as a signed value (0 - 32767) which will overflow on
    Nov 9th 2021. If the code treats it as unsigned, then we
    are good for another 44 years."

    The code in routine EVL$JULIAN appears to treat the
    relevant word as unsigned, but there is an explicit
    check such that any date after 1-Nov-2022 will return
    an error. Simply pushing the gating date check into
    the future allows the date to be formatted and displayed
    correctly. For cuteness, I'm using my 100th birthday of
    December 20, 2061 as the gating date. Yeah, it's not
    exactly 44 years past 10-Nov-2022, but hey, it's my call
    to make.
    --
    -- Rob
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Johnny Billquist@bqt@softjar.se to comp.os.vms on Wed Oct 29 10:04:25 2025
    From Newsgroup: comp.os.vms

    On 2025-10-28 17:15, Robert A. Brooks wrote:
    On 10/28/2025 09:54, Simon Clubley wrote:
    On 2025-10-27, jayjwa <jayjwa@atr2.ath.cx.invalid> wrote:

    %%%%%%%%%%%-a OPCOM-a 18-DEC-2023 20:35:37.33-a %%%%%%%%%%%
    Message from user DECNET on KUSHAL
    DECnet event 0.3, automatic line service
    -aFrom node 1.12 (KUSHAL),-a 1-JAN-2041 00:00:00.00
    Circuit QNA-0, Load, Successful, Node = 1.16, File = SAMPLE.SYS
    Operating system, Ethernet address = AA-00-04-00-10-04


    This may be because the 15-bit date offset boundary for the
    DECnet Phase IV event timestamp (as defined by the specification)
    was passed several years ago and therefore the system may be placing
    junk in that field. Current VMS itself uses the full 16-bits available,
    hence there is no problem on VMS itself.

    I came across this when I was probing EVL a few years ago and found that
    contrary to the specs it was still OK on current VMS systems. I think it
    was Rob who made that change to VMS but I can't remember for sure.

    [EVL]EVLJULIAN.B32
    X-4-a-a-a-a RAB0249-a-a-a-a-a-a-a-a Robert A. Brooks-a-a-a-a-a-a-a 17-Nov-2022
    -a-a-a-a-a-a-a Fix for Jira DV-13/NetSuite 2057 -- "DECnet Phase IV"
    -a-a-a-a-a-a-a NICE event date issue"

    -a-a-a-a-a-a-a From a customer-sent mail message

    -a-a-a-a-a-a-a "Events are time-stamped when they are generated with a
    -a-a-a-a-a-a-a 2-byte field holding the number of half julian days
    -a-a-a-a-a-a-a since Jan-1 1977. The spec (Network Management 4.0.0,
    -a-a-a-a-a-a-a page 170/171) implies that these 2 bytes should be treated
    -a-a-a-a-a-a-a as a signed value (0 - 32767) which will overflow on
    -a-a-a-a-a-a-a Nov 9th 2021. If the code treats it as unsigned, then we
    -a-a-a-a-a-a-a are good for another 44 years."

    -a-a-a-a-a-a-a The code in routine EVL$JULIAN appears to treat the
    -a-a-a-a-a-a-a relevant word as unsigned, but there is an explicit
    -a-a-a-a-a-a-a check such that any date after 1-Nov-2022 will return
    -a-a-a-a-a-a-a an error.-a Simply pushing the gating date check into
    -a-a-a-a-a-a-a the future allows the date to be formatted and displayed
    -a-a-a-a-a-a-a correctly.-a For cuteness, I'm using my 100th birthday of
    -a-a-a-a-a-a-a December 20, 2061 as the gating date.-a Yeah, it's not
    -a-a-a-a-a-a-a exactly 44 years past 10-Nov-2022, but hey, it's my call
    -a-a-a-a-a-a-a to make.

    So VMS only got the fix after the date had passed? Kindof interesting.

    In RSX:

    [320,10]EVCEVT.MAC
    ; 8.10 18-AUG-1998 D. Carroll
    ; DC515 - Correct event time reporting after 10-Nov-2021

    Johnny

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Simon Clubley@clubley@remove_me.eisner.decus.org-Earth.UFP to comp.os.vms on Wed Oct 29 13:13:24 2025
    From Newsgroup: comp.os.vms

    On 2025-10-28, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:

    [EVL]EVLJULIAN.B32
    X-4 RAB0249 Robert A. Brooks 17-Nov-2022
    Fix for Jira DV-13/NetSuite 2057 -- "DECnet Phase IV"
    NICE event date issue"

    From a customer-sent mail message

    "Events are time-stamped when they are generated with a
    2-byte field holding the number of half julian days
    since Jan-1 1977. The spec (Network Management 4.0.0,
    page 170/171) implies that these 2 bytes should be treated
    as a signed value (0 - 32767) which will overflow on
    Nov 9th 2021. If the code treats it as unsigned, then we
    are good for another 44 years."

    The code in routine EVL$JULIAN appears to treat the
    relevant word as unsigned, but there is an explicit
    check such that any date after 1-Nov-2022 will return
    an error. Simply pushing the gating date check into
    the future allows the date to be formatted and displayed
    correctly. For cuteness, I'm using my 100th birthday of
    December 20, 2061 as the gating date. Yeah, it's not
    exactly 44 years past 10-Nov-2022, but hey, it's my call
    to make.


    Interesting thanks. You made your change after I had finished my probing,
    but dates after the overflow date still worked for me at that time. My guess
    is that I didn't try any dates after that hard cutoff date of 1-Nov-2022.

    Also, thanks for showing the detailed change log entry above. It reminded
    me of my thoughts at the time I discovered this that, unless they wanted
    to go back in time, there was no reason for that field to be a signed value instead of an unsigned value.

    Simon.
    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Olorin@no_email@invalid.invalid to comp.os.vms on Thu Oct 30 09:14:27 2025
    From Newsgroup: comp.os.vms

    Subcommandante XDelta <vlf@star.enet.dec.com> 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

    :
    :

    Bare Metal VMS, VSI? - Quo Vadis...


    Back in late 2012 when I was out of work I had accepted (but never actually started) a job working with VMS at the Limerick, PA, nuclear power plant
    then owned by Exelon. They told me that the only application for which
    they were using VMS was some sort of long-term health monitoring of the reactor, rather than controlling it or any safety critical subsystems. My memory is vague these 13 years later, and I donrCOt remember for certain whether it was VAX or Alpha, but I do know they werenrCOt planning to migrate to Integrity (almost certainly a good thing they werenrCOt) but instead to
    move it to some other commodity architecture and OS.

    (I bailed out because the pay was low, the moving expenses were all on me,
    and there was little in the way of decent housing for my family to be had
    in the neighborhood. And Limerick at that time struck me as a pretty dismal place to live or work. Also I think at least some of their software people
    were unionized.)

    I would have had one Patrick Henry as my supervisor. That was really his
    name.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Thu Oct 30 10:52:56 2025
    From Newsgroup: comp.os.vms

    In article <10dva9i$3ihvb$1@dont-email.me>,
    Olorin <no_email@invalid.invalid> wrote:
    Subcommandante XDelta <vlf@star.enet.dec.com> 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

    :
    :

    Bare Metal VMS, VSI? - Quo Vadis...

    Back in late 2012 when I was out of work I had accepted (but never actually >started) a job working with VMS at the Limerick, PA, nuclear power plant
    then owned by Exelon. They told me that the only application for which
    they were using VMS was some sort of long-term health monitoring of the >reactor, rather than controlling it or any safety critical subsystems. My >memory is vague these 13 years later, and I donrCOt remember for certain >whether it was VAX or Alpha, but I do know they werenrCOt planning to migrate >to Integrity (almost certainly a good thing they werenrCOt) but instead to >move it to some other commodity architecture and OS.

    (I bailed out because the pay was low, the moving expenses were all on me, >and there was little in the way of decent housing for my family to be had
    in the neighborhood. And Limerick at that time struck me as a pretty dismal >place to live or work. Also I think at least some of their software people >were unionized.)

    I would have had one Patrick Henry as my supervisor. That was really his >name.

    I wonder if he ever sat in front of his terminal and said to the
    computer, "Give me memory or give me death!"

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2