Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:

In Tokyo, electricity is extremely expensive.

Is this still the case?

DAGS.

For this reason, the university system is shut down on weekends
and holidays.

Hard to believe!

Very much true. Burroughs had a lot of mainframe customers in Japan
in the 1980s and many, if not most, shut down their systems overnight.


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 05 Oct 2025 23:56:10 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

In actual fact, we would just copy another customer's configuration
which we knew to work, making minor tweaks to match the new customer's requirements.

A time-honored tradition XD


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In actual fact, we would just copy another customer's configuration
which we knew to work, making minor tweaks to match the new customer's requirements.

A time-honored tradition XD

A wise sysprog mentor once told me that sysprogs don't write code, they
steal it. :)

De

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Peter Flass <Peter@Iron-Spring.com> writes:

On 10/5/25 14:05, Lawrence D?Oliveiro wrote:

The biggest problem was
the need to add a carriage return to the transmission. A CR could
be added to the end of a data transmission, but no way was found
to add the carriage return to a UNIX message.

I'm not sure what this is trying to say.

IBM terminals were not full duplex. You sent data, then you read data.
The switch in direction was based on the "line turn around character". In this case
carriage return.


--
Dan Espen

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/6/25 09:56, Dan Espen wrote:

Peter Flass <Peter@Iron-Spring.com> writes:

On 10/5/25 14:05, Lawrence D?Oliveiro wrote:

The biggest problem was
the need to add a carriage return to the transmission. A CR could
be added to the end of a data transmission, but no way was found
to add the carriage return to a UNIX message.

I'm not sure what this is trying to say.

IBM terminals were not full duplex. You sent data, then you read data.
The switch in direction was based on the "line turn around character". In this case
carriage return.

I get that, but what about the second part? They're saying that what the
unix system got was missing the CR?

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Peter Flass <Peter@Iron-Spring.com> writes:

On 10/6/25 09:56, Dan Espen wrote:

Peter Flass <Peter@Iron-Spring.com> writes:

On 10/5/25 14:05, Lawrence D?Oliveiro wrote:

The biggest problem was
the need to add a carriage return to the transmission. A CR could >>>> be added to the end of a data transmission, but no way was found >>>> to add the carriage return to a UNIX message.

I'm not sure what this is trying to say.

IBM terminals were not full duplex. You sent data, then you read data.
The switch in direction was based on the "line turn around character". In this case
carriage return.

I get that, but what about the second part? They're saying that what the >unix system got was missing the CR?

Unix systems used linefeed (LF) as the 'line turnaround character'. It
wasn't difficult to instruct the unix terminal driver to send CR instead
of LF.

$ stty -onlret < /dev/ttyXX

Would configure the terminal driver to send a carriage return instead
of a line feed character for the line associated with stdin.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 6 Oct 2025 08:15:25 -0700, John Ames wrote:

On Sun, 05 Oct 2025 23:56:10 GMT Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

In actual fact, we would just copy another customer's configuration
which we knew to work, making minor tweaks to match the new customer's
requirements.

A time-honored tradition XD

As a sysadmin with the programmer mentality, I am always on the lookout
for ways to do less work. Like generating repetitive configs with macros
or scripts. Less chance of getting something wrong if you don?t have to
keep doing it by hand.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Peter Flass <Peter@Iron-Spring.com> writes:

On 10/6/25 09:56, Dan Espen wrote:

Peter Flass <Peter@Iron-Spring.com> writes:

On 10/5/25 14:05, Lawrence D?Oliveiro wrote:

The biggest problem was
the need to add a carriage return to the transmission. A CR could >>>> be added to the end of a data transmission, but no way was found >>>> to add the carriage return to a UNIX message.

I'm not sure what this is trying to say.

IBM terminals were not full duplex. You sent data, then you read
data.
The switch in direction was based on the "line turn around character". In this case
carriage return.

I get that, but what about the second part? They're saying that what
the unix system got was missing the CR?

I think he's saying the UNIX system couldn't send break/cr.

--
Dan Espen

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Dan Espen <dan1espen@gmail.com> writes:

Peter Flass <Peter@Iron-Spring.com> writes:

On 10/6/25 09:56, Dan Espen wrote:

Peter Flass <Peter@Iron-Spring.com> writes:

On 10/5/25 14:05, Lawrence D?Oliveiro wrote:

The biggest problem was
the need to add a carriage return to the transmission. A CR could >>>>> be added to the end of a data transmission, but no way was found >>>>> to add the carriage return to a UNIX message.

I'm not sure what this is trying to say.

IBM terminals were not full duplex. You sent data, then you read
data.
The switch in direction was based on the "line turn around character". In this case
carriage return.

I get that, but what about the second part? They're saying that what
the unix system got was missing the CR?

I think he's saying the UNIX system couldn't send break/cr.

Which would be incorrect today, and would have been incorrect
then.


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/5/25 14:05, Lawrence D?Oliveiro wrote:

The biggest problem was
the need to add a carriage return to the transmission. A CR could >>>>> be added to the end of a data transmission, but no way was found >>>>> to add the carriage return to a UNIX message.

Peter Flass <Peter@Iron-Spring.com> writes:

I'm not sure what this is trying to say.

On 10/6/25 09:56, Dan Espen wrote:

IBM terminals were not full duplex. You sent data, then you read
data.
The switch in direction was based on the "line turn around character". In this case
carriage return.

Peter Flass <Peter@Iron-Spring.com> writes:

I get that, but what about the second part? They're saying that what
the unix system got was missing the CR?

On 2025-10-07, Dan Espen <dan1espen@gmail.com> wrote:

I think he's saying the UNIX system couldn't send break/cr.

As someone who spent some time on async terminal drivers, for both TTYs
and IBM 2741-family terminals as well as in the communications areas of
OS/360 (minimally), Univac 1100 EXEC-8, RSX-11M, VMS and embedded
systems on PDP-11/10, Z80 and MC68000, I can maybe contribute some
perspective here.

The mainframe companies (IBM and Univac) built very large distributed
real-time transaction systems. CICS may be one of the best known
examples, as it was the platform for many large inventory/logistics
systems as well as insurance policy management and airline reservation
systems. All of these systems were based on synchronous block-mode
terminals, designed to be able to be installed in clusters on
multi-dropped communication lines. This hardware design allowed the
software to conserve memory by keeping the queue of waiting transaction
out on the network in the screen buffers of the terminals instead of in
the memory of the host complex. This whole way of thinking is completely
alien to people who have grown up in the world os ASCII TTYs (glass or
steel).

Inherent in the mainframe thinking is that communication is always between
a central host (the "master") and a terminal (the "slave"). Even is a multiprocessor complex, there was no peer-to-peer connections; there
was always a grandmaster and one or more submasters. The Internet idea of
all hosts being co-equal was completely alien to the mainframers.

