バグが多く品質面に問題がある。

IBM は半年かけて直すと公示しているが発表直後から
多くのバグを抱えていることになる。

見た目の印象が良くない。

操作性に加えて横方向に押しつぶしたようなフォントの表示は
お世辞にもよいとは言えない。

クライアント／サーバー・モデルの問題を抱えたままである。

20年前はまだPCは高価であったのでクライアント数は多くなかったが
クライアントＰＣが個人にも多数普及している現在では
配布や保守、さらに初期コストも維持コストもかかる
クライアント／サーバー・モデルは旧時代の産物であり
採用を検討する対象の論外である。

次はJavaの終焉か ?

SunMicroSystems が消滅しJavaもPHPなどに押されて急速に
利用度が衰えている。 JSP&Servletは実用的に学習や運用が難しすぎたのに
パフォーマンスが良くないときているので
Javaの開発プラットフォームも少なくなるだろう。
次に来るのはPHPではない。
オブジェクト指向のJavaScriptつまりJQuery、つまりは
JavaScript だけが生き残っていくだろう。
その状況下でJava製品が生き残っていくのは難しい。
Java でさえ確実に終焉に向かっているのだ。

移行ができない。

CA/400で作成したデータ転送記述(.TTOおよび.DTF)を IBM ACS 用の
TDFX に移行するのもかなり難しい。
IBM が用意した移行ツールにバグがあり移行は無理という意見が多数を占めている。
移行を難しくしている原因のひとつにCA/400のデータ転送定義(.TTOおよび.DTF)
が UNIコードで作成されていることにあるかもしれない。
ただのUNIコードではなく UTF-16LB: CCSID : 1202 というあまり馴染みのないUNIコードである。
一般的にUNIコードと言えば HTMLで最も多く使用されているのが UTF-8 である。
次に多いのが UTF-16 (=UTF16GE: CCSID:1200) であるが
CA/400 は CCSID:1202 という特殊なUNIコードを採用しているため
移行も難しくしているのだろう。

CCSID:1202がどれくらい特殊であるかというと、まず IFS の WRKLNK は
CCSID:1202 をサポートしていない。
つまり IFS のストリーム・ファイルには CCSID:1202 は予期していなかったことになる。
次に EBCDIC とのインターフェースを考えると重要になるコード変換APIである
iconv も CCSID:1202 をサポートしていない。
弊社では特殊なテクニックを使ってCCSID:1202の変換に成功したのだが
一般的にはCCSID:1202 は EBCDIC には変換することができない。

PCオーガナイザーが使用可能である。

海外輸入製品ではPCオーガナイザー(STRPCO)を使える製品はない。
PCオーガナイザーが使えるのはAutoWebだけである。

サーバー・サイドのデータ転送が使える

昨今のWin10問題で CA/400が使えないということで
それではこの際、Web化も含めてWebフェーシングに移行したいと
言うことになった場合、従来のPCOMMやCA/400によるデータ転送を
そのまま残していたのではPCOMMやCA/400をいつまでたっても廃止することができない。
しかし AutoWeb であればクライアントPC(Windows)にあった
データ転送定義(.TTO, .DTF)をサーバー(IBM i)のIFSに
移すだけでサーバー・サイド(IBM i)だけのデータ転送を行うことができる。
もちろん新規の転送定義もサーバー側に作成することができる。