بڑے یو ایس بینک کے لیے مین فریم ماڈرنائزیشن پر میرا تجربہ (بھشیر لیپکشی)

مین فریم جدیدیت کا پس منظر:

      بینکنگ، انشورنس اور دیگر بڑے شعبوں میں کمپیوٹر انقلاب شروع ہونے کے بعد مین فریم ڈیٹا کو محفوظ طریقے سے ذخیرہ کرنے اور اس کا انتظام کرنے کے لیے سب سے بڑے انقلابات میں سے ایک تھا۔ اب بھی بہت سے بڑے بینک اور انشورنس کمپنیاں مین فریم سسٹم کو برقرار رکھتی ہیں۔

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

 اس ڈیجیٹل تیز دنیا میں مین فریم جیسے لیگیسی سسٹم سے ڈیٹا تک رسائی حاصل کرنا صارفین کو تیز رفتار خدمات فراہم کرنا مشکل ہوتا جا رہا ہے، اس لیے کلائنٹ جدیدیت کی طرف جانے کے خواہاں ہیں۔

مین فریم ماڈرنائزیشن کے لیے جن اہم اقدامات کی پیروی کی جائے گی وہ یہ ہیں:

1. دوبارہ انجینئرنگ: ڈیجیٹل پلیٹ فارمز جیسے کلاؤڈ اور مائیکرو سروسز میں خلل ڈالنے والی تبدیلی
2. دوبارہ میزبانی: تقسیم شدہ پلیٹ فارم پر قابل اطلاق ایپلی کیشنز کو دوبارہ پلیٹ فارم بنانا جو کہ میراثی آرکیٹیکچر اور کوڈ کو برقرار رکھے۔
3. پلیس ماڈرنائزیشن میں: Leverage System z اور System I کی جدید کاری کی صلاحیتوں کو Legacy پر صحیح مرکب کے ساتھ
4. تبدیل کریں: مکمل فٹمنٹ تجزیہ کرنے کے بعد ایپلیکیشن کو مناسب COTS پروڈکٹ سے تبدیل کریں۔

یہ بلاگ Re-Engineering کے منظر نامے کے بارے میں بیان کرتا ہے۔ اس منظر نامے میں ہمیں لیگیسی کوڈ سے بزنس رولز نکالنے کی ضرورت ہے جسے فارورڈ انجینئرنگ ٹیم ضرورت کے دستاویز کے طور پر استعمال کرے گی۔

مین فریم کوڈ کو بزنس رولز میں کیسے تبدیل کیا جائے؟

1. ٹیمپلیٹ کی تیاری:

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

کاروباری قواعد کو ایک ساتھ رکھنے کے لیے ٹیمپلیٹ کلیدی حیثیت رکھتا ہے، اگر ٹیمپلیٹ ذیل میں بیان کر سکتا ہے تو یہ مددگار ہو گا:

1. ملازمت کا خلاصہ (جے سی ایل سمری) جو ذیل میں بیان کرنا چاہئے -
   1. ملازمت کی فعالیت / تفصیل
   2. ملازمت میں استعمال ہونے والی فائلیں (پڑھنا/لکھنا)
   3. استعمال شدہ DB2 میزیں (پروگرام وار)
   4. شیڈولنگ کی معلومات
   5. ملازمت کا بہاؤ (شاید درخت کا ڈھانچہ)
   6. ہدایات کو دوبارہ شروع کریں۔
2. کاروباری قواعد - اس میں مخصوص پروگرام کے مخصوص فنکشن سے وابستہ قواعد کی وضاحت ہونی چاہیے۔
3. ریکارڈ لے آؤٹ - پروگرام میں استعمال ہونے والے ریکارڈ لے آؤٹ/فائل سٹرکچرز
4. فیلڈ میپنگ - اسے یا تو تصویری یا ٹیبل فارمیٹ میں بیان کرنا چاہیے کہ کس طرح بزنس منطق/پروگرام میں میپنگ کو ہدف بنانے کا ذریعہ

   2. کاروباری قواعد لکھنا:

     کوڈ کا تجزیہ کریں اور پروگرام کے منطقی بہاؤ کو سمجھیں۔ ہر پیراگراف کو بطور قاعدہ لکھنے کی کوشش نہ کریں، اگر ضرورت ہو تو ہمیں کاروباری منطق/قاعدہ کو منطقی انداز میں لانے کے لیے پیراگراف کو یکجا کرنا پڑ سکتا ہے۔

کاروباری قواعد لکھتے وقت درج ذیل پر غور کرنے کی ضرورت ہے:

