靜態call 動態call LINK

 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命令。