Bob يلتقي بالـ mainframe

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

أطول نسخة قائمة من "نظام موجود" تعمل على mainframe. عقود من COBOL وPL/I وملايين الأسطر وعشرات الآلاف من البرامج المرتبطة معاً عبر Db2 وCICS وIMS ومجدوِلات الدُّفعات — كود يواصل تشغيل الأعمال دون أي انقطاع لا يمكنهم تحمّله.

اليوم نجعل IBM Bob Premium Package for Z (Bob PP4Z) متاحاً للعموم. يحلّ محلّ IBM watsonx Code Assistant for Z ويجلب خبرة IBM Z — لغات المنصة ووعي الـ middleware والتحليل الحتمي على مستوى المؤسسة — مباشرةً إلى تجربة Bob.

هذه القصة الهندسية، لا جولة الميزات. بدلاً من سرد كل ما يفعله PP4Z، نريد تحقيق ثلاثة أهداف:

شرح لماذا ينخطئ النموذج العام في تطبيقات mainframe الخاصة بك أكثر مما يعترف.
إظهار كيف نُرسّخ Bob في حقائق حتمية عن بيئتك بدلاً من الاحتمالات.
استعراض الأوضاع والـ skills والـ workflows الخاصة بـ Z — وما يمكنك بناؤه بها.

1. لماذا mainframe الحالة الصعبة

النموذج العام الموجَّه نحو بيئة mainframe يصطدم بثلاث مشكلات لا يُصلحها القدر من الموجّهات الذكية. تصميم PP4Z يوفّر حلولاً لكل منها.

1.1. الحجم وما يفعله لـ context window

تطبيق أعمال واحد يمكنه أن يكون ملايين أسطر COBOL وعشرات الآلاف من الوحدات المترابطة عبر COBOL وPL/I وassembler وآلاف مهام الدُّفعات المتسلسلة بمجدوِل مؤسسي. حتى "شريحة صغيرة" من 200 برنامج تحتوي بسهولة مئات الآلاف من أسطر الكود.

هذا لا يتناسب مع context window، والمشكلة ليست الـ window فحسب. مع نموّ السياق، يتدهور أداء النموذج (Chroma Research Context Rot Study, 2025) — تصبح الإجابات ناقصة وغير متسقة أو خاطئة بثقة، مثلما يغرق إنسان في طوفان من المعلومات. سحب "الملفات ذات الصلة" يفترض أنك تعرف أصلاً أيّ الملفات ذات صلة، وهذا بالضبط ما كنت تحاول اكتشافه في المقام الأوّل.

1.2. المعنى الغائب عن الكود

كود mainframe كثيف دلالياً. يعيش المعنى التجاري في أسماء الحقول وعقود من الاتفاقيات، لا في شيء يستطيع محلّل النحو قراءته. يمكنك تخمين بعضه — SERIALN على الأرجح رقم تسلسلي، TOT-STTM على الأرجح إجمالي التسوية. معظمه لا تستطيع: ما هو C-M؟ ما هو M-CAP؟ لماذا البادئة CCZD؟ ما الذي يفرّق بين NO-SIN وNO-EVN وNO-CNT؟

المعنى حقيقي وحيوي، لكنّه غير قابل للتخمين من الكود وحده. الإجابة التقليدية قاموس بيانات — لكن الحجم (ملايين إن لم تكن مليارات المتغيّرات) يجعل بناءه يدوياً أو بالقوة الغاشمة ونموذج لغوي أمراً مُهيباً.

1.3. الإجابة الأكثر احتمالاً ليست الصحيحة

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

هذا سيناريو لعلّك صادفته بنفسك، بافتراض أنك أدركته. خذ تطبيق COBOL دُفعي حقيقي: 233 برنامج، 742 copybook، أكثر من 20 ميغابايت من الكود، مع أداة تاريخ مستدعاة كثيراً، N991DATE. من البيانات الوصفية، الحقيقة المؤكّدة أن 30 برنامجاً يستدعيها. الآن اسأل نموذجاً حدوداً مباشرةً:

اليوم الأوّل. لا يمكنه تحميل كل شيء، لذا يبحث في عبارات CALL الثابتة ويُبلّغ عن 13. حين يُسأل عن الاستدعاءات الديناميكية، يُوسّع regex ويُبلّغ عن 29. الواحد الذي يفوته، CHKOUTB، يعيش في ملف باسم ROCHKOUT.cbl — لأن اسم الملف بالاتفاقية عادةً يطابق PROGRAM-ID الخاص به، لكنّه لا يُشترط أبداً.
اليوم الثاني. نفس السؤال، أساليب مختلفة، والآن يُبلّغ عن 31 — عدّ مبالغ فيه. إيجابي كاذب واحد، N285RODR، يُعلن الحرفي 'N991DATE' في working storage فقط ولا يستخدمه أبداً. يصل النموذج إلى ذلك فقط بعد عدة متابعات.

