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

بالنسبة للمؤسسات التي استثمرت بالفعل في منظومة Microsoft، يُعدّ C# على .NET أحد أقوى أهداف الترحيل المتاحة. فهو لغة حديثة ذات أنواع ثابتة (statically typed) وموجّهة للكائنات، وتعمل عبر المنصّات على .NET 8 وما بعده، وتمتلك خاصية تجعلها ملائمة بشكل خاص لـ COBOL: نوع decimal أصلي مصمّم لإجراء الحسابات المالية الدقيقة.

يشرح هذا الدليل ما ينطوي عليه ترحيل COBOL إلى C# فعلياً، والأساليب المتاحة للمؤسسات البريطانية، وكم يكلّف، وكيف تُدار المخاطر.

الخلاصة السريعة (TL;DR)

  • يُعدّ C# هدف الترحيل الأنسب لـ COBOL بالنسبة للمؤسسات القائمة بالفعل على .NET أو Azure، ونوعه الأصلي decimal بحجم 128 بت يُطابِق مباشرة حقول COBOL ذات النظام العشري المضغوط (packed-decimal) دون مكتبات من طرف ثالث
  • تحمل الأساليب الرئيسية الثلاثة (التحويل الآلي، وإعادة الكتابة المتوازية، والترحيل التدريجي على طريقة “شجرة التين الخانقة” strangler fig) ملامح مختلفة من حيث المخاطر والتكلفة؛ وتعتمد معظم المؤسسات البريطانية نهجاً هجيناً
  • يكلّف الترحيل المتوسط الحجم عادةً ما بين £200,000 و£800,000 ويستغرق سنة إلى سنتين؛ ويُعدّ التقليل من تقدير النطاق أكثر أسباب الإخفاق شيوعاً
  • تُنتج أدوات التحويل الآلي شيفرة C# سليمة هيكلياً لكنها ليست نظاماً مكتملاً؛ فطبقة الوصول إلى البيانات والاختبار والتحقق من صحة قواعد العمل تظلّ عملاً يدوياً بصرف النظر عن الأدوات

لماذا يُعدّ C# هدفاً قوياً لترحيل COBOL

C# ليس الوجهة المنطقية الوحيدة لـ COBOL. فلغات Python وJava وGo وC++ وRust جميعها صالحة تبعاً للسياق. لكنّ C# يتميّز لأسباب محدّدة:

دقة decimal الأصلية. هذه هي الحجة التقنية الأقوى على الإطلاق لصالح C#. تستخدم حقول COBOL المالية النظام العشري المضغوط (COMP-3) وبنود PIC 9 الرقمية التي تمثّل قيماً دقيقة بالأساس العشري (base-10). ونوع decimal المدمج في C# هو نوع بأساس عشري وبحجم 128 بت ودقة ثابتة، مصمَّم خصيصاً للحسابات المالية والنقدية. تُطابَق حقول COBOL العشرية مباشرةً عليه، ما يحفظ الدقة الحسابية بلا مفاجآت تقريب ودون مكتبة خارجية. تستطيع Java تحقيق الصحّة ذاتها عبر BigDecimal، لكن عبر واجهة كائنات أكثر إسهاباً؛ أما اللغات التي تعتمد على الفاصلة العائمة الثنائية (double في Java وfloat64 في Go وf64 في Rust) فهي غير ملائمة للأموال دون جهد إضافي.

منظومة .NET. تُشغّل العديد من المؤسسات البريطانية بالفعل Windows Server وSQL Server وActive Directory وAzure. وبالنسبة لهذه المؤسسات، يُبقي ترحيل COBOL إلى C# النظامَ المحدَّث داخل منظومة تُشغّلها فرقها وتراقبها وتؤمّنها أصلاً. ويُطابَق الوصول إلى البيانات بسلاسة على ADO.NET أو Entity Framework Core أو Dapper.

