從ＵＮＩＸ到ＩＢＭ主機系統的程序移植探討

文章編號：1672-5913(2008)19-0086-04

摘 要：本文介紹了UNIX平臺與IBM主機系統平臺之間的差異，并對跨平臺移植過程中應考慮的主要問題和解決方法進行了探討。

關鍵詞：IBM主機系統；移植；作業控制語言；初始化器

中圖分類號：G642 文獻標識碼：A

1 引言

IBM主機系統，又稱IBM大型機，是20世紀60年代發展起來的計算機系統，在全世界各大國家中肩負著銀行、保險、證券、通訊等行業的數據與信息處理工作，因為其獨具的高安全性、高穩定性和強大的數據處理能力，迄今無可替代。

近幾年來，主機系統的前景不斷看好。從1994年起，IBM開始對大型機進行深入的技術改造，采用了新的CMOS技術，極大地縮小了大型機的系統體積，降低了能耗和散熱成本，提高了性能價格比。另一方面，分布式計算開始變得龐雜起來，許多公司的管理費用激增，而且由于數據分散，在數據的互訪和集中管理方面，安全和準確性都不夠高，許多企業開始轉向使用大型機。大型機在總體擁有成本上已經比分布計算廉價，制造業、保險、航空、運輸及大型零售企業的大量事務處理對大型機的要求越來越高，這是大型機重新被人們認可的原因之一。

2 分布式與大型機

分布式計算在短期內給企業帶來了高效，但隨著時間的延續，企業系統擴大，數據分散存放在上百臺服務器上，數據的查詢成為問題，數據的互訪和對大量數據的開采利用變得困難起來，一個新的趨勢——再集中開始出現。如何將分布處理和集中計算結合起來，成為許多企業考慮的問題。大型機的系統完整性和大存儲量的優勢顯示出來，開始承擔用戶再集中需求的任務。

在總體擁有成本上，隨著時間的推移，小型機系統漸漸顯現出極高的使用成本。或許人們在使用一年UNIX后，會說UNIX性價比高，但隨著業務的增加，系統變得分散龐雜起來，維護費用增加。大型機挺過了關鍵的10年暗淡期，終于峰回路轉。因此，越來越多的企業開始關注IBM主機系統，將自己的系統移植到主機系統上來。

3 移植平臺間的差異

3.1 主機操作系統Z/OS與UNIX

目前IBM主機的主流操作系統Z/OS是使用最廣泛的基于64位Z體系結構大型機操作系統，它給在大型機上的應用程序員提供了穩定、安全和可持續運行的環境。

從本質上來說，UNIX是一個計算密集型的操作系統， CPU利用率較高，更適用于需要大量計算的環境；而主機操作系統Z/OS依賴于其強大的硬件后盾，除了強大的計算能力之外，更突出的是它強大的I/O處理能力，依托硬件上的FICON、ESCON等光纖通道，可同時應對大規模的并發用戶，因此它是一個I/O密集型的操作系統。兩種系統在很多內容上有著不同但又類似之處。

3.2 進程與地址空間

在UNIX下，一個程序的執行通常稱為一個進程，操作系統為每個進程分配一定的CPU、內存資源，使其運行，進程與進程之間可以通過信號量機制協同工作實現并發；而在Z/OS下沒有進程的概念，與之對應的是地址空間(Address Space)的概念，任何用戶的登錄、程序的執行、作業的提交，系統都會為其生成一個地址空間。地址空間之間在批處理方式下一般沒有通信，而通過聯機交易處理方式實現程序間通信。

在UNIX下通常會有守護進程(daemon)的概念，在主機環境中通常是一個長時間運行的作業的提交，可以從控制臺為這個守護作業提供輸入輸出對象處理。

3.3 文件的組織與編輯方式

從文件和數據格式上來說，UNIX系統是樹狀的目錄結構，數據的組織以文件夾與文件的方式保存、管理；而在主機上，數據都保存在數據集里，數據集分順序數據集、分區數據集與VSAM數據集，其組織方式沒有多層樹狀結構，分區數據集下可包含稱為member的順序數據集，順序數據集或VSAM數據集存儲實際的數據。

數據的格式在UNIX下是面向字節，而在Z/OS下是面向記錄的。數據的編輯在UNIX下通常是用VI；而在Z/OS下用的是ISPF編輯器。

3.4 交互系統的區別

UNIX下用戶登錄并在Shell環境下執行Shell會話，可以通過發送遠程登錄rlogin命令或者遠程登錄telnet命令連接系統，一個用戶可以同時打開多個用戶會話。在主機環境下，用戶通過TSO/E和它的菜單驅動接口ISPF登錄系統，一個用戶一次只能有一個活動的會話。

