پروگرامرز اور انجینئرز کی لوک داستان (حصہ 1)

یہ انٹرنیٹ سے کہانیوں کا ایک انتخاب ہے کہ کس طرح کیڑے کبھی کبھی مکمل طور پر ناقابل یقین مظہر ہوتے ہیں۔ شاید آپ کو بھی کچھ کہنا ہے۔

ونیلا آئس کریم سے کار کی الرجی۔

انجینئرز کے لئے ایک کہانی جو سمجھتے ہیں کہ واضح ہمیشہ جواب نہیں ہوتا ہے، اور اس سے کوئی فرق نہیں پڑتا ہے کہ حقائق کتنے ہی دور کی بات لگیں، وہ اب بھی حقائق ہیں۔ جنرل موٹرز کارپوریشن کے پونٹیاک ڈویژن کو ایک شکایت موصول ہوئی:

یہ دوسری بار ہے جب میں آپ کو لکھ رہا ہوں، اور میں آپ کو جواب نہ دینے کا الزام نہیں لگاتا، کیونکہ یہ پاگل لگتا ہے۔ ہمارے خاندان میں ہر رات کھانے کے بعد آئس کریم کھانے کی روایت ہے۔ آئس کریم کی اقسام ہر بار بدلتی رہتی ہیں اور رات کے کھانے کے بعد پورا خاندان اس بات کا انتخاب کرتا ہے کہ کون سی آئس کریم خریدنی ہے، جس کے بعد میں دکان پر جاتی ہوں۔ میں نے حال ہی میں ایک نیا Pontiac خریدا ہے اور اس کے بعد سے آئس کریم حاصل کرنے کے لیے میرا سفر ایک مسئلہ بن گیا ہے۔ آپ نے دیکھا، جب بھی میں ونیلا آئس کریم خریدتا ہوں اور اسٹور سے واپس آتا ہوں، گاڑی اسٹارٹ نہیں ہوتی۔ میں کوئی اور آئس کریم لاؤں تو گاڑی بغیر کسی پریشانی کے اسٹارٹ ہو جاتی ہے۔ میں ایک سنجیدہ سوال پوچھنا چاہتا ہوں، چاہے یہ کتنا ہی احمقانہ کیوں نہ ہو: "پونٹیاک کے بارے میں ایسا کیا ہے کہ جب میں ونیلا آئس کریم لاتا ہوں تو یہ شروع نہیں ہوتا، لیکن جب میں آئس کریم کا دوسرا ذائقہ لاتا ہوں تو آسانی سے شروع ہوتا ہے؟"

جیسا کہ آپ تصور کر سکتے ہیں، ڈویژن کے صدر کو خط کے بارے میں شبہ تھا۔ تاہم، صرف اس صورت میں، میں نے ایک انجینئر کو چیک کرنے کے لیے بھیجا تھا۔ وہ حیران تھا کہ اس کی ملاقات ایک خوبصورت علاقے میں رہنے والے ایک امیر، پڑھے لکھے آدمی سے ہوئی۔ وہ رات کے کھانے کے فوراً بعد ملنے پر راضی ہو گئے تاکہ وہ دونوں آئس کریم کے لیے دکان پر جا سکیں۔ اس شام یہ ونیلا تھا، اور جب وہ گاڑی پر واپس آئے تو یہ شروع نہیں ہو گی۔

انجینئر تین اور شام کو آیا۔ پہلی بار آئس کریم چاکلیٹ تھی۔ گاڑی اسٹارٹ ہوئی۔ دوسری بار اسٹرابیری آئس کریم تھی۔ گاڑی اسٹارٹ ہوئی۔ تیسری شام اس نے ونیلا لینے کو کہا۔ گاڑی اسٹارٹ نہیں ہوئی۔

عقلی طور پر استدلال کرتے ہوئے، انجینئر نے یہ ماننے سے انکار کر دیا کہ کار کو ونیلا آئس کریم سے الرجی تھی۔ اس لیے میں نے کار کے مالک سے اتفاق کیا کہ جب تک اسے مسئلہ کا کوئی حل نہیں مل جاتا وہ اپنے دورے جاری رکھے گا۔ اور راستے میں، وہ نوٹ لینے لگا: اس نے تمام معلومات لکھیں، دن کا وقت، پٹرول کی قسم، دکان سے آنے اور واپسی کا وقت وغیرہ۔

انجینئر کو جلد ہی احساس ہوا کہ کار کے مالک نے ونیلا آئس کریم خریدنے میں کم وقت صرف کیا۔ وجہ دکان میں سامان کی ترتیب تھی۔ ونیلا آئس کریم سب سے زیادہ مقبول تھی اور اسے اسٹور کے سامنے ایک علیحدہ فریزر میں رکھا گیا تھا تاکہ اسے تلاش کرنا آسان ہو۔ اور باقی تمام اقسام سٹور کے پچھلے حصے میں تھیں، اور صحیح قسم تلاش کرنے اور ادائیگی کرنے میں بہت زیادہ وقت لگا۔

اب سوال انجینئر کا تھا کہ اگر انجن بند ہونے کے بعد سے کم وقت گزر گیا تو گاڑی اسٹارٹ کیوں نہیں ہوئی؟ چونکہ مسئلہ ونیلا آئس کریم کا نہیں بلکہ وقت کا تھا، اس لیے انجینئر کو جلدی سے جواب مل گیا: یہ گیس کا تالا تھا۔ یہ ہر شام ہوتا تھا، لیکن جب کار کے مالک نے آئس کریم کی تلاش میں زیادہ وقت صرف کیا، تو انجن کافی ٹھنڈا ہونے میں کامیاب ہوگیا اور آسانی سے اسٹارٹ ہوگیا۔ اور جب اس شخص نے ونیلا آئس کریم خریدی تو انجن ابھی بھی بہت گرم تھا اور گیس لاک کو تحلیل ہونے کا وقت نہیں تھا۔

اخلاقی: یہاں تک کہ مکمل طور پر پاگل مسائل بھی کبھی کبھی حقیقی ہوتے ہیں۔

حادثے Bandicoot

اس کا تجربہ کرنا تکلیف دہ ہے۔ ایک پروگرامر کے طور پر، آپ اپنے کوڈ کو پہلے، دوسرے، تیسرے... پر الزام لگانے کے عادی ہو جاتے ہیں اور دس ہزارویں نمبر پر آپ کمپائلر پر الزام لگاتے ہیں۔ اور فہرست میں مزید نیچے آپ پہلے ہی سامان کو مورد الزام ٹھہراتے ہیں۔

ہارڈ ویئر بگ کے بارے میں میری کہانی یہ ہے۔

Crash Bandicoot گیم کے لیے، میں نے میموری کارڈ میں لوڈ اور محفوظ کرنے کے لیے کوڈ لکھا۔ اس طرح کے سمگ گیم ڈویلپر کے لیے، یہ پارک میں چہل قدمی کی طرح تھا: میں نے سوچا کہ اس کام میں کئی دن لگیں گے۔ تاہم، میں نے چھ ہفتوں تک کوڈ کو ڈیبگ کرنا ختم کیا۔ راستے میں، میں نے دیگر مسائل کو حل کیا، لیکن ہر چند دنوں میں میں چند گھنٹوں کے لئے اس کوڈ پر واپس آیا. یہ اذیت تھی۔

علامت اس طرح نظر آتی تھی: جب آپ گیم کے موجودہ پلے تھرو کو محفوظ کرتے ہیں اور میموری کارڈ تک رسائی حاصل کرتے ہیں، تو سب کچھ تقریباً ہمیشہ ٹھیک ہوجاتا ہے... لیکن بعض اوقات بغیر کسی واضح وجہ کے پڑھنے یا لکھنے کے آپریشن کا ٹائم آؤٹ ہوجاتا ہے۔ ایک مختصر ریکارڈنگ اکثر میموری کارڈ کو نقصان پہنچاتی ہے۔ جب کوئی کھلاڑی بچانے کی کوشش کرتا ہے تو وہ نہ صرف بچانے میں ناکام رہتا ہے بلکہ نقشہ کو بھی تباہ کر دیتا ہے۔ گھٹیا.

تھوڑی دیر بعد، سونی میں ہمارے پروڈیوسر، کونی بس، گھبرانے لگے۔ ہم اس بگ کے ساتھ گیم نہیں بھیج سکے، اور چھ ہفتے بعد میں سمجھ نہیں پایا کہ مسئلہ کیا ہے۔ کونی کے ذریعے، ہم نے PS1 کے دوسرے ڈویلپرز سے رابطہ کیا: کیا کسی کو بھی ایسی ہی کسی چیز کا سامنا ہوا ہے؟ نہیں. میموری کارڈ کے ساتھ کسی کو کوئی مسئلہ نہیں تھا۔

جب آپ کے پاس ڈیبگنگ کے لیے کوئی آئیڈیا نہیں ہوتا ہے، تو صرف "تقسیم اور فتح" کا طریقہ باقی رہ جاتا ہے: ناقص پروگرام سے زیادہ سے زیادہ کوڈ ہٹائیں جب تک کہ نسبتاً چھوٹا سا ٹکڑا باقی نہ رہ جائے جو اب بھی مسئلہ کا باعث بنتا ہے۔ یعنی، آپ پروگرام کو ٹکڑے ٹکڑے کر دیتے ہیں جب تک کہ وہ حصہ جس میں بگ موجود ہے باقی نہ رہے۔

لیکن بات یہ ہے کہ ویڈیو گیم سے ٹکڑوں کو کاٹنا بہت مشکل ہے۔ اگر آپ نے کشش ثقل کی تقلید کرنے والے کوڈ کو ہٹا دیا تو اسے کیسے چلائیں؟ یا ڈرائنگ کردار؟

لہذا، ہمیں پورے ماڈیولز کو ایسے اسٹبس سے بدلنا ہوگا جو کچھ مفید کام کرنے کا بہانہ کرتے ہیں، لیکن درحقیقت بہت آسان کام کرتے ہیں جس میں غلطیاں نہیں ہوسکتیں۔ کم از کم کام کے لیے ہمیں ایسی بیساکھی لکھنی پڑتی ہے۔ یہ ایک سست اور تکلیف دہ عمل ہے۔

مختصر میں، میں نے یہ کیا. میں نے کوڈ کے زیادہ سے زیادہ ٹکڑوں کو ہٹا دیا جب تک کہ میرے پاس ابتدائی کوڈ باقی نہ رہ جائے جو سسٹم کو گیم چلانے کے لیے ترتیب دیتا ہے، رینڈرنگ ہارڈویئر کو شروع کرتا ہے، وغیرہ۔ یقیناً، اس مرحلے پر میں سیو اور لوڈ مینو نہیں بنا سکا، کیونکہ مجھے تمام گرافکس کوڈ کے لیے ایک اسٹب بنانا پڑے گا۔ لیکن میں (غیر مرئی) سیو اینڈ لوڈ اسکرین کا استعمال کرتے ہوئے صارف ہونے کا بہانہ کر سکتا ہوں اور محفوظ کرنے کے لیے کہہ سکتا ہوں اور پھر میموری کارڈ پر لکھ سکتا ہوں۔

اس نے مجھے کوڈ کا ایک چھوٹا سا ٹکڑا چھوڑ دیا جس میں ابھی بھی مذکورہ بالا مسئلہ تھا - لیکن یہ اب بھی تصادفی طور پر ہو رہا تھا! اکثر سب کچھ ٹھیک کام کرتا تھا، لیکن کبھی کبھار خرابیاں ہوتی تھیں۔ میں نے تقریباً تمام گیم کوڈ کو ہٹا دیا، لیکن بگ ابھی تک زندہ تھا۔ یہ حیران کن تھا: باقی کوڈ نے حقیقت میں کچھ نہیں کیا۔

