| Re: old pharts, Multics vs Unix vs mainframes [message #426666 is a reply to message #426655] |
Fri, 31 January 2025 17:59   |
Anne & Lynn Wheel
Messages: 3254
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
periodically reposted, including in afc a couple years ago
industry benchmark ... number of program iterations compared to
reference platform. Early mainframe actual benchmarks ... later
mainframe numbers derived from pubs with percent difference change from
previous generation (similar to most recent mainframe revenue, revenue
derived from percent change)
Early 90s:
eight processor ES/9000-982 : 408MIPS, 51MIPS/processor
RS6000/990 : 126MIPS; 16-way cluster: 2016MIPS, 128-way cluster:
16,128MIPS (16.128BIPS)
Then somerset/AIM (apple, ibm, motorola), power/pc single chip as well
as motorola 88k bus supporting cache consistency for multiprocessor.
i86/Pentium new generation where i86 instructions are hardware
translated to RISC micro-ops for actual execution (negating RISC system
advantage compared to i86).
1999 single IBM PowerPC 440 hits 1,000MIPS (>six times each Dec2000
z900 processor)
1999 single Pentium3 hits 2,054MIPS (twice PowerPC and 13times each
Dec2000 z900 processor).
Mainframe this century:
z900, 16 processors, 2.5BIPS (156MIPS/proc), Dec2000
z990, 32 processors, 9BIPS, (281MIPS/proc), 2003
z9, 54 processors, 18BIPS (333MIPS/proc), July2005
z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008
z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010
EC12, 101 processors, 75BIPS (743MIPS/proc), Aug2012
z13, 140 processors, 100BIPS (710MIPS/proc), Jan2015
z14, 170 processors, 150BIPS (862MIPS/proc), Aug2017
z15, 190 processors, 190BIPS (1000MIPS/proc), Sep2019
z16, 200 processors, 222BIPS (1111MIPS/proc), Sep2022
Note max configured z196 (& 50BIPS) went for $30M, at same time E5-2600
server blade (two 8core XEON & 500BIPS) had IBM base list price of $1815
(before industry press announced server chip vendors were shipping half
the product directly to cloud megadatacenters for assembly at 1/3rd
price of brand name systems, and IBM sells off server blade business)
Large cloud operations can have score of megadatacenters around the
world, each with half million or more server blades (2010 era
megadatacenter: processing equivalent around 5M max-configured z196
mainframes).
trivia, IBM early 80s, disk division hardware revunue slightly passed
high end mainframe division hardware revenue. Late 80s, senior disk
engineer got talk scheduled at annual, world-wide, internal
communication group conference, supposedly on 3174 performance but opens
the talk with statement that communication group was going to be
responsible for the demise of the disk division. The disk division was
seeing data fleeing mainframe datacenters to more distributed computing
friendly platforms, with drop in disk sales. The had come up with a
number of solutions but were constantly veoted by the communication
group (had corporate strategic responsibility for everything that
crossed datacenter walls and were fiercely fighting off client/server
and distributed computing).
The disk division software executive partial work around was investing
in distributed computing startups (who would use IBM disks, as well as
sponsored POSIX implementation for MVS). He would sometimes ask us to
visit his investment to see if we could provide any help.
Turns out communication group affecting the whole mainframe revenue and
couple years later, IBM has one of the largest losses in the history of
US corporations ... and IBM was being reorged into the 13 "baby blues"
(take off on "baby bells" in breakup a decade area) in preperation for
breakup
https://web.archive.org/web/20101120231857/http://www.time.c om/time/magazine/article/0,9171,977353,00.html
https://content.time.com/time/subscriber/article/0,33009,977 353-1,00.html
We had already left IBM but get a call from the bowels of Armonk (IBM
hdqtrs) asking if we could help with the breakup. Before we get started,
the board brings in the former AMEX president as CEO to try and save the
company, who (somewhat) reverses the breakup (although it wasn't long
before the disk division is gone).
Then IBM becomes a financial engineering company
Stockman; The Great Deformation: The Corruption of Capitalism in America
https://www.amazon.com/Great-Deformation-Corruption-Capitali sm-America-ebook/dp/B00B3M3UK6/
pg464/loc9995-10000: IBM was not the born-again growth machine trumpeted
by the mob of Wall Street momo traders. It was actually a stock buyback
contraption on steroids. During the five years ending in fiscal 2011,
the company spent a staggering $67 billion repurchasing its own shares,
a figure that was equal to 100 percent of its net income.
pg465/loc10014-17: Total shareholder distributions, including dividends,
amounted to $82 billion, or 122 percent, of net income over this
five-year period. Likewise, during the last five years IBM spent less on
capital investment than its depreciation and amortization charges, and
also shrank its constant dollar spending for research and development by
nearly 2 percent annually.
(2013) New IBM Buyback Plan Is For Over 10 Percent Of Its Stock
http://247wallst.com/technology-3/2013/10/29/new-ibm-buyback -plan-is-for-over-10-percent-of-its-stock/
(2014) IBM Asian Revenues Crash, Adjusted Earnings Beat On Tax Rate
Fudge; Debt Rises 20% To Fund Stock Buybacks (gone behind paywall)
https://web.archive.org/web/20140201174151/http://www.zerohe dge.com/news/2014-01-21/ibm-asian-revenues-crash-adjusted-ea rnings-beat-tax-rate-fudge-debt-rises-20-fund-st
The company has represented that its dividends and share repurchases
have come to a total of over $159 billion since 2000.
(2016) After Forking Out $110 Billion on Stock Buybacks, IBM Shifts Its
Spending Focus
https://www.fool.com/investing/general/2016/04/25/after-fork ing-out-110-billion-on-stock-buybacks-ib.aspx
(2018) ... still doing buybacks ... but will (now?, finally?, a little?)
shift focus needing it for redhat purchase.
https://www.bloomberg.com/news/articles/2018-10-30/ibm-to-bu y-back-up-to-4-billion-of-its-own-shares
(2019) IBM Tumbles After Reporting Worst Revenue In 17 Years As Cloud
Hits Air Pocket (gone behind paywall)
https://web.archive.org/web/20190417002701/https://www.zeroh edge.com/news/2019-04-16/ibm-tumbles-after-reporting-worst-r evenue-17-years-cloud-hits-air-pocket
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426667 is a reply to message #426666] |
Fri, 31 January 2025 20:31 |
John Levine
Messages: 1487
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Lynn Wheeler <lynn@garlic.com>:
> z15, 190 processors, 190BIPS (1000MIPS/proc), Sep2019
> z16, 200 processors, 222BIPS (1111MIPS/proc), Sep2022
>
> Note max configured z196 (& 50BIPS) went for $30M, at same time E5-2600
> server blade (two 8core XEON & 500BIPS) had IBM base list price of $1815
> (before industry press announced server chip vendors were shipping half
> the product directly to cloud megadatacenters for assembly at 1/3rd
> price of brand name systems, and IBM sells off server blade business)
I gather that a major reason one still uses a mainframe is databases and
in particular database locking. Whi;e the aggregate throughput of a lot
of blades may be more than a single mainframe, when you need to do database
updates it's a lot faster if the updates are in one place rather than
trying to synchronize a lot of loosely coupled systems. On that 200
processor z16, you can do a CAS on one processor and the other 199
will see it consistently.
I realize there are ways around this, sharding and such, but there's good
reasons that the reading parts of database applications are widely
distributed while the writing parts are not.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426668 is a reply to message #426667] |
Fri, 31 January 2025 22:38 |
Anne & Lynn Wheel
Messages: 3254
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> I gather that a major reason one still uses a mainframe is databases and
> in particular database locking. Whi;e the aggregate throughput of a lot
> of blades may be more than a single mainframe, when you need to do database
> updates it's a lot faster if the updates are in one place rather than
> trying to synchronize a lot of loosely coupled systems. On that 200
> processor z16, you can do a CAS on one processor and the other 199
> will see it consistently.
>
> I realize there are ways around this, sharding and such, but there's good
> reasons that the reading parts of database applications are widely
> distributed while the writing parts are not.
Some of this left over from mid-90s where billions were spent on
rewritting mainframe financial systems that queued real time
transactions for processing during overnight batch settlement windows
(many from the 60s&70s) ... to straight-through processing using large
number of parallelized killer micros. Some of us pointed out that they
were using industry standard parallelization libraries that had hundred
times the overhead of mainframe cobol batch ... ignored until their
pilots went down in flames (retrenching to the existing status quo).
A major change was combination of 1) major RDBMS vendors (including IBM)
did significiant throughput performance work on cluster RDBMS, 2)
implementations done with fine-grain SQL statements that were highly
parallelized (rather than RYO implementation parallelization), and 3)
non-mainframe systems having significantly higher throughput.
2022 z16 200 processors shared memory multiprocessor and aggregate
222BIPS (1.11BIPS/processor) compared to (single blade) 2010 e5-2600 16
processors shared memory multiprocessor and aggregate 500BIPS
(31BIPS/processor) ... 2010 E5-2600 systen ten times 2022 z16 (2010
e5-2600 processor 30 times 2022 z16 processor). 2010 E5-2600 could have
up to eight processors (with aggregate throughput more than 2022 200
processor z16) sharing cache (w/o going all the way to memory).
When I has doing HA/CMP ... it originally started out HA/6000 for
NYTimes to move their newspaper system (ATEX) off DEC VAXCluster to
RS/6000. I rename it HA/CMP when start doing cluster scaleup with
national labs and RDBMS vendors (oracle, sybase, ingres, informix) that
had VAXCluster in same source base with UNIX.
I did distributed lock manager that emulated VAXCluster DLI semantics
.... but with a lot of enhancements. RDBMS had been doing cluster with
logging and lazy writes to home location ... however when write lock had
to move to a different system ... they had to force any pending
associated write to RDBMS "home" location ... the system receiving the
lock then would read the latest value from disk. Since I would be using
gbit+ links, I did a DLI that could transmit both the lock ownership as
well as the latest record(s) (avoiding the immediate disk write followed
by immediate disk read on different system). Failures would recover from
log records updating RDBMS "home" records.
However, still prefer to have transaction routing to processor
(processor and/or cache affinity) holding current lock ... this is the
observation that cache miss (all the main storage) when measured in
count of processor cycles ... is similar to 60s disk latency when
measured in 60s processor cycles (if purely for throughput).
I had also coined the terms "disaster survivability" and "geographically
survivability" when out marketing HA/CMP ... so more processing for
coordinate data at replicated distributed locations. Jim Gray's study of
availability outages were increasingly shifting to human mistakes and
environmental (as hardware was becoming increasingly reliable, I had worked
with Jim Gray on System/R before he left IBM SJR for Tandem fall81).
https://www.garlic.com/~lynn/grayft84.pdf
'85 paper
https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers /gray85-easy.pdf
https://web.archive.org/web/20080724051051/http://www.cs.ber keley.edu/~yelick/294-f00/papers/Gray85.txt
In 1988, the IBM branch asks if i could help LLNL (national lab) with
standardization of some serial stuff they were working with, which
quickly becomes fibre standard channel (FCS, initially 1gbit/sec
transfer, full-duplex, aggregate 200Mbytes/sec, including some stuff I
had done in 1980). POK ships their fiber stuff in 1990 with ES/9000 as
ESCON (when it was already obsolete, 17mbytes/sec). Then some POK
engineers become involved with FCS and define heavy weight protocol that
significantly reduces throughput, ships as "FICON"
Latest public benchmark I could find was (2010) z196 "Peak I/O" getting
2M IOPS using 104 FICON. About the same time a "FCS" was announced for
E5-2600 server blade claimining over million IOPS (two such FCS would
have higher throughput than 104 FICON ... that run over FCS). Also, IBM
pubs recommend that SAPs (system assist proceessors that actually do
I/O) be kept to 70% CPU ... which would be more like 1.5M IOPS. Also no
CKD DASD have been made for decades, all being simulated on industry
standard fixed-block disks.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426672 is a reply to message #426667] |
Sat, 01 February 2025 11:59 |
|
|
Originally posted by: OrangeFish
On 2025-01-31 20:31, John Levine wrote (in part):
[...]
> I gather that a major reason one still uses a mainframe is databases and
> in particular database locking. Whi;e the aggregate throughput of a lot
> of blades may be more than a single mainframe, when you need to do database
> updates it's a lot faster if the updates are in one place rather than
> trying to synchronize a lot of loosely coupled systems. On that 200
> processor z16, you can do a CAS on one processor and the other 199
> will see it consistently.
>
> I realize there are ways around this, sharding and such, but there's good
> reasons that the reading parts of database applications are widely
> distributed while the writing parts are not.
Speaking of mainframes, Dave's Garage has an interesting video of the
IBM factory: https://www.youtube.com/watch?v=ouAG4vXFORc
OF.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426673 is a reply to message #426672] |
Sat, 01 February 2025 13:35 |
scott
Messages: 4380
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
OrangeFish <OrangeFish@invalid.invalid> writes:
> On 2025-01-31 20:31, John Levine wrote (in part):
> [...]
>> I gather that a major reason one still uses a mainframe is databases and
>> in particular database locking. Whi;e the aggregate throughput of a lot
>> of blades may be more than a single mainframe, when you need to do database
>> updates it's a lot faster if the updates are in one place rather than
>> trying to synchronize a lot of loosely coupled systems. On that 200
>> processor z16, you can do a CAS on one processor and the other 199
>> will see it consistently.
>>
>> I realize there are ways around this, sharding and such, but there's good
>> reasons that the reading parts of database applications are widely
>> distributed while the writing parts are not.
>
> Speaking of mainframes, Dave's Garage has an interesting video of the
> IBM factory: https://www.youtube.com/watch?v=ouAG4vXFORc
>
Burroughs B6500 factory:
https://www.youtube.com/watch?v=rNBtjEBYFPk
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426674 is a reply to message #426624] |
Sat, 01 February 2025 14:08 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> Lynn Wheeler <lynn@garlic.com> writes:
>
>> however, all 3270s were half-duplex and if you were unfortunate to hit a
>> key same time system went to write to screen, it would lock the keyboard
>> and would have to stop and hit the reset key. YKT developed a FIFO box
>> for 3277, unplug the keyboard from the 3277 head, plug the FIFO box into
>> the head and plug the 3277 keyboard into the fifo box ... eliminating
>> the unfortunate keyboad lock.
>
> Back in the late 60s I finished implementing my first online system on a
> S/360-30 and IBM 2260s.
>
> Then my boss came in with the manuals for the IBM 3270s.
> He wanted my opinion on the terminals.
> I read the manual and told my boss they were unnecessary complicated
> crap.
>
> Over the years I did lots of stuff with 3270s. I never changed my mind.
>
> One project I did was using Bunker Ramo 3270 compatible terminals.
> By mistake I wrote some code that put more than 80 characters on a line.
> The Bunker Ramo CRT just squeezed the text a bit. If I recall you could
> put around 120 characters on a line and still read the display.
>
I loved 3270s. I never coded anything for 2260s, but the whole design was a
kludge.I did a lot with 3270 BMS and raw data stream, and i still miss
using them.
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426675 is a reply to message #426627] |
Sat, 01 February 2025 14:08 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 30 Jan 2025 19:45:05 -0000 (UTC), John Levine wrote:
>
>> You'd use it for the same reason you'd use any other mainframe,
>> extremely high reliability with uptime measured in years and sometimes
>> decades. They can swap out entire hardware subsystems without
>> rebooting.
>
> That’s all a complete myth.
>
> There is an article from 1986 on Bitsavers, talking about maintaining
> correct time on IBM mainframes. It recommends rebooting to turn daylight
> saving on and off.
>
40 year old article.
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426676 is a reply to message #426629] |
Sat, 01 February 2025 14:08 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 30 Jan 2025 10:12:15 -0500, Dan Espen wrote:
>
>> ... I wouldn't call z/OS an emulation layer. It looked and acted like a
>> Unix implementation.
>
> Not a very good one, by your own admission:
>
>> One a mainframe, there are a few issues to deal with to run Unix.
>> The common use terminal, a 3270 is not character at a time, data is
>> transferred in blocks with a pretty complex protocol. z/OS unix
>> couldn't do things like run Emacs on a 3270 but it did a reasonably good
>> job of providing a working stdin/stdout.
>
> Couldn’t even run Emacs?? What kind of “Unix” is this?
What the frack is Emacs? I’ve been using forms for unix for decades, and
have managed to avoid it so far.
>
>> Another issue is the native disk file system where data is read in
>> blocks with predefined block sizes. z/OS Unix also did a pretty good
>> job with this.
>
> What did “pretty good job” mean, exactly? Could it reliably and
> efficiently handle files with sizes that were not an exact multiple of
> some block size, or not?
>
> How efficiently could it fork multiple processes?
>
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426677 is a reply to message #426654] |
Sat, 01 February 2025 14:08 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> wrote:
> According to Bob Eager <news0009@eager.cx>:
>> On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
>>
>>>> > IBM is still selling mainframe hardware.
>>>>
>>>> I doubt they’re making any profit on it any more.
>>>
>>> That's something you could look up for yourself.
>>
>> I understand that all the profit has been in software, for many years.
>
> IBM continues to put a lot of effort into their mainframe hardware. If
> you look at their financial reports, they usually have a bullet for "IBM Z"
> which is up some quarters, down others. The most recent slide deck has a
> bullet that says:
>
> z16 our most successful program in history
>
> I agree that mainframes is a legacy business but it's one that still has
> a long life aheade it it.
>
No one is going to watch to convert 60 years of production software to
another platform. Actually, i take that back. It’s been tried, but never
successfully.
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426678 is a reply to message #426659] |
Sat, 01 February 2025 14:08 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> If you haven’t completely depreciated all that by now, then you’re
>>> probably out of business or heading that way.
>>
>> I'm sorry, "depreciated"?
>> What are you talking about?
>
> You know, one of those amounts you offset against gross income to come up
> with net profit (or loss).
>
> Or, if you want it in simpler terms, “written off”.
>
>> There are people running their businesses with their software.
>
> Computing needs have changed a lot. COBOL was designed for the batch era.
> We no longer operate our businesses in the batch era.
>
Ever heard of CICS?
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426679 is a reply to message #426664] |
Sat, 01 February 2025 14:08 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Scott Lurndal <scott@slp53.sl.home> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Fri, 31 Jan 2025 09:44:31 -0800, John Ames wrote:
>>
>>> On Fri, 31 Jan 2025 06:33:03 -0000 (UTC) Lawrence D'Oliveiro
>>> <ldo@nz.invalid> wrote:
>>>
>>>> >> How efficiently could it fork multiple processes?
>>>> >
>>>> > Never saw a problem with that.
>>>>
>>>> Somehow I doubt you tested it very heavily.
>>>
>>> What's your basis for that assertion?
>
>>
>> The idea that a mainframe system, of all things, could handle process
>> creation efficiently, is laughable.
>
> More ravings from a troll who has never even used a mainframe
> operating system, much less actually written one.
>
> Process creation on Burroughs mainframes was certainly
> competitive with fork[*]. I speak from experience on both
> ends (having written both mainframe operating systems
> and an unix-compatible MPP operating system (specifically responsible
> for the process create and management code). I have
> patents related to the latter.
>
> [*] In fact, the algol (MCP flavor) routine to create a
> new process on the Burroughs Large systems was actually
> named 'motherforker'. On Medium systems, the early MCP
> function that created a new context was called 'hiho'. As
> in Hi-Ho, Hi-Ho, it's off to work we go.
>
Burroughs naming was always creative, rivaled only by SDS/XDS.
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426680 is a reply to message #426662] |
Sat, 01 February 2025 14:55 |
jgd
Messages: 59
Registered: May 2013
Karma: 0
|
Member |
|
|
In article <vnjfai$3mhvf$4@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
> Back in 1980, there were something like 10 different companies
> operating in the mainframe business. Now there is only one.
Nope. IBM is the market leader, sure. In Japan, Fujitsu and Hitachi
continue to sell IBM-like 31-bit mainframes, and NEC sells a proprietary
mainframe. The ex-Univac OS 2200, ex-Burroughs MCP, Groupe Bull GCOS,
ex-Siemens BS2000 and ex-ICL VME are all still used, mostly under
emulation.
Yes, the mainframe business is shrinking, but it will be around for
decades yet.
John
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426681 is a reply to message #426676] |
Sat, 01 February 2025 14:49 |
Dan Espen
Messages: 3899
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Thu, 30 Jan 2025 10:12:15 -0500, Dan Espen wrote:
>>
>>> ... I wouldn't call z/OS an emulation layer. It looked and acted like a
>>> Unix implementation.
>>
>> Not a very good one, by your own admission:
>>
>>> One a mainframe, there are a few issues to deal with to run Unix.
>>> The common use terminal, a 3270 is not character at a time, data is
>>> transferred in blocks with a pretty complex protocol. z/OS unix
>>> couldn't do things like run Emacs on a 3270 but it did a reasonably good
>>> job of providing a working stdin/stdout.
>>
>> Couldn’t even run Emacs?? What kind of “Unix” is this?
>
> What the frack is Emacs? I’ve been using forms for unix for decades, and
> have managed to avoid it so far.
Emacs was just an example. vi would also not run.
Anything that needed to react to a single character being typed would
not run.
A 3270 only transfers data when you hit enter, a PK key, hit attention,
just a few select keys.
The async terminals normally only react when you hit enter, (which
transmits a line), but they can be put in raw mode where the host
sees every character typed. The full screen editors rely on this.
--
Dan Espen
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426682 is a reply to message #426681] |
Sat, 01 February 2025 16:49 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Thu, 30 Jan 2025 10:12:15 -0500, Dan Espen wrote:
>>>
>>>> ... I wouldn't call z/OS an emulation layer. It looked and acted like a
>>>> Unix implementation.
>>>
>>> Not a very good one, by your own admission:
>>>
>>>> One a mainframe, there are a few issues to deal with to run Unix.
>>>> The common use terminal, a 3270 is not character at a time, data is
>>>> transferred in blocks with a pretty complex protocol. z/OS unix
>>>> couldn't do things like run Emacs on a 3270 but it did a reasonably good
>>>> job of providing a working stdin/stdout.
>>>
>>> Couldn’t even run Emacs?? What kind of “Unix” is this?
>>
>> What the frack is Emacs? I’ve been using forms for unix for decades, and
>> have managed to avoid it so far.
>
> Emacs was just an example. vi would also not run.
> Anything that needed to react to a single character being typed would
> not run.
>
> A 3270 only transfers data when you hit enter, a PK key, hit attention,
> just a few select keys.
>
> The async terminals normally only react when you hit enter, (which
> transmits a line), but they can be put in raw mode where the host
> sees every character typed. The full screen editors rely on this.
>
I always thought that this was a tremendously wasteful scheme, generating
tons of interrupts instead of only one or two. As I said, I liked the 3270,
I thought ISPF was one of the best editors I’ve ever used. Now my Linux
editor is the closest I could find to ISPF, but there are still features I
miss. I’ve thought of adding a Rexx interface, but it’s a ways down in my
priority list.
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426683 is a reply to message #426682] |
Sat, 01 February 2025 17:05 |
Dan Espen
Messages: 3899
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> On Thu, 30 Jan 2025 10:12:15 -0500, Dan Espen wrote:
>>>>
>>>> > ... I wouldn't call z/OS an emulation layer. It looked and acted like a
>>>> > Unix implementation.
>>>>
>>>> Not a very good one, by your own admission:
>>>>
>>>> > One a mainframe, there are a few issues to deal with to run Unix.
>>>> > The common use terminal, a 3270 is not character at a time, data is
>>>> > transferred in blocks with a pretty complex protocol. z/OS unix
>>>> > couldn't do things like run Emacs on a 3270 but it did a reasonably good
>>>> > job of providing a working stdin/stdout.
>>>>
>>>> Couldn’t even run Emacs?? What kind of “Unix” is this?
>>>
>>> What the frack is Emacs? I’ve been using forms for unix for decades, and
>>> have managed to avoid it so far.
>>
>> Emacs was just an example. vi would also not run.
>> Anything that needed to react to a single character being typed would
>> not run.
>>
>> A 3270 only transfers data when you hit enter, a PK key, hit attention,
>> just a few select keys.
>>
>> The async terminals normally only react when you hit enter, (which
>> transmits a line), but they can be put in raw mode where the host
>> sees every character typed. The full screen editors rely on this.
>
> I always thought that this was a tremendously wasteful scheme, generating
> tons of interrupts instead of only one or two. As I said, I liked the 3270,
> I thought ISPF was one of the best editors I’ve ever used. Now my Linux
> editor is the closest I could find to ISPF, but there are still features I
> miss. I’ve thought of adding a Rexx interface, but it’s a ways down in my
> priority list.
IBM thought it wasteful too, that's why they developed all that block
mode stuff. It's still pretty cool to be able to hit one key and have
stuff happen.
No argument from me about ISPF edit. It's pretty neat.
Still, when I was given the choice, I did all my mainframe editing on my
Linux box.
--
Dan Espen
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426684 is a reply to message #426683] |
Sat, 01 February 2025 17:15 |
scott
Messages: 4380
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> Dan Espen <dan1espen@gmail.com> wrote:
>>> Peter Flass <peter_flass@yahoo.com> writes:
>>>
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> > On Thu, 30 Jan 2025 10:12:15 -0500, Dan Espen wrote:
>>>> >
>>>> >> ... I wouldn't call z/OS an emulation layer. It looked and acted like a
>>>> >> Unix implementation.
>>>> >
>>>> > Not a very good one, by your own admission:
>>>> >
>>>> >> One a mainframe, there are a few issues to deal with to run Unix.
>>>> >> The common use terminal, a 3270 is not character at a time, data is
>>>> >> transferred in blocks with a pretty complex protocol. z/OS unix
>>>> >> couldn't do things like run Emacs on a 3270 but it did a reasonably good
>>>> >> job of providing a working stdin/stdout.
>>>> >
>>>> > Couldn’t even run Emacs?? What kind of “Unix” is this?
>>>>
>>>> What the frack is Emacs? I’ve been using forms for unix for decades, and
>>>> have managed to avoid it so far.
>>>
>>> Emacs was just an example. vi would also not run.
>>> Anything that needed to react to a single character being typed would
>>> not run.
>>>
>>> A 3270 only transfers data when you hit enter, a PK key, hit attention,
>>> just a few select keys.
>>>
>>> The async terminals normally only react when you hit enter, (which
>>> transmits a line), but they can be put in raw mode where the host
>>> sees every character typed. The full screen editors rely on this.
>>
>> I always thought that this was a tremendously wasteful scheme, generating
>> tons of interrupts instead of only one or two. As I said, I liked the 3270,
>> I thought ISPF was one of the best editors I’ve ever used. Now my Linux
>> editor is the closest I could find to ISPF, but there are still features I
>> miss. I’ve thought of adding a Rexx interface, but it’s a ways down in my
>> priority list.
>
> IBM thought it wasteful too, that's why they developed all that block
> mode stuff. It's still pretty cool to be able to hit one key and have
> stuff happen.
Burroughs also used, primarily, block-mode terminals. Teletypes were
supported (the I/O controller collected 'lines' and transferred them
to the host). Data Communications processors had line control modules
that supported async (e.g. tty, modem) and sync (block-mode, multidrop)
terminals which would packet up the transmission and pass it to the host
MCS which would route the transmission to the appropriate program for
handling (using read-only screen fields to route).
None of those block mode editors can be compared with vim or emacs
from a usability or functionality standpoint.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426686 is a reply to message #426677] |
Sat, 01 February 2025 19:58 |
|
|
Originally posted by: antispam
Peter Flass <peter_flass@yahoo.com> wrote:
> John Levine <johnl@taugh.com> wrote:
>> According to Bob Eager <news0009@eager.cx>:
>>> On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
>>>
>>>> >> IBM is still selling mainframe hardware.
>>>> >
>>>> > I doubt they’re making any profit on it any more.
>>>>
>>>> That's something you could look up for yourself.
>>>
>>> I understand that all the profit has been in software, for many years.
>>
>> IBM continues to put a lot of effort into their mainframe hardware. If
>> you look at their financial reports, they usually have a bullet for "IBM Z"
>> which is up some quarters, down others. The most recent slide deck has a
>> bullet that says:
>>
>> z16 our most successful program in history
>>
>> I agree that mainframes is a legacy business but it's one that still has
>> a long life aheade it it.
>>
>
> No one is going to watch to convert 60 years of production software to
> another platform. Actually, i take that back. It’s been tried, but never
> successfully.
I think that there were a lot of successful migrations from
mainframes to other systems. It is likely that most succesful
cases were gradual, taking substantial time.
In Poland during comunist times one of basic machines were
domesticaly produced ICL-1900 compatible machines, using ICL
operating system. It seems that our manufacturer of those
machines stopped production around 1990 (and during eighties
production was decreasing). For few years alternative
manufacturer offered compatible machines using bit-slice
microprocessors. Few years ago supposedly last machine
of this family was decomissioned (it was used by railway
as part of trafic control).
So, it is basically question of time and financial balance:
currently mainframe users pay higer prices to mainframe
vendors so that users can keep using their systems and
avoid migration. But as user population shrinks it may
become too small to adequatly support vendors. That may
force vendors to limit their offer leading to colapse:
limited vendor offer accelerates migration. That seem
to happened with several smaller vendors. IBM-compatible
world currently looks relatively healthy, but it is not
clear for how long. I expect at least 10 more years of use
of IBM-compatible mainframes, but it is hard to make
prediction for longer time. 10 years may look like
long time, but it is short compared to 60 year history.
--
Waldek Hebisch
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426687 is a reply to message #426675] |
Sat, 01 February 2025 20:09 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Sat, 1 Feb 2025 12:08:42 -0700, Peter Flass wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Thu, 30 Jan 2025 19:45:05 -0000 (UTC), John Levine wrote:
>>
>>> You'd use it for the same reason you'd use any other mainframe,
>>> extremely high reliability with uptime measured in years and sometimes
>>> decades. They can swap out entire hardware subsystems without
>>> rebooting.
>>
>> That’s all a complete myth.
>>
>> There is an article from 1986 on Bitsavers, talking about maintaining
>> correct time on IBM mainframes. It recommends rebooting to turn
>> daylight saving on and off.
>>
> 40 year old article.
That was from the heyday of mainframes, don’t forget.
You think they’ve improved since then?
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426688 is a reply to message #426677] |
Sat, 01 February 2025 20:11 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Sat, 1 Feb 2025 12:08:44 -0700, Peter Flass wrote:
> No one is going to watch to convert 60 years of production software to
> another platform. Actually, i take that back. It’s been tried, but never
> successfully.
More likely the company that is chained to that mainframe albatross goes
out of business, and its systems get junked instead of converted.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426689 is a reply to message #426665] |
Sat, 01 February 2025 20:13 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Fri, 31 Jan 2025 14:26:40 -0800, John Ames wrote:
> On Fri, 31 Jan 2025 21:30:10 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>>> What's your basis for that assertion?
>>
>> It’s well known that the Unix creation-of-lots-of-processes model plays
>> poorly with every single proprietary OS out there.
>>
>> The idea that a mainframe system, of all things, could handle process
>> creation efficiently, is laughable.
>
> So your basis for casting doubt on his specific attestation of personal
> experience is "everybody knows?"
In the absence of more detail being supplied, that is the logical
conclusion.
Here another example of something needing clarification: the POSIX fork(2)
call requires the child process to share the same open file descriptions
as the parent.
Name one proprietary (non-*nix) OS that manages to emulate that
successfully.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426690 is a reply to message #426682] |
Sat, 01 February 2025 20:17 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Sat, 1 Feb 2025 14:49:51 -0700, Peter Flass wrote:
> I always thought that this was a tremendously wasteful scheme,
> generating tons of interrupts instead of only one or two.
That’s the mainframe batch mentality speaking.
Yes, it was tremendously wasteful of computer time. But it was a key
factor in improving productivity of the human users. That’s why companies
like DEC, which sold hardware+software systems that were designed from the
ground up to operate in such a mode, were so successful.
IBM could never compete with them on the quality of its products.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426691 is a reply to message #426667] |
Sat, 01 February 2025 20:20 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Sat, 1 Feb 2025 01:31:37 -0000 (UTC), John Levine wrote:
> I gather that a major reason one still uses a mainframe is databases and
> in particular database locking.
Ironic, actually, but no. You think a modern company like Facebook runs
its main system on a mainframe, using some proprietary mainframe DBMS? No,
it uses MySQL/MariaDB with other pieces like memcached, plus code written
in its home-grown PHP engine (open-sourced as HHVM), and also some back-
end Python (that we know of).
The irony is that COBOL, the “business-oriented” language traditionally
associated with mainframes, never quite got to grips with databases.
Accessing them was always a kludge.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426692 is a reply to message #426688] |
Sat, 01 February 2025 22:04 |
|
|
Originally posted by: Lars Poulsen
On Sat, 1 Feb 2025 12:08:44 -0700, Peter Flass wrote:
>> No one is going to watch to convert 60 years of production software to
>> another platform. Actually, i take that back. It’s been tried, but never
>> successfully.
On 2025-02-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> More likely the company that is chained to that mainframe albatross goes
> out of business, and its systems get junked instead of converted.
I Denmark, the main users of mainframes are:
- all the banks
- state tax administration
- motor vehicle registry
They will not go out of business.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426693 is a reply to message #426692] |
Sat, 01 February 2025 22:13 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Sun, 2 Feb 2025 03:04:25 -0000 (UTC), Lars Poulsen wrote:
> On 2025-02-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> More likely the company that is chained to that mainframe albatross
>> goes out of business, and its systems get junked instead of converted.
>
> I Denmark, the main users of mainframes are:
> - all the banks
> - state tax administration
> - motor vehicle registry
I can imagine the last two could just about manage on batch operations,
but the banks cannot. Otherwise they cannot handle online transactions
which require pretty much instant updates.
Do you still have cheques in 🇩🇰? We don’t in 🇳🇿.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426694 is a reply to message #426683] |
Sat, 01 February 2025 22:21 |
John Levine
Messages: 1487
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
It appears that Dan Espen <dan1espen@gmail.com> said:
>>> A 3270 only transfers data when you hit enter, a PK key, hit attention,
>>> just a few select keys.
>>>
>>> The async terminals normally only react when you hit enter, (which
>>> transmits a line), but they can be put in raw mode where the host
>>> sees every character typed. The full screen editors rely on this.
>>
>> I always thought that this was a tremendously wasteful scheme, generating
>> tons of interrupts instead of only one or two. ...
It just changes where you put your hardware. On minicomputers with lightweight
interupts, it makes sense to make the controller simpler and do the character
buffering in the computer. As an extreme example, DEC's 680 TTY interface
took an interrupt not for each character, but for each bit on a serial line,
a total of 10 or 11 bits including start/stop. For 110 baud TTYs it worked
great, attaching a bunch of terminals with very little hardware. A PDP-8
was fast enough that it could do that and also run TSS-8, a nice little
timesharing system that gave everone a virtual PDP-8.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426696 is a reply to message #426683] |
Sun, 02 February 2025 01:03 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Sat, 01 Feb 2025 17:05:35 -0500, Dan Espen wrote:
> IBM thought it wasteful too, that's why they developed all that block
> mode stuff.
No matter how clever and complicated (and expensive) their terminals were,
it could never make up for the versatility of putting every keystroke
under software control.
> Still, when I was given the choice, I did all my mainframe editing on my
> Linux box.
Which proves my point.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426697 is a reply to message #426684] |
Sun, 02 February 2025 01:09 |
Charlie Gibbs
Messages: 5563
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2025-02-01, Scott Lurndal <scott@slp53.sl.home> wrote:
> Burroughs also used, primarily, block-mode terminals.
Univac did as well. A good editor would present you with
a screenful of data; you could edit it using the terminal's
built-in features (insert, delete, or overwrite characters
or lines) and send the updated screenful of data back to
the mainframe. It wasn't a full character-by-character
response, but it was tolerable.
I ported Adventure and Dungeon to OS/3; one of the most
difficult tasks was getting terminal I/O to work properly.
--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426698 is a reply to message #426697] |
Sun, 02 February 2025 07:24 |
|
|
Originally posted by: Bob Eager
On Sun, 02 Feb 2025 06:09:51 +0000, Charlie Gibbs wrote:
> On 2025-02-01, Scott Lurndal <scott@slp53.sl.home> wrote:
>
>> Burroughs also used, primarily, block-mode terminals.
>
> Univac did as well. A good editor would present you with a screenful of
> data; you could edit it using the terminal's built-in features (insert,
> delete, or overwrite characters or lines) and send the updated screenful
> of data back to the mainframe. It wasn't a full character-by-character
> response, but it was tolerable.
>
> I ported Adventure and Dungeon to OS/3; one of the most difficult tasks
> was getting terminal I/O to work properly.
The operating system I helped to support for some years handled terminal
I/O in a PDP-11 used as a front end processor (sometimes more than one).
Characters were sent via an interface that used single characters or not,
as needed.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426699 is a reply to message #426686] |
Sun, 02 February 2025 07:28 |
|
|
Originally posted by: Bob Eager
On Sun, 02 Feb 2025 00:58:36 +0000, Waldek Hebisch wrote:
> In Poland during comunist times one of basic machines were domesticaly
> produced ICL-1900 compatible machines, using ICL operating system. It
> seems that our manufacturer of those machines stopped production around
> 1990 (and during eighties production was decreasing). For few years
> alternative manufacturer offered compatible machines using bit-slice
> microprocessors. Few years ago supposedly last machine of this family
> was decomissioned (it was used by railway as part of trafic control).
ICL were still selling 1900 compatibility (in two different forms) well
into the 1980s. Plus hardware that was essentially a 1900, but branded
differently.
This was on their 2900 series. One was Direct Machine Environment (DME)
where the machine was effectively a 1900. The other was mixed, where the
machine switched dynamically between 1900 and 2900 mode (it could also do
LEO and System 4 if required).
All of the machines were microcoded; I have seen quite a bit of the
microcode. It's the only time I have seen microcode overlaid (from main
memory).
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426701 is a reply to message #426693] |
Sun, 02 February 2025 08:59 |
|
|
Originally posted by: Lars Poulsen
On 2025-02-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 2 Feb 2025 03:04:25 -0000 (UTC), Lars Poulsen wrote:
>
>> On 2025-02-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> More likely the company that is chained to that mainframe albatross
>>> goes out of business, and its systems get junked instead of converted.
>>
>> I Denmark, the main users of mainframes are:
>> - all the banks
>> - state tax administration
>> - motor vehicle registry
>
> I can imagine the last two could just about manage on batch operations,
> but the banks cannot. Otherwise they cannot handle online transactions
> which require pretty much instant updates.
>
> Do you still have cheques in 🇩🇰? We don’t in 🇳🇿.
Denmark did away with checks a decade ago, and is headed towards
eliminating cash as well. Think 6-year olds with debit cards for their
allowances.
Here in the US, we still use checks. In fact, when I am moving money
between banks, I go into my branch of the big national bank, get a
cashier's check for some multiple of USD 50 000 and hand carry it to my
branch of the small regional bank to deposit it there.
If I were to do the transfer electronically, it would cost about USD 30,
and take about 36 hours before the money was available in the new
account. Doing it my way, it is free and the money is available when I
leave the branch.
The USA is stuck in the past, waxing nostalgic for the golden days of
the 1950s. And rapidly becoming a lawless 3rd world country.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426702 is a reply to message #426694] |
Sun, 02 February 2025 09:07 |
|
|
Originally posted by: Lars Poulsen
It appears that Dan Espen <dan1espen@gmail.com> said:
>>>> A 3270 only transfers data when you hit enter, a PK key, hit attention,
>>>> just a few select keys.
>>>>
>>>> The async terminals normally only react when you hit enter, (which
>>>> transmits a line), but they can be put in raw mode where the host
>>>> sees every character typed. The full screen editors rely on this.
>>>
>>> I always thought that this was a tremendously wasteful scheme, generating
>>> tons of interrupts instead of only one or two. ...
The IBM 3270 scheme was very efficient for CICS transaction processing,
offloading memory for both multi-step transaction context and queueing
at peak load to the terminal network.
The context could be held in non-displaying data fields in the terminal
screen buffer, so that each incremental step in the conversation could
be processed independently. And since terminals only transmitted when
polled, any backlogged transactions never got into the mainframe memory,
but stayed in the terminal until it could be processed. So at peak
times, response times went up, buteverything kept running within
available capacity.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426703 is a reply to message #426691] |
Sun, 02 February 2025 10:43 |
jgd
Messages: 59
Registered: May 2013
Karma: 0
|
Member |
|
|
In article <vnmh9e$butt$6@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
> On Sat, 1 Feb 2025 01:31:37 -0000 (UTC), John Levine wrote:
>> I gather that a major reason one still uses a mainframe is
>> databases and in particular database locking.
>
> Ironic, actually, but no. You think a modern company like Facebook
> runs its main system on a mainframe, using some proprietary
> mainframe DBMS? No, it uses MySQL/MariaDB with other pieces like
> memcached, plus code written in its home-grown PHP engine
> (open-sourced as HHVM), and also some back-end Python (that we
> know of).
Facebook has quite different synchronisation requirements from a credit
card provider. It doesn't matter to FB if updates to the page someone is
looking at arrive take a few seconds to arrive.
Speed of synchronisation matters a lot to a credit card provider who is
trying to enforce customer credit limits and avoid double-spends. They
still use mainframes with z/TPF for that. z/TPF is a curious OS; it
essentially makes a mainframe into a single real-time transaction
processing system.
John
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426704 is a reply to message #426683] |
Sun, 02 February 2025 12:56 |
Harry Vaderchi
Messages: 772
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 01 Feb 2025 17:05:35 -0500
Dan Espen <dan1espen@gmail.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> Dan Espen <dan1espen@gmail.com> wrote:
>>> Peter Flass <peter_flass@yahoo.com> writes:
>>>
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> > On Thu, 30 Jan 2025 10:12:15 -0500, Dan Espen wrote:
>>>> >
>>>> >> ... I wouldn't call z/OS an emulation layer. It looked and acted like a
>>>> >> Unix implementation.
>>>> >
>>>> > Not a very good one, by your own admission:
>>>> >
>>>> >> One a mainframe, there are a few issues to deal with to run Unix.
>>>> >> The common use terminal, a 3270 is not character at a time, data is
>>>> >> transferred in blocks with a pretty complex protocol. z/OS unix
>>>> >> couldn't do things like run Emacs on a 3270 but it did a reasonably good
>>>> >> job of providing a working stdin/stdout.
>>>> >
>>>> > Couldn’t even run Emacs?? What kind of “Unix” is this?
>>>>
>>>> What the frack is Emacs? I’ve been using forms for unix for decades, and
>>>> have managed to avoid it so far.
>>>
>>> Emacs was just an example. vi would also not run.
>>> Anything that needed to react to a single character being typed would
>>> not run.
>>>
>>> A 3270 only transfers data when you hit enter, a PK key, hit attention,
>>> just a few select keys.
>>>
>>> The async terminals normally only react when you hit enter, (which
>>> transmits a line), but they can be put in raw mode where the host
>>> sees every character typed. The full screen editors rely on this.
>>
>> I always thought that this was a tremendously wasteful scheme, generating
>> tons of interrupts instead of only one or two. As I said, I liked the 3270,
>> I thought ISPF was one of the best editors I’ve ever used. Now my Linux
>> editor is the closest I could find to ISPF, but there are still features I
>> miss. I’ve thought of adding a Rexx interface, but it’s a ways down in my
>> priority list.
>
> IBM thought it wasteful too, that's why they developed all that block
> mode stuff. It's still pretty cool to be able to hit one key and have
> stuff happen.
>
> No argument from me about ISPF edit. It's pretty neat.
> Still, when I was given the choice, I did all my mainframe editing on my
> Linux box.
Back in the day, I was involved, (as a junior) in a project to "integrate"
Pcs and mainframes; - in the limited sense of a (Cobol) DevShop using PCs
for editing programs and testing (pseudo-transparently) via mainframe
compilers.
We didn't really foresee beyond offloading mainframe development load.
--
Bah, and indeed Humbug.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426705 is a reply to message #426686] |
Sun, 02 February 2025 13:04 |
Harry Vaderchi
Messages: 772
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 2 Feb 2025 00:58:36 -0000 (UTC)
antispam@fricas.org (Waldek Hebisch) wrote:
> Peter Flass <peter_flass@yahoo.com> wrote:
>> John Levine <johnl@taugh.com> wrote:
>>> According to Bob Eager <news0009@eager.cx>:
>>>> On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
>>>>
>>>> >>> IBM is still selling mainframe hardware.
>>>> >>
>>>> >> I doubt they’re making any profit on it any more.
>>>> >
>>>> > That's something you could look up for yourself.
>>>>
>>>> I understand that all the profit has been in software, for many years.
>>>
>>> IBM continues to put a lot of effort into their mainframe hardware. If
>>> you look at their financial reports, they usually have a bullet for "IBM Z"
>>> which is up some quarters, down others. The most recent slide deck has a
>>> bullet that says:
>>>
>>> z16 our most successful program in history
>>>
>>> I agree that mainframes is a legacy business but it's one that still has
>>> a long life aheade it it.
>>>
>>
>> No one is going to watch to convert 60 years of production software to
>> another platform. Actually, i take that back. It’s been tried, but never
>> successfully.
>
> I think that there were a lot of successful migrations from
> mainframes to other systems. It is likely that most succesful
> cases were gradual, taking substantial time.
>
> In Poland during comunist times one of basic machines were
> domesticaly produced ICL-1900 compatible machines, using ICL
> operating system. It seems that our manufacturer of those
> machines stopped production around 1990 (and during eighties
> production was decreasing). For few years alternative
> manufacturer offered compatible machines using bit-slice
> microprocessors. Few years ago supposedly last machine
> of this family was decomissioned (it was used by railway
> as part of trafic control).
>
> So, it is basically question of time and financial balance:
> currently mainframe users pay higer prices to mainframe
> vendors so that users can keep using their systems and
> avoid migration. But as user population shrinks it may
> become too small to adequatly support vendors. That may
> force vendors to limit their offer leading to colapse:
> limited vendor offer accelerates migration. That seem
> to happened with several smaller vendors. IBM-compatible
> world currently looks relatively healthy, but it is not
> clear for how long. I expect at least 10 more years of use
> of IBM-compatible mainframes, but it is hard to make
> prediction for longer time. 10 years may look like
> long time, but it is short compared to 60 year history.
>
No one expected 2 digit year field programs written in 1980 to
still be in production in 20 years time.
--
Bah, and indeed Humbug.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426706 is a reply to message #426705] |
Sun, 02 February 2025 13:23 |
scott
Messages: 4380
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
> On Sun, 2 Feb 2025 00:58:36 -0000 (UTC)
> antispam@fricas.org (Waldek Hebisch) wrote:
>
>> Peter Flass <peter_flass@yahoo.com> wrote:
>>> John Levine <johnl@taugh.com> wrote:
>>>> According to Bob Eager <news0009@eager.cx>:
>>>> > On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
>>>> >
>>>> >>>> IBM is still selling mainframe hardware.
>> So, it is basically question of time and financial balance:
>> currently mainframe users pay higer prices to mainframe
>> vendors so that users can keep using their systems and
>> avoid migration. But as user population shrinks it may
>> become too small to adequatly support vendors. That may
>> force vendors to limit their offer leading to colapse:
>> limited vendor offer accelerates migration. That seem
>> to happened with several smaller vendors. IBM-compatible
>> world currently looks relatively healthy, but it is not
>> clear for how long. I expect at least 10 more years of use
>> of IBM-compatible mainframes, but it is hard to make
>> prediction for longer time. 10 years may look like
>> long time, but it is short compared to 60 year history.
>>
> No one expected 2 digit year field programs written in 1980 to
> still be in production in 20 years time.
At Burroughs, we fully expected 2-digit year field programs
written in 1968 to be still in production by 2000 when we
started the Y2K mitigation work in the mid 1980s.
1960 was used as the dividing line - any two digit year smaller
was assumed to be 21st century; any larger was assumed to be
20th century.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426707 is a reply to message #426698] |
Sun, 02 February 2025 13:32 |
cross
Messages: 55
Registered: May 2013
Karma: 0
|
Member |
|
|
In article <m096f4Fp4ruU1@mid.individual.net>,
Bob Eager <news0009@eager.cx> wrote:
> On Sun, 02 Feb 2025 06:09:51 +0000, Charlie Gibbs wrote:
>
>> On 2025-02-01, Scott Lurndal <scott@slp53.sl.home> wrote:
>>
>>> Burroughs also used, primarily, block-mode terminals.
>>
>> Univac did as well. A good editor would present you with a screenful of
>> data; you could edit it using the terminal's built-in features (insert,
>> delete, or overwrite characters or lines) and send the updated screenful
>> of data back to the mainframe. It wasn't a full character-by-character
>> response, but it was tolerable.
>>
>> I ported Adventure and Dungeon to OS/3; one of the most difficult tasks
>> was getting terminal I/O to work properly.
>
> The operating system I helped to support for some years handled terminal
> I/O in a PDP-11 used as a front end processor (sometimes more than one).
> Characters were sent via an interface that used single characters or not,
> as needed.
Multics did something similar; again, the theory was to protect
the main CPU(s) from a flurry of interrupts as users typed away;
instead, shuttle all of that overhead off to some satellite
processor (the General Input/Output Controller; GIOC, mentioned
here: https://multicians.org/rjf.html) and only send data when
the user's entered an entire line (they weren't exactly record
oriented; more line oriented).
Then Bernie Greenberg wrote an implementation of emacs for
Multics (in Lisp, no less!) and suddenly there was a need to
have the computer react to individual keystrokes; this led to
a notion of "Multics Echo Processing", described here:
https://multicians.org/mepap.html
- Dan C.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426708 is a reply to message #426680] |
Sun, 02 February 2025 14:04 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Sat, 1 Feb 2025 19:16 +0000 (GMT Standard Time), John Dallman wrote:
> In article <vnjfai$3mhvf$4@dont-email.me>, ldo@nz.invalid (Lawrence
> D'Oliveiro) wrote:
>
>> Back in 1980, there were something like 10 different companies
>> operating in the mainframe business. Now there is only one.
>
> Nope. IBM is the market leader, sure. In Japan, Fujitsu and Hitachi
> continue to sell IBM-like 31-bit mainframes, and NEC sells a proprietary
> mainframe.
Don’t be fooled by continuity of branding. Remember, the big Japanese
companies are conglomerates (“sōgō shōsha”), with fingers in many pies.
Fujitsu, for example, among their many businesses sell high-performance
ARM chips (the A64FX and successors), which are used in supercomputers,
not mainframes.
> The ex-Univac OS 2200, ex-Burroughs MCP, Groupe Bull GCOS,
> ex-Siemens BS2000 and ex-ICL VME are all still used, mostly under
> emulation.
“Emulation” on what? What you’re admitting is mainframes as such are not
being sold, the legacy software, such as it is, is now running on
something else.
|
|
|
|
| Re: banking for old pharts, Multics vs Unix vs mainframes [message #426709 is a reply to message #426701] |
Sun, 02 February 2025 15:51 |
John Levine
Messages: 1487
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Lars Poulsen <lars@cleo.beagle-ears.com>:
>> Do you still have cheques in 🇩🇰? We don’t in 🇳🇿.
>
> Denmark did away with checks a decade ago, and is headed towards
> eliminating cash as well. Think 6-year olds with debit cards for their
> allowances.
>
> Here in the US, we still use checks. In fact, when I am moving money
> between banks, I go into my branch of the big national bank, get a
> cashier's check for some multiple of USD 50 000 and hand carry it to my
> branch of the small regional bank to deposit it there.
>
> If I were to do the transfer electronically, it would cost about USD 30,
> and take about 36 hours before the money was available in the new
> account. Doing it my way, it is free and the money is available when I
> leave the branch.
You must have a terrible bank. At an account I have at my large US bank, wire
transfers are free and I consistently see them show up in the recipient account
in less than an hour. I need a large minimum balance for that account, but if
you are buying $50K cashier's checks, you surely qualify.
> The USA is stuck in the past, waxing nostalgic for the golden days of
> the 1950s. And rapidly becoming a lawless 3rd world country.
Somewhat. The US has two bank instant payment systems, Real Time Payments from
The Clearing House (ostentatiously abbreviated TCH RTP), and FedNow from the
Federal Reserve. The problem is that the US, unlike any other country, has a few
large banks and a long tail of 4,000 medium to tiny banks. The small banks know
their local communities but outsource all of their backend systems to a few
specialist providers like FISERV and Jack Henry. It is really frustrating that
the back end providers support RTP, but the banks are clueless. One time I made
an RTP payment to my account at my medium sized local bank, which showed up as
promised in a few seconds. Then I pointed it out to them and asked how do I do a
transfer the other way. Duh, I don't think we offer that.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: how to run fast, old pharts, Multics vs Unix vs mainframes [message #426710 is a reply to message #426703] |
Sun, 02 February 2025 16:00 |
John Levine
Messages: 1487
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to John Dallman <jgd@cix.co.uk>:
> Speed of synchronisation matters a lot to a credit card provider who is
> trying to enforce customer credit limits and avoid double-spends. They
> still use mainframes with z/TPF for that. z/TPF is a curious OS; it
> essentially makes a mainframe into a single real-time transaction
> processing system.
TPF is an amazing fossil. Its design dates back to SABRE in the early 1960s
which borrowed the event loop from the SAGE system that ran on vacuum tube
computers in the 1950s. It still gets astonishing performance out of whatever
hardware it runs on.
The fundamental structure keeps being reinvented. Look inside node.js and it
looks oddly familiar.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: front ends, old pharts, Multics vs Unix [message #426711 is a reply to message #426707] |
Sun, 02 February 2025 16:05 |
John Levine
Messages: 1487
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Dan Cross <cross@spitfire.i.gajendra.net>:
>> The operating system I helped to support for some years handled terminal
>> I/O in a PDP-11 used as a front end processor (sometimes more than one).
>> Characters were sent via an interface that used single characters or not,
>> as needed.
>
> Multics did something similar; again, the theory was to protect
> the main CPU(s) from a flurry of interrupts as users typed away;
> instead, shuttle all of that overhead off to some satellite
> processor (the General Input/Output Controller; GIOC, ...
DTSS, which ran on a GE 635, the much simpler predecessor to the Multics
645, did the same thing, The TTYs connected to a Datanet-30 which
buffered up all the input until the user typed RUN or something else
that needed a response, which it forwarded in a block to the 635.
The performance was great, 100 users on a machine the same size as the
original PDP-10.
The first version of DTSS ran the whole system on the DN-30 and just used
the larger 225 as a compute server to which it handed the users' programs.
You typed RUN, it usually responded WAIT since there were other jobs
ahead of yours.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
Members
Search
Help
Register
Login
Home