在UNIX系統中，用戶可以通過后綴Shell命令觀察處理進程和線程，可通過Kill命令結束一個任務。在主機環境中，用戶通過作業處理子系統提供的SDSF查看他們提交作業的執行情況，并可以終止作業任務的執行。

4 移植實例

下面以一個實際項目實例來闡述一套移植過程中要考慮的具體問題。項目以一個在UNIX平臺上實際應用的后臺結息系統為移植對象，考慮系統處理的各種運行機制和平臺差異，最終將整個系統移植到Z/OS下。

原系統的操作系統為AIX5.0，數據庫為INFORMIX 10X，開發語言為C語言，移植后的操作系統為Z/OS 1.5，數據庫為DB2版本8，開發語言為C語言。

4.1 針對多進程考慮

在原系統中有一個主控程序設計，主控程序是一個主調度程序，主要負責控制并發的進程數量及狀態，系統支持的并發數量由主控程序的參數設置，通常設置為30。主控程序控制的每一個并發進程代表一個部門結息流程。假設一次性有1000個部門運行結息過程，主控程序負責調度，它輪尋所有進程，當一個進程結束時啟動下一個進程，直到所有部門完成。

在Z/OS上沒有進程的概念，針對這種后臺批處理的結息方式，我們通過作業的方式實現，方案是為每個部門的結息準備一個JCL作業。所謂JCL(Job Control Language)是作業控制語言，通過它寫一段作業腳本提交給系統，可以讓系統執行相應的程序或進行相關的工作。為每個部門結息準備一個JCL作業，再準備一個主JCL作業，這個主JCL的任務就是去提交所有部門的JCL作業。

把結息過程定義為作業的好處是，在Z/OS里控制作業的并發數量以及作業調度的任務都可以由系統里的作業處理子系統JES2自動完成。在JES2里，有多個被稱為Initiator的地址空間，每個Initiator都相當于UNIX下的一個守護進程，專門處理提交的作業。

Z/OS中的Intiator是一個自動調度和處理提交的多個作業的地址空間，它主要負責處理如下任務：

(1) 確保同時運行的各項作業不會產生數據集使用上的沖突；

(2) 為作業分配必要的硬件設備，如磁帶等；

(3) 從庫中找到每個作業需要調用的可執行程序；

(4) 當一個作業運行完畢之后，在作業隊列中清除該作業并要求處理下一個作業。

每個Initiator在同一時刻可以處理一個作業，而多個Intiator可以并發處理多個作業，各個Initiator并發處理各個作業都是在保證不出現死鎖的前提下進行的。Initiator的數量可以在系統中設置，這樣一來就自動實現了并發數的控制。比如我希望將并發數控制為50，我們在系統中設置50個Initiator，然后提交主JCL作業，主JCL作業再一次性提交1000個部門的作業，這些作業由JES自動調度給50個Initiator，并實現負載的均衡。

4.2 Makefile的替代

在UNIX平臺上，通常會在準備好源代碼之后使用make工具進行編譯，在執行make之前，需要一個命名為Makefile的特殊文件來告訴make需要做什么，該怎么做。通常make工具主要被用來進行工程編譯和程序鏈接。

當使用make工具進行編譯時，以下幾種文件在執行make時將會被編譯或重新編譯：

(1) 所有的源文件沒有被編譯過，則對各個C源文件進行編譯并進行鏈接，生成最后的可執行程序；

(2) 每一個在上次執行make之后修改過的C源代碼文件在本次執行make時將會被重新編譯；

(3) 頭文件在上一次執行make之后被修改，則所有包含此頭文件的C源文件在本次執行make時將會被重新編譯。

Makefile文件是一個非常有效的文件，而在Z/OS平臺中，沒有類似的文件可用，通常的編譯都是通過使用一個JCL作業去調用系統相關的針對編程語言的編譯器去執行。

考慮到Makefile文件的對應參數、編譯流程、依賴關系與JCL作業有很多相似點，我們的方案是還是使用JCL作業去編譯程序，但將相關的源程序寫在同一個JCL作業中。在Z/OS環境下一個JCL作業可以有多個作業步，每個作業步可以指定進行不同的操作或調用不同的程序，一個作業最多可以有255個作業步。因此，我們可以將相關聯的源程序或者頭文件放到同一個作業的不同作業步中，用于編譯、鏈接，當有程序做了修改需要重新編譯鏈接時，還是提交同一個編譯作業就可完成。

4.3 信號量機制的考慮

