ترحيل COBOL الذي جرى تصريفه بإتقان — ومع ذلك أفسد دفتر الأستاذ

كان الكود مثاليًا. وتلك كانت المشكلة برمّتها.

كان قد جرى تحويل برنامج للتحويلات المصرفية (wire-transfer) من COBOL إلى Java. جرى تصريفه بنجاح. ونجحت اختبارات الوحدة. واجتاز كل بوابة بنيناها لالتقاط الأخطاء. ثم، في اختبار قبول المستخدم، أطاحت أول معاملة على الإطلاق بفحص الاتساق في قاعدة البيانات، وانهار كل شيء.

استغرق التشريح وقتًا أطول مما ينبغي، لأن لا شيء في Java كان يبدو خاطئًا. كان المتسبّب متغيّرًا اسمه TRN-LIMIT. قرأته أداة الترجمة على أنه رقم عادي وأعطته نوعًا صحيحًا قياسيًا (integer). لكن TRN-LIMIT لم يكن مُعرَّفًا قط في الموضع الذي كانت الأداة تنظر فيه. لقد أُعلِن في نسخة copybook — ملف ترويسة مشترك — مُدرَجة قبل آلاف الأسطر في سلسلة التنفيذ، وكانت نسخة الـ copybook تلك تحمل عبارة REDEFINES: بنية في COBOL تتيح قراءة الخانة نفسها من الذاكرة كنوعين مختلفين تمامًا من البيانات تبعًا لعَلَم مضبوط في مكان آخر تمامًا. على الحاسوب المركزي (mainframe)، كان ذلك العنوان يحمل قيمة عشرية محزومة (packed decimal). فكتب كود Java الجديد بيانات ثنائية تالفة في عمود قاعدة البيانات، وانهارت السلامة المرجعية لدفتر الأستاذ.

كان الكود سليمًا نحويًا تمامًا. أما الفشل فكان سياقيًا. لقد أغفلت الأداة تبعية تعيش خارج مجال رؤيتها — وفي تحديث COBOL القديم، هكذا يتبخّر المال دائمًا تقريبًا.

مشاريع التحديث لا تموت عادةً بسبب الكود الذي تراه. بل تموت بسبب الكود الذي لم تستطع الأداة رؤيته.

هذه قصة سبب توقّفي عن الإيمان بأن الترجمة الأفضل هي الحل، وما بنيناه في Veriprajna بدلاً من ذلك.

لماذا يبدو عرض «الصق COBOL، واحصل على Java» ناجحًا دائمًا؟

إن كنت قد حضرت أي اجتماع لتحديث الحاسوب المركزي في العامين الماضيين، فقد سمعت العرض الترويجي: الصق COBOL الخاص بك، واحصل على Java. إنه مغرٍ لأن العرض التوضيحي ينجح دائمًا. يُدخِل أحدهم برنامجًا أنيقًا من 200 سطر، فيُعيد النموذج كود Java نظيفًا واصطلاحيًا، ويتنفّس الجميع في الغرفة الصعداء. أخيرًا.

صدّقته أنا أيضًا لفترة. حين تصدّى فريقي لهذا أول مرة، فعلنا الأمر البديهي — حاولنا جعل الترجمة أفضل. غذّينا النماذج بمزيد من السياق، وضبطناها لخصائص COBOL الغريبة، وقِسنا جودة المُخرَجات. بل هناك نموذج مفتوح مضبوط بدقة اسمه XMainframe، مبني خصيصًا لهذا، يسجّل نحو 30% أعلى من نماذج الكود العامة في مهام COBOL. صارت الترجمات أنظف. وصار Java أكثر قابلية للقراءة.

ومع ذلك ظل ينهار في اختبار قبول المستخدم. مرارًا وتكرارًا، على النوع نفسه بالضبط من التبعية الخفية التي أغرقت برنامج التحويلات المصرفية. كان ذلك هو الشهر الذي أدركت فيه أننا نصقل الشيء الخطأ. لم تكن جودة الترجمة قطّ هي عنق الزجاجة. الكود الذي جرى تصريفه بنجاح هو الجزء السهل. الجزء الصعب هو الكود الذي لا تستطيع الأداة رؤيته.