لا أيٌّ من هذه الأساليب يُعدّ غير معقول. إنها فقط ليست كافية، و"من يستدعي X" واحد من أهمّ الأسئلة أثناء تحليل الأثر وفهم البرنامج. الأسئلة الأكثر تقدّماً التي يطرحها المطوّرون لفهم البرامج والتبعيات — أيّ الجداول تُحدَّث في أكثر من برنامج، أيّ الملفات تُقرأ ولا تُكتب، أيّ المتغيّرات تُغذّي حساب WS-UIT02 في PREMPZ72 — تحتاج تحليلاً كاملاً ودقيقاً لا يمكن للمطابقة بالأنماط تقديمه.

الاستنتاج ليس "النماذج غير مفيدة لفهم برامج mainframe." بل إن جودة استجابة النموذج تتحسّن بشكل كبير مع وجود شيء صحيح للتفكير فيه. النماذج اللغوية تتفوّق في معالجة البيانات.

2. تأسيس Bob في الحقائق لا الاحتمالات

إجابة PP4Z هي التوقّف عن مطالبة النموذج بإعادة بناء النظام من الكود المصدري، وبدلاً من ذلك منحه تمثيلاً حتمياً وقابلاً للاستعلام عن البيئة للتفكير فيه. ثلاثة آليات تؤدّي التأسيس: يُوجَّه النموذج لتحديد الإنشاءات الغامضة لـ z/OS في الطلب نفسه؛ تُثرى الموجّهات بمرجع IBM Z المعتمد ووثائق IBM والمواد المرجعية والعيّنات المُتحقّق منها والمزيد، مع قمع تحيّزات البرمجة العامة بنشاط للحفاظ على التركيز على المنصة المستهدفة؛ ويُعطى النموذج تعليمات للإجابة من البيانات الوصفية للتحليل أوّلاً. النقطة هي جعل الإجابات قابلة للتتبّع إلى نظام IBM Z، لا إلى توزيع التدريب.

2.1. Z Understand: نموذج قابل للاستعلام عن بيئتك

Z Understand هو منصة التحليل الساكن الكامنة تحت PP4Z. تعمل على خادم يصل إلى مصدرك الكامل، وتشحن ماسحات لـ COBOL وPL/I وassembler بالإضافة إلى JCL ومجدوِلات مثل Control-M وTWS، وتعالج آلاف البرامج بالتوازي في مستودع واحد قابل للاستعلام. يحتفظ ببنية حتمية ومتسقة عبر بيئات بـ 10,000+ برنامج.

يُساعد التفكير فيه كـ pipeline مجمِّع بمخرج مختلف: ليس ملفاً تنفيذياً، بل معرفة منظّمة وقابلة للاستعلام — تعريفات البيانات وتدفق التحكّم عبر البرامج والمهام والتدفق الدقيق للبيانات (بما في ذلك REDEFINES وإزاحات الذاكرة) وتفاعلات الأنظمة الفرعية.

2.2. دع النموذج يكتب استعلاماته الخاصة

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

لذلك علّمنا Bob كيف يتجاوز الاستعلامات الجاهزة المقدَّمة ويُولّد ويُشغّل استعلاماته الخاصة ضد البيانات الوصفية. يستند هذا إلى ما تتفوّق فيه النماذج فعلاً — الاستدلال وتوليد الاستعلامات — ويتوسّع بالطريقة التي تتوسّع بها البيانات المنظّمة: سواء كان لديك 10 برامج أو 10,000، الاستعلام واحد؛ فقط مجموعة النتائج تنمو. في الواقع هذا يعني دقة أعلى واتساقاً أكبر عبر التشغيلات واستهلاك أقل للـ tokens، لأن Bob يستدلّ على العلاقات والأنواع ويسحب فقط المقتطفات الدقيقة التي تُشير إليها البيانات الوصفية.

2.3. قابلية التوسّع والماسحات المخصّصة وبيانات وقت التشغيل

التحليل النحوي البحت يُفوّت العلاقات المهمة حين تُخفي الاستدعاءات الديناميكية وتجريدات API والمعالجات المسبقة التدفق الحقيقي. يسدّ إطار Z Understand Extensibility هذه الفجوة:

