Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.vms > #378006 > unrolled thread
| Started by | gcalliet <gerard.calliet@pia-sofer.fr> |
|---|---|
| First post | 2025-10-29 15:48 +0100 |
| Last post | 2025-10-30 22:29 +0000 |
| Articles | 20 on this page of 153 — 15 participants |
Back to article view | Back to comp.os.vms
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
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Dave Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2025-12-08 23:57 -0500 |
| Message-ID | <10h8a6e$jk61$2@dont-email.me> |
| In reply to | #378250 |
On 12/1/2025 8:49 AM, Simon Clubley wrote: > On 2025-11-29, Dave Froble <davef@tsoft-inc.com> wrote: >> >> Sometimes things don't really change. You count to 10 the same way now as in >> 1960. (Trivial example) >> > > Are you sure ? I thought maths teaching was heading in a new direction > in multiple parts of your country as shown by this example (which is way > too close to actually being realistic, especially with the "support" > infrastructure from the people around the teacher): > > https://www.youtube.com/watch?v=Zh3Yz3PiXZw > >> >> Now this is opinion, and really a poor argument. While I detest the verbosity >> in most things, that is my choice, not the problem you claim. >> > > Back on topic, COBOL is very verbose, but I also hate way too concise > languages where the language designers don't even allow words like > "function" to be spelt out in full. You read code many more times than > you write it and having cryptic syntax makes that a lot harder to achieve. Strongly agree ... > Something like Ada was designed for readability, and I wish all other > languages followed that example. > > Just waiting for the moment when a newcomer designs a new language which > has syntax resembling TECO... :-) Save the world, shoot the idiot before it spreads ... -- 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
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2025-11-10 15:35 -0500 |
| Message-ID | <10etib2$94lk$1@dont-email.me> |
| In reply to | #378095 |
On 11/10/2025 9:12 AM, Simon Clubley wrote: >> In article <10eaaqr$2sqg0$1@dont-email.me>, >> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: >>> 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 like the whole CICS transaction functionality and failure recovery model. > BTW, what is the general replacement for CICS transaction processing and > how does the replacement functionality compare to CICS ? (if someone reallyly like CICS then TXSeries should provide a lot of the CICS functionality for AIX/Linux/Windows) CICS is basically just an application server with a transaction monitor supporting transactional components. At the very high level VMS ACMS had (has) a similar role. Once upon a time that was state of the art functionality. But times has changed. Lots of options to deploy transactional components today. Various platform software comes with transactional support: practically all relational databases, many NoSQL database (including MongoDB and BDB), message queue servers (RabbitMQ, ActiveMQ/ArtemisMQ, Kafka etc.) etc.. What that means is that it is trivial for practically any language (including script languages like PHP and Python!) to do transactions for a single data source. For multiple data sources XA transactions has been standardized, so data sources and client libraries supporting XA transactions (above list minus SQLite, MongoDB and Kafka) plus a transaction monitor and it works. It is not even difficult to do in languages like Java, C# etc.. For those that do not like XA transactions or the platform software does not support it, then there is the SAGA pattern and compensating transaction model. Yes that requires some coding, but it is a model that has been implemented hundreds of thousands of times, so developers (working on that type of application) know how to do it. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2025-11-10 15:37 -0500 |
| Message-ID | <10etie5$94lk$2@dont-email.me> |
| In reply to | #378095 |
On 11/10/2025 9:12 AM, Simon Clubley wrote:
> On 2025-11-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> 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.
Lot of companies migrate off cloud, but really no companies
migrate off cloud.
It depends on exactly what we are talking about.
The traditional model from 20 years ago - a data center with:
* a mainframe
* some commercial Unixes on a RISC platform
* some relative unique Linux and Windows server on x86-64 or
ESXi on x86-64
New model with:
* Linux containers deployed to Kubernetes cluster
* standardized Linux VM's
Nobody is going back from the new model to the traditional model.
Everybody is staying with the new model.
But a significant number of companies are migrating either fully or
partially
from public cloud to private cloud.
Still the new model. But the companies own the hardware instead of
Amazon/Microsoft/Google/Oracle owning it. And the companies manage their
own platform software instead of using managed services.
The reasons are not technical but:
1) Cost - if the company have a relative stable workload and have necessarry
inhouse IT expertise, then it is often lower cost.
2) Regulatory issues (data can not leave state/country) or poltical reasons
(dependency on another country).
But the practical change is often small.
One of the most public migrations is that of 37signals. Not because they
are a huge company, but because DHH is a very public person. They moved off
AWS and to their own servers. Servers that they paid for, but servers that
are hosted in a colocation data center and servers that was installed by
a third party company. It is quite possible that no 37signals employee has
ever been in the same rooms as their servers. From a technical
perspective not
so big a difference between AWS data center and co location data center, but
they saved money from paying Dell once instead of Amazon monthly!
Arne
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-11 14:47 +0000 |
| Message-ID | <10evia9$3mks5$1@paganini.bofh.team> |
| In reply to | #378095 |
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).
>
> 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
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-11-11 20:54 +0000 |
| Message-ID | <10f07ql$107hm$5@dont-email.me> |
| In reply to | #378101 |
On Tue, 11 Nov 2025 14:47:39 -0000 (UTC), Waldek Hebisch wrote: > 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. zSeries machines run Linux, too! Officially supported by IBM itself!
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-11-12 17:04 +0000 |
| Message-ID | <10f2emh$489$1@reader2.panix.com> |
| In reply to | #378095 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2025-11-13 13:42 +0000 |
| Message-ID | <10f4n8c$25lkk$1@dont-email.me> |
| In reply to | #378118 |
On 2025-11-12, Dan Cross <cross@spitfire.i.gajendra.net> wrote: > 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: >>> 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 > I was referring to the mistake of getting rid of your local systems, and local systems knowledge, in favour of moving everything into the public clouds and outsourcing your local systems knowledge and development to third party vendors. This works for some people, but not for others, and there appears to have been quite a drive by senior management in general of inappropriate movement away from local control and knowledge so that it "becomes someone else's problem". The problem is that it isn't someone else's problem, it's still their problem, as more than a few people have found out the hard way, promptly followed by spending more money to move things back in house again. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Walking destinations on a map are further away than they appear.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-11-16 02:00 +0000 |
| Message-ID | <10fbb7p$h28$1@reader2.panix.com> |
| In reply to | #378135 |
In article <10f4n8c$25lkk$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: >On 2025-11-12, Dan Cross <cross@spitfire.i.gajendra.net> wrote: >> 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: >>>> 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 > >I was referring to the mistake of getting rid of your local systems, >and local systems knowledge, in favour of moving everything into the >public clouds and outsourcing your local systems knowledge and >development to third party vendors. > >This works for some people, but not for others, and there appears to have >been quite a drive by senior management in general of inappropriate >movement away from local control and knowledge so that it "becomes someone >else's problem". > >The problem is that it isn't someone else's problem, it's still their >problem, as more than a few people have found out the hard way, promptly >followed by spending more money to move things back in house again. Ah, ok. Yes, I agree; discarding local domain knowledge is rarely --- if ever --- a good idea. It seems axiomatic that movement of systems should be done with care, and only after evaluating whether such a move is a good idea holistically. Clearly, a lot of people moved "to the cloud" who either did no such analysis, or did not account for a number of variables if they did. On the one hand, I kind of get that: there are a lot of unknowns when doing such things, and those may not be discovered until after the fact. On the other hand, once you've been around for a while, you know this is the case and should anticipate it. Among the arguments for the cloud are that provisioning, building, and maintaining datacenters is one of the core competencies of the hyperscalars. And that is true; the Googles and Amazons and Microsofts of the world do this better than anybody else. So you get tremendous economies of scale with respect to hardware and its maintenance if you leverage renting capacity from them. Further, you get to skip all of the capital expenses of building out your own infrastructure. Yay! And elasticity is attractive: you don't have to provision for (read: always pay for) your peak usage; you can adjust over time and that can save. But your workload is _your_ workload. The cloud provider doesn't have any insight into your requirements there, really, and if you're not a sufficiently large customer, they won't really care all that much either. At Google, we certainly made a good-faith effort, but some things just weren't worth it from the perspective of deciding where to spend engineering resources. I used to joke that we were sort of like the spacing guild from "Dune": the Atreides and Harkonnen's could have jobs running on the same machine and never know it. However, none of that is an excuse to throw away knowledge of your own workload. But just like renting instead of owning a home, you're subject to the landlord raising the rent on you. And once you hit a certain scale, the economies of scale argument begins to break down. Hence, re-homing back on-prem in a lot of cases. Provided you still know how to run your own stuff, of course. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2025-11-11 10:50 -0500 |
| Message-ID | <69135b62$0$665$14726298@news.sunsite.dk> |
| In reply to | #378038 |
On 11/3/2025 8:31 AM, Simon Clubley wrote: > 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. Note that even though z/OS and mainframes generally have a good track recording regarding availability, then it is not a magic solution - they can also have problems. Banks having mainframe problems are rare but far from unheard of. UK Barclays January 2025. https://www.forbes.com/sites/barrycollins/2025/03/08/barclays-down-again-as-uk-banking-pain-continues/ <quote> The company told MPs that the failure in January resulted in just over half of online payments failing. The failure was attributed to a “severe degradation” in the performance of the company’s mainframe computer. </quote> Denmark Danske Bank March 2003. https://danskebank.com/news-and-insights/news-archive/press-releases/2003/pr03042003 Short version: * during routine HW maintenance disk system for DB2 lost power * crash left data in an unexpected state triggering several until then undetected software errors in DB2 * as a result many of the banks systems was unavailable for most of a week [Danske Bank is Denmark biggest bank!] * and panic was close - the danish central bank sent out a billion dollars extra in liquidity to cover any risk of bank runs [the above link does not tell that story but it was elsewhere in the danish IT press at the time] Arne
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-11-11 20:57 +0000 |
| Message-ID | <10f07ve$107hm$6@dont-email.me> |
| In reply to | #378103 |
On Tue, 11 Nov 2025 10:50:57 -0500, Arne Vajhøj wrote: > Note that even though z/OS and mainframes generally have a good > track recording regarding availability, then it is not a magic > solution - they can also have problems. Mainframes were never designed for high availability. It was normal to run them 24/7, simply to try to get as much as possible out of them because they are/were so expensive to buy. But it was no big deal if they had to be taken down for, say, an hour a week for “preventive maintenance” or to switch OSes or whatever. Back in the 1980s, you had to reboot an IBM machine just to switch daylight saving on or off. Not sure if that’s been fixed yet ...
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2025-11-11 18:56 -0500 |
| Message-ID | <6913cd44$0$674$14726298@news.sunsite.dk> |
| In reply to | #378106 |
On 11/11/2025 3:57 PM, Lawrence D’Oliveiro wrote: > On Tue, 11 Nov 2025 10:50:57 -0500, Arne Vajhøj wrote: >> Note that even though z/OS and mainframes generally have a good >> track recording regarding availability, then it is not a magic >> solution - they can also have problems. > > Mainframes were never designed for high availability. It was normal to > run them 24/7, simply to try to get as much as possible out of them > because they are/were so expensive to buy. But it was no big deal if > they had to be taken down for, say, an hour a week for “preventive > maintenance” or to switch OSes or whatever. 24x7 vs 16x5 is not about HA - HA is about whether the system can continue to serve users in case part of a box or an entire box fail - 24x7 vs 16x5 is about architecture. Once upon a time it was common to shutdown an application at night and run various batch jobs, do backups etc.. z/OS or VMS or Unix. Many of the old applications still work that way. And it is one of the reasons why nobody want to do a 1:1 conversion from Cobol or PL/I to Java or C# or whatever - the application need to be rearchitected to work a different way. Arne
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-11-12 03:56 +0000 |
| Message-ID | <10f10gl$16kvh$5@dont-email.me> |
| In reply to | #378108 |
On Tue, 11 Nov 2025 18:56:53 -0500, Arne Vajhøj wrote: > HA is about whether the system can continue to serve users in case part > of a box or an entire box fail - 24x7 vs 16x5 is about architecture. High availability is measured in “nines” -- e.g. five nines, six nines ... even seven nines. How do big enterprises (like Google) achieve that? By not using mainframes. They set up data centres full of off-the-shelf PC hardware -- one article I remember from over a decade ago said that Google, at that time, had 460,000 servers. All the hardware is obtained as cheaply as possible, except one component: the power supply. They buy quality for that, for power-efficiency reasons. As for the rest, it doesn’t matter if a box falls over every minute, or a hard drive crashes every few minutes; they have higher-level redundancy and recovery procedures that can routinely recover from all those failures, without the users ever noticing. No mainframe can match that.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-11-12 13:43 +0000 |
| Message-ID | <10f22uu$cdv$1@reader2.panix.com> |
| In reply to | #378115 |
In article <10f10gl$16kvh$5@dont-email.me>, Lawrence DÿOliveiro <ldo@nz.invalid> wrote: >On Tue, 11 Nov 2025 18:56:53 -0500, Arne Vajhøj wrote: > >> HA is about whether the system can continue to serve users in case part >> of a box or an entire box fail - 24x7 vs 16x5 is about architecture. > >High availability is measured in “nines†-- e.g. five nines, six nines ... >even seven nines. I don't normally reply to the troll, but, in this case multiple factual misstatements deserve to be corrected. >How do big enterprises (like Google) achieve that? By not using >mainframes. This has absolutely nothing to do with it. Google used COTS x86 gear because of cost, period. The software was then architected to make this work well, and reliably. Google achieves high availability because its internal systems have been architected that way. But doing so is incredibly expensive, in multiple dimensions, and the solutions are unique to Google. >They set up data centres full of off-the-shelf PC hardware -- This has not been true for two decades. Google designs and manufactures its own computers for its datacenters. They are nowhere close to COTS systems anymore. >one article I remember from over a decade ago said that Google, at that >time, had 460,000 servers. Google has O(10^7) CPUs in O(10^6) computers in spread across O(10^2) data centers, distributed globally. There are multiple layers of redundancy and load balancing spreading traffic around and routing around problems (which pop up regularly at that scale). It also has automated monitoring, some automated recovery, and and a small army of SREs and data center technicians keeping everything running. It's not magic. >All the hardware is obtained as cheaply as possible, This has not been true for 15+ years. There was a time, early in Google's life, when this was true, but those days are long gone. Google has a highly developed, _highly_ skilled, internal platforms team that designs and builds its own hardware at nearly all levels of the stack. Very little is off the shelf anymore, and none of it is "cheap". >except one component: >the power supply. They buy quality for that, for power-efficiency reasons. >As for the rest, it doesn’t matter if a box falls over every minute, or a >hard drive crashes every few minutes; they have higher-level redundancy >and recovery procedures that can routinely recover from all those >failures, without the users ever noticing. This is true, but also nearly unique to the workloads Google puts on its systems. >No mainframe can match that. Totally an apples and oranges comparison. Google doesn't run workloads that look anything at all like what traditionally runs on a mainframe. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2025-11-12 14:54 -0500 |
| Message-ID | <10f2ol5$1koun$1@dont-email.me> |
| In reply to | #378115 |
On 11/11/2025 10:56 PM, Lawrence D’Oliveiro wrote: > On Tue, 11 Nov 2025 18:56:53 -0500, Arne Vajhøj wrote: >> HA is about whether the system can continue to serve users in case part >> of a box or an entire box fail - 24x7 vs 16x5 is about architecture. > > High availability is measured in “nines” -- e.g. five nines, six nines ... > even seven nines. > > How do big enterprises (like Google) achieve that? By not using > mainframes. They set up data centres full of off-the-shelf PC hardware -- > one article I remember from over a decade ago said that Google, at that > time, had 460,000 servers. > > All the hardware is obtained as cheaply as possible, except one component: > the power supply. They buy quality for that, for power-efficiency reasons. > As for the rest, it doesn’t matter if a box falls over every minute, or a > hard drive crashes every few minutes; they have higher-level redundancy > and recovery procedures that can routinely recover from all those > failures, without the users ever noticing. > > No mainframe can match that. Of course mainframes can match that. The fundamental mechanism is the same for mainframes and let us call it modern distributed environments. You need N systems running to handle load. There is a probability Pd of one system becoming unavailable. You want Pr probability of handling the load. You can calculate how many systems M you need to achieve that. N is smaller, Pd is smaller and the cost of a system is much bigger for mainframes than for x86-64 servers. But the formula is the same. You can do the math. IBM mainframes use OS clustering (like VMS) called SysPlex. The modern distributed environments use pure application level clustering. But that is the "how" not the "what". Arne
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-11-12 21:02 +0000 |
| Message-ID | <10f2slf$1n77t$6@dont-email.me> |
| In reply to | #378119 |
On Wed, 12 Nov 2025 14:54:13 -0500, Arne Vajhøj wrote: > On 11/11/2025 10:56 PM, Lawrence D’Oliveiro wrote: >> >> No mainframe can match that. > > Of course mainframes can match that. Nobody can afford to buy enough mainframes to match that. > IBM mainframes use OS clustering (like VMS) called > SysPlex. Do either of those scale to 460,000 nodes? No, they don’t.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2025-11-12 16:10 -0500 |
| Message-ID | <6914f7cf$0$675$14726298@news.sunsite.dk> |
| In reply to | #378122 |
On 11/12/2025 4:02 PM, Lawrence D’Oliveiro wrote: > On Wed, 12 Nov 2025 14:54:13 -0500, Arne Vajhøj wrote: >> On 11/11/2025 10:56 PM, Lawrence D’Oliveiro wrote: >>> No mainframe can match that. >> >> Of course mainframes can match that. > > Nobody can afford to buy enough mainframes to match that. > >> IBM mainframes use OS clustering (like VMS) called >> SysPlex. > > Do either of those scale to 460,000 nodes? > > No, they don’t. I believe the topic was whether mainframes can achieve the availability - the required number of nines. They can. Whether mainframes can do web scale like Google Search and FaceBook is a totally different question. I don't think they can - they are not designed for that level of scalability. Arne
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-11-14 05:47 +0000 |
| Message-ID | <10f6fot$2lc5d$2@dont-email.me> |
| In reply to | #378124 |
On Wed, 12 Nov 2025 16:10:39 -0500, Arne Vajhøj wrote: > On 11/12/2025 4:02 PM, Lawrence D’Oliveiro wrote: >> >> On Wed, 12 Nov 2025 14:54:13 -0500, Arne Vajhøj wrote: >>> >>> On 11/11/2025 10:56 PM, Lawrence D’Oliveiro wrote: >>>> >>>> No mainframe can match that. >>> >>> Of course mainframes can match that. >> >> Nobody can afford to buy enough mainframes to match that. >> >>> IBM mainframes use OS clustering (like VMS) called SysPlex. >> >> Do either of those scale to 460,000 nodes? >> >> No, they don’t. > > I believe the topic was whether mainframes can achieve the availability > - the required number of nines. They can. No they can’t. Mainframes were never designed for high availability. How many nines does IBM offer? Hint: look at this intro from IBM itself <https://www.ibm.com/think/topics/high-availability>. Do they mention their own mainframes? No. Do they mention cloud and Linux companies? Yes.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2025-11-14 16:49 -0500 |
| Message-ID | <10f885t$345pn$1@dont-email.me> |
| In reply to | #378139 |
On 11/14/2025 12:47 AM, Lawrence D’Oliveiro wrote: > On Wed, 12 Nov 2025 16:10:39 -0500, Arne Vajhøj wrote: >> I believe the topic was whether mainframes can achieve the availability >> - the required number of nines. They can. > > No they can’t. Mainframes were never designed for high availability. > > How many nines does IBM offer? > > Hint: look at this intro from IBM itself > <https://www.ibm.com/think/topics/high-availability>. Do they mention > their own mainframes? No. Do they mention cloud and Linux companies? Yes. Better hint - their page about z resiliency: https://www.ibm.com/products/z/resiliency <quote> For clients running z/OS v3.1 or higher with a configured high availability IBM software stack on IBM z16 or IBM z17, users can expect up to 99.999999% availability or 315.58 milliseconds of downtime per year when using a GDPS 4.7 Continuous Availability (CA) configuration and workloads. </quote> That is a lot of nines. Arne
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-11-18 07:29 +0000 |
| Message-ID | <10fh795$1cvaf$4@dont-email.me> |
| In reply to | #378145 |
On Fri, 14 Nov 2025 16:49:49 -0500, Arne Vajhøj wrote:
> On 11/14/2025 12:47 AM, Lawrence D’Oliveiro wrote:
>>
>> On Wed, 12 Nov 2025 16:10:39 -0500, Arne Vajhøj wrote:
>>>
>>> I believe the topic was whether mainframes can achieve the
>>> availability - the required number of nines. They can.
>>
>> No they can’t. Mainframes were never designed for high availability.
>>
>> How many nines does IBM offer?
>>
>> Hint: look at this intro from IBM itself
>> <https://www.ibm.com/think/topics/high-availability>. Do they mention
>> their own mainframes? No. Do they mention cloud and Linux companies?
>> Yes.
>
> Better hint - their page about z resiliency:
>
> https://www.ibm.com/products/z/resiliency
>
> <quote>
> For clients running z/OS v3.1 or higher with a configured high
> availability IBM software stack on IBM z16 or IBM z17, users can expect
> up to 99.999999% availability or 315.58 milliseconds of downtime per
> year when using a GDPS 4.7 Continuous Availability (CA) configuration
> and workloads.
> </quote>
>
> That is a lot of nines.
Did you notice the footnote?
<https://www.ibm.com/products/z/resiliency#footnote>:
1 IBM z17 systems, with GDPS, IBM DS8000 series storage with
HyperSwap, and running a Red Hat OpenShift Container Platform
environment, are designed to deliver 99.999999% availability.
Now, what does Red Hat got to do with mainframe resiliency? In fact, the
mainframe doesn’t really have anything to do with it, does it? It’s all
down to Linux-based high-availability technologies, like OpenShift. All
the resiliency is effectively coming from that.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2025-11-18 13:52 -0500 |
| Message-ID | <10fif9t$1n41a$1@dont-email.me> |
| In reply to | #378178 |
On 11/18/2025 2:29 AM, Lawrence D’Oliveiro wrote: > On Fri, 14 Nov 2025 16:49:49 -0500, Arne Vajhøj wrote: >> Better hint - their page about z resiliency: >> >> https://www.ibm.com/products/z/resiliency >> >> <quote> >> For clients running z/OS v3.1 or higher with a configured high >> availability IBM software stack on IBM z16 or IBM z17, users can expect >> up to 99.999999% availability or 315.58 milliseconds of downtime per >> year when using a GDPS 4.7 Continuous Availability (CA) configuration >> and workloads. >> </quote> >> >> That is a lot of nines. > > Did you notice the footnote? > > <https://www.ibm.com/products/z/resiliency#footnote>: > > 1 IBM z17 systems, with GDPS, IBM DS8000 series storage with > HyperSwap, and running a Red Hat OpenShift Container Platform > environment, are designed to deliver 99.999999% availability. > > Now, what does Red Hat got to do with mainframe resiliency? In fact, the > mainframe doesn’t really have anything to do with it, does it? It’s all > down to Linux-based high-availability technologies, like OpenShift. All > the resiliency is effectively coming from that. You need to read it all. They can do that uptime for different software stacks: MongoDB on k8s on Linux on z/VM on mainframe DB2 on z/OS on mainframe IMS on z/OS on mainframe But even for the MongoDB k8s case the mainframe contribute to the expected uptime due to the low number of active physical boxes. Arne
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.os.vms
csiph-web