- COBOL 在 IBM 大型主機中仍然至關重要,廣泛應用於銀行、保險和政府部門,用於管理關鍵的全球交易。
- AI 可以加速 COBOL 程式碼的分析和轉換,但現代化涉及重新設計架構、資料和整合。
- IBM憑藉其基礎設施、工俱生態系統和企業級監管支持,保持戰略地位。
- 現代化決策應該基於投資報酬率、風險和領域知識,而不僅僅是人工智慧的技術前景。
La COBOL、IBM大型主機與新一代生成式人工智慧之間的關係 它正經歷著幾十年來最激烈的時刻之一。一種誕生於上世紀五十年代末、運行在許多人認為「來自另一個時代」的機器上的語言,突然因為一個非常具體的詞——現代化——而成為技術和股市辯論的焦點。
在過去的幾周里, 人類學會的公告 關於 Claude Code 及其在 COBOL 系統轉換和分析方面的功能 這在市場上引起了真正的震動,IBM的股價暴跌數百萬美元,人們也重新燃起了對這些遺留系統究竟還扮演著什麼角色的興趣。對於任何從事技術工作的人——從新創公司的創辦人到銀行或政府部門的IT經理——IBM大型主機上的COBOL系統現狀都是一個值得深入研究的案例… 電腦發展史、關鍵基礎設施和人工智慧顛覆性變革之間有何交集?.
從 CODASYL 到 COBOL 2023:一種「臨時」語言如何變得不可或缺
當 數據系統語言會議(CODASYL)很少有人想到,他們所推廣的語言在六十多年後仍然會被使用。這個由政府機構和大企業組成的團體,追求的是一個非常明確的目標: 創建一種通用程式語言,專注於業務資料管理,並可在不同的系統間移植。.
COBOL繼承了…的思想 Flowmatic,由先驅格蕾絲·霍珀開發的語言。這是美國國防部一項計畫的一部分。目標很明確:開發一種能夠在不同作業系統和硬體平台上運行的語言。這在今天聽起來或許微不足道,但在當時幾乎是科幻小說裡的劇情。在Linux、Windows、Unix,以及後來的z/OS等不同環境下的可移植性,成為其廣泛應用的基礎之一。
La 第一個正式的COBOL規範於1960年發布。 理論上,它最初被設計為一種臨時解決方案,以便在出現「更先進」的替代方案之前先實施。然而,國防部很快就意識到它在商業應用中的實用性,並採取了果斷措施: 要求電腦製造商提供對 COBOL 的支持 在他們的機器上。這項政治和技術舉措對於IBM和其他供應商將其整合到他們的大型主機平台中至關重要。
多年來,這種語言逐漸被廣泛接受,1968 年迎來了一個重要的里程碑: COBOL的官方標準化從那時起,出現了一系列修訂版和變體——COBOL-61、COBOL-68、COBOL-74、COBOL-85——這些版本改進了語法,提升了數據管理,並使語言適應了新的業務需求,但又沒有破壞與已部署在大型主機上的龐大程式碼庫的兼容性。
進入21世紀,標準已經存在。 COBOL 2002 試圖透過引入物件導向的功能和其他現代範式來實現重大飛躍。其理念是讓這些應用程式更好地融入當前的開發實踐中。然而,這個版本遇到了一個非常人為的問題: 缺乏實際支援和使用者需求低他們沒有清楚地看到採用新功能的益處與更新穩定係統的成本之間的權衡。

