IBM Bob

Bob bertemu mainframe

IBM Bob Premium Package for Z kini tersedia secara umum. Inilah alasan model general-purpose sering salah memahami COBOL kamu, dan apa yang kami lakukan untuk mengatasinya.

Bob bertemu mainframe

Penulis

Louisa MuschalNicolas DangevilleStefan Liesche

Diterbitkan

Kategori

announcement

Bagikan

Bob bertemu mainframe

Saat kami meluncurkan Bob, kami mengatakan bahwa masalah yang menarik bukanlah menulis kode baru, melainkan bekerja di dalam sistem yang sudah ada — menemukan tempat yang tepat untuk membuat perubahan, menghormati konvensi yang disepakati tim bertahun-tahun lalu, dan menjaga perilaku tetap konsisten lintas file yang telah berkembang selama sangat lama.

Versi yang paling lama berjalan dari "sistem yang sudah ada" berjalan di mainframe. Puluhan tahun COBOL dan PL/I, jutaan baris kode, puluhan ribu program yang terhubung lewat Db2, CICS, IMS, dan batch scheduler — kode yang terus menjalankan bisnis tanpa gangguan yang tidak mampu mereka tanggung.

Hari ini kami membuat IBM Bob Premium Package for Z (Bob PP4Z) tersedia secara umum. Produk ini menggantikan IBM watsonx Code Assistant for Z dan membawa keahlian IBM Z — bahasa platform, pemahaman middleware, dan analisis enterprise-wide yang deterministik — langsung ke dalam pengalaman Bob.

Ini adalah cerita engineering, bukan tur fitur. Alih-alih mencantumkan semua yang dilakukan PP4Z, kami ingin melakukan tiga hal:

  1. Menjelaskan mengapa model general-purpose lebih sering salah memahami aplikasi mainframe kamu daripada yang diakuinya.
  2. Menunjukkan bagaimana kami membumikan Bob pada fakta deterministik tentang estate milikmu, bukan probabilitas.
  3. Menelusuri mode, skill, dan workflow khusus Z — serta apa yang bisa kamu bangun dengannya.

1. Mengapa mainframe adalah kasus yang sulit

Model general-purpose yang diarahkan ke estate mainframe akan menemui tiga masalah yang tidak benar-benar bisa diperbaiki hanya dengan prompt yang cerdas. Desain PP4Z menyediakan solusi untuk masing-masing masalah ini.

1.1. Skala, dan dampaknya pada context window

Satu aplikasi bisnis bisa terdiri dari jutaan baris COBOL, puluhan ribu modul yang saling terhubung di COBOL, PL/I, dan assembler, serta ribuan batch job yang dirantai oleh enterprise scheduler. Bahkan irisan "kecil" berisi 200 program pun sudah berukuran ratusan ribu baris kode.

Itu tidak muat di context window, dan masalahnya bukan hanya ukuran window. Saat konteks membesar, performa model menurun (Chroma Research Context Rot Study, 2025) — jawaban menjadi tidak lengkap, tidak konsisten, atau sangat percaya diri padahal salah, sama seperti manusia yang tenggelam dalam information overload. Menarik masuk "file yang relevan" mengasumsikan kamu sudah tahu file mana yang relevan, padahal itulah hal yang sedang kamu coba cari sejak awal.

1.2. Makna yang tidak ada di dalam kode

Kode mainframe sangat padat secara semantik. Makna bisnis hidup di nama field dan puluhan tahun konvensi, bukan pada hal yang bisa dibaca parser. Sebagiannya bisa ditebak — SERIALN mungkin serial number, TOT-STTM mungkin total settlement. Sebagian besar tidak bisa: apa itu C-M? M-CAP? Mengapa ada prefix CCZD? Apa yang membedakan NO-SIN, NO-EVN, dan NO-CNT?

Makna itu nyata dan sangat menentukan, tetapi tidak bisa ditebak hanya dari kode. Jawaban tradisionalnya adalah data dictionary — tetapi skalanya (jutaan bahkan miliaran variabel) membuatnya terasa sangat berat untuk dibangun secara manual atau brute force dengan language model.

1.3. Jawaban yang paling mungkin bukan jawaban yang tepat

Language model mengembalikan apa yang secara statistik paling mungkin berdasarkan distribusi pelatihannya. Model bersifat non-deterministik; pertanyaan yang sama bisa mendapat jawaban berbeda di hari yang berbeda. Pada sistem di mana jawaban yang salah tentang control flow bisa salah menyatakan logika bisnis, ini adalah risiko yang signifikan.