When connecting minicomputers to mainframes, there were basically two
ways. The preferred one was to make the mini look like an RJE (Remote
Job Entry) station, i.e. a card reader, printer and punch connected to
the mainframe via a synchronous modem connection. If mini users needed
to do interactive work on the mainframe, you could emulate one of the
above mentioned block mode display terminals. In fact, because "glass
TTYs" were a competitive multi-vendor market, these terminals cost much
less that the mainframe vendors' terminal clusters, so many mainframe
data centers, especially the academic one, would buy a minicomputer such
as a PDP-11/10 with a DH-11 16-port terminal controller to which they
would connect 16 VT100 (or compatible) terminals, along with a 2400 bps synchronous modem interface. The program would then maintain a "screen
buffer" in the mini's memory, update this screen image with input from
the host and the associated TTY, and respond to polls from the host as
needed. I have been a part of projects to do that on both PDP-11 and a
bit later a Z80 multiprocessor complex plugged into the UNIBUS of a
PDP-11 or VAX system running RSX-11M, VMS or Unix. The advantage of the
latter configuration was that you could switch the terminal between the
Unix host and the remote mainframe with a hotkey sequence.

Going the other way was where the problem was: The minicomputers sold by
the mainframe manufacturers had terminal subsystems architected in the mainframe mold, but the other minis had evolved in the asynchronous
ASCII world, and did not have support for terminals other than TTY class devices. If a user on an IBM block-mode terminal wanted to run an
interactive session, it would never work. The IBM 3270 and UNISCOPE 200 terminals did not have an operating mode to transmit a data message for
an arbitrary keypress. You MIGHT be able to write a program for UNIX
that would allow you to receive a text file in a buffered line-by-line
mode from a TTY, and you MIGHT be able to write a program on the
mainframe that could interact with that, but it would be very clumsy and
would at best work in an RJE-like fashion.

When the mainframes supported interactive terminals other than the above mentioned display terminals in synchronous block mode, it was quite
unlike the TTY model. The IBM 2741 was loved by its users; it was a
beautiful word-processing device: An IBM Selectric typewriter with a
modem attached, it was strictly half-duplex. When the keyboard was
unlocked, it could not receive data from the host, and when you hit Return/Enter, the keyboard was locked until the host sent the unlock
code. It had another quirk: Where TTY-style terminals operated in 110
bps, 300 bps, 600 bps, 1200 bps, 2400 bps or 9600 bps, the 2741-style
terminals ran at 134.5 bps.

UNIVAC did not have a terminal like that, so their hardcopy interactive terminal was an actual TTY, so they had some operating system support
for character level interaction, although it was horribly inefficient.

In 1973, I led a project group at RECKU (University of Copenhagen's
academic computer center) to develop a 2741 terminal device driver for
EXEC-8. When we opened up in 1971, we had installed a 2741 device driver
that we got from Rome, but a system update revamped the whole
communications driver complex so we had to replace it. (EXEC-8 release
30). As it happened, I was called up for my military service draft the
week before we went live. I was hoping for a bug to be found on day one
that would make them recall me, but everything worked without a hitch!

--
Lars Poulsen


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lars Poulsen <lars@beagle-ears.com> writes:

On 10/5/25 14:05, Lawrence D?Oliveiro wrote:

The biggest problem was
the need to add a carriage return to the transmission. A CR could >>>>>> be added to the end of a data transmission, but no way was found >>>>>> to add the carriage return to a UNIX message.

Peter Flass <Peter@Iron-Spring.com> writes:

I'm not sure what this is trying to say.

On 10/6/25 09:56, Dan Espen wrote:

IBM terminals were not full duplex. You sent data, then you read
data.
The switch in direction was based on the "line turn around character". In this case
carriage return.

Peter Flass <Peter@Iron-Spring.com> writes:

I get that, but what about the second part? They're saying that what
the unix system got was missing the CR?

On 2025-10-07, Dan Espen <dan1espen@gmail.com> wrote:

I think he's saying the UNIX system couldn't send break/cr.

As someone who spent some time on async terminal drivers, for both TTYs
and IBM 2741-family terminals as well as in the communications areas of >OS/360 (minimally), Univac 1100 EXEC-8, RSX-11M, VMS and embedded
systems on PDP-11/10, Z80 and MC68000, I can maybe contribute some >perspective here.

The mainframe companies (IBM and Univac) built very large distributed >real-time transaction systems.

Don't exclude Burroughs, which ran a significant fraction of the
ATM networks (e.g. FiServ) and banking teller terminals, along with
insurance management (and SWIFT).

CICS may be one of the best known
examples, as it was the platform for many large inventory/logistics
systems as well as insurance policy management and airline reservation >systems. All of these systems were based on synchronous block-mode
terminals, designed to be able to be installed in clusters on
multi-dropped communication lines.

This hardware design allowed the
software to conserve memory by keeping the queue of waiting transaction
out on the network in the screen buffers of the terminals instead of in
the memory of the host complex.

Even more important, it became a 'message-based' interface
rather than a character-by-character interface.

This whole way of thinking is completely
alien to people who have grown up in the world os ASCII TTYs (glass or >steel).

Actually, it's rather like ethernet, just over a different media
and without a standard packet format. For Burroughs, the block
mode terminals would have a protected field that provided the
'routing key' that was used when the screen was transmitted. The
MCS would examine the key and route to the appropriate application.

Inherent in the mainframe thinking is that communication is always between
a central host (the "master") and a terminal (the "slave"). Even is a >multiprocessor complex, there was no peer-to-peer connections; there
was always a grandmaster and one or more submasters. The Internet idea of >all hosts being co-equal was completely alien to the mainframers.

The burroughs data communciations processors (DCP) handled both
block-mode poll-select multidrop lines as well as standard
teletype (RS-232) connections. The later, of course, is
just a slower version of a video terminal.

Going the other way was where the problem was: The minicomputers sold by
the mainframe manufacturers had terminal subsystems architected in the >mainframe mold, but the other minis had evolved in the asynchronous
ASCII world, and did not have support for terminals other than TTY class >devices.

It was not impossible to support poll-select protocols on a
mini or unix-based machine, as long as the hardware has the
right communications Receiver/Transmitter hardware (UART, USART,
et alia).

If a user on an IBM block-mode terminal wanted to run an
interactive session, it would never work. The IBM 3270 and UNISCOPE 200 >terminals did not have an operating mode to transmit a data message for
an arbitrary keypress. You MIGHT be able to write a program for UNIX
that would allow you to receive a text file in a buffered line-by-line
mode from a TTY, and you MIGHT be able to write a program on the
mainframe that could interact with that, but it would be very clumsy and >would at best work in an RJE-like fashion.

The burroughs DCP would buffer TTY data until the CR or LF character (configurable) was received and then pass the data to the mainframe
MCS (Message Control System) for routing to the desired application.

Pseudo-block-mode, basically. Running character by character
(e.g. to support something like vi) would be possible, but the
overhead would be high, as you noted.



--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-07, Lars Poulsen <lars@beagle-ears.com> wrote:

When the mainframes supported interactive terminals other than the above mentioned display terminals in synchronous block mode, it was quite
unlike the TTY model. The IBM 2741 was loved by its users; it was a
beautiful word-processing device: An IBM Selectric typewriter with a
modem attached, it was strictly half-duplex. When the keyboard was
unlocked, it could not receive data from the host, and when you hit Return/Enter, the keyboard was locked until the host sent the unlock
code. It had another quirk: Where TTY-style terminals operated in 110
bps, 300 bps, 600 bps, 1200 bps, 2400 bps or 9600 bps, the 2741-style terminals ran at 134.5 bps.

Univac 90/30 serial hardware would only run async at 2400 bps or less.
This wasn't considered a problem, because Everybody Knows that async
is a low-speed protocol. :-)

