厂商们最近开始吹捧关于大型机迁移这一存在些许矛盾的理念了。尽管如此，此举将为大型机上应用的跨平台提供便利。
大型机迁移的概念
大型机迁移的关键在于，提供便利的应用软件移植途径，使应用可在源代码级别完成至Windows或 Unix平台的移植。在此前提下，这些产品的目标将趋向于批量处理及模拟COBOL CICS。移植应用软件的方法多种多样，但主要有以下因素：
编程语言。有很多可用的COBOL编译器，最流行的是起于80年代的Micro Focus COBOL。用其他语言编写的模块，例如C、C＋＋或Java对平台的兼容性更强，也更容易进行跨平台移植。
数据仓库。一般来说，DB2应用是可以完整迁移至其他关系型数据库管理系统平台上，例如UDB、 Oracle或SQL Server。企业同样可以选择开源数据库引擎以节约后期成本。产商们有许多不同方法以应对虚拟存储访问方法（VSAM）数据集：某些在分布式文件系统上模拟VSAM集群，还可以通过提供包含某些DBMS后端将VSAM文件调用转换为SQL语句。
交易处理模拟器。供应商们通常会提供某种CICS模拟器，用于支持大部分的开放应用程序接口（API）。在这样的情况下，命令调用将通过模拟软件实现类CICS的功能。我目前还没有发现一款可以用于IMS数据库或者在线交易的模拟器。
批量处理。某些产品包含了工具，用于将一次性会话的工作控制语言转换为脚本。其他产品则通过一个实时翻译器运行原始的JCL。
移植应用最大的问题莫过于重新编译。潜在问题可能包括PL/1与汇编程序的重写或调试。某些代码可能会因为无法完全模拟CICS命令的一个子集而需进行修改。最后，应用程序可能会有很少部分，如IMS数据库或企业组件无法迁移至其他平台。遇到这种情况，就需要有所取舍，采取应对方法以实现所需功能。
#p#
大型机迁移的优势
大型机迁移支持者指出了几个方面的优势。首先迁移意味着对传统应用的投资，如果企业拥有可靠强劲的大型机应用并创造利润，这样的投资将很容易实现。其二，代码可以充分调试、测试与预测。最后，移植意味着多年应用维护的经验与知识积累。
厂商们表示，移植应用程序比重写的风险要小。像之前所提及的，旧软件是久经考验的，而重写软件是件十分消时而又昂贵与艰难的事情。产商们指出，迁移项目有很多因为重写代码而失败。
大型机迁移最终与最重要的原因在于其可以节约开支。可以看出成本开支与大型机的价值是最大的矛盾。这两个方面都可能引起无尽的研究与调查，以说服对方，但是没有魔法药水可以将大型机每秒百万指令集（MIPS）转换为SPECinits。不仅如此，软件性能会因为平台而不同，在迁移规划中，各款软件都需要在不同平台上不断进行测试分析。
#p#
大型机迁移是个好主意吗？
最后，迁移依赖于长期合作目标、文化与应用程序关系。企业将花费心思对待成本开支，详细分析开销与投资回报。同样需要考虑个人与企业开销。
公司同样需要与产商建立长期合作关系。在迁移后，企业将可能摆脱IBM的硬件束缚，但同样可能陷入模拟软件供应商的制约中。
分析结果要为迁移的可行性负责，专门用于发挥大型机性能的软件可能无法在其他平台稳定运行。相反，移植交易将无法改善Windows或Unix性能。最后用户很可能得到与预期相距甚远的产品或结果。
最后，选择大型机迁移所适合的应用软件十分重要。对于待移植的系统，最好是小型、自行包含COBL的应用，没有任何IMS接口的松耦合架构。松耦合意味着其他应用程序接口通过网络、MQ或批处理文件进行交互。所以至少在在第一阶段，公司需要避免使用那些通过策略赚钱的软件。
大型机迁移很可能是某个战略计划中一个无关轻重的技术细节。无论公司是否计划将应用移植到其他平台都没有太大的影响。如果某个程序需要重新设计或重写，企业需要考虑其对应的平台。这样做将可以避免受厂商长期限制，并创造出一个确实合适的现代应用软件。
【编辑推荐】
