在本文的第一部分中，我们为大家介绍了大型机迁移策略的制定和基本思路，接下来我们为大家继续讲述迁移大型机应用到Linux，Unix和windows平台有效方法。

　　我们假设你有一个项目的目标是迁移走大型机上的所有应用，通常这个时候你会担心运行在z/OS上的旧应用程序，特别是那些与大型机紧密相关的技术，如COBOL，IMS，CICS等。我们再假设你已经根据本系列的第一篇文章制定好了最佳实践策略，首先将要迁移的软件进行归类，然后选择第三方迁移工具和列出详细的操作过程。

　　接下来的任务是任务分解，首先弄清楚哪些软件最容易迁移，然后为不同类型的大型机软件制定迁移步骤，准备相关的工具，总之就是要将复杂的任务进行分解，划分成一个个容易实现，容易办到的小任务。

　　根据迁移难度级别划分应用程序

　　因为大部分大型机应用都依赖于大型机特定的环境，过去用户发现这类迁移比Unix迁移到Linux，或windows迁移到Linux都要复杂得多。那些不会使用任何大型机特定的软件或固件用COBOL编写的应用程序，大多数时候可以在目标平台上实现开箱即用的效果，这几乎没有难度。那些依赖于COBOL的和某些使用了CICS的应用程序，在Unix/Linux/windows上需要使用CICS或UniKix，也就是说需要在新环境中重新创建CICS，这有一点难度。

　　难度大一点的是那些只依赖于COBOL，DB2和/或CICS的应用程序，DB2转换并不简单，即使DB2在大型机和其它平台上现在都能很好地运行，但由于大部分依赖于DB2的应用程序使用存储过程实现的业务逻辑，而这些存储过程往往是依赖于大型机的。此外，多个应用可能使用的是相同的数据库/数据存储，但存储过程却又不同，因此需要在目标平台上重建那些存储过程。

　　除了那些20多年前的主流软件外，还包括依赖于第三方大型机数据库——Datacom，MODEL 204，Adabas的应用，以及IBM数据管理系统——IMS。许多应用使用专用编程语言（MODEL 204用户语言）或老式的3GL（第三代语言）——PL/1、FORTRAN。因此，这些应用程序如果不能在目标平台上顺利通过编译，那就得重新编写代码了，但幸运的是，现在许多迁移工具已经能够帮助我们自动完成代码重写任务，因此迁移规划一般只需要几个月，而不会长达几年了。

　　我们再来看看那些严重依赖于IBM程序集或裸机ISAM和VSAM数据存储技术的应用程序，这些应用通常缺乏说明文档，可能无法完全搞清楚，那些当年编写这些应用程序的人现在可能已经退休了，因此，自动再生工具可以指出在新环境中重建它们的方法，最著名的就是10年前千年虫问题期间出现Y2K这样优秀的再生工具，有些工具正是因为其处理艰巨的迁移任务的能力得以生存至今。

　　但值得注意的是，即使有些应用程序你做了很大的努力去修改它，但它仍然不能很好地在新平台上运行，于是出现了一些分析工具，它可以对应用程序的功能进行分析，并捕获它们的行为，然后模拟这些行为在新平台上生成新的应用程序，至少可以为开发人员生成这些不可迁移的大型机应用程序在新平台上的基础代码。

　　任务分解

　　关于任务分解的最佳实践与你如何使用大型机应用程序分类结果有关，聪明的用户不会首先将重点放在关键业务应用程序上，无论它是否容易迁移，因为这样做会造成整体迁移进度滞后，相反，这些用户首先会为每个分解的任务寻找合适的工具，并制定好各自独立的迁移步骤，然后优化整个过程和资源分配。

　　在分解完任务后，应该确定哪些应用程序不需要迁移，因为你可能发现这些应用程序不是那么容易迁移，同时找出最容易迁移的先行迁移。

　　在分解任务时还需要重点考虑的是尽量使用自动化迁移工具，不要图便宜使用廉价但功能不佳的迁移工具，迁移关键业务应用时尤其应注意这一点，因为它可能是最大，最复杂的应用了，迁移这些关键应用所花的时间可能也是最多的，而且是整个迁移工作中最主要的一步。

　　小结

　　如果你读完本系列所有文章，你对迁移所有大型机应用应该都会有一个清晰的思路，每一步使用什么工具最好，有哪些步骤最佳应该都有把握。

　　但我要告诉你不好的消息，大量的迁移实践证明，简单的划分应用是不行的，分解的目的是要找出迁移到新平台上需要花多少时间，而不是软件在新平台上如何才能更好地运行，在新平台上性能是否有明显的下降，是否可以简单地一次性迁移成功，过去的经验表明，这些因素往往是造成迁移延迟的重要原因，也是造成用户业务中断的罪魁祸首。关于大型机应用在目标平台上如何更好地运行是本系列第三篇文章要讲述的主要内容，敬请期待！