OS Mainframe

20 Jan 2011 OS Mainframe

Native OS untuk Mainframe System z (z/Series) yang paling populer adalah z/OS, z/VM, z/VSE, z/TPF dan z/Linux. Empat yang pertama adalah bikinan IBM, pemilik dan pencipta arsitektur mainframe (MF) sejak System/360 pada tahun 1960an hingga System z yang sekarang ini. Sedangkan z/Linux adalah GPL seperti Linux yang lain.

z/OS

z/OS adalah OS MF yang hampir 100% mengimplementasikan kemampuan arsitektur MF. Setiap komponen fungsi z/OS didukung oleh teknologi hardware MF (tidak ada simulasi yang murni software), dan semua fungsi dan fitur hardware terimplementasikan dalam z/OS kecuali VMAssist, CPAssist dan PR/SM yang memang disediakan untuk z/VM. Misalnya komponen fungsi yang dinamakan dynamic address translation (DAT). Fungsi DAT adalah untuk mentranslasi virtual memory ke real memory. Tetapi berbeda dengan yang ada pada processor non-MF yang umumnya hanya translasi linier page (virtual) to frame (real) saja. Catatan: Non-MF juga ada yang berjenjang, tapi umumnya jenjang atasnya prefixing untuk virtualisasi mesin (seperti fitur VMX pada Intel). DAT melakukannya secara berjenjang mulai dari page (4KB) melalui page table (PT), segment (1MB) melalui segment table (ST), dan address space (full memory space tergantung addressing modenya) melalui address space table (AST). Semua ini kerjaan hardware, artinya setiap ada instruksi yang mengakses virtual memory, otomatis DAT melakukan translasi mengacu pada translation lookaside buffer (TLB) berjenjang PT, ST dan AST serempak. Jika ternyata di 3 tabel buffer tsb tidak ada, tentu instruksi tersebut mengalami page fault atau “kejeglong” ibarat “terban tanah tempat berpijak”, dan tentu page fault handler segera melakukan page-in atau swap-in (tergantung keperluan) dari auxiliary storage (expaned storage atau disk), maka otomatis DAT mengupdate PT, ST dan AST serempak sesuai penempatan page atau segment yang barusan dihadirkan. Semua ini dilakukan oleh hardware. OS atau Software cukup mengexekusi satu instruksi PAGE-IN (hex ‘B22E’) dan (bila perlu) PAGE-OUT (hex ‘B22F’). Mekansime ini diimplementasikan total oleh z/OS dalam komponen induk yang dikenal dengan nama multiple virtual storage (MVS). MVS dulunya dipakai sebagai nama OS sebelum generasi System z.

Address space merupakan ruang kerja untuk satu job, berisi program dan data. Setiap job berada dalam satu address space, seperti memiliki memori sendiri, menguasainya dari address 0 hingga maximum virtual address, tidak berbagi dengan job lain. Namun, pada saat diperlukan, suatu job bisa mengakses address space milik job lain. Dalam situasi ini address space milik sendiri berperan sebagai primary address space dan address space milik job lain yang sedang diakses berperan sebagai secondary address space. MF hanya menyediakan instruksi untuk menyalin data dari primary address space ke secondary address space dan sebaliknya. Semua manipulasi harus dilakukan di primary address space. Operasi semacam ini dinamakan cross memory.

