Mọi cuộc di trú mainframe đều bắt đầu từ việc ai đó đi tìm công cụ di trú mainframe, và buổi trình diễn của nhà cung cấp diễn ra sau đó luôn trông thuyết phục đến lạ. Vài nghìn dòng COBOL đi vào, Java dễ đọc đi ra, bộ kiểm thử chạy qua hết, và bản trình chiếu hứa hẹn bảy mươi hay tám mươi phần trăm tự động hóa. Bản thân buổi trình diễn thường là trung thực. Nó cũng thường được chạy trên đoạn mã hành xử chẳng giống mã của bạn chút nào.

Hướng dẫn này mô tả những nhóm công cụ thực sự tồn tại, mỗi nhóm làm tốt điều gì và những chỗ cụ thể mà từng nhóm hay hỏng khi gặp khối lượng công việc thật. Nó được viết cho người phải ký vào bản luận chứng kinh doanh, chứ không phải cho người đang cổ vũ nhà cung cấp bên trong tổ chức.

Quan điểm thẳng thắn: Công cụ di trú mainframe làm được rất nhiều việc hữu ích, đặc biệt ở khâu phân tích, di chuyển dữ liệu và chuyển đổi cơ học. Điều chúng không làm được là hiểu các quy tắc nghiệp vụ của bạn. Chuyển đổi tự động chắc chắn tạo ra mã chạy được; nó không tạo ra mã mà đội ngũ của bạn muốn bảo trì, và chính khoảng cách đó mới là nơi phần lớn ngân sách thực sự đi qua.

Bốn nhóm công cụ di trú mainframe

Thị trường trông có vẻ chật chội cho đến khi bạn sắp xếp nó theo việc sản phẩm thực sự làm gì. Gần như mọi thứ đều rơi vào một trong bốn nhóm, và một chương trình nghiêm túc sẽ dùng công cụ từ ít nhất ba nhóm trong số đó.

Công cụ khám phá và phân tích đọc toàn bộ mã nguồn hiện có và cho bạn biết mình đang sở hữu những gì. Chúng phân tích cú pháp COBOL, JCL, copybook và các định nghĩa cơ sở dữ liệu, rồi dựng lên đồ thị lời gọi, bản đồ dòng đời dữ liệu và cây phụ thuộc. Đây là nhóm ít hào nhoáng nhất và cũng có giá trị ổn định nhất, bởi trong tổ chức của bạn không ai nắm được bức tranh đầy đủ của một hệ thống đã bồi đắp suốt bốn mươi năm.

Nền tảng rehosting và giả lập cho phép các khối công việc mainframe đã biên dịch chạy trên phần cứng phổ thông hoặc trên máy ảo đám mây. COBOL của bạn vẫn là COBOL, JCL vẫn là JCL, và một lớp tương thích sẽ cung cấp các dịch vụ thời gian chạy mà trước đây mainframe đảm nhiệm.

Công cụ chuyển đổi tự động dịch mã nguồn từ COBOL sang Java, C# hoặc một ngôn ngữ đích hiện đại khác. Đây là nhóm khiến người mua phấn khích nhất và cũng là nhóm gây thất vọng thường xuyên nhất, vì những lý do trình bày bên dưới.

Công cụ di trú dữ liệu chuyển bản thân dữ liệu: tệp VSAM, tập dữ liệu tuần tự và bảng DB2 sang kho lưu trữ quan hệ hoặc kho gốc đám mây. Chúng xử lý việc chuyển đổi bộ ký tự, các trường thập phân đóng gói và các bố cục bản ghi mà những sản phẩm ETL đa dụng đơn giản là không đọc nổi.

Các nhà cung cấp đám mây lớn đều đóng gói vài nhóm này lại với nhau, còn các hãng chuyên biệt đã hợp nhất khá mạnh qua các thương vụ mua lại trong những năm gần đây. Trước khi ký một hợp đồng hỗ trợ nhiều năm, hãy kiểm tra xem hiện ai đang sở hữu sản phẩm đó và lộ trình của họ cam kết đến đâu, bởi quyền sở hữu trong thị trường này thay đổi thường xuyên hơn cả công nghệ.

Công cụ phân tích thực sự làm tốt điều gì