حلّ استدعاء API / الـ macro يُعيّن الاستدعاءات غير المباشرة والمدفوعة بالمعاملات إلى أهدافها الحقيقية، مستبدلاً حوافّ الاستدعاء العامة بعلاقات caller–callee محدّدة، عبر config بصيغة JSON أو user exits.
قابلية التوسّع في المعالجة المسبقة تُفسّر العبارات غير القياسية مع الحفاظ على عرض المصدر الأصلي، وتُعيّن بنظافة بين الكود قبل وبعد المعالجة المسبقة.
الماسحات المخصّصة تُحضر اللغات المملوكة و4GLs وحتى المصادر غير الكودية إلى نموذج واحد من خلال واجهة JSON مدفوعة بالمخطّط — أنت تتعامل مع التحليل والاستخراج، وZ Understand يتعامل مع التخزين والعلاقات والتحليل.

التحليل الساكن يُخبرك بما يمكن أن يحدث؛ بيانات وقت التشغيل تُخبرك بما حدث. يُحوّل PP4Z المنقّح إلى أداة لجمع البيانات — تتبّع مسارات التنفيذ والتقاط قيم المتغيّرات ومراقبة قرارات الفروع واستدعاءات الأنظمة الفرعية — ويُسلّم تلك المسارات الدقيقة إلى Bob لنوع الإصلاح المعقّد الذي لا تستطيع المدخلات الساكنة وحدها دعمه.

2.4. قاموس البيانات: الصلة على الاكتمال

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

النتيجة المفيدة هنا: التغطية المحدودة كافية. تعريف ما يقارب أعلى 10-20 متغيّراً لكل برنامج يُحسّن الفهم بشكل ملموس دون توثيق شامل. Z Understand Services يؤتمت هذا عبر portfolios كاملة من CLI، ودرجة ثقة تحتفظ فقط بالتعريفات فوق عتبة معيّنة، وخطوة إنسان في الحلقة في IDE تتيح للمطوّرين المراجعة والتصحيح ومحاذاة المخرجات مع المسارد الموجودة.

3. تخصيص Bob لـ Z

التأسيس يمنح Bob حقائق جيدة. التخصيص هو ما يجعله يتصرّف بشكل يمكن التنبّؤ به في بيئة تحتاج مخرجاتها إلى أن تكون قابلة للشرح وعملياتها إلى تلبية متطلبات الحوكمة. PP4Z مبني على أربع قطع: الأوضاع والأدوات والـ skills والـ workflows.

الأوضاع تحدّد الدور والحدود لتدفق تفاعل. وضع المهندس المعماري يُعطي الأولوية للتحليل والتوثيق واكتشاف التبعيات، مع تحريم تعديل الكود صراحةً — حتى لا يتحوّل الاستكشاف بهدوء إلى تغيير. وضع المطوّر مضبوط للتوليد وإعادة البناء مع تطبيق مدمج لمعايير الكود. الحوكمة تعيش في نموذج التفاعل نفسه.
الأدوات تمنح النموذج وصولاً مباشراً إلى المعرفة المنظّمة بالنظام — مسح البرامج واستجواب البيانات الوصفية وبحث قاموس البيانات وخدمات التحليل على مستوى المؤسسة — حتى يستعلم عن حقائق محسوبة مسبقاً بدلاً من الاستنتاج من الكود الخام.
الـ skills تُقنّن الخبرة المتكرّرة في خطوات قابلة للتكرار وخاضعة للمراجعة تُطبَّق في اللحظة المناسبة دون تضخيم السياق. مثلاً تُطبّق skill تخطيط التنفيذ تسلسلاً ثابتاً: الحصول على السياق والتحقق منه، وصياغة المتطلبات وعرض الافتراضات، وتعيين الأثر من البيانات الوصفية، ثم إنتاج خطة محفوظة وقابلة للمراجعة. Bob لا يرتجل الترتيب.
الـ workflows تُضيف تنسيقاً بحالة — إنفاذ الترتيب والتحقق من النتائج الوسيطة والتوقف عند المدخلات السيئة. يتوقّف workflow قاموس البيانات إن لم يجد متغيّرات بدلاً من اختراعها. لا أخطاء صامتة، لا خطوات مُتخطَّاة.

