先の｢37. ACSが複数セッションでフリーズする｣で取り上げたように
ACS(=IBM Access Client Solutions)をもう詳しく調べてみた。

ACSは複数セッションを起動するタブ・ブラウザのようにタブ表示で
表示される。
これはまず便利なようで不便である。
ユーザーが複数セッションを起動する理由は２つのセッションの画面表示を
比較したい場合が多い。
タブ表示になってしまうとつねにどちらかひとつだけしか表示されないので
折角、２つのセッションを起動しても比較することができない。
また筆者は一台のPCに対して2台のディスプレイ(表示装置)を保有していて
2台に表示したくても表示することができなくなってしまった。

さらに根本的な問題としてACSは複数セッションを起動したとしても
中身のプロセスはひとつだけで活動している。
タブ・ブラウザもそうであるがさすがにタブ・ブラウザとは違って
通信のSocket識別子は複数、保有しているようで
別々のセッションとして使用することができる。

しかし問題はここからで複数セッションのうちひとつのセッションで
プログラムが永久LOOPなどで暴走したとする。
プロセスがちゃんと複数に分かれていれば、もうひとつのセッションから
暴走をキャンセルなどで止めることができる。
これは読者も何度も経験のあることだと思う。

しかしブロセスがひとつだけとなると複数セッションのうちひとつでも
暴走すると全体が暴走することになり止めようがなくなる。
これはかつての Win95がよく暴走したのと同じ原理である。

またフリーズしたときにWindowsのタスク・マネージャーで
ひとつのセッションだけ強制終了させると他のすべてのセッションも
終了してしまうことになる。
メモリが高価で節約しなければならない時代ならいざ知らず
豊富にメモリを活用できる時代にあったひとつのプロセスで
複数セッションでタブ・ブラウザにしてしまったことは
現在、ブラウザで｢複数セッション問題｣を生んだのと同じ問題を
わざわざ生むような仕掛けをしてしまっていることになる。

今までのPCOMMやiAccessで役に立っていた機能をわざわざ
トラブるように変更してしまうのはいかがなものだろうか?

IBM のJava開発部隊はなぜACSをタブ・ブラウザとして開発したのだろうか?
確かにブラウザのタブ化は流行であったが同時にタブの入れ替わり問題、
つまり複数セッション問題が大変な問題になつてしまったことは
ちょっとした技術者にはよく知られていた。

IBMのJava開発部隊はあまり考えずに技術不足のままに開発し
受け入れるIBM側もよくよくテストせずに検収としたようである。
しかも十分なテストもされていない。
IBM Java部隊は素人開発部隊と揶揄されても仕方ないだろう。
IBM iのOSに比べて品質が低すぎる。