Ini adalah situasi yang kemungkinan pernah kamu alami sendiri, jika kamu menyadarinya. Ambil contoh aplikasi batch COBOL nyata: 233 program, 742 copybook, 20+ MB kode, dengan utility tanggal yang sering dipanggil, N991DATE. Berdasarkan metadata, ground truth-nya adalah 30 program memanggil utility ini. Sekarang tanyakan langsung ke frontier model:

  • Hari 1. Model itu tidak bisa memuat semuanya, jadi ia melakukan grep untuk statement CALL statis dan melaporkan 13. Saat ditanya tentang dynamic call, ia memperluas regex dan melaporkan 29. Satu yang terlewat, CHKOUTB, ada di file bernama ROCHKOUT.cbl — karena berdasarkan konvensi nama file biasanya cocok dengan PROGRAM-ID, tetapi itu tidak pernah diwajibkan.
  • Hari 2. Pertanyaan yang sama, heuristik yang berbeda, dan sekarang ia melaporkan 31 — kelebihan hitung. Satu false positive, N285RODR, hanya mendeklarasikan literal 'N991DATE' di working storage dan tidak pernah menggunakannya. Model baru menyimpulkan itu setelah beberapa pertanyaan lanjutan.

Tidak ada heuristik ini yang tidak masuk akal. Hanya saja, semuanya tidak cukup baik, dan "siapa yang memanggil X" adalah salah satu pertanyaan inti saat impact analysis dan pemahaman program. Pertanyaan yang lebih maju yang diajukan developer untuk memahami program dan dependency — tabel mana yang di-update di lebih dari satu program, file mana yang dibaca tetapi tidak pernah ditulis, variabel mana yang menjadi input perhitungan WS-UIT02 di PREMPZ72 — membutuhkan analisis yang lengkap dan presisi, sesuatu yang tidak bisa diberikan pattern-matching.

Kesimpulannya bukan "model tidak berguna untuk memahami program mainframe." Kesimpulannya adalah kualitas respons model meningkat secara signifikan ketika ada sesuatu yang benar untuk dijadikan dasar penalaran. Language model unggul dalam memproses data.

2. Membumikan Bob pada fakta, bukan probabilitas

Jawaban PP4Z adalah berhenti meminta model merekonstruksi sistem dari source code, dan sebagai gantinya memberinya representasi estate yang deterministik dan bisa di-query untuk dijadikan dasar berpikir. Ada tiga mekanisme pembumian: model diprompt untuk menandai construct z/OS yang ambigu di dalam permintaan itu sendiri; prompt diperkaya dengan insight IBM Z yang otoritatif, dokumentasi IBM, materi referensi, sampel terverifikasi, dan lainnya, sambil secara aktif menekan bias pemrograman general-purpose agar fokus tetap pada platform target; dan model diinstruksikan untuk menjawab dengan metadata analisis terlebih dahulu. Tujuannya adalah membuat jawaban bisa dilacak ke sistem IBM Z, bukan ke distribusi pelatihan.

2.1. Z Understand: model estate kamu yang bisa di-query

Z Understand adalah platform static analysis di bawah PP4Z. Platform ini berjalan di server yang punya akses ke seluruh source kamu, menyediakan scanner untuk COBOL, PL/I, dan assembler serta JCL dan scheduler seperti Control-M dan TWS, lalu memproses ribuan program secara paralel menjadi satu repository yang bisa di-query. Platform ini menyimpan struktur yang deterministik dan konsisten untuk estate berisi 10.000+ program.

Bayangkan ini sebagai compiler pipeline dengan output yang berbeda: bukan executable, melainkan pengetahuan terstruktur yang bisa di-query — definisi data, control flow lintas program dan job, data flow yang presisi (termasuk REDEFINES dan memory offset), serta interaksi subsystem.

2.2. Biarkan model menulis query-nya sendiri

Cara metadata diekspos sama pentingnya dengan metadata itu sendiri. API tetap dan pola query MCP yang sudah ditentukan sangat efisien untuk pertanyaan yang sudah dikenal dan diperkirakan, tetapi akan runtuh pada analisis yang open-ended. Dalam analisis open-ended, satu pertanyaan nyata menyebar menjadi banyak sub-query yang berubah seiring penalaran berlangsung.

Karena itu kami mengajarkan Bob untuk melampaui query siap pakai yang disediakan dan menghasilkan serta menjalankan query-nya sendiri terhadap metadata. Ini memanfaatkan apa yang memang dikuasai model — penalaran dan pembangkitan query — dan skalanya mengikuti cara data terstruktur berskala: apakah kamu punya 10 program atau 10.000, query-nya tetap sama; hanya himpunan hasilnya yang bertambah. Dalam praktiknya, ini berarti akurasi lebih tinggi, konsistensi lebih baik antar run, dan konsumsi token lebih rendah, karena Bob bernalar di atas relationship dan type dan hanya menarik snippet presisi yang ditunjuk metadata.

2.3. Ekstensibilitas, custom scanner, dan data runtime

Analisis sintaks murni melewatkan relationship yang penting ketika dynamic call, abstraksi API, dan preprocessor menyembunyikan alur sebenarnya. Framework Z Understand Extensibility menutup celah itu:

  • API call / macro resolution memetakan panggilan tidak langsung dan yang didorong parameter ke target sebenarnya, menggantikan edge pemanggilan generik dengan relationship caller–callee yang konkret, lewat konfigurasi JSON atau user exit.
  • Preprocessor extensibility menafsirkan statement non-standar sambil tetap mempertahankan tampilan source asli, dengan pemetaan yang rapi antara kode sebelum dan sesudah preprocessing.
  • Custom scanners membawa bahasa proprietary, 4GL, bahkan sumber non-kode ke dalam satu model melalui interface JSON berbasis schema — kamu menangani parsing dan extraction, Z Understand menangani storage, relationship, dan analysis.

Analisis statis memberi tahu kamu apa yang bisa terjadi; data runtime memberi tahu kamu apa yang memang terjadi. PP4Z mengubah debugger menjadi instrumen pengumpulan data — melacak jalur eksekusi, menangkap nilai variabel, mengamati keputusan percabangan dan panggilan subsystem — lalu memberikan jejak presisi itu ke Bob untuk jenis perbaikan kompleks yang tidak bisa didukung input statis saja.

2.4. Data dictionary: relevansi di atas kelengkapan

Mendokumentasikan miliaran variabel bukan hal yang realistis ataupun mudah dirawat, jadi PP4Z tidak mencoba melakukannya. Analisis deterministik memberi peringkat variabel berdasarkan seberapa besar pengaruhnya terhadap perilaku — frekuensi penggunaan, sebaran lintas region kode, partisipasi dalam control flow, interaksi dengan database dan I/O — lalu memilih himpunan kecil yang benar-benar mengungkap tujuan sebuah program. Untuk setiap variabel itu, sistem menyusun metadata, snippet penggunaan nyata, dan pola interaksi, lalu menghasilkan deskripsi di level bisnis.

Temuan penting di sini: cakupan terbatas sudah cukup. Mendefinisikan kira-kira 10-20 variabel teratas per program secara material meningkatkan pemahaman tanpa perlu dokumentasi menyeluruh. Z Understand Services mengotomatiskan ini di seluruh portfolio dari CLI, skor confidence memastikan hanya definisi di atas threshold yang dipertahankan, dan langkah human-in-the-loop di IDE memungkinkan developer meninjau, mengoreksi, dan menyelaraskan output dengan glosarium yang sudah ada.

3. Mengkhususkan Bob untuk Z

Pembumian memberi Bob fakta yang baik. Spesialisasi yang membuat perilakunya bisa diprediksi di lingkungan di mana output harus dapat dijelaskan dan proses harus memenuhi governance. PP4Z dibangun di atas empat komponen: modes, tools, skills, dan workflows.

  • Modes menetapkan peran dan batasan untuk alur interaksi. Mode bergaya arsitek memprioritaskan analisis, dokumentasi, dan penemuan dependency, dengan modifikasi kode secara eksplisit tidak diizinkan — jadi eksplorasi tidak diam-diam berubah menjadi perubahan. Mode developer di-tune untuk generation dan refactoring dengan penegakan coding standard yang sudah built-in. Governance hidup di model interaksinya sendiri.
  • Tools memberi model akses langsung ke pengetahuan sistem yang terstruktur — pemindaian program, interrogasi metadata, lookup data dictionary, layanan analisis enterprise-wide — sehingga model meng-query fakta yang sudah dihitung sebelumnya alih-alih menyimpulkan dari source mentah.
  • Skills mengodifikasi keahlian yang berulang menjadi langkah yang bisa diulang dan diaudit, diterapkan tepat saat dibutuhkan tanpa menggelembungkan konteks. Skill implementation-planning, misalnya, menegakkan urutan tetap: ambil dan validasi konteks, rangkai requirement dan munculkan asumsi, petakan impact dari metadata, lalu hasilkan rencana yang disimpan dan bisa ditinjau. Bob tidak mengimprovisasi urutannya.
  • Workflows menambahkan orkestrasi yang stateful — menegakkan urutan, memvalidasi hasil perantara, menghentikan proses ketika input buruk. Workflow data dictionary berhenti jika tidak menemukan variabel alih-alih mengarangnya. Tidak ada kegagalan senyap, tidak ada langkah yang dilewati.

Standar dan governance ditegakkan secara default melalui rule agents.md di level repository — tanpa infrastruktur tambahan. Dan karena IBM mengirimkan skill serta workflow ini langsung dalam produk, kamu tidak memulai dari kertas kosong: semuanya mengenkode pendekatan IBM sendiri terhadap COBOL, PL/I, middleware z/OS, dan modernisasi. Skill coding-standards bisa mempelajari konvensimu langsung dari codebase atau menyerap dokumen standar yang sudah ada lalu mengubahnya menjadi skill penegakan yang diterapkan pada setiap interaksi penghasil kode. Kamu juga bisa menulis skill milikmu sendiri tanpa menulis kode.