کسی وقت، غالباً صبح تین بجے کے قریب، میرے ذہن میں ایک خیال آیا۔ پڑھنا اور لکھنا (ان پٹ/آؤٹ پٹ) آپریشنز پر عمل درآمد کے عین اوقات شامل ہیں۔ جب آپ ہارڈ ڈرائیو، میموری کارڈ یا بلوٹوتھ ماڈیول کے ساتھ کام کرتے ہیں، تو پڑھنے اور لکھنے کے لیے ذمہ دار کم درجے کا کوڈ گھڑی کی دھڑکنوں کے مطابق ایسا کرتا ہے۔

گھڑی کی مدد سے، ایک ڈیوائس جو براہ راست پروسیسر سے منسلک نہیں ہے، پروسیسر پر عمل کرنے والے کوڈ کے ساتھ ہم آہنگ کیا جاتا ہے۔ گھڑی بوڈ کی شرح کا تعین کرتی ہے — وہ رفتار جس سے ڈیٹا منتقل ہوتا ہے۔ اگر اوقات کے ساتھ الجھن ہے، تو ہارڈ ویئر یا سافٹ ویئر، یا دونوں، بھی الجھن میں ہیں. اور یہ بہت برا ہے، کیونکہ ڈیٹا کو نقصان پہنچ سکتا ہے۔

اگر ہمارے کوڈ میں کوئی چیز اوقات کو الجھا دیتی ہے تو کیا ہوگا؟ میں نے ٹیسٹ پروگرام کوڈ میں اس سے متعلق ہر چیز کو چیک کیا اور دیکھا کہ ہم نے PS1 میں قابل پروگرام ٹائمر کو 1 kHz (1000 ٹک فی سیکنڈ) پر سیٹ کیا ہے۔ یہ بہت زیادہ ہے؛ بطور ڈیفالٹ، جب کنسول شروع ہوتا ہے، یہ 100 ہرٹج پر چلتا ہے۔ اور زیادہ تر گیمز اس فریکوئنسی کا استعمال کرتے ہیں۔

اینڈی، گیم ڈویلپر نے ٹائمر کو 1 kHz پر سیٹ کیا تاکہ نقل و حرکت کا زیادہ درستگی سے حساب لگایا جائے۔ اینڈی زیادہ سے زیادہ جانے کا رجحان رکھتا ہے، اور اگر ہم کشش ثقل کی تقلید کرتے ہیں، تو ہم اسے ہر ممکن حد تک درست طریقے سے کرتے ہیں!

لیکن کیا ہوگا اگر ٹائمر کو تیز کرنے سے کسی طرح پروگرام کے مجموعی وقت پر اثر پڑتا ہے، اور اس وجہ سے وہ گھڑی جو میموری کارڈ کے لیے بوڈ ریٹ کو کنٹرول کرتی ہے؟

میں نے ٹائمر کوڈ پر تبصرہ کیا۔ غلطی دوبارہ نہیں ہوئی۔ لیکن اس کا مطلب یہ نہیں ہے کہ ہم نے اسے ٹھیک کر دیا، کیونکہ ناکامی تصادفی طور پر ہوئی۔ اگر میں صرف خوش قسمت تھا تو کیا ہوگا؟

کچھ دنوں بعد میں نے ٹیسٹ پروگرام کے ساتھ دوبارہ تجربہ کیا۔ بگ دوبارہ نہیں آیا۔ میں مکمل گیم کوڈبیس پر واپس گیا اور سیو اینڈ لوڈ کوڈ میں ترمیم کی تاکہ پروگرام ایبل ٹائمر میموری کارڈ تک رسائی سے پہلے اپنی اصل قدر (100Hz) پر ری سیٹ ہو جائے، اور پھر 1kHz پر دوبارہ سیٹ ہو جائے۔ مزید حادثات نہیں تھے۔

لیکن ایسا کیوں ہوا؟

میں دوبارہ ٹیسٹ پروگرام میں واپس آیا۔ میں نے 1 کلو ہرٹز ٹائمر کے ساتھ غلطی کی صورت میں کچھ نمونہ تلاش کرنے کی کوشش کی۔ آخر کار میں نے دیکھا کہ غلطی اس وقت ہوتی ہے جب کوئی PS1 کنٹرولر کے ساتھ کھیلتا ہے۔ چونکہ میں خود یہ کام شاذ و نادر ہی کروں گا - مجھے سیو اور لوڈ کوڈ کی جانچ کرتے وقت کنٹرولر کی ضرورت کیوں پڑے گی؟ - میں نے اس انحصار کو بھی محسوس نہیں کیا۔ لیکن ایک دن ہمارے فنکاروں میں سے ایک میرا ٹیسٹنگ ختم کرنے کا انتظار کر رہا تھا - میں شاید اس وقت کوس رہا تھا - اور گھبرا کر کنٹرولر کو اپنے ہاتھوں میں گھمایا۔ ایک خرابی آگئی ہے. "کیا انتظار؟!" ٹھیک ہے، اسے دوبارہ کرو!"

جب میں نے محسوس کیا کہ یہ دونوں واقعات ایک دوسرے سے جڑے ہوئے ہیں، میں آسانی سے غلطی کو دوبارہ پیش کرنے میں کامیاب ہوگیا: میں نے میموری کارڈ میں ریکارڈنگ شروع کی، کنٹرولر کو منتقل کیا، اور میموری کارڈ کو خراب کردیا۔ میرے نزدیک یہ ایک ہارڈ ویئر بگ کی طرح لگتا تھا۔

میں کونی کے پاس آیا اور اسے اپنی دریافت کے بارے میں بتایا۔ اس نے PS1 کو ڈیزائن کرنے والے انجینئرز میں سے ایک کو معلومات فراہم کیں۔ "ناممکن،" اس نے جواب دیا، "یہ ہارڈ ویئر کا مسئلہ نہیں ہو سکتا۔" میں نے کونی سے کہا کہ وہ ہمارے لیے بات چیت کا بندوبست کرے۔

انجینئر نے مجھے بلایا اور ہم نے اس کی ٹوٹی پھوٹی انگریزی اور میری (انتہائی) ٹوٹی ہوئی جاپانی میں بحث کی۔ آخر میں میں نے کہا، "مجھے صرف اپنا 30 لائن ٹیسٹ پروگرام بھیجنے دو جہاں کنٹرولر کو حرکت دینے سے بگ پیدا ہوتا ہے۔" وہ مان گیا. انہوں نے کہا کہ یہ وقت کا ضیاع تھا اور وہ ایک نئے پروجیکٹ پر کام کرنے میں بہت مصروف تھے، لیکن ہم سونی کے لیے بہت اہم ڈویلپر ہونے کی وجہ سے ہار مانیں گے۔ میں نے اپنے ٹیسٹ پروگرام کو صاف کیا اور اسے بھیج دیا۔

اگلی شام (ہم لاس اینجلس میں تھے اور وہ ٹوکیو میں تھا) اس نے مجھے فون کیا اور بے شرمی سے معذرت کی۔ یہ ایک ہارڈ ویئر کا مسئلہ تھا۔

میں نہیں جانتا کہ اصل میں بگ کیا تھا، لیکن سونی ہیڈ کوارٹر میں جو کچھ میں نے سنا، اس سے، اگر آپ ٹائمر کو کافی زیادہ قیمت پر سیٹ کرتے ہیں، تو اس نے ٹائمر کرسٹل کے آس پاس کے مدر بورڈ کے اجزاء میں مداخلت کی۔ ان میں سے ایک میموری کارڈ کے لیے باؤڈ ریٹ کنٹرولر تھا، جس نے کنٹرولرز کے لیے بوڈ ریٹ بھی مقرر کیا تھا۔ میں انجینئر نہیں ہوں، اس لیے میں نے کچھ گڑبڑ کر دی ہے۔

لیکن سب سے اہم بات یہ ہے کہ مدر بورڈ پر اجزاء کے درمیان مداخلت تھی۔ اور 1 کلو ہرٹز پر چلنے والے ٹائمر کے ساتھ کنٹرولر پورٹ اور میموری کارڈ پورٹ کے ذریعے بیک وقت ڈیٹا منتقل کرنے پر، بٹس ضائع ہو گئے، ڈیٹا ضائع ہو گیا، اور کارڈ خراب ہو گیا۔

بری گائیں

1980 کی دہائی میں، میرے سرپرست سرگئی نے SM-1800 کے لیے سافٹ ویئر لکھا، جو PDP-11 کا سوویت کلون تھا۔ یہ مائیکرو کمپیوٹر ابھی یو ایس ایس آر میں ایک اہم ٹرانسپورٹ مرکز Sverdlovsk کے قریب ایک ریلوے اسٹیشن پر نصب کیا گیا ہے۔ نیا نظام ویگنوں اور مال بردار ٹریفک کو روٹ کرنے کے لیے ڈیزائن کیا گیا تھا۔ لیکن اس میں ایک پریشان کن بگ تھا جس کی وجہ سے بے ترتیب کریش اور کریش ہوتے تھے۔ زوال ہمیشہ اس وقت ہوتا جب کوئی شام کو گھر جاتا۔ لیکن اگلے دن مکمل چھان بین کے باوجود کمپیوٹر نے تمام دستی اور خودکار ٹیسٹوں میں درست طریقے سے کام کیا۔ یہ عام طور پر ریس کی حالت یا کسی دوسرے مسابقتی بگ کی نشاندہی کرتا ہے جو کچھ مخصوص حالات میں ہوتا ہے۔ رات گئے کالوں سے تنگ آکر سرگئی نے اس کی تہہ تک جانے کا فیصلہ کیا اور سب سے پہلے یہ سمجھیں کہ مارشلنگ یارڈ میں کن حالات کی وجہ سے کمپیوٹر خراب ہوا۔

سب سے پہلے، اس نے تمام غیر واضح آبشاروں کے اعداد و شمار جمع کیے اور تاریخ اور وقت کے لحاظ سے ایک گراف بنایا۔ نمونہ واضح تھا۔ کچھ دن مزید مشاہدہ کرنے کے بعد، سرگئی نے محسوس کیا کہ وہ مستقبل کے نظام کی ناکامی کے وقت کا اندازہ آسانی سے لگا سکتا ہے۔

اسے جلد ہی معلوم ہوا کہ رکاوٹیں صرف اس وقت پیش آئیں جب اسٹیشن شمالی یوکرین اور مغربی روس سے مویشیوں کی ٹرینوں کو چھانٹ رہا تھا جو قریبی ذبح خانے کی طرف جا رہا تھا۔ یہ اپنے آپ میں عجیب تھا، کیونکہ مذبح کو قازقستان میں بہت قریب واقع فارموں سے فراہم کیا جاتا تھا۔

چرنوبل نیوکلیئر پاور پلانٹ 1986 میں پھٹا، اور تابکار فال آؤٹ نے آس پاس کے علاقوں کو ناقابل رہائش بنا دیا۔ شمالی یوکرین، بیلاروس اور مغربی روس کے وسیع علاقے آلودہ تھے۔ آنے والی گاڑیوں میں تابکاری کی اعلی سطح کا شبہ کرتے ہوئے، سرگئی نے اس نظریے کو جانچنے کے لیے ایک طریقہ تیار کیا۔ آبادی کو ڈوسی میٹر رکھنے سے منع کیا گیا تھا، لہذا سرگئی نے ریلوے اسٹیشن پر کئی فوجیوں کے ساتھ خود کو رجسٹر کرایا۔ ووڈکا کے کئی مشروبات پینے کے بعد، وہ ایک سپاہی کو مشتبہ گاڑیوں میں سے ایک میں تابکاری کی سطح کی پیمائش کرنے پر راضی کرنے میں کامیاب ہوا۔ معلوم ہوا کہ سطح عام اقدار سے کئی گنا زیادہ تھی۔