Address space ada yang fungsinya khusus untuk mewadahi data, disebut dataspace. Dataspace bersifat opsi tergantung keperluan. Job yang memerlukan dataspace bisa membangkitkan satu atau lebih dataspace. Dataspace juga merupakan sebuah lembar memori virtual yang utuh, dari address 0 hingga maximum. Aksesnya menggunakan extended addressing yang melibatkan access register dan seluruh instruksi terkait. Tidak memerlukan privilege khusus, sehingga setiap job boleh memiliki dataspace. Selain itu, dataspace bisa di-share oleh sejumlah job. Gambar berikut ini menayangkan contoh aplikasi dataspace. Program PGM1 dan PGM2 jalan sebagai job JOB1 dan JOB2 di address space masing-masing. PGM1 mengakses data DATA1 lokal di address space sendiri, data DATA4 di dataspace berbagi dengan PGM2 dan data DATA2 di address space JOB2. PGM1 dan PGM2 bisa memanipulasi DATA4 langsung di tempat menggunakan sarana extended addressing. Tetapi PGM1 tidak bisa melakukan hal yang sama dengan data DATA2 milik JOB2. Yang bisa mengolah DATA2 di tempat hanya PGM2, karena lokal. PGM1 hanya bisa menyalin ke address space JOB1 dan mengolahnya lokal, kemudian menyalin hasilnya ke DATA2 di address space JOB2.

Contoh lain misalnya linkage stack (LX) dan program-call (PC). LX untuk melakukan state stacking saat exekusi harus beralih dari satu modul program ke modul lain. Yang di-stack bukan sekedar isi register saja, tetapi seluruh state operasi, termasuk proteksi, addressing mode, privilege dan sebagainya. Sedangkan PC adalah sarana untuk beralih exekusi secara sinkron antar program antar address space. Masih banyak contoh lain implementasi komponen fungsi dan fitur hardware dalam z/OS, kalo ditulis semua bisa jadi buku di blog 🙂 Semua bisa kita coba apa adanya dalam systems programming untuk z/OS tanpa simulasi apapun. Software hanya menyiapkan argumen di memori sesuai dengan aturan main instruksi yang akan diexekusi.

Akibat mengimplementasikan total fitur-fitur z/Series, maka z/OS menjadi sebuah OS yang paling handal bagi MF dalam menggendong aplikasi “mission-critical” yang merupakan esensi MF itu sendiri. Kehandalannya tak tertandingi dalam operasi batch atau background execution mirip daemon di jagad Unix. Semua daemon dikoordinasi sangat rapi dalam sebuah subsystem (pengertiannya = sub-kernel) utama yang disebut JES (job entry subsystem) dan dilengkapi dengan alat pemantau dan pengendali yang lengkap dan cukup akurat, SDSF. Untuk operasi online kelihatannya tak jauh beda dengan non-MF asal dengan power yang sebanding. Tetapi khusus untuk online yang bersifat streaming tentu z/OS on z/Series termasuk paling jago setelah z/TPF.

z/OS memiliki kemampuan yang paling sempurna dalam mendukung aplikasi informatika. Tidak ada aplikasi yang tidak didukung oleh z/OS, mulai dari legacy yang tertua sekalipun hingga aplikasi yang paling modern. Seluruh aplikasi open system dan open source juga didukung oleh z/OS. Sehingga secara keseluruhan, z/OS merupakan OS primadona untuk sistem komputer MF. Harganya pun paling “semelet” (baca: panas), bahkan bisa jadi OS termahal di planet ini. Maka dari itu, kalo bukan karena keharusan mission-critical compliant seperti bank dan pemerintahan, mungkin perlu ditimbang ulang 10 kali untuk menggunakan z/OS. Mission-critical pun kalo kadarnya nggak sekritis bank atau pemerintahan, saya rasa cukup divirtualisasi dengan z/VM.

Meskipun mendukung segala jenis aplikasi, namun yang paling esensial untuk z/OS adalah CICS dan DB2. CICS adalah middleware khusus untuk memuat segala jenis apllikasi transaksi online, khususnya yg bersifat streamming. Medianya bisa networking seperti SNA maupun TCP/IP, bisa juga non-networking seperti BSC atau protokol khusus seperti ISC, CTC dll. Database-nya bisa menggunakan VSAM (database paling sederhana), DB2 maupun database system yang lain (IMS, IDMS, Oracle, CA-Datacom dll). Model transaksinya bisa langsung dengan dumb terminal, bisa client/server umum (SNA APPC maupun TCP/IP socket), dan bisa juga client/server khusus seperti dengan teller machine IBM 4700 maupun ATM. Namun karena CICS itu middleware, maka model-model transaksi tersebut tidak seberapa berbeda bagi programmer. Yang agak berbeda hanya untuk transaksi dumb terminal, dimana programmer harus menyiapkan panel layarnya mengikuti aturan IBM 3270 datastream.

