100 大型主機應用系統移轉之淺見

  • 張貼日期:2010/4/28
  • 更新日期:2010/6/25
100 大型主機應用系統移轉之淺見
100 大型主機應用系統移轉之淺見

大型主機應用系統移轉之淺見

一、前言

過去的十幾年間,有些評論家一直預言大型主機會從電腦應用的主流市場退位,運作於其上之應用系統終將紛紛轉移至 Window 或 Linux/Unix 平台;亦即主機downsizing。

雖然不能否認大型主機引以為傲的穩定、安全與效能等優點,但無論是主機或非主機用戶對其龐大之硬體費用與其上的軟體使用費亦頗為詬病。這十幾年間非大型主機業者在提升性能、等級與產能上不遺餘力,期與大型主機並駕其驅;甚至在整合電腦新技術的彈性與成本上不但取得競爭優勢並且將其遠拋於後。

國外許多文獻指出 Mainframe-to-Server 是『可行的』:移轉成功的案例與開發移植工具之廠商報告不約而同的提及,由 COBOL, FORTRAN, 與 DB-2 組成的應用系統在新平台上重啟爐灶無須迂迴為之;但以 DL/1, CICS 與 IBM assembler code 所組成的應用系統,在移轉時就得花些額外的工夫。即使如此,後者的應用系統移植仍是可期的。某些研究或學術機構中,批次與中、大量資料庫資料處理模式所衍生的 CPU-intensive 問題在移植後的投資報酬方面最引人入勝。

近幾年來主機上新增的特質的確讓其彈性雖較以往增色不少,但仍不甚滿意。逐年累增的使用費在衡量產值時屢居下風,但這麼多年以來,為何仍有主機使用者對平台移轉敬謝不敏?『穩定度』、『安全性』、『移轉風險』、『移轉時間』、『移轉費用』在在都令反對者裹足不前。

本中心IBM大型主機即將於民國99年起逐步除役,個人雖有幸恭逢其盛,但移植至其他平台的不安與恐懼實與日俱增。移轉應用系統的工作何其千頭萬緒,實乃非比尋常,譬如:如何做?從何著手?安全性?正確性?相信有此疑問者應不在少數。

二、移轉方法論