مویشی نہ صرف بہت زیادہ تابکاری خارج کرتے تھے، بلکہ اس کی سطح اتنی زیادہ تھی کہ اس کی وجہ سے SM-1800 کی یادداشت میں بٹس کا بے ترتیب نقصان ہوا، جو اسٹیشن کے ساتھ والی عمارت میں واقع تھا۔

سوویت یونین میں خوراک کی کمی تھی، اور حکام نے ملک کے دیگر علاقوں کے گوشت کے ساتھ چرنوبل کے گوشت کو ملانے کا فیصلہ کیا۔ اس نے قیمتی وسائل کو کھونے کے بغیر تابکاری کی مجموعی سطح کو کم کرنا ممکن بنایا۔ اس کے بارے میں سیکھنے کے بعد، سرگئی نے فوری طور پر ہجرت کے لئے دستاویزات کو بھر دیا. اور وقت کے ساتھ ساتھ تابکاری کی سطح کم ہونے پر کمپیوٹر کریش اپنے طور پر رک گئے۔

پائپوں کے ذریعے

ایک زمانے میں، Movietech Solutions نے سینما گھروں کے لیے سافٹ ویئر بنایا، جو اکاؤنٹنگ، ٹکٹوں کی فروخت اور عمومی انتظام کے لیے ڈیزائن کیا گیا تھا۔ فلیگ شپ ایپ کا DOS ورژن شمالی امریکہ میں چھوٹے اور درمیانے سائز کے مووی تھیٹر چینز میں کافی مقبول تھا۔ لہذا یہ حیرت کی بات نہیں ہے کہ جب ونڈوز 95 کے ورژن کا اعلان کیا گیا، جو جدید ترین ٹچ اسکرینز اور سیلف سروس کیوسک کے ساتھ مربوط تھا، اور ہر طرح کے رپورٹنگ ٹولز سے لیس تھا، تو یہ بھی تیزی سے مقبول ہوگیا۔ اکثر اپ ڈیٹ بغیر کسی پریشانی کے چلا گیا۔ مقامی آئی ٹی کے عملے نے نئے آلات نصب کیے، ڈیٹا منتقل کیا، اور کاروبار جاری رہا۔ سوائے اس کے کہ جب یہ قائم نہ رہے۔ جب ایسا ہوا، تو کمپنی جیمز کو بھیجے گی، جسے "دی کلینر" کا نام دیا گیا تھا۔

اگرچہ عرفی نام ایک مذموم قسم کی تجویز کرتا ہے، کلینر صرف انسٹرکٹر، انسٹالر اور جیک آف آل ٹریڈز کا مجموعہ ہے۔ جیمز کچھ دن کلائنٹ کی سائٹ پر تمام اجزاء کو اکٹھا کرنے میں گزارے گا، اور پھر عملے کو نئے سسٹم کو استعمال کرنے کا طریقہ سکھانے کے لیے مزید کچھ دن گزارے گا، ہارڈ ویئر کے کسی بھی مسائل کو حل کرے گا اور بنیادی طور پر سافٹ ویئر کی بچپن میں مدد کرے گا۔

اس لیے، یہ کوئی تعجب کی بات نہیں ہے کہ ان مصروف اوقات میں، جیمز صبح دفتر پہنچا، اور اس سے پہلے کہ وہ اپنی میز پر پہنچ پاتا، مینیجر نے اس کا استقبال کیا، جو معمول سے زیادہ کیفین سے بھرا ہوا تھا۔

"مجھے ڈر ہے کہ آپ کو جلد از جلد ایناپولس، نووا سکوشیا جانے کی ضرورت ہے۔" ان کا پورا نظام خراب ہو گیا، اور ان کے انجینئرز کے ساتھ ایک رات کام کرنے کے بعد، ہم یہ نہیں جان سکتے کہ کیا ہوا۔ ایسا لگتا ہے کہ نیٹ ورک سرور پر ناکام ہو گیا ہے۔ لیکن کئی منٹ تک سسٹم چلنے کے بعد ہی۔

- وہ پرانے نظام میں واپس نہیں آئے؟ - جیمز نے پوری سنجیدگی سے جواب دیا، حالانکہ ذہنی طور پر اس نے حیرت سے آنکھیں پھیلائیں۔

— بالکل: ان کے آئی ٹی ماہر نے "ترجیحات بدل دی ہیں" اور اپنے پرانے سرور کے ساتھ جانے کا فیصلہ کیا۔ جیمز، انہوں نے سسٹم کو چھ سائٹس پر انسٹال کیا اور صرف پریمیم سپورٹ کے لیے ادائیگی کی، اور اب ان کا کاروبار اسی طرح چل رہا ہے جیسا کہ 1950 کی دہائی میں تھا۔

جیمز تھوڑا سا سیدھا ہوا۔

- یہ اور بات ہے۔ ٹھیک ہے، چلو شروع کرتے ہیں۔

جب وہ اناپولس پہنچا، تو اس نے سب سے پہلا کام اس گاہک کا پہلا تھیٹر تلاش کیا جس میں کوئی مسئلہ تھا۔ ہوائی اڈے پر لیے گئے نقشے پر سب کچھ مہذب نظر آرہا تھا لیکن مطلوبہ پتے کے ارد گرد کا علاقہ مشکوک نظر آرہا تھا۔ یہودی بستی نہیں بلکہ فلم نوئر کی یاد تازہ کردی۔ جیسے ہی جیمز کرب ڈاون ٹاون پر کھڑا ہوا، ایک طوائف اس کے پاس آئی۔ ایناپولس کی جسامت کو دیکھتے ہوئے، غالباً یہ پورے شہر میں واحد تھا۔ اس کی ظاہری شکل نے فوری طور پر اس مشہور کردار کو ذہن میں لایا جس نے بڑی اسکرین پر پیسے کے عوض سیکس کی پیشکش کی۔ نہیں، جولیا رابرٹس کے بارے میں نہیں، بلکہ جون ووائٹ کے بارے میںفلم "مڈ نائٹ کاؤ بوائے" کا اشارہ - تقریباً۔ لین].

طوائف کو اپنے راستے پر بھیجنے کے بعد، جیمز سنیما چلا گیا۔ آس پاس کا علاقہ بہتر ہو گیا تھا، لیکن اس نے پھر بھی کم ہونے کا تاثر دیا۔ ایسا نہیں ہے کہ جیمز بہت پریشان تھا۔ وہ اس سے پہلے بھی خراب جگہوں پر جا چکا ہے۔ اور یہ کینیڈا تھا، جہاں ڈاکو بھی آپ کا بٹوہ لینے کے بعد "شکریہ" کہنے کے لیے کافی شائستہ ہیں۔

سنیما کا سائیڈ انٹرنس ایک سنسان گلی میں تھا۔ جیمز دروازے کی طرف بڑھا اور دستک دی۔ جلد ہی یہ کریک اور تھوڑا سا کھل گیا.

- کیا آپ کلینر ہیں؟ - اندر سے ایک کرخت آواز آئی۔

- ہاں، یہ میں ہوں... میں سب کچھ ٹھیک کرنے آیا ہوں۔

جیمز سینما کی لابی میں چلا گیا۔ بظاہر کوئی اور چارہ نہ ہونے کی وجہ سے عملے نے زائرین کو کاغذی ٹکٹیں دینا شروع کر دیں۔ اس نے مالیاتی رپورٹنگ کو مشکل بنا دیا، مزید دلچسپ تفصیلات کو چھوڑ دیں۔ لیکن عملے نے جیمز کو خوش آمدید کہا اور فوراً سرور روم میں لے گئے۔

پہلی نظر میں، سب کچھ ٹھیک تھا. جیمز نے سرور میں لاگ ان کیا اور معمول کی مشکوک جگہوں کو چیک کیا۔ کوئی مسئلہ نہیں. تاہم، احتیاط کی کثرت سے، جیمز نے سرور کو بند کر دیا، نیٹ ورک کارڈ کو تبدیل کر دیا، اور سسٹم کو واپس کر دیا۔ وہ فوراً مکمل کام کرنے لگی۔ عملے نے دوبارہ ٹکٹوں کی فروخت شروع کر دی۔

جیمز نے مارک کو فون کیا اور اسے صورتحال سے آگاہ کیا۔ یہ تصور کرنا مشکل نہیں ہے کہ جیمز آس پاس رہنا چاہتے ہیں اور دیکھنا چاہتے ہیں کہ آیا کچھ غیر متوقع ہوتا ہے۔ وہ سیڑھیاں اتر کر ملازمین سے پوچھنے لگا کہ کیا ہوا؟ ظاہر ہے نظام نے کام کرنا چھوڑ دیا ہے۔ انہوں نے اسے آف اور آن کر دیا، سب کچھ کام کر گیا۔ لیکن 10 منٹ کے بعد سسٹم بند ہو گیا۔

بس اس وقت کچھ ایسا ہی ہوا۔ اچانک ٹکٹنگ سسٹم میں خرابیاں پیدا ہونے لگیں۔ عملے نے آہ بھری اور کاغذی ٹکٹوں کو پکڑ لیا، اور جیمز تیزی سے سرور روم میں چلا گیا۔ سرور کے ساتھ سب کچھ اچھا لگ رہا تھا۔

پھر ایک ملازم اندر داخل ہوا۔

- نظام دوبارہ کام کر رہا ہے۔

جیمز حیران تھا کیونکہ اس نے کچھ نہیں کیا تھا۔ زیادہ واضح طور پر، کچھ بھی نہیں جو نظام کو کام کرے گا. اس نے لاگ آؤٹ کیا، اپنا فون اٹھایا، اور اپنی کمپنی کی سپورٹ لائن پر کال کی۔ کچھ ہی دیر میں وہی ملازم سرور روم میں داخل ہوا۔

- نظام نیچے ہے.

جیمز نے سرور کی طرف دیکھا۔ کثیر رنگوں کی شکلوں کا ایک دلچسپ اور مانوس نمونہ اسکرین پر رقص کرتا ہے - افراتفری سے جھلسنے والے اور آپس میں جڑے ہوئے پائپ۔ ہم سب نے اس اسکرین سیور کو کسی وقت دیکھا ہے۔ یہ خوبصورتی سے پیش کیا گیا تھا اور لفظی طور پر hypnotizing تھا۔

جیمز نے ایک بٹن دبایا اور پیٹرن غائب ہوگیا۔ وہ جلدی سے ٹکٹ آفس پہنچا اور راستے میں ایک ملازم سے ملاقات ہوئی جو اس کی طرف لوٹ رہی تھی۔

- نظام دوبارہ کام کر رہا ہے۔

اگر آپ دماغی چہرہ ہتھیلی پر رکھ سکتے ہیں تو جیمز نے بالکل ایسا ہی کیا۔ اسکرین سیور. یہ OpenGL استعمال کرتا ہے۔ اور اس وجہ سے، آپریشن کے دوران، یہ سرور پروسیسر کے تمام وسائل استعمال کرتا ہے. نتیجے کے طور پر، سرور پر ہر کال ایک ٹائم آؤٹ کے ساتھ ختم ہوتی ہے۔

جیمز سرور روم میں واپس آیا، لاگ اِن ہوا، اور سکرین سیور کو خالی سکرین والے خوبصورت پائپوں سے بدل دیا۔ یعنی، ایک اسکرین سیور کے بجائے جو 100% پروسیسر وسائل استعمال کرتا ہے، میں نے ایک اور انسٹال کیا جو وسائل استعمال نہیں کرتا ہے۔ پھر میں نے اپنا اندازہ چیک کرنے کے لیے 10 منٹ انتظار کیا۔