Sedangkan DB2 adalah database system yang di dalamnya termasuk database engine dan segala kelengkapannya. DB2 termasuk RDBMS seperti Oracle, mendukung hampir semua platform komputer. Interaksinya dengan SQL seperti pada umumnya RDBMS. DB2 dilengkapi UDB untuk mengakses database MF dari platform apa saja.

Untuk melakukan administrasi (sysadmin) dan troubleshooting (support), kita harus masuk ke z/OS langsung melalui komponen yang dinamakan TSO. Aksesnya bisa lewat dumb terminal maupun telnet 3270 dari komputer PC melalui emulator 3270. TSO tidak menyediakan GUI. Tetapi karena TSO dilengkapi dengan ISPF, maka yang kita hadapi adalah panel-panel full screen, colorful dan windowing yang berisi menu untuk memudahkan pekerjaan. Gambar sebelah menayangkan panel utama ISPF yang kita jumpai pertama kali saat logon TSO di sistem fandezhi.efglobe.com. Saya tidak tahu sistem milik siapa fandezhi tersebut, tetapi kita boleh minta akun dan logon kesana. Untuk logon ke sistem tersebut, gunakan telnet 3270 ke fandezhi.efglobe.com lewat port 23.

ISPF juga menyediakan sarana GUI jika diakses secara client/server dari komputer PC yang berGUI. ISPF-GUI sebenarnya nggak enak dipakai, karena tetap bersetruktur kaku persis seperti ISPF non-GUI, dan tetap membutuhkan emulator 3270. Saya sebenarnya sedang membangun HTTP server khusus untuk mengganti peran TSO dengan browser biasa agar lebih luwes. Sejak awal 2010 pembangunannya sudah mencapai 40%. Tapi lantas mandeg karena muncul keraguan jangan-jangan nggak laku.

Untuk operasi batch dan pengendalian utama, disediakan console yang kurang ramah. Tapi ya lumrah wong namanya server kan tidak terlalu memperhatikan penampilan. Console tidak scrollable. Tetapi jika TSO diaktifkan, kita bisa melakukan hal yang sama melalui SDSF, scrollable dan lebih ramah dari console. Gambar sebelah adalah SDSF pada sistem fandezhi.efglobe.com, sedang menampilkan daftar seluruh job yang sedang aktif. Sejumlah console command bisa dijalankan lewat panel SDSF, tergantung tingkat otoritas userid yang kita gunakan. Untuk tingkat otoritas operator atau technical support, semua command boleh dijalankan lewat SDSF. Console juga bisa diakses lewat telnet 3270 dari komputer PC melalui emulator 3270

Sejak z/OS 1.12, IBM menyediakan sarana akses melalui web browser di PC bagi system administrator. Sarana tersebut dinamakan zOSMF. Penampakannya bisa disimak disini. Penyediaan zOSMF bukan diperuntukkan bagi sysadmin yang belum tahu TSO. Karena sysadmin harus sudah lihai benar dengan TSO maupun ISPF. zOSMF hanyalah untuk mempermudah manakala sysadmin harus melakukan sesuatu dari lingkungan yang tidak menyediakan sarana telnet 2370. Misalnya sysadmin sedang berada di luar, tidak membawa notebook dan mendadak harus melakukan sesuatu, mungkin karena darurat. Tanpa zOSMF, sysadmin harus segera mengambil notebook di rumah atau di kantor, yang tentunya makan waktu. Dengan zOSMF, sysadmin cukup mampir ke warnet dan melakukan pekerjaannya dari warnet.

Bagi para application developer, disediakan beberapa pilihan. (1) Bisa membangun program langsung di perut z/OS melalui TSO dan ISPF seperti sysadmin dan support, baik lewat dumb terminal maupun telnet 3270 dari komputer PC melalui emulator 3270. Syaratnya harus terampil menggunakan TSO dan ISPF.