Macrosoft 微軟公司(http://www.macrosofinc.com/)在 2008 年發表一篇 Mainframe-to-Server Conversion (主機處理型式轉換成伺服器平台型式)的報告,其中說明能夠順暢的協助230個 IBM 大型主機應用系統轉換至其它平台的原因,除了嫻熟多種平台的技術與經驗外,其成功的關鍵在於『移轉五步驟方法論』和其搭配的工具。

(一)主機應用系統解析:

(1) 處理程序解析(JCL analysis:JCL-to-Shell)

- 目地平台無原來之JCL(Job Control Language)須改寫shell script

(2) 程式重新編譯或撰寫(Program recompiling and code conversion)

- 有原始碼(source code)的程式(COBOL, FORTRAN)須重新編譯,有些指令(statement)不支援須改寫,引用的副程式及函數亦須調整。

- 只有目地碼(object code)的程式須重新撰寫。

(3) 原 IBM 服務程式移植性考慮或以新軟體取代 (IBM utility conversion and rebuilding)

(4) 其他廠商之軟體工具、程式移植性考慮或以新軟體取代 (Third party tool migration)

(二)目地平台之選擇與安裝:內容過於專業且為系統工程人員的範疇,個人不作詳述。

(三)目地平台之設置:

(1)制定檔案系統架構(set up the standardized file system structure)

- 各專案目錄架構與命名規範

- 檔案之權限控管

(2)建立工作監控追縱系統(set up the process monitoring, tracking system)

(3)建立警示系統(set up the error tracking and alerting system)

(四)示範應用系統之移轉、單元/系統測試:

(1)改寫JCL/PROCs

(2)適度的改寫程式並重新編譯

(3)IBM 服務程式之替代作法安排與驗證

(4)其他廠商之軟體工具之替代作法

(五)示範應用系統之系統執行、監控、效能調整與障礙排除:

約須三至六個月的時程。

三、實務探討

前述之移轉步驟方法論對茫然不知如何著手的人而言,的確有一藍圖可供參考。但因本中心主機用戶多為業務專業而非資訊專業人員,在實務上仍有一些值得探討之處。

(一)教育訓練(Training/Documentation)

對轉換的恐懼、不安與抗拒起源於疏離感,新平台對大多數的使用者而言極為陌生,許多名詞甚至未曾聽聞;觀念的建立也非一朝一夕即可達成。完整的教育訓練可降低疑慮並增加新環境的熟悉度,勢必得在應用系統移轉前展開。

(二)計劃表(Migration planning and scheduling)

擬計劃表不但可釐清模糊疑問之處,詳盡條列工作細目的手法能讓計劃內容更趨周延,執行上不但有所依循並可供檢驗及進度追蹤。

(三)主機應用系統解析注意項目

(1)資料(File/Data)

主機上累積了多年的資料檔必須在新執行環境建立後先搬移才能進行後續的工作,面對成千上萬的檔案就像搬家時何者該丟何者該留的情況,在檢視這些龐大的資料檔時難免有掛萬漏一、滄海遺珠的窘況,此時若能建立資料流(Data Flow)或許能有些助益。

檔案結構(file type)有些能跨平台有些須重新建立(IBM VSAM 檔因非一般平面檔 flatfile 須先轉出再重建為 ISAM 檔);資料型別(data type:Character│Edited numeric│Date/Time) 也非全然透通:不論中文或非中文之文字資料都有編碼的議題,使用者造字更不能輕忽:即使數值資料在移植時也有失真的風險;日期或時間資料有些也得視情況轉換;檔案存放之磁性媒體(tape/disk)在新平台上無法使用,因此在磁帶上的每一個檔案均須下載至磁碟上才能進行搬移。

非中文的 SAS 資料檔 (SAS DATA Library)可利用程序先轉出再轉入 (CPORT Procedure/CIMPORT Procedure);但含中文的 SAS 資料檔得在無使用者造字之一、二字面前提下才支援 IBM NHC 碼與 BIG-5 碼的交換(CPORT Produre中增加 CINTYPE=IBM OUTTYPE=PCMS參數);至於使用者自定格式檔(SAS FORMATLib) 建議找到原始碼再重建。

伴隨在執行程序中的控制資料(control data)及參考資料(reference table),及 COBOL 程式引用的抄錄表格(copybook)等雖非檔案也須移出。

上述各種資料方面的問題頗令資料擁有者傷神:在處理日常的工作外不但須增加許多一次性程式及程序,對檔案移轉後正確性的驗證問題截至目前又無良策。

(2)程式(program)

目地碼程式館(load module)中每一個目地碼(object code)的程式都不能以二元型態移植至新平台;SAS 用戶所建立的 MACROLib 是一種特別的目地碼程式館,因此找尋其原始碼就變成刻不容緩的工作。

原始碼(source code)程式除 SAS 程式在 I/O 部分僅須微幅改寫外,其餘 COBOL 與 FORTRAN 程式都得在新平台上重新編譯。程式在何處?每一個使用中的目地碼程式是否都有原始碼?那一個程式版本是可信賴的?程式的作者還在組織中可能比較容易解決;若為前輩心血之作或因缺乏文件,或因年代久遠等因素,在轉換執環境後就遺失了許多珍貴的企業解決手法(bussiness logic)。

雖然有些文章指出 99% 的 COBOL 程式是可以沿用的,但對 FORTRAN程式較無文件可供解惑。FORTRAN 組成的應用系統有一個潛在的問題必須面對:程式中引用的副程式及函數均須改寫或驗證!程式語言廠商所提供之副程式或函數與執行平台的相依性可能導致結果出人意表(如 CHAR()與 ICHAR()函數);組織內前輩或他人建立的副程式或函數如隱形人般不易查覺,即便找到或因原始碼遺失,或因能無力改寫,重新開發又是多麼緩不濟急且困難而艱鉅的工作。

程式為處理中文資料使用的變項內容值或條件判斷值,可能非經外部檔傳遞而以hexcode方式埋藏其中,此種狀況不論是以何種語言呈現,均須逐項改寫。

(3)程序

以批次模式處理資料的使用者經由scripting language及執行狀態碼 (return code) 安排控制一個或多個程式完成某特定工作;IBM's JCL (Job Control Language)就扮演這種角色。程序是 JCL 的集合,用來完成特定工作。多數人對應用系統中的程式與資料檔都極為重視,卻忘掉了將程式與資料檔串連起來的『程序』!程序中除了使用者的程式,可能還有一些作業系統提供的服務程式(ultilty)或其他廠商的軟體工具。檢視程序可得到資料(Data Flow)的雛形及應用系統的架構,因此在應用系統解析時也不可忽略此區塊。

(四)現有工具與解決方案的替代考量

(1)文書編輯工具;檔案輔助工具

一般熟知的文書編輯工具對程式編修已然足夠,但對以檔案為主的資料處理用戶而言,檔案編輯工具不能等閒視之!對動輒百萬筆的資料檔使用者所偏愛的的 ISPF tool與 FileAid,期待能有匹配的工具可用。

(2)排序工具

排序是資料處理過程中最常使用的方法,舊版的排序 (ICEMAN 程式或 DFSORT 服務程序)寫法須先明瞭後才能順利轉換。

(3)程式除錯輔助工具

原在主機上的 AbendAid 對 COBOL 程式除錯時效果顯著,若無此軟體協助對程式作者的產能勢必產生挑戰。

(4)程式效益性分析輔助工具

對有時辰壓力的專案,最佳的程式執行效益是每一個程式作者在開發之初就應有的認知。資深或老練的人員自有其高效益程式撰寫的經驗法則,但對資淺或業務專業人員要求寫程式同時且顧及此面相可能強人所難,因此在主機環境中的 STROBE 就擔負起程式效益性解析的角色。

(5)大量報表列印解決方案

報表依時程可分為事前、事中與事後;依格式可分為有套版 (OVERLAY)與無套版;依功能有調查時之調查名冊、街道範圍表單、扣繳憑單、填報表單、調查回表後之資料處理程式及程序內容、資料處理檢誤清單、中間表、提要表、結案後之印書表、電子書籍表、網頁表等等。

結案後之各種報表目前已委付廠商專案開發,其他表件仍須在新環境實現。理論上標準程序(OGL 語言製作套版、PPFA 編排頁資料、JES2合併套版及頁資料、然後送至3835印表出列印)可跨平台在 UNIX 端建構構;但以呼計前人所預先開發之3835副程視的方式產製報表者,須再研議其移植性。

(6)IBM 服務程式(utility)的替代做法

- 備份資料檔工具 ( ADRDSSU)

- 複製資料檔工具 (IEBGENER, ICEGENER)

- VSAM 檔案轉入轉出工具 (IDCAMS)

(五)技術支援(Migration Consultancy)

熟悉主機作業環境與規則的用戶,因其系統封閉性鮮少與其他平台用戶交流,對日新月異的電腦新技術難免有落伍脫節之嫌;能清楚明瞭新平台的架構與作法在短期內也不易實現。對新舊平台不但須瞭若指掌且有豐富經驗的人自然就成為最佳團隊成員,良好的技術支援團隊就像導師般可適時的提出建言並有效的協助障礙排除。

四、結語

若干採行原執行平台軟硬體提升而非移轉至其他環境的大型主機用戶指出:雖然對放棄多年慣用的平台所產生的『移轉風險』頗為重視,但『移轉時間』、『移轉費用』才是他們評估後視為移植成敗與否的最大的因素。大多數使用者必也承認時間是最難掌控的,到底須要多少時間才能將原有的應用系統安穩的在新平台上建立起來?產能是否會降低?組織內最重要的資產是否會因此而毀損?總而言之,應用系統在移植的過程中不容衍生系統品質與正確方面的問題。

(主計故事099,取材:行政院主計處電子處理資料中心內部文案及網路文獻,任晶蓉整理,2009.01)