الأرقام حول هذا قاسية ومتّسقة: من 70 إلى 80% من مشاريع تحديث الحاسوب المركزي تفشل في تحقيق أهدافها. ليس أن 70% تتأخر — بل 70% تفشل. يُلقي التشخيص المعتاد اللوم على الاستهانة بالاختبار أو فوضى ترحيل البيانات، وهما حقيقيان. لكن تحت جميعها تقريبًا السبب الجذري نفسه الذي شاهدته للتو مباشرةً: تتعامل الأدوات مع قاعدة الكود كنصّ يُحوَّل، بينما هي في الواقع طوبولوجيا يجب فهمها.

ما الذي لا يستطيع «الصق COBOL، واحصل على Java» رؤيته

بمجرد أن تبدأ بالبحث عن العمى السياقي، تراه في كل مكان. ثلاثة أنماط أعطبتنا أكثر من غيرها، وليس أيٌّ منها مرئيًا في الملف المصدري الذي يحدّق فيه المترجِم.

ابدأ بمشكلة الـ copybook التي وصفتها للتو. يمكن لبرنامج COBOL واحد أن يشير إلى أكثر من أربعين نسخة copybook، وتلك النسخ تتضمّن بدورها غيرها من نسخ الـ copybook، فقد يقع التعريف الحقيقي للمتغيّر على عمق عدة مستويات في سلسلة التضمين. تقرأ الأداة النصية العبارة التي أمامها وتستنتج نوعًا. وليس لديها أي وسيلة لتعرف أن هذا الاستنتاج، في حقل عشري محزوم، خاطئ بصمت.

ثم يأتي الحساب. فالعشري المحزوم من النوع COMP-3 في COBOL لا مكافئ أصلي له في Java. فإذا لجأت إلى double تكون قد أدخلت للتوّ تقريب الفاصلة العائمة إلى نظام ينقل الأموال. وحتى BigDecimal، وهي الأداة الصحيحة، لا تطابق COBOL افتراضيًا — إذ عليك أن تثبّت صراحةً وضع التقريب فيها على HALF_EVEN لتحاكي عبارة ROUNDED الخاصة بـ COBOL. فإن أخطأت، انحرفت بمقدار سنت واحد لكل معاملة. ويتراكم ذلك السنت عبر ملايين المعاملات حتى، بعد أسابيع، يُظهِر تقرير تسوية فرقًا لا يستطيع أحد تفسيره.

النمط الذي ينساه الجميع تقريبًا هو النمط الذي يُسقِط الإنتاج فعلاً: كود COBOL لديك لا يعمل بمفرده. فمُجدوِل — CA-7 أو TWS — يُنسّق ما بين ألفَي وخمسة آلاف مهمة دفعية (batch)، بسلاسل تبعية متشابكة عبرها. تكتب المهمة A مجموعة بيانات في الساعة الواحدة صباحًا تقرأها المهمة B في الساعة الثانية صباحًا. يمكنك ترحيل كل سطر من COBOL بلا عيب وتُسقِط البنك مع ذلك عند منتصف الليل، لأن لا أحد رسم خريطة شبكة المهام. لم يكن مخطّط الإنتاج موجودًا قطّ في الكود المصدري. كان في JCL.

المهمة التي تُعطِب الإنتاج في الساعة الثانية صباحًا ليست أبدًا تلك التي كنت تنظر إليها.

هذا ما أعنيه بالطوبولوجيا. فالكيان الذي يُشغّل عملك فعلاً هو شبكة من العلاقات — برامج، ونسخ copybook، ومجموعات بيانات، ومهام مجدولة، وجداول DB2، ومعاملات CICS — وما شيفرة COBOL المصدرية إلا خيط واحد منها.

لماذا توقّفت عن الثقة بالمترجِم وبدأت أرسم الخريطة

كانت نقطة التحوّل بالنسبة لنا هي قرارنا أن الخريطة هي المنتج.

قبل أن نترجم سطرًا واحدًا، نبني رسمًا بيانيًا معرفيًا لقاعدة الكود بأكملها — كل برنامج، وكل حافة copybook، وكل تبعية JCL، وكل تسليم لمجموعة بيانات، وكل نقطة تماس مع DB2 — ونحلّ العلاقات المتعدّية التي تخفيها الملفات المصدرية. حين تستطيع أن ترى أن برنامجًا واحدًا لديه أكثر من أربعين حافة copybook، وأن إحداها تحمل عبارة REDEFINES على بُعد وحدتين، فإن كارثة TRN-LIMIT ببساطة لا تحدث، لأنك عرفت أن الحقل عشري محزوم قبل أن تكتب حرفًا واحدًا من Java.

أريد أن أكون دقيقًا في سبب اختلاف هذا عمّا يبيعه بقية المجال، لأن المجال مزدحم ومعظمه جيد فعلاً في الجزء الذي يحلّه.