該標準的最新修訂版不斷推動語言朝著現代互通性方向發展。 COBOL 14 將舊的便攜式算術結果替換為基於 IEEE 754 的資料類型。符合廣泛認可的業界標準。而最新的標準是: 科博爾2023它著重於進一步改進 COBOL 與其他現有系統、語言和平台的互動方式,從而加強其在傳統架構和雲端架構共存的環境中的作用。
IBM 大型主機上的 COBOL:經濟核心的永恆語言
然而,無論他看起來多麼經驗豐富, COBOL 仍然是全球大部分金融和行政基礎設施的「隱形引擎」。根據各種估計,在美國,COBOL 處理了大約 95% 的 ATM 交易,據說生產環境中運行著數千億行 COBOL 程式碼,其中許多程式碼運行在 IBM 大型主機上。
這種組合的成功絕非偶然。 COBOL 是專門為商業資料處理而設計的。優先考慮指令的可讀性和處理大量事務的能力。這正是與以下方面完美契合的工作負載類型: IBM Z 大型主機旨在以極高的可靠性每秒處理數百萬次運算。
在以下領域 銀行、保險、航空公司或政府COBOL 與 IBM 大型主機的組合已經過數十年驗證,其可靠性毋庸置疑。據估計,IBM 大型主機大約可以處理… 全球87%的信用卡交易 並管理訂單 每日支付額達 8 兆美元我們談論的不是邊緣系統,而是數位經濟的真正支柱。
然而,問題不在於此。 COBOL技術上失敗了恰恰相反:它行之有效,而且效果非常好。主要問題在於世代差異。 幾十年來,開發和維護這些系統的大多數人已經退休或即將退休。而且,大學已經很久沒有提供這門語言的系統訓練了。正如Anthropic自己也承認的那樣, 每年能夠閱讀和理解這些程序的專業人員都在減少。 有償付能力。
技術依賴與人才供給之間的這種差距推高了維修成本。 經驗豐富的COBOL開發人員短缺 這使得任何演進或變革項目都變成了一項漫長而昂貴的工程,加劇了「技術債」的產生,而這不再只是一個工程問題,而是一個… 對金融和公共管理系統穩定性的策略風險.

IBM 非常清楚這種情況,而且遠非無所作為, 一直在擴展其 COBOL 編譯器和工具的生態系統如今,IBM COBOL 編譯器不僅與 z/OS 相容,而且還與… AIX 和 Linux這使得應用程式能夠在更多樣化的環境中運作和開發,而無需放棄原始系統。此外,該公司還推廣了… 培訓計劃和學習路徑 訓練時間可能超過 250 小時,內容包括 COBOL、Java、Python、CICS、IMS、DevOps、分析和 Web 開發等,正是為了順利完成世代交接。
從翻譯到轉型:為什麼 COBOL 現代化遠不止於切換到 Java
人種保護協會關於…的聲明 克勞德·科德及其「現代化」COBOL的能力 它揭示了一個反覆出現的誤解:認為僅僅將程式碼從一種語言翻譯成另一種語言就足以實現關鍵系統的現代化。這種過度簡化在新聞標題和論壇中反覆出現,是導致以下問題的因素之一: 市場對IBM的反應強烈.
Claude Code 等工具所提供的功能非常具體: 讀取海量 COBOL 程式碼庫,映射入口點、執行路徑、資料流和依賴關係,然後從那裡 產生文件並提出現代語言翻譯方案 例如 Java 或 Python。它對於打破許多組織遺留系統中存在的「黑盒子」大有裨益,但遠非完美的解決方案。
很多 運行 COBOL 的大型主機系統不僅僅是數百萬行舊程式碼。它們是數十年來不斷調整、修補、與其他系統整合、優化以及與硬體和業務流程緊密相關的改進的結果,而這些改進和優化又與監管法規的演變速度同步。 將指令從一種語言翻譯成另一種語言本身並不能解決架構的複雜性。.
首要挑戰是 這些應用程式通常是建構於單體架構之上。大多數 COBOL 程式的設計初衷是面向批次和集中式事務,與微服務、雲端原生架構或持續部署等概念相去甚遠。指望逐行自動翻譯就能產生「現代」系統,就等於忽略了這一點。 架構和資料模型保持不變。.
另一個嚴重的障礙是 隱藏的和未記錄的依賴項幾十年來,許多系統倉促地進行了調整,整合了來自其他領域的文件、佇列、作業和服務,而沒有提供全面的文件。 翻譯工具可以將 COBOL 指令轉換為 Java 指令。但不一定能發現哪些其他應用程式依賴該模組,或每個流程需要哪些服務等級協定。

