Re: [LINUX5250] replacing dumb terminals

[Scott Klement <klemscot@xxxxxxxxxxxx>]

On Tue, 14 Aug 2001, tonyl wrote:
> 
> Has anyone used tn5250 & linux to replace dumb terminals, specifically for 
> the sort of user that enters data all day, every day?

Not under linux, but the same tn5250, compiled under FreeBSD is used
here in that scenario.   Of course, that also means that I use the FreeBSD
keyboard maps in console mode...   I've tried the Linux console mode maps,
but they seem to be missing some of the vital keys...

> The keyboard mappings! Though it looks like most can be brought into line via 
> config files, judging by the list's archive it would appear that the are 
> still issues. Has anyone got it exactly as one would expect from using 5250?

The biggest problem with the keyboard mapping, right now, is that it's
rather complicated / non-intuitive.   The reason for this is the way that
the Unix & Unix-like systems deal with the keyboard is that they treat
them like DEC VT-xxx terminals.   

Someone should probably write a more user-friendly program that will 
generate the keyboard mapping files as much as possible... (feel free
to volunteer!)

> 
> Another concern is reliability. My experience has left me with the impression 
> that tn5250 has problems launching in X. Sometimes it connects to the host, 
> others it doesn't. Initially I had no such problems, where as now it's quite 
> common.

Hmmmm... this one I haven't run across before.   The only time that xt5250
has trouble, in my experience, is when the xterm-5250 terminal type can't
be found...   

> 
> 132 column displays appear to be unfinished/buggy, in that going from 80 to 
> 132 (wrksplf, seu etc) stretches the window accordingly but leave the screen 
> mode in 80 columns; however, not every time.

Hmmmm....  under which version of tn5250?   I occasionally have problems
with tn5250 only re-drawing columns 1-80, rows 1-25, but hitting a key 
always fixes the problem.   Is that what you're talking about?

This appears to be due to a race condition of sorts.   After cursesterm.c
raises the SIGWINCH signal, and calls resizeterm() and refresh(), it
sometimes gets back a 80 x 24 when calling getmaxyx().   I was thinking
of coding a loop like this:

        for (x=0; x<100; x++) {
           getmaxyx(stdscr, my, mx);
           if (mx==tn5250_display_width(display)) {
                break;
           } else {
                refresh();
           }
        }

But, this seems like a horrible kludge.  Perhaps someone else has a better
idea?

> 
> I'm hoping most, if not all of these problems are related to my configs, X, 
> KDE et al. 
> 
> Feedback would be appreciated from anyone who's been through this before.
> 
> Thanks,
> Tony.
> 
> PS. Any '400 programmers using it full-time instead of doze/client access?
> 

I'm a '400 programmer (I just mess around with FreeBSD/Linux for fun) and
I use tn5250 full-time.  

Never really used Client Access -- Under Winblows I always used Rumba by
WallData (or whatever their name is this week) and it wa pretty good...
However, I *have* found bugs in Rumba that tn5250 did not have, so I'm
pretty happy with tn5250, too...  :)