UNIVAC did not have a terminal like that,

Not at first, anyway; their DCT 500 (a one-character drum printer
that moved across the page) and UTS 10 (async CRT) came soon afterwards.

so their hardcopy interactive terminal was an actual TTY,

Early versions of the 9400 used a TTY35RO mechanism as the console
printer (teamed with one of their own keyboards, which wasn't nearly
as clunky as a Teletype keyboard). Later versions used the DCT 500
mechanism.

so they had some operating system support
for character level interaction, although it was horribly inefficient.

Indeed. There was all that block mode emulation.

As you pointed out, mainframes are block-oriented, rather than character oriented. To me, this - not size - is the distinguishing characteristic between mainframes and minis. By this logic, a mainframe the size of a
PDP-11 is still a mainframe, while a mini the size of a mainframe (e.g.
a big PDP-10) is still a mini.

--
/~\ 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

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/7/25 12:52, Charlie Gibbs wrote:

On 2025-10-07, Lars Poulsen <lars@beagle-ears.com> wrote:

so they had some operating system support
for character level interaction, although it was horribly inefficient.

Indeed. There was all that block mode emulation.

As you pointed out, mainframes are block-oriented, rather than character oriented. To me, this - not size - is the distinguishing characteristic between mainframes and minis. By this logic, a mainframe the size of a PDP-11 is still a mainframe, while a mini the size of a mainframe (e.g.
a big PDP-10) is still a mini.

That's an interesting take. I never thought of that, but it sounds
exactly right.

Can you imagine the interrupt overhead if every keypress on hundreds of terminals instantly generated an interrupt on the host?


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-07, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

As you pointed out, mainframes are block-oriented, rather than character oriented. To me, this - not size - is the distinguishing characteristic between mainframes and minis. By this logic, a mainframe the size of a PDP-11 is still a mainframe, while a mini the size of a mainframe (e.g.
a big PDP-10) is still a mini.

Certainly IBM considered their S/3 and S/34 to be minis ...

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 07 Oct 2025 19:52:37 GMT, Charlie Gibbs wrote:

As you pointed out, mainframes are block-oriented, rather than character oriented. To me, this - not size - is the distinguishing characteristic between mainframes and minis. By this logic, a mainframe the size of a PDP-11 is still a mainframe, while a mini the size of a mainframe (e.g.
a big PDP-10) is still a mini.

To add to that, the whole ?mainframe? concept is built around the (long- outdated) assumption that CPU time is a scarce resource, to be rationed as tightly as possible. This is why you have all those complex I/O channel controllers, capable of performing elaborate sequences of operations on
their own in-between interrupting the CPU to ask what to do next. Block-
mode terminals are just one part of that. Another part, particularly on
the software side, is batch-mode operation, prioritizing high I/O
throughput over low latency.

Some people referred to PDP-10 machines as ?mainframes?, but by this definition, you can see why none of DEC?s systems, large or small, could
be described as such. I think DEC?s own term for the PDP-6/PDP-10 range
was ?large systems?.

But now you look at the modest little RP2040 chip and its followons from
the Raspberry Pi foundation, and you see that it provides quite advanced
I/O channel controllers -- one might describe them as ?mainframe-like?.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 7 Oct 2025 13:32:02 -0700, Peter Flass wrote:

Can you imagine the interrupt overhead if every keypress on hundreds of terminals instantly generated an interrupt on the host?

That?s exactly how DEC?s interactive OSes operated.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 7 Oct 2025 18:06:10 -0000 (UTC), Lars Poulsen wrote:

The Internet idea of all hosts being co-equal was completely alien to
the mainframers.

Would you say that the World-Wide Web has reintroduced that idea to the Internet?

Consider the strong centralization (and consequent concentration of power
over their users) of the well-known ?social-media? services.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/7/25 14:05, Lars Poulsen wrote:

On 2025-10-07, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

As you pointed out, mainframes are block-oriented, rather than character
oriented. To me, this - not size - is the distinguishing characteristic
between mainframes and minis. By this logic, a mainframe the size of a
PDP-11 is still a mainframe, while a mini the size of a mainframe (e.g.
a big PDP-10) is still a mini.

Certainly IBM considered their S/3 and S/34 to be minis ...

"Midrange" I think the Series-1 was the first thing IBM called a
minicomputer.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-07, Peter Flass <Peter@Iron-Spring.com> wrote:

On 10/7/25 12:52, Charlie Gibbs wrote:

On 2025-10-07, Lars Poulsen <lars@beagle-ears.com> wrote:

so they had some operating system support
for character level interaction, although it was horribly inefficient.

Indeed. There was all that block mode emulation.

As you pointed out, mainframes are block-oriented, rather than character
oriented. To me, this - not size - is the distinguishing characteristic
between mainframes and minis. By this logic, a mainframe the size of a
PDP-11 is still a mainframe, while a mini the size of a mainframe (e.g.
a big PDP-10) is still a mini.

That's an interesting take. I never thought of that, but it sounds
exactly right.

Can you imagine the interrupt overhead if every keypress on hundreds of terminals instantly generated an interrupt on the host?

Especially given the CPUs of yesteryear...

--
/~\ 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

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lars Poulsen <lars@beagle-ears.com> writes:

As someone who spent some time on async terminal drivers, for both
TTYs and IBM 2741-family terminals as well as in the communications
areas of OS/360 (minimally), Univac 1100 EXEC-8, RSX-11M, VMS and
embedded systems on PDP-11/10, Z80 and MC68000, I can maybe contribute
some perspective here.

In 60s, lots of science/technical and univ were sold 360/67 (w/virtual
memory) for tss/360 ... but when tss/360 didn't come to production
... lots of places just used it as 360/65 with os/360 (Michigan and
Stanford wrote their own virtual memory systems for 360/67).

Some of the CTSS/7094 people went to the 5th flr to do Multics, others
went to the 4th flr to the IBM science center and did virtual machines, internal network, lots of other stuff. CSC originally wanted 360/50 to
do virtual memory hardware mods, but all the spare 50s were going to
FAA/ATC and had to settle for 360/40 to modify and did (virtual machine) CP40/cms. Then when 360/67 standard with virtual memory came available, CP40/CMS morphs into CP67/CMS.

Univ was getting 360/67 to replace 709/1401 and I had taken two credit
hr intro to fortran/computers; at end of semester was hired to rewrite
1401 MPIO for 360/30 (temporarily replacing 1401 pending 360/67). Within
a yr of taking intro class, the 360/67 arrives and I'm hired fulltime responsible for OS/360 (Univ. shutdowns datacenter on weekend and I got
it dedicated, however 48hrs w/o sleep made monday classes hard).

Eventually CSC comes out to install CP67 (3rd after CSC itself and MIT
Lincoln Labs) and I mostly get to play with it during my 48hr weekend
dedicated time. I initially work on pathlengths for running OS/360 in
virtual machine. Test stream ran 322secs on real machine, initially
856secs in virtual machine (CP67 CPU 534secs), after a couple months I
have reduced CP67 CPU from 534secs to 113secs. I then start rewriting
the dispatcher, (dynamic adaptive resource manager/default fair share
policy) scheduler, paging, adding ordered seek queuing (from FIFO) and mutli-page transfer channel programs (from FIFO and optimized for transfers/revolution, getting 2301 paging drum from 70-80 4k
transfers/sec to channel transfer peak of 270). Six months after univ
initial install, CSC was giving one week class in LA. I arrive on Sunday afternoon and asked to teach the class, it turns out that the people
that were going to teach it had resigned the Friday before to join one
of the 60s CP67 commercial online spin-offs.

