The benefits of supplying internal users and customers access to corporate data via the Internet are numerous and undeniable. From the user’s perspective:
- Access cost is negligible, with most households having Internet access.
- Training costs are minimal, as users are already familiar with the basic hardware (their PC) and software (their Web browser).
- Web-based applications have significant usability advantages over 3270s.
From a support perspective, TCP/IP has become the protocol of choice for data transmission and provides standard access across all data processing platforms. It’s no surprise then that projects that expand the access base to existing applications choose a Web-based delivery method.
What’s surprising is that many companies are choosing to relocate their application logic (and, occasionally, their data) as part of implementing this new delivery method. Credible studies show that mainframes deliver improved reliability and security at a lower total cost of ownership than any other available platform. Often, the required business logic is already implemented on the mainframe. So, how can a decision to relocate processing off the mainframe be justified?
Anecdotal evidence suggests that in many cases, the primary answer for this question is a lack of knowledge. The corporate IT personnel responsible for these decisions simply don’t believe that IBM mainframe products can deliver on Web-based solutions.
This misunderstanding persists even though IBM has aggressively delivered continued enhancements to Web support for the past several years. Starting with CICS/ESA Release 4.1 and continuing through Transaction Server 2.3, every release of CICS has included enhancements to Web-based processing. The result is a robust, secure environment that can deliver on almost any requirement.
Because of the assumption that mainframe-based solutions can’t deliver on Web-based requirements, the burden of proof falls on mainframe IT personnel to show otherwise. We must prove to our users that products such as CICS can fully support HTML applications. Fortunately, IBM has provided a facility that fills this need: the 3270 bridge.
Implementing the 3270 Bridge
First introduced in CICS TS 1.2., the 3270 bridge allows conversion of many applications to HTML display with minimal manual effort, and is ideal for prototyping Web access to existing CICS applications, or for “Webifying” low and moderate use transactions. In fact, if the standard bridge HTML format is acceptable, the entire conversion consists of reassembling the BMS map using a new, IBM-supplied procedure. If the standard display format isn’t acceptable, a few hours of effort by a programmer who is moderately experienced with HTML programming can produce a professional- looking result.
The 3270 bridge works by intercepting a transaction’s SEND and RECEIVE MAP commands, converting the datastreams on-the-fly between 3270 format and HTML format. Variable display areas are tagged, allowing the programmer to relocate them on the HTML display as desired. Since the HTML display is native HTML, links, graphics, and other options are not limited to addresses controlled by CICS, and can point anywhere on the Web.
Before attempting a 3270 bridge conversion, the CICS region must be set up to support it. First, ensure that SIT option TCPIP is set to YES. (For CICS 1.2, the option is WEB=YES.) Determine a value for WEBDELAY, which controls how long state data is maintained. Ensure that the Web support and 3270 bridge resources have been defined in Resource Definition Online (RDO) (groups DFHWEB, DFH$BR and DFH$WBSN, depending on your release, and a TCPIPSERVICE definition must be installed). Of course, TCP/IP must be installed and active under z/OS.