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

Steve,

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

Dynamic Screen Manager.  It has its own API manual.

They are wrappers to the 5250 data stream to make it easier to use than UDDS.
It lets you interact with a display *without* needing a display file.  You can
dynamically create screen layout, size/position and attributes of fields, yada,
yada, yada.

In short, dynamically manage the screen.  As I recall, the DSM api's were added
in 1993.  They must be called from a ILE language.  At the time, that meant C,
so they were not widely used.

With the advent of RPG IV they became available to the "masses".  They are good
for utility type work because you can do anything the device is capable of.  It
is your "direct" access to a display device.  Open/close a device.  Send data
streams.  Wait for or peek at device data.

Note that due to the OS/400 architecture, it is not restricted to real 5250
devices.  Direct it to a regular telnet session (not TN5250) and it still works
-- just like a display file's 5250 data stream gets mapped for use by the ASCII
WS controller, a 3270 controller, etc.

>Having to attach to a pc or network station is a step in the direction of
>complexity,

I didn't say that.  Your toaster will not need to plug into a PC -- it just
plugs into the network.  The same as other devices: PCs, printers, JetDirect
servers, refridgerators, whatever.

I'm not a hardware engineer, but my understanding is that the hardware cost for
the TCP/IP support chips was under $10 many years ago.  And considering the
price of many NICs these days, I believe it is likely to be well under that now.
Just design the device to connect directly to the network.

Again, I'm not a hardware engineer so I can't tell you how to do that.  But my
understanding is that *off the shelf* components (for an engineer) make that
readily available and very, very cheap.

No extra PC to add complexity etc.  My story of 20 years ago was about how you
*could* do that even via twinax before we had other connectivity options.

Plug the device into the network. Telnet to it o configure it like a JetDirect
box (if the chips have this support), or use address switches or whatever to set
the IP address before you plug it in.  Then just write a batch program to talk
to it over the designated port(s).

>>Ever hear of MS Terminal Services for W2K?  Look it up.
>
>It would be easier if you told me about it.

Easier for who?  I'll give you a quick lesson.  Go to www.google.com and type:

"terminal services" site:microsoft.com

Google is very good at searches; you should try it sometime.  <g>  Especially
when you know to limit it to a certain site like I did above.  But tell you
what, here is the very top link which Google returns:

http://www.microsoft.com/windows2000/technologies/terminal/default.asp

It is a good starting point for reading what Terminal Services is, and has links
to sub pages for various categoris of information.  It is much more than I can
just tell you about here.  Even if I knew all about myself, which I don't.

But in a nutshell, it provides the capability to have NT applications execute on
a W2K server, with just the keyboard/video/mouse traffic going across the
network -- very much like a "dumb terminal" or "thin client".

Here is one paragraph from the link to one of the overview pages:

"Terminal Services allows you to provide a consistent desktop environment to
more people in your organization by letting you deliver the Windows 2000 desktop
and latest Windows-based applications to virtually any desktop computing device,
including those that cannot run Windows. Find out how."

>How much time needed to add a new device,

That may depend on what client (ie terminal) you use.  Since TS is relatively
new, I don't think there is much on the market yet other than what MS has put
out to allow PCs to act as clients.  MS may be hoping for that to change.

But one way to do this is to take a very bare bones Win95 PC.  The kind
relagated to the closet long ago because it was too slow, not enough memory or
disk, etc.  It will work for this, so I'm told.

Do a minimal configuration.  Pull out just about everything.  Install Terminal
Services Advanced Client.  (Think of it as Client Access emulation, but for NT.)
Have Terminal Services load automatically on boot.

Now Ghost the disk drive.

Future setups, or a complete reload on any PC which gets messed up can be done
in minutes by using the Ghost image  You could even just keep a few drives
laying around which were pre-Ghosted.  Just slap it in and power it up.

Aside from having to set an IP address, I don't think much else is required.

Note that you do *not* need a fast PC for this.  It only has to keep up with
sending the keyboard/mouse activity, and updating the screen.  All processing is
done on the W2K server.

Kinda like programs on the 400.  Kinda like running pcAnywhere, except it
supports multiple users at once -- each with their own desktop (which is kept on
the server, not the client).

I have *not* used it myself.  So I can't give definitive answers about it.  But
I recently had some offline email exchanges with someone who had bought a used
Dell server with 4 processors and loaded Terminal Services on it with 20 client
licenses.  His total cost for hardware and software was under $5K (not counting
the old PCs used as the terminals, but counting TS and the TS client software
licenses).  The PCs used had previously been abandoned as underpowered.

He said with 20 users the Dell cpu usage was still very nominal.  I think the
network traffic was under 1%.  He figured it could scale fairly large, at least
by his standards.  It was kinda funny, because he was so excited about what it
meant for centralised support and administration.  One upgrade or software patch
on the server and everybody had immediate access to it.

Network traffic was minimal, because programs weren't loaded across the network.
Data traffic like SQL result sets did not travel across the network. Just the
user interface.

He had never worked in an environment with dumb terminals, so he thought this
was a really nifty concept.  He probably figured MS invented the idea...

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

Don't know.  Read the links .

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

Ah, so that is why you keep hounding on twinax.  But that is a different story.
It is *not* the 400 which does not have plenty of connectivity options.  It is
*your* wiring which does not.

IBM *did* add connectivity.  You just don't want to use it, and now want them to
do it on your terms too.

>Can the speed of twinax be increased?

I believe I heard once that it got increased from 1Mb/s to 2Mb/s.  Oh boy.  That
makes it just barely faster than the 1.6Mb/s wireless cards which are so cheap
now that 11Mb/s wireless is here.

So you have twinax cabling, but want to add a new non-twinax device.  Design it
with a network interface and use a 11Mb/s wireless connection.  Much faster than
twinax.  And much cheaper to design/impelment than a custom twinax interface.

Twinax is *not* the future.  Deal with it.

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

You could do that decades ago using twinax.  Make the monitors regular devices,
and use multiple device support from a WS program to direct whatever you want to
each monitor.  No big deal.  See F-spec keywords DEVID and MAXDEV(*FILE).

This is the same concept as using a batch program and acquiring devices to use
as a kiosk, except you hide the keyboards.  You don't need (or want!) full
device capability in cases like this, so you just acquire the device and control
it yourself.  RPG has done that since I worked on the S/34.

>I think we differ on the importance of keeping things simple in the real
>world.

(snip)

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

Which by definition makes it less simple.

Going back to your printer example.  I didn't say attach it to a network station
(ie thin client).  Attach it direct to the network.  Not even a dumb terminal.
Now it is even *easier* to administer.  You don't even have to go to it.  You
can telnet to it from your desk, even if that is thousands of miles away
(firewall permitting of course).  For printers with just a par port, pickup an
external Jet Direct box like I did.  Mine has three ports, although I currently
only have one printer attached.  I paid about $40 on eBay.

To me, the idea of designing new twinax devices just to use existing cabling is
lludicrous unless you think there is a huge potential market for the device.
The only thing which may fall in the this category are the TCP/IP over twinax
cards.  But I don't know much about these -- I use CAT5 wiring everywhere except
to a system console.

You want some low-volume market specialized device?  Slap in an off-the shelf
TCP/IP chipset and use wireless if cable runs are too costly.

Bottom line:

The 400 *does* offer *excellent* connectivity.  If offers "direct", dynamic
access to data streams for displays or any network device.  You can hang
multiple monitors in the manager's office and update them all easily from a
single RPG program, using a standard display file.

Doug