Could do with some clarification/review of this page, regarding the name and the content. Software or Solutions (preferences). Mantis etc. does it make sense to have them here?

Partners help us in providing our services.


The migration of IDMS databases to relational DBMS alternatives can be undertaken in a number of ways. When addressing these projects by means of automation tooling, there are generally two approaches that may be followed.

These are:

 1. The “Native Migration” approach, which involves converting the IDMS DML code to SQL and the database from IDMS to its relational DBMS equivalent.
 2. Retaining the application in its original form and providing an interface mechanism that interprets existing IDMS DML requests for data which has since been migrated to a relational DBMS.

Our approach is based on the second of the above-mentioned approaches and is implemented as follows:
 1. A DML pre-compiler that generates code which is completely compatible with the CA-IDMS DML pre-compiler. The DML pre-compiler makes possible the rehosting of COBOL/IDMS programs together with their continued maintenance and support to non-mainframe platforms.
 2. If the application is to remain on the mainframe, then the underlying database could move to a relational DB equivalent without requiring the applications to undergo any changes to the source code.
 3. An IDMS run-time (data access architecture) that is invoked whenever database interaction is initiated, processes database access statements, and redirects these to the relational DBMS, fulfilling the request in a manner that is entirely transparent to the application.
 4. The data access architecture is designed to implement a database storage management organization that is based on similar principles to those used by IDMS, by leveraging clustering features of the target RDBMS to deliver performance that is comparable to that of IDMS.
 5. This approach makes use of SQL Triggers to build a unique DBKEY when a record is inserted into the DBMS. This ensures that related records are stored in close proximity to each another. I.E. Records are inserted into a clustered index on a DBKEY column and the CALC and VIA records have their DBKEYS clustering targeted on the same page.
 6. The relational DBMS will be structured as a true RDBMS and may be alternatively accessed (including record INSERTS) by means of native SQL without breaking the database structure and retaining the same performance benefits.

PL/1 to JAVA Tools

PL/1 Java Tools provides a complete conversion set for quickly and easily transfer and build existing PL/1 applications for Windows, UNIX and Linux platforms.

Automatic conversion process There are only a few features which do not translate automatically. In most cases a converted PL/I program is ready to go code. Eventual untranslated parts are clearly indicated in a log file and left in the code for manual corrections

All standard file types are supported including stream I/O General system dependent file definitions are included as common copybook files and are thus easy to change according to the current environment.

Embedded SQL and command level CICS code is adjusted for pre-compilers

Co-operative solution as an option In co-operative solution all SQL processes are collected as a separate SQL module for an application.

Original PL/I structure of code is preserved All INCLUDE files of PL/I are transformed together with the main code, creating corresponding COPYBOOK files for with same names. INCLUDE files which contain both declaration and processing statements are divided as two separate copybook files into two different libraries (subdirectories). Internal procedures and functions are changed as separate sections. Local variable of procedures functions or blocks are handled accordingly. Code indenting is done automatically and the indenting depth can be set with a parameter.

Clear structural comments Besides your own in-line comments clear structural comments are added to clarify the original source code.


Many organizations have made a significant investment in Software AG’s Natural/ADABAS technology, the question of what the future might hold is of great relevance.

For those organizations with key investments in Natural/ADABAS technology and for whom Microsoft technology is regarded as strategic, MigrationWare has a solution that will result in the replacement of Natural/ADABAS with Microsoft C# and SQL Server. This MigrationWare solution provides an automated approach to the conversion of Natural and ADABAS, providing functionally equivalent applications on the chosen .NET target environment.

The generated code is designed to be maintainable and all inline comments are preserved, thus ensuring that any documentation that may exist in the original source code is retained.

All code is converted automatically with well above 90% accuracy thereby minimizing the need for any manual intervention.