Re: assertion fails on DSPF

Hi Scott,

Thanks for the patch.  I have not figured out yet what the ideal solution
is.  The problem is that the RQN1251 error seems to be caused when the
terminal receives characters which should signal the start of a command,
but subsequent bytes are invalid.  A real terminal, I assume, can send
back an error to the AS/400, which is why we get RQN1251 on real hardware.

Unfortunately, I don't know if we can send back an error to the AS/400
over tn5250, so we may not be able to mimic the behavior of the real
hardware exactly.  

Mike Madore

On Thu, 27 Apr 2000, Scott Klement wrote:

> 
> Mike/Steve,
> 
> The attached patches for cursesterm.c and utility.c will fix a number of
> the "non-display" character problems.   It doesnt fix them all (by a 
> long shot) but it works for many of them (at least, on my system)
> 
> Perhaps you guys could try them out, and if they're an improvement, add 
> them to the CVS source?
> 
> Thanks...
> 
> Scott
> 
> 
> On Wed, 26 Apr 2000, Mike Madore wrote:
> 
> > Hi Steve,
> > 
> > Thanks for the info.  This is part of a more general problem where we
> > don't handle non-display characters correctly.  I need to come up with a
> > more generic approach.  Will put this on my to-do list.
> > 
> > Mike
> > 
> > On Wed, 26 Apr 2000 stevefx@us.ibm.com wrote:
> > 
> > > I am having problems with an assertion failing when DSPF is used on a
> > > OS/400 development release, it blows up right away. I contacted the owner
> > > of the DSPF command to see what had changed, and below is his response.
> > > 
> > > Thanks!
> > > 
> > > ------------------------------------------------------------------
> > > Steve,
> > > 
> > > I think I figured what is causing your emulator to fail.  From the trace
> > > file it looks like the emulator dies when it tries to read EBCDIC 
>codepoint
> > > 0x09.  This character is the result of one of the changes that was made to
> > > DSPF/EDTF.  The program is designed to take all characters less than 0x40
> > > and replace them with a 0x09 for the purpose of being displayed to the
> > > screen.  There is a control character at the end of the each file name, in
> > > this case "/dev/qsh-stdin-null", that is being replace with a 0x09.
> > > Previously the value was 0x16, but we were having problems with the
> > > character being displayed so we changed it to 0x09.  It looks like the
> > > emulator doesn't know how to handle codepoint 0x09.  Hopefully, this is
> > > helpful.  If you have any more questions let me know.
> > > ------------------------------------------------------------------
> > > 
> > > Steve Fox
> > > http://w3.rchland.ibm.com/~sjfox (IBM Intranet)
> > > http://k-lug.com (Rochester Linux Users Group)
> > > 
> 


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