إن watsonx Code Assistant for Z من IBM هو المنافس الأعرق الأكثر جدية — نظام وكيلي (agentic)، بوكلاء للتنسيق والبنية والكود، يتعامل مع تحويل COBOL إلى Java، بل حتى PL/I وIMS، ويحلّل استهلاك المعالج وصولاً إلى داخل نسخ الـ copybook. لكنه أيضًا التزام يتجاوز مليونَي دولار يعمل على z/OS ويعتمد على أدوات ADDI من IBM، التي تقيّدك بهدوء بالحاسوب المركزي أثناء عملية الترحيل التي يُفترض أن تحرّرك منه. وهو لا يُجري اختبار التكافؤ السلوكي، ولا يرسم خريطة شبكة مهام JCL لديك.

ثم تأتي اللحظة التي أعادت تشكيل السوق بأكمله. في فبراير 2026، نشرت Anthropic دليلًا عمليًا لتحديث COBOL باستخدام Claude Code؛ وهبط سهم IBM بنسبة 13.2% يوم الإعلان، وتبعتها شبكة شركاء بقيمة 100 مليون دولار في مارس. إن Claude Code ممتاز في الاستكشاف والتوثيق وقراءة الكود غير المألوف — مفيد حقًا في المراحل المبكرة. لكنه أداة عامة الغرض. ليس لديه رسم بياني معرفي مدمج لحلّ التبعيات المتعدّية، وهو لا يدّعي أنه يحلّ جدولة JCL، أو التكافؤ السلوكي، أو مسارات التدقيق التي يجب على بنك خاضع للتنظيم أن ينتجها.

يستهدف مصنع الترحيل Azure من Microsoft منصة Java Quarkus ويقيّد منصتك الهدف بـ Azure. أما كبار مُكامِلي الأنظمة — DXC بمحرّك التحويل الحاصل على براءة اختراع، وTCS بأداة MasterCraft، وInfosys بأداة Cobalt، وAccenture — فيديرون مشاريع تتراوح من 500 ألف إلى أكثر من 5 ملايين دولار وينفّذون أدوات موردين بدلاً من بناء فهم ذكي حول النظام الخاص بك؛ فقد قادت Accenture عملية ترحيل نواة بنك الكومنولث الأسترالي التي بلغت نحو 749.9 مليون دولار واستغرقت خمس سنوات. أما Visual COBOL من Micro Focus، التي كثيرًا ما تُطرح كنقطة بداية، فليست تحديثًا على الإطلاق — إنها إعادة استضافة. يبقى COBOL لديك COBOL، لكن على بيئة تشغيل جديدة فحسب. أما الدَّين التقني ومشكلة القوى العاملة فيبقيان تمامًا حيث تركتهما.

كل واحدة من هذه يفعل شيئًا حقيقيًا. لكن ما لا تفعله أيٌّ منها هو بناء طوبولوجيا التبعيات الكاملة — JCL وCICS وDB2 والـ copybooks وكل شيء — أولاً، بمعزل عن أي منصة هدف، ومعاملة تلك الخريطة كأساس يقوم عليه كل شيء آخر.

معظم الموردين يبيعونك مترجِمًا أفضل. لكن الترجمة لم تكن قطّ الجزء الذي فشل.

الساعة التي لا يستطيع أحد إيقافها

وهنا الجزء الذي يحوّل هذا من مشكلة هندسية إلى حالة طوارئ.

الأشخاص الذين يفهمون هذه الأنظمة يرحلون. متوسط عمر مطوّر COBOL في الولايات المتحدة نحو 55 عامًا. ويتقاعد نحو 10% من تلك القوى العاملة كل عام، وقد أسقطت 85% من الجامعات COBOL من المناهج في تسعينيات القرن الماضي، فلا أحد تقريبًا يحلّ محلّهم. ويقول ستون بالمئة من المؤسسات الآن إن إيجاد مطوّري COBOL المهرة هو أكبر تحدٍّ منفرد يواجه تحديثها — و58% من المطوّرين الذين ما زالوا يعرفون هذه الأنظمة يقولون إنهم يفكّرون في الاستقالة بسببها.