Original CP67 came with 1052 & 2741 terminal support with automagic
terminal identification, used SAD CCW to switch controller's port
terminal type scanner. Univ. had some number of TTY33&TTY35 terminals
and I add TTY ASCII terminal support integrated with automagic terminal
type. I then wanted to have a single dial-in number ("hunt group") for
all terminals. It didn't quite work, IBM had taken short cut and had
hard-wired line speed for each port. This kicks off univ effort to do
our own clone controller, built channel interface board for Interdata/3 programmed to emulate IBM controller with the addition it could do auto line-speed/(dynamic auto-baud). It was later upgraded to Interdata/4 for channel interface with cluster of Interdata/3s for port
interfaces. Interdata (and later Perkin-Elmer) was selling it as clone controller and four of us get written up responsible for (some part of)
the IBM clone controller business.
https://en.wikipedia.org/wiki/Interdata https://en.wikipedia.org/wiki/Perkin-Elmer#Computer_Systems_Division

Univ. library gets an ONR grant to do online catalog and some of the
money is used for a 2321 datacell. IBM also selects it as betatest for
the original CICS product and supporting CICS added to my tasks.

Then before I graduate, I'm hired fulltime into a small group in the
Boeing CFO office to help with the formation of Boeing Computer Services (consolidate all dataprocessing into independent business unit). I think
Renton datacenter largest in the world (360/65s arriving faster than
they could be installed, boxes constantly staged in hallways around
machine room; joke that Boeing was getting 360/65s like other companies
got keypunch machines). Lots of politics between Renton director and
CFO, who only had a 360/30 up at Boeing field for payroll (although they enlarge the machine room to install 360/67 for me to play with when I
wasn't doing other stuff). Renton did have a (lonely) 360/75 (among all
the 360/65s) that was used for classified work (black rope around the
area, heavy black felt draopped over console lights & 1403s with guards
at perimeter when running classified). After I graduate, I join IBM CSC
in cambridge (rather than staying with Boeing CFO).

One of my hobbies after joining IBM CSC was enhanced production
operating systems for internal datacenters. At one time had rivalry with
5th flr over whether they had more total installations (internal,
development, commercial, gov, etc) running Multics or I had more internal installations running my internal CSC/VM.

A decade later, I'm at SJR on the west coast and working with Jim Gray
and Vera Watson on the original SQL/relational implementation
System/R. I also had numerous internal datacenters running my internal
SJR/VM system ... getting .11sec trivial interactive system
response. This was at the time of several studies showing .25sec
response getting improved productivity.

The 3272/3777 controller/terminal had .089 hardware response (plus the
.11 system response resulted in .199 response, meeting .25sec criteria).
The 3277 still had half-duplex problem attempting to hit a key at same
time as screen write, keyboard would lock and would have to stop and
reset. YKT was making a FIFO box available, unplug the 3277 keyboard for
the head, plug-in the FIFO box and plug keyboard into FIFO ... which
avoided the half-duplex keyboard lock).

Then IBM produced 3274/3278 controller/terminal were lots of electronics
were moved back into the controller, reducing cost to make the 3278, but significantly increase coax protocol chatter ... significantly
increasing hardware response to .3-.5secs depending on how much data was written to screen. Letters to the 3278 product administrator
complaining, got back response that 3278 wasn't designed for interactive computing ... but data entry.

--
virtualization experience starting Jan1968, online at home since Mar1970

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/7/2025 11:06 AM, Lars Poulsen wrote:

snip

I agree almost entirely with your post below, but with a few minor issues.

As someone who spent some time on async terminal drivers, for both TTYs
and IBM 2741-family terminals as well as in the communications areas of OS/360 (minimally), Univac 1100 EXEC-8, RSX-11M, VMS and embedded
systems on PDP-11/10, Z80 and MC68000, I can maybe contribute some perspective here.

The mainframe companies (IBM and Univac) built very large distributed real-time transaction systems. CICS may be one of the best known
examples, as it was the platform for many large inventory/logistics
systems as well as insurance policy management and airline reservation systems.

CICS was indeed the most popular transaction system, but it was not used
by airlines (nor credit card validation systems), as the overhead was
too large so wouldn't permit the transaction volume these users needed.
They used ACP (Airline Control Program), later renames TPF (Transaction processing facility) which was a stand alone OS designed just for high
volume transactions.

All of these systems were based on synchronous block-mode
terminals, designed to be able to be installed in clusters on
multi-dropped communication lines. This hardware design allowed the
software to conserve memory by keeping the queue of waiting transaction
out on the network in the screen buffers of the terminals instead of in
the memory of the host complex.

As well as other advantages, such as less costly long distance wiring
(or fewer modems if using telecommunications) from the terminals to the mainframe, more efficient wire use for moderately long (say dozens to
perhaps a hundred characters) messages due to no need for start bits,
can do parity on the whole message instead of per character, etc,

This whole way of thinking is completely
alien to people who have grown up in the world os ASCII TTYs (glass or steel).

Inherent in the mainframe thinking is that communication is always between
a central host (the "master") and a terminal (the "slave"). Even is a multiprocessor complex, there was no peer-to-peer connections; there
was always a grandmaster and one or more submasters. The Internet idea of all hosts being co-equal was completely alien to the mainframers.

Yup.

When the mainframes supported interactive terminals other than the above mentioned display terminals in synchronous block mode, it was quite
unlike the TTY model. The IBM 2741 was loved by its users; it was a
beautiful word-processing device: An IBM Selectric typewriter with a
modem attached, it was strictly half-duplex. When the keyboard was
unlocked, it could not receive data from the host, and when you hit Return/Enter, the keyboard was locked until the host sent the unlock
code. It had another quirk: Where TTY-style terminals operated in 110
bps, 300 bps, 600 bps, 1200 bps, 2400 bps or 9600 bps, the 2741-style terminals ran at 134.5 bps.

UNIVAC did not have a terminal like that, so their hardcopy interactive terminal was an actual TTY, so they had some operating system support
for character level interaction, although it was horribly inefficient.

