× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Doug,

I agree that direct access to the hardware is inadvisable.

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 )
- open, close channel to device
- send data stream to device
- wait, receive, peek for data from device.

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

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?

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.

Device centric computing has the disadvantages that we all know about, but
it also has advantages:  ease of use for the user, quick setup and simple
support.  In some situations the dumb, dedicated device is the prefered
solution: terminal in the whse or factory floor, printing labels, time
clock, bar code scanning ...

The problem with device computing is that the features of the device are not
extensible. Hard to add gui features to the terminal display, limited mouse
support. Adding an image overlay to the forms printer is tough to do.
Vendors have you locked in to their device and charge too much for add ons,
...

Consider what it would take to attach a diskette device to the system. Or a
cd rw drive, a modem, a monitor, a computer hard drive? ...   Similar to the
usb attachment of devices to a pc. You need a hardware interface to the
device, you need installable device drivers on the system. And you need to
be able to send and rcv a raw data stream to the device ( esp if you are
writing the device driver ).

An example. A diskette drive device attached to a terminal at the loading
dock. Used to cut a diskette that contains the tiff image of the material
test report of the material being shipped.  To add a dkt device to our
twinax world you would have a cradle that the dkt drive is inserted into.
The cradle has a twinax port and is cabled thru to the twinax terminal. The
cradle has the intelligence needed to control the diskette device. The data
stream it sends/rcvs to the as400 is not 5250, it is specific to the device
type.

I am suggesting that the system provide a class of data stream api's to
enable extended device support.  No need for an extension of the 5250 data
stream.  Ibm does not have to define any new data stream standards. Just
device type and address basics so the device can auto config, can be varied
on and off.   Allow the device vendor to supply the device drivers, to
define the data stream used to talk to the device.

etc, etc

Steve Richter



-----Original Message-----
From: Douglas Handy <dhandy1@bellsouth.net>
To: midrange-l@midrange.com <midrange-l@midrange.com>
Date: Friday, August 17, 2001 7:28 PM
Subject: Re: PC connection via twinax ?


>
>I can't provide definitive answers to those questions -- but IMHO one of
the
>hallmarks of a "real" operating system is that it *does* prevent you from
having
>direct access to certain hardware components.  Witness the difference
between
>Win 9x and NT, and the compatibility problems with games etc which will not
run
>on NT because they are blocked from techniques which they never should have
used
>in the first place...
>
>>a valid response is: what is gained by ibm in not releasing what I have
>>described.  It is not a threat to system integrity.
>
>It's not?  Allowing a user program "direct" access to hardware is not a
threat
>to system integrity?   You mean NT would be no less stable if it allowed
games
>et al to manipulate all the hardware registers and OS hooks possible in
Win9x?
>Then why doesn't MS just open back up access to the hardware from NT?  They
>could have had the convergence of the Win 9x and NT code base done much
sooner
>I'm sure.
>
>Allowing a RPG program "direct" access to the WS controller instead of just
>direct access to the data streams (ala DSM or UDDS) is no threat to the
>stability of the other programs also using the WS controller?
>
>I trow not.
>
>>also, maybe there could be more twinax type attachments. Any use for a  cd
r/w
>>device attached thru twinax and controlled by a user written rpg pgm?  Or
fax modem?
>
>This seems to me the exact *opposite* of what you want.  I want fewer
twinax
>connections, not more.
>
>We *used* to see more twinax type attachments -- like the tape drives I
>mentioned for a S/36.  Or data transfer box between the 3x and 400.  I
believe
>some vendors do (or did?) have fax controllers which attach via twinax.
>
>Face it.  Twinax is not fast -- you don't want to use it for something like
CDRW
>access.  And just think what one of the those twinax tape drives or the
data
>transfer box would do to the CFINT govenor.  It would probably think 5250
data
>traffic was going through the roof.
>
>It *used* to be that PCs used 5250 traffic even for batch processes like
data
>transfer -- I know because I used to write them even before PC Support/36
>existed as I explained in a previious post.
>
>Now network attached PCs can do batch and client/server work without using
5250
>data streams to do it.  And they don't count against the CFINT govenor.
>
>Why in the world would I want to attach some new device via slow twinax
when it
>could be connected via TCP/IP to a fast network interface or some other
bus?
>
>Doug
>
>_______________________________________________
>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
>
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.