Nếu chỉ mua được một nhóm, hãy mua nhóm này. Công cụ khám phá trả lời những câu hỏi mà nếu làm tay thì một đội nhân sự thuê ngoài phải mất vài tháng mới trả lời xong.

Sản phẩm phân tích tốt sẽ cho bạn biết chương trình nào thực sự được gọi trong môi trường vận hành và chương trình nào đã chết cả chục năm, dữ liệu đi từ một trường trên màn hình qua nửa tá chương trình vào một bảng DB2 như thế nào, copybook nào đang được dùng chung giữa các phân hệ, và đoạn mã thực sự nguy hiểm nằm ở đâu. Chính kết quả cuối cùng đó mới làm thay đổi kế hoạch. Mọi hệ thống mainframe đều có một nhúm chương trình mà mọi thứ khác phụ thuộc vào, và chúng hiếm khi là những chương trình mà phía nghiệp vụ vẫn hình dung.

Giới hạn nằm ở khâu diễn giải. Một đồ thị phụ thuộc với bốn vạn nút là dữ liệu, không phải hiểu biết. Vẫn phải có người nhìn vào kết quả đó, gom lại theo các năng lực nghiệp vụ và quyết định cái gì đi trước. Những công cụ hứa hẹn tự động rút ra quy tắc nghiệp vụ thường tạo ra thứ gần với một bản diễn giải lại của mã hơn là một mô tả về ý định, và hai thứ đó lệch nhau đúng ở chỗ mã chứa một lỗi mà phía nghiệp vụ đã âm thầm thích nghi.

Hãy chạy phân tích trước khi chốt cách tiếp cận. Hướng dẫn của chúng tôi về chiến lược hiện đại hóa mainframe trình bày cách những phát hiện đó nên định hình lựa chọn giữa viết lại, refactor hay đổi nền tảng.

Nền tảng rehosting: nhanh, có thật, và không phải hiện đại hóa

Rehosting là lựa chọn dễ dự đoán nhất hiện có, và cũng vì thế mà nó bị đánh giá thấp một cách kinh niên.

Đề xuất rất thẳng thắn. COBOL của bạn được biên dịch lại hoặc thông dịch trên một nền tảng giả lập các dịch vụ thời gian chạy của mainframe, nên xử lý giao dịch, lập lịch theo lô, thao tác tệp và điều khiển tác vụ vẫn hành xử như trước. Vì mã nguồn gần như không đổi, gánh nặng kiểm thử nhẹ hơn nhiều so với bất kỳ hướng nào khác, và dự án hoàn thành trong vài tháng thay vì vài năm.

Khoản tiết kiệm là có thật, và nó đến từ mô hình phần cứng và bản quyền chứ không phải từ phần mềm. Nhiều tổ chức cho biết chi phí vận hành hằng năm giảm đáng kể sau khi rời khỏi mainframe vật lý, và con số đó thường đủ để tài trợ cho giai đoạn công việc kế tiếp.

Điều rehosting không làm được là giải quyết chính lý do khiến phần lớn hội đồng quản trị phê duyệt những chương trình kiểu này. Sau một lần rehost thành công, bạn vẫn có một mã nguồn COBOL, vẫn cần lập trình viên COBOL, và khả năng tuyển được họ không hề khá lên. Không có gì trong ứng dụng trở nên dễ thay đổi hơn. Rehosting mua cho bạn thời gian và tiền mặt, điều đó thực sự có giá trị, nhưng nó nên được gọi một cách trung thực là đổi nền tảng chứ không phải hiện đại hóa.

Nó cũng mang vào một phụ thuộc mới. Bạn đã đổi môi trường thời gian chạy của IBM lấy lớp tương thích của một nhà cung cấp, và hệ thống vận hành của bạn giờ dựa vào việc nhà cung cấp đó tiếp tục hỗ trợ nó. Với mức độ hợp nhất của thị trường này, đó là một rủi ro đáng được ghi vào luận chứng kinh doanh.

Chuyển đổi tự động: nơi rắc rối thật sự trú ngụ

Chuyển đổi COBOL tự động có chạy. Đó không phải vấn đề. Vấn đề là kết quả trông ra sao và sống chung với nó tốn bao nhiêu.

