تحديث الحاسوب المركزي القديم
تفشل 70-80% من مشاريع تحديث الحواسيب المركزية. ليس لأن التقنية خاطئة، بل لأن الأدوات تعامل الشيفرة كنص بدلاً من كونها طوبولوجيا. نحن نبني خريطة قاعدة الشيفرة الخاصة بك قبل المساس بسطر واحد، حتى تنجح عملية الترحيل لديك حيث استنزف الآخرون الملايين ولم يقدموا شيئاً.
1.52 تريليون دولار
الدين التقني الأمريكي
Pragmatic Coders، 2025
10%/سنة
تناقص القوى العاملة في COBOL
IEEE Spectrum، 2025
70-80%
معدل فشل التحديث
تحليل تجميعي للصناعة، 2025
إن الأدوات التي تَعِد بـ "الصق COBOL، احصل على Java" تُنتج شيفرة تُصرَّف. هذا هو الجزء السهل. الجزء الصعب هو الشيفرة التي لا تستطيع رؤيتها.
تأمل برنامج معالجة تحويل برقي. إنه يحتوي على جملة COMPUTE تستخدم متغيراً يُسمى TRN-LIMIT. يقوم مساعد برمجة بالذكاء الاصطناعي بترجمة الجملة إلى عملية Java BigDecimal . تُصرَّف الشيفرة. وتنجح اختبارات الوحدة.
في اختبار قبول المستخدم (UAT)، تتسبب أول معاملة في انهيار فحص اتساق قاعدة البيانات.
التشريح: TRN-LIMIT لم يكن معرّفاً في الملف المصدري الذي ترجمه الذكاء الاصطناعي. بل كان معرّفاً في دفتر نسخ (copybook) مُضمَّن قبل آلاف الأسطر في سلسلة التنفيذ. وقد احتوى دفتر النسخ ذاك على جملة REDEFINES ، وهي بنية في COBOL تتيح تفسير العنوان نفسه في الذاكرة كنوعين مختلفين من البيانات اعتماداً على راية (flag) تُضبَط في وحدة (module) مختلفة تماماً.
رأى الذكاء الاصطناعي TRN-LIMIT كحقل رقمي بسيط وافترض نوع عدد صحيح قياسي. على الحاسوب المركزي، احتوى ذلك العنوان في الذاكرة على عدد عشري مضغوط (COMP-3). كتب تطبيق Java بيانات ثنائية تالفة في عمود قاعدة البيانات، مُطلِقاً فشلاً في التكامل المرجعي.
كانت الشيفرة سليمة نحوياً تماماً. لكن الفشل كان عمى السياق. أغفل الذكاء الاصطناعي اعتمادية موجودة خارج مجال رؤيته.
قد يشير برنامج COBOL واحد إلى أكثر من 40 دفتر نسخ. وقد ينسخ كل دفتر نسخ (COPY) دفاتر نسخ أخرى. يمكن أن تكون تعريفات المتغيرات على عمق 5 مستويات في سلسلة التضمين. أدوات الذكاء الاصطناعي القائمة على النص لا ترى أياً من هذا.
إن شيفرة COBOL الخاصة بك لا تعمل بشكل مستقل. يجدول CA-7 أو TWS ما بين 2,000 و5,000 وظيفة JCL مع سلاسل اعتماديات. تكتب الوظيفة A مجموعة بيانات تقرؤها الوظيفة B في الساعة الثانية صباحاً. رحّل COBOL لكن أغفل JCL، وسينهار الإنتاج عند منتصف الليل.
إن العدد العشري المضغوط COMP-3 في COBOL ليس له مكافئ في Java. يُدخِل نوع Java double أخطاء تقريب الفاصلة العائمة. حتى BigDecimal يتطلب تكويناً صريحاً لوضع التقريب (HALF_EVEN) ليطابق جملة ROUNDED في COBOL. خطأ بقيمة سنت واحد يتراكم عبر ملايين المعاملات.
كل مورّد تقني رئيسي يبيع الآن تحديث الحواسيب المركزية. إليك ما يقدمه كل منهم فعلاً، وأين تبقى الثغرات.
| المورّد / النهج | ما الذي يفعله | التكلفة النمطية | ما الذي يغفله |
|---|---|---|---|
| IBM Watsonx Code Assistant for Z | ترجمة وكيلية (agentic) من COBOL إلى Java مع تحليل اعتماديات ADDI. بنية متعددة الوكلاء (وكلاء Orchestrate وArchitect وCode). يدعم PL/I وIMS. | 2 مليون دولار+ (ترخيص للمؤسسات + متطلب z/OS) | يعمل ADDI على z/OS، مما يخلق ارتباطاً بالمورّد أثناء الترحيل. يتعثر المحلّل النحوي (Parser) مع بنى COBOL السابقة لعام 85 (جمل ALTER). لا يوجد اختبار تكافؤ سلوكي. لا يوجد تخطيط لاعتماديات JCL. |
| Anthropic Claude Code | تحليل شيفرة وتوثيق وتخطيط اعتماديات مدعوم بالذكاء الاصطناعي. قوي في مراحل الاكتشاف والاستكشاف. يدعم الترحيل التدريجي وتغليف واجهات البرمجة (API). | تسعير API قائم على الاستخدام | ذكاء اصطناعي للأغراض العامة. لا يوجد رسم بياني معرفي مدمج لحل الاعتماديات المتعدّية. لا يعالج جدولة JCL، أو اختبار التكافؤ السلوكي، أو سجلات التدقيق التنظيمية. |
| Microsoft Azure Migration Factory | وكلاء وكيليون (agentic) معياريون عبر Semantic Kernel. وكلاء COBOL Expert + Java Expert. يستهدف Java Quarkus. وكيل ترحيل Azure Copilot في مرحلة المعاينة. | استهلاك Azure + استشارات | ارتباط بـ Azure للمنصة المستهدفة. الوكلاء مفتوحو المصدر هم تطبيقات مرجعية، وليسوا جاهزين للإنتاج في البيئات الخاضعة للتنظيم. دعم محدود لـ CICS/IMS. |
| DXC Technology | تحويل شيفرة آلي مسجّل ببراءة اختراع (من COBOL/RPG/JCL إلى Java). عقود من الخبرة في الحواسيب المركزية. نماذج سحابة هجينة + حاسوب مركزي كخدمة. | 1 مليون - 10 ملايين دولار+ | أدوات احتكارية، شفافية محدودة في منطق التحويل. تركيز على المؤسسات الكبيرة. الجداول الزمنية للارتباط التي تتراوح بين 18 و36 شهراً شائعة. |
| TCS / Infosys / Accenture | ممارسات تكامل أنظمة كبيرة مع أُطُر احتكارية (MasterCraft، Cobalt). فرق تسليم ضخمة. إدارة برامج شاملة من البداية إلى النهاية. | 500 ألف - 5 ملايين دولار+ | نهج محوره المنصة. هم ينفّذون أدوات المورّدين، لا يبنون ذكاءً مخصصاً. عبء نموذج ارتباط مُكامِل الأنظمة الكبير. قاد أحد مُكامِلي الأنظمة عملية ترحيل لمصرف بقيمة مليار دولار أسترالي استغرقت 5 سنوات وضاعفت ميزانيتها. |
| Micro Focus (OpenText) Visual COBOL | تشغيل COBOL أصلياً على .NET/JVM. نقطة انطلاق عملية بنمط "شجرة الخنق" (strangler fig). الرائد في سوق مُصرِّفات COBOL. | 200 ألف - 500 ألف دولار ترخيص | ليس تحديثاً، بل هو إعادة استضافة. منطق COBOL يبقى COBOL. يستمر الدين التقني. لا يحل مشكلة القوى العاملة. |
| افعلها بنفسك بذكاء اصطناعي مفتوح المصدر | نموذج XMainframe اللغوي الكبير (7B/10.5B معامل، أفضل بنسبة 30% من DeepSeek في COBOL). تحليل نحوي بـ Tree-sitter. خطوط أنابيب مخصصة. | وقت هندسي + بنية تحتية | يتطلب خبرة عميقة في COBOL + هندسة الرسوم البيانية. لا يوجد محلّل نحوي لـ COBOL بدرجة إنتاجية يغطي كل بنى IBM Enterprise COBOL v6.x. خطر عالٍ من بناء ثغرات المحلّل النحوي في الأساس. |
خمس قدرات، تعالج كل منها ثغرة محددة في سلسلة أدوات التحديث. نحن محايدون تجاه المورّدين: يعمل الرسم البياني المعرفي بغض النظر عما إذا كان هدفك AWS أو Azure أو GCP أو Java في موقع داخلي.
نقوم باستيعاب مصدر COBOL الخاص بك، ودفاتر النسخ، ومكتبات JCL، وصادرات كتالوج DB2، وتعريفات معاملات CICS، وتسلسلات هرمية لأجزاء IMS في قاعدة بيانات رسم بياني موحّدة. يصبح كل متغير، وكل سلسلة PERFORM، وكل جملة REDEFINES، وكل اعتمادية دُفعية حافة رسم بياني صريحة. نلجأ إلى Neo4j عندما تهيمن استعلامات الإغلاق المتعدّي المعقدة على حالة الاستخدام، وإلى Memgraph عندما تكون سرعة الاجتياز في الوقت الفعلي مهمة للاستكشاف التفاعلي.
يعالج الرسم البياني نحو 200 ألف - 300 ألف سطر يومياً أثناء الاستيعاب. لقاعدة شيفرة بحجم 2 مليون سطر، توقّع 8-12 أسبوعاً من أول استيعاب إلى رسم بياني مُتحقَّق منه وقابل للاستعلام. المُخرَج هو أصل دائم: قاعدة شيفرتك كطوبولوجيا قابلة للبحث، لا ملفات نصية غامضة.
قبل أن تبدأ أي ترجمة للشيفرة، نُجري تحليلاً للرسم البياني عبر أربعة أبعاد: درجة الاقتران (كم عدد الوحدات الأخرى التي تعتمد على هذه الوحدة)، وكثافة REDEFINES/COMP-3 (كم عدد فخاخ أنواع البيانات الموجودة)، ونسبة الشيفرة الميتة (عادة 20-30% من قاعدة الشيفرة)، وحرجية جدولة الدُفعات (أي وظائف JCL تمس هذه الوحدة ومتى).
المُخرَج هو تسلسل استخراج مُرتَّب لترحيل شجرة الخنق (strangler fig). تُستخرَج أولاً الوحدات ذات الاقتران الأدنى وأنواع البيانات الأبسط. أما "البرامج الإلهية" التي تستدعيها أكثر من 50 وحدة أخرى فتُستخرَج أخيراً. هذا التسلسل هو الفرق بين طرح مُتحكَّم به وفشل متسلسل.
تستعلم وكلاء الترجمة لدينا الرسم البياني المعرفي قبل توليد كل وحدة Java، مستخرجةً الإغلاق المتعدّي الكامل للاعتماديات. يرى الوكيل جملة REDEFINES في دفتر النسخ الموجود على بُعد ثلاثة أدلة. ويرى تعريف العدد العشري المضغوط الذي يحدد سلوك التقريب. وهو يُولِّد Java بتمرير معاملات صريح (حقن الاعتماديات) بدلاً من الحالة العامة الضمنية في COBOL. ثم يُصرِّفها في بيئة معزولة (sandbox)، ويُجري اختبارات تكافؤ سلوكي، ويصحح نفسه ذاتياً.
نستخدم أي نموذج أساسي يناسب تعقيد الوحدة. للتحويلات المباشرة من PERFORM إلى دالة، يعمل نموذج أصغر بشكل جيد. أما للوحدات ذات REDEFINES المتداخلة، أو فوضى GOTO التي تتطلب تسطيح تدفق التحكم، أو منطق المعاملات المُضمَّن EXEC CICS، فنستخدم أقدر نموذج متاح ونعززه بسياق الرسم البياني الكامل.
الجزء الذي يتخطاه معظم المورّدين وتفشل فيه معظم عمليات الترحيل. نبني نظام تحقق من ثلاث طبقات: اختبارات وحدة رمزية مُولَّدة من مسارات تدفق التحكم المستمدة من الرسم البياني، وإعادة تشغيل مجموعة بيانات ذهبية باستخدام معاملات إنتاج مُلتقَطة تُقارَن حقلاً بحقل بدقة لا تخطئ بسنت، وتشغيلات إنتاج متوازية حيث يعالج كلا النظامين معاملات حية لمدة 30-90 يوماً قبل إيقاف وحدة الحاسوب المركزي عن الخدمة.
تتطلب الحسابات المالية BigDecimal مع وضع تقريب HALF_EVEN ليطابق جملة ROUNDED في COBOL. وتتطلب حسابات التواريخ التعامل مع صيغة التاريخ ذات الستة أرقام في COBOL (YYMMDD) مع منطق نافذة القرن. نبني قواعد التحويل هذه في أداة الاختبار، لا في تصحيحات مرتجلة تُكتشَف أثناء ضمان الجودة.
نحلّل نحوياً شبكات وظائف JCL الخاصة بك، وسلاسل اعتماديات CA-7/TWS/Control-M، وتسلسلات معالجة الدُفعات في الرسم البياني المعرفي. تصبح كل وظيفة JCL عقدة لها حواف نحو برامج COBOL التي تنفّذها، ومجموعات البيانات التي تقرؤها وتكتبها، وشروط الجدولة التي تعتمد عليها (مُطلِقات زمنية، توفر مجموعة البيانات، اكتمال السابق).
عندما تُرحَّل وحدة COBOL إلى Java، نبني في الوقت نفسه الجدولة المكافئة في منصة التنسيق المستهدفة لديك (Apache Airflow، أو AWS Step Functions، أو Azure Data Factory، أو Control-M على البيئة الموزّعة). تُحفَظ سلسلة الاعتماديات ويُتحقَّق منها مقابل تعريف CA-7/TWS الأصلي. لدى المصرف النمطي متوسط الحجم ما بين 2,000 و5,000 وظيفة JCL. لقد رأيناها جميعاً.
شرح خطوة بخطوة لكيفية منع حل الاعتماديات القائم على الرسم البياني لأكثر أنماط فشل الترحيل شيوعاً.
يعالج المحلّل النحوي PROG-WIRE-01.cbl، ويصادف COPY CB-ACCT-LIMITS، ويتبع سلسلة التضمين. يبني عُقد شجرة بناء مجردة (AST) لكل تصريح متغير، بما في ذلك تلك الموجودة في دفاتر النسخ المتداخلة على عمق 3 مستويات.
يُنشئ محرك الرسم البياني الحواف: PROG-WIRE-01 → IMPORTS → CB-ACCT-LIMITS. TRN-LIMIT → REDEFINES → TRN-LIMIT-ALPHA. LIMIT-TYPE-FLAG → CONTROLS_TYPE_OF → TRN-LIMIT. هذا يلتقط حقيقة أن نوع بيانات TRN-LIMIT يعتمد على راية وقت تشغيل في حقل مختلف.
يجتاز الرسم البياني نحو الخارج: أي برامج أخرى تنسخ (COPY) أيضاً CB-ACCT-LIMITS؟ أي برامج تضبط LIMIT-TYPE-FLAG؟ أي وظائف JCL تنفّذ تلك البرامج، وبأي تسلسل؟ النتيجة هي سلسلة أثر كاملة. إن تغيير كيفية ترجمة TRN-LIMIT يؤثر على كل برنامج في هذه السلسلة.
عندما يعالج وكيل الترجمة PROG-WIRE-01، يسترجع GraphRAG ليس فقط الملف المصدري بل أيضاً تعريف دفتر النسخ، وعلاقة REDEFINES، وحقل الراية، وكل البرامج التي تضبط الراية. يُولِّد الوكيل صنف Java بنمط اتحاد آمن النوع: كائن TransactionLimit يفحص الراية قبل تفسير البايتات الأساسية إما كـ BigDecimal (وضع العدد العشري المضغوط) أو كـ String (الوضع الأبجدي).
بدون الرسم البياني: يفترض الذكاء الاصطناعي أن TRN-LIMIT حقل رقمي بسيط، ويُولِّد long في Java، وأول تحويل برقي يُفسِد قاعدة البيانات. مع الرسم البياني: يرى الذكاء الاصطناعي سلسلة الاعتماديات الكاملة ويُولِّد شيفرة آمنة النوع تتعامل مع كلا التفسيرين بشكل صحيح. هذا هو الفرق بين ترحيل يعمل في اختبار قبول المستخدم (UAT) وآخر يعمل في الإنتاج.
أربع مراحل، لكل منها مُخرجات واضحة. نحن لا نقدّم عرض سعر لجدول زمني مدته 3 سنوات ثم نختفي. تُنتج كل مرحلة قطعاً (artifacts) تملكها ويمكنك استخدامها بشكل مستقل.
المُخرَج: تقرير التقييم + نموذج أولي للرسم البياني المعرفي
المُخرَج: رسم بياني معرفي قابل للاستعلام + تسلسل استخراج مُرتَّب + أداة تحليل الأثر
المُخرَج: وحدات Java مُرحَّلة في الإنتاج + رسم بياني معرفي مُحدَّث + مكافئات الجدولة
المُخرَج: نشر إنتاج مُتحقَّق منه + حزمة توثيق تنظيمي + رسم بياني مُحدَّث
أجب عن سبعة أسئلة حول بيئتك. يحدد التقييم مستوى جاهزيتك والعوائق المحددة التي يجب معالجتها قبل بدء ارتباط ترحيل، مع Veriprajna أو بدونها.
لقاعدة شيفرة بحجم 2 مليون سطر بتعقيد نمطي (IBM Enterprise COBOL v6.x، وSQL مُضمَّن في DB2، و500+ دفتر نسخ)، يستغرق بناء الرسم البياني من 8 إلى 12 أسبوعاً. الأسابيع الثلاثة الأولى هي تكوين المحلّل النحوي والتحقق منه. تتفاوت لهجات COBOL بما يكفي لنحتاج إلى التحقق من أن المحلّل النحوي يتعامل مع استخدامك المحدد لـ REDEFINES، وOCCURS DEPENDING ON، وكتل EXEC CICS/SQL قبل استيعاب قاعدة الشيفرة الكاملة.
الأسابيع من 4 إلى 8 هي الاستيعاب الآلي، واستخراج الكيانات، وتخطيط العلاقات. يعالج المحلّل النحوي نحو 200 ألف - 300 ألف سطر يومياً، لكن عنق الزجاجة هو حل الكيانات، وتحديداً تحديد أن ACCT-NUM في البرنامج A و ACCT-NUM في دفتر النسخ CB-ACCT-01 هما المتغير نفسه.
الأسابيع من 9 إلى 12 هي حساب الإغلاق المتعدّي والتحقق منه. نُجري فحوص اكتمال الرسم البياني: يجب أن يُحَل كل هدف PERFORM إلى فقرة، ويجب أن تُحَل كل جملة COPY إلى دفتر نسخ، ويجب أن يُخطَّط كل مرجع جدول DB2 إلى تعريف مخطط. تُعلَّم الثغرات للمراجعة اليدوية. المُخرَج هو رسم بياني معرفي قابل للاستعلام حيث يمكنك طرح أسئلة مثل "ماذا يحدث إذا غيّرتُ INTEREST-RATE في CB-GLOBAL-01؟" والحصول على سلسلة أثر كاملة عبر كل برنامج يشير إليه، بشكل مباشر أو متعدٍّ.
نعم، ونوصي بذلك بشدة. نمط شجرة الخنق هو النهج الوحيد ذو السجل المثبت في ترحيل الحواسيب المركزية. تفشل عمليات إعادة الكتابة الكاملة بنسبة 70-80% من الوقت لأنها تحاول استبدال كل شيء في وقت واحد، مما يخلق نقطة فشل واحدة هائلة.
مع نهج شجرة الخنق، يحدد الرسم البياني المعرفي أي وحدات لها أدنى درجات اقتران، أي أقل اعتماديات واردة من وحدات أخرى. هذه هي مرشحاتك للاستخراج. نبدأ عادةً بوحدات تقارير الدُفعات أو روتينات الحساب المستقلة التي تقرأ من DB2 لكن لا تُحدِّث الحالة المشتركة. تعمل خدمة Java الجديدة جنباً إلى جنب مع الحاسوب المركزي. تُوجَّه حركة مرور الإنتاج إلى الخدمة الجديدة لتلك الوظيفة المحددة بينما يستمر الحاسوب المركزي في معالجة كل شيء آخر. تتحقق من التكافؤ السلوكي على بيانات إنتاج حقيقية قبل إيقاف وحدة COBOL عن الخدمة.
تستخرج معظم المؤسسات من 15 إلى 20 وحدة في السنة الأولى، مما يخفض استهلاك MIPS بنسبة 20-30% ويولّد وفورات تكلفة كافية لتمويل المرحلة التالية. يجعل الرسم البياني المعرفي هذا آمناً لأنه يُظهر لك نطاق التأثير لكل استخراج. إذا كانت الوحدة A تُستدعى من 47 برنامجاً آخر، فهي ليست مرشحك الأول للاستخراج. إذا كانت الوحدة B تُستدعى من برنامجين وتقرأ من جدول DB2 واحد، فابدأ من هناك.
هذه هي الطبقة التي تصطدم فيها معظم مشاريع التحديث بإخفاقات غير متوقعة بعد 6 إلى 12 شهراً. إن برامج COBOL الخاصة بك لا تعمل بمعزل. بل تُنسَّق بواسطة تدفقات وظائف JCL التي تديرها CA-7، أو TWS (Tivoli Workload Scheduler)، أو Control-M. لدى المصرف النمطي متوسط الحجم ما بين 2,000 و5,000 وظيفة JCL مع سلاسل اعتماديات معقدة: يجب أن تكتمل الوظيفة A قبل أن تبدأ الوظيفة B، تعمل الوظيفة C فقط في آخر يوم عمل من الشهر، تُطلِق الوظيفة D معاملة CICS تُحدِّث ملف VSAM تقرؤه الوظيفة E.
نحلّل JCL نحوياً جنباً إلى جنب مع COBOL في الرسم البياني المعرفي نفسه. تصبح كل وظيفة JCL عقدة لها حواف نحو برامج COBOL التي تنفّذها، ومجموعات البيانات التي تقرؤها وتكتبها، وشروط الجدولة التي تعتمد عليها. عندما نُرحِّل وحدة COBOL إلى Java، نبني في الوقت نفسه الجدولة المكافئة في منصتك المستهدفة، سواء كانت Apache Airflow، أو AWS Step Functions، أو Azure Data Factory. تُحفَظ سلسلة الاعتماديات ويُتحقَّق منها مقابل الأصلية.
لقد رأينا مشاريع نجح فيها ترحيل الشيفرة بشكل مثالي لكن الإنتاج انهار لأنه لم يقم أحد بتخطيط وظيفة CA-7 التي كانت تُشغّل خطوة معالجة مسبقة كل ليلة في الساعة الثانية صباحاً.
إن IBM Watsonx Code Assistant for Z (حالياً الإصدار v2.8.20، مع Project Bob القادم في وقت لاحق من 2026) منتج قوي بتكامل عميق مع الحاسوب المركزي. يتطلب IBM ADDI (Application Discovery and Delivery Intelligence) لبناء تحليل اعتمادياته، ويعمل ADDI على z/OS. هذا يعني أن أدوات تحليل الاعتماديات لديك تعيش على الحاسوب المركزي نفسه الذي تحاول الترحيل بعيداً عنه. ويعني أيضاً أن IBM تتحكم في طبقة التحليل، مما يخلق ارتباطاً بالمورّد أثناء أكثر مراحل الترحيل حرجاً.
يعمل رسمنا البياني المعرفي خارج الحاسوب المركزي. نستوعب صادرات الشيفرة المصدرية، ومكتبات JCL، وصادرات كتالوج DB2، ومستودعات دفاتر النسخ. يعيش الرسم البياني في بيئتك السحابية أو بنيتك التحتية الداخلية، بشكل مستقل عن ترخيص IBM. ثانياً، يركّز Watsonx على ترجمة COBOL إلى Java. نحن نركّز على الفهم أولاً، والترجمة ثانياً. الرسم البياني المعرفي أصل دائم يخدم تحليل الأثر، وتوليد التوثيق، والحوكمة المعمارية لفترة طويلة بعد اكتمال الترحيل.
ثالثاً، للمحلّل النحوي لـ COBOL في ADDI قيود موثّقة مع بنى COBOL السابقة لعام 85، وخاصة جمل ALTER وأنماط REDEFINES المتداخلة المعينة. نبني امتدادات محلّل نحوي مخصصة للهجة كل عميل.
أخيراً، يستهدف تسعير IBM المؤسسات الكبيرة. يعمل نموذج ارتباطنا للمؤسسات متوسطة الحجم حيث لا يكون ارتباط IBM بقيمة 2 مليون دولار+ ضمن الميزانية.
التكافؤ السلوكي هو حيث تنهار معظم عمليات الترحيل المدعومة بالذكاء الاصطناعي. الشيفرة التي تُصرَّف وتجتاز اختبارات الوحدة قد تُنتج مع ذلك نتائج خاطئة بسبب اختلافات تقريب العدد العشري المضغوط، أو عدم تطابق ترميز EBCDIC إلى ASCII، أو دلالات تراكب ذاكرة REDEFINES التي لا تُترجَم إلى كائنات Java.
نبني أداة تحقق من ثلاث طبقات. الطبقة 1 هي التكافؤ الرمزي: نُولِّد اختبارات وحدة من الرسم البياني المعرفي تغطي كل فرع في تدفق تحكم COBOL الأصلي، بما في ذلك الحالات الحدّية مثل المبالغ السالبة، وحُرّاس القسمة على صفر، وحسابات تواريخ السنة الكبيسة. الطبقة 2 هي إعادة تشغيل مجموعة البيانات الذهبية: نلتقط مجموعة تمثيلية من معاملات الإنتاج من الحاسوب المركزي (سجلات الإدخال، وقراءات DB2، وتفاعلات CICS) ونعيد تشغيلها عبر خدمة Java الجديدة. تُقارَن المُخرجات حقلاً بحقل. للحسابات المالية، نتحقق من دقة لا تخطئ بسنت باستخدام BigDecimal مع تقريب HALF_EVEN ليطابق سلوك جملة ROUNDED في COBOL.
الطبقة 3 هي تشغيل الإنتاج المتوازي: يعالج كلا النظامين المعاملات الحية نفسها في وقت واحد لمدة 30 إلى 90 يوماً. تُسجَّل التباينات، ويُحقَّق فيها، وتُصحَّح قبل إيقاف وحدة الحاسوب المركزي عن الخدمة. هذه أطول مرحلة، لكنها أيضاً المرحلة التي تلتقط الحالات الحدّية المتراكمة عبر 30 عاماً من الإنتاج التي لا يمكن لأي مجموعة اختبارات توقّعها بالكامل.
إن DORA (قانون المرونة التشغيلية الرقمية) سارية المفعول بالكامل منذ 17 يناير 2025، وهي تؤثر مباشرة على أي كيان مالي خاضع للتنظيم في الاتحاد الأوروبي يُشغّل أنظمة حواسيب مركزية. تتطلب المادة 11 أُطُر إدارة مخاطر تقنية المعلومات والاتصالات التي تتضمن اختبار مرونة منتظماً واختبار اختراق موجَّهاً بالتهديدات بناءً على سيناريوهات هجوم واقعية. لم تُصمَّم معظم بيئات الحواسيب المركزية لهذا النوع من الاختبار. لا يمكنك بسهولة إطلاق بيئة z/OS مماثلة لإجراء اختبارات اختراق دون تكاليف ترخيص وبنية تحتية كبيرة.
تتطلب DORA أيضاً قوائم جرد مفصّلة لأصول تقنية المعلومات والاتصالات، والإبلاغ عن الحوادث ضمن أُطُر زمنية محددة، وإدارة مخاطر الأطراف الثالثة لمزوّدي خدمات تقنية المعلومات والاتصالات الحرجة، والتي تشمل مورّد الحاسوب المركزي لديك. يساعد التحديث بطريقتين. أولاً، يخدم الرسم البياني المعرفي نفسه كقائمة جرد أصول تقنية المعلومات والاتصالات التي تتطلبها DORA. إنه يُخطِّط كل برنامج، وكل تدفق بيانات، وكل اعتمادية خارجية. يمكن للمنظمين الاستعلام عنه مباشرة.
ثانياً، المكوّنات المُرحَّلة التي تعمل على بنية تحتية سحابية أسهل بطبيعتها في اختبار المرونة. يمكنك إطلاق بيئات اختبار عند الطلب، وتشغيل سيناريوهات هندسة الفوضى، والتحقق من إجراءات الاسترداد دون التأثير على الإنتاج. لقد رأينا مؤسسات تستخدم الرسم البياني المعرفي كدليل في الفحوص التنظيمية لإثبات أنها تفهم أصولها التقنية، حتى قبل اكتمال الترحيل.
المنهجية وراء صفحة الحل هذه مستندة إلى بحثنا المنشور حول تحديث الأنظمة القديمة وبنى الرسوم البيانية المعرفية.
كيف تتغلب الرسوم البيانية المعرفية الواعية بالمستودع وGraphRAG على متلازمة "الضياع في المنتصف" التي تتسبب في فشل ترجمة الشيفرة بالذكاء الاصطناعي على أنظمة COBOL المؤسسية.
خفض MIPS بنسبة 20-30% في السنة الأولى يوفّر عادةً 500 ألف - 2 مليون دولار سنوياً لمؤسسة متوسطة الحجم.
يستغرق تقييم الرسم البياني المعرفي 4-6 أسابيع. تحصل على خريطة اعتماديات كاملة لقاعدة شيفرتك، وتقرير شيفرة ميتة، وتسلسل استخراج مُرتَّب، سواء مضيتَ في الترحيل أم لا. التقييم نفسه أصل دائم.