(2) Bagi yang tidak mengenal TSO/ISPF tapi terampil bermain Unix atau Linux, bisa membangun program langsung di perut z/OS melalui USS (Unix) baik lewat dumb terminal maupun telnet biasa dari komputer PC apa saja. Namun cara ini hanya berlaku jika data yang diakses berada dalam file yang menganut HFS. USS juga bisa menggunakan panel-panel ISPF untuk menghindari perintah-perintah Unix yang kurang manusiawi. Tetapi syaratnya harus lewat telnet 3270 dari komputer PC melalui emulator 3270. Gambar sebelah menayangkan penampilan USS tanpa ISPF yang diakses lewat telnet 3270. Sedangkan gambar di bawahnya menayangkan penampilan USS menggunakan ISPF yang diakses melalui telnet 3270. Bisa memanfaatkan kelebihan ISPF, termasuk layar ganda, mengingat command (semacam cookies) dan model maupun strukturnya bisa dirancang sendiri. Tentu jauh lebih ramah dan manusiawi ketimbang USS bergaya Unix telanjang.

(3) Bagi yang tidak mau menggunakan TSO maupun USS, bisa saja tetap di komputer apa saja selama memiliki koneksi dengan JES, baik melalui network job entry (NJE) maupun remote job entry (RJE). Koneksi NJE bisa melalui SNA maupun TCP/IP. Sedangkan RJE hanya SNA. Namun cara ini tidak bisa mengkompilasi program secara interaktif seperti USS. Jadi tetap saja harus menguasai job control language JCL, sebuah script mirip BAT file di DOS tetapi bergaya macro assembler. Maklum JCL hadir sejak generasi S/360 tahun 60an.

Dalam operasinya, z/OS menyediakan 3 cara untuk mengexekusi program. Pertama adalah sebagai job. Ada 4 macam job, yaitu initiated job yang dalam terminolog z/OS ditulis sebagai JOB, started task atau STC, time sharing user atau TSU dan open MVS user atau OMVS. Baik JOB, STC maupun TSU harus dikawal dengan berbagai definisi yang dituliskan dengan JCL untuk menunjuk modul yang akan diexekusi, data yang akan diakses dll. Sedangkan OMVS ikut aturan Unix. Yang kedua adalah sebagai command processor dan yang ketiga sebagai subsystem.

STC adalah program yang jalan dipicu dengan command START dan JCL-nya harus berada di dataset yang didefinisikan sebagai procedure library (PROCLIB). Program selanjutnya aktif sebagai system task dalam sebuah address space terpisah. Pada saat exekusi program berakhir, system task dan address space-nya dilenyapkan. STC memiliki nama dan boleh kembar dengan STC lain. Selama program yang jalan mentolerir untuk berduplikasi, maka satu program bisa di-START berduplikasi berapapun. JES tidak mengkoordinasi STC kecuali jika memerlukan spooling. Tetapi JES memberikan identitas unik STCnnnnn kepada setiap STC, sehingga meskipun terduplikasi, kita bisa membedakanm melalui identitas tersebut.

JOB adalah program yang jalan dipicu oleh STC “khusus” yang berfungsi sebagai initiator (INIT). Nama STC tersebut memang INIT. INIT adalah anakbuah JES yang berfungsi mengkordinasi JOB. Mula-mula sejumlah INIT di-START oleh JES untuk mengaktifkan system task yang tugasnya menerima dan melakukan perintah JES serta menginformasikan status operasi kepada JES. Jika ada JCL masuk ke spool reader khusus yang dinamakan internal reader, JES akan menginterpretasikan JCL tersebut. Jika ditemukan indikator yang menyatakan JCL tersebut JOB, maka JES akan memerintakan salah satu INIT untuk mengalokasi data sesuai yang didefinisikan JCL dan mengexekusi program-nya sebagai subtask utama serta mengganti nama INIT dengan nama JOB sesuai dengan yang tertera di JCL. JES juga memberikan identitas unik JOBnnnnn. JOB dikoordinasi ketat oleh JES sehingga jika ada nama terduplikat, satu jalan dan yang lain menunggu. Pada saat exekusi JOB berakhir, maka job kembali menjadi INIT. Subtask diputus dan dilenyapkan, tetapi system task semula tetap aktif dan address space-nya tetap dipertahankan untuk JOB berikutnya.

