Re: device centric computing. was: PC connection via twinax ?

Steve,

>I agree that direct access to the hardware is inadvisable.

And yet you want 3rd party device drivers, including twinax.  I must be missing
something obvious here, but I can't reconcile these two statements.

>The system should provide api's that enable the sending of a data stream
>direct to the device ( similar to udds but more feature rich )

Um, it is hard to be more feature rich when the existing device doesn't
understand anything but the data stream.

>- open, close channel to device
>- send data stream to device
>- wait, receive, peek for data from device.

DSM does *exactly* that -- including the wait, receive, and peek for data

>no hardware access needed or wanted. device name is provided to identify the
>device.

Again, this is what DSM does.  So where's the beef?  That you can't easily hook
up a non-display/printer device to the system via twinax?

I'm sorry - I just don't see this as a problem.  Twinax has very limited
bandwith.  Why not hook up the device via a NIC and TCP/IP?  You know, like
toasters are supposed to be able to do in the future.

Write sockets programs and use normal TCP/IP protocols.  Again, where is the
beef?

>The attachment of devices, dumb terminals and printers, to the computer is
>something the as400 excels at. Amoung computer systems being sold today,
>only the mainframe has comparable capability?

Ever hear of MS Terminal Services for W2K?  Look it up.

>This is a competitive advantage that we have over NT. More as400's can be
>sold if the device capablities of the system are enhanced.

You are still talking about new devices -- you can't extend the function of
existing devices without changing the WS controller and enhancing the 5250 data
stream.  And IBM has done this from time to time.

Why do you keep thinking that new devices have to be connected via twinax?  New
devices would be much cheaper to develop with off-the-shelf chipsets for TCP/IP
access.  I don't want to run twinax to my toaster.

>Consider what it would take to attach a diskette device to the system. 

>An example. A diskette drive device attached to a terminal at the loading
>dock. 

Actually, I did nearly this back in 1982 or 1983.  But it was a manufacturing
floor, not a loading dock.  A diskless PC (no hard drive but dual sloppy floppy)
had a 5250 emulation card.  Data was collected from multiple RS232 devices on
the floor which monitored quality control and reported the results of tests
performed robotically on machines coming off the assembly line.  (This was a
microware manufacturer, and Fed regulations required keeping on file the exact
coordinates and leakage values by serial number.)  External black boxes were
used to increase the number of serial connections I could make to the PC, since
this was prior to Dialogic cards etc.

The PC would collect the data and store it on floppies without the need for 24/7
availability of the S/3x host.  Shift managers would get live statistics on the
display of production runs, QA ratios, which lines had the worst test results,
etc.

On demand, the manager could transfer the data to the 3x.  Or store the floppies
for later transfer.  The data transfer was accomplished via the APIs to the 5250
emulation program.  This was prior to the availability of PC Support etc.  

The data was archived off the S/3x to comply with Fed regulations in the event
of consumer complaints or mishaps down the road, so the serial number could be
used to find out the original leakage values for the oven.  But the engineers
also did linear regression analysis on the test results to look for ways to
improve the ovens or manufacturing process.

In those days, the IBM solution for interfacing something like this was to put
in a Series/1 as the intermediate box.  When I first got 5250 emulation 1.0 and
saw the APIs, I knew we now had a "cheap" way of interfacing to the 3x.  OI
course, back then a floppy based PC was still about $5K, but that sure beat the
cost of a S/1...

My point is that there are almost always methods to do whatever you want.  And
this was in the days when connectivity was *not* a strongpoint of the 3x.

Today I'd of course never design a system like that, because the 400 *excels* at
connectivity.  Why do you keep thinking you want to do it via twinax?  The 400
has lots better options for non-display devices.

>I am suggesting that the system provide a class of data stream api's to
>enable extended device support.  

Ever hear of TCP/IP?  Sockets?  You *can* talk to your toaster or fridge, when
they come with a network port.

I'm sorry, but I still fail to see your point.  The 400 *can* talk to just about
anything out there.  I can't think of another machine, at any price, which can
talk to as wide a range of communication methods and protocols.

Why design a non-display/printer device to use twinax?  There are plenty of
other options, and the 400 supports just about every one of them I know of
except perhaps USB, Firewire, and IDE.

Doug