メインフレームの追憶 1話 世界を動かすたった３つのアルゴリズム
さて、すっかり忘れていた連載企画ですが、今日からつらつらと書き始めてみます。
第１回は「世界を動かすたった３つのアルゴリズム」です。
- 作者: ジョン・マコーミック,長尾高弘
- 出版社/メーカー: 日経BP社
- 発売日: 2012/07/19
- メディア: 単行本
- 購入: 15人 クリック: 437回
- この商品を含むブログ (20件) を見る
いきなり、冒頭で種明かしと行きましょう。
その３つのアルゴリズムとは、
１．ソート・マージ
２．マッチング
３．コントロールブレイク
です。
この話は社会に出てすぐの研修で教えてもらいました。ずぶの素人がとりあえずメインフレーム環境でアプリを作れるようになるために、いろいろなことを教えてもらいました。その中でこの話があったんです。
聞いた当時はまったく理解できませんでした。そして、現場に配属され、どういうわけかメインフレームの世界では主流派にはなりえない、画面があるアプリのスペシャリストという道に進んでしまって、ずっとずっと忘れていました。
ところがある時気づいたんです。
画面だろうがなんだろうが、よくよく考えてみると、ソート・マージ、マッチング、コントロールブレイクというアルゴリズムの応用にすぎないのではなかろうかと？
詳細な解説がいろいろなところにあると思うので冗長になってしまいますけれど、俺自身の復習として、いや、恥をかくというリスクもありますけれどね、この３つのアルゴリズムをテキストで説明してみましょうかね。
まずはソート・マージ。
たとえば、
５，２，９，４，３，１
と並んでいる数列を、
１，２，３，４，５，９
に並べ替えるのがソートです。
マージってのは
Ａ：５，２，９，４，３，１
Ｂ：７，１，２，６，５
のＡとＢを合体させて
ＯＵＴ：１，２，３，４，５，６，７，９
という結果を得るアルゴリズムです。
ソートとマージは実は同じアルゴリズムでできるので人くくりになっています。
と、書きましたが、ソート・マージのアルゴリズム書いたのって、その最初の研修だけなんですよね。俺が社会に出た頃にはすでに強力な既成アプリがあったので、メインフレーム環境でも引数としてファイル名といくつかのパラメータを渡すだけで勝手にソートマージされた結果を取得できるようになっていました。なので、今すぐソートマージのアルゴリズムを書けといわれても絶対書けない自信がある。
まぁ、それだけポピュラーなアルゴリズムって事です。
次はマッチング。
これは表形式を使わないとつらい
社員ファイル
| 社員コード | 社員名 |
|---|---|
| 1 | Ｇ |
| 2 | Ｔ |
| 3 | Ｘ |
部門ファイル
| 部門コード | 部門名 |
|---|---|
| 1 | Ｌ |
| 2 | ２ |
| 3 | ０ |
部員ファイル
| 社員コード | 部門コード |
|---|---|
| 1 | 2 |
| 2 | 2 |
| 3 | 1 |
ってな具合になっていた時、社員コードからその社員が所属する部門名を取得するには……。
社員ファイルと社員コードと部員ファイルの社員コードを突き合わせて、部員ファイルの部門コードを取得し、その部門コードを部門ファイルの部門コードと突き合わせて部門名を取得します。それが、俺がここで言っているマッチングです。
プログラマーの人ならすぐにわかるでしょうが、これってORACLEとかMySQLのRDBMS使えばSQL一発でできる話ですよね。そう。逆にSQLの中ではマッチングしまくってると思うんですよね。そして。今の例だと社員コードがキーになっていたけれど、逆に部門コードがキーになっていた場合は、部員ファイルを部門コード順にあらかじめソートしておかなきゃたぶん無駄に複雑になります。
マッチング単独で使うこともたぶん稀にあるけれど、多くの場合はソートマージと組み合わせて使われます。
最後はコントロールブレイク。これの説明がむつかしいんだよなぁ。知らない人には伝わらない。
ってことで外部リンクに丸投げします。
おやおや。コントロールブレイクだけではなくソート・マージとマッチングも解説してあるぞと。3のファイルの併合がマージ、4のファイルの照会と更新がマッチングですね。
コントロールブレイク処理の所に、COBOLで組むと組みやすいみたいなことが書いてありますが、んなことはない。どの言語でもできます。簡単な命令の組み合わせですから。
あと、SQLでも記述できる、とありますが、実際のアプリを作ってみると難しいことも多いです。
俺の経験ではこの３つのアルゴリズムの組み合わせとそれぞれの応用でほとんどの事務系システムは記述できるんですよ。
複雑に見える処理でも、中身を注意深く追ってみると、実はこの３つのアルゴリズムにたどりつく、みたいなことはよくあることです。
メインフレーム時代には、３つのアルゴリズムを組み合わせて同じプログラムで実行するってことはあんまりありませんでした。それぞれ別の専用プログラムを書いてJCLでコントロールするっていうのが普通の作り方でした。
JCLのジョブステップを見ると
１．DBの順次読み出しとPSファイル*1への書き出し
２．ソート・マージ
３．マッチング
４．ソート・マージ
５．マッチング
６．ソート・マージ
７．PSファイルの読み込みとDBへの書き出し
８．コントロールブレイク
みたいな感じになっていることが多かったですねぇ。いやね、DBって遅かったんですよ。あり得ないくらい遅い。PSファイルに書き出さないとバッチ処理は不可能だった。そんな時代もありました。今でもクリティカルな所ではこういう方法を取っていると思うんですよねぇ。
思ったより全然うまく書けませんね。先が思いやられます。自分自身の備忘録ですからなんか思い出したら都度追記してみようと思っています。