بيئة تشغيل حديثة عابرة للمنصّات. لم يعد .NET الحديث حكراً على Windows. فشيفرة C# 12 تُترجَم وتعمل على .NET 8 أو أحدث (وهو إصدار بدعم طويل الأمد) عبر Windows وLinux وmacOS، وتُنشَر بشكل طبيعي كحاوية على Azure أو AWS أو GCP. لم يعد الانتقال إلى C# يقيّدك بنظام تشغيل واحد.

الأنواع الثابتة والأدوات. تلتقط الأنواع الثابتة القوية في C# فئات كاملة من الأخطاء وقت الترجمة، وهو أمر مهم عند ترجمة منطق عمل عمره عقود. وتوفّر Visual Studio وRider وأداة سطر الأوامر .NET CLI دعماً ناضجاً للتنقيح والتحليل وإعادة الهيكلة.

توافر المطوّرين. يظلّ C# باستمرار من بين أكثر لغات المؤسسات استخداماً في المملكة المتحدة، ما يجعل مجموعة التوظيف والصيانة على المدى الطويل عميقة.

فهم ما تُرحّل منه

تندرج أنظمة COBOL في سياق المؤسسات البريطانية عادةً ضمن فئات قليلة، ويتغيّر طابع الترحيل مع كل منها:

أنظمة المعالجة الدُّفعية (Batch). حِمل عمل COBOL الكلاسيكي: أحجام كبيرة من السجلات تُقرأ من الملفات، وتُعالَج تسلسلياً، ثم تُكتب مجدداً. عادةً ما تكون هذه الأنظمة الأسهل في الترحيل وتُطابَق جيداً على خدمات C# الخلفية والإدخال/الإخراج المتدفّق (streaming I/O).

أنظمة معالجة المعاملات. معالجة المعاملات عبر الإنترنت (OLTP)، تُدار غالباً بواسطة CICS أو IMS على حواسيب IBM المركزية. تحمل هذه الأنظمة أكبر قدر من المخاطر لأن حدود المعاملات وسلوك التراجع (rollback) وإدارة الاتصالات تحتاج جميعها إلى مطابقة دقيقة على مكافئاتها في .NET.

أنظمة توليد التقارير. يُرحَّل إعداد التقارير في COBOL عادةً إلى خطوط أنابيب C# تُخرج صيغاً حديثة: PDF أو Excel أو لوحات معلومات ويب.

طبقات الواجهات والوسيطة (Middleware). كثيراً ما تتحوّل برامج COBOL الواقعة بين الأنظمة الأقدم وقواعد البيانات إلى خدمات C# في البنية المحدَّثة.

بُنى COBOL التي تحتاج ترجمة حقيقية

يعتمد الترحيل الآمن على ترجمة دلالات COBOL، لا على الاستبدال النصي سطراً بسطر. ومن البُنى التي تحتاج مطابقة فعلية:

  • نطاقات PERFORM تصبح استدعاءات دوال في C#، مع تفكيك الفقرات (paragraphs) والأقسام (sections) إلى دوال (methods).
  • EVALUATE / WHEN تُطابَق على عبارات switch في C# أو على مطابقة الأنماط (pattern matching).
  • أسماء الشروط من المستوى 88-level تصبح خصائص منطقية (boolean) أو دوالّ مساعدة.
  • MOVE CORRESPONDING وREDEFINES وOCCURS تتطلّب مطابقة دقيقة على حقول ذات أنواع، واتحادات (unions) بحسب القصد، ومصفوفات أو مجموعات (collections).
  • بنود PIC تُطابَق على نوع C# المناسب: string للأبجدي الرقمي، وshort / int / long للأعداد الصحيحة بأحجامها، وdecimal لحقول النظام العشري المضغوط مع الحفاظ على الدقة.
  • توجيهات COPY وREPLACE (كتب النسخ copybooks) يجب حلّها قبل التحليل أو أثناءه، بما في ذلك كتب النسخ المتداخلة.
  • EXEC SQL (DB2) وEXEC CICS والوصول إلى ملفات VSAM ليس لها مكافئ جاهز في C# وهي الأجزاء الأكثر احتمالاً للحاجة إلى إعادة تصميم متعمّدة على ADO.NET / Entity Framework Core وأنماط الخدمات الحديثة.
  • ترميز EBCDIC وتخطيطات السجلات ذات العرض الثابت تحتاج إلى تحويل صريح إلى Unicode ونماذج ذات أنواع.

