2.1 The Retail Supply System

Before a modernization effort can begin, it is necessary to understand how the legacy system is used and how it is constructed . RSS has the following characteristics.

• The legacy RSS is deployed on a Unisys Clearpath server running the OS 2200 operating system.

• RSS is operated at more than 90 locations and supports 25,000 users at 350 locations, many of which are remote.

• A typical RSS transaction completes in 3 to 5 seconds.

• The RSS is coded in Unisys COBOL 85 and uses the Unisys Data Management System (DMS) 2200 network database.

• The system consists of approximately 1.8 million lines of code, including batch processing, reports , and on-line high-volume transaction processing (HVTIP) transactions.

• The user interface is implemented using the Display Processing System (DPS) with screens generated by the DPS FORMGEN tool.

• The RSS consists of approximately 900 program elements, each containing about 2,000 lines of COBOL 85 code. In total, there are more than 13,000 CALL, COPY, and PERFORM dependencies between program elements.

Figure 2-1 provides a high-level architecture of the legacy RSS. The following sections describe additional details about the database, user interface, and transaction processing subsystems.

Figure 2-1. Legacy RSS high-level architecture

Database

As already mentioned, the RSS maintains data in the Unisys DMS 2200 network database. The DMS is a logical data manager based on the specifications recommended by the CODASYL committees for network database processing. The DMS 2200 includes a variety of database storage structures, high-level language interfaces, and a selection of data-accessing techniques, as well as several levels of database recovery and security.

Program elements interact with the DMS by using the following operations:

• STORE: stores a new record in the database

• FETCH: combined FIND and GET that establishes a specific record in the database as the current record of the run unit

• MODIFY: changes the contents of specified data items in a database record

• DELETE: logically removes a record from a mass storage file

The RSS references 700 database tables in slightly fewer than 11,000 operations. Figure 2-2 illustrates both data flow and control flow in the RSS. Program elements typically fetch records from the DMS database into common storage. These data records may then be completely or partly transferred from common storage to working storage, where they can be accessed by application program elements. Modified data may be placed back in common storage and control is passed between program elements, using common storage to pass data between program elements. ^[1]

^[1] This is similar to the use of shared memory in System V UNIX.

Figure 2-2. Data and control flow in RSS

Eventually, data is written from working storage back to common storage. A program element may perform a STORE operation to create a new database record or a MODIFY operation to update an existing record.

Figure 2-2 is a fairly straightforward illustration of data and control flow in the RSS. However, many internal complications make it difficult to understand, much less depict, legacy data flows. Foremost among these is poor data encapsulation. Any program element can read and write to a database record. Many of these relationships can be identified easily by searching for STORE, FETCH, MODIFY, and DELETE operations in the source code. However, program elements can indirectly affect data stored in the database by modifying information in common storage that is then written to the database by a different program element.

Other complications include the use of FILLER space to hold data and the REDEFINES clause that allows the same common storage area to be accessed using different names . Both of these complications can make it difficult to identify and manage data flow in the legacy system.

User Interface

The RSS uses the Unisys Display Processing System (DPS 2200) to provide the user interface. The DPS 2200 enables a programmer to define forms ”screens ”and incorporate them into application programs. Forms are created by using the FORMGEN program and are then transferred to working storage.

At runtime, application programs read the screen data from working storage and display the screens to the end users. The DPS runtime handler transfers data between the form and the application program during program execution.

Transactions

OS 2200 transaction processing (TIP) is a modular extension of the OS 2200 operating system. TIP is the basis for a high-performance system in which an end user at a remote terminal inputs a message that executes an application program. The high-volume transaction processing environment (HVTIP) passes transactions through an arbitrary sequence of subprograms to maintain high throughput.

The RSS relies on HVTIP to maintain data integrity during transaction processing. A typical RSS transaction invokes between 20 and 40 program elements, most of which range in size from 3K lines of code (KLOC) to 7K lines of code. The RSS also uses the Unisys message control bank (MCB) to interface with the transaction programs for message recovery and transaction scheduling.