Re: 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.