Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.2602:f977:0:1::2!not-for-mail
From: kludge@panix.com (Scott Dorsey)
Newsgroups: comp.misc
Subject: Re: Inside an IBM z17
Date: Sun, 4 May 2025 20:53:42 -0400 (EDT)
Organization: Former users of Netcom shell (1989-2000)
Message-ID: <vv926m$bj1$1@panix2.panix.com>
References: <6813ee86$8$17$882e4bbb@reader.netnews.com> <vv6ip3$vubv$4@dont-email.me> <vv7t7r$kb1$1@panix2.panix.com> <vv8m4u$2qpl1$3@dont-email.me>
Injection-Info: reader1.panix.com; posting-host="2602:f977:0:1::2";
	logging-data="16858"; mail-complaints-to="abuse@panix.com"
Bytes: 2361
Lines: 41

Lawrence D'Oliveiro  <ldo@nz.invalid> wrote:
>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.

Yes, there are still 80 column card images in common use, but they are
not batch systems under the hood at all.  (Well, MVS still is, but CMS and
CICS sure aren't).

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.

>> 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.

Yes, that was the idea, but in the end it turned out to be a win instead
of a loss.   I wouldn't call it a kludge so much as a deeper sort of 
timesharing.

>> 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.

Sadly, I wish that were the case, although I will say that the one good
thing about systemd is the "quota system" built into it that does allow
some crude per-process I/O restrictions in ways that ionice never did.
It's certainly getting better.
--scott
-- 
"C'est un Nagra. C'est suisse, et tres, tres precis."