Wyse Winterm(tm) 5000 Network Terminal

(Note: Winterm is a trademark of Wyse Technology, Inc)

This review is going to have to be broken up into several parts: there is just too much to cover all of it in one article.

Let me tell you first that from the time I first unpacked the unit, and all through setting it up, configuring it, and beginning to use it, I kept saying things like "Neat!", "Wow!", "Oh, good!". I have setup and used the older WinTerms in a Citrix environment in the past, and I've also used the NCD versions, so I've had some experience with this kind of device, and this new model was full of pleasant surprises.

What is it?

It's a Winterm(tm).

An X-Terminal.

A Workstation.

A Network Terminal.

A Tarantella client.

It is all of that and more in a $699.00 (list price) box. That's the price for the 5315SE model, to which you attach your own monitor. The Local Boot PCMCIA card is another $199.00, see Wyse Web Page for details.

Physically, this is a small box designed for desktop or even wall or under-desk mounting. It took me a while to understand that the extra hardware I received wasn't necessary if I just wanted to set it up on my desk. Attaching that hardware is explained in the on-line CD manual, but that, of course, was the very last thing I looked at.

The backpanel has all the connectors you need, even including headphone and microphone ports. The PCMCIA slot is designed to accept a Local Boot Option card, which means that it doesn't even have to be connected to the network- it can boot up all by itself, and if attached to a modem, can connect to an ISP for telnet, browsing, and POP3 email.

That was the first functionality I configured. After unpacking the box and installing the local boot PCMCIA card, I connected all my cables and turned it on. I used an old Dell monitor that is pretty much retired from active use these days. I knew it wouldn't be able to give me more than 640 x 480 resolution (the Winterm(tm) supports up to 1024 x 768), but that would be OK for testing.

The terminal did have some trouble syncing up to that monitor, and for a few seconds I thought I was going to have to haul something better over, but the old monitor finally did come to life. It takes just about a minute for the boot, and then presents a desktop. I fooled around a bit, looking around the menus, and checked out the online help built into the firmware. That was pretty good, and it has a button for more help that will take you to Wyse's web site if you are connected to the Internet. Of course, if that's part of what you are having trouble configuring, that option can't do you much good. I decided it was time to connect up to my ISP and give this something to do.

I started by configuring one of the serial ports:

I screwed this up at first, because I misunderstood the "Dialout" box. It's intended use is for phone systems where a "9" or other string is required before dialing; you might use this to disable call-waiting, too.

It's also not obvious that you must choose "New" before filling in anything; if you don't, you can't save what you typed. The manual doesn't explain how much NVRAM is available for multiple configurations.

Other than that, there's not much too this. A phone number, perhaps ATZ for initializion, and the normal ATDT as a dial command, and it's pretty well ready to go. I did select hardware handshaking because I knew I was going to use this for PPP.

Then it was on to configuring the actual connection. This time I knew enough to hit "New" before trying to type anything. I chose the serial connection I had previously defined, typed in my domain and DNS server information, and then defined a login script using the same chat style format you'd use for a uucp connection. My only complaint about that is that the interface doesn't seem to allow inserting new expect/send pairs; if you screw it up, you have to delete and start over. Still, most chat scripts are pretty simple, and once it is done you won't be coming back here very often, except perhaps to change passwords, and editing individual lines is simple, so I don't see this as a problem.

The rest of the configuration is straightforward, except that it confusingly insists upon your filling in a Local Host name, which has to be a name defined with an ip address in the Hosts table. If your ISP has assigned you a static IP address, that's the address you would associate with the name you put in that box. Yet you'd also put that address in the Local IP address box, and if you have checked off that the remote and local ip address will be provided from the server (the ISP), it makes no sense to have to fill this in. However, the software requires that you do so. This had me confused for a while, but once I was satisfied that it would, in fact, be ignored, I just filled in in with the name of my ISP's server.

To make the connection, I simply chose System->Serial Networking, and then clicked "Connect" in the dialog box. One minor gripe is that neither the status box nor the System messages show much detail about what is happening; I'd like to see an option to increase the level of detail for debugging.

However, in a very few seconds, I could see that my modem had negotiated a PPP connection, and the status box confirmed that I was connected.

My first connection was through the Terminal application. This offers the typical VT emulations, Wyse 50 and Wyse 60, and even SCO Console. Nothing exciting there, but certainly all the basic functionality you could need.

Next, I tried the email client, configuring it with my ISP's POP3 server address. As there's no local storage, the client doesn't delete messages automatically, and it also has to attach to the server at least twice for each message: once to get the header, once to retrieve it for viewing, and yet again if you want to delete it. This is a little disconcerting on a dial-up link, but would work nicely on a local network.

Finally, I tried the browser, and that's where I ran into my first bit of trouble: it couldn't connect to anything. If I had tried the browser first, I would have suspected something seriously wrong, but as I knew that I had working PPP, this seemed strange, yet the error was definitely tcp/ip related.

For lack of anything else I could do, I turned off Van Jacobsen header compression, not really expecting this to fix anything. However, after reconnecting with VJ turned off, the browser worked perfectly!

The browser, by the way, is a Mozilla version, and does not support Java. That limits its functionality rather severely, but then again you don't have to run the builtin browser: this is, after all, both an ICA client and an X-terminal, so once it's connected to the network, you can run whatever you want.

And that configuration will have to be the subject of another article.

© January 1999 Anthony Lawrence. All rights reserved.

Click here to add your comments


Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Why no "Digg this!" etc.?

My Unix/Linux Troubleshooting Book

My Hard Truths about Easy Money Book

My Self Employment Book

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here