|
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
As an Amazon Associate we earn from qualifying purchases.
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.