שינוי פלטפורמה או תכנון מחדש? כיצד לבחור את נתיב המודרניזציה הנכון עבור COBOL מדור קודם

שני ארגונים עם תיקי COBOL בגודל דומה מקבלים החלטות מודרניזציה שונות. ארגון אחד מבצע שינוי פלטפורמה: מעביר תוכניות COBOL לתשתית ענן באמצעות AWS Mainframe Modernization או שכבת אמולציה של COBOL, תוך שמירה על הקוד תוך ביטול המיינפריים הפיזי. תוך שמונה עשר חודשים הם קיצצו את עלויות התשתית ב-40% והתוכנית נחשבת להצלחה. הארגון השני מנסה את אותה גישה, נתקל בקיר לאחר שנים עשר חודשים, ועובר לשינוי מבנה, תוך בנייה מחדש של התוכניות הקריטיות ביותר כמיקרו-שירותי Java. עלות השינוי כפולה מהתקציב המקורי ואורכת שלוש שנים נוספות.

אותה נקודת התחלה. תוצאות שונות באופן קיצוני. ההבדל לא היה הכלים, הספקים או הצוותים. ההבדל היה שהארגון השני בחר בפלטפורמה מחדש עבור מערכות שהיו להן אילוצים אדריכליים שהפלטפורמה החדשה לא יכלה להתאים להם, תלות בעסקות CICS, מבני קבצים VSAM ודרישות בזמן אמת שהקוד שעבר הפלטפורמה מחדש לא יכול היה לעמוד בהן ללא עיצוב מחדש יסודי. ההחלטה התקבלה לפני שמישהו הבין את המערכות מספיק טוב כדי לבצע אותה נכון.

מה המשמעות של כל נתיב בפועל עבור COBOL

ההגדרות הגנריות ידועות היטב. מה שחשוב הוא מה המשמעות של כל נתיב באופן ספציפי עבור תוכניות COBOL, שבהן הארכיטקטורה, מודל הביצוע ומבני הנתונים שונים מיישומים מודרניים בדרכים המשפיעות ישירות על איזה נתיב בר-קיימא.

הפיכת COBOL לפלטפורמה מחדש

שינוי פלטפורמה (replatforming) מעביר תוכניות COBOL לסביבת הפעלה חדשה, בדרך כלל תשתית ענן, תוך שמירה על הקוד ברובו ללא שינוי. ה-COBOL מתקמפל ופועל על הפלטפורמה החדשה, בין אם באופן מקורי (באמצעות מהדר COBOL של IBM בלינוקס) או באמצעות שכבת אמולציה שמיירטת קריאות ספציפיות למיינפריים (CICS, VSAM, JES) ומתרגמת אותן למקבילות מקוריות לענן.

מה ששומר על עיבוד פלטפורמות:

• קוד המקור של COBOL
• הלוגיקה, החישובים וכללי העסק של התוכנית
• מודל ביצוע אצווה (לולאות PERFORM, עיבוד קבצים סדרתי)
• מבני הנתונים (פריסות רשומות, הגדרות ספר עותקים)
• מבנה משימות JCL (נכתב מחדש עבור המתזמן החדש, אך שווה ערך לוגית)

אילו שינויים בעיצוב מחדש של הפלטפורמה:

• התשתית הפיזית (z/OS → לינוקס בענן)
• תת-מערכת קלט/פלט (VSAM → אחסון קבצים מנוהל או מסד נתונים, בהתאם לכלי)
• מתזמן המשימות (JES2/JES3 → AWS Batch, Azure Logic Apps, או שווה ערך)
• מודל העלות (חיוב מבוסס MIPS → חיוב ענן מבוסס צריכה)

מסקנה עיקרית: שינוי פלטפורמה נכון כאשר הבעיה היא הפלטפורמה, עלות הפעלת z/OS, תלות התשתית, מודל החיוב של MIPS. זוהי הדרך הלא נכונה כאשר הבעיה היא הקוד או הארכיטקטורה.

תכנון מחדש של COBOL

