在计算机软件和系统中，性能和灵活性是两个典型的对立因素，因而此消彼长。在以前64K机器的时代，CPU主频以TIPS（每秒千条指令）为单位，那时的机器性能都是差不多的。但是，现在随着机器速度的加快、Web接口和IT技能的欠缺，灵活性也变得越来越重要。因此，在本文中，TechTarget中国的特约专家Robert Crawford将为您提供一些提高大型机应用灵活性的技巧。

　　抽象法或间接法

　　几年以前，CICS提出TOR（terminal owning regions），引入了一定的抽象性或间接性，后来被普遍称为RR（Routing Regions）。如果客户机直接与处理事务的CICS相连接，效率会更高。但是，为了获得更充足的CPU资源，减少一些烦恼，你可以将客户机连接到RR，然后由RR决定事务的最终到达。这样的灵活性会有利于任务分配和可用性。

　　其它有些系统服务也可以提供这种功能，如WebSphere MQ shared queues，Sysplex Distribution（SD），还有VTAM generic resources。无论使用什么设备，它的原理都是一样的：利用一个智能的中间介质，由它根据性能和资源可用性情况做出任务路由决策。

　　外部参考表格数据

　　包含参考数据的内部表格性能总是比外部表格或数据库要好。然而，更改内部表格需要程序生命周期、回归测试（regression test）和生产实践（production implementation）。虽然外部表格的执行成本稍微高一点，但它能使生产更有效率，从而从中获利。

　　动态控制块结构

　　动态控制块结构（Dynamic control block structures）在系统级软件中应用得较多。不过，有些复杂应用或公司事业可能也可以受益于这种结构。在过去，静态结构表现得也不错，更改静态结构并不成问题，因为18：00后就没人会使用系统了。

　　显然，现在不能这么做了。系统和应用软件需要维护和更新它们的结构，又不能被中断。想像一下，你要将连续的表格更改为链表，还要考虑如何更新回弹（bounce）地址空间的控制块。最后，你还要为软件添加逻辑，建立结构，而不是去预计需要多少块。

　　版本相容（Version Tolerance）

　　当大型机完全占领市场后，我们以为已经解决了这个问题。然而，多年的客户机“革命”不但没有解决这个问题，反而使问题更加严重了。通常，Unix和Windows客户机通过严格的应用协议向服务器请求数据。结果，我们经常发现客户机和主机要么在一个锁定的步骤里工作，要么都不工作。更可怕的是，新版本将无法工作，用户在星期一登陆之前，服务器与客户机都只能退出。

　　要解决这个问题，有两种方法：

• 模块版本控制（Module versioning）：为应用例行程序名、客户机和服务器添加版本限定符，允许同样模块的多种不同版本同时被使用。这个方法有个缺点，就是必须要有人写路由器代码以调用正确的模块。此外，多个装载代码还需要额外的虚拟存储和物理存储成本。
• 消息版本控制（Message versioning）：在客户机和服务器交换的每条信息中都包含接口版本号（interface version number），这可能是最干净利落的做法了。尽管降低了同一模块不同版本的存储和维护要求，但它要求所有应用信息处理逻辑（application message processing logic）都能识别接口层（interface levels），并知道如何处理。此外，还有另一个难题：何时可以安全地废弃某个过时的接口版本并删除它的代码。

　　Version tolerance和系统软件有所不同，它假定操作系统与其所有子系统是可以进行不同级别的互操作的，包括维护和释放。

　　用户自己是不能这样做的。IBM和其它厂商会为它们的系统写入tolerance。它们还必须为已经很复杂的测试脚本中加入版本互操作性。

　　性能投资物有所值

　　对性能的投资是巨大的，不过其回报也是丰厚的。想像一个这样的世界：公司可以用新的维护IPL一个LPAR。如果一切正常，它们可以保留高级的LPAR，并将它引入承担生产任务的Sysplex。在确定新软件的安全性的一周里，不停地进行测试。然后，下一个周末系统程序员就可以高枕无忧了，余下的LPAR会被自动放到新发布中。

　　维护点（maintenance point）和系统较少是大型机的一个优势，然而在系统版本控制中，这反而成为了劣势。这让有些人感到不安，不过这是我们对大型机必须有的。它在Unix中运行良好，这证明可用性和系统管理员的生活质量都得到了提高。

　　以我的CICS背景，我往往宁可选择灵活性。我更倾向于可用性要求和一些“狡诈”应用的处理。然而，作为一个致力于节约成本和充分利用机器的mainframer，我认识到了性能和简洁的重要性，并不断地在寻找二者之间的最佳平衡点。

　　关于作者：Robert Crawford有24年关于CICS系统项目的经验。他擅长于调试应用，也写了关于COBOL、Assembler与C++、DLI 和DB2方面的书。