The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: paul.winalski@gmail.com (Paul Winalski)
Subject: [TUHS] UNIX on S/370
Date: Mon, 20 Nov 2017 14:44:03 -0500	[thread overview]
Message-ID: <CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com> (raw)
In-Reply-To: <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>

On 11/20/17, Clem Cole <clemc at ccc.com> wrote:
> On Mon, Nov 20, 2017 at 11:03 AM, ron minnich <rminnich at gmail.com> wrote:
>
> IMO: The issue was less understanding how channels worked, as much as the
> biasing between the UNIX I/O model *vs.* the mainframe I/O model.   360 and
> CDC boxes for that matter, were a coprocessor that was programmed for the
> I/O.   Figuring out how to splice that into the UNIX world efficiently was
> not always easy.

The PDP-11 and VAX used memory-mapped I/O.  Devices presented
themselves to the CPU as special areas of main memory.  Instead of
retrieving or storing data, these memory locations performed device
operations when you read or wrote to them.

System/360/370 had a radically different I/O model.  I/O devices and
their control units were connected to specialized coprocessors called
I/O channels.  Devices were addressed via a number with three hex
digits, the first of which was the channel number.  The CPU had an
instruction called start I/O (SIO) that took as parameters a device
address and the address of a series of channel command words (CCWs)
that indicated to the channel the I/O operation to perform and its
parameters (such as the address of the I/O buffer in main memory).
The CPU was notified of I/O termination by three interrupts:
channel-end (the I/O channel reached the end of its channel program),
control-unit-end (the I/O control unit completed a command), and
device-end (the I/O device completed a command).

CCW programs were capable of primitive conditional branching and
looping.  It was possible to set up a channel program to perform
sequential multi-buffered reading or writing, using the device-end
interrupts to determine when each buffer was free for reuse.  If no
I/O errors occurred, it was possible to read or write a whole tape
file with a single SIO instruction.

-Paul W.


  reply	other threads:[~2017-11-20 19:44 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-20  0:57 Nemo
2017-11-20  1:01 ` Ronald Natalie
2017-11-20  1:06 ` Dave Horsfall
2017-11-20  3:50 ` arnold
2017-11-20 15:23   ` Clem Cole
2017-11-20 16:03     ` ron minnich
2017-11-20 16:31       ` Clem Cole
2017-11-20 19:44         ` Paul Winalski [this message]
2017-11-20 19:56           ` Larry McVoy
2017-11-20 23:43             ` Ron Natalie
2017-11-20 23:45               ` Larry McVoy
2017-11-20 23:49                 ` Ron Natalie
     [not found]                 ` <CAC20D2N=aBhdON1YqHH57ZG-TmC62yWGF4_=HK5Gp2XwdbHkyQ@mail.gmail.com>
2017-11-21  2:41                   ` Larry McVoy
2017-11-29 22:42                     ` Dave Horsfall
2017-11-29 22:55                       ` ron minnich
2017-11-21  1:15     ` Ron Natalie
2017-11-21  3:29       ` Grant Taylor
2017-11-21  3:40         ` Ron Natalie
2017-11-21  3:46           ` Grant Taylor
2017-11-21  8:09             ` arnold
2017-11-21 16:49             ` Paul Winalski
2017-11-21  4:34           ` Clem cole
2017-11-21  5:42             ` Grant Taylor
2017-11-21 12:00               ` Ron Natalie
2017-11-21 13:51                 ` Clem Cole
2017-11-21 14:59                   ` Larry McVoy
2017-11-21 17:06                     ` Clem Cole
2017-11-21 17:23                       ` Clem Cole
2017-11-21 18:29                         ` Larry McVoy
2017-11-21 19:10                           ` Clem Cole
2017-11-21 15:40                   ` Ron Natalie
2017-11-21 15:45                     ` Larry McVoy
2017-11-21 13:24               ` Clem Cole
2017-11-22  1:33 ` Kevin Bowling
2017-11-22  6:35   ` Wesley Parish
2017-11-22  9:38     ` Kevin Bowling
2017-11-22 13:40       ` Clem Cole
2017-11-22 14:09         ` Ron Natalie
2017-11-22 13:51     ` Clem Cole
2017-11-22 14:04       ` Ron Natalie
2017-11-20 16:05 Noel Chiappa
2017-11-20 16:37 ` Clem Cole
2017-11-20 16:47   ` Charles H Sauer
2017-11-20 17:44     ` Toby Thain
2017-11-20 19:07 ` Paul Winalski
2017-11-20 19:10   ` Larry McVoy
2017-11-20 19:36     ` Warner Losh
2017-11-20 19:36       ` Larry McVoy
2017-11-20 19:39         ` Larry McVoy
2017-11-20 19:56     ` Arthur Krewat
2017-11-20 19:59       ` Larry McVoy
2017-11-20 19:27   ` arnold
2017-11-20 19:29     ` Larry McVoy
2017-11-20 22:56       ` Michael Parson
2017-11-20 23:23         ` Larry McVoy
2017-11-21  2:56 Noel Chiappa
2017-11-21  3:15 ` Ron Natalie
2017-11-21  3:51   ` Larry McVoy
2017-11-21  5:14     ` Warner Losh
2017-11-21  5:20       ` Larry McVoy
2017-11-22 15:38 Noel Chiappa
2017-11-28  0:13 ` Kevin Bowling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com' \
    --to=paul.winalski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).