大型主機上面跑的資訊系統缺陷
【去IOE】、【去IOM】！郵局和許多人壽保險公司、銀行、信用合作社、農會的核心ERP在mainframe和mini computer上面跑。
（為求簡潔，我隨波逐流，用時髦名詞【ERP】取代歷久彌新而且傳神的【 資訊系統 】）
我使用mini computer和mainframe的經驗
細數在mainframe和mini computer上面跑的ERP重大缺陷。
我第一個工作單位使用mini computer。現在坦承，我很少去碰那部含三個合計容量50MB的硬碟，每個硬碟體積和炒鍋一樣大，機身大約與10部堆疊在一起的PC和螢幕相當，外形像火車頭的機器。遠離它的原因有：
- 它只提供低生產力的萬惡COBOL。DBase家族和具有關聯式資料庫（Relational Data Base，RDB）CRUD SQL能力的RBase 5000（後來升級到RBase IV）的魅力導致我自始至終敬COBOL鬼神而遠之。
- 感覺它的運算速度不比桌上那部含Intel 80386 CPU的PC高。
- 我正在用Borland C寫一個RDB modeling工具，以深化自己對C的熟練度。那部mini computer沒有C。
我低空飛過微積分，僥倖按時取得大學文憑。約於1989年，和一位任職精算部對計算機求知慾極高的同事聊天時，他說自己在研究高等微積分，讓我接不下話。
我兒子去年（2021）七月考取臺灣大學【財務金融系】。該系必修微積分的消息是導致他放棄就讀的原因之一。
連接兩點成為一條直線之後，我得到結論：
每推出一款新保險商品之前，精算部門必先蒐集利率、壽命、匯率、停保率、公司經營績效……等歷史數據，加入現有法定數據、公司期望獲利率、競爭產品……等天量 （大）數據 ，應用微積分、統計學等深奧數學知識，模擬試算，權衡企業、保戶、法規三方利益，層層簽核之後才上市。
這位同事聲稱
我（硬碟容量20MB ？）的PC裡面有大量數據。
我們從未討論過這個構想： 下載mainframe的數據 ，充實他的PC裡面的資料庫。
擔任【Information System Analyst】，身為全公司唯一負責PC業務的我，當時之所以沒提出這個構想，不是沒想到這項MIS服務。相反地，有下列疑問，但是沒問他：
- 精算部的人員真有能力在沒有歷史數據的情況下精算出新商品？
- 精算部人員都用手工重複輸入mainframe印出來的報表天量資料到自己的PC？
- 軟體技術似乎領先精算部門同儕的這位同事到底使用哪種軟體去跑微積分、管理其資料庫甚至精算商品？當時能在PC上面跑，適合拿來做數學和統計運算，而且我用過的軟體只有Borland C、Borland Pascal、DBase家族、RBase 5000。
- 擁有精算師執照的部門主管是否知道這位同事有此特異功能？
我明知自己有義務提供這項MIS服務給同事，卻失職地保持沉默的原因有二：
- 我對mainframe所知有限。
- 我對mainframe少有興趣。
核心壽險ERP 100％在mainframe上面跑。我只負責MIS部門的周邊業務－－【user computing】，訓練各部門終端使用人（end users）在mainframe上面用COBOL的簡化語言QuikJob寫他們自己需要的報表，也就是35年後的今天一些專家們在推銷的【 Citizen Developers ，全民寫程式運動】。
End users興趣缺缺，我能貢獻的地方不多，於是在空檔期間用Borland C寫一個處理text file的百寶箱（類似Unix一定附贈的sort、cut、cat…），自己練功，順便看看能否被end users所用。
雖然全公司就我最熟PC，但是對mainframe的瞭解始終止於JCL的皮毛和Quikjob。對這些知識一概無知：
- 數量龐大，千絲萬縷的壽險COBOL資料檔案（files。不是RDB的tables）結構
- 讀取資料檔案以供user下載的合適程式語言或工具（QuikJob無此功能）
- 下載軟體或工具（類似ftp等Unix工具）
因為不知道如何讀取、下載mainframe資料，所以不敢向這位同事提及下載mainframe資料這個主意，以免自曝其短。
導致我對mainframe無知的原因有二：
- 負責mainframe的資深infrastructure同事以「權限控制很重要！」為由，不希望我這類MIS部門邊緣人撈過界，瞭解太多他一人獨攬的mainframe know-how。
- mainframe的特性給我很壞的印象，導致我完全沒興趣多瞭解那一團佔據整個機房，數分鐘不回應【Submit】鍵的恐龍巨獸。
「不求上進」不是我的個性，而是有我的「正當」理由：
壹、mainframe綁架企業和電腦人員
主機板、CPU、記憶體、體積接近蒸氣火車頭尺寸的機殼、每個容量（記憶中）少於200 MB的硬碟、【周邊處理卡】、磁帶機、終端機、【周邊處理卡】與終端機之間的通訊軟體＆網路卡＆網路線＆hub、終端機模擬程式……等全部零件，其供應商「僅此一家，別無分號」。交易價格，買方幾無討價還價的空間。
如果一名盡忠職守的MIS infrastructure主管心生
當盡心盡力為雇主節省MIS費用，改買廉價高性能代用品
邪念時，獨家供應商自己和經銷商的業務員就客氣地善意提醒他：
如果出現任何問題，我方概不負責收拾。
則這位主管將立即懸崖勒馬，改邪歸正，從此一心一意以個人錢途為重，廣結善緣，把路走寬走廣。
應該不至於和我一樣幼稚到低估跨國巨型mainframe供應商的影響力，重複追問經銷商的業務員：
如果我捨昂貴的專屬終端機，改買end users可以跑Lotus-123（M$ Excel的前身）和dBase的PC，去充當mainframe的終端機，結果會怎樣？
我當時就體會兩個道理：
- 唯有財力雄厚、體質優良的組織能經得起MIS硬體、軟體、人力資源三者合計費用的考驗。
- 電腦人員一旦投入全部生命在專屬（proprietary）mainframe技術，等於自己的未來必須與這專屬商品共存亡，落入近年西岸順口溜描述的陷阱：
錯把平臺當本事。離開平臺，你甚麼都不是。
貳、mainframe帶給MIS人員低生產力
任該職之前已苦讀過《Operating System Design: The Xinu Approach》、《Advanced Programming in the UNIX Environment》，知道Unix shell的威力：
數百列甚至數千列不具loop能力的JCL才能完成的工作，一列while … do … done或awk等指令就解決掉。
目睹機房負責跑batch job的operator同事們，每天抱著30公分高，上面印著JCL的A1連續報表紙，匆忙進出機房，自卑感油然而生：
何方神人？竟有此高智慧撰寫、維護此浩瀚天書！
operator們輪值大夜班，能精準抽換成千上萬列天書裡面1～2列JCL之後，送進巨型怪獸嘴巴。從未因昏沉而失誤，鑄成大錯，造成保戶和公司嚴重損失，自己悔恨一生。彼智力與體力豈我輩凡夫可及於萬一！
比較mainframe與Unix二者之後，徹底體驗【 MIS人員生產力】、【 MIS人力成本】、【 硬體費用 】對企業、政府部門的真實意義。
參、預測：PC將會大行其道。
我入職之前，在香港技術人員的指導下，那套壽險軟體已經大致上線。mini computer繼續跑COBOL會計軟體，供會計部人員使用。（菜鳥我沒追問資深同事後面這句話的含意。難道在mainframe上面跑的新ERP壽險模組與會計模組無縫整合？沒有會計模組？有會計模組，但mini computer上面的會計資料尚未全部轉去mainframe？）
壽險應用程式全部在mainframe上面跑，上層是COBOL，核心是assembly。
用assembly寫商業應用軟體？
是的，一名負責 維護mainframe壽險應用程式 的女同事確實這樣回答我的好奇。
是誰建議的？
誰決定要購買用assembly做底層的壽險軟體？
建議的基礎是甚麼？
assembly的執行速度最快，為甚麼公司全部使用人不耐煩地猛按【Submit】鍵，mainframe一概數分鐘不回應？
雖然我入職前寫過Z80、6502、8088 CPU的assembly，用C呼叫 M$ DOS ，在螢幕上面斜對角畫X大直線，對assembly並非完全恐懼，但是愛面子的我不敢問任何人前述敏感問題，深怕被反譏：
你撈過界了！
或
玩PC家家酒的人懂甚麼大系統？
當時很懷疑決策品質和外國專家的專業，但是因為沒膽問、不知道該問誰、非我層級和職務應該問，所以那些疑問始終未獲澄清，也輪不到只懂PC的新人我去打聽全部比我資深的上司和香港顧問。
壽險資料檔案的結構之複雜，難以文字精準形容，只能按回憶簡化描述如下：
- 欄位f1：保單狀態（status code）。A：有效；B：永久停保；C：暫時凍結。
- 欄位f2：繳費狀態（premium code）。01：最近一期繳費單據ID：02：停保：03：續保過程代碼。
- 欄位f3：繳費代碼（trailer code）。X：讀取f3為99，f4欄位的金額。
- 欄位f4與欄位f5同屬一筆記錄。
- 欄位f6：（sequence code）。金額有多筆。若欲讀取最近繳費金額，應先讀取欄位f6。欄位f5等於該數字的同一筆記錄的f4即為最近繳費金額。
複雜的壽險COBOL檔案結構突顯下列缺失：
- 執行大量IF … THEN … ELSE..程式碼，徒耗mainframe CPU資源，並無直接生產力。
- 維護錯綜複雜的大量COBOL程式碼，導致MIS程式設計人員的生產力低、成就感低、士氣低、IT服務品質低，不受別部門資訊使用同事的感謝和尊重。
任該職前，我已經熟稔RDB設計專業。感謝恩師黎主任的引薦，讓我有機會使用RBase 5000承包並完成一套ERP，既充實荷包又實踐RDB設計與SQL理論。
透過實戰經驗，比較mainframe的COBOL與PC的SQL二者之後，當時即大徹大悟 mainframe相關的【軟體費用】、【硬體費用】、【人力成本】帶給企業和郵局的財務壓力 。
mainframe和COBOL的優點也很明顯： 因為IT人員生產力低，所以IT部門編制龐大 或外包核心甚至全部ERP業務，企業和郵局【提供社會龐大就業機會】。
數十位會計部門同事整天面對mainframe終端機和PC裡面的Lotus-123埋頭苦幹。有同事反應：
mainframe無法提供我需要的數據。
於是我用Foxbase幫她寫了對帳程式。嚴重缺陷：她仍必須用手工重複輸入mainframe裡面有，但是我沒辦法協助他下載的數據，仍治標不治本。
多次看到團體保險部一絕世美女翻閱單據和報表，使用計算器核算數字。顯然mainframe仍無法徹底淘汰計算器。
- mainframe使用人痛苦：要甚麼，沒甚麼，「求人不如求己」，只好咬牙手工DIY。
- mainframe的優點也很明顯：會計部門、團體保險部門的手工作業量大，所以需要大量人力資源，企業【提供社會龐大就業機會】。
我的經驗指出： 無論哪種行業、何種規模，【ERP軟體有重大缺陷】是全部資訊相關問題的唯一原因。
因為ERP劣質，所以「溝通很重要」。事實：因為MIS整體績效長期不見改善，所以MIS人員不受end users同事的敬重：
- 有求無應：別部門的end users要甚麼，沒甚麼。
- 資訊軟體給end users不完整、散亂、錯誤資訊。
- 資訊提供不即時：end users需要現在取得資訊，資訊軟體一小時之後才能提供，甚至永遠不提供。
劣質ERP造成「人際關係很重要」：
- 人際關係良好的MIS人員，end users礙於良好的私人關係，所以避免傷感情去舉報MIS人員「服務品質低劣」。
- 人際關係欠佳者，人人避之唯恐不及，時而被end users當眾指控。
- 為人強勢者，每以「資訊專業不是你們外行人能說三道四！」高姿態壓制end users，後者因自己的「無知」與前者的職位與「專業、權威」而敢怒不敢言，甚至佩服。
劣質ERP形成不健康的MIS部門生態：
- 劣質ERP孕育兩類MIS主管：（A）知道問題源自劣質資訊軟體，所以善待基層程式設計師，為人心所向，眾望所歸。（B）不知道問題源自劣質資訊軟體，自始至終避談【ERP】的缺陷與解法細節。為展現自己的「領導統御和管理能力」，於是緊迫釘人，【微細管理，micro-manage】基層程式設計師：要求後者寫工作報告，每月、每週、甚至每日開會，一對一單挑「輔導」，集中火力檢討【人】。
- 因為劣質ERP錯綜複雜、混亂、龐大、含無數隱藏性錯誤，改這裡、錯那裡。所以基層程式設計師每天猶如消防隊員，精神經年累月處於緊急滅火緊繃狀態：接不完資訊使用人送來的【資訊服務申請單】和電話，疲於奔命，焦頭爛額。自顧不暇，遑論同事之間互助！
- MIS部門人員，或「良禽擇木而棲」；或遵循「活下來的人贏」哲學而忍辱負重留下來；或埋首繼續練功，充實履歷表內容。
劣質ERP導致組織內部人員加入辦公室政治內戰。
結論
在mainframe和mini computer上面跑的資訊軟體，因為老舊、落後的先天架構不良，所以，無論如何優化mainframe和mini computer上面跑的ERP，都止於皮毛層次， 不可能徹頭徹尾改良其品質 。
用科學精神細究
- MIS人員生產力
- MIS人力成本
- 硬體費用
- 資訊服務速度與品質
- 組織內部人心向背
- 資訊使用人的感受
…等因素之後，人人都能得出結論：
- 無論組織歸屬哪種行業、何種規模，【ERP軟體有重大缺陷】是全部資訊相關問題的唯一原因。
- 放棄COBOL應用軟體，是大型組織的資訊系統脫胎換骨的前提；移植COBOL檔案至PostgreSQL資料庫，是IT決策者的睿智決定。
- 淘汰專屬（proprietary）mainframe和mini主機，擁抱量產、平價的AMD 64-bits主機，是上策。
去IOE、【去IOM】
西岸壽險公司、政府部門、大企業已經在【去IOE】運動中衝刺多年。東岸政府部門、公營事業、郵局、銀行、保險公司…各大組織的IT決策者宜儘早覺醒、行動，【去IOMicrosoft】，以免落後太多，積重難返！
淘汰食量巨大的mainframe巨獸和「 百足之蟲，死而不僵 」的COBOL，擁抱平價、普及的AMD 64-bits硬體是明智之舉，但是正途只走一半。
前面還有 一大片雷區等著你！除非 IT決策者夠機警，否則企業雖逃出豺狼的爪牙，恐怕又 進入虎豹的大口 。
一家巨型壽險公司於30年後壯士斷腕，雖然脫離了mainframe對現金的搜刮、COBOL對人力資源的消耗，然而卻出現 這篇文章 描述的悲劇 ：引進劣質ERP軟體之後，
- 上下左右、跨部門、跨國、跨語言溝通技巧
- 聲色俱全的Power Point
- 管理（別人）能力
- 協調功夫
- 無極EQ心法
- end user教育訓練補習班
- 專案規劃能力
- 專案控管能力
- 風險評估與控制能力
- 品質監督機制
- 人力資源規劃能力
- 撲克牌＋水晶球面相術
- 茅山他心通祕笈
- 5000頁頂級agile/water-fall ERP開發、測試、轉資料、big bang/phased roll-out上線Product Life Management（PLM） 大全
- 方塊架構示意圖、甘特圖、魚骨圖、圓餅圖、長條圖、折線圖、流程圖
- CMMI＋ISO 9999999國際標準機制
- 進階時間管理大法
…全部頂尖大學資訊管理系博士班教的高等理論，全部失效。整個 壽險資料庫又被 更昂貴、 複雜、 低生產力的新ERP軟體 打亂， 永無徹底修復之日。 低性能的新ERP軟體迫使公司購買 價格與mainframe相差無幾的新主機去彌補 笨重、 反應遲鈍 的新ERP軟體缺陷。
給大型組織的IT決策者，董事長、總經理、CIO們的建議
- 放棄「外來和尚會唸經」、【自己的IT人員不如外來專家】、【我有產業，吾寧贈之于朋友，而必不使奴隸分其潤也！】的觀念。
- 先深入基層，傾聽ERP使用人的心聲與期望，虛心自問：「我的決策有幾成把握能令資訊使用人滿意？」，後下決定。
- 先徵詢IT部門【第一線的基層人員】，而不僅是一、二名MIS主管：「你們有無自信使用這套ERP框架，在指定【時間和費用】的預算內完成ERP專案任務？」，後下決定。
- 嚴防【位置決定腦袋】、【外行領導內行】、【少數菁英包辦錯誤IT決策，導致組織重大損失】等現象發生。
本文揭櫫mainframe、mini computer、上面跑的資訊系統缺陷，以及其改善【決策】和【理論】。下文將聚焦【技術】和【實務】。
— — — — — — — — — — — — — — — — — — — -
（續西岸【去IOE】運動圖集）
mainframe的長處
我就使用mainframe的皮毛經驗，推論而得這段心得。未經深入研究，僅供參考。
平心而論，mainframe並不是一無是處。它仍有一項長處：高整體效能（performance、throughput）。其高整體效能，不完全因為它的CPU比今天的AMD 64-bits強悍，而是因為它的CPU只負責少量工作。
- 我們用telnet遙控Unix的時候，在鍵盤按下每一個鍵，Unix都必須逐一處理之後回應。
- 讀寫硬碟機和磁帶機的細節，Unix事必躬親。
- 點矩陣印表機打印每一個字之前，Unix必須先計算格式之後，詳細通知印表機：按這個位置和外觀列印。
換言之，因為Unix負責大量的I/O工作，耗費大量CPU資源，所以用telnet去遙控Unix的ERP跑不快，不適合大型組織採用，例如：4GL ERP。
mainframe大不相同。它的CPU只負責極少I/O工作，或甚至完全不負責。【周邊處理卡】接走大部分甚至全部I/O工作：
主機板被無數【周邊處理卡】團團包圍：
以終端機【周邊處理卡】為例：它連接全部終端機。終端機使用人按下鍵盤之後，除了【Submit】和F1～F10等特殊鍵，其餘信號多被終端機的【終端機模擬程式】攔截、接管，未被傳送去【周邊處理卡】。換言之，mainframe的使用人數即使上萬，其【周邊處理卡】和網路設備其實很悠閒，抵達主機板和CPU的信號更是鳳毛麟角。
同理，硬碟機【周邊處理卡】、磁帶機【周邊處理卡】、印表機【周邊處理卡】也類似：它們分攤掉幾乎全部I/O工作，CPU和記憶體的主要負擔剩下ERP應用程式和少量作業系統（operating system）工作。
我們可以這樣想像：一部mainframe等於一片尺寸巨大的主機板。主機板上面除了有CPU和RAM晶片，更插上無數【周邊處理卡】。每一片【周邊處理卡】的處理速度猶如一片AMD 64 PC主機板。
一團多部AMD 64 PC組成的併裝機，馬力當然強大。大量的【周邊處理卡】和無數終端機接管週邊業務，mainframe的整體效能（overall performance、throughput）當然驚人。
Originally published at https://www.linkedin.com.