أساليب الترحيل

هناك ثلاثة أساليب رئيسية، لكل منها ملمح مختلف من حيث المخاطر والتكلفة.

1. التحويل الآلي

تُحلّل الأدوات شيفرة COBOL وتُولّد ما يكافئها من C#. وعند تنفيذ ذلك بإتقان، تكون المخرجات شيفرة C# 12 سليمة هيكلياً بمساحات أسماء (namespaces) وأصناف (classes) ومطابقة decimal صحيحة. وعند تنفيذه بسذاجة، ينتج صنف واحد محشو بدوال ساكنة (static) يصعب صيانته أكثر من COBOL الأصلي.

الأنسب لـ: قواعد الشيفرة الكبيرة حيث الأولوية للتخلّص من الاعتماد على COBOL بسرعة، تليها إعادة هيكلة تدريجية.

المخاطر: لا توجد أداة تُنتج نظاماً مكتملاً وجاهزاً للإنتاج. فالـ SQL المضمَّن وتفاعلات CICS والاستدعاءات الديناميكية ما زالت تتطلّب قرارات بشرية.

توضّح أداة Mecanik لترحيل COBOL إلى C# كيف يبدو التحويل الآلي الجيّد. فهي تُشغّل خط أنابيب مترجم كامل (محلّل معجمي lexer، ومحلّل نحوي parser، ومحلّل دلالي، ومولّد شيفرة) بدلاً من الاستبدال النصي، وتفكّك أقسام COBOL وفقراته إلى دوال C#، وتُطابِق حقول COMP-3 على decimal الأصلي، وتحلّ توجيهات COPY / REPLACE بما فيها كتب النسخ المتداخلة، وتُنتج Migration Report يُبرز كل EXEC SQL وEXEC CICS وكل CALL ديناميكي يحتاج إلى تدخّل يدوي. كما تتولّى التفاصيل العملية، مثل إضافة بادئة للمعرّفات التي تتعارض مع الكلمات المحجوزة في C#، وتحويل الأسماء بنمط ACCOUNT-RECORD إلى PascalCase.

2. إعادة الكتابة المتوازية

يُبنى نظام C# جنباً إلى جنب مع نظام COBOL القائم. ويعمل الاثنان على المدخلات نفسها، وتُتحقَّق المخرجات ببعضها البعض حتى يجتاز نظام C# الاختبار، وعندها يُوقَف COBOL عن الخدمة.

الأنسب لـ: الأنظمة الحرجة للأعمال التي لا يمكن المخاطرة باستمراريتها، مثل المدفوعات وكشوف الرواتب والمزايا الاجتماعية.

المخاطر: تشغيل نظامين بالتوازي يضاعف تكلفة التشغيل أثناء الترحيل ويتطلّب تسوية منضبطة.

3. الترحيل التدريجي (Strangler Fig)

تُستبدَل برامج COBOL الفردية بمكافئاتها من C# واحداً تلو الآخر. فيصبح النظام هجيناً ثم، في نهاية المطاف، C# خالصاً.

الأنسب لـ: أنظمة COBOL الأحادية الكبيرة (monolithic) حيث تكون إعادة الكتابة الكاملة غير عملية. فهو يتيح للفريق أن يتعلّم ويكرّر مع إبقاء الأعمال قائمة.

المخاطر: قد تستمر الحالة الهجينة أطول مما هو مخطَّط، وتتطلّب تصميماً دقيقاً للواجهات بين مكوّنات COBOL وC#.

بالنسبة لمعظم عمليات ترحيل المؤسسات البريطانية، يمنح نهج strangler fig المقترن بتحويل آلي انتقائي للأقسام المثقلة بالشيفرة المتكرّرة (boilerplate) أفضل توازن بين المخاطر والسرعة.