אדריכלות מחדש משנה את העיצוב הבסיסי של המערכת. הלוגיקה העסקית נשמרת, או נגזרת מחדש ממקור COBOL, אך היא מיושמת בשפה חדשה, עם מודל ביצוע חדש, כנגד שכבת נתונים חדשה. התוצאה היא מערכת שעושה את מה ש-COBOL עשה אך אינה דומה ל-COBOL במבנה.

אילו שינויים בתכנון מחדש:

• שפת התכנות (COBOL → Java, Python, Go, C#)
• מודל הביצוע (אצווה → מונחה אירועים, סטרימינג או מבוסס API)
• שכבת הנתונים (קבצי VSAM → מסד נתונים יחסי, NoSQL, אחסון ענן-מקורי)
• מודל העסקה (CICS פסאודו-שיחתי → שירותים חסרי מצב RESTful)
• דפוס האינטגרציה (מערכי נתונים משותפים → חוזי API, תורי הודעות)

מה שתכנון מחדש חייב לשמר:

• כל כלל עסקי ש-COBOL מיישם, כולל מקרי קצה לא מתועדים
• כל חישוב, כולל מאפייני הדיוק המספרי של חשבון עשרוני ארוז
• כל טרנספורמציה של נתונים, כולל המרות מרומזות במשפטי MOVE
• כל מצב שגיאה, כולל קודי FILE STATUS הספציפיים והתנהגויות abend שמערכות במורד הזרם עשויות להסתמך עליהם.

שימו לב: מצב הכשל הנפוץ ביותר בארכיטקטורה מחדש הוא גילוי ש-COBOL מכיל כללים עסקיים שמעולם לא נכתבו בשום מקום אחר. המערכת החדשה מתנהגת בצורה שונה מהישנה במקרי קצה ספציפיים, לא בגלל שגיאת יישום, אלא משום שהמפרט לא היה שלם. יש לחלץ ולתעד לוגיקה עסקית ממקור COBOL לפני תחילת הארכיטקטורה מחדש.

הגורמים הספציפיים ל-COBOL שמשנים החלטה זו

מסגרות מודרניזציה גנריות מתייחסות לשינוי פלטפורמה ועיצוב מחדש כהחלטות הנוגעות בעיקר לעלות, לוח זמנים וסיכון. עבור COBOL, מספר גורמים טכניים ספציפיים לשפה ולסביבת זמן הריצה שלה דוחפים את ההחלטה חזק לכיוון אחד או אחר.

תלויות עסקאות CICS

CICS (מערכת בקרת מידע לקוח) היא תוכנת ביניים לעיבוד טרנזקציות בה משתמשות תוכניות COBOL רבות עבור עומסי עבודה אינטראקטיביים. תוכנית COBOL שמבצעת קריאות EXEC CICS קיימת תלות מרומזת בשרת הטרנזקציות של CICS לצורך ניהול מסכים, תקשורת מסוף, שיגור משימות ובקרת תוכניות.

השלכות של שינוי פלטפורמה: כלים כמו אמולציית Micro Focus CICS, OpenFrame, וכמה תכונות של AWS Mainframe Modernization מחקות סמנטיקה של CICS. אם השימוש ב-CICS סטנדרטי ומתנהל היטב, האמולציה עשויה לעבוד. אם התוכנית מסתמכת על רכיבים פנימיים של CICS, מניפולציה של commarea, בקרת נקודת סינכרון ואחסון ברמת המשימה, איכות האמולציה פוחתת.

השלכת אדריכלות מחדש: תוכנית CICS שהומרה ל-REST API חייבת לקבל עיצוב מחדש של מודל העסקאות הפסאודו-שיחתיות שלה כאינטראקציות חסרות מצב. זהו שינוי ארכיטקטוני, לא תרגום קוד.

דוחף אותות לכיוון אדריכלות מחדש: שימוש רב ב-CICS עם טיפול מורכב ב-commarea, שרשור טרנזקציות אחורי או לוגיקת נקודות סינכרון.

ארכיטקטורת קבצי VSAM

VSAM (Virtual Storage Access Method) היא מערכת הקבצים המאונדקסת המשמשת את רוב תוכנות הייצור של COBOL. לקבצי VSAM יש דפוסי גישה ספציפיים, KSDS keyed sequential, ESDS entry-sequence, ו-RRDS relative record, שאין להם מקבילות ישירות באחסון ענן-מקורי.

השלכת הפלטפורמה מחדש: שכבות אמולציה מתרגמות קריאות וכתיבות של VSAM לפעולות קבצים או מסד נתונים בסיסיים. עבור גישה פשוטה, סדרתית או מבוססת מפתח, זה עובד. עבור גישה מורכבת של מפתחות חלופיים, אשכולות VSAM המשותפים על פני מספר תוכניות, או דפוסי גישה אקראית רגישות לביצועים, האמולציה מוסיפה השהייה ומורכבות.

השלכות של אדריכלות מחדש: החלפת VSAM במסד נתונים יחסי דורשת מיפוי פריסות רשומות לסכמות טבלאות, טיפול בהמרות סוגי נתונים מרומזות וכתיבה מחדש של כל גישה לקובץ לשימוש ב-SQL או ב-ORM.

אותות דוחפים לכיוון אדריכלות מחדש: קבצי VSAM המשותפים בין תוכניות רבות, דפוסי גישה חלופיים לאינדקסים או דרישות ביצועים בזמן אמת שהאמולציה אינה יכולה לעמוד בהן.

דרישות אצווה לעומת דרישות זמן אמת

תוכניות אצווה של COBOL נועדו לעבד כמויות גדולות של רשומות ברצף בחלונות מתוזמנים. מערכות רבות של בנקים, ביטוח וממשל עדיין מפעילות עבודות אצווה בן לילה שמעבדות מיליוני עסקאות, מייצרות דוחות ומעדכנות קבצי אב.

השלכות של שינוי פלטפורמה: סמנטיקה של אצווה מתורגמת היטב לביצוע אצווה בענן (AWS Batch, Azure Batch). מודל העיבוד הרציף שורד את שינוי הפלטפורמה. אם הדרישה היא פשוט להריץ את אותה משימת אצווה על תשתית זולה יותר, שינוי פלטפורמה מטפל בכך ישירות.

השלכות של אדריכלות מחדש: אם דרישת העסק השתנתה, מעיבוד אצווה בן לילה לעיבוד כמעט בזמן אמת, מחילופי קבצים לאינטגרציה של API, מהרצות אצווה מונוליטיות למיקרו-שירותים המופעלים בנפרד, עיבוד מחדש של הפלטפורמה לא יוכל לספק את הדרישה החדשה. הארכיטקטורה חייבת להשתנות.

איתות דוחף לכיוון אדריכלות מחדש: דרישות בעלי עניין לעיבוד בזמן אמת, אינטגרציה מבוססת API, ארכיטקטורה מונעת אירועים או זמני תגובה של פחות משנייה שסמנטיקה של אצווה אינה יכולה לספק.

לוגיקה עסקית משובצת ללא מפרט חיצוני

זהו הגורם הספציפי ל-COBOL שאינו מוערך מספיק. הסיכונים העיקריים כוללים אובדן של כללי עסקיים קריטיים המוטמעים בקוד בן עשרות שנים ותיעוד לא מספק של התנהגות המערכת. תוכניות COBOL מכילות לעתים קרובות את המפרט היחיד ששרד של כלל עסקי. התקנה שדרשה חישוב ספציפי נכתבה בשנת 1983. האנליסט העסקי שהבין אותה פרש בשנת 2001. קוד COBOL אינו רק יישום, הוא התיעוד.

השלכת שינוי פלטפורמה: כללי העסק שורדים בשלמותם מכיוון שהקוד נשמר. זהו אחד הטיעונים החזקים ביותר של שינוי פלטפורמה.

השלכה של אדריכלות מחדש: יש לחלץ את כללי העסק ממקור COBOL לפני יישום מחדש. <cite index="28-1">קוד לא מתועד ומחובר היטב מכפיל את המאמץ בכל שלב.</cite> אם חילוץ זה אינו שלם, למערכת החדשה יש מפרט שונה מהישן, וההבדלים הללו צפים בתהליך הייצור.

מסגרת קבלת החלטות: שמונה שאלות

לפני שבוחרים נתיב, שמונה השאלות הללו מייצרות את הראיות הדרושות כדי לקבל את ההחלטה בביטחון ולא בהנחות.

1. מהו המניע העיקרי למודרניזציה זו?

• עלות תשתית → מספיקה הפלטפורמה מחדש
• תלות בפלטפורמה (z/OS) → חידוש פלטפורמה מספיק
• דרישות בזמן אמת → נדרשת תכנון מחדש
• דרישות אינטגרציה (API) → סביר להניח שנדרשת תכנון מחדש
• תחזוקה / זמינות כישרונות → תכנון מחדש או שיפוץ

2. מהי רמת הצימוד של CICS? מנה כל קריאה ל-EXEC CICS. מנה של תוכניות עם יותר מעשרים פקודות CICS שונות. תוכניות עם צימוד CICS כבד הן מועמדות גרוע לעיצוב מחדש אם נאמנות האמולציה אינה ודאית.

3. מהם דפוסי הגישה של VSAM? זהו תוכניות הניגשות לקבצי VSAM באמצעות מפתחות חלופיים, אשכולות משותפים או גישה אקראית תלוית ביצועים. אלו הם אינדיקטורים לסיכון לפלטפורמה מחדש.

4. האם הלוגיקה העסקית תועדה חיצונית? אם מקור ה-COBOL הוא המפרט הסמכותי היחיד, תכנון מחדש דורש חילוץ לוגיקה עסקית כשלב מוקדם, ולא עומס עבודה מקביל.

5. מהי סבילות חלון העיבוד (batch)? אם העסק דורש את אותו מודל עיבוד עיבוד (batch processing) בעלות נמוכה יותר, יש לעצב מחדש את הפלטפורמה. אם העסק דורש את אותו עיבוד שיהיה זמין בזמן אמת, יש לעצב מחדש את הפלטפורמה.

6. מהי מורכבות התלות? תוכנית עם חמישים תלויות במורד הזרם, מערכי נתונים, הנקראים תת-תוכניות, קוראים ל-JCL, נושאת סיכון גבוה יותר בבנייה מחדש מאשר כלי עזר עצמאי. מבנה התלות קובע את רצף ההגירה ואת היקף הבדיקה.

7. איזה אחוז מהקוד מת? קוד מת שאינו נכלל בטווח לפני כל המרה מפחית את המאמץ עבור שני הנתיבים. עבור תוכניות בעיצוב מחדש, קוד מת שאינו נכלל מומר בעלות מלאה ולאחר מכן נזרק.

8. מהי התפלגות המורכבות? מורכבות ציקלומטית מעל 50 לכל תוכנית, או יותר מעשרים ספרי עותקים כלולים, מצביעה על תוכניות יקרות מבחינת תכנון מחדש ומסוכנות מבחינת הפלטפורמה מחדש. אלה מצדיקים תשומת לב אישית ולא הקצאת נתיבים בכמות גדולה.

יישום המסגרת: ארבעה פרופילי מערכת COBOL

פּרוֹפִיל	מאפיינים	נתיב מומלץ	רציונל
כלי אצווה יציב	קלט/פלט של קבצים סדרתיים, ללא CICS, לוגיקה מתועדת היטב, מורכבות נמוכה	פלטפורמה מחדש	עלות הפלטפורמה היא הבעיה; קוד אינו המגבלה
עסקאות מקוונות עתירות CICS	שימוש רב ב-EXEC CICS, תלויות commarea, מודל פסאודו-שיחתי	אדריכל מחדש	הסיכון באמולציית CICS גבוה; דרישות בזמן אמת צפויות
מעבד קבצי אב של VSAM	דפוסי גישה מורכבים של VSAM, משותפים בין תוכניות רבות, נפח קריאה גבוה	הערך תחילה את נאמנות האמולציה; הפוך את הפלטפורמה לפלטפורמה מחדש אם האמולציה תקפה	אמולציית VSAM היא משתנה ההחלטה
אוצר לוגיקה עסקית	כללים לא מתועדים, ללא מפרט חיצוני, משמעות רגולטורית גבוהה	תחילה חלץ את הלוגיקה, לאחר מכן בחר	סיכון אדריכלי מחדש אינו מקובל ללא חילוץ מוקדם של לוגיקה עסקית

מסקנה עיקרית: <cite index="30-1">בפועל, מערכות גדולות משלבות גישות: שינוי פלטפורמה של החלקים היציבים, שינוי פקטור של הקוד שקשה לתחזק, כתיבה מחדש של קומץ המערכות הזקוקות ליכולות חדשות, והוצאת מה שכבר לא בשימוש.</cite> ההחלטה אינה ברמת תיק העבודות, אלא ברמת עומס העבודה, המיושמת באופן פרטני לכל תוכנית או קבוצת תוכניות בהתבסס על הראיות.

הגישה ההיברידית: תחילה תכנון מחדש של הפלטפורמה, תכנון מחדש היכן שצריך

כלל מעשי: אירוח מחדש או שינוי פלטפורמה כדי לעצור את הדימום במהירות, לאחר מכן תכנון מחדש או תכנון מחדש של המערכות שהן בידול תחרותי אמיתי.

עבור רוב הארגונים עם תיקי COBOL גדולים, הרצף המעשי הוא:

שלב 1, הפיכת פלטפורמה מחדש של המועמדים הברורים. תוכניות ללא CICS, קלט/פלט סדרתי פשוט, לוגיקה מתועדת ומורכבות נמוכה יכולות להיבנות מחדש עם מאמץ וסיכון צפויים. זה מספק הפחתה מהירה של עלויות התשתית ובונה ביטחון ארגוני.

שלב 2, הערכת תוכניות מורכבות. תוכניות עם צימוד CICS, דפוסי VSAM מורכבים או לוגיקה עסקית לא מתועדת דורשות ניתוח פרטני לפני בחירת נתיב. כאן חילוץ לוגיקה עסקית וניתוח מבני קובעים האם תכנון מחדש נחוץ ומה יהיה היקף התכנון.

שלב 3, ארכיטקטורה מחדש של התוכניות עם חוסמי ארכיטקטורה. תוכניות שאינן יכולות לעמוד בדרישות העסקיות של התשתית שעברה פלטפורמה מחדש, דרישות זמן אמת, שילוב API, ועיבוד מונחה אירועים, מתוכננות מחדש באמצעות תבנית Strangler Fig: בניית השירות החדש לצד התוכנית שעברה פלטפורמה מחדש, ניתוב התנועה בהדרגה למימוש החדש ככל שכל רכיב עובר אימות, והוצאת התוכנית הישנה משימוש כאשר כל התעבורה הועברה.

שלב 4, הוצאת קוד מת. תוכניות שזוהו כמתות במהלך ניתוח מבני אינן נכללות בשני המסלולים ומוצאות משימוש, מה שמפחית את עלויות התחזוקה השוטפות ללא כל מאמץ המרה.

---

מה הניתוח חייב להניב לפני קבלת כל החלטה

מסגרת ההחלטות הנ"ל מניבה תשובות טובות יותר כאשר התשומות הן ראיות ולא הערכות. הניתוח המבני המספק תשומות אלו דורש ניתוח של קוד המקור בפועל של COBOL במקום להסתמך על תיעוד או ידע של מפתחים.

מה הניתוח חייב לקבוע עבור כל תוכנית:

מלאי תוכנות מלא הכולל תוכנות שהתיעוד אינו מתחשב בהן. בסביבות COBOL גדולות, ספירת התוכנות הלא מתועדות עולה לרוב על 20% מהסך הכל. גרף תלות המציג אילו תוכנות קוראות לאילו אחרות, אילו מערכי נתונים משותפים, אילו עבודות JCL קוראות לאילו תוכנות. מלאי פקודות CICS עבור כל תוכנה, הספירה, הסוגים ומורכבות הקריאות. ניתוח תבניות גישה VSAM, אילו שיטות גישה, אילו קבצים משותפים בין תוכנות, אילו קבצים בעלי אינדקסים חלופיים. התפלגות מורכבות ציקלומטית, אילו תוכנות פשוטות מבחינה מבנית ואילו מועמדים בסיכון גבוה לכל המרה. זיהוי קוד מת, אילו תוכנות ופסקאות אין להן נתיבי ביצוע נכנסים. חילוץ לוגיקה עסקית, אילו כללים כל תוכנה מיישמת, בצורה שניתן להשתמש בה כדי לאמת את הפלט של כל אחד מהנתיבים.

ללא מלאי זה, החלטת הנתיב מתקבלת על סמך מידע חלקי. תוכניות מוקצות לפלטפורמה מחדש על סמך הנחות שמתבררות כשגויות כאשר האמולציה מגלה אילוצים אדריכליים שלא היו גלויים במהלך התכנון.

איך SMART TS XL מייצר את הראיות טרום-החלטה

SMART TS XL"S מודרניזציה מורשת ניתוח זה מבצע אוטומציה של המלאי המבני שתואר לעיל, ומנתח בו זמנית כל תוכנית COBOL, ספר עותקים, משימת JCL והפניה לקובץ VSAM כדי לבנות את מודל התלות המאוחד שהופך את החלטת הנתיב למבוססת ראיות.

מיפוי תלות האפליקציה מייצר את גרף הקריאה בין-תוכניות ואת מפת שיתוף מערכי הנתונים שקובעת את מורכבות התלות, הגורם שמשפיע בצורה הישירה ביותר הן על הסיכון של אמולציית פלטפורמה מחדש והן על היקף ורצף התכנון מחדש.

ניתוח הקוד הסטטי מייצר מדדי מורכבות, מלאי קריאות CICS וזיהוי קוד מת עבור כל תוכנית בתיק. תוכניות מעל סף המורכבות הציקלומטית ועם צימוד CICS כבד מוצגות אוטומטית כמועמדות לתכנון מחדש או הערכה במקום להקצות אותן בכמות גדולה לעיצוב מחדש של הפלטפורמה.

הרחבת JCL פותרת פרמטרים סמליים ובונה את שרשרת התלות המלאה של ביצוע האצווה, אילו עבודות JCL מפעילות אילו תוכניות, באיזה רצף, עם אילו מערכי נתונים, ומספקת את ההקשר התפעולי שקובע כיצד הפלט של כל נתיב חייב להתנהג כדי לעמוד בלוח הזמנים של האצווה.

יכולת ניתוח ההשפעה הופכת את היקף כל נתיב לקונקרטי עוד לפני תחילת התוכנית: עבור כל תוכנית שנבחרה לתכנון מחדש, ניתוח ההשפעה מונה כל תוכנית תלויה שיש לעדכן, לבדוק מחדש או לתאם עם הרכיב שעוצב מחדש. עבור מועמדים לתכנון מחדש, אותו ניתוח מזהה אילו מערכי נתונים משותפים ותתי-תוכניות משותפות יוצרים תלויות בין-תוכניות שיש לטפל בהן באופן עקבי.

חיפוש הארגון מאפשר שאילתה על כל המלאי לאורך כל התוכנית: מצא כל תוכנית המשתמשת בפקודה ספציפית של CICS, כל תוכנית הניגשת לאשכול VSAM ספציפי, כל ספר עותקים שמגדיר מבנה נתונים ספציפי, תוך שניות, על פני מיליוני שורות של COBOL.

הארגונים שמקבלים את ההחלטה הזו בצורה נכונה הם אלה שמקבלים אותה על סמך ראיות מבניות ולא על סמך הנחות תכנון הפרויקט. הראיות המבניות הן מה SMART TS XL מייצר.