実験装置が完成する２年前の平成６年１月稼働し始めた計算機システムは、シミュレーションによる実験装置の細部のデザインとともに解析プログラムの準備などに使われた後、平成８年度から実際のデータ処理に使われ始めた。このシステムの概略構成を図１に示す。データサーバーとなるマシンは、負荷分散のため複数のテープドライブ、磁気ディスクへの接続が必要な上、分散配置されたWSへの複数のネットワークでの接続など、多くのI/Oポートを必要としたため、大型計算機(VPX210/10S)を導入した。そのため実行プログラムはWSと共有できず特別のものを用意する必要があった。また、水冷装置保守のための停止などが必要となり、信頼性の高いシステムではあるが、365日24時間の稼働は原理的にできない構成になっていた。また、データーサーバーとCPUサーバーとなる分散配置されたWSの間は非常に高速の接続が必要と考えられたため、理論性能1GbpsのUltraNETを導入したが、あまり普及していなかったこのネットワークはトラブル続きで安定稼働とはほど遠く、基幹システムを構成するネットワークには向かないものであった。そのため、データサーバーとの接続ではFDDIを主に使うようになり、繁忙期にはI/Oネックとなって処理が追いつかないことがたびたび起こった。
図１ 移行前システムでの分散型の構成
リアルタイム処理の際のデータの流れは図２のように行われた。５種類の異なるデータ解析プログラムが動かなければならなかったが、共通の処理(TQREAL)は最初に行って各解析の負担を減らすようにデザインされた。それでも処理の遅い解析は並列に実行する必要があり、データの順序は維持する必要もあったので、入出力のためのバッファーのプロセスなどを含めて、１台のデータサーバーと10台のWSに分散配置された総計で約100のプロセスが協調して動かなければならないという事態になっていた。この中の１つのプロセスでも処理に失敗した場合、プロセス間の相互依存性が複雑で、その復旧は難しく、エキスパートが２４時間電話を受け付けられる状態になければならなかった。それでもなお復旧できなかった場合は、バッファーに残っているデータやテープ中のデータから過去にさかのぼり、すべてをやり直すということもたびたびあり、手間のかかる信頼性の低いソフトウェア構造となっていた。
また、MTL内のファイルの配置は独自のデータベースで管理されおり、磁気ディスク上のファイルシステムとは独立したものであったため、大きな出力があるプロセスは直接テープに書き込む必要があった。そのため、テープドライブの競合をさけるための特別の配慮や調停が必要であり、ユーザーは意図的、計画的にディスク上のファイルをテープにバックアップする必要があった。
図２ 分散型システムでの並列処理の様子