تجربة ترحيل Cobol/PL1 القديم إلى Java

Question

السؤال الأصلي:أتساءل عما إذا كان لدى أي شخص خبرة في ترحيل قاعدة بيانات كبيرة من Cobol/PL1 إلى Java؟

ما مدى أتمتة العملية وما مدى إمكانية صيانتها؟

كيف تم الانتقال من المعاملات إلى OO؟

سيكون موضع تقدير أي دروس مستفادة على طول الطريق أو موارد/أوراق بيضاء قد تكون ذات فائدة.

---

تحرير 7/7: من المؤكد أن نهج NACA مثير للاهتمام، فالقدرة على الاستمرار في إجراء تغييرات BAU الخاصة بك على كود COBOL حتى نقطة إصدار إصدار JAVA لها ميزة لأي مؤسسة.

تعد الحجة الخاصة بـ Java الإجرائية بنفس تخطيط COBOL لمنح المبرمجين إحساسًا بالراحة أثناء التعرف على لغة Java حجة صالحة لمؤسسة كبيرة ذات قاعدة تعليمات برمجية كبيرة.كما يشير @Didier، فإن التوفير السنوي البالغ 3 ملايين دولار يمنح مجالًا لحشوة سخية على أي تغييرات في BAU من الآن فصاعدا لإعادة بناء الكود على أساس مستمر.وعلى حد تعبيره، إذا كنت تهتم بموظفيك، فإنك تجد طريقة لإبقائهم سعداء بينما تتحدىهم تدريجياً.

المشكلة كما أراها مع الاقتراح المقدم من @duffymo إلى

من الأفضل محاولة فهم المشكلة حقًا في جذورها وإعادة التعبير عنها كنظام موجه للكائنات

هو أنه إذا كان لديك أي تغييرات في BAU مستمرة، فخلال عمر المشروع الطويل لترميز نظام OO الجديد الخاص بك، سينتهي بك الأمر إلى ترميز واختبار التغييرات بشكل مزدوج.وهذه فائدة كبيرة لنهج NACA.لقد اكتسبت بعض الخبرة في ترحيل تطبيقات Client-Server إلى تطبيق الويب وكانت هذه إحدى المشكلات الرئيسية التي واجهناها، حيث كانت المتطلبات تتغير باستمرار بسبب تغييرات BAU.لقد جعل من PM والجدولة تحديًا حقيقيًا.

شكرًا لـhhafez الذي تم وضع تجربته بشكل جيد "مشابهة ولكن مختلفة قليلا" ولديه تجربة مرضية إلى حد معقول فيما يتعلق بالترحيل التلقائي للتعليمات البرمجية من Ada إلى Java.

شكرًا @Didier على مساهمتك، ما زلت أدرس منهجك وإذا كان لدي أي أسئلة فسأرسل لك رسالة.

Answer 1

تحديث 25/6: ركض صديق للتو عبر ناكا كوبول لتحويل جافا.يبدو الأمر مثيرًا للاهتمام، فقد تم استخدامه لترجمة 4 ملايين سطر من Cobol بدقة 100%.هنا صفحة مشروع NACA مفتوحة المصدر.كانت المحولات الأخرى التي رأيتها مملوكة، وكانت المواد تفتقر بشكل واضح إلى قصص النجاح وأمثلة التعليمات البرمجية التفصيلية.NACA تستحق نظرة طويلة.

التحديث 7/4: أفادIra Baxter أن مخرجات Java تبدو مشابهة جدًا لـ Cobol، وهو ما يحدث تمامًا.بالنسبة لي، هذه هي النتيجة الطبيعية للترجمة الآلية.أشك في أننا سنجد مترجمًا أفضل بكثير.ولعل هذا يدعو إلى اتباع نهج تدريجي لإعادة الكتابة.

تحديث 2/7/11: يشير @spgennard إلى وجود بعض مترجمات Cobol على JVM، على سبيل المثال Veryant's هوكوبول تتطور.يمكن استخدام هذه للمساعدة في نقل قاعدة التعليمات البرمجية تدريجيًا، على الرغم من أنني أعتقد أن OP كان مهتمًا أكثر بتحويل المصدر الآلي.

---

سأكون حذرا جدا بشأن هذا.(كنت أعمل في شركة تعمل تلقائيًا تصحيح برامج Cobol وPL/I لـ Y2K، وقامت بإنشاء مترجم الواجهة الأمامية الذي حول العديد من لهجات Cobol إلى نموذجنا التحليلي الوسيط، وكذلك مولد الأكواد.) إحساسي هو أنك ستنتهي بقاعدة أكواد Java التي لا تزال سيكون غير أنيق وغير مرضي للعمل معه.قد ينتهي بك الأمر إلى مواجهة مشكلات في الأداء، والتبعيات على المكتبات التي يوفرها البائع، والتعليمات البرمجية التي تولد أخطاء، وما إلى ذلك.ستتحمل بالتأكيد فاتورة اختبار ضخمة.

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

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

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