TSU adalah program yang jalan dipicu oleh command LOGON ke terminal control yang jalan sebagai STC. Biasanya nama STC tersebut TCAS atau TSO dan jalan sebagai aplikasi VTAM (pengendali SNA networking). TCAS kemudian mencari definisi userid yang ditunjuk oleh command LOGON untuk mendapatkan nama logon procedure dan meminta VTAM untuk menyelenggarakan session dengan terminal dimana command LOGON dilakukan. TCAS lantas melakukan hal yang sama dengan command START, yaitu menggelar address space, melacak logon procedure di PROCLIB dan menginterpretasikannya dan menjalankan program yang tertera di JCL. Karena program tersebut adalah TSO yang memang sudah dirancang khusus berinteraksi dengan terminal, maka langsung terjalin interaksi melalui sesi yang sudah terselenggara tersebut. JES tidak mengkoordinasi TSU kecuali jika memerlukan spooling. Tetapi JES memberikan identitas unik TSUnnnnn kepada setiap TSU untuk memudahkan pelayanan spooling. Pada saat command LOGOFF dipasok, system task dan address space-nya dilenyapkan.

OMVS adalah program yang jalan dipicu oleh command LOGON ke Unix system service (USS) yang jalan sebagai STC dengan nama OMVS, melalui telnet. Meskipun dalam z/OS, USS berupa STC, namun di dalamnya adalah Unix kernel. Oleh karenanya aturan mainnya sama persis dengan Unix pada umumnya. Namun pada saat kita menjalankan program di background, maka daemon yang terbentuk akan diexekusi oleh z/OS sebagai STC. Logon ke USS juga bisa melalui TSO dari dalam TSU.

Command processor adalah program yang jalan dipicu oleh command tertentu melalui sarana interaktif (selain console subsystem), misalnya TSO shell, USS shell dll termasuk aplikasi taylor made dan subsystem. Command processor tidak dikawal JCL. Sehingga semua definisi yang diperlukan (jika ada) harus dimasukkan melalui argumen.

Subsystem adalah program yang jalan sebagai bagian dari nucleus atau kernel OS. Begitu terdefinisi, maka otomatis langsung aktif kecuali sengaja dibikin nonaktif. Program subsystem adalah system program untuk melakukan fungsi-fungsi tertentu yang tidak disediakan oleh OS. Kita tidak dianjurkan membuat sendiri subsystem kecuali tidak ada jalan lain dan harus tahu betul resikonya. Sekali terdefinisi, tidak bisa dihapus lagi, hanya bisa dinonaktifkan. Karena menjadi bagian dari OS, subsystem jalannya tidak seperti job maupun command processor dan tidak memiliki address space sendiri, melainkan numpang di MSTR (system task utama OS). Program yang dijalankan sebagai subsystem harus bersifat event driven dan selalu standby hanya untuk merespon system event. Banyak batasan-batasan lain yang harus diperhatikan.