Các bộ máy chuyển đổi nhìn chung rất trung thành. Chúng bảo toàn hành vi, kể cả hành vi không ai cố ý tạo ra, bởi trung thành là mục tiêu thiết kế duy nhất có thể biện hộ được. Một công cụ không thể biết rằng một thói làm tròn nào đó trong công thức tính phí bảo hiểm là lỗi mà các chuyên viên định phí đã bù trừ từ năm 1997, nên nó tái tạo lỗi ấy y nguyên. Đó là lựa chọn đúng, và nó cũng có nghĩa hệ thống Java mới của bạn thừa hưởng toàn bộ những điều kỳ quặc đã tích tụ trong hệ thống cũ.

Kết quả cũng bị định hình bởi đầu vào. COBOL viết bằng các chuỗi GOTO, kiểu rơi tự do của PERFORM THRU, câu lệnh ALTER và những đoạn được nhảy vào từ nhiều hướng thì không tách ra thành các phương thức sạch sẽ, vì đơn giản là không có cách tách nào sạch sẽ để tìm. Cái hiện ra là Java hoặc C# đi theo luồng điều khiển của COBOL, dùng tên biến của COBOL và nhiều khi khó đọc hơn cả bản gốc. Dân trong nghề gọi nó là JOBOL, và hoàn toàn có thể xảy ra chuyện một cuộc di trú kết thúc thành công nhưng để lại một mã nguồn không ai bảo trì nổi bằng cả hai ngôn ngữ.

Có vài cấu trúc gây đau đớn không cân xứng, và chúng đáng được kiểm tra sớm vì chính chúng quyết định con số ước lượng công làm tay.

Năm cấu trúc quyết định khối lượng làm tay

Số học thập phân đóng gói là cái đầu tiên. Các trường COMP-3 của COBOL và ngữ nghĩa thập phân dấu phẩy tĩnh không ánh xạ được sang dấu phẩy động, và bất kỳ công cụ nào cho phép chúng làm vậy sẽ tạo ra kết quả tài chính lệch với mainframe ở chữ số thập phân thứ tư. Bản chuyển đổi đúng dùng các kiểu thập phân độ chính xác tùy ý, vốn chậm hơn và phải được áp dụng nhất quán trên mọi nhánh tính toán.

Mã hóa ký tự là cái thứ hai. Chuyển EBCDIC sang ASCII là việc cơ học, nhưng thứ tự đối chiếu thì không giống nhau, nên bất cứ thứ gì phụ thuộc vào thứ tự sắp xếp đều có thể đổi. Báo cáo ra theo một trình tự khác, các phép kiểm tra khoảng hành xử khác đi, và phép so sánh khóa cho ra kết quả đúng trong hệ thống mới nhưng sai khi đối chiếu với hệ thống cũ.

REDEFINES và bản ghi biến thể là cái thứ ba. Một vùng nhớ duy nhất được diễn giải theo nhiều cách khác nhau thì không có tương đương tự nhiên trong một ngôn ngữ định kiểu chặt. Mã sinh ra thường là thao tác mảng byte bọc trong các hàm truy cập, chạy được và cực kỳ khó chịu khi phải bảo trì.

Ngữ nghĩa giao dịch là cái thứ tư. Lối lập trình giả hội thoại của CICS, nơi trạng thái được mang theo trong một vùng truyền thông giữa các lần tương tác màn hình, không tương ứng với bất kỳ mô hình web hay dịch vụ hiện đại nào. Giả lập nó sinh ra thứ kỳ quặc; thiết kế lại cho tử tế thì đó là viết lại tầng giao diện.

Các thủ tục Assembler là cái thứ năm và là cái bị đánh giá thấp một cách đáng tin cậy nhất. Gần như mọi hệ thống sống lâu đều chứa một nhúm mô-đun Assembler, thường do một người đã nghỉ hưu từ nhiều năm trước viết, làm một việc gì đó quan trọng về hiệu năng hoặc gắn chặt với nền tảng. Không công cụ nào chuyển đổi được chúng. Chúng được viết lại bằng tay, dựa trên hành vi, có kiểm thử đi kèm.

