هل كان هناك شيء في كوبول جوهريا جعله عرضة لقضايا Y2K؟

Question

أعلم أن الكثير من جهود / تخويف Y2K كانت تركز بطريقة أو بأخرى على COBOL، بجدية أم لا. (هيك، رأيت علة Y2K طفيفة في نصوص بيرل التي كسرت 1/1/2000)

ما يهمني، هل كان هناك شيء محدد بك كوليك ككون لغة جعله عرضة لقضايا Y2K؟

وهذا يعني، على عكس عمر معظم البرامج المكتوبة فيه، والاحتياجات اللاحقة إلى تفاخر على استخدام الذاكرة / القرص مدفوعة بالأجهزة القديمة وحقيقة أنه لم يتوقع أي شخص أن هذه البرامج للبقاء على قيد الحياة لمدة 30 عاما؟

أنا سعيد تماما إذا كانت الإجابة "لا شيء خاص بك من كوليك بخلاف العمر" - مجرد فضول، لا يعرف شيئا عن كوبول.

Answer 1

نعم ورقم في COBOL، اضطررت إلى إعلان المتغيرات بحيث كان عليك بالفعل أن تقول عدد الأرقام الموجودة في عدد IE، YEAR PIC 99 أعلن المتغير YEAR بحيث لا يمكن أن تعقد فقط رقما عشريا. نعم، كان من الأسهل اتخاذ هذا الخطأ مما كانت عليه في ج int أو short أو char في السنة ولا يزال لديك مساحة كبيرة لسنوات أكبر من 99. بالطبع لا يحميك من printfعمل 19%d في C وما زلت تواجه مشكلة في الإخراج الخاص بك، أو جعل الحسابات الداخلية الأخرى القائمة على التفكير في السنة ستكون أقل من 99 أو تساوي 99.

Answer 2

كان 80٪ عن سعة التخزين، نقية وبسيطة.

الناس لا يدركون أن قدرة القرص الصلب المحمول الخاص بهم اليوم سيكون لها تكلفة ملايين في عام 1980. تعتقد أن إنقاذ بايتين سخيف؟ ليس عندما يكون لديك 100000 سجل عملاء وعصي صلب بحجم الثلاجة عقدت 20 ميغا بايت وتتطلب غرفة خاصة للحفاظ على بارد.

Answer 3

يبدو أن أكثر مشكلة في الأشخاص الذين لا يعرفون كم من الوقت سيتم استخدام رمزهم، لذلك اختاروا استخدام سنوات مكونة من رقمين.

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

Answer 4

هل كان هناك شيء في كوبول جوهريا جعله عرضة لقضايا Y2K؟

مبرمجون¹. وبعد والأنظمة التي تعمل فيها برامج COBOL².

---

_{1: لم يتم تصميمهم إلى الأمام يبحثون عن 30 عاما. لا أستطيع إلقاء اللوم عليهم حقا. إذا كان لدي قيود على الذاكرة، بين الضغط على 2 بايت في التاريخ وجعلها تعمل 30 عاما على الأرجح، على الأرجح سأجعل نفس القرار.}

2: قد يكون للأنظمة نفس المشكلة إذا تخزين الأجهزة السنة في رقمين.

Answer 5

السؤال الرائع. ما هي مشكلة Y2K، في جوهرها؟ إنها مشكلة لا تحدد الكون الخاص بك بما فيه الكفاية. لم تكن هناك محاولة جادة لنموذج جميع التواريخ، لأن المساحة كانت أكثر أهمية (وسيتم استبدال التطبيقات بحلول ذلك الوقت) لذلك في COBOL في كل مستوى، هذا مهم: أن تكون فعالة وليس overdeClare الذاكرة التي تحتاجها، سواء في المتجر وعلى مستوى البرنامج.

حيث تكون الكفاءة مهمة، نلتزم بأخطاء Y2Kish ... نقوم بذلك في كل مرة نقوم بتخزين موعد في DB دون زمن الزمن. تخضع التخزين الحديث لذلك بالتأكيد أخطاء Y2Kish، لأننا نحاول أن نكون فعالين مع المساحة المستخدمة (على الرغم من أن أراهن أنه أكثر تقدما في العديد من الحالات، خاصة في مستوى المبالغة - كل شيء).

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

لغات أحدث مع ألعاب البيانات المدمجة (والتسهيلات) للعديد من الأشياء مثل التاريخ، وكذلك الذاكرة الضخمة للعب مع، والمساعدة في تجنب الكثير من مشاكل Y2Kish المحتملة.

Answer 6

كان جزءان. 1- العمر / طولها من برامج COBOL، و 2- الحد 80 حرف سجلات البيانات.

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

ثانيا، تم تقييد COBOL إلى 80 حرفا لكل سجل للبيانات (نظرا لحجم بطاقات لكمة!)، كان المطورون في ضغط أكبر للحد من حجم الحقول. لأنهم أحسبوا "عام 2000 لن يكونوا هنا حتى أنا طويل متقاعد!" كانت الأحرف 2 من البيانات المحفوظة ضخمة!

Answer 7

