Code Search (Find, Follow), Analysis (Metrics, Static, Dynamic, Bugs) and Change (Modernization, Migration, Generation, Optimization, Rearchitecting)

Natural/ADABAS Software Migration

Semantic Designs provides tools and services to help migrate Software AG Natural and ADABAS systems to new languages and technologies.

Applications coded in Natural or that use ADABAS often run critical business operations. Yet they are becoming difficult to maintain due to lack of available skilled people, and increasingly expensive to support in terms of licensing and mainframe costs. Rebuilding such applications from scratch on a new platform is often proposed, but that process is long and painful, and often fails due to scope creep and missing knowledge about what the legacy application really does. Yet failure is not an option for critical business systems.

Automated migration of Natural and COBOL code using ADABAS to modern platform such as Java or C#, or conversion of mainframe COBOL code using ADABAS to use a relational database rather than ADABAS, is a cost-effective way to remove the dependencies on legacy techologies.

You can read more on general issues of Legacy Software Migration, but this page is specifically about migrating Natural and ADABAS.

Issues in Migrating Natural/ADABAS

There are a variety of problems that must be handled in migrating Natural and ADABAS-based COBOL code:

• Database Conversion
  • Conversion of the ADABAS data model to a Relational model. The ADABAS data model is not relational and definitely not normalized. The data model must be converted into an efficient, maintainable Relational model, using datatypes supported by the Relational model as opposed to the legacy ADABAS datatypes. A key consequence is that the placement and representation of the data in the database will not be the same and therefore data accesses and updates must change.
  • Conversion of ADABAS data base content into Relational database content. It is called "data processing" because ultimately these applications are about the data! The existing ADABAS database content must be extracted and moved into the new Relational form without losing any information. If the new target platform is not the mainframe, the data must moved off the mainframe.
• COBOL code modification to change ADABAS calls to relational calls. If COBOL programs will be retained on the mainframe, then ADABAS calls in the COBOL programs must be modified to access the data from the new Relational model.
• Code translation of Natural or COBOL code with ADABAS calls to modern OO languages. If the goal is to move from mainframe then
  • The source code of the application must be converted to Java or C#
  • Screen input-output must be changed to use GUIs or Web-based interfaces
  • Explicit ADABAS calls in COBOL code and implicit calls in Natural must be replaced by database calls that understand the relational model and the representational changes. Reads and writes of flat files must be replaced by modern file reads and writes.
  • External interfaces to other systems must be replaced by some equivalent
  • EntireX interfaces must be converted in a way that enables short-term continued access through EntireX with eventual ability to replace by equivalent remote access facilities such as Web services.
  • Job Control and Scheduling must be replaced
  • Security must revised to support the broader accessiblity of the application
• Application Testing. This provide assurance to all parties that the result preserves the business logic and functionality.
• Maintenance change Integration. Migrations take time. The legacy application will continue to serve the organization during the migration, and business needs will force changes to the legacy application to even as the migration occurs. These changes must be moved into the migrated application.

Natural/ADABAS migrations with Semantic Designs and DMS

Using DMS, Semantic Designs can automate Natural and ADABAS migrations, preserving the business rules exactly. The issues above are handled as follows:

