富士通の撤退する「メインフレーム」ってそもそも何？
はじめに
富士通がついに2030年にメインフレーム市場から撤退し、66年の歴史に幕を閉じるという話が出てきました。
富士通といえば国産大型コンピュータの先駆けであり、IBM互換機を作って巨人IBMに食らいついたベンダーでもあります。そんなわけで中々に歴史の転換点を感じる話題ではあるのですが 「ところでメインフレームって何？ 」 という方も多いでしょう。という分けで名前は聞いたことがるけど実態が良く知らない「メインフレーム」 に関して少しだけ解説をする動画を作りました。
この記事は動画では話しきれなかった事も含めて、もう少し深堀した解説をしていきたいと思います。ちょっと長くなりましたが、前半が歴史の話で後半がアーキテクチャの話になるので好きな所にジャンプして読んでみてください。
メインフレーム？ 汎用機？ ホスト？
メインフレームは他にも汎用機とかホスト機と呼ばれることもありますよね。Wikipediaにもいくつかの呼び方と解説が載っています。
実はこれらの名称はだいたい同じものを指しますが微妙に意味ががいます。
メインフレーム
メインフレームとはコンピュータシステムの 「中心」 である事にフォーカスした呼び名です。コンピュータシステムは計算機だけでは成立せず、入出力装置や端末も必要です。それらのシステムの主たるシステム だからメインフレーム、と呼ばれたのですね。当時はシステム一式が非常に巨大だったのでその中心となるコンピュータをメインフレーム、と呼んだのです。
汎用機
汎用機という呼び方も良く聞くと思います。パソコンだってサーバだってどんな処理でも出来るのにどうして 「汎用」 機なんて呼び方をするのを不思議に思った人は大勢居るでしょう。これは言い換えるとかつてのコンピュータは専用機 だった時代があるんです。 かつては商用計算専用機や科学技術計算専用機と言う感じで特化型でした。System/360に代表されるようなソフトを変える事で複数の目的に使えるが故に 「汎用」 機と呼ばれた訳です。現代のコンピュータは基本的に全て汎用用途で活用できるのでちょっとピンと来ないですよね。
ホスト
ホスト あるいはホストコンピュータという呼び方も良くしますよね。これは今では一般的に使われる分散システム(※)---つまり普段我々が使っているWindowsやUnix/Linuxとの対比です。母艦（ホスト）となるマシンに各周辺系が繋ぎに行くことからのイメージだと思います。特にダム端末（現代で言うシンクライアントみたいなの）だと全部ホストでやりますからね。まあ一周回ってクラウドの時代はホスト時代と同じ集中の時代な感じもするのは面白いですよね。
ref: 総務省 - 情報システムの進化
この３つの言い回しは微妙に定義が違います。特に古い機種だと 「メインフレームではあるけど汎用機では無い」 というケースもあり得ますが、この令和の時代、特に注釈が無ければIBMのSystem/360の後継及びその互換機を指していることが多いでしょう。今回の記事の中では基本的にはその意味でメインフレーム、呼んでいきます。
ちょっとだけメインフレームの歴史
コンピュータの登場、そしてIBM System/360の爆誕
さて、まずは少しだけメインフレーム、そしてコンピュータの歴史をおさらいしましょう。コンピュータの歴史はバベッジの階差機関まで遡る事ができ。。。とか言い出すと長くなるので、一般的に世界最初のコンピュータと言われるENIACから始めます。
1947年に最初のコンピュータENIACが稼働を始め、1950年には最初の商用計算向けコンピュータのUNIVAC Iが登場しました。ちなみにUNIVACの開発にはCOBOLお婆ちゃんことグレース・ホッパーも参加しており世界最初のコンパイラとか開発しています。
閑話休題。ただ、この頃に登場したマシンは以下のような課題がありました。
- 科学技術計算専用、商用計算専用という形でコンピュータが用途毎の専用機に分かれていた
- 同じ会社（例えばIBM）が開発したマシンでも現行機と次世代機で互換性がなくアプリが使い回せない
1は先ほど述べたとおりなのですが、2も相当の困りものです。これはファミコンとスーパーファミコンは同じ任天堂のゲーム機の次世代機でありながらまったく互換性がない事と同じです。ファミコンで遊んでいたマリオをスーファミで楽しむには新規に開発しなおしみたいな話です。これでは気軽に現行機から次世代機に切り替える、というわけには行かないですよね？
スーファミでファミコンを代替することは出来ませんから、当時のちびっこ達は両方持つ必要がありました。これと同じことが当時の大型コンピュータの世界でも起こっていたのです。
そこに誕生したのがIBMのSystem/360です。このマシンは現代では当たり前のOSを搭載し、これによりアプリケーションを入れることで科学技術計算から商用計算まで様々な用途に活用することが出来ました。360度全方位に対応できるゆえのSystem/360なのです。
それだけではありません。IBMのSystem/360の最大の特徴はアーキテクチャに互換性のあるコンピュータ・ファミリという概念を作り上げたことです。IBMは様々な価格帯でCPUアーキテクチャに互換性をもたせる事で廉価版から初めて上位機種にアップグレードする余地を作ったり、後継機でも改良しながらも可能な限り互換性を保つことで圧倒的なシェアをとる事が出来ました。
この利便性とそもそもの性能の良さも相まって、当時はアメリカの出荷数の７割を締め 「白雪姫(IBM)と7人の小人」 と呼ばれ他のベンダーが残りのシェアを数％ずつ分け合うというような状況だったようです。
ref: 日本のコンピュータメーカと 7人の小人（1）
日本でのメインフレームの展開
さてIBMのSystem/360の登場まで話したところで日本のコンピュータ史を見ていきましょう。
今でこそコンピュータの開発ベンダーといえば海外を想像しますが、当時は日本も国産コンピュータを作っていました。
日本で最初のコンピュータは1956年に岡崎文次により開発されたFUJICだと言われています。UNIVACから数年でしかもほぼ単独で開発してるのは天才としか言いようが無いですね。。。
そして日本のコンピュータを世界に知らしめたのは今回話題の富士通、そして国産コンピュータの父とも呼ばれる池田敏雄です。彼らは真空管ではないリレー式と呼ばれる仕組みのFACOM100を開発し、トランジスタ型、LSI型と開発を続け国内でのシェアを獲得していっていました。
しかし1964年にIBMがSystem/360を開発すると事態は大きく急変します。このままでは我々も白雪姫に付き従う小人の一人になると焦った彼らは、System/360の互換機を作り膨大なソフトウェア資産を共通化することで移行をしやすくし、廉価版/パチモンでは無く、性能などの優位性を出して客を奪い取る、というチャレンジに出ます。そのためにSystem/360を開発し、あのアムダールの法則を提唱した、天才アムダールと組んで作り上げたのがFACOM Mシリーズです。これが今回試合終了を言い渡されたGS21のご先祖様ですね。
ref: FACOM M-160 -コンピュータ博物館
ちなみにアムダール社は1997年に富士通に完全買収され今でもシリコンバレーのサニーベールにFujitsu Research of America, Inc.として存在しているので機会がある人は寄ってみても良いかもしれません。
また、このあたりの富士通のコンピュータ開発物語はプロジェクトXとかでもやってたので、以下を読んだり見たりしても面白いかもですね。それ以外にも多くの書籍やWebを読むことが出来ます。
また、富士通以外にもNECや日立、東芝や三菱が経産省の旗振りの元に集い当時のコンピュータ産業を支えていました。
ダウンサイジングの波、そして衰退へ
メインフレームは国内外で大人気となり80年代にはその隆盛を極めました。銀行の第3次オンラインと言われるムーブメントもこの頃に起こり、多くの金融系システムがメインフレームなのもこういった時代背景に由来します。
しかし、そんなメインフレームも90年代にはその権勢に陰りが見えてきます。今までは本格的な業務用途には耐えられないと考えられていたUnixやWindowsが力を増し、シェアを奪われていったのです。
ref:メインフレームに対する認識はIBMユーザーと国産ユーザーでは異なる
ref: 総務省 - 情報システムの進化
メインフレーム大国と言われる日本ですら、近年は大きく売り上げを落としてるのが分かります。
これらUnixやWindowsといったサーバは、C/SモデルやTCP/IPなど当時の最新技術を採用し、単一のマシンで動作しClosedなソフトや仕様を扱うメインフレームとの対比で、分散システムあるいはオープン系システムとも呼ばれました。ちなみにこの時シェアを奪った急先鋒の一人が今回同じく富士通が終了宣言をしたのがUnixの代表格SPARCです。かつての侵略者と同時に退場と言う意味ではメインフレームは良く頑張ったのではと。
セキュリティや保守性、TCOの面で優位性から完全悪とみなされている分けでもないですが、世間的には 「レガシー」、「滅びゆく恐竜」 とか揶揄されながらもCOBOLと共にどっこい生きてるすごい奴です。色んな経緯が紐づいてるとは言え50年間意味のあるコードであり続けることはシンプルにスゲーのです。私はそんなアーキテクチャ設計やコーディングする自信は無いです。。。
現在のメインフレーム
さてオワコンのメインフレームを富士通が辞めるのは当然。むしろようやく？
と思う人も多いのかな、と思います。しかし、実際問題としてメインフレームは割りとまだ動いています。
銀行を始めとした金融系は基本的にコアな部分は秘伝のタレを継ぎ足して作ってるので、そう簡単には入れ替えが出来ません。今話題沸騰中のみずほだってメインフレームは使っています。
他にも政府系などでも元気に動いているところもあり、コロナショックでCOBOLエンジニアを募集していたのも記憶に新しいですね。
めずらしい所だと2026年にはオーディナルスケールという最新のメタバースシステムがIBMのz/Systemで稼働するそうですよ！（ﾏﾃ
冗談はさておき、全盛期からするとメインフレームは確かに大きく売り上げを落としていますが、この10年くらい落ちてもいません。しかもこれはあくまで出荷の売上ですが実際には保守サポート費用がガッツリ乗ってきます。
また、グローバルでは2020年時点でも2兆円を超えるマーケットと言われています。このようにメインフレームはまだまだそれなりの市場規模はある業界なのです。日本の銀行もメインフレームを使っている所はまだまだありそうです。
最近、AmazonやGoogleがやっきになってメインフレームからのマイグレーション市場を取り込みたいのはそもそも巨大なマーケットだからというのも理由の一つでしょうね。
つまり、以下に書かれているように価値があるから捨てれない。技術的負債は資産であってゴミじゃないですからね。移行しやすい/出来るところは既に2000年台前半で移行しているので、今残っているところはそうそう移行しない(or できない)でしょうね。
そんな中で、その市場から富士通が抜けるというのはやはりインパクトのある話です。何しろ富士通は国内シェアの3割以上を持つトップベンダーですから。
ref:お客様の基幹システムを支え続ける富士通メインフレーム ～国内市場シェアNo.1～
まあ現代でも最強の恐竜であり続けるIBMのz/Systemとは異なり何年も前から進化を止めて保守で食ってた感じはするので、時間の問題かなー、とは思ってたのですが、思ったよりも完全撤退が早かったですね。しばらく保守で生きていくと思ってたので。
これから富士通ホストを使ってたところは移行祭りが発生するでしょうね。今も残ってるところは規模か予算に課題を持ってるだろうから大変そう... そして富士通はクラウドを押してるけど、やはり富士通クラウドなんですかね？ AIMとかマネージドサービスで出すんだろうか… 気になります。
メインフレームのアーキテクチャ
メインフレームの歴史の話をしたので、次はアーキテクチャの話も少ししたいと思います。
メインフレームはオープン系と言われる今のふつうのサーバ(以下、ふつうのサーバ)とは全く異なるアーキテクチャです。スマホとサーバの方が全然近いレベルですね。共通のご先祖はいても系統樹が異なる昆虫と哺乳類みたいな関係とでも言えば良いのでしょうか。
言い出すとキリが無いのですが、個人的に注目するべき差分を以下にサマリしてみました。
| メインフレーム | ふつうのサーバ(オープン系) | |
|---|---|---|
| CPU | 独自 | x86/Arm |
| OS | MVS系 | Linux, Windows |
| 文字コード | EBCDIC | ASCII, UTF-8 |
| ファイルシステム | フラット構造 | ツリー構造 |
| ファイル構造 | レコード単位、OS管理 | バイナリストリーム単位、アプリ管理 |
| ジョブ制御 | JCL | Bash, bat(cmd), PowerShell |
| 良く使われる言語 | アセンブラ, COBOL, PL/I | C, Java, .NET, Python, Ruby, PHP, JS, Go |
| 良く使われるDB | IMS/HDB, NDB | RDB, KVS/NoSQL |
ちなみにメインフレームのアーキテクチャは下記のサイトが詳しすぎるほど詳しく当時よくお世話になりました。
書籍はこれが現代語で読みやすかったです。
CPU
ふつうのサーバではCPUはx86かArmですよね。IntelやAMDを中心にサーバベンダーとは別の専任のCPUベンダーが開発をしています。メインフレームは**IBMのPower IBM z14等が有名ですがベンダー自身がチップも製造しているケースも多いです。富士通もそうですね。こうした独自アーキテクチャによってBCDのサポートなどメインフレームに特化したHWサポート**を入れています。
また、IBMのz/Architectureは別ですが現代のIntel/AMDのチップに比べれば単純スペックは見劣りするのがメインフレーム系のCPUだと思います。
ただ、そんなことよりも重要なのはCPUの使われ方です。PCサーバ由来のアーキテクチャではCPUがほとんどの処理を行います。もちろんGPUとか専用ユニットもありますが、やはりCPUが基本。対してメインフレームでは用途毎に専用チップを持っている事も少なくありません。
その代表格がI/Oチャネルです。これはようはI/O専用プロセッサですね。CPUの代わりにI/O機器と直接やり取りをするため、CPUが高負荷になったり逆にI/Oが高負荷になったりした場合にお互いに影響を与えずに安定した処理を行う事が出来ます。
メインフレームの高負荷でもスループットが安定する という特徴はCPU以外にもI/Oチャネルのような専用のチップを持っている事に由来します。
とはいえ今はDMAもあるし、I/Oに限ればそこまで顕著に変わらないんじゃないかなー、という気はします。マルチコアだし。シングル(ないしはデュアルくらい)のCPUでDMAなしの環境と比較した事が無いので分からないですが… DCに大型プリンタがあってメインフレームから直接帳票を印刷するようなケースだと圧倒的な速度差だった！ というのは話に聞いたことはあります。
Operating System (OS)
ふつうのサーバではWindows ServerかRedhatやUbuntuのようなLinuxディストリビューションが使われるでしょう。メインフレームではMVSと言われる聞いたことも無いOSが使われます。これはSystem/360に乗っていたOS/360の系譜ですがLinuxとWindows以上に全然違うOSです。MVSの後継及び互換OSであるz/OS(IBM)、MSP(富士通), VOS(日立)があります。いやz/SystemならLinux動くし何ならDockerとかk8sも行けるよ！ って話は今回は割愛。
もちろん、WindowsとLinuxも全く違うOSなのですが長年の相互運用の中で用語や概念が近づいていたり採用しているテクノロジーが一緒だったりします。一方で、MVSは先ほども述べた通りの別の系統樹。用語や概念も違えば採用しているテクノロジーが違う事も多いです。以下ではその特徴的な所を見ていきましょう。
文字コード
WindowsやLinuxで文字コードといえばASCII、そしてその拡張であるUTF-8ですね？ かつてはWindowsとMacはShift_JIS系、LinuxはEUC-JP系という感じで分かれていましたが今はみんなUTF8を使う事が多いですね。そしてなにより全部ASCII互換なので日本語は読めなくても英数字の部分はどの文字コードで書いてもどのOSでも読めました。
これがメインフレームと決定的に違います。メインフレームではEBCDICを基本にしており、日本語拡張はJEF(富士通), KEIS(日立), JIPS(NEC)等があります。これらはASCII系では無いのでなんと英数文字すらそのままま表示できません！ PCで直接開こうとしても専用の変換ツールを経由させて置かないと文字コード違うので普通に不便です。そこは売ってるので買えば良いだけですが。
さらに厄介なのは漢字周りでJEFやKEISは古いからと言って一概に文字のカバー範囲が狭いわけでもないのです。結構、微妙な異体字とか入っていて何処までをカバーするかは難しい… 少なくともShift-JISとかの範囲では外字を使わなければ表示が出来ないので要注意です。
ちなみにEBCDICには数値型を文字のように取り扱うゾーン10進という考え方があります。これはメモリの中身をファイルにそのまま吐くCOBOLのような言語ではとても重宝しますね。可読性の点で。EBCIDCに関連した動画として以下のようなものも作っているので良ければ見てみてください。
ファイルシステムとファイル
通常はファイルシステムはツリー構造ですよね？ ルートが合って、そこからディレクトリまたはフォルダを作成していくのが一般的だと思います。
一方で、メインフレームではファイルシステムは基本的にフラットです。階層が無いのですね。そこにファイルを置いていきますがそれだと不便なので「.(ドット)」で区切ってFOO.BAR.HOGE.FUGAみたいな感じで疑似的な階層構造を表します。S3などクラウドのオブジェクトストレージとおんなじ感じですね。最も、あれはちゃんとGUI上の支援があると思いますが。。。 とはいえ、これだけだと不便なので区分データセット ( PDS, Partitioned Data Set) というモノを作り中にファイルを入れる事が出来ます。これは1階層しかないフォルダとみなすことも出来るのでPDSとネーミングルールで管理を行います。
もう一つ、大きな特徴としてはファイルの取り扱いです。ふつうのサーバのファイルシステムはファイルを単なるバイトストリームとして扱い、フォーマット等中に何が書いてあるかはアプリケーションの責任です。一方、メインフレームではファイル---データセットと呼ばれますが、をバイトストリームでは無くレコード単位(行単位)で取り扱います。つまりフォーマットの責務がOSにあります。
バイトストリーム方式の場合は、アプリで自由にフォーマットを決めれるのでフレキシブルな反面、対象のアプリケーションが分からなければ開くことが出来ません。一方で、OSが責務を持つレコード方式の場合はどのアプリで書いたファイルもOSの標準形式として読むことが出来ます。これはメリットデメリットがある話ですが業務アプリにはなかなか便利な特徴です。
メインフレームはファイル(データセット)を取り扱う際に以下の2つのポイントがあります。
- レコードフォーマット
- ファイル編成法
レコードフォーマット
レコードフォーマットは固定長と可変長があります。レコードの中にブロック云々の話は今回は割愛。
固定長は文字通り固定のレコード長で区切ってデータを入れる方式で100バイトなら実際に必要なサイズが10バイトであっても残りを0とか空白で埋めて1行100バイトで出力するような形式です。メインフレームを直接触らなくてもレガシーデータを触る時には見るかもしれませんし、パフォーマンスが良いので現在もプリミティブな仕組みの中には入っている事が多いです。
注意しないといけないのは 「改行コードも本来は無い」 という事です。普通のサーバにデータを渡す時にメインフレーム側で気を利かせて毎レコード改行コードを入れた形に変換する事はありますが固定長に改行コードなんで本来ありません。改行コードのように特定のバイト値でレコードを区切るのはどちらかというと可変長の考え方です。改行を期待して開いてみたら1行しかなかった！ みたいなこともあり得ると思うので注意をしてください。
ref: 「メインフレーム・コンピューター」で遊ぼう - 07.データセットの種類とアクセス方式
可変長 はレコード長が決まってない可変長の一種です。レコードの先頭4バイトにRDWと呼ばれるヘッダがありレコード長が書いてあります。つまり改行コードのように区切り文字がある所まで読み進めなくてもレコード長が分かるのです。便利ですね。
ref: 「メインフレーム・コンピューター」で遊ぼう - 07.データセットの種類とアクセス方式
固定長は非常にシンプルなのでLinuxのfoldコマンドとかでも簡単に改行をくっつけれて便利ですが、可変長はバイナリを解析しないとレコード長が分からないのがマイグレーションをする時の注意点でしょうか。一方で、固定長はファイルだけ見てもレコード長が推測しかできないので使ってるプログラムを探し当てる必要があります。
ファイル編成法
レコードフォーマットとは別にファイル編成法というものがあります。かつては基本情報技術者試験に良く出てたんですが、最近はさすがに出ないかな？ 当時、何のことを言ってるのかさっぱり分からなくて困惑したのを今でも思い出します。何しろメインフレーム特有の概念なのでWindowsとかLinuxしか触ってないと分からない... そんなファイル編成法を紹介しましょう。
| 名称 | 概要 |
|---|---|
| 区分編成ファイル(PDS) | ファイルシステムのところで説明したけど乱暴に言えばフォルダ。この中に複数のデータセットを入れる事が出来る |
| 順編成ファイル(PS) | レコードをシーケンシャルに読み書きする。ふつうのサーバでのファイルの感覚に最も近い |
| 仮想記憶編成ファイル(VSAM) | キーアクセスおよびインデックスアクセスが出来る。実質DB |
PDSはいったんフォルダとして理解して問題無いと思います。PSファイルは普通のファイルに最も近いですね。シーケンシャルに読み書きを行う。面白いのがVSAMで、これはKVSみたいな簡易のDBですね。インデックスキーでアクセスする事で高速なランダムアクセスを可能にしています。同じ 「ファイル」 くくりで見てると大きく誤解しがちだと思います。
データベース
ふつうのサーバではRDBやKVSを良く使いますが、メインフレームではIMSのような階層型DB(HDB)やその発展形であるネットワークDB(NDB) が使われる事が多いです。一応RDBもありますが性能等から前者の方が多い印象です。
HDBとかNDBとか大学の授業で古典として習うレベルですが、まだまだ現役です。
ref: データベースの種類を３つ紹介！RDBMSとNoSQLの違いも解説
HDB/NDBとRDBの最大の違いは、SQLのようなクエリの存在と何よりもWHERE句の存在です。HDBにしろNDBにしろアクセスの基本はキーアクセスと隣接するノードを辿る事だけです。
例えば以下のような果物スキーマを考えます。
| ID | 名前 | 個数 |
|---|---|---|
| 1 | リンゴ | 5 |
| 2 | レモン | 0 |
| 3 | トマト | 3 |
| 4 | スイカ | 0 |
| 5 | ミカン | 0 |
このデータから売り切れ(=個数が0)の商品を削除してみましょう。RDBを使うのであれば以下のような疑似コードで書けますね。
rs = db.execute("delete from 果物 where 個数 == 0")
これで個数が0個のものだけ出力できますね。一方でHDBやNDBの場合は以下のような感じになります。
db.init("果物").first
r = db.next
while(r != null){
if (r.個数 == 0){
db.delete(r.id)
}
r = db.next
}
疑似コード、疑似APIなので細かい所はさておき、違いの雰囲気は掴んでもらえたのではないでしょうか？ 重要な点はWhere句が無いのでHDB/NDBではデータを全てなめてプログラム側でフィルタリングしているという事です。
これはRDBよりもKVSのようなよりシンプルなモデルに近い考え方ですよね。シンプルな分性能は非常に高いです。
それぞれの違いはDBの特性の違いなので良い悪いは無いのですが、マイグレーション等でHDB/NDBからRDBに移行しようとすると問題になりがちです。まずプログラムをなるべく書き換えずに 先ほどのHDB/NDB向けのコードをRDBに対応させてみましょう。
rs = db.execute("select * from 果物")
for(r : rs){
if (r.個数 == 0){
db.execute("delete from 果物 where ID=r.id")
}
}
こんな感じで本来1度で良かったSQL発行が4回に増え、DBアクセスもやり取りするデータ量も増えて今います。これは典型的なRDBのアンチパターンですが膨大なCOBOL資産のビジネスロジックをすべて書き直すのは現実的では無く、マイグレーションではマシン性能で何処まで誤魔化しきれるか？ が鍵になるかと思います。どうしても誤魔化せない奴だけ気合い入れて改修ですかね... 以前、以下のような記事も書いたので良ければ参考に。
またRDBよりデータモデルがより近くアクセスも高速なKVS/NOSQLに置き換えるのは良いアイデアに思えます。顧客番号みたいなのがキーになってると尚更相性は良い気がします。ただ現代でも残っているメインフレームの大半は重要な基幹システムでしょうから、そこにKVS/Document DBを入れるとなればかなりそれらに精通している必要があるのでチャレンジングな領域ですね。DB側でACIDが保証されない部分を別な方法で担保したりもいるし…
他にもデータモデルの違いから第三正規化とかがされているわけでは無いですし、そこら辺のRDBとのギャップが大きいのは事実です。1. RDBでシミュレーションするか、2. SQL最適に書き直すか、3. KVS/NOSQLを使うか、それが問題。まあ1をベースに部分的に2が安パイだけど3は今後が気になるなぁ。
JCL(Job Control Language)
さて、最後にJCL(Job Control Language) に関して話ましょう。
ふつうのサーバでジョブ、つまりバッチを起動する時はどうしますか？ JP1やRundeckのようなジョブ管理ツールの話はいったんさておき、Windowsならbat/psファイルに包んで、LinuxならBashなどに包んで実行する事が多いと思います。それらシェルファイルの中で実際のプログラムで使う環境変数の定義やパラメータを渡し、そしてプログラムを実行するわけですね。
JCLは端的にはこのバッチ用に作ったシェルファイルと同じ役割です。ただ圧倒的に高機能です。
JCLにはリソース管理という非常に強力な特徴があります。単なるシェルというよりはk8sとかのコンテナへのリソース管理をイメージした方が分かりやすいかもしれません。
以下はとてもシンプルなJCLのサンプルです。//から始まっていますが別にコメントアウトされている分けでは無く実行部です。これも初めて見るときは戸惑いますよね＞＜
//JOBA JOB MSGCLASS=H
//STEP1 EXEC PGM=PGMA
//INPUT1 DD DSN=USER.DATA1,DISP=SHR
//OUTPUT1 DD SYSOUT=*
ref: 「メインフレーム・コンピューター」で遊ぼう - JCL入門
まず先頭行でジョブ名をJOBAと定めています。2行目のSTEP1は最初のステップを定義しています。ジョブは複数のステップを束ねたもの。 なので、一つのJCLの中で複数の一連の処理を実行する事が出来るわけです。。EXEC PGMは実行する対象プログラムを指定しています。ここではPGMAが実行対象です。
次にINPUT1とOUTPUT1が定義されています。これはJCLのとても面白いところで、このDD句(ディーディー:Data Definition)を使って物理的なファイルをPG内で使われる論理ファイル名にマッピングします。今回でいえばデータセット名がUSER.DATA1のファイルにINPUT1という名前をつけ、OUTPUT1にSYSOUTをマッピングしています。SYSOUTは画面とかプリンタみたいな出力装置です。
COBOLなどプログラム上では論理名でしか記述してないのでJCLを書き直すだけで入出力の対象を切り替えれますし、なにより障害調査等でJCLを見るだけで入出力ファイルが瞬時に特定できます。これがふつうのサーバのようにBashだと実際のプログラムの中を見てみるまで本当はどんな入出力か分かりませんが、JCLは命名規約じゃなくてシステム仕様なので信用できるのは良いですよね。この仕組みはふつうのサーバの世界にも欲しいと思いました。Dockerとかコンテナを頑張れば出来そうな気もするけれど...
このDD句でリソース制限やアクセスコントロール、ファイルの世代管理なんかも出来て割と万能な感じはありましたね。
不思議の国のメインフレーム語
さて、アーキテクチャの話もしてメインフレームがふつうのサーバであるWindowsやUnix/Linuxとは系統樹が大きく違う事を知ってもらえたと思います。私は元々Web系の開発年やってから少しばかりメインフレームに触る機会があったのですが、新卒以来久々に 「何言ってるのか良くわからんMTG」 という言葉のか別にぶつかりました。という分けで、当時の私に届けと言う気持ちで特に当時印象に残った不思議な用語をピックアップして載せておきたいと思います。
アップロードとダウンロード
私の一番のお気に入りかつ、困惑した言葉がこれ。
いや、アップロード/ダウンロードは普通に使うでしょ？ と思ったそこのあなた。認識が甘いですよ！
なんと、これ一般的な意味と逆なんです。つまりPCからメインフレームにファイルを持って行くことをダウンロードと呼び、メインフレームからPCにファイルを持って行く事をアップロードと呼ぶのです。当時、配属されたチームで先輩社員に「作ったPGをアップしたいので手順書ありますか？」と聞いたところ快く教えてくれたのですが、どう考えてもメインフレームからの取得方法で困惑したのは良い思い出...
これはメインフレームが全ての中心でありPCのような周辺のシステムにファイルを配るという発想でアップロードなんですね。我々はクライアントを中心に考えがちですがメインフレームの世界ではあくまでメインフレームが王様なのです。
ちなみにimport/exportも逆なのでコマンドとかは注意をしましょう。
ライブラリ
これはちょっと会社方言の可能性もありますがPDS(=フォルダみたいなもの)をライブラリと呼んでる事もありました。たぶんPDSにプログラムを固めてプログラムライブラリとして利用していたからだと思いますが、そもそもプログラムライブラリからしてDLLとかsoとかを思い浮かべがちなふつうのサーバの世界からは謎用語ですよね。これは単なるプログラムを集めてるところくらいの意味です（※ なんかシステム的にも特別だったのかもだけ覚えてない）。初期のMTGで 「何故この文脈で急にDLLの話を？？？」 と困惑したものです。
データベースの創成
データベースの創成、なんかココロオドル中二な言葉ですね！
ただこれ何のことは無いデータベースの作成、という意味なんですよね。今の訳語が固まる前から日本語化等をしていたので、ミドルウェアのマニュアルとかを読んでるとこうしたちょっと独特の言い回しに出くわすことがあります。DB創成って最初何してるのかと思いましたよ。。。
FILLER
別にこれはメインフレーム用語では無いのですが、同じタイミングで知った＆良く使うので。
固定長で余った部分にゼロや空白を埋める領域の事をFILLERと呼びます。通常COBOLの構造体は固定長で作るので後から項目を増やせるように要所要所にFILLERを定義して遊びを作っておくのですね。
「そこのフィラーを〇×△して。。。」みたいに言われた時には「フィラーってなに？」という気持ちでしたね。
分散システム/オープン系
本文中でも既に書いていますが、メインフレーム界隈で分散システムといえばふつうのサーバの事をさし、オープン系といえばやはりふつうのサーバの事をさします。別段、HadoopやKafkaの話をしていたりOSSの話をしていたわけでは無いのです。
同じくPCを利用した開発のことを分散開発と呼んでるドキュメントも見たことがあります。
今の私たちからすると 「それってふつうじゃん！？」 って思うのですが、それが「ふつう」ではない時代もあったという事です。
なお日本では分散システムとオープン系はほぼ同じ意味で使うのですが、海外ではオープンシステムは主にUnixの事をさしてWindowsは含まないらしいです。Windowsサーバは分散システムとだけ呼ばれてたんですかね？ まあメインフレームと汎用機の違いみたいなものなので、トリビアとして覚えておいても良いかもです。
おまけ: ターミナルエミュレータは何を「エミュレーション」しているのか？
ターミナルソフトあるいはターミナルエミュレータという言葉を聞いたことがありますか？ そうTenletやSSHをするための黒い画面です。TeraTearm とかが元々有名ですが、最近はWindows Tearminalとかも出たり、リモート接続というよりシェルへのI/Fとしての意味合いが大きいですよね。
このターミナルが何を 「エミュレーション」 しているかと言えば、実はメインフレームへの接続端末のエミュレーションに由来します。このVT100を使う代わりにPCから接続できるようにしたからターミナル(端末)エミュレータなんですね。
複数の方から指摘ありましたが、メインフレーム向けの端末エミュレーション対象はVT100じゃ無いですよね。。。3270型端末とか富士通6680型端末とかですよね。どのメインフレーム使ってるかによると思いますが。端末名忘れたのでEXTESとかのページ見てたらSNA（FNA）とかの話題もあったなぁ、と思い出す。
VT100互換の端末エミュレータは多くダム端末の一つではある認識ですがメインフレーム向けに通常使われるものでは無いですね。
今となっては名前が残ってるだけですが、こんなところにもメインフレームのかつての栄華を垣間見る事が出来ます。
まとめ
メインフレームに関して、歴史からアーキテクチャまでざっくりと書いてみました。
国内でもまだ使っている所があったり、グローバルでも2兆円規模の市場が残ってるとかは意外に思われた方も居るんじゃないでしょうか？ 今回の記事で謎のマシン - メインフレームの理解が少しでも深まれば幸いです。
また、「ふつうのサーバ」 とは文字コードやファイルシステムなど基本的な所がかけ離れているのは面白いですよね！ あまり積極的に触りたい気持ちにもなりませんが…
それにしても、2035年まで保守期間を含めると使えはしますが、これから各社で移行祭りが始まりそうですね。どうなるのだろうか。。。
それでは、Happy Hacking！
Discussion
富士通のIBM互換機を誤ってFACOM-230としていた所をMシリーズだよ、と@hiyodori5さんに指摘を頂いたので修正しました。ありがとうございます。
とても良く纏められた分かり易い記事ですね！Wikipediaのメインフレーム記事にお粗末な名称などの話を書いた者です。ところで「メインフレームはIBMのPowerが有名ですがベンダー自身がチップも製造しているケースも多いです。」はpowerがメインフレーム用プロセッサにも読めてしまう気がしますが、zと powerは別プロセッサですので、念のため（ウェハーやSOIなど製造技術は一部共有化していますが）。
おっしゃる通りですね。。。一応ちゃんと別物とは知ったはずなのに書きながらIBMだからPOWERみたいにうっかり混同して書いてますねorz
ご指摘ありがとうございます！ 修正しました。
Operation Systemってなんだろう。。。直した
ライブラリーはJCLでJOBLIBとかで指定できるDSNで共通モジュールを入れてますよ。
あとJCLはカラムが意識されていると良かった。DDは9カラム目に書かないとだめとか…。
なるほど！ そういえばJOBLIBとかあった気がしますね。うろ覚えすぎる。 そういえばJCLは書く位置が決まってたんでしたっけ。
私の猿真似ブログに、勝手ながらこちらの記事へのリンク貼らせていただきました。問題あればお知らせくださいませ（ぺこり）
丁寧にありがとうございます。もちろん問題は無いです！
そして、記事中の歴史とか経緯の話はとても勉強になりました＞＜