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

Doug,



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



No direct access to the hardware registers, io ports, ...  I want to
send/rcv a data stream direct to the device.  the system simply encapsulates
my ds with the device addr routing info.

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


What is DSM?  Is it only 5250?  What api's?


>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 device must be plug and play. Attach the cable, the device varies on and
auto configs.

Having to attach to a pc or network station is a step in the direction of
complexity, adds to problem determination, is a barrier between the device
and its real owner, the central computer ( as400 ).  Another piece of equip
needed, something else that can go wrong.

Using the network stn or pc as a connection vehicle. Fine. But it should not
be mandatory. Otherwise the complexity factors jumps, leaving behind devices
that cannot be attached.



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


It would be easier if you told me about it.

How much time needed to add a new device, can I vary the device off from NT,
Can I control the authority to it so only certain users can use it, can I
WrkCfgSts and WrkActJob to see all the active devices and jobs,  what is the
reallistic max nbr of terminals supported?  When I chg a pgm on the NT, is
it usable from all the nt terminals?  Can I end a job running on the windows
terminal?


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


Twinax is what we have. It is our installed base.

Can the speed of twinax be increased?

I am not wedded to it, partly using it as a starting point.

You dont want to attach a toaster, but would you want to attach a set of
monitors, suspend them in the whse managers office and display a running
status of activity in the whse?  All controlled and updated by a data stream
sent from the central as400?

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


I think we differ on the importance of keeping things simple in the real
world. Example: When I have to provide remote support of a network station.
It is a lot harder troubleshooting the label printer attached to a network
station than one attached to a dumb terminal.  I Dont think  the toaster
would be any easier.

There is a tradeoff between simple and flexible. I am proposing the
extension of the simple to make it more flexible.


-Steve Richter




>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>
>