Nếu bạn đang cân nhắc ngôn ngữ đích, các hướng dẫn chi tiết của chúng tôi về di trú COBOL sang Java và di trú COBOL sang C# trình bày những cấu trúc này đáp xuống từng hệ sinh thái ra sao.

Công cụ di trú dữ liệu và những chi tiết cắn ngược

Việc chuyển dữ liệu ít được chú ý hơn chuyển đổi mã, nhưng gây ra ít nhất là chừng ấy chậm trễ.

Công cụ chuyên biệt xứng đáng có chỗ ở đây bởi các định dạng dữ liệu mainframe thật sự khó chịu. Chúng hiểu bố cục copybook, các trường thập phân đóng gói và thập phân vùng, dấu chồng ký tự, mệnh đề OCCURS DEPENDING ON, và cả sự thật rằng một tệp VSAM có thể chứa nhiều loại bản ghi khác nhau được phân biệt bằng một byte ở vị trí thứ mười hai. Các sản phẩm ETL đa dụng thì không, và những đội cố ép chúng làm việc đó thường kết thúc bằng việc dựng lại một phiên bản tệ hơn của chính năng lực này.

Vấn đề khó hơn nằm ở ngữ nghĩa chứ không phải kỹ thuật. Tệp mainframe thường mã hóa ý nghĩa theo cách mà một lược đồ quan hệ không diễn đạt trực tiếp được: những trường dự phòng bị dùng sang mục đích khác, ngày tháng lưu dưới dạng số nguyên sáu chữ số kèm một quy tắc suy ra thế kỷ, cờ trạng thái mà tập giá trị hợp lệ chỉ nằm trong một chương trình chứ không nằm trong bảng tra cứu, và các khóa trùng lặp mà ứng dụng vẫn dung thứ. Quyết định mỗi thứ đó sẽ trở thành cái gì trong lược đồ đích là công việc phân tích, và nó không thể tự động hóa vì câu trả lời chỉ tồn tại trong đầu người.

Hãy lên kế hoạch đối soát ngay từ đầu. Mỗi tập dữ liệu đã chuyển đều cần đếm số bản ghi, tổng kiểm soát và so sánh đến từng trường, chạy lặp đi lặp lại chứ không phải một lần. Phần lớn chương trình còn cần một giai đoạn chạy song song, khi cả hai hệ thống cùng xử lý một đầu vào và kết quả được so từng byte cho đến khi mọi khác biệt hoặc được loại bỏ hoặc được giải thích. Bộ khung so sánh đó là một phần mềm thực thụ với chi phí phát triển riêng, và nó thuộc về kế hoạch chứ không thuộc về quỹ dự phòng.

Cách chọn công cụ di trú mainframe mà không hối tiếc

Một vài nguyên tắc giữ cho các quyết định này bám sát mặt đất.

Hãy khăng khăng làm bản chứng minh khả thi bằng chính đoạn mã tệ nhất của bạn, không phải bằng mẫu của nhà cung cấp. Chọn mô-đun mà ai cũng né, cái có lời gọi Assembler và bảy tầng REDEFINES, rồi đề nghị họ chuyển đổi nó. Kết quả đó nói với bạn nhiều hơn bất kỳ khách hàng tham chiếu nào.

Hãy hỏi cụ thể công cụ xử lý số học thập phân và thứ tự sắp xếp ra sao, và đòi xem mã sinh ra chứ không phải một bản tóm tắt. Nếu nhà cung cấp không cho bạn thấy được mã dễ đọc từ đầu vào xấu xí, hãy coi như con số ước lượng cho phần sửa tay lớn hơn mức họ báo.

Hãy xem tỷ lệ tự động hóa là thước đo số dòng, không phải công sức. Một công cụ chuyển được chín mươi phần trăm câu lệnh vẫn có thể để lại cho bạn mười phần trăm chứa toàn bộ rủi ro, và mười phần trăm ấy thường ngốn hơn nửa tiến độ.

Cuối cùng, hãy dự trù ngân sách cho những phần không công cụ nào chạm tới: bộ khung kiểm thử, đối soát, chạy song song, tài liệu vận hành và đào tạo lại. Hướng dẫn về chi phí và tiến độ di trú COBOL của chúng tôi trình bày các khoản mục ấy thường phân bổ thế nào trong một chương trình.