جب جیمز اگلے سنیما میں پہنچے تو وہ سوچ رہے تھے کہ اپنے مینیجر کو کیسے سمجھائیں کہ اس نے اسکرین سیور کو بند کرنے کے لیے ابھی 800 کلومیٹر کا سفر طے کیا ہے۔

چاند کے ایک خاص مرحلے کے دوران کریش

سچی کہانی. ایک دن ایک سافٹ ویئر بگ پیدا ہوا جو چاند کے مرحلے پر منحصر تھا۔ ایک چھوٹا سا معمول تھا جو عام طور پر مختلف MIT پروگراموں میں چاند کے حقیقی مرحلے کے قریب ہونے کا حساب لگانے کے لیے استعمال ہوتا تھا۔ GLS نے اس روٹین کو ایک LISP پروگرام میں بنایا جو، فائل لکھتے وقت، تقریباً 80 حروف طویل ٹائم اسٹیمپ کے ساتھ ایک لائن نکالتا ہے۔ یہ بہت کم ہوتا تھا کہ کسی پیغام کی پہلی سطر بہت لمبی ہو کر اگلی لائن کی طرف لے جاتی۔ اور جب پروگرام نے بعد میں اس فائل کو پڑھا تو اس پر لعنت بھیجی۔ پہلی سطر کی لمبائی کا انحصار صحیح تاریخ اور وقت پر ہوتا ہے، نیز ٹائم اسٹیمپ کے پرنٹ ہونے کے وقت مرحلے کی تفصیلات کی لمبائی۔ یعنی، بگ لفظی طور پر چاند کے مرحلے پر منحصر تھا!

پہلا پیپر ایڈیشن جرگن فائل (Steele-1983) میں ایسی لائن کی ایک مثال موجود ہے جو بیان کردہ بگ کی طرف لے گئی، لیکن ٹائپ سیٹٹر نے اسے "فکس" کیا۔ اس کے بعد سے اسے "مون فیز بگ" کے طور پر بیان کیا گیا ہے۔

تاہم، مفروضوں کے ساتھ محتاط رہیں. کچھ سال پہلے، CERN (European Center for Nuclear Research) کے انجینئروں کو لارج الیکٹران-پوزیٹرون کولائیڈر پر کیے گئے تجربات میں غلطیوں کا سامنا کرنا پڑا۔ چونکہ کمپیوٹر سائنسدانوں کو نتیجہ دکھانے سے پہلے اس ڈیوائس کے ذریعے پیدا ہونے والے بہت زیادہ ڈیٹا کو فعال طور پر پروسس کرتے ہیں، بہت سے لوگوں نے قیاس کیا کہ یہ سافٹ ویئر کسی نہ کسی طرح چاند کے مرحلے کے لیے حساس تھا۔ کئی مایوس انجینئر سچ کی تہہ تک پہنچ گئے۔ یہ خرابی چاند کے گزرنے کے دوران زمین کی خرابی کی وجہ سے 27 کلومیٹر طویل حلقے کی جیومیٹری میں معمولی تبدیلی کی وجہ سے پیدا ہوئی! یہ کہانی طبیعیات کی لوک داستانوں میں "ذراتی طبیعیات پر نیوٹن کا بدلہ" کے طور پر داخل ہوئی ہے اور طبیعیات کے سب سے آسان اور قدیم ترین قوانین اور جدید ترین سائنسی تصورات کے درمیان تعلق کی ایک مثال ہے۔

ٹوائلٹ فلش کرنے سے ٹرین رک جاتی ہے۔

بہترین ہارڈ ویئر بگ جس کے بارے میں میں نے کبھی سنا ہے وہ فرانس میں تیز رفتار ٹرین میں تھا۔ بگ کی وجہ سے ٹرین کی ہنگامی بریک لگ گئی، لیکن صرف اس صورت میں جب جہاز میں مسافر موجود ہوں۔ ایسے ہر معاملے میں ٹرین کو سروس سے ہٹایا گیا، چیک کیا گیا، لیکن کچھ نہیں ملا۔ پھر اسے لائن پر واپس بھیج دیا گیا، اور وہ فوری طور پر ایک سٹاپ پر گر کر تباہ ہو گیا۔

ایک چیک کے دوران، ٹرین میں سفر کرنے والا ایک انجینئر ٹوائلٹ گیا۔ وہ جلد ہی دھل گیا، بوم! ایمرجنسی اسٹاپ۔

انجینئر نے ڈرائیور سے رابطہ کیا اور پوچھا:

- بریک لگانے سے پہلے آپ کیا کر رہے تھے؟

- ٹھیک ہے، میں نے نزول کی رفتار کم کر دی...

یہ عجیب تھا، کیونکہ عام آپریشن کے دوران ٹرین درجنوں بار نیچے اترتی ہے۔ ٹرین آگے بڑھی، اور اگلے نزول پر ڈرائیور نے خبردار کیا:

- میں سست ہونے جا رہا ہوں۔

کچھ بھی نہیں ہوا.

- آپ نے آخری بریک کے دوران کیا کیا؟ - ڈرائیور نے پوچھا.

- اچھا... میں ٹوائلٹ میں تھا...

- ٹھیک ہے، پھر ٹوائلٹ میں جاؤ اور تم نے کیا کیا جب ہم دوبارہ نیچے جائیں گے!

انجینئر ٹوائلٹ گیا، اور جب ڈرائیور نے خبردار کیا: "میں سست ہو رہا ہوں،" اس نے پانی بہایا۔ یقیناً ٹرین فوراً رک گئی۔

اب وہ مسئلہ کو دوبارہ پیش کر سکتے ہیں اور اس کی وجہ تلاش کرنے کی ضرورت ہے۔

دو منٹ کے بعد، انہوں نے دیکھا کہ انجن بریک کرنے والی ریموٹ کنٹرول کیبل (ٹرین کے ہر سرے پر ایک انجن تھا) برقی کیبنٹ کی دیوار سے منقطع ہو گیا تھا اور ریلے پر پڑا تھا جو ٹوائلٹ پلگ سولینائیڈ کو کنٹرول کرتا تھا... جب ریلے آن کیا گیا تھا، اس نے بریک کیبل میں مداخلت پیدا کی، اور ناکامیوں کے خلاف سسٹم کے تحفظ میں صرف ہنگامی بریک لگانا شامل تھا۔

گیٹ وے جو فورٹران سے نفرت کرتا تھا۔

کچھ مہینے پہلے ہم نے دیکھا کہ مین لینڈ [یہ ہوائی میں تھا] پر نیٹ ورک کنکشن بہت، بہت سست ہو رہے تھے۔ یہ 10-15 منٹ تک جاری رہ سکتا ہے اور پھر اچانک دوبارہ ہو سکتا ہے۔ کچھ دیر بعد، میرے ساتھی نے مجھ سے شکایت کی کہ سرزمین پر نیٹ ورک کنکشن ہے۔ عام طور پر کام نہیں کرتا. اس کے پاس کچھ FORTRAN کوڈ تھا جسے مین لینڈ پر کسی مشین میں کاپی کرنے کی ضرورت تھی، لیکن ایسا نہیں ہو سکا کیونکہ "نیٹ ورک نے FTP اپ لوڈ مکمل ہونے کے لیے کافی دیر تک روک نہیں رکھی تھی۔"

ہاں، یہ پتہ چلا کہ نیٹ ورک کی ناکامی اس وقت ہوئی جب ایک ساتھی نے فورٹران میں سورس کوڈ والی فائل کو مین لینڈ کی ایک مشین پر FTP کرنے کی کوشش کی۔ ہم نے فائل کو آرکائیو کرنے کی کوشش کی: پھر اسے آسانی سے کاپی کیا گیا (لیکن ٹارگٹ مشین میں پیکر نہیں تھا، اس لیے مسئلہ حل نہیں ہوا)۔ آخر کار ہم نے FORTRAN کوڈ کو بہت چھوٹے ٹکڑوں میں "تقسیم" کیا اور ایک ایک کرکے بھیج دیا۔ زیادہ تر ٹکڑوں کو بغیر کسی پریشانی کے نقل کیا گیا تھا، لیکن چند ٹکڑے نہیں گزرے، یا گزر گئے۔ متعدد کوششیں

مشکل اقتباسات کی جانچ کرنے کے بعد، ہم نے دریافت کیا کہ ان میں کچھ مشترک ہے: ان سب میں تبصرے کے بلاکس تھے جو کیپٹل C پر مشتمل لائنوں کے ساتھ شروع اور ختم ہوتے تھے (بطور ایک ساتھی نے FORTRAN میں تبصرہ کرنے کو ترجیح دی)۔ ہم نے سرزمین پر نیٹ ورک کے ماہرین کو ای میل کیا اور مدد کے لیے کہا۔ بلاشبہ، وہ ہماری فائلوں کے نمونے دیکھنا چاہتے تھے جو FTP کے ذریعے منتقل نہیں کیے جا سکتے تھے... لیکن ہمارے خطوط ان تک نہیں پہنچے۔ آخر کار ہم ایک سادہ کے ساتھ آئے بیان کریںناقابل منتقلی فائلیں کیسی نظر آتی ہیں۔ اس سے کام ہوا :) شاید اس کے قابل نہیں!]

آخر میں ہم اس کا پتہ لگانے میں کامیاب ہو گئے۔ کیمپس کے ہمارے حصے اور مین لینڈ نیٹ ورک کے درمیان حال ہی میں ایک نیا گیٹ وے نصب کیا گیا تھا۔ اس میں پیکٹوں کو منتقل کرنے میں بہت زیادہ دشواری تھی جس میں بڑے حروف C کے بار بار بٹس ہوتے تھے! ان میں سے صرف چند پیکٹ گیٹ وے کے تمام وسائل کو لے سکتے ہیں اور زیادہ تر دوسرے پیکٹوں کو گزرنے سے روک سکتے ہیں۔ ہم نے گیٹ وے مینوفیکچرر سے شکایت کی... اور انہوں نے جواب دیا: "اوہ، ہاں، آپ کو بار بار C کے مسئلے کا سامنا ہے! ہم اس کے بارے میں پہلے ہی جانتے ہیں۔" ہم نے آخر کار ایک اور صنعت کار سے ایک نیا گیٹ وے خرید کر مسئلہ حل کیا (سابقہ ​​کے دفاع میں، FORTRAN پروگراموں کو منتقل کرنے میں ناکامی کچھ لوگوں کے لیے فائدہ مند ہو سکتی ہے!)۔

مشکل وقت

چند سال پہلے، فیز 40 کلینیکل ٹرائلز کے اخراجات کو کم کرنے کے لیے پرل میں ایک ETL سسٹم بنانے پر کام کرتے ہوئے، مجھے تقریباً 000 تاریخوں پر کارروائی کرنے کی ضرورت تھی۔ ان میں سے دو نے امتحان پاس نہیں کیا۔ اس نے مجھے زیادہ پریشان نہیں کیا کیونکہ یہ تاریخیں کلائنٹ کے فراہم کردہ ڈیٹا سے لی گئی تھیں جو اکثر ہوتا تھا، کیا ہم کہیں گے، حیرت کی بات ہے۔ لیکن جب میں نے اصل ڈیٹا چیک کیا تو معلوم ہوا کہ یہ تاریخیں یکم جنوری 1 اور یکم جنوری 2011 تھیں۔ میں نے سوچا کہ یہ بگ اس پروگرام میں موجود ہے جو میں نے ابھی لکھا تھا، لیکن معلوم ہوا کہ یہ 1 سال کا ہو چکا ہے۔ پرانا یہ سافٹ ویئر ایکو سسٹم سے ناواقف لوگوں کے لیے پراسرار لگ سکتا ہے۔ ایک اور کمپنی کے پیسے کمانے کے دیرینہ فیصلے کی وجہ سے، میرے کلائنٹ نے مجھے اس مسئلے کو ٹھیک کرنے کے لیے ادائیگی کی جسے ایک کمپنی نے حادثاتی طور پر اور دوسری نے جان بوجھ کر متعارف کرایا تھا۔ آپ کو یہ سمجھنے کے لیے کہ میں کس چیز کے بارے میں بات کر رہا ہوں، مجھے اس کمپنی کے بارے میں بات کرنے کی ضرورت ہے جس نے اس خصوصیت کو شامل کیا جو ایک بگ بن گیا، اور ساتھ ہی ساتھ چند دوسرے دلچسپ واقعات جنہوں نے پراسرار بگ کو ٹھیک کرنے میں تعاون کیا۔

