Most Read This Week
May. 1, 2003 12:00 AM
Every developer will at some point have to integrate his or her work with a legacy system running on a mainframe platform. These projects tend to be both painful and challenging due in no small part to the limited information- sharing capabilities of outdated, albeit stable, systems. XML and Web services didn't exist when some of these applications were written. The concept of browser-based applications was years away. Green-screen applications were the norm and dinosaurs ruled the earth (just kidding about that last part).
Teamstudio has a product called Screensurfer that brings screen-based applications to the browser in HTML format quickly and painlessly. They do this through a 3270/5250 Web gateway controlled by easily modified ASCII text files. Using a series of wizards, a developer can quickly generate the necessary files and have a terminal session open and operational in the browser within minutes. Teamstudio calls this their "Screen to HTML" feature.
"Screen scraping" applications (such as Screensurfer) are not new. By extracting the data from the existing user interface, they enable a company to utilize these systems in new ways and repurpose the data for other applications. Screensurfer's ability to move screen-based applications to the browser also removes the requirement that system users have terminal emulation software installed on their desktop. This allows the application to be accessed by many more people than traditionally possible.
We are also given the option of running Screensurfer in a "co-server" environment. This is where Screensurfer sits between your application server of choice and the mainframe. ColdFusion is supported through a provided CFX tag. A COM object is available as well for those who are running ASP/VB code. Additional application servers (PHP, JSP, .NET) are supported through XML-over-HTTP calls. In a co-server environment, the screen-scraped data is returned in a useful format (usually a recordset) to the calling application server for processing and HTML markup.
Teamstudio packages an IDE tool with Screensurfer called Teamstudio Express. This IDE can be used to modify the ASCII files mentioned above, which contain HTML and specialized markup called Surferscript (we will discuss this momentarily) that are used to control the output of the scraped screen data. Teamstudio Express features syntax highlighting (for HTML and Surferscript), tag completion, a terminal emulator, and some debugging capabilities. We found the integrated "trace" functionality to be extremely helpful.
Our first test was to see our application using the "screen to HTML" functionality. We cracked open the tutorial and followed along, starting with opening up Teamstudio Express and creating a new project. We were quite pleased to find that the Teamstudio Express IDE interface is similar to the ColdFusion Studio interface my colleague and I were both quite comfortable with.
Teamstudio Express provides a wizard for configuring your application. All of the necessary Surferscript files were automatically generated by this wizard; we just had to hit the Compile button and were ready to go! Officially, that's all that we needed to do to get Screensurfer to drop our green screens into a browser. There are two ways to see the fruits of our (admittedly meager) labor. The first is by hitting the Launch button in Express (it looks like an exclamation point) and the second is to go to the default URL (http://localhost:82/surfer/home/) in your browser. The host access page is shown in Figure 1.
Select the protocol, enter the host name, and press "Connect." If you entered all the correct information, you'll get your mainframe's logon screen. The mainframe logon screen is shown in Figure 2.
It doesn't get much easier than that. We just eliminated the necessity of each mainframe user having terminal emulation software installed on their workstation and opened up all of those applications to anyone with a Web browser. The total development cost was about 10 minutes of developer time. All of your green screen users will feel right at home, as the application interface is the same as in the terminal emulator.
In a production environment, Screensurfer should be installed on your Web application server or another Web-accessible server. Important to note is that Screensurfer operates as its own Web server. If you install it on a machine with an operating Web server, you will need to give Screensurfer a port number other than the one currently being used by your Web server software. We did not see any documentation that suggested we could use Screensurfer in conjunction with an external Web server.
To enhance the user experience, Screensurfer ships with functionality to handle keymapping. For example, a developer could map the F11 key on the user's keyboard to send the F11 command to Screensurfer (and therefore to your mainframe application). This is accomplished through the use of an ActiveX control (distributed via .cab file) for Internet Explorer users and a Netscape plug-in for Netscape users. If you opt not to use this functionality, the end user will have to click on an image map that appears next to the mainframe display screen to actuate function key commands. It's a nice touch that will be much appreciated by terminal emulator power users.
Surferscript tags are prefixed with "TE" similarly to how ColdFusion tags are prefixed with "CF". ColdFusion code is stored in ".cfm" pages, while Surferscript code is stored in ".stml" files. These ".stml" files are what get compiled by Teamstudio Express to form your Screensurfer application. A complete tag reference document is installed with Teamstudio Express and does a good job of explaining the functionality behind each tag.
For our second experiment, we decided to retrieve multiple screens of data. In our green-screen application, the user has to hit "page down" repeatedly to navigate through all the information. We were curious as to how Screensurfer accomplished this task.
Fortunately for us, the tutorial coupled with the wizard in Teamstudio Express made the task of retrieving multiple screens of data fairly easy. We launched the wizard, marked up our terminal screens, and aside from a minor mix-up between page up and page down, we were good to go. Looking at the trace of the screens that Teamstudio processed made the task of debugging our code simple and also gave us a good look into what was happening behind the scenes.
Screensurfer was selecting the data from the marked regions on the AS400 display screens, sending a "Page Down" keystroke to the AS400, and repeating this process until the string "more..." no longer appeared on the screen. We noted that retrieving the data and generating the page output for display took slightly longer than an equivalent database call. Later on, we determined that compiling the Screensurfer application without the trace functionality enabled decreased runtime dramatically.
The Co-Server Environment
This proved slightly more difficult to do and the instructions really only made sense after we completed the task. Most of our work was in adding custom Surferscript around the HTML output blocks in the STML files so Screensurfer would not be interjecting HTML into the return data stream. Once that part of the application was completed, we created a simple ColdFusion page containing the <CFX_Surfer...> tag call and a <CFDUMP>.
We compiled the Screensurfer application without trace functionality enabled. When we ran the ColdFusion template, performance was definitely acceptable. We compared the runtime of our <CFX_Surfer...> call with a stored procedure grabbing the same data from the same database and found that they were practically the same.
Some may ask what the point of the co-server environment is. As part of a larger migration scheme, the co-server environment is a key phase to migrating away from the green screen entirely. By implementing the "screen to HTML" functionality of Screensurfer alone, the potential user base of the application is increased and the desktop software requirement (terminal-emulation software) is removed.
The users continue to work on screens in the browser that look the same as the ones they saw in their terminal emulation software. Meanwhile, the development staff can work on creating dynamic, data-driven applications that are fed by the Screensurfer co-server application in ColdFusion, ASP, JSP, or whatever supported language they choose. Once that is complete, system users can be smoothly migrated to a "Webified" user interface without leaving the browser. Ultimately, though, this ColdFusion/ASP/JSP application should move to the final phase of hitting the database directly, especially since database drivers are available for most mainframe databases. Screensurfer gives the developer the ability to smoothly transition the user base to a Web interface.
Supported Terminal Types:
Pros: Easy setup and quick terminal emulation in the browser; application server integration
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads