Menulis ulang assembler IBM + COBOL dalam C ++

Saya bekerja sebagai agen / manajer rental untuk perusahaan rental mobil yang menjalankan sistem rental yang ditulis pada tahun 1972. Saya memutuskan bahwa mungkin sudah waktunya untuk pembaruan. Untuk sedikit latar belakang, berikut adalah contoh singkat dari kegilaan yang harus kita hadapi dari program ini setiap hari:

Agen rental harus ingat bahwa pencetakan pada satu layar menggunakan "MXC" di bidang ACT (semuanya didasarkan pada kode pendek), yang secara membingungkan berarti "tampilan MaXimum pada Kontrak", sedangkan pada yang lain memerlukan PR (untuk PRint) di bidang AKSI, tetapi beberapa layar menggunakan Y di bidang PT (untuk PrinT), namun layar lain menggunakan Y di bidang PRT (untuk PRinT), namun layar lain mengharuskan pengguna untuk menekan enter (tetapi bukan enter di sebelah huruf, karena itu adalah karakter baris baru, itu harus menjadi enter pada tombol angka) dan kemudian F8, layar berbeda tetapi terkait hanya membutuhkan F8, beberapa layar memiliki bidang berlabel PRT, yang harus untuk PRINT, tetapi bidang sebenarnya tidak melakukan apa pun dan pencetakan dilakukan secara otomatis setelah melalui beberapa permintaan, dan masih banyak layar memiliki bidang berlabel PRINT Y / N,yang gila-gilaan default untuk Y untuk operasi di mana lokasi lain sudah memberikan dokumen, dan ke N untuk operasi di mana dealer lain akan membutuhkan dokumen.

Saya memutuskan bahwa saya bisa melakukan pekerjaan yang lebih baik dari ini, jadi saya berangkat untuk menghubungi orang di perusahaan yang akan membuat keputusan untuk memperbarui ini. Saya akhirnya menghubungi VP IT, yang bertanggung jawab atas program ini. Saya mendapatkan sedikit informasi darinya, dan mengetahui bahwa perusahaan rental mobil saya memiliki program rental yang ditulis dalam assembler mainframe IBM dengan sedikit COBOL. Dia mengatakan bahwa tidak ada posisi yang terbuka saat ini, tetapi saya harus tetap kirim e-mail padanya resume saya (kalau-kalau ada sesuatu yang terbuka).

Ini mengarahkan saya ke pertanyaan saya.

Yang pertama adalah teknis. Dengan gagasan meningkatkan rawatan di masa depan, pemikiran saya adalah menulis ulang dalam bahasa tingkat yang lebih tinggi daripada bahasa rakitan. Area pengalaman saya ada di C ++, jadi itu pilihan yang jelas bagi saya. Perusahaan sangat membutuhkan cara yang lebih mudah untuk memperbarui program, karena saya baru-baru ini membaca sebuah artikel di mana orang yang saya ajak bicara dikutip mengatakan bahwa tim bekerja keras, dan mereka dengan bangga mengumumkan bahwa program sekarang memiliki dukungan untuk 5 -digit kode lokasi (bukan 4) dan 8 digit nomor mobil (bukan 7). Filosofi saya tentang pembaruan, bahkan dalam situasi yang mengerikan ini, sejalan dengan Joel: http://www.joelonsoftware.com/articles/fog0000000069.html singkatnya, menulis ulang haruslah bertahap, alih-alih membuang semua yang ada sebelumnya dan mulai segar.

Apakah ada cara mudah untuk mengintegrasikan perakitan IBM dengan C ++, dan jika demikian, bagaimana saya harus melakukannya? Saya samar-samar menyadari kata kunci asm, tetapi saya tidak tahu apakah yang terbaik untuk menggunakan itu atau melakukan sesuatu yang lain. Apakah rencana semacam itu keliru? Saya melakukan sebagian besar pekerjaan saya di Linux menggunakan g ++ dan GNU make, jadi jawaban khusus untuk yang disambut, tapi jelas tidak diperlukan (karena saya tidak tahu apa jenis sistem mereka tidak membangun, tapi saya kira hampir tidak ada).

Pertanyaan kedua lebih bersifat politis. Bagaimana saya harus meyakinkan perusahaan ini bahwa mereka perlu beralih? Penghematan biaya teoretis sangat besar (berdasarkan perkiraan saya, perusahaan menghabiskan jutaan dolar atau lebih per tahun, hanya pada peningkatan biaya pelatihan untuk belajar bagaimana berinteraksi dengan program ini), tetapi perubahan yang saya usulkan mungkin akan menempatkan semua programmer saat ini kehilangan pekerjaan, harus diberlakukan, sehingga ada hambatan struktural yang besar untuk berubah.

sunting: Saya harus menjelaskan mengapa saya memodifikasi apa yang sudah dimiliki perusahaan sebagai solusi terbaik bagi saya. Saya masih terbuka untuk saran lain, karena ini adalah monster dari sebuah program. Saya belum pernah memiliki pekerjaan pemrograman sebelumnya, jadi tolong perbaiki saya pada analisis yang salah yang mungkin saya berikan.

Pertama, ada solusi di luar rak.

Dari pembicaraan saya dengan beberapa manajer tingkat menengah tentang hal semacam ini, salah satu masalah utama dengan beralih ke sistem baru adalah sejumlah besar karyawan setia yang telah bersama perusahaan selama beberapa dekade dan merasa nyaman dengan sistem tersebut sekarang. . Jika saya memiliki kemampuan untuk mengubah apa yang kita miliki, saya dapat mempertahankan antarmuka saat ini dalam semacam 'mode kompatibilitas'. Pengguna sudah harus masuk untuk menggunakan sistem saat ini, jadi saya bisa menambahkan kemampuan untuk mengaktifkan pengaturan ketika pengguna masuk untuk 'pertama kali' (setelah saya melakukan perubahan ini), di mana mereka diberi pilihan untuk menggunakan salah satu antarmuka 'klasik' atau antarmuka 'baru'. Tidak ada cara saya akan menemukan solusi yang memungkinkan,

Perusahaan saya juga memiliki perangkat lunak yang kami gunakan; kami tidak melisensikannya. Ini berarti bahwa manajemen yang saya ajak bicara saat ini adalah orang yang sama yang sebenarnya dapat memberi saya wewenang untuk melakukan perubahan. Dengan solusi pihak ketiga, saya harus mendapatkan persetujuan dari perusahaan saya selain mendapatkan hak apa pun yang diperlukan dari perusahaan yang mengembangkan produk yang kami gunakan, yang menambah rintangan tambahan. Ini juga membutuhkan meyakinkan perusahaan untuk menyerah pada produk "mereka" dan mengambil beberapa produk lain, yang sepertinya merupakan rintangan yang lebih besar daripada mencoba memperbarui apa yang kita miliki, tetapi saya bisa saja salah dalam masalah ini.

Akhirnya, melihat ke masa depan, saya tidak hanya ingin meningkatkan antarmuka pengguna dan memperbaiki beberapa bug. Setelah saya memperbarui masalah 'mendesak' itu, saya berharap untuk memperbarui cara mendasar perusahaan berjalan terkait dengan teknologi. Setelah menghabiskan 1-2 tahun untuk masalah-masalah seperti ini, rencana saya adalah kembali ke manajemen dan mengusulkan perubahan yang lebih dramatis. Ada banyak cara perusahaan berjalan yang secara fundamental dapat ditingkatkan dengan teknologi yang mereka tidak gunakan saat ini. Misalnya, masing-masing daerah cukup banyak beroperasi dengan cara yang sama. Bandara utama setempat adalah pusat hub untuk mendistribusikan mobil. Mereka terutama dikirim berdasarkan kebutuhan. Namun, bandara digunakan sebagai pangkalan untuk semua operasi. Mereka akan mengirim dua orang dalam satu mobil ke lokasi saya untuk mengambil satu mobil dari kami yang tidak kami butuhkan, kemudian kembali ke bandara dengan mobil yang mereka datangi, ditambah apa yang mereka ambil kembali (kami berjarak 32 mil dari bandara). Kemudian mereka akan datang ke lokasi 5 mil jauhnya dari kami dengan dua mobil untuk mengantar salah satu dari mereka, kemudian kembali dengan mobil mereka yang lain ke bandara. Mereka melakukan ini bahkan jika mobil yang kami kirim kembali adalah jenis mobil yang sama yang mereka butuhkan di dekat kami. Saya sudah bersama perusahaan selama sekitar dua tahun sekarang, dan saya hanya tampaknya mereka menyimpang dari ini dalam keadaan darurat kekurangan mobil yang paling ekstrem (sekitar tiga kali sebelumnya). Saya akan mengganti 4 orang yang bekerja di setiap wilayah dengan sistem penjadwalan otomatis yang menentukan mobil mana yang pergi dan mencoba serta menemukan jalur yang memerlukan paling sedikit waktu + mil + driver untuk mengantarkan semua mobil ke tempat yang mereka inginkan, sebagai contoh perbaikan tingkat yang lebih tinggi Saya berharap suatu hari nanti menambahkan.

Namun, sebelum saya merasa nyaman untuk mengajukan semua ini, saya merasa akan sangat membantu untuk mendapatkan pijakan di perusahaan dan basis kode dengan melakukan tugas yang lebih kecil, seperti memperbarui antarmuka. Solusi seperti outsourcing atau sebaliknya akan menghapus kemungkinan ini.

Mengurung diri di depan teknis ...

Saya sarankan Anda mulai dengan menentukan lingkungan di mana aplikasi berjalan. "Mainframe" bisa berarti beberapa hal yang berbeda, mengingat usia aplikasi itu bisa CICS atau IMS . Mungkin juga penulis asli menulis tugas awal mereka sendiri.

Bergantung pada tempat aplikasi berjalan, kemungkinan akan menggunakan API untuk lingkungan itu, CICS sekarang menggunakan antarmuka yang sangat berbeda dari hari-hari awalnya, saya tidak bisa berbicara untuk IMS. Jika aplikasi adalah tugasnya sendiri, maka mungkin saja memiliki API internal sendiri - saya menghabiskan tujuh tahun mendukung binatang seperti itu, ditulis pada era yang sama.

Hal lain yang perlu dipertimbangkan, mengingat usia aplikasi, adalah Assembler yang ingin Anda integrasikan C ++ mendahului keberadaan Lingkungan Bahasa (LE). Dengan demikian, kecuali Assembler telah diperbarui agar sesuai dengan LE, Anda akan mengalami kesulitan karena C dan C ++ sesuai dengan LE dan mengharuskan penelepon dan callees mereka juga untuk menyesuaikan.

Poin lain yang perlu dipertimbangkan, jika aplikasi ini berjalan pada mainframe yang hampir mati, Anda mungkin melihat mencoba untuk mengintegrasikan dengan aplikasi yang berjalan pada perangkat keras dan perangkat lunak yang tidak didukung. Ini tidak seperti mencoba mengintegrasikan dengan aplikasi yang ditulis pada tahun 1989 yang berjalan pada DOS 4.01 pada perangkat keras aslinya.

Anda melompati pistol. Dari deskripsi Anda, sepertinya Anda belum sepenuhnya memahami lingkungan teknis saat ini (OS apa sebenarnya, di mana dan bagaimana data disimpan, apakah ada antarmuka ke sistem lain, dll.). Tetapi yang lebih penting: rencana serius harus mempertimbangkan alternatif untuk penulisan ulang perangkat lunak yang sebagian atau seluruhnya dilakukan di rumah, yaitu perangkat lunak di luar rak, penyelesaian awal penulisan ulang, perangkat lunak sebagai layanan dll.

Apa pun cara perusahaan akhirnya berjalan, pertama-tama perlu analisis yang solid tentang apa yang dilakukan perangkat lunak saat ini dan apa persyaratan untuk solusi baru tersebut.

Jadi mengapa Anda tidak menawarkan untuk melakukan analisis ini?

Saya terkejut Anda mendapat respons yang sopan!

Mari kita lihat ini dari sudut pandang mereka.

Mereka berhasil mengelola sistem berusia tiga puluh tahun dengan kemungkinan ratusan ribu baris kode, antarmuka ke mungkin dua puluh sistem lain yang mewujudkan proses bisnis yang berkembang lebih dari empat puluh tahun.

Mereka mungkin / mudah-mudahan ahli di bidangnya dan karena itu akan menganggap C ++ sebagai langkah turun dari IBM "High Level Assembler Language" untuk memberikan judul lengkapnya. Bahasa assembler IBM sangat kuat dan bahasa "MACRO" adalah implementasi terbaik dari bahasa pra-pemrosesan / templat yang pernah ada.

Akan ada proposal untuk mengganti sistem mereka setiap lima tahun sejak pertama kali diterapkan. Beberapa akan ditolak setelah studi kelayakan, beberapa akan mendapatkan sejauh tahap desain sebelum mereka kehilangan anggaran, beberapa mungkin bahkan masuk ke dalam kode dan mungkin tahap pengujian sebelum mereka mencapai masalah kinerja dan dikalengkan.

C ++ tidak akan membantu. Tidak ada perpustakaan grafis di lingkungan tempat aplikasi berjalan. (Ada perpustakaan grafis 3270 tetapi tidak mungkin didukung dalam C ++ karena tidak ada yang menggunakannya, dan, ada perpustakaan klien "X" penuh tetapi Anda harus berada di lingkungan yang berbeda untuk menggunakannya.)

Mereka memiliki antarmuka pengguna yang jauh dari sempurna tetapi yang terkenal dan cepat. Operator berpengalaman akan mengisi formulir sekitar tiga kali lebih cepat menggunakan layar hijau daripada GUI yang setara. Plus mereka dapat memperhatikan pelanggan saat mereka menyentuh tipe.

Operator layar akan membutuhkan pelatihan antarmuka apa pun yang mereka gunakan, melatih kembali semua karyawan yang ada untuk menggunakan GUI baru dan asing akan menjadi item anggaran besar dibandingkan dengan hanya melatih karyawan baru pada sistem dunia lama.

Saya memiliki masalah serupa beberapa tahun yang lalu di BellSouth. Saya hanya menulis kode COBOL untuk memindai program bahasa assembler byte demi byte, memisahkan opcodes dan operan, mengonversi instruksi cabang ke tos, dan mengonversi petunjuk bandingkan ke IFs. Program ini mengonversi instruksi DC ke kode COBOL Data Division yang setara, dan mengonversi gerakan, zaps, dll., Sesuai keperluan.

Setelah itu selesai, saya menulis program kedua untuk mengubah IF dan GOTO ke IF-THEN, dengan gerakan dan semacam itu di antara cluster-cluster ini (ini tidak terlalu sulit untuk dilakukan - rahasianya adalah memasukkan IF dan Lain-lain saat Anda membaca ulang cobol "pidgin" fase 1 dari belakang-ke-depan).

JIKA-THEN-ELSER mencari situasi di mana ia menemukan referensi GOTO di dekat label, yang dapat dihapus dengan aman (mengurangi jumlah referensi dengan 1). Anda menjalankan program IF-THEN-ELSER ini secara iteratif (yaitu, Anda menjalankannya lagi dan lagi, berhenti hanya ketika pass terakhir Anda tidak dapat menemukan cara untuk membuat perubahan lagi). Sebagian besar pekerjaan kritis dilakukan oleh elser if-then-elser ini, yang produk COBOL-nya harus ditinjau dan diperiksa dengan teliti oleh programmer bahasa assembler yang kompeten dan berpengalaman (yaitu, saya). Dalam pengalaman saya, "if-then-elser" saya mampu menghilangkan lebih dari 90 persen GO TOs yang dihasilkan dari instruksi cabang asli.

Saya kira mungkin untuk maju dari titik ini dengan konversi langsung ke C (atau C ++) - bahasa yang saya juga mengerti. Namun, di BellSouth, bahasa target kami adalah COBOL / II. Selalu ada sedikit kerumitan yang muncul dari situasi di mana label yang tersisa memiliki beberapa referensi GO TO (berkali-kali, situasi ini ditangani oleh COBOL PERFORMs, tetapi kadang-kadang dapat dengan mudah diwakili oleh OR dan DAN konstruksi).

Saya pikir itu bagus untuk menghasilkan kode dalam blok-terstruktur elegan COBOL / II, dengan EVALUASI (Konstruksi kasus) dan 88 nama kondisi tingkat. Menambahkan sentuhan akhir ini menghasilkan sepasang program lain, yang terbukti praktis pada program COBOL yang tidak berasal dari program yang dikonversi dari assembler.

Saya tidak tahu apakah ini membantu.

Seperti yang dikomentari orang lain di atas, Anda harus melakukan proses ini dengan hati-hati. Ini membantu untuk memiliki 10-12 tahun pengalaman assembler coding menginformasikan proses pengambilan keputusan Anda. Kami yang memiliki pengalaman itu sulit ditemukan lagi.

Sebagai catatan terakhir: Kami hanya menulis di assembler saat itu karena kompiler untuk bahasa tingkat tinggi menghasilkan kode objek yang rumit dan tidak efisien. Kompiler COBOL "yang mengoptimalkan" saat ini tidak memiliki kebiasaan buruk yang sama. ----------

Nasihat Joel umumnya masuk akal, tetapi dalam hal ini penulisan ulang yang lengkap sudah terlambat. Idealnya, menulis ulang dengan battleaxe, karena apa yang Anda hadapi di sini adalah monster.

Saya tidak yakin apa yang harus ditambahkan, karena Anda telah membuat argumen yang cukup bagus untuk menulis ulang ini sendiri. Satu-satunya rekomendasi saya adalah untuk melewati C ++ sepenuhnya dan langsung menuju antarmuka web untuk sistem rental, karena itu mungkin akan lebih mudah untuk melatih pekerja, dan akan menghemat banyak pekerjaan di UI (serta membuat lebih mudah mendapatkan darah baru di proyek, atau bahkan hanya mengalihdayakan semuanya).

Adapun programmer COBOL yang ada - mungkin mereka dapat membantu dengan mendokumentasikan sistem yang ada, dan dengan proses migrasi.

Adapun aspek teknis, banyak akan tergantung pada kualitas - modularitas - dari kode assembler. Beberapa programmer memahami pentingnya membuat modul dengan fungsi spesifik dan terbatas dan antarmuka parameter yang jelas dan sederhana, menggunakan konvensi subrutin linkage IBM standar. Akan tetapi, mayoritas besar cenderung menciptakan monstrositas monolitik.

Dengan yang pertama, penggunaan kembali dimungkinkan, dan seharusnya tidak terlalu sulit untuk mengerjakan "lem" antara C ++ dan assembler, dengan asumsi modul assembler Anda menggunakan urutan panggilan standar (atau setidaknya konsisten). Namun, dalam kemungkinan besar, kode assembler akan berantakan. Meskipun dimungkinkan untuk menulis assembler terstruktur, sangat sedikit orang yang melakukannya, dan hampir tidak mungkin untuk melihat "desain" apa pun untuk mulai menulis ulang.

Di sisi lain, assembler 360/370 cukup tingkat tinggi dibandingkan dengan mikroprosesor saat ini, dan jauh lebih sederhana, dan C kadang-kadang dianggap "assembler tingkat tinggi". Saya bekerja untuk perusahaan DBMS yang produknya seluruhnya 370 assembler, dan arsitek utama kami percaya mungkin untuk menerjemahkan mesin kode assembler ke C (untuk portabilitas masa depan). Saya skeptis, tetapi intinya adalah bahwa jaraknya tidak sebesar yang Anda kira.

Tidak tahu apakah semua ini bermanfaat. Seperti yang saya katakan, saya pikir ini sangat tergantung pada kualitas dan ukuran kode asli.

Saya tidak tahu apakah ini lelucon atau tidak - perusahaan Anda serius menjalankan kode yang awalnya ditulis 39 tahun yang lalu? Jika itu berjalan pada Sistem / 360, Anda harus mengkompilasi g ++ dari sumber ...

Jujur, saya bahkan tidak akan berpikir untuk menggunakan kode lama mana pun; Anda perlu mengambil pendekatan baru, duduk dan berpikir tentang apa yang perlu dimasukkan ke dalam desain, dan lakukan dari bawah ke atas. Ya, itu akan melibatkan sedikit perencanaan yang adil, tetapi saya tidak berpikir bahkan Joel akan mengatakan ini adalah kasus untuk perubahan tambahan.

Sedangkan untuk membujuk perusahaan bahwa Anda perlu beralih, Anda perlu menunjukkan alasan spesifik yang akan meningkatkan efisiensi, mengarah pada biaya yang lebih rendah, dan / atau menunjukkan bahwa apa yang Anda gunakan saat ini membahayakan lini bawah sekarang.

Satu komentar lain - saya membayangkan bahwa perusahaan penyewaan mobil lain telah bergabung dengan kita semua di abad ke-21; Saya akan melakukan sedikit pengintaian untuk melihat bagaimana mereka melakukannya (berbasis web, saya bayangkan), dan mungkin memodelkannya setelah salah satu dari sistem tersebut (yaitu, jangan menciptakan kembali roda).

Semoga berhasil!

Secara teori seharusnya tidak sulit untuk meyakinkan manajemen atas untuk mengganti sistem lama jika Anda dapat menunjukkan kepada mereka bahwa itu akan menyelamatkan mereka megabucks. Dan itu akan terjadi. Akan semakin sulit menemukan programmer untuk memelihara sistem ini, dan programmer tersebut akan semakin mahal. Ini bukan masalah "jika", ini masalah "kapan". Itu benar-benar harus diperbarui.

Namun pertanyaannya adalah apakah Anda dapat meyakinkan mereka tidak hanya bahwa mereka perlu memperbarui (dan mereka mungkin tahu itu), tetapi bahwa itu harus proyek in-house. Apalagi jika tim itu hanya Anda. Cukup sering penggantian besar semacam itu dilakukan oleh pihak luar. Bahkan mungkin ada beberapa perangkat lunak yang tersedia untuk dipertimbangkan. Opsi-opsi ini perlu diselidiki dan manajer Anda akan bersikeras bahwa itu terjadi jika mereka masuk akal.

Adapun tugas, jika Anda melakukannya, saya benar-benar percaya bulldoze-penulisan ulang mungkin sesuai dalam kasus ini. Argumen Joel tidak berlaku dalam setiap kasus. Namun saya tidak bisa benar-benar tahu tanpa melihatnya.

1. Perubahan tambahan tidak mungkin dilakukan.

2. Kemungkinan ada solusi yang tersedia. Ada banyak bisnis penyewaan mobil.

3. Jika, sebagai upaya terakhir, Anda perlu menulis ulang, pertama-tama luangkan waktu untuk memikirkan bagaimana sistem baru akan bekerja.
   Setelah Anda mengidentifikasi fungsionalitas dan antarmuka, maka Anda dapat memilih alat pengembangan yang paling sesuai dengan kebutuhan (dan keterampilan Anda).

Salah satu strategi untuk meminimalkan tekanan kepada pengguna akhir adalah mulai meniru antarmuka lama yang jelek yang diketahui pengguna, dengan beberapa pilihan seperti daftar drop-down untuk mnemonik jelek, kemudian secara bertahap menambahkan fungsionalitas UI dan menyapih mereka ke UI modern.

Anda mungkin tidak ingin mempertahankan format file data yang sama, jadi tidak akan ada kembali setelah mereka beralih.