除此之外, 許多業務邏輯都以非常具體的方式嵌入到程式碼中。稅收規則、特定銀行產品、監管例外…所有這些都存在於 COBOL 語句中,而這些語句有時只有最初編寫它們的人才能理解。在不失去任何邏輯細節的前提下進行現代化改造意味著 解釋並驗證每個模組的功能目前,這項工作仍需要專家進行人工監督。
最後,還有一個問題… 大型主機固有的效能與最佳化這些機器旨在以極低的延遲和極高的可靠性處理大量交易。在基於 x86 伺服器的基礎架構或雲端複製這種行為並非簡單地「遷移」程式碼;它通常需要… 重新設計整個系統,調整資料庫、訊息佇列和災難復原機制 和長等。
現代化的真正成本:投資報酬率、風險以及圍繞 IBM 的股市恐慌
市場對克勞德·科德事件的反應既引人注目又具有啟發意義。 IBM股價單日下跌約13%。這是自2000年以來最糟糕的單日表現,市值下跌了約 幾小時內損失30億至40億美元。2月份,股市下跌近27%,創下數十年來最糟糕的一個月紀錄。
這次崩盤不能僅僅被理解為技術運動。 投資人正在重新審視人工智慧將如何顛覆現有商業模式。尤其是那些依賴勞力密集服務的業務,例如遺留系統現代化諮詢。簡單來說,如果人工智慧能夠「快速且低成本」地翻譯 COBOL 程式碼,那麼 IBM 與大型主機和服務相關的相當一部分收入可能會面臨風險。
然而,當我們分析資料和業務結構時,情況就變得更加複雜。在最近一年, IBM公佈的總營收約67.500億美元。其中約45%來自軟體,其餘則分散在各處。 諮詢和基礎設施IBM Z 大型主機業務就屬於後者,它與 COBOL 應用密切相關。各種分析估計: IBM 約 20% 的收入依賴大型主機和與 COBOL 相關的環境,這可能對利潤產生更大的影響。.
在真相大白的時刻, 現代化決策不僅取決於技術能力,還取決於投資報酬率 (ROI)。遷移用 COBOL 編寫的關鍵系統涉及大量直接支出: 程式碼翻譯或重寫、廣泛測試、新技術團隊培訓、新基礎設施部署 以及可能的其他許可證。這還不包括… 機會成本和風險:新功能開發、服務中斷、目前運作正常但出現嚴重事故的系統中引入的漏洞以及過渡期間機構知識的喪失所造成的時間損失。
在監管嚴格的行業,例如 銀行、保險或公共管理許多組織得出這樣的結論: 繼續運作並優化由 IBM 大型主機支援的現有 COBOL 系統,可以帶來更可預測的投資報酬率。 比起徹底遷移,人工智慧工具或許能改變成本格局,但它們並不能取代仔細評估對日常營運影響的必要性。
同時,市場正經歷著一些人所說的… “SaaS末日”受擔憂情緒的影響,軟體即服務公司(包括Salesforce、SAP、微軟、Adobe、Intuit和Atlassian等)的股價出現了一波回檔。 人工智慧可能會蠶食那些看似不可撼動的商業模式。IBM 和 COBOL 的故事只是同一故事的另一個篇章:人們擔心人工智慧會自動化以前需要高利潤合約才能完成的任務。
克勞德·科德、IBM 和新型人工智慧輔助現代化生態系統
在這種緊張的氛圍下,理解這一點至關重要。 Claude Code 的具體功能是什麼?它在現代化工具領域中扮演著怎樣的角色?Anthropic公司提出的解決方案是一個能夠讀取完整COBOL專案的系統。 識別資料結構和檔案操作中的入口點、追蹤執行路徑並偵測隱式耦合 很多傳統的靜態分析工具都忽略了這一點。
一旦映射完成,克勞德·科德就可以 產生僅存在於程式本身「編碼」中的工作流程的詳細文檔除了提供風險評估,區分相對容易遷移的模組和其他更敏感的模組之外,其商業前景也十分誘人: 將以前需要數年才能完成的項目縮減到季度規模至少就分析、文件編寫和部分重構而言是如此。
值得注意的是,Anthropic 本身也承認這一點。 需要專家級的人工監督人工智慧可以自動完成許多繁瑣的工作,但在關鍵系統中——尤其是在金融系統中—— 如果沒有負責驗證每一項變更的人員,這項工作就無法進行。從這個意義上講,克勞德的角色將是一位非常能幹的助手,而不是現代化團隊的完全替代品。
Anthropic並非唯一涉足該領域的公司。遷移和現代化工具市場已經發展多年。 AWS Mainframe Modernization 它同時提供重構和平台遷移選項; 微軟 Azure 大型主機遷移 它包括用於分析和自動遷移的實用程式;以及諸如…的公司 微距對焦 它們使 COBOL 能夠在現代環境中運行而無需完全程式碼轉換,從而延長了遺留應用程式的使用壽命。
最大的差別是 語言模型(LLM) 克勞德使得對程式碼的理解更加深入、更具脈絡性。以前所未有的速度產生文件、自動化測試和設計建議。除了翻譯工具之外,其他工具也開始大量出現。 自動化文件產生、依賴關係分析、AI產生的迴歸測試和架構助手 這有助於決定遷移哪些內容、何時遷移以及如何遷移。
矛盾的是, IBM 對這一趨勢並不陌生。該公司幾年前就推出了利用人工智慧將 COBOL 程式碼重寫為 Java 程式碼的獨特方法,並推出了相關產品,例如… 適用於 Z 的 watsonx 代碼助手事實上,IBM執行長在最近的業績報告中強調,大型主機部門的強勁表現部分原因正是由於… 程式碼轉換工具 大型客戶中已經出現了對可控現代化改造的需求。
此外,IBM 和 Anthropic 當時也宣布了一項 策略聯盟旨在將 Claude 模型整合到 IBM 業務生態系統中這其中包括人工智慧輔助開發環境,根據早期用戶報告,其生產力提高了高達 45%。最初被視為協同效應的這種現象,現在至少從股市的角度來看,被重新解讀為在服務業務的某些細分領域可能出現的直接競爭。
總之,關鍵在於理解這一點。 沒有哪一種人工智慧能夠解決 COBOL 遷移的所有挑戰。大規模歷史資料遷移、中間件替換、整合重構、災難復原流程重建以及操作流程調整等專案仍然至關重要。憑藉其豐富的經驗、企業級支援服務以及在受監管行業的地位,IBM 在這些領域繼續發揮重要作用。
儘管遭受股市重創,IBM 為何仍是策略參與者
股價暴跌讓許多人不禁懷疑: IBM大型主機的時代即將結束。然而,如果我們拋開短期噪音,就會發現有幾個因素可以解釋為什麼這家藍色巨頭即使在人工智慧主導的世界中也能保持難以複製的地位。
首先,有 其大型主機基礎設施在實體經濟中的重要性相當一部分信用卡交易和日常大量支付都透過 IBM Z 平台進行,這絕非小事。處理此類業務的組織幾乎將 IBM Z 平台的可靠性視為最重要的因素。 可靠性、安全性、處理能力和支持,並嚴格遵守服務等級協議。僅僅承諾翻譯代碼是不夠的:還需要保證營運連續性、稽核和監管合規性。
其次, IBM 提供支援合約和商業保修 這些對銀行、保險公司和公共機構至關重要。如果一個每天經手數十億歐元資金的系統出現問題,就必須有人承擔責任並迅速採取行動。 硬體、軟體和專業服務的結合 IBM 提供的這套解決方案,對於其他新供應商來說很難匹敵,無論他們的 AI 工具多麼先進。
我們還必須考慮 數十年來,圍繞著大型機構建造的工俱生態系統不斷壯大。監控解決方案、安全、性能優化、變更管理、與其他環境的整合……所有這些都構成了一道“護城河”,而僅僅出現一個好的程式碼分析工具是無法將其摧毀的。
儘管缺乏 COBOL 人才是一個現實問題,但 IBM 已經投入資金。 使新一代更容易接觸大型主機環境的訓練計畫和工具將 COBOL 與 Java、Python、敏捷實踐、DevOps 和資料分析結合的學習路徑旨在防止遺留系統與技術堆疊的其他部分隔離。
最後,許多分析師指出了一個近乎諷刺的面向: 如果 COBOL 最終被大規模取代,IBM 可以透過協助執行和協調這項轉變來賺取更多利潤。無論是在他們自己的大型主機上、混合雲中,還是兩者的組合中。換句話說,業務可以從純粹的傳統系統維護轉向… 高附加價值現代化和遷移服務該公司在該領域已經擁有非常強大的影響力。
創辦人和技術領導者的智慧現代化:策略和經驗教訓
圍繞著 COBOL、IBM 和人工智慧的種種喧囂,為我們提供了幾個有益的教訓。 新創公司創辦人及產品或技術經理 即使生活中沒有大型主機,他們也面臨現代化的困境。
首先,建議… 明確區分漸進式改進與徹底變革像 Claude Code、watsonx Code Assistant 等 AI 工具可以為重構、文件編寫、依賴分析和測試生成等任務帶來巨大的價值。這與……並不相同。 徹底重寫平台並改變底層架構在著手進行重大計畫之前,關鍵在於明確目標是提高可維護性、降低基礎設施成本,還是實現全新的功能。
另一個關鍵點是 計算機會成本花費在遷移一個運作尚可接受的系統上的時間,就無法用於推出新產品、改善使用者體驗或開拓市場。諸如此類的問題 “這種遷移能否帶來額外收入?”、“節省的成本是否足以抵消風險?”或“是否存在可能導致企業倒閉的真正過時風險?” 在被時尚潮流沖昏頭之前,這些問題應該要擺到桌面上來討論。
此外,值得探索。 混合策略而非「要嘛全有或全無」的方法許多成功的組織都選擇了所謂的 絞殺圖案在這種模式下,功能會逐步被取代,而原有系統則繼續運作。另一些人則更傾向於將舊系統封裝在底層。 現代 API這樣可以確保 COBOL 核心程式碼在前端及相關服務更新的同時保持穩定。此外,通常的做法是… 選擇性現代化集中精力開發最有價值或風險最大的模組。
最後,還有一個因素常被低估: 遺留程式碼中蘊含的領域知識在許多情況下,COBOL 程式碼包含的業務規則、異常處理和案例研究已不再出現在任何正式文件中。保存和理解這些知識與實現這些知識的技術同等重要。人工智慧可以幫助提取和組織這些訊息,但至關重要的是要有能夠驗證結果並進行上下文解讀的人員。
最新進展表明 人工智慧將成為關鍵系統現代化進程中的強大助力。它能夠加速大型程式碼庫的分析、改進文件、產生測試套件,並為架構變更提供影響模型。然而,它距離獨立處理複雜流程還相差甚遠,例如: 遷移歷史資料、重新設計整合方案、滿足嚴格的監管要求,或重新定義整個業務運作。.
IBM、COBOL 和克勞德·科德的遭遇提醒我們: 技術穩定性始終是相對的。如果市場將精心策劃的公告解讀為解決了一個困擾數十年的問題,那麼該公告可能會在一天之內蒸發數百億美元的市值。同時,技術和營運方面的現實往往更加頑固:關鍵基礎設施的變革緩慢,而那些最了解其複雜性的人最能引領變革。
整件事清楚地表明了一個基本觀點: 傳統系統之所以能繼續存在,不是因為慣性或懶惰,而是因為它們已被證明是解決非常複雜問題的極其可靠的方法。爭論的焦點不應該是COBOL程式碼是否應該翻譯,而應該放在… 現代化何時才能帶來回報?哪些部分適合改造?以及如何將現有有效技術與人工智慧帶來的新功能結合?在這種平衡狀態下,IBM 大型主機、COBOL 和新的人工智慧工具將繼續共存多年。
對字節世界和一般技術充滿熱情的作家。我喜歡透過寫作分享我的知識,這就是我在這個部落格中要做的,向您展示有關小工具、軟體、硬體、技術趨勢等的所有最有趣的事情。我的目標是幫助您以簡單有趣的方式暢遊數位世界。
