ここに紹介するのは１０万件の中から任意の ２００レコードを抽出して表示するサンプルです。
初期画面が表示されたら 1 〜 100000 のあいだの任意の数字を入れて投入して表示されるまでの
パフォーマンスを実感してください。
実行しているのは弊社のSystem i CPW 500 OS V5R4M0です。

最近は、Webソリューションの実行は遅いものであると思われがちであり、実際、
非常にパフォーマンスが悪くて現実の運用に耐えない、というトラブルが増えてきています。
この原因の大半は ODBC や JDBC 、ストアド・プロシージャーをその製品が利用しているためで
System i のデータ・ベースに ODBC やJDBC, ストアド・プロシージャー ( RPC )でアクセスするのは
実用上、全く向いていません。
ご存知のようにSystem i の基幹業務では 数十万件レコードを持つデータ・ベースは珍しくはありません。
ところが Webソリューションの開発元は ODBC や JDBC でもSystem i の DB2/400 にアタッチできるので
動作する、販売することになります。
ODBC や JDBC を Webソリューションの技術として採用している背景には ODBC や JDBC であれば
SQLサーバーや他のほとんどのデータ・ベースにアクセスできるため、ひとつの技術だけで、すべての
プラットフォームで通用するものとして、あらゆるプラットフォームに同じアーキテクチャーの製品を
売り込もうとしているからに他なりません。

○○○○/400 という語尾に「/400」を付加している製品は他のプラットフォームのものを System i
つまりAS/400 にポーティングしたことを表しています。

ところが ODBC や JDBC では大量のデータ・ベースからレコードを抽出しようとすると
全件の数十万レコードをすべて読みとってからレコードかが抽出されます。
またレコードを一件でも追加しようとしても、また全件にキーの重複がないかどうか検査してから、
初めてレコードが追加されます。
ユーザーの操作は速くて数十秒、遅ければ 5〜10分かかることも珍しくはありません。
Query/400 のジョブが大量に実行されているのと同じだからです。
もちろん CPW も大量に消費されます。

System i の良好なパフォーマンスを知っている System i のユーザーはこれには驚くはずです。
ところがベンダーもこのことは良く認識しているようで製品紹介では決してODBC や JDBC を
採用していることは決して自ら進んで公表しようとしませんし、むしろ隠しているようにも見えます。
「実行は遅い」とはどこにも書いていませんので、確かに遅くても許されるのかも知れませんが
お客様のためにほんのわずかでもパフォーマンスが良くなるようにとの機能改善に努力している
弊社から見れば、これはユーザー様への背信と見えます。