irm. In other words, the data on which corporate America runs is currently inaccessible through browsers and intranets.
You can fix th
at.
Pick One, Any One
There are a couple of fundamentally different ways to give browsers access to IBM hosts. The two basic methods can generically be called native 3270 and Hypertext Markup Language (HTML) conversion. Each method has technical merits and deficiencies.
With native 3270, you need to have a special browser. In this case, the browser needs some form of built-in 3270 terminal emulator and applets that know what to do with the 3270 data streams once they reach the desktop system.
With conversion, 3270 screens are changed to HTML format and posted to a Web server. The
converted screens
can then be viewed using any browser.
HTML conversion comes in two flavors. One is a static approach, where the user has what amounts to read-only access to data made available by an administrator. The other method is more dynamic (and similar to your typical transaction-oriented mainframe data access), where the user queries a database and views th
e results using a browser.
An example of the static approach would be where some mainframe data is made available to an organization. For instance, a human resources department might, on a monthly basis, post to an intranet server the amount each employee has in the 401 (k) plan.
To do this, the 401 (k) information would be pulled off the mainframe and converted to HTML format. Then employees would be able to look up this information using the browser on their desktop computers simply by entering the uniform resource locator (URL) of the Web server. (Obviously, security is an issue here and the information would need to be password-protected.)
This approach to making mainframe data available through browsers is fairly limited. And while such access might do in many situations, it's not sufficient when users need access to data that changes more frequently.
For example, you might have an inventory database that sales staffers frequently check when they're taking orders over the pho
ne. For such applications, you need an HTML conversion method that is more dynamic.
The way to accomplish this level of access to mainframe data is through embedded HTML scripts. (In a sense, this is the normal HTML process applied to 3270 data streams.)
First, a Systems Network Architecture (SNA) gateway into an IBM host pulls off a standard IBM host screen with embedded data. This screen is then converted to HTML format on-the-fly. That's what Salvo Server Edition from Simware and the Emissary Host Publishing System from Attachmate do.
From a common browser, the user enters the URL of an intranet server that is connected to the server that's performing the HTML conversion. Common Gateway Interface (CGI) scripts are employed to generate the HTML pages based on user queries.
The possible downside to the HTML conversion approach is that you may not, in all cases, be able to support some of the more complex 3270 commands, such as creating built-in function keys that perform a series
of operations.
The Natives Are Wild
An alternative to HTML conversion is to leave the data in native 3270 data stream format and use a special browser. Such a browser would need 3270 terminal emulation features and would require an applet to handle the data.
These browsers would replace a terminal emulator and would include the underlying technology needed to maintain a connection with the mainframe (e.g., by sending acknowledgments to the host to keep the session alive).
Using a special browser may seem idiotic. Would anyone actually do that? The answer is probably--especially if the browser solves a specific problem, like giving users access to mainframe data. The Aberdeen Group consulting firm believes the browser market will become fragmented and, despite Netscape's current dominance, users will buy browsers based on their personal requirements.
With the native 3270 approach, a user establishes a session with the mainframe, typically by running a Telnet sessio
n into the host. The resulting TN3270 data stream would travel across the network to the desktop system. There, the browser would need to have embedded applets to take the data stream and display it as a normal 3270 screen.
The applets could be designed to handle even the most complex 3270 commands. This would overcome the shortcomings you might encounter with an HTML conversion approach. The trade-off, of course, is that you need a special browser that can perform emulation and handle the data.
But that may not be a problem if you decide to use a common applet technology, such as Java. If that's the case, then any of the major browsers will work, since virtually all the browser vendors either support Java or plan to do so.
And when it comes to mainframe connectivity, there's already some movement in Java's direction. For example, OpenConnect Systems, a TCP/IP-to-SNA connectivity company, offers a product called OC://WebConnect, which is Java-enhanced server software that lets users acces
s mainframes and midrange systems through a Java-enabled browser.
With the OC://WebConnect software, Java applets convert standard data flows into HTML/Java data flows (and vice versa). This conversion enables multisession, multiprotocol access to existing mainframe applications.
Fast Forward
Giving users access to mainframe data through Web browsers is a big start. But many organizations also want to extend this level of connectivity to other types of IBM environments--specifically, to AS/400 systems.
Some help in this area has already arrived. Earlier this year, IBM's AS/400 Division announced it was teaming up with I/NET, a research and custom software solution provider, to bring AS/400 users onto the Web. I/NET has a software package called Web Server/400 that enables an AS/400 running OS/400 version 3.1 to operate as a Web server. (About 360,000 such systems are installed today.)
The move to open corporate data to Web technology has just begun. And it's likel
y that for the next year or so HTML conversion and the native 3270 access methods we've outlined here will be the best ones to consider. But in the future, a better way to access mainframe data may become available.
One idea being considered is to use existing client/server tools, such as Visual Basic, C++, and OLE 2.0, to develop applications that can access mainframe data. You can then ready any application for intranet use by dropping an OLE custom control (OCX) onto a form to display the data in HTML format with a browser.
Regardless of the method used to access mainframe data with a browser, one other issue must be addressed before opening up the corporate treasures. That is security.
Many Web browsers (including the Netscape Navigator) store on-screen images in a local cache and often in a server cache. After a user logs out of a session with a mainframe computer, these screen images can then be viewed by anyone with a Web browser.
That means someone could come along after a
session and view data to which the original user gained access only after entering a password and ID when logging onto the mainframe application. Peeking at the cached screen images also defeats any encryption that would have been used when the data passed over the corporate network.
This is an area that will probably be addressed quickly. Web browser vendors will most likely add HTML extensions to tackle this security breach. That's at least something to consider before opening the doors to your mainframe data. But once that's done, you may have an easy way to give users a common interface to all your corporate data, whether it's on big iron or little.
Where to Find
Attachmate
Bellevue, WA
Phone: (800) 426-6283 or (206) 644-4010
Fax: (206) 649-6484
Internet:
http://www.attachmate.com
How to Put Mainframes on the Web
