ההגירה מ-COBOL שעברה קומפילציה בשלמות — ובכל זאת השחיתה את הפנקס
הקוד היה מושלם. זו הייתה כל הבעיה.
תוכנית להעברות בנקאיות תורגמה מ-COBOL ל-Java. היא עברה קומפילציה. בדיקות היחידה עברו. היא צלחה כל שער שבנינו כדי לתפוס טעויות. ואז, בבדיקות קבלה של המשתמש, העסקה הראשונה ממש הפעילה את בדיקת העקביות של מסד הנתונים והכול קרס.
הנתיחה שלאחר המוות ארכה יותר מכפי שהייתה צריכה, כי שום דבר ב-Java לא נראה שגוי. האשם היה משתנה בשם TRN-LIMIT. כלי התרגום קרא אותו כמספר רגיל והעניק לו טיפוס מספר שלם סטנדרטי. אבל TRN-LIMIT מעולם לא הוגדר במקום שבו הכלי חיפש. הוא הוכרז בקובץ copybook — קובץ כותרת משותף — שנמשך אלפי שורות קודם לכן בשרשרת הביצוע, וה-copybook הזה נשא סעיף REDEFINES: מבנה של COBOL שמאפשר לאותו תא בזיכרון להיקרא כשני טיפוסי נתונים שונים לחלוטין, בהתאם לדגל שנקבע במקום אחר לגמרי. במיינפריים, אותה כתובת החזיקה packed decimal. קוד ה-Java החדש כתב נתונים בינאריים משובשים לתוך עמודת מסד הנתונים, והשלמות ההתייחסותית של הפנקס קרסה.
הקוד היה תקין מבחינה תחבירית ללא רבב. הכשל היה הקשרי. הכלי פספס תלות ששכנה מחוץ לשדה הראייה שלו — ובמודרניזציה של COBOL מדור קודם, כמעט תמיד כך הכסף נעלם.
פרויקטי מודרניזציה בדרך כלל אינם מתים על הקוד שאתה יכול לראות. הם מתים על הקוד שהכלי לא יכול היה.
זהו הסיפור על מדוע הפסקתי להאמין שתרגום טוב יותר הוא התשובה, ומה בנינו ב-Veriprajna במקום זאת.
מדוע "הדבק COBOL, קבל Java" תמיד מתפקד יפה בהדגמה?
אם ישבת באיזושהי פגישת מודרניזציה של מיינפריים בשנתיים האחרונות, שמעת את המצג: הדבק את ה-COBOL שלך, קבל בחזרה Java. זה מפתה כי ההדגמה תמיד עובדת. מישהו מכניס תוכנית מסודרת בת 200 שורות, המודל מחזיר Java נקייה ואידיומטית, וכולם בחדר נושמים לרווחה. סוף סוף.
גם אני האמנתי בזה, לזמן מה. כשהצוות שלי ניגש לזה לראשונה, עשינו את הדבר המובן מאליו — ניסינו לעשות את התרגום טוב יותר. הזנו למודלים יותר הקשר, כיווננו אותם למוזרויות של COBOL, מדדנו את איכות הפלט. יש אפילו מודל פתוח מכוונן בשם XMainframe, שנבנה במיוחד לשם כך, שמשיג ציון גבוה בכ-30% ממודלי קוד כלליים במשימות COBOL. התרגומים נעשו נקיים יותר. ה-Java נעשתה קריאה יותר.
והיא עדיין נשברה בבדיקות הקבלה. שוב ושוב, בדיוק על אותו סוג של תלות נסתרת שהטביעה את תוכנית ההעברות הבנקאיות. זה היה החודש שבו הבנתי שאנחנו מלטשים את הדבר הלא נכון. איכות התרגום מעולם לא הייתה צוואר הבקבוק. הקוד שעובר קומפילציה הוא החלק הקל. החלק הקשה הוא הקוד שהכלי אינו יכול לראות.
המספרים סביב זה אכזריים ועקביים: 70 עד 80% מפרויקטי המודרניזציה של מיינפריים נכשלים בעמידה ביעדיהם. לא 70% מתעכבים — 70% נכשלים. האבחון הרגיל מאשים בהערכת חסר של הבדיקות או בהעברת נתונים מבולגנת, ואלה קיימים באמת. אבל מתחת כמעט לכולם נמצא אותו שורש הבעיה שזה עתה ראיתי בשידור חי: הכלים מתייחסים לבסיס הקוד כטקסט שיש להמיר, בעוד שהוא למעשה טופולוגיה שיש להבין.
מה ש"הדבק COBOL, קבל Java" אינו יכול לראות
ברגע שאתה מתחיל לחפש עיוורון הקשרי, אתה רואה אותו בכל מקום. שלוש תבניות שברו אותנו בתדירות הגבוהה ביותר, ואף אחת מהן אינה נראית בקובץ המקור שבו מתרגם בוהה.
נתחיל בבעיית ה-copybook שכבר תיארתי. תוכנית COBOL בודדת יכולה להפנות ליותר מארבעים copybooks, וה-copybooks הללו כוללים copybooks אחרים, כך שההגדרה האמיתית של משתנה יכולה לשבת כמה רמות עמוק בשרשרת ההכללה. כלי מבוסס-טקסט קורא את ההצהרה שלפניו ומסיק טיפוס. אין לו שום דרך לדעת שבשדה packed-decimal, ההסקה הזו שגויה בשקט.
ואז יש את החשבון. אצל COBOL, ה-COMP-3 packed decimal אין לו מקבילה מקורית ב-Java. אם תושיט יד אל double הרגע הכנסת עיגול נקודה צפה למערכת שמניעה כסף. אפילו BigDecimal, הכלי הנכון, אינו תואם ל-COBOL כברירת מחדל — עליך לקבע במפורש את מצב העיגול שלו ל-HALF_EVEN כדי לשקף את סעיף ה-ROUNDED של COBOL. אם תטעה בזה, תסטה בפרוטה לכל עסקה. הפרוטה הזו מצטברת על פני מיליוני עסקאות עד שבועות לאחר מכן, דוח התאמה מסמן סטייה שאיש אינו יכול להסביר.
התבנית שכמעט כולם שוכחים היא זו שבאמת מפילה את הסביבה הפרודקטיבית: ה-COBOL שלך אינו רץ בפני עצמו. מתזמן — CA-7 או TWS — מתזמר איפשהו בין אלפיים לחמשת אלפים עבודות אצווה, עם שרשראות תלות השזורות דרכן. עבודה A כותבת מערך נתונים בשעה 1 בלילה שעבודה B קוראת בשעה 2 בלילה. אתה יכול להעביר כל שורה של COBOL ללא רבב ועדיין להפיל את הבנק בחצות, כי איש לא מיפה את רשת העבודות. גרף הפרודקשן מעולם לא היה בקוד המקור. הוא היה ב-JCL.
העבודה ששוברת את הפרודקשן בשעה 2 בלילה לעולם אינה זו שהסתכלת עליה.
לזה אני מתכוון כשאני אומר טופולוגיה. הארטיפקט שבאמת מפעיל את העסק שלך הוא רשת של קשרים — תוכניות, copybooks, מערכי נתונים, עבודות מתוזמנות, טבלאות DB2, טרנזקציות CICS — וקוד המקור של COBOL הוא רק חוט אחד בה.
מדוע הפסקתי לסמוך על המתרגם והתחלתי לשרטט את המפה
נקודת המפנה עבורנו הייתה ההחלטה שהמפה היא המוצר.
לפני שאנו מתרגמים ולו שורה אחת, אנו בונים גרף ידע של כל בסיס הקוד — כל תוכנית, כל קשת copybook, כל תלות JCL, כל העברת מערך נתונים, כל נקודת מגע DB2 — ואנו פותרים את הקשרים הטרנזיטיביים שקבצי המקור מסתירים. כשאתה יכול לראות שלתוכנית אחת יש למעלה מארבעים קשתות copybook ושאחת מהן נושאת REDEFINES במרחק שני מודולים, אסון ה-TRN-LIMIT פשוט אינו קורה, כי ידעת שהשדה הוא packed decimal לפני שהקלדת תו אחד של Java.
אני רוצה להיות מדויק לגבי מדוע זה שונה ממה ששאר התחום מוכר, כי התחום צפוף ורובו באמת טוב בחלק שהוא פותר.
watsonx Code Assistant for Z של IBM הוא השחקן המבוסס הרציני ביותר — מערכת אג'נטית, עם סוכני תזמור, ארכיטקטורה וקוד, שמטפלת ב-COBOL-ל-Java ואפילו ב-PL/I וב-IMS, והיא מנתחת צריכת CPU עד לתוך ה-copybooks. זו גם התחייבות של יותר מ-2 מיליון דולר שרצה על z/OS ונשענת על כלי ה-ADDI של IBM, שנועלים אותך בשקט למיינפריים בדיוק במהלך ההגירה שנועדה לשחרר אותך ממנו. היא אינה מבצעת בדיקות שקילות התנהגותית, והיא אינה ממפה את רשת עבודות ה-JCL שלך.
ואז מגיע הרגע ששינה את צורת כל השוק. בפברואר 2026, Anthropic פרסמה מדריך למודרניזציה של COBOL עבור Claude Code; מניית IBM צנחה ב-13.2% ביום ההכרזה, ורשת שותפים בשווי 100 מיליון דולר הצטרפה במרץ. Claude Code מצוין בגילוי, בתיעוד ובקריאת קוד לא מוכר — שימושי באמת בשלבים המוקדמים. אבל זהו כלי כללי. אין לו גרף ידע מובנה לפתרון תלויות טרנזיטיביות, והוא אינו מתיימר לפתור תזמון JCL, שקילות התנהגותית, או את שבילי הביקורת שבנק מפוקח חייב להפיק.
מפעל ההגירה של Microsoft ל-Azure מכוון ל-Java Quarkus ונועל את פלטפורמת היעד שלך ל-Azure. אינטגרטורי המערכות הגדולים — DXC עם מנוע ההמרה שרשם פטנט, TCS עם MasterCraft, Infosys עם Cobalt, Accenture — מריצים התקשרויות של 500 אלף עד יותר מ-5 מיליון דולר ומיישמים כלי ספקים במקום לבנות תבונה על המערכת שלך; Accenture הובילה את ההגירה של הליבה בבנק Commonwealth Bank of Australia שעלתה בערך 749.9 מיליון דולר ונמשכה חמש שנים. ו-Visual COBOL של Micro Focus, שמוצג לעתים קרובות כנקודת התחלה, אינו מודרניזציה כלל — זהו רה-הוסטינג. ה-COBOL שלך ממשיך להיות COBOL, רק על סביבת ריצה חדשה. החוב הטכני ובעיית כוח האדם נמצאים בדיוק היכן שהשארת אותם.
כל אחד מאלה עושה משהו אמיתי. מה שאף אחד מהם אינו עושה הוא לבנות את טופולוגיית התלות המלאה — JCL, CICS, DB2, copybooks, והכול — תחילה, ללא תלות בכל פלטפורמת יעד, ולהתייחס למפה הזו כאל היסוד שעליו כל השאר עומד.
רוב הספקים מוכרים לך מתרגם טוב יותר. התרגום מעולם לא היה החלק שנכשל.
השעון שאיש אינו יכול לעצור
הנה החלק שהופך את זה מבעיה הנדסית למקרה חירום.
האנשים שמבינים את המערכות האלה עוזבים. מפתח ה-COBOL הממוצע בארה״ב הוא בן 55 בערך. בערך 10% מכוח העבודה הזה פורש מדי שנה, ו-85% מהאוניברסיטאות הורידו את COBOL מתוכנית הלימודים עוד בשנות ה-90, ולכן כמעט אף אחד אינו מחליף אותם. שישים אחוז מהארגונים אומרים כעת שמציאת מפתחי COBOL מיומנים היא אתגר המודרניזציה הגדול ביותר שלהם — ו-58% מהמפתחים שעדיין מכירים את המחסניות האלה אומרים שהם שוקלים לעזוב בגללן.
עמדתי בגרסה של זה שרודפת אותי: מסיבת הפרישה של האדם היחיד שבאמת הבין את חלון האצווה. כולם מחייכים, יש עוגה, ואיפשהו בירכתי מוחי קול אומר הידע הזה בדיוק יצא מהדלת והוא אינו כתוב בשום מקום. גרף ידע הוא, בין היתר, דרך ללכוד את מה שנמצא בראשו של אותו אדם לפני המסיבה — לגרום למפת התלות לשרוד את האנשים ששיננו אותה.
וההימור אינו קטן או מופשט. כ-220 מיליארד שורות של COBOL עדיין נמצאות בפרודקשן פעיל. הוא מפעיל 95% מעסקאות הכספומטים ומסלק בערך 3 טריליון דולר ביום. ארבעים ושלושה אחוז ממערכות הבנקאות בנויות עליו. החוב הטכני של ארה״ב עומד על 1.52 טריליון דולר לפי הערכה, והמיזם הממוצע שורף בערך 370 מיליון דולר בשנה על חוסר יעילות של מערכות מדור קודם, כאשר חברות שירותים פיננסיים מוציאות 70 עד 75% מתקציבי ה-IT שלהן רק על החזקת המערכות הישנות בחיים. הצוותים שמבצעים את ההגירה נכון מדווחים על תשואות של 114 עד 225% ועל חיסכון של כ-25 מיליון דולר בשנה — אבל היתרון הזה קיים רק בצדה הרחוק של הגירה שלא נכשלה. זוהי המודרניזציה הנדירה שבה לא לעשות דבר היא האפשרות היקרה.
האם כלי ה-AI החדשים פשוט לא יפתרו את זה?
זו השאלה שאני מקבל הכי הרבה, והיא הוגנת, במיוחד לאחר שהכרזת Anthropic גרמה לזה להיראות כאילו הבעיה זה עתה הוכרזה כפתורה.
התשובה הכנה שלי: הכלים החדשים הפכו את שלב הגילוי למהיר בהרבה, וזו התקדמות אמיתית — אני משתמש בהם. אבל AI אג'נטי שנעשה טוב בקריאת COBOL אינו משנה את הדבר שבאמת הורג פרויקטים. Gartner צופה ש-40% מאפליקציות הארגון יכללו סוכני AI ייעודיים למשימה עד 2026; יותר סוכנים שמתרגמים קוד מהר יותר אינם עוזרים אם כולם עיוורים לאותה תלות JCL. מהירות בבעיה הלא נכונה היא פשוט דרך מהירה יותר להגיע לבדיקות הקבלה ולהיכשל שם.
השאלה השנייה שאני מקבל היא לגבי רגולציה, והיא זו שבנקים מדרג-הביניים ממעיטים בערכה. חוק החוסן התפעולי הדיגיטלי של האיחוד האירופי — DORA — נכנס לתוקף בינואר 2025 ודורש בדיקות חוסן תפעולי ובדיקות חדירה מונחות-איום שמערכות מדור קודם פשוט מעולם לא תוכננו לעבור. בוחנים אמריקאים ב-FFIEC וב-OCC מתייחסים לתשתית מזדקנת כפער ציות פעיל, ומערכות בנות יותר מעשר שנים נושאות בערך פי שלושה סבירות לפריצה. הגירה שאינה יכולה להפיק שביל ביקורת המוכיח שהמערכת החדשה מתנהגת באופן זהה לישנה אינה מודרניזציה — היא התחייבות חדשה עם תחביר טוב יותר.
לכן בדיקות שקילות התנהגותית חשובות בדיוק כמו המפה. הטכניקה פשוטה לתיאור וקשה לביצוע טוב: לכידת קלטים ופלטים אמיתיים מהמערכת המדור קודם — מערך נתונים זהב — והרצתם מחדש מול החדשה עד שההתנהגות תואמת, מקרה קצה מול מקרה קצה. מקרי הקצה הללו, שהצטברו על פני עשורים, לעתים קרובות מקודדים לוגיקה רגולטורית שאינה קיימת בשום מקום אחר — לא במפרט, לא בראשו של אדם, רק בקוד הרץ. ראיתי את זה נושך מבטח קשה יותר מבנק: כלל התמחור שמופעל רק עבור תוספת פוליסה משנת 1998, חישוב עתודת התביעות שאת העיגול שלו אף אדם חי אינו יכול להסביר אבל כל ביקורת תלויה בו. אבד אותם בשקט ותגלה אילו מהם היו חשובים ביום שרגולטור ישאל.
איזו לבנה אתה מושך ראשונה?
ברגע שיש לך את המפה, היא אומרת לך משהו ששום מתרגם אינו יכול: היכן בטוח להתחיל.
האסטרטגיה הדומיננטית כעת — ומטעם טוב — היא ה"תאנה החונקת": במקום שכתוב במפץ גדול, אתה מחלץ יכולת אחת בכל פעם, מריץ ישן וחדש זה לצד זה, ושומר את המערכת המדור קודם כגיבוי חי עד שהחלק החדש זכה באמון. אבל כל ספק שממליץ על התאנה החונקת משמיט את השאלה הקשה ביותר — איזה מודול אתה חונק ראשון? בחר אחד שצמוד עמוקות ושחזרת את סיכון המפץ הגדול עם צעדים נוספים.
גרף הידע עונה על זה ישירות. הוא מציף את המודולים בעלי הצימוד הנמוך ביותר — אלה עם הכי מעט תלויות נכנסות — כדי שתוכל לחלץ חלק אמיתי מהמערכת, להוכיח את הגישה, ולבנות ביטחון ארגוני לפני שתיגע בליבה המסוכנת. המפה אינה רק ביטוח מפני כשל ה-TRN-LIMIT. היא תוכנית הרצף.
בנינו את כל זה — גרף ידע התלות, רצף התאנה החונקת, מערך בדיקות השקילות ההתנהגותית, במכוון ללא תלות בכל פלטפורמת יעד — לתוך תחום העיסוק של Veriprajna במודרניזציה של COBOL מדור קודם, המכוון ישירות לבנקים ולמבטחים מדרג-הביניים שהשחקנים המבוססים עם רצפת ה-2 מיליון דולר ואינטגרטורי המערכות בעלי המחירים בני שבע הספרות מתייחסים אליהם כקטנים מכדי לטרוח בהם.
על מה אני כן ישר
לא אעמיד פנים שהטכנולוגיה פותרת הכול, כי הכשלים היקרים ביותר שראיתי לא היו טכניים כלל.
שום כלי — כולל שלנו — אינו מתקן את ההסכמה הארגונית, מנקה שנים של נתונים גרועים, או מנצח את המאבק הפוליטי של שכנוע מאתיים מפתחים לשנות את אופן עבודתם. השוק צפוי לצמוח מכ-9 מיליארד דולר ב-2026 לכפול מכך עד סוף העשור בדיוק מכיוון שכל כך הרבה מההוצאה הולכת לשכבה האנושית והארגונית, לא למהדר. ואף מנתח (parser) עלי אדמות, בקוד פתוח או מסחרי, אינו מכסה באופן מושלם כל מבנה ב-IBM Enterprise COBOL — פקודות ה-ALTER שמלפני 1985, ה-REDEFINES העמוקים ביותר. כל מי שאומר לך אחרת מוכר לך את הפער. הטכנולוגיה הכרחית. היא מעולם לא הייתה מספקת.
אבל החלק שהטכנולוגיה כן יכולה לקחת עליו בעלות, עליה לקחת עליו בעלות מלאה. הסיבה שהגירות שורפות מיליונים ואינן מספקות דבר היא לעתים רחוקות שמישהו כתב Java גרועה. אלא שהם תרגמו מערכת שמעולם לא מיפו באמת — תוך המרת חוטים של רשת בעוד הרשת עצמה נותרה בלתי נראית עד הלילה שבו נקרעה.
שרטט את המפה תחילה. מערכת ששרדה את האנשים שכתבו אותה אינה סולחת על תלות שהוחמצה, ואין גרסה של עבודה זו שבטוחה לפני שאתה יכול לראות מה מתחבר למה. למדנו זאת מפנקס שהתמוטט בגלל שדה packed-decimal בודד שאיש לא ידע שהוא שם. מצא את השדות האלה לפני שהם ימצאו אותך.