لقد وقفت عند النسخة من هذا التي تطاردني: حفل تقاعد الشخص الوحيد الذي فهم فعلاً نافذة المعالجة الدفعية (batch window). الجميع يبتسمون، وهناك كعكة، وفي مؤخّرة رأسي صوت يقول إن تلك المعرفة قد خرجت للتوّ من الباب، وهي غير مدوّنة في أي مكان. والرسم البياني المعرفي هو، من بين أمور أخرى، وسيلة لالتقاط ما في رأس ذلك الشخص قبل الحفل — لجعل خريطة التبعيات تعيش أطول من الأشخاص الذين حفظوها.

والمخاطر ليست صغيرة ولا مجرّدة. فلا يزال نحو 220 مليار سطر من COBOL في الإنتاج الفعّال. وهو يشغّل 95% من معاملات أجهزة الصرّاف الآلي ويقاصّ نحو 3 تريليونات دولار يوميًا. وثلاثة وأربعون بالمئة من الأنظمة المصرفية مبنية عليه. ويُقدَّر الدَّين التقني في الولايات المتحدة بنحو 1.52 تريليون دولار، وتحرق المؤسسة المتوسطة نحو 370 مليون دولار سنويًا على عدم كفاءة الأنظمة القديمة، فيما تنفق شركات الخدمات المالية من 70 إلى 75% من ميزانيات تقنية المعلومات لديها لمجرد إبقاء الأنظمة القديمة على قيد الحياة. أما الفرق التي تنجح في الترحيل فتُبلِّغ عن عوائد تتراوح من 114 إلى 225% وعن نحو 25 مليون دولار من الوفورات سنويًا — لكن ذلك الجانب الإيجابي لا يوجد إلا على الضفة الأخرى من ترحيل لم يفشل. هذا هو التحديث النادر الذي يكون فيه عدم فعل شيء هو الخيار الأغلى.

أفلن تحلّ أدوات الذكاء الاصطناعي الجديدة هذا ببساطة؟

هذا هو السؤال الذي يردني أكثر من غيره، وهو سؤال منصف، خصوصًا بعد أن جعل إعلان Anthropic الأمر يبدو وكأن المشكلة قد أُعلِن حلّها للتوّ.

جوابي الصادق: جعلت الأدوات الجديدة مرحلة الاستكشاف أسرع بكثير، وهذا تقدّم حقيقي — وأنا أستخدمها. لكن براعة الذكاء الاصطناعي الوكيلي في قراءة COBOL لا تغيّر الشيء الذي يقتل المشاريع فعلاً. تتوقّع Gartner أن 40% من تطبيقات المؤسسات ستتضمّن وكلاء ذكاء اصطناعي متخصّصين بالمهام بحلول 2026؛ ووجود مزيد من الوكلاء الذين يترجمون الكود بسرعة أكبر لا يفيد إن كانوا جميعًا عُميانًا عن تبعية JCL نفسها. السرعة في المشكلة الخطأ ليست إلا طريقة أسرع للوصول إلى اختبار قبول المستخدم والفشل فيه.

والسؤال الآخر الذي يردني يتعلّق بالتنظيم، وهو ما تستهين به البنوك المتوسطة. فقانون المرونة التشغيلية الرقمية للاتحاد الأوروبي — DORA — دخل حيّز التنفيذ في يناير 2025 ويتطلّب مرونة تشغيلية واختبار اختراق قائمًا على التهديدات لم تُصمَّم الأنظمة القديمة أبدًا لاجتيازه. ويتعامل المفتّشون الأمريكيون في FFIEC وOCC مع البنية التحتية المتقادمة كفجوة امتثال قائمة، وتحمل الأنظمة الأقدم من عشر سنوات نحو ثلاثة أضعاف احتمال الاختراق. وعملية الترحيل التي لا تستطيع إنتاج مسار تدقيق يثبت أن النظام الجديد يتصرّف بشكل مطابق للقديم ليست تحديثًا — بل مسؤولية جديدة ببناء نحوي أفضل.

لهذا يهمّ اختبار التكافؤ السلوكي بقدر أهمية الخريطة. التقنية سهلة الوصف صعبة الإتقان: التقاط مدخلات ومخرجات حقيقية من النظام القديم — مجموعة بيانات ذهبية (golden dataset) — وإعادة تشغيلها على النظام الجديد حتى يتطابق السلوك، حالة حدّية بحالة حدّية. وتلك الحالات الحدّية، المتراكمة عبر عقود، كثيرًا ما تُرمِّز منطقًا تنظيميًا لا وجود له في أي مكان آخر — لا في مواصفة، ولا في رأس شخص، بل فقط في الكود العامل. لقد رأيت هذا يعضّ شركة تأمين أقسى مما يعضّ بنكًا: قاعدة التسعير التي لا تُفعَّل إلا لملحق وثيقة من عام 1998، وحساب احتياطي المطالبات الذي لا يستطيع أحد على قيد الحياة تفسير تقريبه لكن يعتمد عليه كل تدقيق. اخسرها بصمت، وستكتشف أيها كان مهمًّا يوم يسأل مُنظِّم.