Answer 2

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

كان أحد أهم أهدافنا هو إبقاء المطورين الأوائل على متن الطائرة:هذه هي الطريقة التي وجدناها لتحقيق ذلك.عندما يتم ترحيل التطبيق إلى Java، يمكن لهؤلاء الأشخاص البدء في جعله أكثر OO أثناء تطويره/إعادة هيكلته.

إذا كنت لا تهتم بهجرة الناس، يمكنك استخدام استراتيجية أخرى.

كما أدى هذا التحويل من 1 إلى 1 إلى جعل التحويل الآلي بنسبة 100% أسهل وأسرع:والنتيجة الجيدة هي أننا حققنا مدخراتنا المتكررة (3 ملايين يورو سنويًا) بشكل أسرع بكثير:نحن نقدر 12-18 شهرا.من الواضح أنه يمكن إعادة استثمار هذه المدخرات المبكرة في إعادة هيكلة OO

لا تتردد في الاتصال بي:didier.durand@publicitas.com أو mediaandtech@gmail.com

ديدييه

Answer 3

تجربتي مماثلة ولكنها مختلفة قليلا.لدينا قاعدة أكواد كبيرة وقديمة في Ada (0.5Mloc على مدار أكثر من 15 عامًا) والتي تم تحويلها مؤخرًا إلى Java.وقد تم الاستعانة بمصادر خارجية لشركة قدمت مزيجًا من التحويل الآلي/اليدوي.لقد أجروا أيضًا اختبارات للتحقق من أن نظامي Ada وJava يتصرفان بنفس الطريقة.

تمت كتابة بعض أجزاء منه في Ada 95 (على سبيل المثال، كان هناك إمكانية لـ OOP) ولكن معظمها لم يكن كذلك

الآن، نعم، لا يرقى الكود إلى نفس معايير الكود المكتوب بلغة Java في المقام الأول ولكننا نستخدمه منذ ذلك الحين بنجاح (18 شهرًا حتى الآن) دون أي مشكلات كبيرة.الميزة الرئيسية التي حصلنا عليها هي أنه يمكننا الآن العثور على المزيد من المطورين للحفاظ على قاعدة التعليمات البرمجية لدينا بالمهارات اللازمة لإنتاج تعليمات برمجية قابلة للصيانة.(يمكن لأي شخص التطوير بلغة Ada ولكن مثل أي لغة أخرى إذا لم تكن لديك الخبرة فيها، فقد ينتهي بك الأمر برمز لا يمكن صيانته)

Answer 4

من وجهة نظر تجنب المخاطر، فإن نهج NACA منطقي تمامًا.إعادة استخدام أدواتهم قد لا.لقد استخدموا تطوير الأدوات لجعل موظفيهم يواكبون السرعة في جافا ولينكس.

لن تكون نتيجة تحويل NACA جيدة بما فيه الكفاية، أو حتى OO، وتجعل من الصعب توظيف أشخاص جدد.ولكنه قابل للاختبار، ويمكن إعادة هيكلته، ويمكنك توصيل مترجمين أفضل.

[edit] Ira, you don't seem to be very risk-aware.

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

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

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

• سيقوم المبرمجون القدامى بتغيير مدخلات كوبول؛
• سوف تغير برامج جافا الجديدة المترجم.

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

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

• مكونات إدخال كوبول.
• OO مكونات إدخال جافا؛
• مكونات إخراج نمط كوبول.
• مكونات إخراج نمط OO.

قد ترغب في قراءة:بيتر فان دن هامر وكيس ليبوتر (1996) إدارة بيانات التصميم:الأبعاد الخمسة لأطر CAD، وإدارة التكوين، وإدارة البيانات، وقائع IEEE، المجلد.84، لا.1 يناير 1996

نقل منصات COBOL] يمكن أن يكون الانتقال من COBOL على جهاز الكمبيوتر الرئيسي إلى COBOL على Windows/Linux استراتيجية قابلة للحياة لفريق NACA ، ولكن السؤال كان حول الانتقال إلى Java.إذا كان الهدف على المدى الطويل هو الحصول على نظام تشغيل خارجي حديث، والوصول إلى هناك بأقل قدر ممكن من المخاطر التشغيلية، فإن نهج NACA سليم.إنها الخطوة الأولى فقط.سيتبع ذلك الكثير من إعادة الهيكلة.

