Re: Bug busting session next week.

On a side note to your discussion about underlining:

In FreeBSD, running XFree86 (as far as I know, all versions) when theres
a "real" underline, it resets the attributes for the colors when an
underline ends.   This results in the colors being goofy, unless:

1) You turn off underlining and use the -u (or put us@ in termcap) 
2) You turn off colors, and use it monochrome.



Mike:
I have an updated termcap file, 5250keys script and an XTerm file for
FreeBSD.   Can we include these in the distribution?   can the Makefiles
be changed to install the freebsd stuff in the same place that you're
installing the linux version of the XTerm file, when its FreeBSD?

Thanks.



On Wed, 5 Apr 2000, Jason M. Felice wrote:

> First note, I've re-added the -u flag in CVS to force tn5250 to use 
>underscores
> instead of the underline attribute.  This was removed at one point because I
> figured out how to detect that the terminal type supports underlining.
> Unfortunately, the terminal type isn't necessarily the terminal.  For example,
> underlining supposedly works on an xterm, and does according to the xterm
> termcap, but you can configure your xterm to show a different color text 
> instead of underlining (about the only thing this is good for is showing
> man pages...  blah).  Also, the `linux' terminal type supports underlining,
> but a VGA linux console does not.  However, I'm guessing that a fb linux
> console would (there is no reason that it couldn't).
> 
> -u forces the use of underscores.  Otherwise, the presence or absence of
> the "us" terminal capability determines what we use.
> 
> Also, please don't see this reply as a commitment to performing the following
> bug-fixes.  I hope I can help out, but can't promise anything.
> 
> On Wed, Apr 05, 2000 at 09:50:25PM +1200, Carey Evans wrote:
> > Mike Madore <mmadore@mail.turbolinux.com> writes:
> > 
> > > I am going to have access to an AS/400 for the week of April 10th.  I
> > > would like to get a list of outstanding bugs so that I can make maximum
> > > use of my time while I am there.
> > 
> > Here's some bugs I'm aware of at the moment.  Let me know if you want
> > tracefiles for any of them.
> > 
> > * BUGS
> > ======
> > 
> > ** Cursor positioning.
> > 
> > The cursor doesn't appear in the correct place in at least two places.
> > Instead it appears at the start of the first field.  In particular,
> > this happens with DFU.  On a slow link, I see the screen appear with
> > the cursor in the correct place, then X SYSTEM is displayed again, the
> > function key labels are drawn, and the cursor pops up to the first
> > field.
> > 
> > It also reappears in the first field if a break message is displayed.
> > It should come back exactly where it was before.
> >
> 
> I thought we fixed this in 0.15.8...
>  
> > 
> > ** Assertion 0 failed at session.c, line 339.
> > 
> > This appears when the X SYSTEM display isn't showing, when a real 5250
> > or Client Access does show it.  I can duplicate this in two places:
> > edit a record in DFU and press Enter several times quickly; or exit
> > from interactive SQL and press Enter very quickly twice.
> > 
> > Both of these seem easier to get on a slow link.
> > 
> > 
> > ** Field Exit in Field Exit Required position.
> > 
> > In a field exit required field, pressing Field Exit with the field
> > filled and the cursor in the Field Exit Required state erases the last
> > character.  The last character should be left alone, unless something
> > has to be done for signed fields.
> > 
> > DFU fields seem to be FER by default, so this is a good place to test
> > this.
> >
> 
> Oops, dropped off my to-do list.
>  
> > 
> > * BUGLETS
> > =========
> > 
> > ** Non DEC-alike terminals.
> > 
> > On terminals such as the IBM 3151 where some of the keypress escape
> > sequences are the same as our built-in keys, or longer, then those
> > keys will never get detected.  For example, F13 to F24 on the IBM 3151
> > begin with "^[!", but this is F13 in tn5250.
> > 
> > curses uses its delay to guess whether "^[ ! h ^M" is "Meta-! h Enter"
> > or F20.
> >
> 
> This should be resolved with a delay, and with precendence when loading
> the key mappings.  One good question is, when a terminal maps Esc+A as another
> key, should Esc+A be attention or the other key?
>  
> > 
> > ** End of field in an empty field.
> > 
> > Pressing End on the QCMD display, when nothing's been entered, moves
> > the cursor two the second position in the field.
> > 
> 
> Hmm, I wonder if there's a blank in the field as it is sent to the emulator.
> 
> > 
> > ** Screen redraws on 80 -> 132 column switch.
> > 
> > Sometimes, when the screen is switched to 132 columns, it isn't
> > redrawn until the next keyboard activity, including Esc on its own,
> > which doesn't generate any screen output.
> > 
> 
> I still have never been able to duplicate this, so I can only assume it is
> a bug with a particular xterm/curses/X windows.  Right now, we are doing a
> few things to ensure that the signal is getting delivered.  I know that
> resizing probably won't work at all on systems which don't support SIGWINCH,
> and this would be pretty much anything other than BSD and Linux (well, maybe
> Sun*)
> 
> > 
> > ** recv with buffer length of 1.
> > 
> > telnetstr.c line 224 always reads just a single character.  Each
> > recv() results in a system call, and even on Linux this is quite
> > expensive, since it requires a context switch into and out of kernel
> > mode, and the TCP/IP drivers probably aren't designed for this access
> > pattern either.  tn5250 would run faster if some kind of buffering was
> > used.
> > 
> > In addition, SNA itself is more of a datagram protocol, which the
> > tn5250 datastream emulates with GA.  It might be easier to deal with
> > this if tn5250 gets ported to SNA, if buffering is implemented now.
> > 
> 
> While SNA is a datagram protocol, telnet is not.  The telnet stream underling
> the data must be processed as a stream.
> 
> However, I agree that we should probably implement some sort of buffer.  I
> think we are already doing non-blocking IO, so this should not be a problem.
> (Just read as much as we can in one swipe).
> 
> > 
> > 
> > * WIBNI¹
> > ========
> > 
> > ¹ Wouldn't It Be Nice If....
> > 
> > Some terminals only have 24 rows.  Maybe X SYSTEM, etc., should
> > obscure the line above in this case, so that the user can still get
> > some idea of what's going on.
> 
> This would be fairly neat if implemented correctly, which would mean 
>displaying
> the 25th line of the terminal on the 24th unless the cursor is on the 24th
> line.  You would also need to display the 24th line for a second after the
> 24th line was written to so that the user understands that there is a field
> there (or something).  And you would need to flash the 25th line if an
> indicator (such as message waiting) changed.
> 
> That's probably a little bit of work.
> 
> > 
> > On terminals that don't support blinking text, such as xterm, tn5250
> > could do it itself by repainting the fields every half a second.  This
> > would have to be easily disabled if it was the default.
> 
> Ick!  Well, okay, but I recommend off by default.  If I'm getting serious
> lag and I start up tn5250, I want to be sure that I can still _type_.
> 
> > 
> > IBM's Client Access for DOS does the underscore-for-underline trick,
> > but it doesn't draw the underscore for spaces that have been typed
> > in. only for positions containing nulls as far as I can tell.  I'd
> > gotten used to this.
> 
> Eiww.  I don't like that.  Maybe an option which is off by default.
> 
> > 
> > tn5250 seems to repaint the whole screen more often than needed.  It
> > would be nice if only the parts that were changed in the datastream
> > received from the AS/400 were redrawn, with a key like ^L or ^R to
> > redraw the whole screen if this goes wrong.
> 
> I've noticed with this and another project recently that curses redraws
> maybe a bit too often.  Curses is supposed to handle buffering the screen
> and making sure that you actually update as little as possible, but sometimes
> it decides just to redraw the whole screen.
> 
> If/when I get more time to work on this project, I wanted to eliminate curses
> completely from the loop (now that I've done the hard part) and handle our
> own buffering.  It's simpler for us to do because we don't have to worry about
> nearly as many cases.
> 
> > 
> > The latest versions of IBM Client Access Express will work out which
> > session name to use if the first one isn't available.  My PC is
> > configured for a session name of "+&COMP%=", which tries "EVANSCS1",
> > "EVANSCS2", etc. until one of them works.  It would be nice to be able
> > to do this in tn5250 too.
> 
> I'm not sure we have the ability to do this... this might be one of those
> things CA uses a different service (other than tn5250) to do.  I beleive
> that if we try to connect but the device is already in use, the session
> just hangs (e.g. it exists as if it were normal, but doesn't send any data
> to user).
> 
> 
> > 
> > System Request is supposed to display a line for the request number to
> > be typed on, instead of going straight to the menu.  This is
> > definitely not a priority, but I wanted to mention it.
> 
> Hrmm???
> 
> > 
> > 
> > -- 
> >      Carey Evans  http://home.clear.net.nz/pages/c.evans/
> > 
> > "Validate me!  Give me eternal digital life!  Quote me in your .sigs!"
> >                                                              - djc in asr
> > +---
> > | This is the LINUX5250 Mailing List!
> > | To submit a new message, send your mail to LINUX5250@midrange.com.
> > | To subscribe to this list send email to LINUX5250-SUB@midrange.com.
> > | To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator: 
>david@midrange.com
> > +---
> 
> +---
> | This is the LINUX5250 Mailing List!
> | To submit a new message, send your mail to LINUX5250@midrange.com.
> | To subscribe to this list send email to LINUX5250-SUB@midrange.com.
> | To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
> 
> 

+---
| This is the LINUX5250 Mailing List!
| To submit a new message, send your mail to LINUX5250@midrange.com.
| To subscribe to this list send email to LINUX5250-SUB@midrange.com.
| To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---