必要ありません。

EnterpriseServer によって開発される Webアプリケーションは、完全にネィティプな CGI ですので、別途にPCサーバーを用意する必要もありませんし、実行環境の PC に ブラウザ (IE = InternetExplorer) だけあれば十分です。

RPG で開発されるのであれば RPGコンパイラーが導入されている OS でOS V5R2M0 以上であれば十分です。 EnterpriseServer は Java や WebSphere を必要としません。

また独自の HTTPサーバーである 「Alaska」 が提供されていますので IBM HTTPサーバーが導入されていない環境でも動作させることができます。

必要ありません。

EnterpriseServer は純粋な CGIアプリケーションを実行しますので500 CPW もあれば十分です。 例として 2000 CPW で 1万クライアントからの受注入力を 12時間稼動で運用している例もあります。

さらに HTTPサーバーである「Alaska」は Ver4.0でリニューアルされてパフォーマンスが大幅に向上しています。 Ver3.0 では従来の約250% アップの速度向上、さらに Ver4.0 では Ver3.0 の 150% 以上のパフォーマンス改善が図られました。

HTML や JavaScript もある程度学習しておいていたほうが良いのは事実ですが、Ver5.0 以降 の TONAKAI/2.0( CGI への移行モジュール) と HTMLデザイナーを使えば特に HTML や JavaScript を知らなくても HTML の生成や編集を行うことができます。

TONAKAI/2.0 は DSPF を HTML に変換することができますし、HTMLデザイナー は ブラウザ上でHTML のボタンやテキスト、入力ボックスなどのオブジェクトを移動して配置等を編集することができます。

Web化の目的は概ね次のとおりです。

• 24×80 桁の画面制限を撤廃して画面の情報量を増やしたい。

• グラフィカルで美しい画面にしたい。

• HTML であれば コンボボックス や ラジオ・ボタン等で説明不要の画面となる。

• クライアントに5250エミュレータ等のモジュール配布の手間とコストを削減したい。

• 通信の悪い状況でも安定した業務環境にしたい。

• 通信コストを削減したい。

これらすべてを満足しているのは、やはり CGI による Web化だけです。

通常のユーザー作成の CGI の動作が遅いのは、ほとんどの時間が EBCDIC/ASCII の変換に費やされてしまうからです。 また HTML をテンプレート化しても EBCDIC として保管しているのであればこれもパフォーマンスを低下させる原因となります。

EnterpriseServer では HTMLテンプレートは ASCIIコードとして IFS に保管され、唯一データだけがEBCDIC から ASCII へ変換されるだけですのでコード変換によるオーバーヘッドを最小限に抑えることができます。 しかもそのコード変換API も独自のものであり OS API による変換の 2倍以上の速度で実行されます。 さらに HTTPサーバー上での完全なロード・バランス(負荷分散)が行われ、内部ではすべての関数の呼び出しはポインターによる高速の呼び出しに変更されています。

このように目に見えない部分にまでもつねにパフォーマンスの改善が図られており、快適なパフォーマンスをお客様に提供できるよう配慮されています。 「Webはパフォーマンスが命！」それが EnterpriseServer の信条です。

EnterpriseServer の動作 CGI はバッチCPW のみを使用しますので対話 CPW = 0 の System i でも動作させることができます。 これに対して仮想端末を使用している WebFacing などでは対話式 CPW が使用されています。

DOS/V から Windows95 が普及し始めたころを思い出してください。 ファイルのコピーなどは DOS コマンドによるほうが速いと言って、技術者は好んでDOS コマンドを使用したものです。

しかし Windowsエクスプローラが普及した今日では DOS コマンドを使ってファイルをコピーする人は皆無ではないでしょうか ? これは操作が速いという理由ではなく、

• 誰もが見やすくわかりやすい

• 見栄えがきれい

という点がグラフィカルな Windowsエクスプローラのほうが圧倒的に優れているからです。

また私達、System i の開発者は Ftp というと DOS窓を開いて Ftpのコマンドを DOS上で打鍵しますが、Webデザイナー達のあいだでは、このような Ftpコマンドを直接、打鍵するような人はいないのも事実です。 既にほとんど(全員と言っても過言ではありませんが) の Webデザイナーは Webコンテンツをサーバーにアップロードするのには FFFTP や NEXTFTP などのツールを利用しています。

このように考えていくと Web化の対象には例外はありません。 すべての業務を Web化の対象と考えるべきではないでしょうか ?

数字の妥当性検査は JavaScript のライブラリーが自動的に数字の妥当性検査を行いますのでユーザーによる検査は必要ありません。

また Field-Exit や Tab機能などの 5250独自の機能は JavaScript のライブラリーとして EnterpriseServerに同梱されていますのでご利用になることができます。

CLP と言えどもプログラムには変わりはありませんので、CLP も CGI として利用することができます。

弊社別製品の「Spoolライター」をご利用になれば印刷スプールはその場で動的にPDF 化してWeb公開することができます。 元の印刷プログラムは一切、手を加える必要はありません。 SpoolWTR のコマンド CVTSPLF を実行させる小さな CLP を作成するだけで済みます。 元の印刷プログラムは RPG III/ILE-RPG , QUERY/400 であっても構いません。

申し訳ありませんがランタイム版は廃止とさせて頂きました。 (既存のランタイム版ユーザー様はそのまま継続してご利用になれます。)

これは例えランタイム環境であってもディバッグが必要なケースがあるからです。 ご了承のほどお願い申し上げます。

弊社では OS V3R7M0 〜 V5R4M0 , Ver6.1 〜 Ver7.3 までのすべての OSリリースのテスト環境を用意して、検証できる体制にあります。(EnterpriseServer の対応は V5R2M0〜)

また新しい OS がリリースアップされると、いち早く検証するよう体制を整えております。 製品内部では弊社での製品の責任の範囲でできるだけ対応できるようにとさらにパフォーマンス向上のため、できるだけ OS API への依存性を少なくしています。

例えば EBCDIC/ASCII 変換でさえも API: QDCXLATE ではなく独自の高速の API を開発して提供しています。(外字だけは QDCXLATE によって変換されます) TCP/IP は OS に依存していますが IBM HTTPサーバーが導入されていない環境下であっても動作いたします。

IE などの Windows製品におきましては Microsoft社との年間契約によっていち早く次期 Microsoft製品を入手して検証できる体制にあります。