Answer 5

أنا مندهش من عدم ذكر أحد لمجموعة أدوات إعادة هندسة برامج DMS الخاصة بـ Semantic Design.لقد بحثت في تحويل COBOL في الماضي.كنت أعمل على "البرمجة التلقائية" في ذلك الوقت.قبل أن أكتب مترجمًا، بحثت عن مجموعة من الجهود والمنتجات السابقة في هذا المجال.كانت الأداة المستندة إلى GLR من Semantic Designs هي الأفضل في المجموعة.

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

http://www.semdesigns.com/Products/DMS/DMSToolkit.html

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

Answer 6

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

تحظى فكرة الترجمة الآلية بشعبية كبيرة، حتى تحاول تحويل شيء ما.عادة ما تكون النتيجة فظيعة وغير قابلة للاستمرار.إنه غير قابل للصيانة أكثر من التطبيق المعقد الأصلي.من وجهة نظري، كل أداة تتيح الترجمة الآلية من اللغة القديمة إلى اللغة الحديثة موجهة نحو التسويق بشكل كبير:فهو يوضح بالضبط ما يريد الناس سماعه "ترجمة تطبيقك من...إلى Java مرة واحدة، وتنسى!"، مما يعني أنك تشتري عقدًا، ثم تدرك أنك تعتمد بشدة على الأداة (لأنه لا يمكنك إجراء أي تغيير على تطبيقك بدونها!).

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

أعرف القليل عنها منضدة التحديث التاريخ قبل أن تشتريها شركة Microfocus العام الماضي وتنقل التطوير إلى دولة أخرى.كان هناك عدد كبير من أدوات التحليل المعقدة وعدد من اللغات المستهدفة المدعومة (بما في ذلك Java).ولكن لم يستخدم أي عميل بالفعل إنشاء التعليمات البرمجية تلقائيًا، لذلك تم تجميد تطوير جزء التوليد.بقدر ما أعرف، تم تنفيذ دعم PL/I في الغالب، لكنه لم ينته أبدًا.ولكن لا يزال بإمكانك المحاولة، ربما يكون هذا هو ما تبحث عنه.

Answer 7

لقد ألقيت نظرة للتو على صفحة NACA والمستندات.من وثائقهم:

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

لم أر مثالا، ولكن الاقتباس يعطي نكهة قوية للنتيجة.تم ترميز COBOL الخاص بها بلغة Java.

(لا عجب أن هذا الشيء يسمى "Transcoder"؛لم أسمع هذا المصطلح من قبل).

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

السماء تساعد الناس الذين وقعوا ضحية لهذه الأداة.

تحرير مايو 2010:لقد وجدت مثالاً على مخرجات NACA؛واحد من هُمحالات تجريبية.هذا هو JOBOL الرائع للغاية.إنه شيء جيد هم حفظ مبرمجي COBOL الخاصة بهم ولا يريدون توظيف أي مبرمجين Java.كما تقرأ هذا ، تأكد من أنك تتذكر هذا جافا شفرة.

/*
 * NacaRTTests - Naca Tests for NacaRT support.
 *
 * Copyright (c) 2005, 2006, 2007, 2008 Publicitas SA.
 * Licensed under GPL (GPL-LICENSE.txt) license.
 */

import idea.onlinePrgEnv.OnlineProgram;
import nacaLib.varEx.*;

public class TestLong extends OnlineProgram
{
  DataSection WorkingStorage = declare.workingStorageSection();

  Var W3 = declare.level(1).occurs(10).var();
  Var V9Comp010 = declare.level(5).pic9(10).var();
  Var V9Comp014V4 = declare.level(5).pic9(14, 4).var();
  Var VX10 = declare.level(5).picX(10).var();

  public void procedureDivision()
  {
    setAssertActive(true);

    move("9876543210", VX10);
    assertIfDifferent("9876543210", VX10);

    move(VX10, V9Comp010);
    long l = V9Comp010.getLong();
    assertIfFalse(l == 9876543210L);

    multiply(1000, V9Comp010).to(V9Comp014V4);
    assertIfFalse(9876543210000L == V9Comp014V4.getLong());

    String cs = V9Comp010.toString();
    cs = V9Comp014V4.toString();
    assertIfDifferent("9876543210000.0000", V9Comp014V4);

    inc(V9Comp010);
    assertIfFalse(9876543211L == V9Comp010.getLong());

    CESM.returnTrans();
  }

أطفال:ويتم ذلك فقط من قبل المتخصصين.لا تحاول هذا في المنزل.