أدوات ترحيل الحاسبات المركزية: ما ينجح وما يفشل

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

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

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

الفئات الأربع لأدوات ترحيل الحاسبات المركزية

يبدو السوق مزدحماً حتى ترتّبه بحسب ما تفعله المنتجات فعلاً. فكل شيء تقريباً يقع في إحدى أربع مجموعات، وأي برنامج حقيقي يستخدم أدوات من ثلاث منها على الأقل.

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

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

أدوات الترجمة الآلية تحوّل الشيفرة المصدرية من COBOL إلى Java أو C# أو لغة هدف أخرى. هذه هي الفئة التي يتحمس لها المشترون أكثر والتي تخيب الآمال أكثر، لأسباب مذكورة أدناه.

أدوات ترحيل البيانات تنقل البيانات نفسها: ملفات VSAM والمجموعات التسلسلية وجداول DB2 إلى تخزين علائقي أو سحابي. تعالج تحويل مجموعة المحارف وحقول العشري المحزوم وتخطيطات السجلات التي لا تستطيع منتجات ETL العامة تحليلها ببساطة.

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

ما تجيده أدوات التحليل فعلاً

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

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

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

شغّل التحليل قبل الالتزام بنهج. يوضّح دليلنا حول استراتيجية تحديث الحاسبات المركزية كيف ينبغي أن تشكّل تلك النتائج قرار إعادة الكتابة أو إعادة الهيكلة أو تغيير المنصة.

منصات إعادة الاستضافة: سريعة وحقيقية وليست تحديثاً

إعادة الاستضافة هي الخيار الأكثر قابلية للتنبؤ المتاح، وهي مُقلَّل من شأنها بشكل مزمن نتيجة لذلك.

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

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

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

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

الترجمة الآلية: حيث تعيش المشكلة الحقيقية

التحويل الآلي لـ COBOL يعمل. ليست تلك هي المشكلة. المشكلة هي شكل المخرجات وكلفة التعايش معها.

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

كما أن المخرجات يشكّلها المدخل. فـ COBOL المكتوبة بسلاسل GOTO وتمرير PERFORM THRU وعبارات ALTER وفقرات تُدخَل من عدة اتجاهات لا تتحلل إلى دوال نظيفة، لأنه لا يوجد تحلل نظيف لإيجاده. وما يخرج هو Java أو C# تتبع تدفق تحكم COBOL وتستخدم أسماء متغيرات COBOL، وكثيراً ما تكون أصعب قراءةً من الأصل. يسميها الممارسون JOBOL، ومن الممكن تماماً إتمام ترحيل بنجاح والانتهاء بشيفرة لا يستطيع أحد صيانتها بأي من اللغتين.

البنى الخمس التي تحرّك الجهد اليدوي

الحساب العشري المحزوم هو الأول. فحقول COMP-3 ودلالات العشري الثابت في COBOL لا تُطابَق على الفاصلة العائمة، وأي أداة تسمح بذلك ستنتج نتائج مالية تختلف عن الحاسب المركزي في الخانة العشرية الرابعة. والتحويلات الصحيحة تستخدم أنواعاً عشرية بدقة اعتباطية، وهي أبطأ ويجب تطبيقها باتساق عبر كل مسار حسابي.

ترميز المحارف هو الثاني. فتحويل EBCDIC إلى ASCII آلي، لكن تسلسل الترتيب ليس نفسه، لذا فإن كل ما يعتمد على ترتيب الفرز قد يتغير. تخرج التقارير بتسلسل مختلف، وتتصرف فحوص النطاق بشكل مختلف، وتنتج مقارنات المفاتيح نتائج صحيحة في النظام الجديد وخاطئة مقابل القديم.

REDEFINES والسجلات المتغايرة هي الثالث. فمنطقة تخزين واحدة تُفسَّر بعدة طرق ليس لها مكافئ طبيعي في لغة صارمة الأنواع. وتميل الشيفرة المولَّدة إلى إنتاج معالجة لمصفوفات البايتات مغلَّفة بدوال وصول، وهو ما يعمل وهو بالغ الإزعاج في الصيانة.

دلالات المعاملات هي الرابع. فالبرمجة شبه التحاورية في CICS، حيث تُحمل الحالة في منطقة اتصال بين تفاعلات الشاشة، لا تقابل أي نمط ويب أو خدمة حديث. ومحاكاتها تنتج شيئاً غريباً، وإعادة تصميمها بشكل صحيح هي إعادة كتابة لطبقة العرض.

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

وإذا كنت توازن بين لغات الهدف، يغطي دليلانا المفصّلان حول ترحيل COBOL إلى Java وترحيل COBOL إلى C# كيف تحطّ هذه البنى في كل بيئة.

أدوات ترحيل البيانات والتفاصيل التي تعضّ

يحظى نقل البيانات باهتمام أقل من تحويل الشيفرة ويتسبب في تأخيرات لا تقل عنه.

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

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

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

كيف تختار أدوات ترحيل الحاسبات المركزية دون ندم

بضعة مبادئ تُبقي هذه القرارات على أرض صلبة.

أصرّ على إثبات مفهوم يستخدم أسوأ شيفرتك أنت لا عينة المورّد. اختر الوحدة التي يتجنبها الجميع، تلك التي فيها استدعاء المُجمِّع وREDEFINES بسبعة مستويات، واطلب منهم تحويلها. النتيجة تخبرك أكثر من أي عميل مرجعي.

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

تعامل مع نسب الأتمتة بوصفها مقياساً للأسطر لا للجهد. فالأداة التي تحوّل تسعين بالمئة من العبارات قد تترك لك العشرة بالمئة التي تحتوي كل المخاطر، وتلك العشرة تستهلك روتينياً أكثر من نصف الجدول الزمني.

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

احصل على قراءة مستقلة قبل أن تلتزم

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

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

تدوينات ذات صلة: خدمات تحديث COBOL: كيف تختار المورّد المناسب ، الانتقال من COBOL إلى Python - دليل المؤسسات البريطانية 2026 ، ترحيل COBOL إلى Go: دليل للمؤسسات في المملكة المتحدة ، ترحيل COBOL إلى Rust - دليل مؤسسات المملكة المتحدة .

الأسئلة الشائعة

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

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

لماذا تبدو شيفرة COBOL المحوَّلة غير مقروءة إلى هذا الحد؟ تحافظ محركات الترجمة على السلوك بأمانة، بما في ذلك تدفق تحكم COBOL وتسميتها وبنى بياناتها. والشيفرة المبنية حول سلاسل GOTO ومناطق تخزين مشتركة ليس لها مكافئ نظيف في Java أو C#، فتعكس المخرجات بنية الأصل. وإنتاج شيفرة قابلة للصيانة يتطلب إعادة هيكلة بشرية بعد التحويل.

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

كيف أتحقق من أن النظام المرحّل يتصرف بشكل مطابق؟ شغّل النظامين على المدخلات الإنتاجية نفسها لفترة محددة وقارن المخرجات حقلاً بحقل، مدعوماً بأعداد السجلات ومجاميع الضبط لكل مجموعة بيانات مرحّلة. وابنِ منظومة المقارنة تلك بوصفها مُخرَجاً قائماً بذاته، لأن الفروق تُكتشَف باستمرار لا دفعة واحدة.