使用 Hopper 使大型主機維運現代化：z/OS 的代理式介面

大型主機仍然是全球金融與保險業的支柱，然而用於管理它們的維運工具往往已有數十年的歷史。對於許多開發者而言，與 z/OS 環境互動需要導航複雜的文字介面，並必須掌握與 Job Control Language (JCL) 及 System Display and Search Facility (SDSF) 相關的高難度學習曲線。

由 Hypercubic 開發的 Hopper，旨在透過引入首個大型主機代理式開發環境來彌補這一差距。透過在傳統大型主機維運之上疊加 AI 代理，Hopper 將體驗從手動終端機導航轉變為提示詞驅動的工作流，從而潛在加速了舊有系統的現代化進程。

大型主機開發中的代理式轉變

傳統上，大型主機開發涉及高度的手動操作。開發者必須編寫 JCL 來提交作業，監控 Spool 以查看回傳碼，並手動篩選系統日誌以尋找故障原因。Hopper 將這些重複性任務替換為能夠在 z/OS 內執行複雜操作的 AI 代理。

精簡 Build-Test-Ship 週期

大型主機維運中最顯著的痛點之一是編譯與部署程式碼的過程。Hopper 允許開發者「在一個提示詞中完成編譯、測試與交付」。代理會處理以下繁重工作：

• 驅動 JCL：自動生成並提交必要的 Job Control Language 腳本。
• 解析回傳碼：監控 JES (Job Entry Subsystem) 回傳碼以確保流程成功。
• 執行 NEWCOPY：執行 CICS (Customer Information Control System) 的部署，使變更生效。

至關重要的是，該系統採用「人機協作 (human-in-the-loop)」的方法，在每次變更前都會暫停以等待使用者核准，確保 AI 不會對生產環境進行未經授權或具破壞性的修改。

智慧除錯與分流

大型主機上的除錯以困難著稱，通常需要花費數小時搜尋 SDSF 日誌。Hopper 引入了 @-tag 系統以進行快速診斷。透過標記特定作業（例如 @JOB01945），代理可以自動解碼 JESMSGLG、JESYSMSG 和 SYSUDUMP 檔案。接著，它會呈現確切的 abend 代碼、失敗的步驟以及錯誤的原始碼行數，將分流時間從數小時縮短至數秒。

在創新與風險之間取得平衡

雖然 AI 驅動的大型主機維運前景誘人，但將 LLM 引入關鍵基礎設施在業界引發了合理的疑慮。

安全性與智慧財產權

對於依賴大型主機的機構而言，數據隱私是首要考量。如社群討論所述，許多高品質的 COBOL 程式碼庫是專有的。Hypercubic 透過提供企業級方案來解決此問題，該方案明確保證模型不會在使用者數據上進行訓練，並提供 on-prem/VPC 部署選項，以確保敏感的 IP 留在機構的防火牆內。

「狐狸進入雞舍」的困境

一些批評者認為，將 LLM 引入穩定且舊有的系統風險過高。正如一位使用者所指出的：

"如果沒壞，就別去修它。所以讓一個 LLM 在大型主機上橫行，就像是讓狐狸進入雞舍。"

然而，其他人則認為，即使 AI 不會立即被信任用於編寫生產等級的金融服務程式碼，它對於為舊有的 COBOL 生成全面的測試套件也極具價值——由於缺乏文件，這在舊有系統中通常是被忽視的任務。

靈活性與舊有系統支援

Hopper 並非尋求完全取代傳統的大型主機體驗。它提供了一個完整的 TN3270 終端機模擬器，並支援 PF、PA 和 attention keys，允許開發者在代理式介面與手動模式之間隨時切換。這確保了經驗豐富的大型主機維運人員可以維持現有的工作流，並能讓新開發者更快地上手。

結論

Hopper 代表了一種轉向，旨在讓大型主機對習慣於現代 IDE 和 AI 輔助編碼的一代開發者而言變得更加容易上手。透過自動化 JCL 和 SDSF 分流的繁瑣部分，Hypercubic 正的是嘗試在不需完全重寫舊有程式碼本身的情況下，使大型主機的維運層現代化。