IMS Conversion Toolkit

8/3/2019 IMS Conversion Toolkit

http://slidepdf.com/reader/full/ims-conversion-toolkit 1/14

Application migration from

IMS DLI environments



1

AbstractThis 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 applicationsto 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

MigrationWare’s 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 3

Why MigrationWare? 3

Where can MigrationWare help? 3

The project 3The future 4

Potential approaches to IDMS DML migrations 4

Re-hosting 5

Native migration 5

Re-engineering 5

What’s involved in the IDMS DML conversion? 6

Automated or manual conversion? 6

Application analysis 6

Source code changes 6Regression testing 7

Project ownership: 7

The conversion process: 7

Sizing the project 7

Re-code rule determination and data mapping 8

Setting the baseline 8

Source conversion 9

Data conversion 9

Regression test 9

Warranty period 10

Summary 10

Maximising development team productivity on the target platform 10

Working with MigrationWare 11

Migration options 11

Option 1. Turnkey solution 12

Option 2. Semi-factory approach 12

Option 3. Toolkit only 13

Summary 13

2



IntroductionAlthough 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 chargeof 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 competit ive 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 theproject, timescales and costs.

3



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 goingforward.

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 today’s business issues will be invaluable to you in developing

plans to achieve your specific business objectives.

Potential approaches to IDMS DML migrationsThe 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.

4



5

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.

Let’s 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 screenhandler 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



6

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 that’s 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 “re-

hosting” 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.

What’s involved in the IDMS DML conversion?In developing your migration strategy, you must first understand what’s 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 analysisThe 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.



7

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 degreeHuman 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 off-

site 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 (NDA’s) 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

wil l be identif ied. Once the whole inventory is received then the DLI analysis wil l 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



8

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 (MWP’s). Each MWP will be a number of sources andassociated 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 ConversionToolkit, %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

MigrationWare’s %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 acceptableamount of code is proven to be executed (typically around 80% ).



9

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 trailMigrationWare’s %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, PSB’s,

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 sourceconversion 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

init ial ly for testing, but may be uti l ised 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 lineby 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 client’s 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 hasn’t 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 usingthe Workstation based technology.

Maximising development team productivity on the target platformTypically, 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 optionsAs 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 Option 2 Semi - Factory Option 3 ToolkitTurnkey

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

Process All MWPs

Unit Test

Provide Warranty

User Acceptance

Test

Sign Off Phase I

Phase ll

Phase lll

X

X

X

X

X

X

X

X

X

X

X

X

X

X X

N/A N/A N/AN/A

N/A

X

X

X

X

X

X

X

X X X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

MWare Client ClientMWare MWare Client

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 inventorythemselves.



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.

SummaryThere 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 [email protected] with IMS/DLI in the title of your note.

IMS Conversion Toolkit

Documents

Transcript of IMS Conversion Toolkit