Hầu Hết Công Cụ Hiện Đại Hóa COBOL Chỉ Dừng Lại Ở Chương Trình. Nơi Các Dự Án Di Trú Thực Sự Đổ Vỡ Là Job Batch Gọi Nó.

Dự Án Di Trú Vượt Qua Mọi Bài Kiểm Thử Nhưng Vẫn Trễ Khung Giờ Chạy Batch

Một khuôn mẫu thất bại lặp đi lặp lại trong hiện đại hóa mainframe chẳng liên quan gì đến việc COBOL đã dịch có biên dịch được hay không, hay có cho ra đúng kết quả với một đầu vào cụ thể hay không. Hệ thống vượt qua toàn bộ kiểm thử chức năng, được đưa lên production, rồi lại trễ khung giờ xử lý ngay trong môi trường thực — không phải vì một chương trình cụ thể nào đó sai, mà vì thứ tự thực thi, hành vi checkpoint/restart, và các phụ thuộc về khung giờ chạy batch — những thứ từng chi phối việc job chạy khi nào và chạy như thế nào — chưa bao giờ được đưa vào thiết kế của hệ thống sau di trú. Những đợt đánh giá batch đủ sớm để phát hiện ra điều này là những đợt đánh giá vượt ra ngoài logic chương trình, xem xét cả luồng job, định nghĩa của bộ lập lịch, quan hệ trước-sau giữa các job, và cách xử lý khi job kết thúc bất thường (abend) — tức là lớp vận hành nằm phía trên bất kỳ chương trình đơn lẻ nào.

Lớp vận hành đó có tên gọi riêng, và nó không phải là COBOL. Đó là JCL.

Những Gì Một Bản Đồ Phụ Thuộc Thường Bỏ Sót

Phần lớn công cụ hiện đại hóa COBOL coi JCL chỉ là khung đỡ: một job card, cùng vài câu lệnh EXEC và DD nêu tên chương trình cần chạy và các tệp mà nó thao tác. Đồ thị phụ thuộc thực sự được xây dựng từ phía COBOL — chương trình, copybook, câu lệnh CALL — còn JCL bị thu gọn thành siêu dữ liệu chỉ cho biết chương trình nào chạy vào lúc nào.

Cách nhìn đó bỏ lỡ phần lớn nơi mà sự kết hợp (coupling) trong mainframe thực sự tồn tại. Các tham số ký hiệu (symbolic parameter) của JCL phải được giải quyết thông qua bước mở rộng JCL để lộ ra chương trình nào thực sự đang được job stream gọi tới, thay vì chỉ là các tham chiếu mẫu (template) chưa được giải quyết mà một lượt quét kiểm kê thông thường sẽ báo cáo. Các bước JCL thực thi có điều kiện dựa trên mã trả về (return code) của bước trước đó tạo ra sự kết hợp về luồng điều khiển giữa các chương trình chưa bao giờ trực tiếp gọi nhau trong mã nguồn — và sự kết hợp này hoàn toàn vô hình trong bất kỳ bản kiểm kê nào chỉ dựa trên tài liệu. Cộng thêm các copybook được chia sẻ giữa hàng chục chương trình và các lệnh CALL được giải quyết động lúc chạy, câu trả lời trung thực là: phần lớn tài liệu về phụ thuộc trong mainframe không chỉ thiếu sót — mà mặc định là sai. Một job COBOL duy nhất có thể vừa chuyển tiền, vừa kích hoạt kiểm tra tuân thủ, vừa cập nhật hàng chục báo cáo ở tầng dưới — và trong một lần chạy cụ thể, điều nào thực sự xảy ra có thể phụ thuộc hoàn toàn vào một mã điều kiện được thiết lập từ ba bước job trước đó.

Generation Data Group (GDG) khiến khoảng trống này càng lớn hơn. Một GDG không tham chiếu tới “tệp đó” — nó tham chiếu tới một thế hệ tương đối hoặc tuyệt đối trong một họ dataset xoay vòng, với các quy tắc lưu giữ và dọn dẹp riêng, đến mức các nền tảng hiện đại hóa đã phải xây dựng hẳn phần hỗ trợ chuyên biệt chỉ để giữ đúng ý nghĩa đó thay vì làm phẳng nó thành một tham chiếu tệp tĩnh duy nhất. Một đồ thị phụ thuộc không hiểu các thế hệ GDG sẽ không biết lần chạy job nào thực sự đã tạo ra dữ liệu đầu vào mà bước job tiếp theo sắp đọc.

Ngành Công Cụ Đã Biết Rõ Điều Này

