×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
