Groups | Search | Server Info | Login | Register
Groups > comp.os.vms > #378118
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Newsgroups | comp.os.vms |
| Subject | Re: And so? (VMS/XDE) |
| Date | 2025-11-12 17:04 +0000 |
| Organization | PANIX Public Access Internet and UNIX, NYC |
| Message-ID | <10f2emh$489$1@reader2.panix.com> (permalink) |
| References | <mmenp7F4bqiU1@mid.individual.net> <10eaaqr$2sqg0$1@dont-email.me> <10eku4c$fka$1@reader2.panix.com> <10esrru$1qu6$1@dont-email.me> |
In article <10esrru$1qu6$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: >On 2025-11-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote: >> In article <10eaaqr$2sqg0$1@dont-email.me>, >> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: >>>On 2025-10-30, Arne Vajhøj <arne@vajhoej.dk> wrote: >>>> On 10/30/2025 9:12 AM, Simon Clubley wrote: >>>>> On 2025-10-30, gcalliet <gerard.calliet@pia-sofer.fr> wrote: >>>>>> It seems now, because the strategy used by VSI or its investor has been >>>>>> for ten years a strategy copied on strategies for legacies OS (like >>>>>> z/os...), the option of a VMS revival as an alternate OS solution is >>>>>> almost dead. >>>>> >>>>> z/OS is responsible for keeping a good portion of today's world running. >>>>> I would hardly call that a legacy OS. >>>> >>>> z/OS is still used for a lot of very important systems. >>>> >>>> But it is also an OS that companies are actively >>>> moving away from. >>>> >>> >>>Interesting. I can see how some people on the edges might be considering >>>such a move, but at the very core of the z/OS world are companies that >>>I thought such a move would be absolutely impossible to consider. >>> >>>What are they moving to, and how are they satisfying the extremely high >>>constraints both on software and hardware availability, failure detection, >>>and recovery that z/OS and its underlying hardware provides ? >>> >>>z/OS has a unique set of capabilities when it comes to the absolutely >>>critical this _MUST_ continue working or the country/company dies area. >> >> I'm curious: what, in your view, are those capabilities? > >That's a good question. I am hard pressed to identify one single feature, >but can identify a range of features, that when combined together, help to >produce a solid robust system for mission critical computing. > >For example, I like the predictive failure analysis capabilities (and I wish >VMS had something like that). This is certainly an area where other systems lag behind, but as x86 systems (for example) increase support for RAS and MCA/MCAX, they are rapidly catching up. The SoCs and interconnects have the capability at the hardware level, but the software is not there (Linux in particular was lagging the last time I looked closely). >I like the multiple levels of hardware failure detection and automatic >recovery without system downtime. Fair, but this is not unique to IBM or even mainframes; most server-grade systems support auto offlining storage devices and hotplug; some also support this for CPUs and/or DRAM. However, I would argue that this speaks to a system view that was becoming obsolete, but is (perhaps ironically) coming back into fashion. A couple of decades ago, the realization was that, for certain workloads, you were better off providing availability by horizontal scaling and if building availability in software at the application level. If a machine fell over and took out a job, oh well; just restart it on another node. No need for the complexity of handling that on a single node. Google, for instance, did this somewhat famously for web search, where regularly indexing (essentially) the entire world wide web was required. The MapReduce framework put the self-healing into the job/sharding layer: if a shard was being slow, MR just restarted it. This ended up pervading the software stack, to the point that regular maintenance jobs (for instance, to update software) would just restart the machine regardless of what jobs were running on it; the borg scheduler would just spin them up elsewhere, and whatever framework was being used by them would coordinate things appropriately. But note that web search is an embarassingly parallel problem, which is amenable to such things. Many other workloads are not; this really broke down for e.g. GCP, where you can't just knock over a customer VM and restart it somewhere else with no coordination. Furthermore, as core counts are increasing significantly, now regularly exceeding 255 on high end parts, this is become more expensive. With so many different things running on a single node, "just reboot" as a means to fixing things doesn't scale. >I like the way the hardware and z/OS and layered products software are >tightly integrated into a coherent whole. > >I like the way the software was designed with a very tight single-minded >focus on providing certain capabilities in highly demanding environments >instead of in some undirected rambling evolution. > >I like the way the hardware and software have evolved, in a designed way, >to address business needs, without becoming bloated (unlike modern software >stacks). A lean system has many less failure points and less points of >vulnerability than a bloated system. I dunno, I always felt that mainframe software was bloated and baroque. VTAM, ISAM, JCL...ick. The hardware/software co-design advantage is very real however. That's one reason we do hardware/software codesign at work. >I like the whole CICS transaction functionality and failure recovery model. As has been pointed out, this exists outside of the CICS system as well. XA is pretty well standard at this point. >>>Likewise, to replace z/OS, any replacement hardware and software must also >>>have the same unique capabilities that z/OS, and the hardware it runs on, >>>has. What is the general ecosystem, at both software and hardware level, >>>that these people are moving to ? >> >> I think a bigger issue is lock-in. We _know_ how to build >> performant, reliable, distributed systems. What we don't seem >> able to collectively do is migrate away from 50 years of history >> with proprietary technology. Mainframes work, they're reliable, >> and they're low-risk. It's dealing with the ISAM, CICS, VTAM, >> DB2, COBOL extensions, etc, etc, etc, that are slowing migration >> off of them because that's migrating to a fundamentally >> different model, which is both hard and high-risk. > >Question: are they low-risk because they were designed to do one thing >and to do it very well in extremely demanding environments ? > >Are the replacements higher-risk because they are more of a generic >infrastructure and the mission critical workloads need to be force-fitted >into them ? I think it's low-risk because those applications have been running in production for many years, in some cases, decades; they're well-tested and debugged, and the rate of change is very low. The alternatives are higher-risk because it's not just the underlying OS or hardware that's changing, but the entire application model. It's my sense that so many migrate-off-the-mainframe projects fail not because the mainframe is so singularly unmatched, but because those projects are world-shifts, in which _everything_ changes: the hardware and host OS, but also the application code itself, the user interface, database, etc. I suspect that if it were feasible to just lift the code and data off of the mainframe and plop it onto something else, most would work just fine. But that's essentially never what happens. The mainframe is, at this point, so alien in the larger scheme of things that it's impossible to "just" move with a recompile. OTOH, I suspect that for _many_ projects if you were running on, say, Solaris, it's pretty straight-forward to recompile for Linux and run with more or less the same stack. Of course there is a lot of heavy lifting one must do in terms of testing and qualification, but that is qualitatively different than having no choice other than rewriting everything from the ground up. >BTW, what is the general replacement for CICS transaction processing and >how does the replacement functionality compare to CICS ? This is outside of my wheelhouse, but back in the day things like BEA Tuxedo could do this and more. >> As for the cloud, the number of organizations moving back >> on-prem for very good reasons shouldn't be discounted. > >Yes, and I hope the latest batch of critical system movers do not >repeat those same mistakes. I'm not sure what mistakes you're referring to, but let's hope that system maintainers make fewer mistakes generally. :-D - Dan C.
Back to comp.os.vms | Previous | Next — Previous in thread | Next in thread | Find similar
And so? (VMS/XDE) gcalliet <gerard.calliet@pia-sofer.fr> - 2025-10-29 15:48 +0100
Re: And so? (VMS/XDE) Chris Townley <news@cct-net.co.uk> - 2025-10-29 15:19 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-10-29 19:03 -0400
Re: And so? (VMS/XDE) Chris Townley <news@cct-net.co.uk> - 2025-10-29 23:16 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-10-29 19:25 -0400
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-10-30 11:30 +0000
Re: And so? (VMS/XDE) drb@ihatespam.msu.edu (Dennis Boone) - 2025-10-29 16:13 +0000
Re: And so? (VMS/XDE) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-10-29 18:48 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-10-29 15:52 -0400
Re: And so? (VMS/XDE) Chris Townley <news@cct-net.co.uk> - 2025-10-29 21:45 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-10-29 15:59 -0400
Re: And so? (VMS/XDE) gcalliet <gerard.calliet@pia-sofer.fr> - 2025-10-30 09:19 +0100
Re: And so? (VMS/XDE) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-10-30 13:12 +0000
Re: And so? (VMS/XDE) gcalliet <gerard.calliet@pia-sofer.fr> - 2025-10-30 20:05 +0100
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-10-30 15:59 -0400
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-30 22:28 +0000
Re: And so? (VMS/XDE) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-03 13:31 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-03 15:18 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-03 15:28 -0500
Re: And so? (VMS/XDE) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-04 13:59 +0000
Re: And so? (VMS/XDE) Subcommandante XDelta <vlf@star.enet.dec.com> - 2025-11-05 07:57 +1100
Re: And so? (VMS/XDE) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-05 13:25 +0000
Re: And so? (VMS/XDE) bill <bill.gunshannon@gmail.com> - 2025-11-06 08:44 -0500
Re: And so? (VMS/XDE) gcalliet <gerard.calliet@pia-sofer.fr> - 2025-11-20 13:05 +0100
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-04 19:34 -0500
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-07 14:01 +0000
Re: And so? (VMS/XDE) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-10 14:12 +0000
Re: And so? (VMS/XDE) bill <bill.gunshannon@gmail.com> - 2025-11-10 10:19 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-10 15:43 -0500
Re: And so? (VMS/XDE) antispam@fricas.org (Waldek Hebisch) - 2025-11-11 15:23 +0000
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-11 20:59 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-11 19:57 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-11 20:02 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-12 03:51 +0000
Re: And so? (VMS/XDE) Chris Townley <news@cct-net.co.uk> - 2025-11-12 01:50 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-11 21:00 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-12 03:48 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-12 15:12 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-12 21:01 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-12 16:06 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-14 23:35 +0000
Re: And so? (VMS/XDE) antispam@fricas.org (Waldek Hebisch) - 2025-11-15 00:24 +0000
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-15 02:41 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 22:18 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-15 06:00 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-15 09:22 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-15 22:16 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-15 18:12 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-18 07:25 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-18 09:19 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-20 23:07 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-20 19:41 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-20 19:55 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-21 19:09 -0500
Re: And so? (VMS/XDE) Andreas Eder <a_eder_muc@web.de> - 2025-11-15 12:15 +0100
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-15 08:27 -0500
Re: And so? (VMS/XDE) Dave Froble <davef@tsoft-inc.com> - 2025-11-29 19:49 -0500
Re: And so? (VMS/XDE) antispam@fricas.org (Waldek Hebisch) - 2025-11-30 05:44 +0000
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-30 06:33 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-30 14:21 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-30 14:23 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-30 16:04 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-30 16:09 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-30 16:11 -0500
Re: And so? (VMS/XDE) Chris Townley <news@cct-net.co.uk> - 2025-11-30 21:49 +0000
Re: And so? (VMS/XDE) antispam@fricas.org (Waldek Hebisch) - 2025-11-30 22:18 +0000
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-14 01:37 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-30 17:44 -0500
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-01 13:37 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-01 16:02 -0500
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-01 21:26 +0000
Re: And so? (VMS/XDE) bill <bill.gunshannon@gmail.com> - 2025-12-01 17:46 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-01 18:50 -0500
Re: And so? (VMS/XDE) bill <bill.gunshannon@gmail.com> - 2025-12-01 20:23 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-01 20:44 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-01 20:55 -0500
Re: And so? (VMS/XDE) bill <bill.gunshannon@gmail.com> - 2025-12-01 22:05 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-01 22:18 -0500
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-02 12:59 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-01 20:06 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-01 20:14 -0500
Re: And so? (VMS/XDE) bill <bill.gunshannon@gmail.com> - 2025-12-01 20:15 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-01 20:31 -0500
Re: And so? (VMS/XDE) bill <bill.gunshannon@gmail.com> - 2025-12-01 21:39 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-01 22:03 -0500
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-02 13:50 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-02 10:25 -0500
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-02 15:46 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-02 10:57 -0500
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-02 19:03 +0000
Re: And so? (VMS/XDE) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-01 13:49 +0000
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-01 18:59 +0000
Re: And so? (VMS/XDE) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-01 19:58 +0000
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-02 15:42 +0000
Re: And so? (VMS/XDE) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-12-03 14:07 +0000
Re: And so? (VMS/XDE) Dave Froble <davef@tsoft-inc.com> - 2025-12-09 00:19 -0500
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-10 18:38 +0000
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-01 21:23 +0000
Re: And so? (VMS/XDE) bill <bill.gunshannon@gmail.com> - 2025-12-01 17:50 -0500
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-02 13:56 +0000
Re: And so? (VMS/XDE) Dave Froble <davef@tsoft-inc.com> - 2025-12-08 23:57 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-10 15:35 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-10 15:37 -0500
Re: And so? (VMS/XDE) antispam@fricas.org (Waldek Hebisch) - 2025-11-11 14:47 +0000
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-11 20:54 +0000
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-12 17:04 +0000
Re: And so? (VMS/XDE) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-13 13:42 +0000
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-16 02:00 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-11 10:50 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-11 20:57 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-11 18:56 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-12 03:56 +0000
Re: And so? (VMS/XDE) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-12 13:43 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-12 14:54 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-12 21:02 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-12 16:10 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-14 05:47 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 16:49 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-18 07:29 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-18 13:52 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-20 23:09 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-20 19:31 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-21 01:32 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-20 19:36 -0500
Re: And so? (VMS/XDE) David Wade <g4ugm@dave.invalid> - 2025-11-12 21:43 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-12 16:57 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-13 02:45 +0000
Re: And so? (VMS/XDE) David Wade <g4ugm@dave.invalid> - 2025-11-13 10:36 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-13 16:13 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-14 23:39 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 16:58 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-17 21:19 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-18 06:47 +0000
Re: And so? (VMS/XDE) "Niels S. Eliasen" <nse@eliasen.co> - 2025-12-19 11:16 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-19 08:07 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-12-19 08:53 -0500
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-10-30 15:52 -0400
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-30 22:26 +0000
Re: And so? (VMS/XDE) jgd@cix.co.uk (John Dallman) - 2025-11-01 16:40 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-01 13:04 -0400
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-01 20:18 +0000
Re: And so? (VMS/XDE) jgd@cix.co.uk (John Dallman) - 2025-11-04 22:17 +0000
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-04 22:25 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-04 19:13 -0500
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-01 20:14 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-01 20:02 -0400
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-02 01:34 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-01 21:44 -0400
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-01 17:44 -0400
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-01 22:13 +0000
Re: And so? (VMS/XDE) Arne Vajhøj <arne@vajhoej.dk> - 2025-11-01 20:14 -0400
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-02 01:30 +0000
Re: And so? (VMS/XDE) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-30 22:29 +0000
csiph-web