Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!swrinde!ucsd!hub.ucsb.edu!spectrum.CMC.COM!lars
From: lars@spectrum.CMC.COM (Lars Poulsen)
Newsgroups: comp.dcom.lans
Subject: Re: Info req on IBM370 I/O channel
Keywords: IBM 370 channel network protocol
Message-ID: <1990Oct3.185932.29713@spectrum.CMC.COM>
Date: 3 Oct 90 18:59:32 GMT
References: <186@canstar.UUCP>
Organization: Rockwell CMC
Lines: 57

In article <186@canstar.UUCP> khasin@canstar.UUCP (Kha Sin Teow) writes:
>I'm involved in solving a problem which involves the IBM I/O channels and
>many I/O devices connected to the channels.
>
>There is a proposal/suggestion to replace the existing 370 (and channels)
>with a network of vendor independent high-powered micro/mini computers such as
>Sun workstations, MIP machines, etc.
>The network must also be vendor and protocol independent.
>However, the I/O devices on the "bus and tag" side of the channel must
>remain.

The IBM-360 data channel is also known as the "FIPS channel" because the
US Government mandated that all mainframe vendors must support it in
order to protect the existing investment in disk and tape drives etc
without locking data centers into a single vendor. It is, however, an
obsolete standard, and I think most IBM peripherals are not even
attached that way any more. The SCSI channel is sort of a modern-day
successor to the IBM channel.

The signaling scheme of the channel is straightforward and well
documented, and can be implemented by any 8-bit microprocessor with a
couple of parallel I/O ports, but in order to be useful, they must also
implement a number of higher-order protocols, which may not be practical
for small systems. In particular, many control units (what sits out on
the channel, attaching preipherals to the BUS and TAG cables) usually do
not have much, if any, buffering (not much means 2-8 bytes of fifo), and
thus the channel must be capable of absorbing/generating data at device
speeds. For disks, this means keeping up with the rotational speed of
the disk as it moves under the heads. Also, some devices require that
the channel do "command chaining", where the channel issues a new
command IMMEDIATELY when certain "prep" commands terminate. Many channel
emulators cannot do this.

When it comes to remote access to a farm of IBM peripherals, I guess the
leader would be Network Systems in Minneapolis, who built the
"Hyperchannel" as a local area network that looked like a cable full of
control units to the mainframe, and looked like a mainframe to the
control units plugged into it. This allowed data centers to set up
high-speed printers and terminal clusters at client sites. Versions
existed that would link up over T1 lines, too.

What peripherals is it that you want to retain ?
Old disk and tape drives are just not cost-effective compared to the
never, smaller footprint, larger capatity drives. Old magtape drives are
not very useful for the modern computing environment. And old IBM
terminal clusters cannot really be made compatible with the UNIX
environment.

The most useful of the old stuff is 1401 line printers. There is a
company called SPUR that has a unibus-to-channel converter emulating a
DEC LP-11. You might be able to put that on an ULTRAX machine in your
network.

Hope some if this is useful to you.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM