Application migration from IMS DLI environments

Abstract
This paper will be relevant to any CIO, CTO or senior IT executive who is responsible for COBOL/IMS DB-based, business applications running in production on an IBM MVS platform. There is an increasing requirement for IT systems to provide efficient business-to-business capabilities through the use of open, SQL based applications. This is often in parallel with a move onto a cheaper platform, encompassing the use of data warehousing and/or Customer Relationship Management tools (CRM). Using a hierarchically structured IMS Database has certain limitations in terms of portability and database integration, and thus prevents the modernisation of business applications to this degree. IMS DL/1 skills are becoming scarcer while relational database expertise is more commonplace. As this legacy data is in many cases a significant asset to the business, converting to the typically strategic open SQL based environment will future proof the business in terms of data skills allowing for faster and more flexible access to critical business information. MigrationWare is partnered with Micro Focus who has a market position as the leading COBOL development and deployment technology provider on Windows, UNIX and Linux using SQL data repositories. This key partnership, coupled with MigrationWares conversion toolkit development experience, means our integration of technologies will enable the accurate conversion and testing of the majority of business systems from some of the most complex and outdated legacy environments - including IMS DL/1. This paper outlines how MigrationWare can bring significant productivity and quality to this sometimes-complex migration exercise.

Table of contents
Introduction Why MigrationWare? Where can MigrationWare help? The project The future Potential approaches to IDMS DML migrations Re-hosting Native migration Re-engineering Whats involved in the IDMS DML conversion? Automated or manual conversion? Application analysis Source code changes Regression testing Project ownership: The conversion process: Sizing the project Re-code rule determination and data mapping Setting the baseline Source conversion Data conversion Regression test Warranty period Summary Maximising development team productivity on the target platform Working with MigrationWare Migration options Option 1. Turnkey solution Option 2. Semi-factory approach Option 3. Toolkit only Summary 3 3 3 3 4 4 5 5 5 6 6 6 6 7 7 7 7 8 8 9 9 9 10 10 10 11 11 12 12 13 13

Introduction
Although the performance of IMS applications remains competitive, its overall functionality has not been enhanced by IBM for some time. Consequently it is lacking important benefits associated with relational databases structures - openness in terms of portability between many different platforms, connectivity to external applications through a number of communications protocols, data readability through its query management capabilities, and the increasingly important use within Data Warehousing and CRM projects. The above coupled with the increasing difficulty to findiing adequate skilled resources mean that IT managers in charge of applications using DLI are looking for easy and comprehensive tools to convert IMS databases to a relational format. To minimise the risks and costs while maximising the benefits of a migration strategy, corporations look to experts with hands-on experience and a proven, comprehensive toolset that can assist in the migration process.

Why MigrationWare?
MigrationWare has gained in-depth experience helping businesses effectively migrate and develop their critical business assets. In all, MigrationWare have a core experience team with over 50 years of accumulated conversion experience. MigrationWare have conducted most of their business to date within the European Community, but have offices based in South Africa where there is access to a significant pool of expert resources that can allow for a fast and cost effective turnaround in migration projects (see www.migrationware.com). MigrationWare have developed and continue to develop complementary technology to the Micro Focus Integrated Development Environments. (Mainframe Express Professional and NetExpress). This technology has enabled for example, IBM mainframe programmers using IDMS and ADABAS environments to enjoy the benefits of the productivity gains and considerable cost savings that Micro Focus IDEs offer. This development work has provided a technical foundation that has enabled MigrationWare to develop a unique solution to the IMS to SQL conversion problem. The IMS database with its associated DLI call structure and the dynamically built Search Segment Arguments (SSA) has proven difficult and complex to convert in the past. To conduct these projects manualy is a lengthy process which is prone to error and heavy on human resources as well as mainframe CPU cycles. There are few competitive DLI to relational database conversion tools available on the market. Given the following facts: MigrationWare uses existing proven database conversion toolkits with built-in relational repositories Micro Focus IDE provides a fast and accurate conversion and testing environment that is mostly independent of expensive mainframe CPU resources. MigrationWare IMS-DB2 Toolkit offers a sophisticated yet comprehensive testing methodology that enables a high degree of automation and accuracy with audit trail logging. MigrationWare Service personnel are cost effective and highly skilled. MigrationWare technology will therefore be a highly competitive option for organisations migrating business applications using the IMS hierarchical databases to SQL-based systems. Secondly, by exploiting technology and services developed by ourselves and Micro Focus, we can offer a breadth and depth of application migration alternatives not available from any other single source. These two factors combined, explain why MigrationWare is in a unique position to help any organisation interested in migrating their DLI applications to a relational format.

Where Can MigrationWare Help?

The project The MigrationWare solution can be applied to the following phases of the migration project Inventory Analysis. An accurate analysis of all components to be converted and tested will assist with the scope of the project, timescales and costs.

Test data preparation A unique solution and process will be implemented that will create a reliable test data environment that will ensure the highest degree of confidence in the eventual test results. Data mapping Key decisions will be made to determine the data mapping rules from one environment to the next. MigrationWare and the client will use a mapping process that will contribute to the automation of the conversion process. Source conversion All sources will be converted from DLI to SQL using sophisticated conversion algorithms and methods providing equivalent function in the target environment. Data conversion Data utilities that will re-map the databases will be provided to the client for a fast conversion process. Regression testing All application units will be automatically tested against an audit trail that will highlight automatically and in detail any areas of regression. CPU saving All of the above facilities will be conducted using Windows based workstations, saving considerable CPU processing yet giving highly compatible results. Project management Close planning with the client is essential to find the optimum approach that has minimal impact on production systems. Skilled resources MigrationWare staff are higly skilled in IBM mainframe conversions and may provide cost effective support and assistance to the manual aspects of the project. The future The expense and time spent on your migration project will have an impact on your business, but any negative impacts can be minimised by ensuring: Your migration strategy does not cause unexpected re-work in the future. There is a plan to evolve applications to meet your future business needs. You exploit the opportunities that arise from moving your applications to a more contemporary platform to deliver additional value to the business. This is why MigrationWare works with you to explore if your migration strategy has considered the long-term goals of your business and if you will be able to effectively evolve your migrated applications to meet the needs of your business going forward. The objectives of this exercise is to ensure that: Regardless of your initial migration approach, there is a path to a complete non-proprietary open system architecture that will isolate your mission critical applications from future changes that are out of your control, e.g. your chosen new platform becomes obsolete in the future. The future needs of the business are considered as part of your migration strategy. Our experience helping businesses evolve their open systems COBOL applications to tackle todays business issues will be invaluable to you in developing plans to achieve your specific business objectives.

Potential approaches to IDMS DML migrations

The phrase Migration can mean different things to different people, so before we look at migration approaches it seems pertinent to state our definition of migration. Migration, in the context of this document, means the process of offloading the application currently running in IBM MVS IMS/DLI environment onto an SQL based platform (MVS, Windows, Unix etc). The following are three general approaches to migration: Re-hosting Native migration Re-engineering Re-hosting is making the minimum changes possible and utilising IMS DLI emulation technology on the target platform to replicate existing application functionality.

Native migration is making the necessary changes to fully exploit native technology on the target platform, rather than utilising IMS DLI emulation technology, to replicate existing application functionality. E.g. Convert IMS DLI to DB2 Re-engineering is making whatever changes are required to fully exploit native technology to provide existing application functionality and deliver incremental improvements. Lets look at each of these in a little more detail. Re-hosting Re-hosting is made possible by the availability of technology on your target platform that emulates the capabilities utilised by your existing application on the IMS DLI platform. For example, any calls within your application to access proprietary IMS DLI technology such as the DLI components (PROCOPT, PSB), Database Definitions (DBD) and IMS DC screen handler remain within your application code and are processed with emulation technology on your target platform. In simple terms, the re-hosting approach involves transferring your COBOL application source code to the target platform, recompiling the code with the appropriate Micro Focus COBOL compiler, linking with Micro Focus deployment libraries and testing its execution with the emulation technology on your target platform. It is the availability of the COBOL compiler, execution environment and the compatibility of the IMS DLI emulation capabilities that make such a straightforward approach possible. The application source functions (e.g.) user interface, application code characteristics, and data storage, are replicated on the target platform. This allows the application to be migrated virtually without physical change. When the re-host is completed, the application runs on your target platform providing the same functions and in the same manner to your existing end-users. Native migration Native migration involves a variety of changes to your application code removing any reliance on proprietary IMS DLI technology and instead utilising technology that is native to your target platform. Any calls within your application to access proprietary IMS DLI technology such as the IMS database and IMS DC screen handler are removed from your application code and replaced with code to access standard screen systems and databases which are native to your target platform. For example, calls to access IMS database are changed to standard SQL statements and the data within your IMS database is converted and stored in a standard relational database available on your target platform. In simple terms, the native migration approach involves transferring your COBOL application source code to the target platform, automatically converting any proprietary COBOL statements to the equivalent standard COBOL statements, modifying code to utilise facilities that are native to your target platform, converting data, recompiling the code with the appropriate COBOL compiler, linking with Micro Focus deployment libraries and testing it executing with the native technology on your target platform. Basically, you take the application and modify it to only utilise technology that is native to your target platform. When the native migration is completed, your application runs on your target platform providing the same functions and in the same manner to your existing end-users, however, internally all proprietary IMS DLI elements have been replaced with native technology. Ideally, the end-user would not be aware that the functions are now executing on a different platform from the IMS DLI. Re-engineering Involves updating your application to satisfy a broad spectrum of business requirements such as: Improved maintainability or reduce application down time Improved user interface for increased internal user productivity New user interface to allow access by a different customer base Updated data structures to improve performance or consolidate customer information Re-structuring of processes to allow easier re-use or improved B2B integration

Re-engineering typically involves all the changes described under Native migration plus additional structural changes or significant re-work to improve the architecture of your application or to add some new or improved functionality. For example: It is possible to migrate IMS data to a RDBMS under a Native Migration approach so you can take advantage of a modern RDBMS without actually changing your original data structures, which were designed for the IMS database. However, this may not be suitable for you because you need better performance or consolidated data. You may want to make additional changes to provide normalised relational data storage to maximise performance and increase flexibility. It is possible to take advantage of native terminal information technology on UNIX under a Native Migration to provide the exact same user interface thats currently on the IMS platform but in a way that would work on any UNIX platform in the future. However, this may not be suitable for you because your business has been demanding a modern Windows GUI to improve usability for years, or your business requires an additional web user interface to satisfy a demand for self-service capabilities from your end users. You may therefore want to make additional structural changes to allow for this and then invest in designing and developing your new user interface. You may already be experiencing performance issues or issues related to the maintainability of your application e.g. different problems being introduced every time you fix a problem. If this is the case it may not be prudent to take a rehosting or native migration approach as you will encounter the exact same issues but on your new target platform. Instead, you may want to look at the architecture, structure, duplication and redundancy within your application and make the necessary changes before going live on you new platform. Re-engineering can therefore involve all of the following: Transferring your COBOL application source code to the target platform, automatically converting any proprietary DLI statements to the equivalent ANSI standard SQL COBOL statements, changing code to remove any reliance on proprietary IMS technology and use facilities that are native on your target platform, converting data, updating data structures, changing application structure, removing redundant code, minimising, duplication, designing and implementing new user interfaces, recompiling the code with the appropriate Micro Focus COBOL compiler, linking with Micro Focus deployment libraries and testing it executing with the native technology on your target platform. Basically, you take the application and implement whatever changes are needed to satisfy business requests that have been outstanding for some time or which are critical to the business going forward. When the re-engineering is completed, your application runs on your target platform providing whatever new functions you require for your existing and your new end-users. However, internally all proprietary IMS elements have been replaced with native technology and potentially the architecture has been updated to provide greater flexibility going forward.

Whats involved in the IDMS DML conversion?

In developing your migration strategy, you must first understand whats involved in migrating your applications from your IMS environment. Here is outlined the process and technologies that MigrationWare and the client will need to adopt when converting applications from DLI to an SQL environment.

Automated or manual conversion?

Automation is key. The MigrationWare process will ensure that as much of the inventory analysis, source and data conversion, regression testing, and results analysis is as automated as possible. Automation reduces the risks in terms of production errors or project delays. The risks may be found in the following areas:Application analysis The technology will find every DLI construct that needs to be changed. Typically there will be thousands of DLI calls throughout the inventory and it is important that all are identified at the begining of the project. Each construct will mean code changes therefore the same technology will be applied to identify precisely what code will be changed and, importantly, the impact those changes will have on any other items within the code. Analysing to this degree of accuaracy using manual methods is a lengthy process that is prone to human error. Technology will turn this exercise into days and not weeks with audit trails that prove the accuracy of the analysis and increases confidence in the project sizing. Source Code Changes Changing thousands of DLI Calls by hand is very heavy on human resources and again highly prone to error. Should errors be programmed into the code at this stage, effort will be wasted during latter stages of the project in problem determination.

It is expected that most source modules will require some kind of manual intervention. As these areas are already identified, our experience shows that typically these changes can be made from within one hour for simple complexity changes, to up to four hours for more complex issues. However, for the bulk of the code changes, the technology will convert each source module in seconds rather than days. Regression testing The results of regression testing are influenced by two factors:Quality of test data to ensure the application is exercised to a high degree Human evaluation of the test results Considerable time can be saved using technology that will clearly show areas of the application that have not been tested at the code level, while measuring the quality of test data, automatically. Typically (without automation), the results of a test will have to be analysed with human resources. A great deal of time and effort for end users or business analysts will be expended at the User Acceptance testing phase, by studying program outputs. An automated analysis of test results that show the behaviour of the application at the code level as well as program output comparisons, will cut down this human intervention considerably and, at the same time, increase confidence in the test results by providing a comprehensive audit trail. In summary, as long as the results of the conversion can be clearly reported as being 100% accurate, the automated approach is by far the most cost effective. We expect that using the MigrationWare process and associated technology to convert, fully unit test (to functional equivalence) and provide an audit trail that gives 100% quality confidence, it will take, in the most extreme of cases, no more than 2 person days per program. Compare that to a turnaround of 5 days or more using manual methods - there is an obvious and significant commercial advantage.

Project ownership:
The client will typically need to understand what resources they need to apply to the project and how much involvement MigrationWare need to have. Often clients wish to just utilise the Conversion Toolkit and minimise the usage of external resources (such as MigrationWare) in the project. This is inadviseable in the early planning stages of the project as the Conversion Toolkit will probably need to be enhanced due to specific application requirements. But once these extra requirements have been identified, and an initial application analysis complete, then the client will be able to determine precisely how much of the project they will require to conduct themselves. Should the client request just the Conversion Toolkit after this stage, then MigrationWare will ensure that the client is fully trained in the Conversion Toolkit process and technology and provide the necessary offsite support for the project duration. (This is discussed further below in Working with MigrationWare).

The conversion process:

Sizing the project. To determine the scope of the project, timescales, costs and resources required, then MigrationWare will conduct an Inventory analysis. MigrationWare will initially request that the whole project source inventory is shipped to MigrationWare offices. This is because an intensive study of the source environment will take place and can easily be conducted in isolation from the client premises. Having the sources at MigrationWare offices will also expedite any problem resolution during the course of the conversion project (regardless of where the actual conversion exercise takes place). Electronic transfer mechanisms are normally sufficient. Non disclosure agreements (NDAs) will be arranged as necessary. The inventory will incude all COBOL Sources, DBDs, PSB, and MFS macros. DBD maps and other data layout information. The inventory will be loaded into a Micro Focus Revolve Database where in the first instance, any missing components will be identified. Once the whole inventory is received then the DLI analysis will take place. The sources are studied for all DLI calls. As each client will have quite different programming approaches and standards, it is necessary to ensure that the Conversion Toolkit has the appropriate re-code rules for the specific DLI structures. It is

common that differences will be found and therefore extra re-code rules will have to be added to the toolkit to increase the level of automation. This analysis will determine exactly where and how many changes to the source programs will be made automatically.It will also determine where any manual recodes may have to take place. Because of certain application complexities, it could be the case that up to 20% of changes have to be made manually. The client will separate the inventory into Migration Work Packages (MWPs). Each MWP will be a number of sources and associated Copybooks, MFS, BMS, PSB, DBD etc. They will be related normally by business function and therefore a distinct testing unit. Numbers can vary but around 20 COBOL programs is fairly typical for a MWP. As a result of the analysis, MigrationWare will deliver a full Cost Proposal together with a Macro Plan that will outline the further phases of the project, prioritisation of MWPs, and timescales involved. Re-code rule determination and Data mapping Each DLI call or EXEC structure will need to be converted to the SQL equivalent. In many cases there is a straight forward conversion to be made but normally the conversion is dependant on the differences in data structures. Most Re-code rules will already be in the Conversion Toolkit, but MigrationWare will be studying for further rules that may need to be built after identifying specific patterns of behaviour within the clients code. This is an important part of the conversion project as considerable manual intervetion and risk can be reduced by automating even the simplest of changes. Other than studying the code, MigrationWare will determine further rules based on the mapping of the Data. A spread sheet will be produced that will contain these rules and will become a key input file for the conversion and testing process. Each segement and its field definitions will be included in the spread sheet together with its corresponding SQL data definition. This spread sheet will need to be signed off by the client (typically DBA personnel). As the project progresses through the proving phases and initial MWP testing phases, then candidates for further Re-code rules may become evident. MigrationWare may continue to build these extra rules into the Conversion Toolkit if required, throughout the whole lifecycle of the project. Setting the baseline. Here we introduce two products - Micro Focus Mainframe Express (MFE) and the first part of the MigrationWare Conversion Toolkit, %Exec. The Micro Focus Mainframe Express IDE is a completed IBM emulation environement that runs on Windows workstations (See Appendix A for further details). Together, the technology will contribute significantly to this most important part of the project. Proving that the baseline test data is of a high quality and determining the correct test process through the application will considerably reduce the risk of the project as a whole. The goal at this stage is to take each MWP in order and create a fully executing test environment within MFE. As MFE is project based, then each MWP becomes an MFE project. The MWP sources are compiled and the various macros assembled within the project. MFE allows the client to execute the project against local IMS data or databases that still reside on the mainframe. It is recommended (although not essential) that test databases are downloaded to the workstation environment as this gives the project staff greater flexibility and speed when backing up/restoring data. The MFE project may now be executed as if running in production. Code coverage MigrationWares %Exec will accumulate precise execution data within the application. It will determine exactly what lines of the code have been executed after each test run and will report on the increment of the percentage code after each subsequent test run. This means that for example, if the first test run against the test databases reaches 50% code execution, then by changing the screen interaction or actual data in the database then you can iteratively test until an acceptable amount of code is proven to be executed (typically around 80% ).

Migration input package Once the desired percentage has been achieved then the databases used must be backed up and stored as part of associated Migration Input Package (MIP) for the MWP. If appropriate, screen snapshots of the exact path through the application should be created and saved as part of the MIP. This will assist any person testing the MWP in the future. All JCL again if appropriate, should also be saved into the MIP. A MIP may actually be considered a different MFE project The Baseline Project. Audit trail MigrationWares %Exec will also create a further audit trail during program execution. %Exec will record at key parts within the program logic, precisely how the program is behaving. For example, %Exec will store into an audit trail as part of the MIP, all Data and Screen I/O, key variable values, and the path that the execution takes through the code. This will give the project two benefits:A dynamic analysis of SSA contents can assist in determining more precise Data Mapping and Re-Code rules. The Audit Trail file will be automatically compared to the post conversion test runs and will precisely determine any regression from the baseline. This is explained further below Regression test. Source conversion While it is important to conduct the base-line capture and regression testing by MWP, the whole source inventory may be converted in one phase. This will ensure that all conversion problems that may arise are dealt with early in the project, and again, any subsequent Re-code rules may be found and added to the tool. Manual changes can begin to take place at this time. The Conversion Toolkit is executed within the MFE project environment. To run the source code through the Conversion Toolkit, takes only a few seconds per program. For Input, it will use all appication sources including programs, PSBs, segment layouts and copybooks, as well as the Spreadsheet created during the Data Mapping exercise and all the original Re-code rules plus those specific client Re-code rules. The resulting converted code will be deposited in the appropriate MFE project directories as part of the Migration Output Package (MOP). To minimise Code Freeze time, if changes have been made to the sources in any particular MWP after this source conversion phase, then simply they can be re-converted using the tool and manual process at any time. Managing the Code Freeze window and re-introduction into production will be the responsibility of the client and can be catered for in the intial planning stages with the Macro Plan. Data conversion The Data Mapping exercise will assist in determining the new database structures. Generally the data is mapped closely to the original constructs and relationships. A program is created that will in simplistic terms read DLI data in and write RDBMS data out. This program will be used initially for testing, but may be utilised on the mainframe for the production data conversion. The converted test data will form part of the Migration Output Package. Regression test Once each MWP has been converted the package may be tested for any regression errors. Basically we are searching for exact functional equivalence to the base line execution using exactly the same application context JCL, Screen I/O , Data etc The converted application (The Migration Output package) is executed in the MFE environment once more. As execution takes place, the COMPARE component of the Conversion Toolkit is activated. All those areas that were recorded into the Audit Trail at Baseline execution will now be automatically compared against the variables and program flow in this regression test execution.

10

If any descrepencies are found, the client has two options:To write out all descrepencies to a report file for later analysis. This report may be used as the final proof of the quality of the test and hence the conversion. To halt execution within MFE by breacking into a debug session at the exact line where the descrepency takes place. The tester will then be able to quickly determine the cause of the descrepencey, apply a fix or re-evaluate Re-code rules used. The MFE environment allows programmers to follow the execution of any program by Stepping through the code line by line using the MFE debug facility. Variables can be monitored and changed as necessary, and execution can be halted, re-started or re-positioned within the code. It is likely that there will be some acceptable differences within the code e.g, Date/Time fields. These can be masked out of the reporting mechanism as required. Warranty period MigrationWare will generally offer a Warranty period during the course of the clients User Acceptance testing. Should any Re-codes produce program errors at this time then MigrationWare will address and fix those issues. Summary Organising the project into Migration Work Packages will ensure a focussed approach to the conversion. The client has significant flexibility in precisely how the applications are prioritised for conversion and ultimately implemented in production. More importantly however, is the fact that these applications have been through a build and testing process that can remain as part of the clients development/maintenance process going forward. The test data that has been accumulated is built by Business Function to a level of quality that probably hasnt been realised before or at least not proven to be. The regression testing process is re-usable. The execution data can continue to be accumulated both for the Baseline test environments and for any change projects. Almost all of this conversion process has been condcucted away from the Mainframe. Considerable CPU cycles have been saved in terms of Edit, Compile, Build and Test., and importantly significant productivity gains have ben realised using the Workstation based technology.

Maximising development team productivity on the target platform

Typically, vendors offering application migration capabilities do not address this key requirement because they are focused on their end point of delivering the migrated application. However, accepting delivery of the migrated application is actually the start point for the development team that will continue to maintain and enhance the migrated application, to meet your ongoing business requirements. Organisations typically understand the need to migrate their applications off the outdated environments, but overlook the fact that the team of developers maintaining and enhancing the application will no longer be able to utilise the development infrastructure and development tools they have been using so far. This is why MigrationWare will work with you, in parallel with the application migration, to help your IT department implement an effective application development infrastructure and provide the training required, ensuring your development team can: Seamlessly continue to service business requirements even though the application is now using an SQL-based platform. Take advantage of the improved development tools on your new platform to service the business requests faster than was previously possible. Begin to take advantage of the modern infrastructure capabilities available on open database, that were not available on the IMS environment, to evolve the application to respond to your business needs better than ever before. In order to realise these benefits, MigrationWare will work with you to ensure: The optimum development infrastructure is set up to exploit Windows workstations for development, regardless of the new deployment environment.

11

Developers are trained to use the Micro Focus IDE, the new tool they will be using to understand the impact of potential changes before they are applied, to make the required changes and test the updated code. The proven new testing process that the client will have adopted throught the migration process will still be very relevant to onging maintenanence and development tasks. The Integration/Build teams can efficiently perform the integration and build activities needed to promote the application to the new production environment.

Working with MigrationWare Migration options

As discussed, MigrationWare provide tools, process and expert services to deliver a high quality and fast migration project. The objective in any of these projects is to automate the process as much as possible. However it is unlikely the project can be automated 100%, and it is therefore, these areas that MigrationWare are most interested in identifying to ascertain the complete scope of the project and project complexity. MigrationWare can supply the Conversion Toolkit out of the box, but it is essential that the client is trained extensively in the methodology that must accompany the Toolkit. In this case the client will only be able to automate those Re-code rules that are already identified in the tool. Even the simplest of new Re-code rules discovered, can mean extensive manual intervention in the project. It is far better to utilise MigrationWare at least in the early phase of the project, so that the Conversion Toolkit can be adapted to the clients specific needs, or at least to identify clearly to the client what areas need to be handled manually. Here are three options that the client may choose when engaging with MigrationWare:-

12

Option 1 Task Phase l Conduct Process / Tool Training Provide Inventory Conduct Inventory Analysis Scope Project Macro Plan Identify & Build Re-code rules Create 1st MWP Test 1st MWP Sign Off Phase I Phase ll Process All MWPs Unit Test Phase lll Provide Warranty User Acceptance Test X X X X X X X X X X MWare

Turnkey Client

Option 2 Semi - Factory MWare Client

Option 3 MWare

Toolkit Client

X X X X X X X X X X X X X

X X X X X X N/A X X X

X X

X X

N/A X

N/A X

N/A

N/A X

Option 1. Turnkey solution. A Turnkey solution is normally offered where the client has minimal resource available to conduct a conversion project. By providing this option, MigrationWare will take responsibility in delivering code that has been fully converted and tested to functional equivalence. MigrationWare staff will spend a significant part of the project on-site analysing the applications, accumulating the test data environment, and creating the MWPs. At this stage MigrationWare will need assistance in defining the Test Scripts to execute thed baseline test. MigrationWare will also need to consult with internal database specialist to design the data structures. The major part of the conversion will then be conducted both on and off site. The client will be required to sign off each MWP once it has completed the Regression Test Phase. Option 2. Semi-factory approach. This approach will allow the client considerable control in how the project is conducted. Essentialy the goal of this option is for MigrationWare to use its expertise in sizing the project, proving the process on the first MWP, and then to educate the client in the process and technology to convert and test the rest of the inventory themselves.

13

After the initial analysis, MigrationWare will make every effort to ensure that as many Re-code rules have been built into the Conversion Tool as possible. MigrationWare will work together with the Client to create the first MWP and use this as a proving stage for the process. The Client will conduct the rest of the project themselves, only calling on MigrationWare if any of the new code is causing peoblems. MigrationWare will typically offer a d3 month warranty for this level of service. Option 3. Toolkit only. As discussed it is more difficult to conduct a conversion project with the tool kit out of the box. However, all of the Converion Toolkit can be made available alongside some eduction on the methodology required. It is worth openeing a channel for discussion with MigrationWare during the course of the project for their guidance in terms of project sizing and management, and how you may feed back Re-Code rule requirements back to the development team.

Summary
There is an increasing requirement for applications to provide business-to-business capabilities through the use of open, SQL based data repositories and there are not many products and service offerings to assist companies with their IMS DLI conversion efforts. MigrationWare understands the value of legacy COBOL applications and as a result has developed a sophisticated Conversion Toolkit. This complements the Micro Focus Mainframe Express technology that will form the foundation technology that will execute the sometimes very complex DLI conversion project. When combining our leading-edge technologies and experience with those from Micro Focus, we can offer a complete Iapplication conversion strategy that can be custom-tailored to your individual company needs. We offer a breadth and depth of options not available from any other single source. If you would like more information you may contact MigrationWare by phone (see www.MigrationWare.com) or send an email to sales@migrationware.com with IMS/DLI in the title of your note.