تكاليف ترحيل COBOL إلى C# في المملكة المتحدة

تعتمد التكلفة بشدة على حجم قاعدة الشيفرة وتعقيدها والأسلوب المتَّبع. وفيما يلي نطاقات استرشادية لمشاريع المؤسسات البريطانية:

حجم النظامالأسلوبالتكلفة التقديرية
صغير (< 50,000 سطر)إعادة الكتابة المتوازية£80,000 إلى £200,000
متوسط (50,000 إلى 500,000 سطر)Strangler fig£200,000 إلى £800,000
كبير (500,000+ سطر)آلي + إعادة هيكلة تدريجية£500,000 إلى £2,000,000+
إيقاف حاسوب مركزي قديمبرنامج كامل£1,000,000 إلى £10,000,000+

تغطّي هذه الأرقام التحليل والترحيل والاختبار ودعم الإطلاق. وهي لا تشمل تكاليف التشغيل الجارية والتدريب وأعمال التكامل اللاحقة التي تظهر غالباً في منتصف المشروع.

تتخصّص خدمة Mecanik لترحيل COBOL إلى C# في عمليات ترحيل المؤسسات البريطانية، وتغطّي التقييم والتحويل وتنفيذ طبقة الوصول إلى البيانات عبر Entity Framework واختبار تكافؤ المخرجات. وبالنسبة للمؤسسات التي توازن بين عدة لغات هدف، يعرض دليل ترحيل COBOL الشامل المجموعة الكاملة من الخيارات بما فيها Python وJava وGo وC++ وRust، ويتناول دليل ترحيل COBOL إلى Python البديلَ الأكثر شيوعاً بالعمق نفسه الذي يتناوله هذا الدليل.

أما بالنسبة لعمليات الترحيل حيث يعمل COBOL على IBM z/OS أو بنية تحتية مشابهة، فتغطّي خدمة Mecanik لترحيل الحواسيب المركزية القديمة إيقاف البنية التحتية إلى جانب ترحيل الشيفرة.

المخاطر الرئيسية وكيفية إدارتها

تتجاوز عمليات ترحيل COBOL إلى C# ميزانياتها أو تُخفق لأسباب يمكن التنبّؤ بها:

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

تبعيّات صيغ البيانات. ليس للنظام العشري المضغوط (COMP-3) وترميز EBCDIC والتخطيطات ذات العرض الثابت مكافئ تلقائي في C#. يحلّ نوع decimal في C# الجانب الحسابي بسلاسة، لكن يظلّ لزاماً مطابقة كل حقل واختباره ببيانات حقيقية قبل التبديل.

طبقة الوصول إلى البيانات. غالباً ما يكون تحويل منطق COBOL أسهل من استبدال وصوله إلى البيانات. فـ EXEC SQL مقابل DB2 ومعالجة ملفات VSAM يجب إعادة تصميمهما على ADO.NET أو Entity Framework Core أو Dapper، وهذا كثيراً ما يكون أكبر بند عمل مفرد.

توقّعات الأداء. إن مهمة دُفعية بلغة COBOL تُنجز 10 ملايين سجل خلال الليل تضع سقفاً قد لا تبلغه إعادة كتابة C# الساذجة. لذا يلزم التحليل والتحسين، وأحياناً تغيير معماري.

تغطية اختبارات الانحدار (Regression). الطريقة الموثوقة الوحيدة لإثبات أن مخرجات C# تطابق مخرجات COBOL هي إجراء اختبارات انحدار شاملة ببيانات حقيقية (مجهّلة الهوية عند اللزوم). وبناء مجموعة الاختبارات هذه قبل بدء الترحيل ليس أمراً اختيارياً.

مخاطر التبديل. التحوّل إلى C# في بيئة الإنتاج هو أعلى اللحظات خطورة. وخطة تبديل مفصّلة تتضمّن إجراءات التراجع وفحوص التسوية أمر إلزامي.