Dalam mendukung operasi dan aplikasi mission-critical, z/OS menyediakan berbagai sarana yang jarang dimiliki oleh OS lain. Untuk mendukung kepentingan proteksi antara lain authorized program facility (APF). Semua program yang dijalankan sebagai job, baik JOB, STC maupun TSU, ataupun command processor, pertama kali diexekusi selalu ditempatkan dalam user state atau problem state. Jika program tersebut harus memasuki privilege state atau supervisor state, misalnya akan mengexekusi instruksi-instruksi privilege, maka terlebuh dulu harus memanggil APF melalui interrupsi SVC (supervisor call MODESET. APF lantas memeriksa apakah program berasal dari library yang disahkan sebagai APF library dan memiliki tanda pada APF pada modulnya. Jika tidak maka permintaan ditolak dan exekusi program dihentikan taknormal dengan kode hex 047.

Untuk mendukung kinerja, z/OS menyediakan library lookaside (LLA), virtual lookaside facility (VLF) dan link pack area (LPA). LLA adalah alokasi memori khusus untuk menyimpan salinan catalog dan directory modul-modul program sesuai dengan execution path-nya. VLF adalah alokasi memori dataspace untuk menyimpan modul program yang pernah diexekusi, sehingga manakala diexekusi lagi, tidak perlu loading lagi dari library yang tentu adanya di disk melalui proses I/O. Sehingga VLF berfungsi mengurangi I/O untuk program yang sering diexekusi. Proses loading tetap ada tapi disimulasi dari memori ke memori.

Sedangkan LPA adalah untuk membuat modul program preloaded dan protected. LPA benar-benar menghindari proses I/O dan loading. Modul diexekusi ditempat. Sehingga jika ada beberapa job atau command processor memanggil modul yang sama, modul di-shared. Oleh karena itu modul-modul yang dipasang di LPA harus reentrant. Tentang reentrancy bisa disimak di artikel berjudul Systems Programming #2 (lanjutan).

z/VM

z/VM adalah OS yang khusus untuk memvirtualisasi MF. z/VM tidak mengimplementasikan semua kapabilitas MF, tetapi dia sepenuhnya menggunakan sarana virtualisasi yang disediakan hardware MF, seperti VMAssist, CPAssist dan PR/SM. VMAssist (atau dinamakan System Interpretive Execution, SIE) adalah komponen hardware (dan microcodes) untuk mensimulasi sejumlah instruksi kendali tertentu (seperti LPSW, SVC, LCTL, SSM dan timer) yang diexekusi dari virtual machine agar tidak berdampak ke real machine dan mensimulasi interrupsi untuk virtual machine baik berasal dari interupsi beneran maupun bohongan.

CPAssist adalah komponen hardware (dan microcodes) untuk menyelenggarakan interaksi antara virtual machine dengan host control program (HCP). CPAssist ada yang langsung “nemplok”, ada pula yang harus diexekusi sebagai instruksi. Yang langsung nemplok misalnya untuk virtual machine yang didefinisikan sebagai V=R atau V=F. HCP otomatis akan mengalokasikan real memory pada virtual machine dan mensimulasikan address-nya mulai dari 0, dan tidak menyentuhnya selama virtual machine tersebut aktif. Dalam hal ini guest OS bertanggungjawab untuk memvirtualisasikannya sendiri. Guest OS yang males melakukan paging sendiri bisa menyerahkan tugas tersebut kepada HCP dengan menghapus definisi V=R atau V=F. Sedangkan yang berupa instruksi (juga disebut hypervisor) berupa himpunan instruksi yang khusus untuk menembus HCP untuk mendapatkan layanan tertentu. Siapa saja boleh mengexekusi hypervisor selain HCP itu sendiri. Tetapi jika tidak ada HCP, misalnya jalan di real machine, maka tidak menghasilkan apapun alias “NO-OP”.

PR/SM adalah komponen hardware (dan microcodes) untuk menyelenggarakan Logical Partition (LPAR). Tanpa z/VM, hardware MF bisa dipartisi menjadi sejumlah partisi (tergantung tipe mesinnya) yang bisa diopersikan terpisah bagaikan virtual machine. Tetapi jika dengan z/VM, PR/SM bisa diberdayakan untuk membuat partisi lebih banyak lagi. Fungsi utama PR/SM adalah untuk membagi I/O channel secara fisik dan membagi memori melalui prefixing. Tanpa PR/SM, virtual machine hanya memiliki virtual I/O channel. CPAssist memang melakukan prefixing, tapi dalam jumlah terbatas. Selebihnya murni simulasi. Sedangkan dengan PR/SM, virtual machine boleh memiliki dedicated I/O channel. Kemampuan prefixing-nya pun meningkat, sehingga pada saat yang sama bisa menjalankan preferred virtual machine (dengan definisi V=R dan V=F) jauh lebih banyak.

Adanya VMAssist, CPAssist dan PR/SM menekan overhead virtualisasi z/VM menjadi nyaris nol. Penjelasan mengenai virtualisasi dengan z/VM dapat disimaak di artikel berjudul zEnterprise Cara Jitu Beternak Server.

Selain virtualisasi untuk keperluan hosting OS lain, z/VM juga dilengkapi sarana yang cukup memadahi untuk aplikasi native, yaitu CMS dan GCS. CMS (singkatan “Coversational Monitoring System”) adalah OS yang dirancang khusus hanya bisa dijalankan di virtual machine z/VM. Penampilannya interaktif dan pipeline seperti Unix atau Linux, tetapi perintah-perintahnya jauh lebih manusiawi dan sarana helpnya bersifat wizard. CMS tampil full screen, colorful dan windowing, bahkan lebih cantik ketimbang penampilan ISPF.

CMS dilengkapi development tools paling canggih untuk seluruh OS MF. Filing dan editor sangat canggih. Script orisinilnya adalah sebuah bahasa komputer terstruktur yang lengkap yang dinamakan Rexx. Bisa digunakan untuk menyusun prosedur sederhana seperti BAT pada MS DOS. Bisa juga digunakan untuk membangun aplikasai yang serius. Bahkan rexx kadang juga bisa digunakan untuk systems programming sederhana. Kini rexx sudah ada di z/OS, z/VSE bahkan di luar MF. Tapi dulu rexx lahir di CMS.

Selain sebagai development system, CMS juga banyak digunakan untuk produksi, terutama untuk aplikasi yang bersifat interaktif seperti aplikasi Unix atau Linux. Bahkan sejumlah DBMS seperti Oracle, Focus, Supra, SQL/DS dll lahir di CMS duluan sebelum di sistem lain. CMS juga menyediakan email dan spreadhseet sejak awal 1980an, jauh sebelum ada email dan spreadhseet Windows dan keluarga Unix.

GCS (singkatan “Group Control System”) adalah OS yang dirancang khusus hanya bisa dijalankan di virtual machine z/VM seperti CMS. Bedanya, GCS tidak menyediakan development tools yang lengkap seperti CMS. Fungsi GCS adalah untuk mengaktifkan sarana-sarana z/OS MVS untuk mendukung z/VM khususnya CMS. Yang terpenting adalah untuk menyelenggarakan networking berbasis SNA. Karena IBM tidak membikinkan SNA services khusus untuk z/VM, melainkan mengadopdi dari z/OS (MVS), sehingga harus disediakan semacam MVS emulator yang kemudian dinamai GCS.

Selain OS “anak kandung” (CMS dan GCS), z/VM juga menyediakan sarana interaksi antar virtual machine yaitu VMCF (virtual machine communication facility) dan IUCV (inter-user communication vehicle). VMCF untuk interaksi sederhana sedangkan IUCV mirip banget dengan IP socket dan memang aplikasinya mayoritas untuk mensimulasi TCP/IP. Oleh karena itu IP socket antar program dalam satu host MF tidak memerlukan TCP/IP stack.

z/VM juga menyediakan sarana yang disebut Discontigous Shared Sagment (DCSS) dan Named Saved System (NSS). DCSS berfungsi untuk menyimpan data atau program di memori yang otomatis di-shared oleh seluruh virtual machine. Mirip dengan LPA pada z/OS. Tentu terproteksi sehingga hanya untuk keperluan read only. Untuk program tentu harus reentrant. Tentang reentrancy bisa disimak di artikel berjudul Systems Programming #2 (lanjutan).

Sedangkan NSS adalah DCSS yang berfungsi khusus untuk menyimpan OS atau bootable program apapun agar bisa di-boot oleh oleh semua virtual machine tanpa menimbulkan efek I/O karena semua sudah di memori. Karena bahan dasarnya adalah DCSS yang terproteksi, maka hanya modul-modul OS yang reentrant saja yang boleh dimuat dalam NSS. Boot-nya pun tidak menunjuk device sebagaimana umumnya, cukup menunjuk nama dari NSS tersebut, misalnya “CMS”, “GCS”, “VSE” dsb.

Menyelenggarakan preloaded program/data baik dengan DCSS maupun NSS menuntut agar memori virtual machine tidak diutak-atik. Artinya dari sisi virtual machine, memori harus dibiarkan seolah real. Jadi guest OS yang menyelenggarakan virtualisasi memori sendiri tentu tidak bisa melihat DCSS maupun NSS. Virtual machine dengan V=R dan V=F juga tidak bisa melihat DCSS dan NSS karena alokasi memorinya benar-benar partisi terpisah.

CMS dan GCS jelas bisa dipasang di NSS dan bisa mengakses DCSS karena tidak melakukan virtualisasi memori sendiri. OS lain yang bisa dipasang di NSS antara lain z/VSE dan AIX/370 jika dijalankan dengan “VM mode”.

z/VM jauh lebih murah dari z/OS. Kemampuannya menangani batch memang kalah di bawah z/OS, tetapi untuk menangani online tidak kalah dalam kinerja, bahkan memiliki kelebihan dalam kemudahan. Dulu di awal dekade 90an sempat IBM meluncurkan CICS/VM untuk produksi dan CICS/CMS untuk pengembangan. Kontan saja heboh orang boyongan ke VM/ESA (nama z/VM ketika itu). IBM malah ketakutan dan akhirnya CICS/VM dan CICS/CMS dihetikan peredarannya. Andaikata tidak dihentikan, mungkin pendapatan IBM menurun sesaat, tetapi pengguna MF makin banyak.

z/VSE

z/VSE dulunya adalah DOS/VSE kemudian VSE/SP, adalah OS untuk supermini IBM 43xx. Saya kurang tahu banyak versi z/VSE saat ini. Tetapi saat masih VSE/SP sangat sederhana dan bukan untuk MF yang sebenarnya karena tidak mendukung parallel I/O. Untuk jalan di MF, harus dalam virtual machine. Sangat mirip dengan OS/400 hanya memiliki kelebihan VSE didukung dengan CICS untuk melayani transaksi online “deras” berskala lebih besar dari OS/400.

z/TPF

z/TPF sebenarnya adalah stand-alone program khusus untuk reservasi online yang sangat mission-critical. Arti stand-alone program adalah program yang tidak memerlukan OS untuk jalan. Sehingga untuk memulainya harus melalui bootstrap dan sepanjang operasinya harus mampu memenuhi kebutuhannya sendiri.

z/Linux

z/Linux adalah Linux yang dimodifikasi untuk jalan di MF. Yang dimodifikasi tentu segala sesuatu yang terkait dengan hardware MF. Sedangkan sisi operasi dan aplikasinya tetap orisinil Linux. Semua kelebihan dan esensi arsiitektur MF tidak dapat dimanfaatkan. Oleh karena itu IBM menyiapkan processor khusus yang telah di-specdown untuk z/Linux yang dinamakan IFL (integrated facility for linux).

Topik-topik terkait

1. Mengoptimasi z/OS
2. Komputer Mainframe
3. GDPS – Konfigurasi Sistem Komputer Antar Kota Antar Propinsi
4. Downsize – Manfaat apa Mudharat? 
5. Mainframe z/Enterprise, Cara Jitu Beternak Server
6. Capacity Planning untukVirtualisasi
7. Mainframe Solusi Paling Jitu untuk e-Gov
8. Web Server Sederhana Berbahanbaku Rexx untuk z/OS
9. Virtualisasi dengan z/VM makin Heboh
10. Awan Cumulonimbus Hadir di Jagat IT