COBOL动态与静态调用

    COBOL的调用可以是静态调用（Static Call），这时，被调用的子程序必须与调用程序一起链接（link-edited）起来形成一个完整的装载模块（Load module）,但子程序依然可以单独编译。这种方法会生成一个大的模块，同时也使得多个主程序调用同一个子程序时共享程序拷贝的愿望落空。
    另外一种COBOL调用方法是动态调用（Dynamic CALL），这时，被调用的子程序必须编译和链接成一个独立的装载模块（Load module）。它可以与主程序一起放到同一个装载模块库中。当有多个主程序调用同一个子程序时，大家可以共享它的程序拷贝。 
    在CICS中我们使用LINK或XCTL命令调用CICS子程序，是否我们可以使用COBOL的（静态的（Static）或动态的(Dynamic）CALL语句呢？COBOL的CALL语句在CICS中到底会有什么样的效果呢？如果可以，那么COBOL CALL与CICS的LINK或XCTL有什么区别呢？哪种方法效率更高？
许多程序员甚至工作过很多年的大机CICS程序开发人员都有类似的疑问，很难清晰地回答上面的问题，现在，借此机会，我们一起来回答它。
COBOL静态调用是用CALL LITERAL（文字常数）来说明的，程序是用COBOL的编译选项NODYNAM编译的。被调用程序必须由调用者进行连接编译，并与调用程序一起生成一个装载模块。
    COBOL动态调用使用CALL VARIABLE（变量）来说明的，不管COBOL编译是用DYNAM或NODYNAM选项，都是动态调用。动态调用的程序会生成独立的装载模块，因此可以被多个调用者共享。 
    COBOL的CALL语句可以说类似于LINK语句，因为它们都会转移到下一逻辑层运行，但XCTL则在同一逻辑层运行。此外，CALL语句象LINK一样在执行完后一定要将控制权转移回调用程序而XCTL则不用。在CICS中，程序之间是通过DFHCOMMAREA来传递信息的。XCTL命令相对于LINK命令来说，开销要小些，因此性能要优越些。此外，调用程序不会指望被XCTL的程序将控制权转移回调用程序。
    在CICS中我们可以使用CALL语句动态调用子程序，但这时，子程序必须定义在CICS的程序处理表（PPT）表中，而在CICS中使用CALL语句调用子程序也只能在VS COBOL II中 才可以，换句话说，COBOL 74不支持这种方法。
    毫无疑问，我们可以使用COBOL CALL语句代替CICS LINK命令，但是，它代替不了XCTL命令。有许多理由支持使用动态调用（Dynamic CALL）比静态调用（STATIC CALL）更好。假定我们使用动态调用,它与CICS LINK语句的区别是：
	COBOL CALL比LINK有更好的性能，因为CALL与主程序处在同一个运行单元（Run unit）中，而LINK与调用程序处于不同的运行单元中。 
	COBOL CALL可以用来在主程序和子程序之间传递最多32K的通讯区。
	COBOL CALL可以传递多个数据项而LINK只能传递一个数据项即DFHCOMMAREA。 
	COBOL CALL只能使用在单个CICS区域（Region）中而LINK可以在不同的CICS区域中转移控制，LINK是为了支持类似于VS COBOL中的CALL语句而创建的。
    事实上，我们可以使用三种方法调用子程序： 
	使用COBOL CALL语句 
	使用CICS LINK命令 
	使用CICS XCTL命令 
    如果你使用静态CALL语句，则每次编译时你必须连接到被调用程序而每个调用程序都会有一个被调用程序的拷贝。比如，程序ProgA、程序ProgB和程序ProgC都静态调用程序ProgD，这时，在内存中就会有ProgD的三个拷贝，分别供ProgA、ProgB和ProgC使用。 
    另一方面，如果你使用LINK或XCTL语句，则在CICS区域中只有ProgD的一个拷贝被调用程序ProgA、ProgB和ProgC共享，因为在CICS中，程序是可重入（re-enterrant）的,这样，每个调用程序会有自己的区域但被调用程序会在所有调用程序之间共享。
    所以，从CICS资源的角度来看，它们是有区别的。毫无疑问，使用COBOL静态CALL时由于每个调用程序有单独的被调用程序区域，运行效率当然要高些，但对CICS的资源来说，则是很大的负担。所以，除非被调用程序使用得非常频繁，使用LINK和XCTL更好一些。 
除此之外，还有一些因素也是我们需要考虑的：
    小心使用CALL语句，因为你所调用的子程序使用的内存空间会累积起来，从而大量增加你的交易使用的内存空间。它会使你的内存使用量迅速提高。使用LINK命令时，属于被调用程序的工作区（Working storage）会在程序返回调用程序时会释放出来，所以，使用LINK命令会降低你的内存的消耗，它会自己打扫战场。而COBOL CALL从内存使用的角度来看是笨蛋。被调用程序的工作区只有在运行单位结束时才会释放。这种情况典型地出现在从CALL语句返回时，而从LINK语句返回时则不会发生。
    如果你喜欢CICS调试工具CEDF，你就会知道它不会显示CALL语句的活动但却会显示LINK命令的活动。这也是本人喜欢LINK比CALL多一点的原因之一。同样你在阅读系统跟踪（Trace）报告时，也会发现它只报告CALL语句的只言片语，但对于LINK命令则有详细的报告，这是本人喜欢LINK多过CALL的另外一个小原因。
    静态调用（STATIC CALL）管理起来更困难因而不值得考虑它所产生的一点点额外的效能。静态调用的另外一个问题是，当你修改子程序时，你必须修改所有调用它的主程序，这是令人讨厌也是容易出错的。我的建议是，总是使用动态调用除非你有令人信服的理由要使用静态调用。
    如果在你的程序中混合使用LINK和CALLs则你的交易确实要消耗大量的内存空间。例如，假定我们有三个程序分别是A、B和C。考虑下面的情节：
	A CALL C, C 返回 A 
	A LINK B 
	B CALL C 
    这时，系统需要分配4个而不是3个工作区（working storage）。程序A和B各有一个工作区，而程序C则要二个工作区。C需要分配二个工作区是因为它需要在二个不同的运行单元中运行。在上面的例子中，如果只使用CALL则只需要分配3个工作区。
再补充说一下XCTL命令。我们只在从一个画面(MAP)跳到下一个画面时才使用XCTL命令。换句话说，只是在画面层而不是在业务处理层使用XCTL命令。

    上述内容节选自即将于本月末出版的《IBM主机技术一本通》中，博客 http://blog.sina.com.cn/newmanworkshop 提供了该书的前言和目录，欢迎大家阅读了解详细情况。