Ketika semuanya berpadu, satu prompt bisa mendorong tugas end-to-end:

"Tambahkan kolom ke Motor Policy Table yang merekam apakah kendaraan itu listrik. Terapkan coding standard saya dan perbarui semua program yang terdampak."

Bob membaca niatnya, membangun rencana, memilih mode, skill, dan rule repository yang tepat, lalu dengan aman menjalankan tool yang dibutuhkan untuk menganalisis program, mengekstrak variabel, memperbarui definisi data, dan menghasilkan hasil yang patuh — governance, eksekusi, dan penalaran dalam satu alur, dengan kamu tetap menyetujui perubahannya.

4. Apa yang bisa kamu bangun hari ini

  • Dokumentasi yang tidak menyimpang dari kenyataan. Perlakukan dokumentasi sebagai artefak yang dihasilkan dari metadata deterministik plus source dan konteks runtime — bisa dihasilkan ulang sesuai kebutuhan, selaras dengan sistem saat ini, bukan snapshot dari tiga tahun lalu.
  • Transisi COBOL-ke-Java yang deterministik di z/OS. Rewrite gagal saat kesetaraan fungsional diperlakukan sebagai sesuatu yang mendekati; kalkulasi hipotek harus menghasilkan angka yang sama meskipun ada perbedaan dalam pembulatan dan semantik runtime COBOL. PP4Z memakai metadata sebagai tulang punggung transformasi, membangun model paralel dari source dan target agar arsitektur bisa direproduksi, logika bisnis dipetakan secara presisi alih-alih diringkas, dan validasi menjadi hal utama — menghasilkan test case dari perilaku source untuk membuktikan kesetaraan.
  • Refactoring terarah dan function extraction. Bob menghasilkan daftar kandidat refactoring yang diberi peringkat dan diberi anotasi fungsi bisnis, lalu mengekstrak modul-modul mandiri dengan input dan output yang jelas, traceability ke sumber asli, dan saran integrasi — sambil menjaga investasi COBOL kamu tetap utuh.
  • Tooling z/OS native. Kemampuan Z Open Editor berlisensi plus tool MCP baru: Dependency Based Build (DBB) untuk menjalankan build di z/OS dari IDE, Z Code Scan untuk quality check berbasis rule dan perbaikan di dalam workflow Bob, serta IBM Debug for z/OS untuk mengubah sesi debug langsung menjadi root-cause analysis berbantuan AI.

Sedikit catatan kejujuran, karena ini post engineering: semua ini tidak mengeluarkan developer dari loop, dan memang tidak dimaksudkan begitu. Mode, approval gate, dan human-in-the-loop data dictionary semuanya ada karena pada sistem seperti ini, "sebagian besar benar" adalah mode kegagalan, bukan tujuan.

5. Cara mendapatkan akses

Bob Premium Package for Z (PP4Z) adalah add-on untuk IBM Bob, bukan produk terpisah yang perlu kamu unduh. PP4Z berjalan terhadap estate mainframe yang hidup di dalam lingkungan enterprise, jadi tidak ada self-serve checkout — entitlement-nya dipandu oleh tim sales.

  • Mulailah dengan perwakilan IBM kamu, atau gunakan Contact Sales di bob.ibm.com. Mereka akan menyiapkan base plan IBM Bob dan add-on Z untuk organisasimu.
  • Setelah administrator Bob kamu memberikan seat dengan add-on Z, entitlement itu akan terdeteksi saat kamu menggunakan IBM Bob. Install Bob IDE, sign in, dan mode, skill, serta tool khusus Z akan muncul.

6. Memulai

  1. Jika kamu sudah menjalankan Bob, PP4Z menambahkan mode, skill, dan tool khusus Z di atas apa yang sudah kamu punya.
  2. Gunakan kemampuan embedded understand untuk mendapatkan insight yang lebih dalam ke kode di workspace kamu.
  3. Arahkan Z Understand ke aplikasi nyata yang bisa jauh melampaui workspace kamu — tempat kamu sudah tahu jawaban yang benar — lalu cek analisis Bob terhadap ground truth itu.
  4. Mulailah dengan pertanyaan yang belum pernah kamu dapat jawaban tegasnya: siapa yang benar-benar memanggil utility ini, tabel mana yang disentuh job ini, apa arti variabel ini?
  5. Ajukan pertanyaan yang lebih menantang yang mencampur data dan penalaran: "Beri saya call graph dengan diagram yang diorganisasi berdasarkan topik"

Links