• ہر لین دین اور جاب کو بزنس فنکشن میں میپ کریں۔   
• ایک بار قواعد کی گرفت میں آنے کے بعد، انہیں لیول-4، لیول-3، لیول-2، لیول-1، اور لیول-0 پر نقشہ بنائیں۔ لیول-0 سب سے زیادہ ہے اور یہ فیچر حاصل کرنے کے لیے لیول 1 سے 4 کا مجموعہ ہے (مثال: کسٹمر آن بورڈنگ لیول-0 ہوگی)
• عنوانات، ذیلی عنوانات - کاروباری اصولوں کو لکھتے وقت عنوانات اور ذیلی سرخیاں بہت اہم ہوتی ہیں مثال کے طور پر: عمومی طور پر، بنیادی منطق پر کارروائی کرنے کے لیے پیراگراف پروسیسنگ ہو گی، اس سیکشن/پیراگراف کے تحت تمام فنکشنلٹیز ذیلی سرخیوں کے طور پر آئیں گی، آپ پوری طرح کو سمجھنے کے قابل ہو جائیں گے۔ سرخی اور ذیلی عنوانات دیکھ کر بہاؤ یا منطق۔
• عارضی متغیرات/ ورکنگ سٹوریج متغیرات - یقینی بنائیں کہ کسی بھی Temp متغیر کا حوالہ دیں، اصول نمبر کا ذکر کریں جہاں ہم اس متغیر کو استعمال کریں گے یا اس کا حوالہ دیں گے۔ 
• IF شرائط اور جائزے کے بیانات - IF حالات کے لیے پرانے پروگرامنگ اسٹائل میں END-IF کا ذکر نہیں کیا جائے گا، لہذا یقینی بنائیں کہ END-IF کا ذکر کریں اور نیسٹڈ IFs کی صورت میں رنگوں کا استعمال کریں۔ ہر شرط کو ایک مخصوص اصول میں توڑ دیں۔
• پرفارم لوپس - لوپ کے بارے میں واضح طور پر ذکر کریں کہ یہ کب شروع ہو رہا ہے اور کب ختم ہو رہا ہے۔
• ARRAYS/ٹیبلز - Arrays/Table کی صورت میں تمام ڈیکلریشن کا ذکر کریں اور کسی مخصوص فنکشن کے لیے اس سے منسلک استعمال۔
• ڈیٹا بیس - ڈیٹا بیس سے متعلق منطق لکھتے وقت، بہتر ہے کہ ڈیکلیئر کرسر اور دیگر ایس کیو ایل اسٹیٹمنٹس کو بطور قاعدہ لکھیں اور جہاں بھی آپ کو حوالہ دینے کی ضرورت ہو وہاں حوالہ دیں۔ بزنس رول میں منطق کو شامل کرتے ہوئے SQLCODE کے معنی کا ذکر کریں۔
• اغلاط کی درستگی - اس بات کو یقینی بنائیں کہ DISPLAY بیانات کے ساتھ غلطی سے نمٹنے کا صحیح طریقے سے دستاویز کیا گیا ہے۔
• عام معمولات - کامن روٹینز رولز کو ایک عام شیٹ یا دستاویز میں رکھا جا سکتا ہے تاکہ فارورڈ انجینئرنگ ٹیم انہیں ایک بار بنا کر استعمال کر سکے۔

انجینئرنگ ٹیم کو آگے بڑھانے کے لیے کاروباری قواعد پیش کرنا:

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

مین فریم کی طرف سے بہتر طریقہ یہ ہے کہ کام کی سطح پر بہت اعلی سطحی بہاؤ کے ساتھ کچھ فلو ڈایاگرام سامنے لایا جائے۔ تاکہ پورے بہاؤ پر فارورڈ انجینئرنگ ٹیم کو ہضم کرنا آسان ہو اور مین فریم کے لڑکوں کو بہاؤ کے بارے میں بھی وضاحت کرنا آسان ہو۔

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

قوانین کو جاوا میں تبدیل کرنا:

      مین فریم COBOL کو جاوا میں تبدیل کرتے وقت، کسی کو COBOL اور Java کے درمیان فرق کو سمجھنا چاہیے۔ سب سے پہلے، COBOL طریقہ کار کی زبان ہے، اور اس نے ترتیب وار مراحل کی وضاحت کی ہوگی۔ جبکہ جاوا آبجیکٹ اورینٹڈ لینگویج ہے جو OOPs تصورات کی پیروی کرتی ہے۔

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

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

COBOL کوڈ کو تبدیل کرنے کے لیے جاوا کی طرف سے درج ذیل غور و فکر کرنا ہے:

1. کلائنٹ کے ماحول کے مطابق جاوا کوڈنگ کے معیارات کو سمجھیں۔
2. COBOL اور جاوا ڈیٹا کی اقسام کے درمیان فرق
3. COBOL اور Java کے درمیان مساوی افعال۔
4. لیگیسی ڈیٹا بیس کالز (یا تو JPA یا JDBC) کی صورت میں جاوا میں کون سا ڈیٹا بیس کنکشن استعمال کیا جائے؟
5. کیا DB سوالات کے لیے کوئی استفسار کی اصلاح کی جا سکتی ہے؟
6. کیا کوئی متوازی رن (قدموں کے درمیان) ممکن ہو سکتا ہے؟
7. کیا ہم DML آپریشنز پر چنکنگ منطق کو لاگو کر سکتے ہیں؟
8. کسی بھی عام معمولات/سروسز کو بنانے اور دوبارہ استعمال کرنے کی ضرورت ہے۔

• SEO سے چلنے والا مواد اور PR کی تقسیم۔ آج ہی بڑھا دیں۔
• پلیٹو بلاک چین۔ Web3 Metaverse Intelligence. علم میں اضافہ۔ یہاں تک رسائی حاصل کریں۔
• ماخذ: https://www.finextra.com/blogposting/23602/my-experience-on-mainframe-modernization-for-major-us-bank?utm_medium=rssfinextra&utm_source=finextrablogs