أبرز النقاط

  • يُعدّ C# أقوى هدف لترحيل COBOL بالنسبة للمؤسسات القائمة على منظومة .NET أو Azure، ويرجع ذلك أساساً إلى أن نوعه الأصلي decimal بحجم 128 بت يُطابِق حقول COBOL العشرية المضغوطة مباشرة وبدقة تامة ودون مكتبة خارجية.
  • الأساليب الرئيسية الثلاثة هي التحويل الآلي، وإعادة الكتابة المتوازية، والترحيل التدريجي؛ وتعتمد معظم مشاريع المؤسسات البريطانية نهج strangler fig مع أتمتة انتقائية.
  • تتراوح التكاليف من نحو £80,000 للأنظمة الصغيرة إلى برامج بملايين الجنيهات لإيقاف الحواسيب المركزية بالكامل.
  • أكبر المخاطر هي منطق العمل غير الموثّق، وتبعيّات صيغ البيانات، وإعادة تصميم طبقة الوصول إلى البيانات. ومعالجة الثلاثة جميعاً قبل بدء الترحيل أمر جوهري.

الأسئلة الشائعة (FAQ)

لماذا الترحيل من COBOL إلى C# بدلاً من Java أو Python؟ اختر C# عندما تعمل مؤسستك على منظومة .NET أو على بنية تحتية من Windows وAzure. فنوعه الأصلي decimal مناسب بشكل خاص لحقول COBOL المالية. أما Java فهي الخيار الطبيعي للفرق العاملة على JVM، وPython تناسب المؤسسات التي تعطي الأولوية لسهولة القراءة والتكامل مع الذكاء الاصطناعي.

ما الذي يجعل نوع decimal في C# أفضل لترحيل COBOL؟ إن decimal في C# هو نوع بحجم 128 بت وبأساس عشري ودقة ثابتة، مبني للحسابات المالية، لذا تُطابَق حقول COBOL من نوع COMP-3 وPIC 9 العشرية عليه مباشرة بدقة حسابية تامة ودون مكتبة من طرف ثالث. أما اللغات التي تستخدم الفاصلة العائمة الثنائية للأرقام فتحتاج إلى جهد إضافي لمحاكاة سلوك decimal في COBOL.

هل تعمل شيفرة C# المُرحَّلة على Linux، أم على Windows فقط؟ تعمل على كليهما. فـ C# 12 يستهدف .NET 8 أو أحدث، وهو عابر للمنصّات عبر Windows وLinux وmacOS، ويُنشَر كتطبيق قياسي أو كحاوية على Azure أو AWS أو GCP.

هل يمكن تحويل منطق COBOL إلى C# آلياً؟ نعم، بالأدوات. فأداة التحويل الجيّدة تُنتج شيفرة C# سليمة هيكلياً ببنية أصناف صحيحة ومطابقة decimal، لكنها تُبرز الـ SQL المضمَّن وتفاعلات CICS والاستدعاءات الديناميكية للعمل اليدوي بدلاً من التخمين. وتظلّ طبقة الوصول إلى البيانات والتحقق من صحة قواعد العمل مهام بشرية.

ماذا يحدث لصيغ بيانات COBOL مثل COMP-3 وEBCDIC؟ تُطابَق حقول COMP-3 بسلاسة على decimal في C#. أما نصوص EBCDIC والتخطيطات ذات العرض الثابت فتتطلّب تحويلاً صريحاً إلى Unicode ونماذج ذات أنواع، وينبغي اختبار كل بنية ببيانات حقيقية قبل الاستخدام في الإنتاج.

كم يستغرق ترحيل COBOL إلى C#؟ تستغرق الأنظمة الصغيرة جيّدة التوثيق من ثلاثة إلى تسعة أشهر. وتستغرق أنظمة المؤسسات المتوسطة من اثني عشر إلى أربعة وعشرين شهراً. أما برامج الحواسيب المركزية الكبيرة فقد تستغرق من ثلاث إلى خمس سنوات للإيقاف الكامل.