• DataBase Conversion
• ADABAS data model conversion: DMS-based tools can automatically convert the set of Adabas model as represented by the DDM files into a normalized relational model. ISNs become explicit table fields. Period Groups (PEs) become sub-tables. Multiple Value (MU)s become sub-tables or bounded-size arrays. Multiple Record (MR) types become separate tables. Subdescriptors become additional table columns. Descriptors and SuperDescriptors become keys. The customer may rename fields and/or add additional keys. Data representations change from EBCDIC strings to ISO8859-1 or Unicode UTF-16 strings; packed decimal number and date representations are converted to target relational database native data forms as appropriate.
• ADABAS database content conversion: DMS-based tools can be used to generate database content migration. This is accomplished by syntheszing Natural programs and target language program (Java, C# or COBOL). The Natural programs easily read the Natural tables, and export the results as flat files; the target langauge programs read the flat files, convert the data representation as needed, and write the result to the relational data base. The generated data migration tools may be run repeatedly for testing purposes and to refresh the migrated code's database.
• COBOL Code Conversion. Automated transformations implemented with DMS can locate database I/O statements in IBM Enterprise COBOL and replace those statements with equivalent blocks of code that read the requested values from the relational model, e.g., EXEC SQL constructs for DB2 calls.
• Code Translation
• Conversion of core COBOL/Natural constructs: SD migrates code by applying transformation rules to map the syntax of the source languages to OO target language syntax (e.g., Java or C#) in a way that preserves the semantics of the source code. This ensures that the generated program does exactly what the original program does.
• Handling of special idioms: Certain source language idioms need translation in special or efficient ways, including database access, screen I/O, and even clones in the legacy code. By writing custom translation rules, SD can ensure that the special cases are converted in the most effective way for the particular application system.
• Database accesses: All Natural (and COBOL) accesses to ADABAS will be replaced by idiomatic code in the target OO language, that satisfies two needs: a) it handles the data model changes caused by the ADABAS to Relational conversion determined by the data model migration tools, and b) organizes the data access according to useful architectural principles. For example, all database calls in the translated code might be abstracted in Hibernate API calls to implement an Object-Relational Mapping in the converted application.
• Screen Management: Natural MAPs will be replaced by idiomatic code in the target OO langauge to implement the types of user interfaces desired by the customer: GUI or HTML. Special features of Natural I/O such as REINPUT and HELP can be handled efficiently, and some of the input validation can be moved to the client.
• EntireX Interfaces: These provide external access by other Natural-based applications to a targeted application. After migration, such interfaces need to continue to exist, to maintain compatibility with other legacy software not yet modernized. However, the migrated code will be structured as EntireX interfaces interfacing to generated Web Services, which in turn talk to the original Natural code interfaced to EntireX. This chain provides legacy EntireX compatibility, plus Web Services ready to support interfaces to other (eventually) modified applications, and yet provides an easy way to remove EntireX interfaces when they are no longer needed.
• Job Scheduling: Mainframe applications are controlled by JCL, yet JCL should not appear in the converted system. This is solved by providing a job scheduler that runs in the target environment (there are many choices) and translating the JCL calls into target language code modules executed by the target scheduler. JCL generated by a Natural application directly can be converted idiomatically into target langauge code.
• Testing SD's migrations are tested several different ways using automated testing methods:
  • Unit testing of migration tool: each Natural code element, and each interesting idiom, is coded as unit test in Natural, and verified that unit runs correcly as a Natural program. The migration tool is applied to all unit tests, and the resulting OO unit code is executed; it will run successfully only if it correctly translates the semantics of the original program.
  • Functional testing of legacy application and the migrated version: The original applications is augmented with tests of application functionality, coded in Natural and verified for correctness in the original application context. These functional tests are translated along with the application code and indicate whether the translated application implements the functionality correctly.
  • Test Coverage Analysis: SD supplies Test Coverage tools for a variety of langauges, including the targeted OO languages Java and C#. The functional tests are exercised to collect test coverage data for the Natural program. The translated application is exercised, and test coverage is collected for that. The levels and areas of covered are compared to determine similarity.
  • Performance Profiling: SD supplies Profiler tools for a variety of langauges, including the targeted OO languages Java and C#. The translated application is exercised under essentially production load, and performance profiling is used to verify performance or spot bottlenecks.
• Ongoing change to legacy code: The SD process handles this easily and continuously. The legacy development team continues to revise the ADABAS-based programs during the migration as though the migration were not happening. The automated migration tools can be used to convert the legacy application at any moment. Early in the migration the original legacy code base is converted and testing/tuning the migration rules starts. Late in the migration, a final snapshot of the modified legacy code base is converted and used for the final conversion and cutover. This ensures tha the final application is converted with all the knowledge gained during the migration, and the coding results are consistent across the entire system.

The bottom line is that automated migrations lower costs, time, and risks, and raise the quality of the result.

The following diagram shows a conceptual overview of a Natural to C# migration.

Custom Translation Tools

It is the case the every organization's migration task is unique. While all Natural/ADABAS conversions have these technology foundations, the other technology and organizational circumstances (other source languages, job control, security, external interfaces, architectural goals, ...) and a unique set of target technologies force customization of the migration to user's needs. SD's approach to migration using DMS ensures the flexibility needed to address the customer's unique needs are met.

Assessment and Planning

Any large migration requires careful planning and support. Semantic Designs can

• carry out automated assessments of a source code base for troublesome constructs
• find/remove redundant code before conversion to minimize total conversion costs
• define an effective, economical porting plan which minimizes risk
• determine how to handle special customer requirements effectively

To discuss migrations in more detail, contact us. Details about timeframe, your special circumstances, and desired modern target system configurations are extremely helpful.

Not ready to migrate? Tools to help you manage Natural

The decision to perform a migration is not an easy one. Whether you do or not, it is likely to be some time before a migration starts, and you must enhance the application you have. SD offers tools to support Natural programming to help regardless of your decision.