كان أكثر متعلقة بتخزين السنة في عناصر البيانات التي قد تعقد فقط قيم من 0 إلى 99 (حرفين، أو رقمين عشريين، أو بايت واحد). أن الحسابات التي قدمت افتراضات مماثلة حول قيم السنة.

كان بالكاد شيء خاص كوبول. تأثرت الكثير من البرامج.

Answer 8

كانت هناك بعض الأشياء حول COBOL التي تفاقم الوضع.

• انها قديمة، لذلك استخدام رمز المكتبة، المزيد من كل شيء
• إنه قديم، لذلك الإنترنت قبل الإنترنت، التواصل قبل الاجتماعية، أكثر من أطر أقل، وأكثر أشياء مخصصة
• انها قديمة، لذلك، أقل مجردة، من المرجح أن يكون لها حلول مفتوحة مشفرة
• إنه قديم، لذلك، العودة بعيدا بما فيه الكفاية وحفظ 2 بايت قد يكون، نوع من، كان مهما
• انها قديمة، لذلك، لذلك يستعد SQL. حتى برنامج التشغيل القديم قد فهرست ملفات القرص الموجهة إليه السجلات لجعل برنامج قاعدة البيانات المتداول-الخاص بك - كل برنامج أسهل قليلا.
• "طباعة" سلاسل تنسيق وإعلان نوع البيانات كانت نفس الشيء، كل شيء كان ن الأرقام

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

Answer 9

كوبول لم يأت أبدا مع أي مكتبة معالجة التاريخ القياسية.

لذلك كلها ترميز محلولهم الخاصة.

كانت بعض الحلول سيئة للغاية مقابل الألفية. معظم هذه الحلول السيئة لم تكن مهمة لأن التطبيقات لم تعيش 40 عاما. لا تتسبب الأقلية الصغيرة في الحلول السيئة في مشكلة Y2K المعروفة في عالم الأعمال.

(كانت بعض الحلول أفضل. أعرف أن أنظمة COBOL التي ترميزها في الخمسينيات من الخمسينيات بتنسيق تاريخ جيد حتى 2027 - يجب أن يبدو إلى الأبد في ذلك الوقت؛ وأنا مصممة الأنظمة في 1970s جيدة حتى عام 2079).

ومع ذلك، كان لدى COBOL نوع التاريخ القياسي ....

03 ORDER-DATE     PIC DATE.

.

الأخلاقية: استخدم اللغات مع المكتبات القياسية.

Answer 10

لم يكن لدى COBOL 85 (المعيار 1985) والإصدارات السابقة أي طريقة للحصول على القرن الحالي **، والتي كانت أحد العوامل الواردة في COBOL التي تثبط استخدام السنوات المكونة من 4 أرقام حتى بعد أن لم تعد مساحة تخزين إضافية 2 بحياء قضية.

** قد يكون تطبيقات محددة ملحقات غير قياسية لهذا الغرض.

Answer 11

كانت القضية الجوهرية الوحيدة مع COBOL هي بيان قياسي الأصلي (أواخر الستينيات) لاسترداد تاريخ النظام الحالي، الذي كان:

ACCEPT todays-date FROM DATE

تم إرجاع هذا الرقم المكون من 6 أرقام مع تاريخ تنسيق YYMMDD.

ومع ذلك، حتى أن هذه ليست بالضرورة مشكلة حيث كتبنا رمز في التسعينيات باستخدام هذا البيان الذي تم التحقق منه للتو ما إذا كان جزء السنة أقل من 70 عاما وفترض أن التاريخ كان 20yy، مما كان قد جعلته مشكلة Y2K070. :-)

تم تمديد المعيار لاحقا (COBOL-85، وأعتقد أنه) حتى تتمكن من طلب التاريخ بتنسيقات مختلفة، مثل:

ACCEPT todays-date FROM CENTURY-DATE

الذي أعطاك رقم مكون من 8 أرقام مع تاريخ ccyymmdd.

كما أشرك، وأشار آخرون، سمحت العديد من لغات برمجة الكمبيوتر الأخرى بتمثيل "Lossy" للتواريخ / السنوات.

Answer 12

كانت المشكلة حقا عن قيود الذاكرة والتخزين في أواخر 70s في أوائل الثمانينات.

عندما كان لدى ربع جهاز الكمبيوتر الخاص بك بمبلغ مليون دولار 128k و 4 أقراص يبلغ مجموعها حوالي 6 ميغابايت، يمكنك إما أن تطلب من إدارتك عن طاحنة ربع أخرى لآلة 256 كيلو بايت مع 12 ميج من تخزين القرص أو تكون فعالة للغاية حول الفضاء.

لذلك تم استخدام جميع أنواع الحيل لتوفير المساحة. وكان المفضل لدي لتخزين تاريخ YYMMDD ك 991231 في حقل عشري معبأ X'9912310C "ثم طرق البايت الأخير وتخزينه باسم" 991231 ". لذلك بدلا من 6 بايت، كنت تولى فقط 3 بايت.

وشملت الحيل الأخرى بعض نوع Hokey Hokey Type مقابل الأسعار - رمز 12 -> $ 19.99.