- Retargeting
- Migrate data and data access to Oracle/relational
- Eliminate Unisys dependencies
Migrate data and data access to Oracle/relational
Before the legacy system can be ported to Solaris, the data and data access need to be migrated from the DMS to Oracle. This can be a major undertaking since calls to the DMS are scattered throughout the legacy system.
One solution to this problem is to generate database adapters. These adapters are COBOL subroutines used to isolate the database access from the existing application programs. Most of the existing DMS 2200 database commands can be converted automatically into the appropriate database adapters calls. The adapters contain the embedded SQL commands to access the new Oracle database.
In the DMS 2200 database, each data record belongs to a particular AREA. Each AREA in the database is a separate and distinct file that resides on disk. An AREA is made up of a collection of records, and each record may be part of an owner-member relationship. That is to say, each record can be an owner of records (members) or a member belonging to an owner. Think of a card file system, where tabs exist. Each tabbed card (owner) could be a letter of the alphabet with detail cards in between being the members. To get to a particular detail card beginning with a specific letter, one would first find the tabbed card for the letter, then walk through the detail cards looking for the one desired. This walking process is common practice with a hierarchical database such as the DMS 2200. In a relational database such as Oracle, each card or record would have its own unique key for direct access. Migrating data from a hierarchical database to a relational database, at a minimum, requires the addition of key information for each record to allow for direct access. A record that previously depended on an owner record to be physically behind it must now contain the key information of its owner.
Another difference between the existing network and proposed relational database deals with the issue of repeating fields, that is, fields that occur multiple times within one record. The DMS 2200 database schema defines such fields with an OCCURS clause, and application programs reference each occurrence by using a subscript. Repeating fields are not allowed in a relational database such as Oracle. There are several ways of handling this issue. In a true normalized database, one would create a separate table with a row for each occurrence of the repeating field, using the appropriate key fields for direct access (a one-to-many relationship between tables). Another method is to create separate named fields within the existing table rows.
Another complication in this database migration is that the proposed database structure has many record changes. Some existing records will not be transitional at all, and many records and/or fields are transitional to more than one Oracle table. In other words, portions of the database are being reengineered, not just migrated. To modify each application program to handle the new database structure would increase the complexity of the software migration and create a maintenance nightmare.
For example, the legacy legacy system database contains some multi-purpose or variable-use fields. These are database fields that are being used for two or more functions, usually determined by some other code in the record. Multi- purpose fields are being eliminated in the new Oracle database, since they are not considered to be part of a good database design. The change can involve the creation of new fields, new records, and new tables. These changes are hidden from the business logic through the database adapters.
In addition to the DMS 2200 database, legacy system program elements also read many sequential files, including both indexed and relative record data sets. If any of these files are not temporary files (created only for the duration of the run stream), they need to be created in the new environment.