Concepts of Migration Projects?

[Nitin Gadge]

Hi,

Is there some general strategy of Migration Projects? Possibly my question is pretty loose ended as for different migration platforms the strategy will be different but in general, if someone migrate to Mainframes from other platforms what general considerations can be taken care. Nothing like a question but would like to hear thoughts on this.

[Robert Sample]

Scheduling -- mainframes often have complicated, intricate networks of batch jobs running and replicating these networks can be a problem.

Non-display data -- binary or packed decimal data in files will have to be changed before migration

Non-sequential data sets -- VSAM data sets may need to be replaced with something on the target platform

Source language conversion -- even if the same source language is available on the target platform, there will usually be some dependencies to fix (such as SELECT statements in COBOL, for example)

Backup and recovery -- mainframe applications usually have detailed and complete backup and recovery processes; a daily production job with a 1% chance of problems will fail 3 to 4 times a year so backup and recovery are important to consider.

Data volume -- a 20 GB file on the mainframe is not that unusual; being able to process such a file on the target platform may pose issues.

External interfaces -- if the applications gets data from or puts data to an external interface, that interface may need to be revised (for example, some bank interfaces require hard-coded IP addresses and that can cause problems when migrating away from a mainframe).

There are others but these are the one that came to mind for me.

[byelen]

Hi Nitan,

First of all, I'm all in favor of seeing more migrations TO the mainframe! To many migrations are to move away from it.

Each migration can be so different, that there really aren't any general strategies beyond the obvious of comparing data types, checking data integrity, comparing application results and so forth. The main thing to always keep uppermost in your mind during the process is to Test! Test early! Test often! Test again! Test some more! Drive everybody crazy with your incessant demands for continual testing. And, insure that there is sufficient overlap in the schedule to allow for testing the new system in parallel with the old. Make sure that the results coming off the new system exactly matches the old. Different languages can (and will) yield slightly different results due to how they handle rounding. We had a case where after a rewrite of a payroll calculation program in COBOL (with the new program also in COBOL), the new vs old results could differ on an employee's paycheck by one cent. The applications programmer involved couldn't figure out why this could happen, as the exact same formula was used. We traced it down by having the compiler generate an assembler listing for the two programs. The difference was that the old program used "ADD", "SUBTRACT", "MULTIPLY", and "DIVIDE" statements, the new one just a "COMPUTE" statement. Each statement in the old program did its own rounding. The COMPUTE statement rounded once, at the end. Had we not performed exhaustive testing, we would not have caught this, and a real "circus" would have resulted when employees started complaining about being shortchanged one penny!

- Bruce

[Nitin Gadge]

 Make sure that the results coming off the new system exactly matches the old.  Different languages can (and will) yield slightly different results due to how they handle rounding.  We had a case where after a rewrite of a payroll calculation program in COBOL (with the new program also in COBOL), the new vs old results could differ on an employee's paycheck by one cent.  The applications programmer involved couldn't figure out why this could happen, as the exact same formula was used.  We traced it down by having the compiler generate an assembler listing for the two programs.  The difference was that the old program used "ADD", "SUBTRACT", "MULTIPLY", and "DIVIDE" statements, the new one just a "COMPUTE" statement.  Each statement in the old program did its own rounding.  The COMPUTE statement rounded once, at the end.  Had we not performed exhaustive testing, we would not have caught this, and a real "circus" would have resulted when employees started complaining about being shortchanged one penny!

Thanks for the example. It make all the sense. But whenever we talk about such migration, there are many tools involved in the talks. What are the tools do you suggest had been useful in such migrations?

[Robert Sample]

What are the tools do you suggest had been useful in such migrations?

How high is up?
The reality is that the migration details will mandate the tools used -- if you're migrating from a mainframe to a Unix platform, for example, the tools (and the processes) involved will differ than migrating from a mainframe to a Windows platform -- or from a Windows platform to a Unix platform.  Furthermore, migrating from COBOL source to Java source would mandate different tools than if you're migrating from COBOL to COBOL.  Nobody can suggest tools without knowing the details of the migration -- if you find someone doing so, avoid that person as he/she is a fool!

[Nitin Gadge]

I agree that tools will differ. I'd be more interested in the mainframe to java migration tools When we search about it on google many tools come up and mostly from the vendors and not from the users so that we can understand what tool might create what problem, at least to understand at initial level.