今年是CICS诞辰40周年。它从最初的面向小型企业的汇编语言程序发展到今天这一步，经历了漫长的发展阶段。对此，我想对CICS的未来发表一些我个人的看法。

　　CICSPlex System Manager（CPSM）

　　总的来说，CICSPlex System Manager（CPSM）是一个喜忧参半的产品。一方面，它是监测和转换资源的绝佳工具。尽管有一些小问题，但CPSM的动态处理路由（DTR）非常好用。最后，CPSM还是Web User Interface（WUI）和CICS Explorer的顶梁柱。WUI和CICS Explorer是两个非常不错的管理工具。

　　遗憾的是，CPSM也是一个复杂的“黑盒子”，它的应用程序接口（API）常常不能以同样的方式工作两次，这让人感到很是莫名其妙。此外，CPSM实时分析（RTA）的警告信息在控制台会弹出两次，而不是一次，这也是一个很恼人的事。

　　任务控制块（Task Control Blocks）更多

　　CICS的单任务结构有两个缺点。首先，CICS所运行的任务负载永远不可能超过一个CPU的处理能力。第二，任何操作系统等待都会冻结整个CICS region。

　　IBM在CICS地址空间里建立了很多任务，并且将TaskControlBlocks（TCB）分为一些“mode”组，每个mode专门处理一个特定的任务。后来，IBM又进一步完善了用于在不同任务mode之间迁移正在运行事物（也就是任务）的代码，使得事务的迁移变得更加轻松（除了指令路径长度变长了以外）。随着IBM不断地找出更多CICS可以做的事情，新的任务mode也会不断出现。
　　
　　资源管理接口与相关任务用户并存

　　资源管理接口（RMI）是由CICS的概念引申而来，它是一个任务协调单元。通过资源管理接口，要求数据完整性的其它系统可以参与同步或恢复处理，比如数据库（DB2和IMS）或收发消息（MQ）。等下一个大型数据库管理系统（DBMS）出现时（DB3或DL/2），只要有可用的RMI接口，CICS就可以支持它。

　　CICS高级语言运行时间库

　　如果编程的限制太多或者CICS的多任务环境被破坏，那么对COBOL或PL/1等高级语言的支持就没有多大的意义了。不过，有些IBM的人认为，为高级语言提供CICS运行时间库（CICS run-time library）可以使它们更轻松地进入CICS环境。这些CICS运行时间程序会处理操作系统之类的请求（例如程序管理），创建工作存储的单独复本。这样，即便是COBOL程序也可以并行运行。

　　当然，限制CICS程序可以做哪些事情的一些限制还是必要的。不过，随着CICS的多任务控制块（TCB）结构和API的不断扩增，这些限制将会不断减少。随着语言环境的出现，各个单独运行时间库的维护也会逐渐轻松下来。

　　多区域操作

　　多区域操作（Multi-region operation）是一个很大的进步。系统管理员不再是处理多个单用途的区域（region），而是可以将它们连接到一个灵活的CICSPlexes。

　　这样，各个region可以彼此进行对话，此后的很多概念都是从这个想法发展得来的。

• 远程资源定义  远程资源定义允许Baltimore中的事务使用Vancouver中的文件，而且不用对应用程序做任何更改。
• 用户可以设计拓扑并行运行多个事务，从而避免达到CICS TCB的处理能力极限。
• 我个人最喜欢的是动态工作路由（dynamic workload routing）。这使得特定的任务不必绑定到特定的region了，路由软件可以根据自己的标准做出选择，从而可以避免瓶颈和降低系统系能。没有它，我无法想象我们的应用会怎样运行下去。

　　我不知道下一个将会出现什么功能，但是我相信灵活性和结构化会让CICS满足市场的任何需求。