在實際結息流程中，通常每個進程都需要從數據庫表里申請一個唯一的編號作為結息流程的流水號，最終保存到數據庫。流水號是一個遞增數列，無論進程執行是否成功，此流水號都必須唯一且不可讓其他進程使用，即使進程執行失敗，此流水號也必須作廢而不可給后續進程使用。

在UNIX平臺下，允許進程間通信，信號量機制就是用來解決進程同步與互斥問題的。通過P、V操作，保證并發進程互斥地訪問數據庫里的流水號資源。

而在Z/OS平臺下，特別針對后臺批處理方式下，用戶的程序之間，作業與作業之間一般不允許相互通信，資源的互斥使用是通過Initiator調度實現的。

考慮到進程使用的流水號最終需要保存到數據庫，而且流水號要求是遞增數列，我們針對DB2數據庫直接操作，DB2里面有個Sequence Object，它是一個遞增數列，其遞增幅度與初始值都可以在建立的時候設定。我們可以針對不同類型的流水號建立一個或多個Sequence Object，之后在任何需要用到流水號的地方，通過調用Sequence Object的next value取其當前值的下一個值，這樣不管多少進程并發，在同一時刻其next value永遠不可能重復，保證流水號的唯一性。

4.4 程序的準備

移植初期首先需要將程序與數據導入到Z/OS環境下。

程序的導入可以通過FTP上傳或3270終端直接上傳的方式。首先需要在主機上針對不同屬性的文件建立不同屬性的數據集。由于主機上不是樹狀文件系統結構，所以要建立幾個分區數據集，將相關文件保存成為相關數據集的member。如源文件可以建立一個數據集，名為userid.SRC，庫文件可以建立為userid.LIB等，數據集的大小根據實際情況指定，我們的項目考慮可擴展性，建立的每個分區數據集以M為分配單位，初次分配量為300，再次分配量為100，目錄空間大小為100。

將文件保存成文本格式上傳，如果上傳后都成了順序數據集，可以寫一個簡單的JCL，使用IEBGENER將其拷貝到分區數據集里。

4.5 數據的導入

對于數據庫的導出導入，我們的方案是先將數據庫創建腳本導入到數據集，使用主機上的SPUFI運行腳本創建好數據庫、表空間和相關表、索引等。將原Infomix數據庫的數據以文本方式導出，再導入到主機，最后導入到數據庫。

在DB2里，數據庫的導入有Import和Load兩種方法。Import以SQL為基礎，會寫日志，可以對視圖操作，表上定義的各種約束都將被檢查，可以在目標表不存在的情況下通過ixf格式的文件創建表，不能在Import過程中搜集統計信息。Import成功后表就可以使用。

Load操作屬于偏底層的操作，不寫日志，不可以對視圖操作，除了唯一性約束之外的各種約束都不在Load過程中被檢查，不可以在目標表不存在的情況下創建表，可以在Load過程中搜集統計信息。Load過程成功后也有可能將表空間置于pending等的特殊狀態，管理相對比較復雜。

總的來說，由于Load操作底層，因此速度很快，適合用于大量數據的導入；Import速度慢但管理簡單，適用于少量數據導入。

由于我們的數據量非常大，因此選擇使用Load導入數據。我們將導出的數據保存到主機的數據集里，通過寫一個Load作業，從相關數據集導入需要的數據。在Load過程中，可能會因為參數或數據出錯導致表空間置于reorganize pending狀態，或者將某個表的Index置于rebuild pending狀態，這時只需要將相應的表空間做一個REORG或者對相應的Index做一個rebuild就可以解決。

5 總結

在決定對一套應用軟件進行移植前，首先要明確移植的目的，選用適當的平臺和語言，然后充分地分析移植前后軟件運行環境的異同，決定要采取的技術和需要進行的結構調整，這樣就可以系統而有序地完成大中型軟件的移植工作，并可有效地提高軟件質量，延長軟件生命期。通過幾個月的實踐，我們的方案在可行性上得到了驗證，作為實際的應用，還有很多地方有待我們進一步探討。

Discussion on the Program Migration from UNIX to IBM Mainframe

WANG Zhen-yu1，TANG Feng1，LIU Qing1，LI Ji-yu2

(1.IBM zSeries System Education Center，South China University of Technology，Guangzhou，510006，China；

2.South China Agricultural University，Guangzhou，510006，China)

Abstract: This paper first introduces the main differences between UINX and IBM Mainframe platforms，and then discusses the main problems and the solutions on the program migration from UNIX to IBM Mainframe.

Key words: IBM Mainframe；migration；Job Control Language；Initiator