From: antispam@fricas.org

Simon Clubley  wrote:
> On 2025-11-07, Dan Cross  wrote:
>> In article <10eaaqr$2sqg0$1@dont-email.me>,
>> Simon Clubley   wrote:
>>>On 2025-10-30, Arne Vajhøj  wrote:
>>>> On 10/30/2025 9:12 AM, Simon Clubley wrote:
>>>>> On 2025-10-30, gcalliet  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).
>
> I like the multiple levels of hardware failure detection and automatic
> recovery without system downtime.
>
> 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.

Sorry, your claim about "designed way" looks out of place.  z/OS is
a descendant of OS/360.  OS/360 attempted to support all possible
uses and consequently put in a lot of complexity and bloat.  It
quickly turned out that actual needs are different, so system
evolved.  Its designers realised that it is rather bad fit for
some use case, so concentrated on its traditional uses.  But it
still carry things which make no sense in modern times, but are
there just to support old applications that expect old interfaces.

In modern system there is no need for "below the line" (or "below
the bar").  IIUC IBM still pretends that disks have CKD organization.
IBM did a lot of things differently than a rest of industry and
I am affraid that there is a lot of code to support old applications
working in IBM way.

> I like the whole CICS transaction functionality and failure recovery model.
>
>>>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 ?

No.  Mainfraimes are low risk because change is risky.  That is,
if you wanted to port some modern software to z/OS, then there
would be risk.  Of course, mainfraimes have advantage of long
experience with "enterprise" data processing, but current
Linux vendors also have a lot of experience.  And there are
kinds of processing that never were popular on mainfraimes,
so actually alternatives may offer more experience.

--
                              Waldek Hebisch

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)