أي طوبة تسحبها أولاً؟

بمجرد أن تمتلك الخريطة، تخبرك بشيء لا يستطيع أي مترجِم إخبارك به: أين يكون البدء آمنًا.

الاستراتيجية السائدة الآن — لسبب وجيه — هي استراتيجية شجرة التين الخانقة (strangler fig): فبدلاً من إعادة كتابة دفعة واحدة، تستخرج قدرة واحدة في كل مرة، وتشغّل القديم والجديد جنبًا إلى جنب، وتُبقي النظام القديم كخيار احتياطي حيّ حتى يكسب الجزء الجديد الثقة. لكن كل مورد يوصي بشجرة التين الخانقة يُغفل أصعب سؤال — أي وحدة تخنقها أولاً؟ اختر وحدة شديدة الاقتران وتكون قد أعدت إنتاج مخاطر الدفعة الواحدة بخطوات إضافية.

الرسم البياني المعرفي يجيب عن ذلك مباشرةً. فهو يُبرِز الوحدات الأقل اقترانًا — تلك ذات أقل التبعيات الواردة — بحيث يمكنك استخراج جزء حقيقي من النظام، وإثبات النهج، وبناء ثقة تنظيمية قبل أن تمسّ النواة الخطرة. الخريطة ليست مجرد تأمين ضد فشل TRN-LIMIT. إنها خطة التسلسل.

لقد بنينا كل هذا — الرسم البياني المعرفي للتبعيات، وتسلسل شجرة التين الخانقة، ومنظومة اختبار التكافؤ السلوكي، بمعزل متعمَّد عن أي منصة هدف — في ممارسة تحديث COBOL القديم لدى Veriprajna، الموجَّهة مباشرةً نحو البنوك وشركات التأمين المتوسطة التي يعاملها أصحاب الحد الأدنى البالغ مليونَي دولار ومُكامِلو الأنظمة ذوو الأرقام السباعية على أنها أصغر من أن تستحق العناء.

ما أنا صادق بشأنه

لن أتظاهر بأن التقنية تحلّ كل شيء، لأن أغلى حالات الفشل التي رأيتها لم تكن تقنية على الإطلاق.

لا أداة — بما فيها أداتنا — تُصلِح قبول المؤسسة، أو تنظّف سنوات من البيانات السيئة، أو تكسب المعركة السياسية المتمثّلة في إقناع مئتَي مطوّر بتغيير طريقة عملهم. ويُتوقَّع أن ينمو السوق من نحو 9 مليارات دولار في 2026 إلى ضِعف ذلك بحلول نهاية العقد، وذلك تحديدًا لأن كثيرًا من الإنفاق يذهب إلى الطبقة البشرية والتنظيمية، لا إلى المُصرِّف. ولا مُحلِّل نحوي (parser) على وجه الأرض، مفتوح المصدر أو تجاري، يغطّي بشكل مثالي كل بنية في IBM Enterprise COBOL — عبارات ALTER لما قبل عام 1985، وأعمق حالات REDEFINES. فكل من يخبرك بغير ذلك يبيعك الفجوة. التقنية ضرورية. لكنها لم تكن كافية قطّ.

لكن الجزء الذي تستطيع التقنية أن تمتلكه، يجب أن تمتلكه بالكامل. فالسبب في أن عمليات الترحيل تحرق الملايين ولا تسلّم شيئًا نادرًا ما يكون أن أحدهم كتب Java سيئًا. بل أنهم ترجموا نظامًا لم يرسموا خريطته فعلاً قطّ — يحوّلون خيوطًا من شبكة بينما الشبكة نفسها بقيت غير مرئية حتى الليلة التي تمزّقت فيها.

ارسم الخريطة أولاً. فالنظام الذي عُمِّر أطول من الأشخاص الذين كتبوه لا يغفر تبعية مفقودة، ولا وجود لنسخة من هذا العمل تكون آمنة قبل أن تستطيع رؤية ما يتّصل بماذا. تعلّمنا ذلك من دفتر أستاذ أطاح به حقل عشري محزوم واحد لم يعرف أحد بوجوده. اعثر على تلك الحقول قبل أن تعثر هي عليك.