Nhận một đánh giá độc lập trước khi cam kết

Mecanik tham gia các chương trình di trú mainframe cũ và di trú COBOL với tư cách kỹ sư chứ không phải đại lý bán công cụ, nghĩa là chúng tôi không ăn hoa hồng theo nền tảng bạn chọn. Chúng tôi chạy khâu khám phá, chuyển đổi một mô-đun thật sự khó bằng cả tay lẫn công cụ, và cho bạn thấy khác biệt trước khi có ai ký bất cứ điều gì.

Nếu hệ thống của bạn nhỏ hơn, hoặc câu hỏi của bạn thiên về ngôn ngữ đích hơn là về công cụ, các trang dịch vụ hiện đại hóa COBOL của chúng tôi trình bày cách chúng tôi xác định phạm vi cho công việc đó. Dù theo hướng nào, bước đầu hữu ích vẫn là một cuộc trò chuyện ngắn về những gì thực sự đang nằm trong mã nguồn của bạn, bởi câu trả lời cho câu hỏi về công cụ phụ thuộc hoàn toàn vào đó.

Bài viết liên quan: Dịch vụ hiện đại hóa COBOL: chọn nhà cung cấp , Di chuyen tu COBOL sang Python , Di chuyển COBOL sang Go: hướng dẫn cho doanh nghiệp UK , Di chuyển COBOL sang Rust - Hướng dẫn doanh nghiệp UK .

Câu hỏi thường gặp

Công cụ di trú mainframe có tự động hóa được toàn bộ dự án không? Không. Chuyển đổi tự động thường dịch được phần lớn câu lệnh, nhưng phần còn lại chứa các mô-đun Assembler, xử lý trạng thái giao dịch, cấu trúc bản ghi biến thể và những quy tắc nghiệp vụ không được ghi lại, tất cả đều cần làm tay. Kiểm thử, đối soát và chạy song song cũng không hề thay đổi dù mức tự động hóa mã có cao đến đâu.

Rehosting hay chuyển đổi mã tự động thì tốt hơn? Chúng giải quyết hai bài toán khác nhau. Rehosting đưa khối công việc rời phần cứng mainframe nhanh chóng và cắt chi phí vận hành, nhưng để lại cho bạn COBOL. Chuyển đổi mã thay đổi ngôn ngữ và thị trường tuyển dụng, với chi phí và rủi ro cao hơn đáng kể. Nhiều tổ chức rehost trước để lấy tiền tài trợ cho một cuộc chuyển đổi theo giai đoạn sau đó.

Vì sao mã COBOL sau chuyển đổi lại khó đọc đến vậy? Vì các bộ máy chuyển đổi bảo toàn hành vi một cách trung thành, gồm cả luồng điều khiển, cách đặt tên và cấu trúc dữ liệu của COBOL. Mã xây quanh các chuỗi GOTO và vùng nhớ dùng chung không có tương đương sạch sẽ trong Java hay C#, nên kết quả phản chiếu đúng cấu trúc gốc. Muốn có mã bảo trì được thì phải refactor bằng tay sau khi chuyển đổi.

Công cụ di trú mainframe bỏ sót những vấn đề dữ liệu nào? Chúng xử lý tốt việc chuyển định dạng nhưng không giải quyết được ý nghĩa. Các trường dự phòng bị dùng sang mục đích khác, ngày sáu chữ số kèm quy tắc suy ra thế kỷ, mã trạng thái chỉ được định nghĩa bên trong chương trình và những khóa trùng lặp được dung thứ đều cần con người quyết định trước khi thiết kế đúng lược đồ đích.

Làm sao kiểm chứng hệ thống sau di trú hành xử y hệt hệ thống cũ? Hãy chạy cả hai hệ thống trên cùng dữ liệu đầu vào thật trong một khoảng thời gian đã định và so sánh kết quả đến từng trường, kèm theo số đếm bản ghi và tổng kiểm soát cho mọi tập dữ liệu đã chuyển. Hãy xây bộ khung so sánh đó như một sản phẩm bàn giao riêng, vì khác biệt được phát hiện liên tục chứ không phải cùng một lúc.