Re: 5250 & 3270 together?

Check out <ftp://dxcoms.cern.ch/pub/3270> for a 3270 client that seemed 
pretty nice when originally looked at it (4+ years ago).  I liked the
layout of the code much better in that client verses the X3270 client.

There also exists somewheres a Java client..  Can't find that URL though.

I have written both a tn3270 and a tn5250 client.  One of the things that
I've seen done is to have a well defined set of interfaces, and dlopen a
shared library that will do the actual datastream processing for you.
That way, you can provide a library that has the basic screen manipulation
routines, and then have your datastream processor be linked in based upon
the terminal type you are asking for.  This would possibly allow in the
future to have async terminal emulations added in later.  Some of that
async emulation needs to be there for TN3270, because if you try to access
a terminal server that doesn't have any sessions available in it's pool
of dynamic LU's, then you will get an ASCII message to that effect, not
a tn3270 datastream message.  

You also have to be aware of the differences in the telnet layer as well,
which are minor for tn3270, but a little bit more involved for tn3270e.
Plus, there is a new RFC out that adds more enhancements to the tn3270e
protocol.

From what I hear as well, the 3270 emulation layer on the AS/400 does take
some CPU cycles.  Plus in order to send aid codes to the AS/400, you have
to send two aid keys.  There are some things you won't run into on an AS/400
that you would in other environments as well, but it would be a good 
starting point..

Bill Suetholz

On 30-May-00 Mike Madore wrote:

> Hi,
> 
>> We had some discussions about this before, and I think we concluded that
>> our 5250 emulator was sufficiently abstracted enough to brave the change
>> without many problems.  Really, the only thing which would need to be
>> re-implemented from the client-side is the session, and probably various
>> pieces of functionality would have to be implemented in the display and
>> display buffer code.  For the server side, wtd.c would probably have to
>> be either modified or re-implemented for 3270.
>> 
>> There are three or four open-source 3270 emulators.  I downloaded them
>> at one point with the intention of checking which if any could be hacked
>> and merged with tn5250, but then I decided I didn't have adequate
>> resources
>> to test features and functionality (I hear that using 3270 to connect to
>> an AS/400 can burn lots of CPU).
>> 
>> IIRC, beware that telnet negotiation may behave differently for 3270
>> hosts.
> 
> I'm restricting myself to the server side for the time being, which is
> much less complicated than the client.  I'm not really even going to be
> generating screens, but rather getting them from the IBM host.  We'll I've
> generated one screen.  Just so you can connect the the server running on
> Linux and see a green penguin. ;-)  I did that for tn5250d also.  Now just
> combine that with ARP spoofing on april fools day...
> 
> The telnet server side telnet negotiation we have works as is for TN3270
> (not TN3270E of course).
> 
> I looked at the x3270 license, and I think it may be incompatible with the
> GPL/LGPL.
> 
> Mike
> 
> +---
>| 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
> +---

----------------------------------
E-Mail: wsuetholz@centonline.com
Date: 30-May-00
Time: 13:57:50

This message was sent by XFMail
----------------------------------
+---
| 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
+---