تُطبَّق المعايير والحوكمة بشكل افتراضي من خلال قواعد agents.md على مستوى المستودع — بدون بنية تحتية إضافية. ولأن IBM تشحن هذه الـ skills والـ workflows في الصندوق، لا تبدأ من صفحة بيضاء: إنها تُرمّز نهج IBM الخاص لـ COBOL وPL/I وz/OS middleware والتحديث. يمكن لـ skill معايير الكود تعلّم اتفاقياتك مباشرةً من قاعدة الكود أو استيعاب وثيقة معاييرك الموجودة وتحويلها إلى skill تطبيق مُطبَّقة على كل تفاعل يُنتج كوداً. يمكنك أيضاً تأليف skills الخاصة بك دون كتابة كود.

حين تتركّب هذه العناصر، يمكن لموجّه واحد قيادة مهمة شاملة:

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

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

4. ما يمكنك بناؤه اليوم

توثيق لا يتقادم. تعامل مع الوثائق كمصنوعة مولّدة مُرسَّخة في بيانات وصفية حتمية بالإضافة إلى سياق المصدر ووقت التشغيل — قابلة للتوليد عند الطلب ومحاذاة للنظام الحالي، لا لقطة من ثلاث سنوات مضت.
انتقال COBOL إلى Java حتمي على z/OS. تفشل عمليات إعادة الكتابة حين تُعامَل التكافؤية الوظيفية كتقريبية؛ حساب الرهن العقاري لا بدّ أن يُعيد النتيجة ذاتها رغم الاختلافات في التقريب ودلالات وقت تشغيل COBOL. يستخدم PP4Z البيانات الوصفية كعمود فقري للتحويل، ويبني نماذج موازية للمصدر والهدف حتى تكون البنية قابلة للإعادة والمنطق التجاري مُعيَّناً بدقة لا مُلخَّصاً والتحقق من الدرجة الأولى — يُولّد حالات اختبار من سلوك المصدر لإثبات التكافؤية.
إعادة بناء مستهدفة واستخراج الدوال. يُنتج Bob قائمة مرتّبة من مرشّحي إعادة البناء مُشرَّحة بالوظيفة التجارية، ثم يستخرج وحدات مستقلة ذاتياً بمدخلات ومخرجات واضحة وإمكانية تتبّع للأصل ونصائح تكامل — مع الحفاظ على استثمارك في COBOL.
أدوات z/OS الأصلية. قدرات Z Open Editor المرخّصة بالإضافة إلى أدوات MCP جديدة: Dependency Based Build (DBB) لتشغيل عمليات البناء على z/OS من IDE، وZ Code Scan لفحوصات الجودة القائمة على القواعد وإصلاحاتها داخل workflows Bob، وIBM Debug for z/OS لتحويل جلسات debug المباشرة إلى تحليل سبب جذري مدعوم بالذكاء الاصطناعي.

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

5. كيفية الحصول على الوصول

Bob Premium Package for Z (PP4Z) إضافة لـ IBM Bob، لا منتج منفصل يحتاج تحميلاً. PP4Z يعمل ضد بيئة mainframe مباشرة داخل بيئة مؤسسية، لا يوجد checkout ذاتية الخدمة — الاستحقاق بقيادة المبيعات.

ابدأ مع ممثّل IBM الخاص بك، أو استخدم "تواصل مع المبيعات" على bob.ibm.com. يُعدّون خطة IBM Bob الأساسية وإضافة Z لمؤسستك.
بمجرّد أن يعيّن مسؤول Bob مقعداً بإضافة Z، يُكتشف الاستحقاق عند استخدام IBM Bob. ثبّت Bob IDE وسجّل الدخول، وستظهر الأوضاع والـ skills والأدوات الخاصة بـ Z.

6. ابدأ

إن كنت تُشغّل Bob بالفعل، يُضيف PP4Z الأوضاع والـ skills والأدوات الخاصة بـ Z فوق ما لديك.
استخدم قدرة الفهم المدمجة للحصول على رؤى أعمق في الكود بـ workspace الخاص بك.
وجّه Z Understand نحو تطبيق حقيقي يمكن أن يتجاوز workspace الخاص بك — مكان تعرف فيه الإجابات الصحيحة بالفعل — وتحقّق من تحليل Bob مقابل حقيقتك الثابتة.
ابدأ بسؤال لم تحصل على إجابة مباشرة عليه: من يستدعي هذه الأداة فعلاً، أيّ الجداول تلمس هذه المهمة، ماذا يعني هذا المتغيّر؟
اطرح أسئلة أكثر تحدّياً تمزج البيانات والاستدلال: "أعطني مخطّط استدعاء مع مخطّطات منظّمة حسب الموضوعات"

روابط