交換機のリンケージ

　割り付け職人は、ヘキサ電卓（１６進の電卓）を何日もたたいて、足し算をしていた。
　コンパイラが出力する機械語は相対番地で、それを絶対番地に直すことを「リンケージ」という。絶対番地は、物理メモリ上のアドレスである。最近はロード時にリンケージしているシステムが多いが、交換機では事前に行い、リロードを高速にしていた。
　交換機は二次記憶にも半導体メモリを採用していた。通常のコンピュータはハードディスクで、プログラムはファイルとして保存されている。交換機のリブートは、二次記憶からメモリへ転送するだけ。そのためメモリイメージのまま二次記憶に保存した。そこで、リンケージでは、メモリと二次記憶、両方の絶対番地を割り付ける。これが割り付け作業を難しくしていた。
　まずメモリの割り付けを考えてみよう。０番地から順にプログラムやデータを割り付ける。プログラムの領域は、バグで破壊されないよう書き込み禁止にする。データは、いつ初期化するかでグループ化する。スタックのように、初期化が不要、つまり二次記憶にバックアップが不要な領域もある。リブートの種類に応じて、リロードプログラムが百個もある領域から選んで転送する。
　１つのモジュールをコンパイルすると、プログラムの機械語、データ、ジャンプテーブルなどが出力される。全モジュールでは千個にもなる。それらをどの領域に割り付けるか、リンケージのコマンドで指定する。領域の名前、メモリ番地、二次記憶の番地、その領域に含める機械語というコマンドの羅列である。職人は機械語サイズを足して、領域を越えていないか確認する。
　ただ順番に並べるだけなら、領域の番地指定を「＊」とすればよい。リンケージプログラムが足し算を行い、番地を割り当ててくれる。、それなのに、職人はすべての領域に番地を指定していた。それは、メモリの番地と二次記憶の番地の両方をコマンドで指定しなければならなかったからだ。
　交換機は役割の異なる４種類のプロセッサから構成されていた。各プロセッサのメモリは独立で、０番地からだが、二次記憶は１つ。だから、二次記憶上はプロセッサ毎にずらして配置しなければならない。また、メモリ上に存在するが二次記憶にはない（バックアップがない）領域もある。だから、メモリと二次記憶の領域の配置は全く異なる。コマンドを見ても、割り付けをイメージできない。そこでまず「割り付け図」を描いた。プロセッサ別のメモリ割り付け図と二次記憶の割り付け図が職人の成果物だった。
　某社の初代割り付け職人は、じつはリロードプログラムの担当だった。各領域をどうロードするか設計し、割り付けも決める。合理的だ。しかし、リロードプログラムにはゴミがたくさんあった。じつは三割がゴミだったモジュールだ。どういう領域がいくつ必要になるか、最初は分からないから多めに用意していたのだ。プログラムをカードパンチで入力していた。急に領域が必要になったら、計算センタの入口でカードを受け渡す。領域の先頭とお尻のカードを挟んで加え、リンケージを実行する。ゴミから、そんな光景が想像できた。
　ゴミ掃除で絶対番地指定は半減したが、まだ百のオーダである。大幅削減には＊指定しかない。そこで、メモリのリンケージと二次記憶のリンケージを別々に行う方法を思いついた。片方だけなら、領域を順に並べるだけなので、ほとんど＊指定にできる。ハード的に特定の番地指定が必要な箇所は数個だった。（たとえばプロセッサ間通信の領域）
　二次記憶だけリンケージして番地を決める。プロセッサ別メモリ割り付けのコマンドファイルの二次記憶アドレスだけ書き換えるツールを用意した。そうして、二百箇所あった番地指定を十箇所まで減らすことができた。
　二カ月毎に恐る恐る＊指定に変更していった。それを社内のニュースで報告した。リンケージ専用にメモリ１６ＭＢのＳｕｎサーバを買ってもらいたかったからだ。リンケージ回数が増えたため、朝までに終わるよう高速化したかった。（当時４ＭＢ、８ＭＢだった）「そも何回もリンケージするのはおかしい」と批判はあった。しかし、番地指定削減が役立つときがすぐにきた。「二次記憶上のプロセッサの配置を変えたい」という要望が舞い込んだのだ。従来なら「では次のバージョンで」つまり半年先だ。割り付けを大幅に変えたら試験が止まり、振り出し戻る恐れがあった。それを一晩で変更し、リンケージしてみせた。交換機は一発で立ち上がった。
　削減にあたり、もう１つ大きな壁があった。それまでは、メモリと二次記憶、番地の下３桁を揃えていた。パッチの作成を楽にするためだった。パッチもメモリと二次記憶、両方の番地が必要だった。＊指定では揃わなくなる。揃える工夫より、割り付けをシンプルにして、ほぼ自動で一晩でリンケージできることを優先した。クレームに備えて、パッチ作成支援のツールも用意した。結局クレームは来なかった。本当は誰もパッチを作りたくなかったのだ。
　割り付け職人の成果物はＡ３の「割り付け図」だった。ヘキサ電卓をたたき、決定した番地を図に書き込む。それを基にリンケージのコマンドを作成した。リンケージ後、割り付け図通りにできているか確認していた。この手順を逆転した。リンケージ結果から割り付け図を作成するツールを用意したのだ。しかし、パッチが不要になると、割り付け図は重要ではなくなった。
　研究所でも割り付け図作成支援ツールを開発していた。そこが大変だと聞いたからだ。しかし、ツールが描く割り付け図は評判が良くなかった。領域のサイズを正確に反映していたが、分かりにくい。職人は関心ある領域を大きく描いていた。見やすい図にする工夫で研究所は苦戦していた。「利用者の声を聞け」とよく言われるが、本当のことを知っている利用者はなかなかいない。
　コンパイルやリンケージの改良について、研究所の冊子に書く機会を得たので、開発現場からの視点でまとめた。しかし数年後、研究所はＣＨＩＬＬ言語を捨て、Ｃ言語に乗り換えてしまう。
　ソースを直し、翌日には試験できる体制は、後輩たちに引き継ぎ、私はカナダのノーザンテレコム社に半年の研修に旅立つ。
　割り付け改良はメモリ枯渇対策に貢献したと思っている。この時点（リリーズから十数年）ですでに枯渇が問題になっていた。新サービス導入でメモリを急速に消費していた。グラフを描くとあと数年だった。しかし、初代の割り付けは、とんでもない「どんぶり」だった。できるだけ割り付けを変更したくなかったからだろう。充分すぎる余裕をとっていた。パッチのための領域も大量に確保してあった。＊指定なら自然に詰めて配置される。
　さらなるメモリ削減が必要になり、後輩たちは苦労していた。寿命三十年には、隠れた細かな工夫の積み重ねがあった。