As Charlie Gibbs pointed out Univac had the DCT 500, but that was not equivalent to IBM's 2741. There were actually several products in the
DCT (Data Communications Terminal) line. The DCT 500, was a teletype equivalent, paper output and asynchronous communications. The DCT 1000
was more like the 2741 in that it used Univac's synchronous
communications protocol and was a paper terminal. You could mix DCT
1000s with Uniscope 100s (Univac's 2780 like glass terminal) on the same multiplexor. There was also a DCT 2000, which was basically a remote
job entry system (card reader/printer, etc.)



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 7 Oct 2025 22:00:06 -0000 (UTC)
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

The Internet idea of all hosts being co-equal was completely alien
to the mainframers.

Would you say that the World-Wide Web has reintroduced that idea to
the Internet?

Consider the strong centralization (and consequent concentration of
power over their users) of the well-known ?social-media?

services.

The Web didn't do that - Facebook and its ilk did, making a *very*
deliberate push over the span of about 2005 - 2015 to de-educate people
on how the Web works (as well as the basics of online privacy, but
that's another rant.) By now, I'm given to understand, they actually
sandbox links to external content so that you have to open them in FB's
own in-app browser, the better to track and control any exits from
their prison^H^H^H^H^H^H walled garden.

But the Web is still open, despite their best efforts - and may it
remain so long after they're dead and gone.


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-08, Lynn Wheeler <lynn@garlic.com> wrote:

Then IBM produced 3274/3278 controller/terminal were lots of electronics
were moved back into the controller, reducing cost to make the 3278, but significantly increase coax protocol chatter ... significantly
increasing hardware response to .3-.5secs depending on how much data was written to screen. Letters to the 3278 product administrator
complaining, got back response that 3278 wasn't designed for interactive computing ... but data entry.

Univac terminals of the day (multi-drop polled protocol) tended to
poll a group once a second, which set a minimum response time right
there. (I think you could configure a shorter poll interval, but
then your CPU overhead went up.) I heard a rumour that the designers
believed what the user wanted was a consistent response time, rather
than a fast one - and as a result they designed the system to insert
a delay if the response was ready before the target response time.

--
/~\ 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

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-08, John Ames <commodorejohn@gmail.com> wrote:

But the Web is still open, despite their best efforts - and may it
remain so long after they're dead and gone.

We must remain vigilant, though. HTML has incorporated so much
gratuitous complexity that it's in danger of becoming a proprietary
protocol. Some browsers (e.g. Seamonkey) can't display many pages.
I think Chrome and Edge are fighting it out to see who becomes the
winner in an online game of Monopoly. Firefox is hanging in there;
I no longer like its user interface, but more and more often I have
no alternative but to use it, because I won't touch the M$ and Google
browsers.

Remember, complexity is a weapon.

--
/~\ 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

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 08 Oct 2025 17:31:23 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

But the Web is still open, despite their best efforts - and may it
remain so long after they're dead and gone.

We must remain vigilant, though. HTML has incorporated so much
gratuitous complexity that it's in danger of becoming a proprietary
protocol. Some browsers (e.g. Seamonkey) can't display many pages.

Very true, though there's been an encouragin movement back towards
simpler web design among independent developers recently.


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/8/25 10:31, Charlie Gibbs wrote:

On 2025-10-08, Lynn Wheeler <lynn@garlic.com> wrote:

Then IBM produced 3274/3278 controller/terminal were lots of electronics
were moved back into the controller, reducing cost to make the 3278, but
significantly increase coax protocol chatter ... significantly
increasing hardware response to .3-.5secs depending on how much data was
written to screen. Letters to the 3278 product administrator
complaining, got back response that 3278 wasn't designed for interactive
computing ... but data entry.

Univac terminals of the day (multi-drop polled protocol) tended to
poll a group once a second, which set a minimum response time right
there. (I think you could configure a shorter poll interval, but
then your CPU overhead went up.) I heard a rumour that the designers believed what the user wanted was a consistent response time, rather
than a fast one - and as a result they designed the system to insert
a delay if the response was ready before the target response time.

I don't know about the delay part, but I believe they were right about consistent response.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 8 Oct 2025 08:38:20 -0700, John Ames wrote:

On Tue, 7 Oct 2025 22:00:06 -0000 (UTC)
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

The Internet idea of all hosts being co-equal was completely alien to
the mainframers.

Would you say that the World-Wide Web has reintroduced that idea to the
Internet?

Consider the strong centralization (and consequent concentration of
power over their users) of the well-known ?social-media? services.

The Web didn't do that - Facebook and its ilk did ...

Why do you think the new-style services are trying to move away from that centralization, by using more distributed protocols?

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 8 Oct 2025 21:00:05 -0000 (UTC)
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

The Internet idea of all hosts being co-equal was completely
alien to the mainframers.

Would you say that the World-Wide Web has reintroduced that idea
to the Internet?

Consider the strong centralization (and consequent concentration of
power over their users) of the well-known ?social-media?

? services.

The Web didn't do that - Facebook and its ilk did ...

Why do you think the new-style services are trying to move away from
that centralization, by using more distributed protocols?

To the best of my knowledge, the "new-style services" (which I assume
is referring to e.g. Mastodon) aren't aiming to replace the Web per se,
but rather to replace specific sites/services that attracted Very Large userbases that the site owners then exerted a lot of influence/control
over with decentralized systems that would give that control to the
users. That's perfectly fine, but as a goal it's completely orthogonal;
it neither obsoletes nor is incompatible with the existence of the
"open Web."


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 8 Oct 2025 14:26:36 -0700, John Ames wrote:

On Wed, 8 Oct 2025 21:00:05 -0000 (UTC)
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

The Internet idea of all hosts being co-equal was completely alien
to the mainframers.

Would you say that the World-Wide Web has reintroduced that idea to
the Internet?

Consider the strong centralization (and consequent concentration of
power over their users) of the well-known ?social-media? services.

The Web didn't do that - Facebook and its ilk did ...

Why do you think the new-style services are trying to move away from
that centralization, by using more distributed protocols?

To the best of my knowledge, the "new-style services" (which I assume is referring to e.g. Mastodon) aren't aiming to replace the Web per se ...

But there is a conscious design to make the Web part of it optional. Not
just access via apps, but even independent third-party apps.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/8/25 11:40, Stefan Ram wrote:

John Ames <commodorejohn@gmail.com> wrote or quoted:

Very true, though there's been an encouragin movement back towards
simpler web design among independent developers recently.

When I got zero hits on a web search, a JavaScript-based SVG
animation popped up and just kept moving non-stop. JavaScript
is basically the comeback of the old "BLINK" element for HTML.

I don't see whatever movement you're talking about. For me
it's going the other way. More and more sites are locked into
certain browsers - "Your browser is not supported." - and
hard-wired to JavaScript - "Enable JavaScript and Reload!".
The whole old-school idea of a browser-neutral standard with
graceful degradation is getting less and less respect.

But, but, MY animations are so important I have to make sure you all see
them.


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-09, Peter Flass <Peter@Iron-Spring.com> wrote:

On 10/8/25 11:40, Stefan Ram wrote:

John Ames <commodorejohn@gmail.com> wrote or quoted:

Very true, though there's been an encouragin movement back towards
simpler web design among independent developers recently.

When I got zero hits on a web search, a JavaScript-based SVG
animation popped up and just kept moving non-stop. JavaScript
is basically the comeback of the old "BLINK" element for HTML.

I don't see whatever movement you're talking about. For me
it's going the other way. More and more sites are locked into
certain browsers - "Your browser is not supported." - and
hard-wired to JavaScript - "Enable JavaScript and Reload!".
The whole old-school idea of a browser-neutral standard with
graceful degradation is getting less and less respect.

But, but, MY animations are so important I have to make sure you all see them.

But only on my terms.

--
/~\ 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

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 09 Oct 2025 05:12:41 GMT, Charlie Gibbs wrote:

On 2025-10-09, Peter Flass <Peter@Iron-Spring.com> wrote:

But, but, MY animations are so important I have to make sure you
all see them.

But only on my terms.

Replace all the general-purpose PCs and browsers with locked-down dumb terminals! No more private browsing, ad blockers, telemetry blockers,
cookie control, disabling JavaScript, client-side CSS and all the rest
of it! The websites must be in control!

Remember the ?telescreens? in ?1984?, that could never be turned off?
Even as you were watching the programs that were broadcast, the
screens were watching you?

TV was still a novelty when Orwell wrote that. But the Web has
completely leapfrogged that idea.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-08, Charlie Gibbs wrote:

On 2025-10-08, John Ames <commodorejohn@gmail.com> wrote:

But the Web is still open, despite their best efforts - and may it
remain so long after they're dead and gone.

We must remain vigilant, though. HTML has incorporated so much
gratuitous complexity that it's in danger of becoming a proprietary
protocol. Some browsers (e.g. Seamonkey) can't display many pages.
I think Chrome and Edge are fighting it out to see who becomes the
winner in an online game of Monopoly. Firefox is hanging in there;
I no longer like its user interface, but more and more often I have
no alternative but to use it, because I won't touch the M$ and Google browsers.

Remember, complexity is a weapon.

Google has now broken Recaptcha. This, like Cloudflare's recurring
technical issues in implementing their "Browser Integrity Check" (which
at one point some years ago was coded to perform a self-DDoS on
Cloudflare...), will outright render incompatible a bunch of websites
that are perfectly compatible with a bigger number of browsers, except
for their use of Recaptcha or Cloudflare Turnstile.

This, where Google is concerned, might be part of a bigger thing
happening now, as until some weeks ago, Google was still serving
perfectly usable non-JS web search results to some UA strings, including
that of IE6. Now, along with changes to start requiring JS on newer
browsers, Google web search is also outright refusing to serve such
older UA strings, serving "update your browser" messages instead.

There could be some hope the Recaptcha part is just an unintended
glitch, but given what they're doing in the search engine web interface,
it seems less likely...

--
Nuno Silva

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 9 Oct 2025 00:08:46 -0000 (UTC)
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

Consider the strong centralization (and consequent concentration
of power over their users) of the well-known ?social-media

?

services.

The Web didn't do that - Facebook and its ilk did ...

Why do you think the new-style services are trying to move away
from that centralization, by using more distributed protocols?

To the best of my knowledge, the "new-style services" (which I
assume is referring to e.g. Mastodon) aren't aiming to replace the
Web per se ...

But there is a conscious design to make the Web part of it optional.
Not just access via apps, but even independent third-party apps.

Sure, and for those services that makes perfect sense - the originals
they're replacing were only Web-based in the first place because that
was the most conveniently accessible platform, and they added dedicated
clients for e.g. mobile devices very early on.

But those things are far from the only use case for the Web. Nobody,
AFAIK, is proposing anything that would obsolete personal websites,
specialist public fora, webcomic or other browsable gallery-format
sites, etc. For most of those, it'd be silly to bother with a de-
centralized approach in the first place (that's debatable with forums,
I suppose.)


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-08, John Ames <commodorejohn@gmail.com> wrote:

But the Web is still open, despite their best efforts - and may it
remain so long after they're dead and gone.

The biggest driver towards centralization (from this old techie's
perspective) is how hard it is to get a static IP for a residential
Internet subscription.

To get a static IP and permission to accept inbound connections, I have
to pay for a "business" account which comes at a significant price
increase over a residentail account.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-08, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

Univac terminals of the day (multi-drop polled protocol) tended to
poll a group once a second, which set a minimum response time right
there. (I think you could configure a shorter poll interval, but
then your CPU overhead went up.) I heard a rumour that the designers believed what the user wanted was a consistent response time, rather
than a fast one - and as a result they designed the system to insert
a delay if the response was ready before the target response time.

I heard that same "rumor" (I think it was in an article in the Wiley
journal "Software, Practice and Experience") when I was at RECKU (Univ
of Copenhagen) and inserted a 500ms delay in our local build of EXEC-8
EDIT. Later, (after I moved on from there) I learned that 500 ms delay
forced a SWAP (because the system declared it a LONGWAIT) whether there
was memory contention or not, so they took it out to improve performace.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

According to Lars Poulsen <lars@cleo.beagle-ears.com>:

The biggest driver towards centralization (from this old techie's >perspective) is how hard it is to get a static IP for a residential
Internet subscription.

There's perfectly good reasons for that. The vast majority of
residential users have no interest in running servers, and any
server-like thing is either a botnet or a semi-legal VPN relay they
don't know they're running.

To get a static IP and permission to accept inbound connections, I have
to pay for a "business" account which comes at a significant price
increase over a residentail account.

I have a VPS with static v4 and v6 addresses that costs $5/mo. And I
don't have to screw around with a physical server in my house, either.

Back in the 1990s I had a physical T1 to my house, with an old PC
running BSDI as the router, which involved a lot of OSPF debugging
that I wouldn't have been able to do execpt that, by stupendous
coincidence, the guy who wrote the router software lives in the
same town and could say, oh right, that bug.

I don't miss it.

(His licence plate says TCP-IP. Mine says IPV4.)
--
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

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lars Poulsen wrote:
...

I heard that same "rumor" (I think it was in an article in the Wiley
journal "Software, Practice and Experience") when I was at RECKU (Univ
of Copenhagen) and inserted a 500ms delay in our local build of EXEC-8
EDIT. Later, (after I moved on from there) I learned that 500 ms delay
forced a SWAP (because the system declared it a LONGWAIT) whether there
was memory contention or not, so they took it out to improve performace.

@ed macros were a great help in getting things to look
better. :)

hard to believe that was over 40yrs ago now...


songbird

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-07 23:57, Lawrence D?Oliveiro wrote:

On Tue, 7 Oct 2025 13:32:02 -0700, Peter Flass wrote:

Can you imagine the interrupt overhead if every keypress on hundreds of
terminals instantly generated an interrupt on the host?

That?s exactly how DEC?s interactive OSes operated.

Not on the PDP-10. Terminals were usually hooked up to a front-end
(usually a PDP-11) which did all of that messy work, and the PDP-10 only
got noted when a whole line was available, and it didn't know or care at
all about individual keypresses.

Johnny


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-07 23:56, Lawrence D?Oliveiro wrote:

On Tue, 07 Oct 2025 19:52:37 GMT, Charlie Gibbs wrote:

As you pointed out, mainframes are block-oriented, rather than character
oriented. To me, this - not size - is the distinguishing characteristic
between mainframes and minis. By this logic, a mainframe the size of a
PDP-11 is still a mainframe, while a mini the size of a mainframe (e.g.
a big PDP-10) is still a mini.

To add to that, the whole ?mainframe? concept is built around the (long- outdated) assumption that CPU time is a scarce resource, to be rationed as tightly as possible. This is why you have all those complex I/O channel controllers, capable of performing elaborate sequences of operations on
their own in-between interrupting the CPU to ask what to do next. Block-
mode terminals are just one part of that. Another part, particularly on
the software side, is batch-mode operation, prioritizing high I/O
throughput over low latency.

Some people referred to PDP-10 machines as ?mainframes?, but by this definition, you can see why none of DEC?s systems, large or small, could
be described as such. I think DEC?s own term for the PDP-6/PDP-10 range
was ?large systems?.

People really need to learn how the PDP-10 works before making these comments... :-(

Johnny


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 10 Oct 2025 05:18:02 +0200, Johnny Billquist wrote:

On 2025-10-07 23:57, Lawrence D?Oliveiro wrote:

On Tue, 7 Oct 2025 13:32:02 -0700, Peter Flass wrote:

Can you imagine the interrupt overhead if every keypress on hundreds
of terminals instantly generated an interrupt on the host?

That?s exactly how DEC?s interactive OSes operated.

Not on the PDP-10. Terminals were usually hooked up to a front-end
(usually a PDP-11) which did all of that messy work, and the PDP-10 only
got noted when a whole line was available, and it didn't know or care at
all about individual keypresses.

If you were running something that needed to respond to every keystroke,
like TECO, I don?t see how a front-end processor could help with that.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 10 Oct 2025 05:18:02 +0200, Johnny Billquist wrote:

On 2025-10-07 23:57, Lawrence D?Oliveiro wrote:

On Tue, 7 Oct 2025 13:32:02 -0700, Peter Flass wrote:

Can you imagine the interrupt overhead if every keypress on hundreds
of terminals instantly generated an interrupt on the host?

That?s exactly how DEC?s interactive OSes operated.

Not on the PDP-10. Terminals were usually hooked up to a front-end
(usually a PDP-11) which did all of that messy work, and the PDP-10 only
got noted when a whole line was available, and it didn't know or care at
all about individual keypresses.

Unless you were using TECO.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <10c9u0b$ris$2@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:

On 2025-10-07 23:56, Lawrence D?Oliveiro wrote:

On Tue, 07 Oct 2025 19:52:37 GMT, Charlie Gibbs wrote:

As you pointed out, mainframes are block-oriented, rather than character >>> oriented. To me, this - not size - is the distinguishing characteristic >>> between mainframes and minis. By this logic, a mainframe the size of a
PDP-11 is still a mainframe, while a mini the size of a mainframe (e.g.
a big PDP-10) is still a mini.

To add to that, the whole ?mainframe? concept is built around the (long-
outdated) assumption that CPU time is a scarce resource, to be rationed as >> tightly as possible. This is why you have all those complex I/O channel
controllers, capable of performing elaborate sequences of operations on
their own in-between interrupting the CPU to ask what to do next. Block-
mode terminals are just one part of that. Another part, particularly on
the software side, is batch-mode operation, prioritizing high I/O
throughput over low latency.

Some people referred to PDP-10 machines as ?mainframes?, but by this
definition, you can see why none of DEC?s systems, large or small, could
be described as such. I think DEC?s own term for the PDP-6/PDP-10 range
was ?large systems?.

People really need to learn how the PDP-10 works before making these >comments... :-(

Lawrence is a clown. Seriously, people should just stop
engaging with him; it's like trying to explain evolution to a
broken lamp: the light never goes on.

- Dan C.


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 7 Oct 2025 13:32:02 -0700, Peter Flass wrote:

Can you imagine the interrupt overhead if every keypress on hundreds of
terminals instantly generated an interrupt on the host?

On 2025-10-07 23:57, Lawrence D?Oliveiro wrote:

That?s exactly how DEC?s interactive OSes operated.

On 2025-10-10, Johnny Billquist <bqt@softjar.se> wrote:

Not on the PDP-10. Terminals were usually hooked up to a front-end
(usually a PDP-11) which did all of that messy work, and the PDP-10 only
got noted when a whole line was available, and it didn't know or care at
all about individual keypresses.

[Hey, a familiar name from ... DECUS? - It's been decades!]

VMS had a state-machine driven terminal driver where you could set masks
for which characters should be echoed, which characters should terminate
the read and post the buffer, and how many milliseconds of
inter-character spacing would cause end-of-read. I presume this must
have been modeled on what the PDP-10 did?

--
Lars Poulsen

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 10 Oct 2025 12:54:41 -0000 (UTC), Lars Poulsen wrote:

VMS had a state-machine driven terminal driver where you could set masks
for which characters should be echoed, which characters should terminate
the read and post the buffer, and how many milliseconds of
inter-character spacing would cause end-of-read.

Still does, insofar as VMS is still (kind of) around. All that logic has
to be handled at interrupt level, in the terminal driver. Except no, the
I/O timeout was in whole seconds, last I checked.

Back in VMS V3, terminal handling was split into a ?class driver? versus a ?port driver?. Third-party serial multiplexer controllers had become quite popular, so DEC decided to implement all the well-known terminal
functionality in a hardware-independent class driver, so third parties
only had to implement the port driver for their particular hardware, conforming to the documented interface between the two, and they would automatically get all the standard terminal behaviour as with DEC?s own hardware, as described above.

That?s one part of VMS I wish Linux would copy. Doesn?t really fit into
the *nix character-device model, though.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

On 2025-10-07, Lars Poulsen <lars@beagle-ears.com> wrote:

When the mainframes supported interactive terminals other than the above
mentioned display terminals in synchronous block mode, it was quite
unlike the TTY model. The IBM 2741 was loved by its users; it was a
beautiful word-processing device: An IBM Selectric typewriter with a
modem attached, it was strictly half-duplex. When the keyboard was
unlocked, it could not receive data from the host, and when you hit
Return/Enter, the keyboard was locked until the host sent the unlock
code. It had another quirk: Where TTY-style terminals operated in 110
bps, 300 bps, 600 bps, 1200 bps, 2400 bps or 9600 bps, the 2741-style
terminals ran at 134.5 bps.

Univac 90/30 serial hardware would only run async at 2400 bps or less.
This wasn't considered a problem, because Everybody Knows that async
is a low-speed protocol. :-)

UNIVAC did not have a terminal like that,

Not at first, anyway; their DCT 500 (a one-character drum printer
that moved across the page) and UTS 10 (async CRT) came soon afterwards.

so their hardcopy interactive
terminal was an actual TTY,

Early versions of the 9400 used a TTY35RO mechanism as the console
printer (teamed with one of their own keyboards, which wasn't nearly
as clunky as a Teletype keyboard). Later versions used the DCT 500 mechanism.

so they had some operating system support
for character level interaction, although it was horribly inefficient.

Indeed. There was all that block mode emulation.

As you pointed out, mainframes are block-oriented, rather than character oriented. To me, this - not size - is the distinguishing characteristic between mainframes and minis. By this logic, a mainframe the size of a PDP-11 is still a mainframe, while a mini the size of a mainframe (e.g.
a big PDP-10) is still a mini.

By that logic machine running a Web server is a mainframe. Taking
this to logical conclusion, tiny ATmega328 with 2KB RAM running a
web server is a mainframe.

And looking at classics, IBM360/30 is a mini pretending to be
mainfraime. Pretending, because actual hardware is executing
microcode which is doing interrupt driven character by character
transfers. Only at 360 machine level (which is interpreted by
microcode) one deals with blocks.

That leaves open question what do with Unix machines. Once
networking became popular typical case involved many users
conncected via network. IIUC quite early telnet protocol
included "line mode" option. So, is Unix machine taking
advantage of "line mode" option a mainframe? One can object
that lines are smaller than blocks used on 3270. But
IIUC early mainfraime equipement worked with lines, so I
do not think this is valid objection. One could object
that mere ability to do interrupt driven input disqualifies
machine as a mainframe. But IIUC IBM mainframes allowed
interrupt driven input, normal IBM terminal was limited
to polled block transfers, but mainfraime could be
configured to do interrupt driven character by character
transfers to async terminals.

--
Waldek Hebisch

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 10 Oct 2025 18:45:57 -0000 (UTC), Waldek Hebisch wrote:

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

... mainframes are block-oriented, rather than character oriented.

By that logic machine running a Web server is a mainframe.

Maybe if it?s only running PHP code. The modern Web is a bit more
dynamic than that, with the ability to have full-duplex communication
going on, and parts of the page updating dynamically as a result,
without any full page refresh.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

According to Johnny Billquist <bqt@softjar.se>:

Can you imagine the interrupt overhead if every keypress on hundreds of
terminals instantly generated an interrupt on the host?

That?s exactly how DEC?s interactive OSes operated.

Not on the PDP-10. Terminals were usually hooked up to a front-end ...

Depends what model. The KA10 had a straightforward tty interface with
an interrupt per character. I think that was common on KI also. Someone
said there was a PDP-8i front end but I never saw it.

KL's had a front end PDP-11 which did indeed do a lot of the tty work.

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

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-10 05:54, Lawrence D?Oliveiro wrote:

On Fri, 10 Oct 2025 05:18:02 +0200, Johnny Billquist wrote:

On 2025-10-07 23:57, Lawrence D?Oliveiro wrote:

On Tue, 7 Oct 2025 13:32:02 -0700, Peter Flass wrote:

Can you imagine the interrupt overhead if every keypress on hundreds
of terminals instantly generated an interrupt on the host?

That?s exactly how DEC?s interactive OSes operated.

Not on the PDP-10. Terminals were usually hooked up to a front-end
(usually a PDP-11) which did all of that messy work, and the PDP-10 only
got noted when a whole line was available, and it didn't know or care at
all about individual keypresses.

If you were running something that needed to respond to every keystroke,
like TECO, I don?t see how a front-end processor could help with that.

teco don't respond to every key stroke normally. Maybe you should learn
teco as well?

Johnny


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-11 04:23, John Levine wrote:

According to Johnny Billquist <bqt@softjar.se>:

Can you imagine the interrupt overhead if every keypress on hundreds of >>>> terminals instantly generated an interrupt on the host?

That?s exactly how DEC?s interactive OSes operated.

Not on the PDP-10. Terminals were usually hooked up to a front-end ...

Depends what model. The KA10 had a straightforward tty interface with
an interrupt per character. I think that was common on KI also. Someone said there was a PDP-8i front end but I never saw it.

KL's had a front end PDP-11 which did indeed do a lot of the tty work.

I was/am aware that this differs on model. But if we want to talk
"mainframe", then I think KL comes the closest.

KA probably being the most simple one. Pretty sure there were PDP-8 FE
for the KI, but it's been long since I even looked at on. For KL, there
are no way to even connect a terminal to the KL itself. However, if you
were connecting using ethernet, then the KL cpu would have to do a lot
of the work itself, since there is no FE involved in that path. So
running things interactively over the net was actually pretty bad with a KL.

Johnny


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-11 12:23, Johnny Billquist wrote:

On 2025-10-10 05:54, Lawrence D?Oliveiro wrote:

On Fri, 10 Oct 2025 05:18:02 +0200, Johnny Billquist wrote:

On 2025-10-07 23:57, Lawrence D?Oliveiro wrote:

On Tue, 7 Oct 2025 13:32:02 -0700, Peter Flass wrote:

Can you imagine the interrupt overhead if every keypress on hundreds >>>>> of terminals instantly generated an interrupt on the host?

That?s exactly how DEC?s interactive OSes operated.

Not on the PDP-10. Terminals were usually hooked up to a front-end
(usually a PDP-11) which did all of that messy work, and the PDP-10 only >>> got noted when a whole line was available, and it didn't know or care at >>> all about individual keypresses.

If you were running something that needed to respond to every keystroke,
like TECO, I don?t see how a front-end processor could help with that.

teco don't respond to every key stroke normally. Maybe you should learn
teco as well?

Although, the core point is (I guess) that programs can be wanting to
get every keystroke, which is of course possible to achieve.

Not sure how relevant that is, though. If we're talking about mainframe concepts, and things like terminal handling being offloaded and not done
by the main CPU, that is still the case on the PDP-10. The fact that you
can tell the FE that it should hand every character it receives over to
the main CPU immediately instead of doing more processing locally don't
change the system design having the FE in there, which is the CPU
dealing with the terminal lines.

(And yes, for the nitpicking, I'm mostly talking about the KL when we
talk PDP-10, since that's the most mainframe of the systems.)

Johnny


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 11 Oct 2025 19:26:54 -0000 (UTC), Waldek Hebisch wrote:

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Fri, 10 Oct 2025 18:45:57 -0000 (UTC), Waldek Hebisch wrote:

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

... mainframes are block-oriented, rather than character oriented.

By that logic machine running a Web server is a mainframe.

Maybe if it?s only running PHP code. The modern Web is a bit more
dynamic than that, with the ability to have full-duplex communication
going on, and parts of the page updating dynamically as a result,
without any full page refresh.

Dynamic interaction may mean much more data to send and possibly smaller blocks, but it is still block oriented.

Heck no.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 11 Oct 2025 12:23:07 +0200, Johnny Billquist wrote:

On 2025-10-10 05:54, Lawrence D?Oliveiro wrote:

If you were running something that needed to respond to every
keystroke, like TECO, I don?t see how a front-end processor could
help with that.

teco don't respond to every key stroke normally.

It does, actually. You can see this quite simply: you know how you are supposed to type <ESC><ESC> to execute a command sequence? Try typing the first <ESC>, then another, non-<ESC> character, delete that last
character, then try the second <ESC>, and you will notice that it doesn?t immediately execute the command.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-11 21:54, Lawrence D?Oliveiro wrote:

On Sat, 11 Oct 2025 12:23:07 +0200, Johnny Billquist wrote:

On 2025-10-10 05:54, Lawrence D?Oliveiro wrote:

If you were running something that needed to respond to every
keystroke, like TECO, I don?t see how a front-end processor could
help with that.

teco don't respond to every key stroke normally.

It does, actually. You can see this quite simply: you know how you are supposed to type <ESC><ESC> to execute a command sequence? Try typing the first <ESC>, then another, non-<ESC> character, delete that last
character, then try the second <ESC>, and you will notice that it doesn?t immediately execute the command.

Which, rather than prove your point, proves mine. Teco don't respond to
each keystroke. There are only a few immediate commands, and then the
ESC. Any other character you type are just put into the buffer, to be processed when you hit two ESC after each other. So the only thing Teco
(and thus the OS) is interested in, is when you hit ESC. Everything else
can be saved for later.
You do not need to immediately process the character in between before
the next ESC. And yes, the system can understand that there was a rubout before the second ESC without having to do anything with that rubout immediately. (In fact, there are multiple ways you could make that
effect if you want to go into implementation details, but in the end
Teco don't "respond to every keystroke". In fact it most certainly do not.)

And to illustrate more obviously that TECO don't do things immediately,
just try something like 10D DEL DEL. You will not have the 10 character
after point have been deleted. And it would be quite a feat if TECO
would execute all the changes immediately, and also remember the state
of the buffer before each command, in case you decided to delete that
input again before executing. Some things could not even easily be
undone. You'd go into crazy land if you were to have Teco work that way.

Johnny


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)