2.2 Recent History

In this section, we describe some modifications to RSS that occurred prior to the modernization effort.

Web Enablement

Before beginning the effort to replace the RSS, the project managers decided to comply with a corporate mandate to Web enable all legacy data systems. As the RSS replacement effort would result in a Web-enabled system, an argument could be made to defer Web enablement until a later stage in the process. Because this was primarily a political decision, however, arguing the merits of one approach over the other was somewhat irrelevant in this case.

Politically motivated decisions are part of any engineering and development effort, and responding to them in an appropriate manner should be routinely taught in any undergraduate software engineering course. In this case, the most appropriate action was to satisfy the request with minimal disruption and delay.

The user interface of the legacy RSS is implemented using the DPS, a screen-management system for creating and supporting "green screens." Unisys provides the Web Transaction Server (WebTS), a product that can revamp user interfaces developed in this manner. WebTS supports Web pages and transactions and can deliver Web-style HTML documents. It can also invoke transactions based on user actions, such as completing an input form or clicking a hyperlink. Transaction results are returned to the user as a standard HTML page [Unisys 00].

WebTS can deliver both static and dynamic pages. Static pages are prefabricated and may contain various types of data, such as text, VBScript, JavaScript, graphics ”for example, JPEG and GIF ”video, and audio. In addition to static data, dynamic pages can also include data that is retrieved at runtime and formatted by transaction programs.

When the user invokes a static page, the text, graphics, and other static content are read by the WebTS directly from the file system and referred to the Web browser for display. If the user calls a dynamic page, WebTS must start the targeted transaction, process the data, and generate an output message formatted in HTML.

WebTS implements dynamic pages by using traditional-style HVTIP/TIP transactions, as shown in Table 2-1. The use of Open/DTP transactions via a special OLTPTx transaction is not a viable option for the RSS that relies on HVTIP/TIP transactions. The two remaining mechanisms for invoking transactions are both viable options.

The Web Enabler for the DPS uses a Java applet that is downloaded to the client's browser. This applet accepts user input and makes the appropriate transaction calls. The transaction-processing application does not need to be modified to allow access from the Web.

TIP and HVTIP transactions can also be called using the WebTS interface based on the CGI. This approach requires modifying the existing code, but eliminates the dependency on the DPS.

To call a transaction, WebTS performs minimal processing to determine where to send the message. WebTS calls the HVTIP application, which initiates the transaction. All other processing is performed by the transaction itself.

The goal of this preliminary effort was to Web enable the RSS as quickly as possible. The Web Enabler for the DPS product was used to minimize the effort and consequent disruption to the RSS replacement schedule. Figure 2-3 shows the RSS architecture after Web enablement.

Figure 2-3. The RSS after Web enablement with the Web Enabler

Table 2-1. Mechanisms for Invoking Transactions

Technique	Description
Web Enabler for the DPS	Existing DPS-based transaction applications can be called via WebTS without change.
CGI for C/COBOL	UCS C and UCS COBOL transactions can be called via WebTS, using a high-level, Web-compatible interface. Existing HVTIP/TIP transactions require at least some modification.
OLTPTx	Existing Open/DTP transaction applications can be called via WebTS with little or no change.

Reports

RSS provides reports to management for decision making. As in any organization, management continually requested new reports, new data aggregations, and new ways to look at data. The ability for the maintenance organization to provide these new reports was hampered by a restriction from changing the database schema ”imposed because of the ensuing system instability ”and the dispersal of the data over 90 locations. These new requests usually resulted in manually exporting raw data, importing it into another tool, such as Microsoft Excel, using the tool to perform calculations on the data, aggregating the information from various files, and, finally, formatting the data. Depending on the nature of the request, this process could take anywhere from several hours to several days and was not adequately responsive to management needs.

After analyzing the existing database structure and the nature of the most common requests, an Oracle database was created that aggregates data from the 90 DMS databases. Data is transferred from the DMS to the Oracle database once every 24 hours. Developers could create reports by using such tools as Oracle Discoverer or any other COTS-reporting tools that work with Oracle.

In addition to satisfying the needs of management during the modernization effort, migrating reports to Oracle at this stage had several advantages. Implemented reports using Oracle Discoverer or other COTS-reporting tool made it unnecessary to maintain and migrate COBOL report modules. The software maintenance staff also became more familiar with their future database environment early in the modernization effort.