Arron wrote: ported to the AS400.\001 TN5250 can be found here:\001
http://tn5250.sourceforge.net.\001
<<
.. looking at right now - thanx :)
Best regards
Niels Liisberg
IceBreak Chief SW Architect
System & Metode Technologies
Håndværkersvinget 8, DK-2970 Hørsholm
Phone: +45 70 20 36 10
Fax: +45 70 20 30 11
Direct: +45 45 177 055
Mobile: +45 31 158 861
E-mail: nli@xxxxxxxxxxxxxxxxx
Web: www.system-method.com and www.Icebreak.org
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Aaron Bartell
Sent: 22. december 2008 17:00
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Pete's web5250 was->Re: Business Developers was ->Re:
IBM Gives RPG Devotees Their Own Café
>On the other hand, the virtual terminal api would let you bypass Java
middleware entirely, and streamline communication between browsers and
virtual terminal servers.
Another thought to eliminate Java would be the look into what of the
TN5250 project (note there is no "j") could be ported to the AS400.\001
TN5250 can be found here:\001
http://tn5250.sourceforge.net.\001 I have
recently been looking into using this on my linux desktop, but there are
a
few things that I haven't been able to figure out yet that are keeping me
from being productive with it.
Aaron Bartell
http://mowyourlawn.com
Nathan Andelin wrote:
From: Niels Liisberg
In the end of the day - I will be very grateful for any plumbing
that is using the virtual terminal.
I'd check first with your IBM contacts. They may be able to suggest a
better API than the virtual terminal interface. It sounds like Zend and Look
Software have had some pull with IBM.
Virtual terminals are NOT much different than socket programs that connect
to telnet ports and send / receive 5250 data streams.
From the source code that Pete Helgren posted it was clear that the tn5250j
interface insulated him from dealing directly with 5250 data streams.
tn5250j parsed the data stream and generated high-level collections of
screen elements; very object oriented. I can see how something that would
be easier to work with.
On the other hand, the virtual terminal api would let you bypass Java
middleware entirely, and streamline communication between browsers and
virtual terminal servers.
Pete Helgren had a noteworthy idea about deploying 5250 interfaces
alongside new Web applications within the same portal, using a shared menu
system. Something like that helps smooth the transition from 5250 to more
modern user interfaces. But the web5250 interface is too slow in my
opinion.
Most 5250 applications communicate with telnet servers which communicate
with 5250 terminal emulators. A virtual terminal server on the other hand,
could bypass telnet servers and communicate through the HTTP server, with
browser clients instead.
The "pluming" that I referred to in my earlier post was a menu sytem, and
an API that can establish and maintain persistent connections between
browsers and a virtual terminal servers, if that would help.
Nathan.
midrange.com