اچھے پرانے دنوں میں، ایپل کمپیوٹر بعض اوقات بے ساختہ اپنی تاریخ کو یکم جنوری 1 پر سیٹ کر دیتے تھے۔ وجہ سادہ تھی: اس نے تاریخ اور وقت پر نظر رکھنے کے لیے بیٹری سے چلنے والی "سسٹم کلاک" کا استعمال کیا۔ جب بیٹری مر گئی تو کیا ہوا؟ کمپیوٹرز نے ایک دور کے آغاز کے بعد سے تاریخ کو سیکنڈوں کی تعداد سے ٹریک کرنا شروع کیا۔ دور سے ہمارا مطلب اصل تاریخ کا حوالہ تھا، اور میکنٹوشس کے لیے یہ یکم جنوری 1904 تھی۔ اور بیٹری کے مرنے کے بعد، موجودہ تاریخ کو مخصوص تاریخ پر دوبارہ ترتیب دیا گیا۔ لیکن ایسا کیوں ہوا؟

اس سے پہلے، ایپل اصل تاریخ کے بعد سے سیکنڈز کی تعداد کو ذخیرہ کرنے کے لیے 32 بٹس استعمال کرتا تھا۔ ایک بٹ دو قدروں میں سے ایک کو ذخیرہ کر سکتا ہے - 1 یا 0۔ دو بٹس چار میں سے ایک قدر کو ذخیرہ کر سکتے ہیں: 00، 01، 10، 11۔ تین بٹس - آٹھ میں سے ایک قدر: 000، 001، 010، 011، 100 ، 101، 110، 111، وغیرہ۔ اور 32 232 میں سے ایک قدر کو محفوظ کر سکتا ہے، یعنی 4 سیکنڈز۔ ایپل کی تاریخوں کے لیے، یہ تقریباً 294 سال کے برابر ہے، لہذا پرانے میک 967 کے بعد کی تاریخوں کو نہیں سنبھال سکتے۔ اور اگر سسٹم کی بیٹری ختم ہو جاتی ہے، تو تاریخ کو عہد کے آغاز سے 296 سیکنڈ پر ری سیٹ کر دیا جاتا ہے، اور جب بھی آپ کمپیوٹر آن کرتے ہیں (یا جب تک آپ نئی بیٹری خریدتے ہیں) آپ کو دستی طور پر تاریخ سیٹ کرنی ہوگی۔

تاہم، ایپل کے عہد کے بعد سے تاریخوں کو سیکنڈ کے طور پر ذخیرہ کرنے کے فیصلے کا مطلب یہ تھا کہ ہم عہد سے پہلے کی تاریخوں کو سنبھال نہیں سکتے، جس کے دور رس نتائج تھے، جیسا کہ ہم دیکھیں گے۔ ایپل نے ایک فیچر متعارف کرایا، بگ نہیں۔ دوسری چیزوں کے علاوہ، اس کا مطلب یہ تھا کہ میکنٹوش آپریٹنگ سسٹم "ملینیم بگ" سے محفوظ تھا (جس کے بارے میں بہت سی میک ایپلی کیشنز کے بارے میں نہیں کہا جا سکتا تھا جن کے پاس پابندیوں کو روکنے کے لیے اپنے ڈیٹ سسٹم موجود تھے)۔

آگے بڑھو. ہم نے لوٹس 1-2-3، IBM کی "قاتل ایپلی کیشن" کا استعمال کیا جس نے PC انقلاب شروع کرنے میں مدد کی، حالانکہ ایپل کمپیوٹرز میں VisiCalc تھا، جس نے پرسنل کمپیوٹر کو کامیاب بنایا۔ منصفانہ طور پر، اگر 1-2-3 ظاہر نہ ہوتا، تو PC شاید ہی ختم ہو جاتا، اور پرسنل کمپیوٹرز کی تاریخ بہت مختلف طریقے سے تیار ہو سکتی تھی۔ لوٹس 1-2-3 نے 1900 کو لیپ سال کے طور پر غلط طریقے سے سمجھا۔ جب مائیکروسافٹ نے اپنی پہلی اسپریڈشیٹ، ملٹی پلان جاری کی، تو اس نے مارکیٹ کا ایک چھوٹا سا حصہ حاصل کیا۔ اور جب انہوں نے Excel پروجیکٹ کا آغاز کیا، تو انہوں نے نہ صرف Lotus 1-2-3 سے قطار اور کالم کے ناموں کی اسکیم کو کاپی کرنے کا فیصلہ کیا، بلکہ 1900 کو جان بوجھ کر ایک لیپ سال کے طور پر دیکھ کر بگ کی مطابقت کو بھی یقینی بنایا۔ یہ مسئلہ آج بھی موجود ہے۔ تو 1-2-3 میں یہ ایک بگ تھا، لیکن ایکسل میں یہ ایک شعوری فیصلہ تھا کہ اس بات کو یقینی بنایا جائے کہ تمام 1-2-3 صارفین ڈیٹا کو تبدیل کیے بغیر اپنی ٹیبلز کو Excel میں درآمد کر سکتے ہیں، چاہے یہ غلط ہی کیوں نہ ہو۔

لیکن ایک اور مسئلہ تھا۔ سب سے پہلے، مائیکروسافٹ نے میکنٹوش کے لیے ایکسل جاری کیا، جو یکم جنوری 1 سے پہلے کی تاریخوں کو نہیں پہچانتا تھا۔ اور ایکسل میں یکم جنوری 1904 کو عہد کا آغاز سمجھا جاتا تھا۔ لہذا، ڈویلپرز نے ایک تبدیلی کی تاکہ ان کے پروگرام نے دور کی قسم کو پہچان لیا اور مطلوبہ دور کے مطابق ڈیٹا کو اپنے اندر محفوظ کرلیا۔ مائیکروسافٹ نے اس کے بارے میں ایک وضاحتی مضمون بھی لکھا۔ اور یہ فیصلہ میرے مسئلے کا باعث بنا۔

میرے ای ٹی ایل سسٹم کو صارفین سے ایکسل اسپریڈشیٹ موصول ہوئی ہیں جو ونڈوز پر بنائی گئی تھیں، لیکن میک پر بھی بنائی جا سکتی ہیں۔ لہذا، جدول میں دور کا آغاز یکم جنوری 1 یا یکم جنوری 1900 ہو سکتا ہے۔ کیسے معلوم کریں؟ ایکسل فائل فارمیٹ ضروری معلومات دکھاتا ہے، لیکن میں نے جو پارسر استعمال کیا اس نے اسے نہیں دکھایا (اب ایسا ہوتا ہے)، اور فرض کیا کہ آپ کو ایک مخصوص ٹیبل کے لیے عہد معلوم ہے۔ میں شاید ایکسل بائنری فارمیٹ کو سمجھنے اور پارسر مصنف کو ایک پیچ بھیجنے میں زیادہ وقت صرف کر سکتا تھا، لیکن میرے پاس کلائنٹ کے لیے اور بھی بہت کچھ تھا، اس لیے میں نے عہد کا تعین کرنے کے لیے جلدی سے ایک ہورسٹک لکھا۔ وہ سادہ سی تھی۔

ایکسل میں، 5 جولائی 1998 کی تاریخ کو "07-05-98" (بیکار امریکی نظام)، "جولائی 5، 98"، "5 جولائی، 1998"، "5-جولائی-98" یا فارمیٹ میں دکھایا جا سکتا ہے۔ ایک اور بیکار فارمیٹ (ستم ظریفی یہ ہے کہ میرے ایکسل کے ورژن نے جو فارمیٹ پیش نہیں کیا ان میں سے ایک ISO 8601 تھا)۔ تاہم، جدول کے اندر، غیر فارمیٹ شدہ تاریخ کو یا تو epoch-35981 کے لیے "1900" یا epoch-34519 کے لیے "1904" کے طور پر محفوظ کیا گیا تھا (اعداد و شمار عہد کے بعد کے دنوں کی تعداد کی نمائندگی کرتے ہیں)۔ میں نے فارمیٹ شدہ تاریخ سے سال نکالنے کے لیے ایک سادہ پارسر کا استعمال کیا، اور پھر غیر فارمیٹ شدہ تاریخ سے سال نکالنے کے لیے ایکسل پارسر کا استعمال کیا۔ اگر دونوں قدروں میں 4 سال کا فرق تھا، تو میں جانتا تھا کہ میں epoch-1904 والا سسٹم استعمال کر رہا ہوں۔

میں نے صرف فارمیٹ شدہ تاریخیں کیوں نہیں استعمال کیں؟ کیونکہ 5 جولائی 1998 کو کھوئے ہوئے مہینے کے دن کے ساتھ "جولائی، 98" کے طور پر فارمیٹ کیا جا سکتا ہے۔ ہمیں بہت ساری کمپنیوں سے میزیں موصول ہوئیں جنہوں نے انہیں اتنے مختلف طریقوں سے بنایا کہ تاریخوں کا پتہ لگانا ہم پر (اس معاملے میں، میں) تھا۔ اس کے علاوہ، اگر ایکسل اسے درست کرتا ہے، تو ہمیں بھی ایسا کرنا چاہئے!

اسی وقت میں نے 39082 کا سامنا کیا۔ میں آپ کو یاد دلاتا ہوں کہ لوٹس 1-2-3 نے 1900 کو ایک لیپ سال سمجھا، اور اسے ایکسل میں ایمانداری سے دہرایا گیا۔ اور چونکہ اس نے سال 1900 میں ایک دن کا اضافہ کیا، اسی دن کے لیے تاریخ کے حساب کتاب کے بہت سے افعال غلط ہو سکتے ہیں۔ یعنی 39082 یکم جنوری 1 (میک پر) یا 2011 دسمبر 31 (ونڈوز پر) ہوسکتا ہے۔ اگر میرے "سال پارسر" نے فارمیٹ شدہ قدر سے سال 2006 نکالا، تو سب کچھ ٹھیک ہے۔ لیکن چونکہ ایکسل تجزیہ کار یہ نہیں جانتا کہ کون سا دور استعمال کیا جا رہا ہے، اس لیے یہ ڈیفالٹ epoch-2011 میں ہو جاتا ہے، جو سال 1900 کو لوٹتا ہے۔ میری درخواست نے دیکھا کہ فرق 2006 سال کا تھا، اسے ایک غلطی سمجھا، اسے لاگ کیا، اور غیر فارمیٹ شدہ قدر واپس کی۔

اس کے ارد گرد حاصل کرنے کے لئے، میں نے یہ لکھا (pseudocode):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

اور پھر تمام 40 تاریخوں کو درست طریقے سے پارس کیا گیا۔

بڑے پرنٹ ملازمتوں کے وسط میں

1980 کی دہائی کے اوائل میں، میرے والد نے سٹوریج ٹیکنالوجی میں کام کیا، جو اب ناکارہ ہو چکا ہے جس نے تیز رفتار ٹیپ فیڈنگ کے لیے ٹیپ ڈرائیوز اور نیومیٹک سسٹم بنائے۔

انہوں نے ڈرائیوز کو نئے سرے سے ڈیزائن کیا تاکہ ان کے پاس ایک مرکزی "A" ڈرائیو سات "B" ڈرائیوز سے منسلک ہو، اور RAM میں چھوٹا OS جو "A" ڈرائیو کو کنٹرول کرتا ہے وہ تمام "B" ڈرائیوز کو پڑھنے اور لکھنے کی کارروائیوں کو سونپ سکتا ہے۔

جب بھی ڈرائیو "A" شروع کی جاتی تھی، آپریٹنگ سسٹم کو اس کی میموری میں لوڈ کرنے کے لیے "A" سے منسلک پیریفرل ڈرائیو میں فلاپی ڈسک ڈالنا ضروری تھا۔ یہ انتہائی قدیم تھا: کمپیوٹنگ پاور 8 بٹ مائیکرو کنٹرولر کے ذریعہ فراہم کی گئی تھی۔

اس طرح کے سازوسامان کے ہدف کے سامعین وہ کمپنیاں تھیں جن کے پاس بہت بڑے ڈیٹا گودام ہیں - بینک، ریٹیل چینز، وغیرہ - جنہیں ایڈریس لیبلز یا بینک اسٹیٹمنٹس کو بہت زیادہ پرنٹ کرنے کی ضرورت تھی۔

ایک کلائنٹ کا مسئلہ تھا۔ پرنٹ جاب کے بیچ میں، ایک مخصوص ڈرائیو "A" کام کرنا بند کر سکتی ہے، جس سے پورا کام رک جاتا ہے۔ ڈرائیو کے آپریشن کو بحال کرنے کے لیے، عملے کو سب کچھ ریبوٹ کرنا پڑا۔ اور اگر یہ چھ گھنٹے کے کام کے درمیان میں ہوا تو کمپیوٹر کا ایک بہت بڑا مہنگا وقت ضائع ہو گیا اور پورے آپریشن کا شیڈول درہم برہم ہو گیا۔

تکنیکی ماہرین کو اسٹوریج ٹیکنالوجیز سے بھیجا گیا تھا۔ لیکن ان کی بہترین کوششوں کے باوجود، وہ آزمائشی حالات میں بگ کو دوبارہ پیدا کرنے سے قاصر تھے: ایسا لگتا تھا کہ یہ بڑی پرنٹ ملازمتوں کے بیچ میں ہوتا ہے۔ مسئلہ ہارڈ ویئر کا نہیں تھا، انہوں نے ہر وہ چیز بدل دی جو وہ کر سکتے تھے: ریم، مائیکرو کنٹرولر، فلاپی ڈرائیو، ٹیپ ڈرائیو کا ہر قابل فہم حصہ - مسئلہ برقرار رہا۔

پھر ٹیکنیشنز نے ہیڈ کوارٹر بلا کر ایکسپرٹ کو بلایا۔

ماہر نے ایک کرسی اور کافی کا کپ پکڑا، کمپیوٹر روم میں بیٹھ گیا — ان دنوں کمپیوٹر کے لیے مخصوص کمرے تھے — اور دیکھا کہ عملہ ایک بڑی پرنٹ جاب کی قطار میں کھڑا ہے۔ ماہر ناکامی کا انتظار کر رہا تھا - اور ایسا ہوا۔ سب نے ایکسپرٹ کی طرف دیکھا لیکن اسے کچھ سمجھ نہیں آرہا تھا کہ ایسا کیوں ہوا۔ چنانچہ اس نے کام کو دوبارہ قطار میں لگانے کا حکم دیا، اور تمام عملہ اور تکنیکی ماہرین کام پر واپس آگئے۔

ماہر دوبارہ کرسی پر بیٹھ گیا اور ناکامی کا انتظار کرنے لگا۔ تقریباً چھ گھنٹے گزر گئے اور ناکامی ہوئی۔ ماہر کو پھر کوئی خیال نہیں تھا، سوائے اس کے کہ سب کچھ لوگوں سے بھرے کمرے میں ہوا۔ اس نے مشن کو دوبارہ شروع کرنے کا حکم دیا، واپس بیٹھ کر انتظار کیا۔

تیسری ناکامی سے، ماہر نے کچھ محسوس کیا۔ ناکامی اس وقت ہوئی جب اہلکاروں نے غیر ملکی ڈرائیو میں ٹیپ تبدیل کی۔ مزید یہ کہ، ناکامی اس وقت ہوئی جب ایک ملازم فرش پر ایک مخصوص ٹائل سے گزرا۔

اونچا فرش 6 سے 8 انچ کی اونچائی پر بچھائی گئی ایلومینیم ٹائلوں سے بنا تھا۔ کمپیوٹرز کی متعدد تاریں اونچی منزل کے نیچے دوڑتی ہیں تاکہ کسی کو غلطی سے اہم کیبل پر قدم رکھنے سے روکا جا سکے۔ ٹائلیں بہت مضبوطی سے بچھائی گئی تھیں تاکہ ملبے کو اونچے فرش کے نیچے جانے سے روکا جا سکے۔

ماہر نے محسوس کیا کہ ٹائلوں میں سے ایک بگڑی ہوئی تھی۔ جب ایک ملازم نے اس کے کونے پر قدم رکھا تو ٹائل کے کنارے ملحقہ ٹائلوں سے رگڑ گئے۔ ٹائلوں کو جوڑنے والے پلاسٹک کے پرزے بھی ان کے ساتھ رگڑتے تھے، جس کی وجہ سے جامد مائیکرو ڈسچارجز ہوتے ہیں جس سے ریڈیو فریکوئنسی میں مداخلت ہوتی ہے۔

آج، RAM ریڈیو فریکوئنسی مداخلت سے بہت بہتر محفوظ ہے۔ لیکن ان سالوں میں ایسا نہیں تھا۔ ماہر نے محسوس کیا کہ اس مداخلت نے یادداشت کو متاثر کیا، اور اس کے ساتھ آپریٹنگ سسٹم کے کام کو متاثر کیا. اس نے سپورٹ سروس کو کال کی، نئی ٹائلوں کا آرڈر دیا، انہیں خود انسٹال کیا، اور مسئلہ غائب ہوگیا۔

یہ تیز لہر ہے!

یہ کہانی پورٹسماؤتھ (میرے خیال میں) کے ایک دفتر کی چوتھی یا پانچویں منزل پر ایک سرور روم میں ہوئی، ڈاکس کے علاقے میں۔

ایک دن مرکزی ڈیٹا بیس کے ساتھ یونکس سرور کریش ہو گیا۔ انہوں نے اسے دوبارہ شروع کیا، لیکن وہ خوشی سے بار بار گرتا رہا۔ ہم نے سپورٹ سروس سے کسی کو کال کرنے کا فیصلہ کیا۔

حمایتی آدمی... میرے خیال میں اس کا نام مارک تھا، لیکن اس سے کوئی فرق نہیں پڑتا... مجھے نہیں لگتا کہ میں اسے جانتا ہوں۔ اس سے کوئی فرق نہیں پڑتا، واقعی۔ آئیے مارک کے ساتھ رہیں، ٹھیک ہے؟ زبردست.

لہذا، چند گھنٹے بعد مارک پہنچا (یہ لیڈز سے پورٹسماؤتھ تک کا طویل راستہ نہیں ہے، آپ جانتے ہیں)، سرور آن کر دیا اور ہر چیز بغیر کسی پریشانی کے کام کر گئی۔ عام لات کی حمایت، کلائنٹ اس کے بارے میں بہت پریشان ہو جاتا ہے. مارک لاگ فائلوں کو دیکھتا ہے اور اسے کچھ بھی ناگوار نہیں ملتا۔ اس لیے مارک ٹرین پر واپس چلا گیا (یا وہ جس بھی نقل و حمل کے طریقے پر پہنچا، وہ سب کے لیے ایک لنگڑی گائے ہو سکتی تھی جو میں جانتا ہوں... ویسے بھی، اس سے کوئی فرق نہیں پڑتا، ٹھیک ہے؟) اور ضائع ہو کر واپس لیڈز کی طرف روانہ ہو گیا۔ دن.

اسی شام سرور دوبارہ کریش ہو جاتا ہے۔ کہانی وہی ہے سرور نہیں اٹھتا مارک دور سے مدد کرنے کی کوشش کرتا ہے، لیکن کلائنٹ سرور کو شروع نہیں کر سکتا۔

ایک اور ٹرین، بس، لیمن میرنگو یا کوئی اور گھٹیا، اور مارک پورٹسماؤتھ میں واپس آ گیا ہے۔ دیکھو، سرور بغیر کسی پریشانی کے بوٹ کرتا ہے! معجزہ۔ مارک یہ جانچنے میں کئی گھنٹے گزارتا ہے کہ آپریٹنگ سسٹم یا سافٹ ویئر کے ساتھ سب کچھ ٹھیک ہے اور لیڈز کے لیے روانہ ہو جاتا ہے۔

دن کے وسط میں سرور کریش ہو جاتا ہے (اسے آسانی سے لیں!) اس بار سرور کو تبدیل کرنے کے لیے ہارڈویئر سپورٹ والے لوگوں کو لانا مناسب معلوم ہوتا ہے۔ لیکن نہیں، تقریباً 10 گھنٹے بعد یہ بھی گر جاتا ہے۔

کئی دنوں تک یہ صورت حال دہرائی گئی۔ سرور کام کرتا ہے، تقریباً 10 گھنٹے بعد کریش ہو جاتا ہے اور اگلے 2 گھنٹے تک شروع نہیں ہوتا ہے۔ انہوں نے کولنگ، میموری لیک کی جانچ کی، انہوں نے سب کچھ چیک کیا، لیکن کچھ نہیں ملا۔ پھر کریشیں رک گئیں۔

ہفتہ بے فکری سے گزرا... سب خوش تھے۔ یہ سب دوبارہ شروع ہونے تک خوش رہیں۔ تصویر وہی ہے۔ 10 گھنٹے کام، 2-3 گھنٹے کا ڈاؤن ٹائم...

اور پھر کسی نے (میرے خیال میں انہوں نے مجھے بتایا کہ اس شخص کا آئی ٹی سے کوئی تعلق نہیں ہے) نے کہا:

"یہ جوار ہے!"

فجائیہ خالی نظروں سے ملا اور کسی کا ہاتھ شاید سیکیورٹی کال کے بٹن پر جھجک گیا۔

"یہ جوار کے ساتھ کام کرنا بند کر دیتا ہے۔"

یہ آئی ٹی سپورٹ ورکرز کے لیے مکمل طور پر غیر ملکی تصور معلوم ہوتا ہے، جو کافی کے لیے بیٹھتے ہوئے ٹائیڈ ایئر بک کو پڑھنے کا امکان نہیں رکھتے ہیں۔ انہوں نے وضاحت کی کہ یہ کسی بھی طرح سے جوار سے متعلق نہیں ہوسکتا ہے، کیونکہ سرور ناکامی کے بغیر ایک ہفتے سے کام کر رہا تھا.

"پچھلے ہفتے جوار کم تھا، لیکن اس ہفتے یہ زیادہ ہے۔"

ان لوگوں کے لیے تھوڑی سی اصطلاحات جن کے پاس یاٹ کا لائسنس نہیں ہے۔ لہروں کا انحصار قمری چکر پر ہوتا ہے۔ اور جیسے ہی زمین گھومتی ہے، ہر 12,5 گھنٹے میں سورج اور چاند کی کشش ثقل ایک سمندری لہر پیدا کرتی ہے۔ 12,5 گھنٹے کے چکر کے آغاز میں ایک اونچی لہر ہوتی ہے، سائیکل کے وسط میں ایک ایب ہوتا ہے، اور آخر میں دوبارہ اونچی لہر آتی ہے۔ لیکن جیسے جیسے چاند کا مدار تبدیل ہوتا ہے، اسی طرح کم اور اونچی لہر میں فرق ہوتا ہے۔ جب چاند سورج اور زمین کے درمیان یا زمین کے مخالف سمت میں ہوتا ہے (مکمل چاند یا کوئی چاند نہیں)، تو ہمیں Syzygyn tides - سب سے زیادہ اونچی جوار اور سب سے کم نچلی لہریں ملتی ہیں۔ آدھے چاند پر ہمیں چوکور جوار ملتا ہے - سب سے کم جوار۔ دونوں انتہاؤں کے درمیان فرق بہت کم ہو جاتا ہے۔ قمری چکر 28 دن تک رہتا ہے: syzygian - quadrature - syzygian - quadrature.

جب تکنیکی ماہرین کو سمندری قوتوں کے جوہر کی وضاحت کی گئی، تو انہوں نے فوراً سوچا کہ انہیں پولیس کو بلانے کی ضرورت ہے۔ اور کافی منطقی۔ لیکن یہ پتہ چلتا ہے کہ دوست ٹھیک تھا. دو ہفتے پہلے، ایک ڈسٹرائر دفتر سے زیادہ دور نہیں تھا۔ جب بھی لہر اسے ایک خاص اونچائی تک لے جاتی ہے، جہاز کی ریڈار پوسٹ سرور روم کے فرش کی سطح پر ختم ہوتی ہے۔ اور ریڈار (یا الیکٹرانک جنگی سازوسامان، یا کوئی دوسرا فوجی کھلونا) کمپیوٹرز میں افراتفری پیدا کرتا ہے۔

راکٹ کے لیے فلائٹ مشن

مجھے ایک بڑے (تقریباً 400 ہزار لائنوں) راکٹ لانچ کنٹرول اور مانیٹرنگ سسٹم کو آپریٹنگ سسٹم، کمپائلر اور لینگویج کے نئے ورژن میں پورٹ کرنے کا کام سونپا گیا تھا۔ مزید واضح طور پر، سولاریس 2.5.1 سے سولاریس 7 تک، اور اڈا 83 میں لکھے گئے ورڈکس اڈا ڈیولپمنٹ سسٹم (VADS) سے، اڈا 95 میں لکھے گئے ریشنل اپیکس اڈا سسٹم تک۔ VADS کو ریشنل نے خریدا تھا، اور اس کی مصنوعات متروک، اگرچہ Rational نے Apex compiler میں منتقلی کو آسان بنانے کے لیے VADS مخصوص پیکجوں کے ہم آہنگ ورژن کو لاگو کرنے کی کوشش کی۔

تین لوگوں نے میری مدد کی صرف کوڈ کو صاف طور پر مرتب کیا۔ اس میں دو ہفتے لگے۔ اور پھر میں نے سسٹم کو کام کرنے کے لیے اپنے طور پر کام کیا۔ مختصراً، یہ ایک سافٹ ویئر سسٹم کا بدترین فن تعمیر اور نفاذ تھا جس کا میں نے سامنا کیا تھا، اس لیے بندرگاہ کو مکمل کرنے میں مزید دو مہینے لگے۔ اس کے بعد سسٹم کو جانچ کے لیے پیش کیا گیا، جس میں مزید کئی ماہ لگے۔ میں نے جانچ کے دوران پائے جانے والے کیڑے کو فوری طور پر درست کیا، لیکن ان کی تعداد میں تیزی سے کمی واقع ہوئی (سورس کوڈ ایک پروڈکشن سسٹم تھا، اس لیے اس کی فعالیت کافی قابل اعتماد طریقے سے کام کرتی تھی، مجھے صرف نئے کمپائلر میں موافقت کے دوران پیدا ہونے والے کیڑے دور کرنے تھے)۔ بالآخر، جب سب کچھ اس طرح کام کر رہا تھا جیسا کہ ہونا چاہیے، مجھے دوسرے پروجیکٹ میں منتقل کر دیا گیا۔

اور تھینکس گیونگ سے پہلے جمعہ کو فون کی گھنٹی بجی۔

راکٹ لانچ کا تجربہ تقریباً تین ہفتوں میں ہونا تھا، اور الٹی گنتی کے لیبارٹری ٹیسٹ کے دوران، حکموں کی ترتیب کو روک دیا گیا۔ حقیقی زندگی میں، یہ ٹیسٹ کو روک دے گا، اور اگر انجن شروع ہونے کے چند سیکنڈ کے اندر رکاوٹ واقع ہو جاتی ہے، تو معاون نظاموں میں کئی ناقابل واپسی کارروائیاں ہوں گی، جن کے لیے راکٹ کی طویل اور مہنگی تیاری کی ضرورت ہوگی۔ یہ شروع نہیں ہوتا، لیکن بہت سے لوگ وقت اور بہت سے، بہت سارے پیسے کے نقصان کے بارے میں بہت پریشان ہوتے. کسی کو آپ کو یہ بتانے نہ دیں کہ محکمہ دفاع لاپرواہی سے پیسہ خرچ کرتا ہے — میں نے کبھی بھی ایسے کنٹریکٹنگ مینیجر سے ملاقات نہیں کی جس نے بجٹ کو پہلے یا دوسرے نمبر پر نہ رکھا ہو، اس کے بعد شیڈول کے مطابق۔

پچھلے مہینوں میں، یہ الٹی گنتی چیلنج سیکڑوں بار کئی مختلف حالتوں میں چلائی گئی تھی، صرف چند معمولی ہچکیوں کے ساتھ۔ اس لیے اس کے ہونے کا امکان بہت کم تھا، لیکن اس کے نتائج بہت اہم تھے۔ ان دونوں عوامل کو ضرب دیں، اور آپ سمجھ جائیں گے کہ اس خبر نے میرے اور درجنوں انجینئرز اور مینیجرز کے لیے چھٹی والے ہفتے کی بربادی کی پیش گوئی کی تھی۔

اور نظام کو پورٹ کرنے والے شخص کے طور پر مجھ پر توجہ دی گئی۔

جیسا کہ سب سے زیادہ حفاظتی اہم نظاموں کے ساتھ، بہت سارے پیرامیٹرز لاگ ان کیے گئے تھے، لہذا کوڈ کی چند لائنوں کی شناخت کرنا کافی آسان تھا جو سسٹم کے کریش ہونے سے پہلے عمل میں لایا گیا تھا۔ اور بلاشبہ، ان کے بارے میں کوئی غیر معمولی بات نہیں تھی؛ ایک ہی دوڑ کے دوران ایک ہی تاثرات کو کامیابی کے ساتھ لفظی طور پر ہزاروں بار عمل میں لایا گیا تھا۔

ہم نے اپیکس سے لوگوں کو Rational میں بلایا کیونکہ انہوں نے ہی کمپائلر تیار کیا تھا اور ان کے تیار کردہ کچھ معمولات کو مشکوک کوڈ میں بلایا گیا تھا۔ وہ (اور باقی سب) متاثر ہوئے کہ لفظی طور پر قومی اہمیت کے مسئلے کی جڑ تک جانے کی ضرورت ہے۔

چونکہ جرائد میں کوئی دلچسپ چیز نہیں تھی، اس لیے ہم نے اس مسئلے کو مقامی لیبارٹری میں دوبارہ پیش کرنے کی کوشش کرنے کا فیصلہ کیا۔ یہ کوئی آسان کام نہیں تھا کیونکہ ایونٹ فی 1000 رنز پر تقریباً ایک بار ہوتا تھا۔ ایک مشتبہ وجہ یہ تھی کہ وینڈر کے تیار کردہ mutex فنکشن (VADS مائیگریشن پیکج کا حصہ) پر کال Unlock غیر مقفل کرنے کی قیادت نہیں کی. پروسیسنگ تھریڈ جس کو فنکشن کہا جاتا ہے دل کی دھڑکن کے پیغامات پر کارروائی کرتا ہے، جو برائے نام ہر سیکنڈ میں آتے ہیں۔ ہم نے فریکوئنسی کو 10 ہرٹز تک بڑھایا، یعنی 10 بار فی سیکنڈ، اور چلنا شروع کیا۔ تقریباً ایک گھنٹے بعد سسٹم نے خود کو لاک کر دیا۔ لاگ میں، ہم نے دیکھا کہ ریکارڈ شدہ پیغامات کی ترتیب وہی تھی جو ناکام ٹیسٹ کے دوران تھی۔ ہم نے مزید کئی رنز بنائے، سسٹم کو شروع ہونے کے 45-90 منٹ بعد مسلسل بلاک کر دیا گیا، اور ہر بار لاگ میں ایک ہی راستہ ہوتا تھا۔ اگرچہ ہم تکنیکی طور پر مختلف کوڈ چلا رہے تھے - پیغام کی فریکوئنسی مختلف تھی - سسٹم کا رویہ ایک جیسا تھا، اس لیے ہمیں یقین تھا کہ لوڈ کا یہ منظر نامہ ایک ہی مسئلہ کا سبب بن رہا ہے۔

اب ہمیں یہ جاننے کی ضرورت تھی کہ تاثرات کی ترتیب میں بلاکنگ کہاں واقع ہوئی ہے۔

اس نظام کے نفاذ نے Ada ٹاسک سسٹم کا استعمال کیا، اور اسے ناقابل یقین حد تک ناقص استعمال کیا۔ Ada میں ٹاسکس ایک اعلیٰ سطحی بیک وقت قابل عمل تعمیر ہیں، جو کہ عمل درآمد کے دھاگوں کی طرح ہے، صرف زبان میں ہی بنایا گیا ہے۔ جب دو کاموں کو بات چیت کرنے کی ضرورت ہوتی ہے، تو وہ "ملاقات طے کرتے ہیں"، ضروری ڈیٹا کا تبادلہ کرتے ہیں، اور پھر ملاقات کو روکتے ہیں اور اپنے آزادانہ عمل پر واپس آتے ہیں۔ تاہم، نظام مختلف طریقے سے لاگو کیا گیا تھا. ایک ٹارگٹ ٹاسک کے ملنے کے بعد، وہ ٹارگٹ ٹاسک دوسرے ٹاسک کے ساتھ ملایا گیا، جو پھر تیسرے ٹاسک کے ساتھ ملایا گیا، اور اسی طرح کچھ پروسیسنگ مکمل ہونے تک۔ اس کے بعد یہ تمام ملاقاتیں مکمل ہوئیں اور ہر کام کو اپنے انجام کی طرف لوٹنا پڑا۔ یعنی، ہم دنیا کے سب سے مہنگے فنکشن کال سسٹم سے نمٹ رہے تھے، جس نے ان پٹ ڈیٹا کے کچھ حصے پر کارروائی کرتے ہوئے "ملٹی ٹاسکنگ" کا پورا عمل روک دیا۔ اور اس سے پہلے صرف اس وجہ سے مسائل پیدا نہیں ہوئے کہ تھرو پٹ بہت کم تھا۔

میں نے اس ٹاسک میکانزم کو اس لیے بیان کیا کہ جب ملاقات کی درخواست کی گئی یا مکمل ہونے کی توقع کی گئی تو ایک "ٹاسک سوئچ" ہو سکتا ہے۔ یعنی، پروسیسر ایک اور کام پر کارروائی شروع کر سکتا ہے جو کہ انجام دینے کے لیے تیار ہے۔ اس سے پتہ چلتا ہے کہ جب ایک کام دوسرے کام کے ساتھ ملاپ کے لیے تیار ہوتا ہے، تو ایک بالکل مختلف کام انجام دینا شروع کر سکتا ہے، اور بالآخر کنٹرول پہلی ملاقات میں واپس آجاتا ہے۔ اور دوسرے واقعات رونما ہو سکتے ہیں جو کام کو تبدیل کرنے کا سبب بنتے ہیں۔ ایسا ہی ایک واقعہ سسٹم فنکشن کی کال ہے، جیسے کہ mutex کو پرنٹ کرنا یا اس پر عمل کرنا۔

یہ سمجھنے کے لیے کہ کوڈ کی کون سی لائن مسئلہ کا سبب بن رہی ہے، مجھے ٹاسک سوئچ کو متحرک کیے بغیر بیانات کی ترتیب کے ذریعے پیش رفت کو ریکارڈ کرنے کا ایک طریقہ تلاش کرنے کی ضرورت تھی، جو حادثے کو ہونے سے روکے۔ اس لیے میں فائدہ نہیں اٹھا سکا Put_Line()I/O آپریشن کرنے سے بچنے کے لیے۔ میں کاؤنٹر متغیر یا اس سے ملتی جلتی کوئی چیز سیٹ کر سکتا ہوں، لیکن اگر میں اسے اسکرین پر ظاہر نہیں کر سکتا تو میں اس کی قدر کیسے دیکھ سکتا ہوں؟

اس کے علاوہ، لاگ کی جانچ پڑتال کرتے وقت، یہ پتہ چلا کہ، دل کی دھڑکن کے پیغامات کی پروسیسنگ کے معلق ہونے کے باوجود، جس نے عمل کے تمام I/O آپریشنز کو روک دیا اور دیگر پروسیسنگ کو انجام دینے سے روک دیا، دیگر آزادانہ کاموں کو جاری رکھا گیا۔ یعنی کام کو مکمل طور پر مسدود نہیں کیا گیا تھا، صرف کاموں کا ایک (تنقیدی) سلسلہ تھا۔

یہ مسدود اظہار کا اندازہ کرنے کے لیے درکار اشارہ تھا۔

میں نے ایک Ada پیکیج بنایا جس میں ایک ٹاسک، ایک شمار شدہ قسم، اور اس قسم کا عالمی متغیر تھا۔ لاتعداد لغوی مسائل کی ترتیب کے مخصوص اظہار کے پابند تھے (جیسے Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked)، اور پھر اس میں اسائنمنٹ ایکسپریشنز داخل کیے جس نے متعلقہ گنتی کو عالمی متغیر کو تفویض کیا۔ چونکہ اس سب کا آبجیکٹ کوڈ صرف میموری میں ایک مستقل ذخیرہ کرتا ہے، اس لیے اس کے عمل کے نتیجے میں ٹاسک سوئچنگ کا امکان بہت کم تھا۔ ہمیں بنیادی طور پر ایسے تاثرات کے بارے میں شک تھا جو ٹاسک کو تبدیل کر سکتے ہیں، کیونکہ بلاکنگ کام کو واپس سوئچ کرتے وقت واپس آنے کے بجائے عمل درآمد پر واقع ہوئی تھی (کئی وجوہات کی بناء پر)۔

ٹریکنگ کا کام صرف ایک لوپ میں چلتا تھا اور وقتاً فوقتاً یہ دیکھنے کے لیے چیک کیا جاتا تھا کہ آیا عالمی متغیر کی قدر بدل گئی ہے۔ ہر تبدیلی کے ساتھ، قدر کو ایک فائل میں محفوظ کیا گیا تھا۔ پھر ایک مختصر انتظار اور ایک نیا چیک۔ میں نے فائل میں متغیر لکھا ہے کیونکہ ٹاسک کو صرف اس وقت انجام دیا گیا تھا جب سسٹم نے اسے ایگزیکیوشن کے لیے منتخب کیا تھا جب ٹاسک کو مسئلے کے علاقے میں تبدیل کیا گیا تھا۔ اس ٹاسک میں جو کچھ بھی ہوا اس سے دوسرے غیر متعلقہ بلاک شدہ کام متاثر نہیں ہوں گے۔

یہ توقع کی جا رہی تھی کہ جب سسٹم مشکل کوڈ پر عمل کرنے کے مقام پر پہنچ جائے گا، تو ہر اگلے اظہار پر منتقل ہونے پر عالمی متغیر دوبارہ ترتیب دیا جائے گا۔ پھر کچھ ایسا ہو گا جس کی وجہ سے ٹاسک تبدیل ہو جائے گا، اور چونکہ اس کی عمل آوری کی فریکوئنسی (10 ہرٹز) مانیٹرنگ ٹاسک سے کم ہے، اس لیے مانیٹر عالمی متغیر کی قدر کو پکڑ سکتا ہے اور اسے لکھ سکتا ہے۔ ایک عام صورت حال میں، میں شماروں کے ذیلی سیٹ کی دہرائی جانے والی ترتیب حاصل کر سکتا ہوں: ٹاسک سوئچ کے وقت متغیر کی آخری اقدار۔ معلق ہونے پر، عالمی متغیر کو مزید تبدیل نہیں ہونا چاہیے، اور لکھی گئی آخری قدر اس بات کی نشاندہی کرے گی کہ کون سا اظہار مکمل نہیں ہوا۔

میں نے ٹریکنگ کے ساتھ کوڈ چلایا۔ وہ جم گیا۔ اور نگرانی گھڑی کے کام کی طرح کام کرتی تھی۔

لاگ میں متوقع ترتیب تھی، جس میں ایک قدر کی وجہ سے خلل پڑا تھا جس سے یہ ظاہر ہوتا ہے کہ ایک mutex کو بلایا گیا تھا۔ Unlock، اور کام مکمل نہیں ہوا ہے - جیسا کہ ہزاروں پچھلی کالوں کا معاملہ ہے۔

اس وقت اپیکس انجینئرز اپنے کوڈ کا سختی سے تجزیہ کر رہے تھے اور انہیں mutex میں ایک ایسی جگہ ملی جہاں نظریاتی طور پر ایک تالا لگ سکتا تھا۔ لیکن اس کا امکان بہت کم تھا، کیونکہ صرف ایک خاص وقت میں ہونے والے واقعات کی ایک خاص ترتیب بلاکنگ کا باعث بن سکتی ہے۔ مرفی کا قانون، لوگو، یہ مرفی کا قانون ہے۔

مجھے جس کوڈ کی ضرورت تھی اس کی حفاظت کے لیے، میں نے mutex فنکشن کالز (OS mutex فعالیت کے اوپر بنایا ہوا) کو ایک چھوٹے سے مقامی Ada mutex پیکیج سے بدل دیا تاکہ اس ٹکڑے تک mutex رسائی کو کنٹرول کیا جا سکے۔

میں نے اسے کوڈ میں داخل کیا اور ٹیسٹ چلایا۔ سات گھنٹے بعد بھی کوڈ کام کر رہا تھا۔

میرا کوڈ Rational کے پاس جمع کرایا گیا تھا، جہاں انہوں نے اسے مرتب کیا، اسے جدا کیا، اور چیک کیا کہ اس نے وہی طریقہ استعمال نہیں کیا جو دشواری والے mutex افعال میں استعمال ہوتا تھا۔

یہ میرے کیریئر کا سب سے زیادہ ہجوم کوڈ کا جائزہ تھا 🙂 میرے ساتھ کمرے میں تقریباً دس انجینئرز اور مینیجر تھے، مزید دس لوگ کانفرنس کال پر تھے - اور ان سب نے کوڈ کی تقریباً 20 لائنوں کا جائزہ لیا۔

کوڈ کا جائزہ لیا گیا، نئی قابل عمل فائلوں کو جمع کیا گیا اور باقاعدہ ریگریشن ٹیسٹنگ کے لیے جمع کرایا گیا۔ چند ہفتوں بعد، الٹی گنتی کا تجربہ کامیاب رہا اور راکٹ نے پرواز کی۔

ٹھیک ہے، یہ سب ٹھیک اور اچھا ہے، لیکن کہانی کا کیا فائدہ ہے؟

یہ ایک بالکل ناگوار مسئلہ تھا۔ کوڈ کی لاکھوں لائنیں، متوازی عملدرآمد، ایک درجن سے زیادہ بات چیت کے عمل، خراب فن تعمیر اور ناقص عمل درآمد، ایمبیڈڈ سسٹمز کے لیے انٹرفیس اور لاکھوں ڈالر خرچ ہوئے۔ کوئی دباؤ نہیں، ٹھیک ہے۔

میں اس مسئلے پر کام کرنے والا اکیلا نہیں تھا، حالانکہ میں اسپاٹ لائٹ میں تھا جب میں پورٹنگ کر رہا تھا۔ لیکن اگرچہ میں نے یہ کیا، اس کا مطلب یہ نہیں ہے کہ میں کوڈ کی تمام سیکڑوں ہزاروں لائنوں کو سمجھ گیا ہوں، یا یہاں تک کہ ان کو سکم کر دیا ہے۔ کوڈ اور لاگز کا تجزیہ پورے ملک کے انجینئرز نے کیا، لیکن جب انہوں نے مجھے ناکامی کی وجوہات کے بارے میں اپنے مفروضے بتائے، تو مجھے ان کی تردید کرنے میں صرف آدھا منٹ لگا۔ اور جب مجھے نظریات کا تجزیہ کرنے کے لیے کہا گیا تو میں اسے کسی اور کو دے دوں گا، کیونکہ یہ میرے لیے واضح تھا کہ یہ انجینئر غلط راستے پر جا رہے تھے۔ متکبر آواز؟ ہاں، یہ سچ ہے، لیکن میں نے ایک اور وجہ سے مفروضوں اور درخواستوں کو رد کر دیا۔

میں مسئلے کی نوعیت کو سمجھ گیا۔ میں بالکل نہیں جانتا تھا کہ یہ کہاں ہو رہا ہے یا کیوں، لیکن میں جانتا تھا کہ کیا ہو رہا ہے۔

سالوں میں، میں نے بہت زیادہ علم اور تجربہ جمع کیا ہے۔ میں اڈا کے استعمال کے علمبرداروں میں سے ایک تھا اور اس کے فوائد اور نقصانات کو سمجھتا تھا۔ میں جانتا ہوں کہ Ada رن ٹائم لائبریریاں کس طرح کاموں کو ہینڈل کرتی ہیں اور متوازی عملدرآمد سے نمٹتی ہیں۔ اور میں میموری، رجسٹر اور اسمبلر کی سطح پر لو لیول پروگرامنگ کو سمجھتا ہوں۔ دوسرے لفظوں میں، مجھے اپنے شعبے میں گہرا علم ہے۔ اور میں نے انہیں مسئلہ کی وجہ تلاش کرنے کے لیے استعمال کیا۔ میں نے صرف بگ کے ارد گرد کام نہیں کیا، میں سمجھ گیا کہ اسے انتہائی حساس رن ٹائم ماحول میں کیسے تلاش کیا جائے۔

ضابطہ کے ساتھ جدوجہد کی ایسی کہانیاں ان لوگوں کے لیے زیادہ دلچسپ نہیں ہیں جو اس طرح کی جدوجہد کی خصوصیات اور حالات سے واقف نہیں ہیں۔ لیکن یہ کہانیاں ہمیں یہ سمجھنے میں مدد کرتی ہیں کہ واقعی مشکل مسائل کو حل کرنے میں کیا ضرورت ہے۔

واقعی مشکل مسائل کو حل کرنے کے لیے، آپ کو صرف ایک پروگرامر سے زیادہ ہونا ضروری ہے۔ آپ کو کوڈ کی "قسمت" کو سمجھنے کی ضرورت ہے، یہ اپنے ماحول کے ساتھ کیسے تعامل کرتا ہے، اور ماحول خود کیسے کام کرتا ہے۔

اور پھر آپ کا اپنا برباد چھٹی والا ہفتہ ہوگا۔

جاری رکھنا

ماخذ: www.habr.com