What exactly are they good for? Nothing, really, except perhaps
compatibility with ancient legacy code that has long passed its EOL, just >like the companies that might still be running it.
From the «go big or go home» department:
Title: A tour inside the IBM z17
Author: Thom Holwerda
Date: Thu, 24 Apr 2025 20:38:18 +0000
Link: https://www.osnews.com/story/142196/a-tour-inside-the-ibm-z17/
It's a weird thing... it's an I/O machine that happens to have a CPU controlling it.
It's a very different way of thinking about computing and it's still a
good thing for transaction processing systems with big databases behind
it, the sort of thing that is I/O intensive but cannot be easily
distributed.
What exactly are they good for? Nothing, really, except perhaps
compatibility with ancient legacy code that has long passed its EOL,
just like the companies that might still be running it.
On 01.05.2025 22:16 Uhr Lawrence D'Oliveiro wrote:
What exactly are they good for? Nothing, really, except perhaps
compatibility with ancient legacy code that has long passed its EOL,
just like the companies that might still be running it.
Linux can run on IBM z, so you can do anything that Linux can do on
those machines.
Linux can run on IBM z, so you can do anything that Linux can do on
those machines.
On Fri, 2 May 2025 10:34:07 +0200, Marco Moock wrote:
Linux can run on IBM z, so you can do anything that Linux can do on
those machines.
Yeah, but how on earth would you run something like a full-screen
editor on a block-mode text terminal that requires you to press the
SEND key every time?
From the «go big or go home» department:
Title: A tour inside the IBM z17
Author: Thom Holwerda
Date: Thu, 24 Apr 2025 20:38:18 +0000
Link: https://www.osnews.com/story/142196/a-tour-inside-the-ibm-z17/
Welcome to a photo-driven tour of the IBM z17[1]. I’ve scoured the image library to pull dig deep inside these machines that most people don’t get an
opportunity to see inside, and I’ll share some of the specifications gleaned
from the announcement and related Redbooks.
I was sorry to see even the purveyors of mainframe solutions are
obliged to slather their marketing material with the phrase "AI" from
the get-go. Here is the first paragraph on that IBM fact sheet, pure >horse-pucky. Oh wow, the Z17 comes with AI built in? How many
funloops is it capable of?*
On Fri, 2 May 2025 10:34:07 +0200, Marco Moock wrote:
Linux can run on IBM z, so you can do anything that Linux can do on
those machines.
Yeah, but how on earth would you run something like a full-screen editor
on a block-mode text terminal that requires you to press the SEND key
every time?
Try connecting thousands of users to a single linux box. You'll soon see the >utility of block mode terminals.
Try connecting thousands of users to a single linux box. You'll soon
see the utility of block mode terminals.
That's the cool thing... the way you manage it is by having thousands of users, each on their own linux box, sending short transactions to the
big IBM machine.
Mainframes support NFS but in my case I mostly ftp'd files, JCL, and
results back and forth.
I was sorry to see even the purveyors of mainframe solutions are obliged
to slather their marketing material with the phrase "AI" from the
get-go.
On Sat, 03 May 2025 13:51:35 -0400, Dan Espen wrote:
Try connecting thousands of users to a single linux box. You'll soon
see the utility of block mode terminals.
A client of mine just got a machine with 40-something CPU cores (each >multithreaded), and something close to a terabyte of RAM. And a couple
dozen hot-swap slots for multi-terabyte hard drives.
Of course we’re going to run Linux. I don’t think we’ll have trouble >handling thousands of users on that ...
On Sat, 3 May 2025 16:07:59 -0400 (EDT), Scott Dorsey wrote:
That's the cool thing... the way you manage it is by having thousands of
users, each on their own linux box, sending short transactions to the
big IBM machine.
How wonderful. No doubt your user base are accustomed to thinking in terms
of “transactions” rather than point-and-click, are they ...
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 3 May 2025 16:07:59 -0400 (EDT), Scott Dorsey wrote:
That's the cool thing... the way you manage it is by having thousands
of users, each on their own linux box, sending short transactions to
the big IBM machine.
How wonderful. No doubt your user base are accustomed to thinking in
terms of “transactions” rather than point-and-click, are they ...
The users never see that ...
But make all those web servers refer to a central Oracle database and
watch everything slow to a crawl.
But they do still suffer the latencies from a platform optimized for batch >rather than interactive operation, don’t they.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
But they do still suffer the latencies from a platform optimized for
batch rather than interactive operation, don’t they.
No, this isn't 1965 any longer. These are realtime transaction
processing systems.
You _can_ run batch stuff on VM/CMS too ...
The ability to manage I/O load dynamically is a big deal.
On Sun, 4 May 2025 10:22:51 -0400 (EDT), Scott Dorsey wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
But they do still suffer the latencies from a platform optimized for >>>batch rather than interactive operation, don’t they.
No, this isn't 1965 any longer. These are realtime transaction
processing systems.
No, they are *batch* transaction processing systems. They have file
formats that still emulate the layout of punch cards.
You _can_ run batch stuff on VM/CMS too ...
Remember what the VM part was for: it was a kludge because CMS wasn't a >proper multiuser OS. So to work around that, each user was given their own >entire virtual machine.
The ability to manage I/O load dynamically is a big deal.
Not on a modern OS like Linux, that just takes it all in its stride.
You should check out Martin's "Design of Real-Time Computer Systems"
which was written in the early days of SAABRE and other transaction processing systems.
On Sun, 4 May 2025 20:53:42 -0400 (EDT), Scott Dorsey wrote:
You should check out Martin's "Design of Real-Time Computer Systems"
which was written in the early days of SAABRE and other transaction
processing systems.
Their idea of real time was responding in a few seconds, before the user
got frustrated enough to hit SEND again.
Meanwhile, Linux recently mainlined the PREEMPT_RT patches, where the >definition of real time is being able to provide sub-millisecond
response to playing or recording sound samples for pro audio.
In article <vv9fdc$3mhk4$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Meanwhile, Linux recently mainlined the PREEMPT_RT patches, where the
definition of real time is being able to provide sub-millisecond
response to playing or recording sound samples for pro audio.
That's still not hard realtime at all ...
But what they mean by "RT" isn't what hard realtime people mean by "RT"
which has nothing to do with what the transaction processing guys meant
as "RT." Do not get hung up on words, especially when people use the
same words for rather different concepts.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Sun, 4 May 2025 20:53:42 -0400 (EDT), Scott Dorsey wrote:
You should check out Martin's "Design of Real-Time Computer Systems"
which was written in the early days of SAABRE and other transaction
processing systems.
Their idea of “real time” was responding in a few seconds, before the
user got frustrated enough to hit SEND again.
My experience: 360/30, 64K, 1968, locally attached 2260s, BTAM
application, instantaneous response.
My experience: 360/30, 64K, 1968, locally attached 2260s, BTAM
application, instantaneous response.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Mon, 05 May 2025 11:31:55 -0400, Dan Espen wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Sun, 4 May 2025 20:53:42 -0400 (EDT), Scott Dorsey wrote:
You should check out Martin's "Design of Real-Time Computer Systems" >>>>> which was written in the early days of SAABRE and other transaction
processing systems.
Their idea of “real time” was responding in a few seconds, before the >>>> user got frustrated enough to hit SEND again.
My experience: 360/30, 64K, 1968, locally attached 2260s, BTAM
application, instantaneous response.
“Instantaneous” to every keystroke? In something like a full-screen
editor?
Huh?
What about block mode terminals don't you understand?
Of course it's instantaneous to every keystroke. And in this case
it was also instantaneous to the enter key. First online
app I developed. Online order entry.
What about block mode terminals don't you understand?
Of course it's instantaneous to every keystroke.
Now imagine trying to run something more properly interactive, like Emacs
(or vi/vim, if you prefer), through such an interface.
You mean like word processing on PROFS where the editor is basically
running on the channel controller? That is great and extremely zippy
over a slow network. Far better performance with any network latency
than trying to send everything over the connection.
Where I worked, it was also instant on Enter, Function keys, etc. All
the keys that required mainframe attention.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 491 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 136:16:44 |
| Calls: | 9,692 |
| Calls today: | 2 |
| Files: | 13,728 |
| Messages: | 6,177,927 |