Đây không phải là một quan sát mới mẻ — đó chính là lý do tồn tại cả một nhóm công cụ chuyên để tái dựng lại những phần của đồ thị phụ thuộc mà tài liệu không nắm bắt được. Các sản phẩm như SMART TS XL xây dựng bản đồ phụ thuộc trải rộng qua chương trình COBOL, job JCL, copybook và cấu trúc dữ liệu cùng lúc, chính vì phân tích tĩnh COBOL một cách đơn lẻ chỉ hé lộ một phần độ phức tạp thực sự quyết định chi phí và tiến độ di trú. Luận điểm lớn hơn mà các phân tích ngành liên tục đi đến là: ánh xạ JCL sang COBOL về bản chất là một hoạt động quản trị rủi ro — mọi thay đổi trên hệ thống mainframe đều kéo theo hệ quả vượt ra ngoài phạm vi thành phần thực sự bị thay đổi, và JCL thường chính là nơi “bán kính ảnh hưởng” đó lan tới.

Không có điều nào trong số này là vấn đề nhỏ nếu làm sai. Hơn 71% doanh nghiệp trong danh sách Fortune 500 vẫn đang vận hành các khối lượng công việc trọng yếu trên mainframe, và mainframe đảm nhận khoảng 68% khối lượng công việc IT sản xuất trên toàn cầu trong khi chỉ chiếm khoảng 6% chi tiêu IT — đây là quy mô hạ tầng mà sai sót trong ánh xạ phụ thuộc đặt vào rủi ro sản xuất thực sự, chứ không phải một bài tập trong phòng thí nghiệm.

Vì Sao Legacy Dragon Phân Tích JCL Như Một Ngôn Ngữ Hạng Nhất, Không Phải Tệp Đi Kèm

Legacy Dragon phân tích cú pháp mười ngôn ngữ nguồn — COBOL, JCL, PL/I, VB6, VB.NET, PowerBuilder, Assembly, SQL/DB2, CICS và REXX — thành một đồ thị AST và đồ thị phụ thuộc duy nhất, và trong danh sách đó, JCL đứng ngang hàng với COBOL, chứ không phải như một tệp siêu dữ liệu mô tả nó. Đây là một lựa chọn thiết kế có chủ đích, với cùng lý do khiến việc xử lý bảng mã ký tự của đồ thị này nằm bên trong bộ phân tích cú pháp thay vì trong một script tiền xử lý: một đồ thị được xây dựng bằng cách coi JCL chỉ là khung đỡ sẽ thừa hưởng đúng điểm mù mà mọi bản kiểm kê dựa trên tài liệu đều mắc phải — các nhánh mã điều kiện chưa từng được giải quyết, các thế hệ GDG không thể phân biệt, các tham số ký hiệu chưa được mở rộng. Một đồ thị phân tích JCL như một ngôn ngữ thực sự với luồng điều khiển thực sự có thể biểu diễn một bước job, mã điều kiện mà nó dùng để rẽ nhánh, chương trình mà nó gọi tới, và thế hệ GDG mà nó đọc hoặc ghi — tất cả như các cạnh trong cùng một cấu trúc vốn đã theo dõi đoạn COBOL nào gọi tới copybook nào.

Đó cũng là lý do JCL và điều phối batch là phần mở rộng tự nhiên của phân tích tác động, chứ không phải một tính năng tách biệt: câu hỏi “thay đổi này ảnh hưởng đến những gì” chưa bao giờ có thể trả lời được chỉ từ COBOL, trong trường hợp sự kết hợp thực sự giữa hai chương trình tưởng chừng không liên quan lại chính là một mã điều kiện được thiết lập trong một bước job mà mã nguồn của cả hai chương trình đều chưa bao giờ nhắc tới.

Vượt Ra Ngoài Legacy Dragon

Đây không phải là lập luận rằng điều phối batch khó hơn logic COBOL mà nó kích hoạt, hay rằng JCL xứng đáng được chú ý nhiều hơn những hệ thống mà nó thường bị gộp chung như một chi tiết phụ. Đây là một khẳng định hẹp hơn: một đồ thị phụ thuộc chỉ đầy đủ đến mức các ngôn ngữ mà nó thực sự được xây dựng để phân tích cho phép. Và trên mainframe, một phần đáng kể nguyên nhân thực sự làm đổ vỡ các dự án di trú được viết bằng một ngôn ngữ điều khiển công việc (job control language), không phải một ngôn ngữ lập trình — và phần lớn công cụ được xây dựng chỉ xoay quanh COBOL chưa bao giờ được thiết kế để nhìn thấy nó.

---

Muốn biết đồ thị phụ thuộc sẽ trông như thế nào khi JCL được phân tích như một ngôn ngữ hạng nhất thay vì khung đỡ quanh COBOL? Xem Legacy Dragon tại dragon.aitytech.com, đọc thêm về vì sao đồ thị AST được xây dựng trước hết như một công cụ phân tích tác động, hoặc liên hệ chúng tôi tại [email protected].