変換できます。

ユーザー・プロフィールでサイン・オン後に表示されるメニューは CLP, DSPF形式および PNLGRP形式のいずれであっても正しくツリー構造メニューに変換することができます。

但しメイン・メニューから下位のメニューにさらに展開されるには、そのメニュー項目のテキストに「メニュー」または「ﾒﾆｭｰ」という文字列が含まれていなければなりません。 これ以外の文字列を含むメニュー項目があってもユーザー設定により展開できるようにすることもできます。

可能です。

ご指摘のとおり、System i 上では上位のメニューに戻って選択をやり直さないと別のメニューの項目に移ることはできませんが AutoWeb ではツリー構造として表示されている以上、ユーザーがそのような移動操作を行ったとしても、内部では 5250エミュレータ上での上位のメニューに戻る操作が人手に代わって行われています。

できます。

動作させるだけで HTMLテンプレートが IFS に保管されますので個別の変更が必要な場合はHTMLテンプレートを変更することによって背景色や文字コードも変更することができます。 AutoWeb の変換の省略値を変更されたい場合は、画面と動作についての設定ファイルが用意されていますので、ユーザーの好みに応じて設定ファイルを変更すれば可能です。

メニューの項目間の移動は、ユーザーの操作に応じて内部では上位に戻るために、CF03キー等が押されています。 しかしユーザーに応じてこのような機能キーが統一されていない場合もありますので動作の設定ファイルに記述を追加できるように配慮されています。

DDS上でこれらの GUIコントロールが定義できることをご存知の方も少ないのですが DDS で定義されるこれらの GUIコントロールも正しく HTMLのコントロールに変換されます。 逆な言い方をしますと DDS でこれらを定義しておくと HTMLのコントロールとして使用することができます。

ただしコンボボックスは DDS の定義にはありませんが VALUESキーワードと TEXTキーワードを定義することによってコンボボックスを生成することができます。

できます。

Ajax を利用してコンボボックスの候補を与える CGI が別に必要となります。

ブラウザ上で POPUPウィンドウとして正しく表示されてドラッグしてマウスで位置を移動させることができるようになります。 従来ではこのような本来の POPUPウィンドウを表示させることは HTMLの仕様上、とても難解なものでした。 しかし AutoWeb では Ajax を組み込むことによって、表示だけでなく振る舞いも洗練された動作に仕上がっています。

画面罫線はサポートされていません。(無視されます)

漢字専用フィールドや数字や半角カナなどの属性の妥当性もその場で検査されます。 特にオープン・フィールドの桁数オーバーについてご懸念されるのは無理もありません。

しかしオープン・フィールドは FOCUS が離れた途端に Javascript によって即時に検査が行われるようになっています。

FiledExit による数字の右寄せや後続文字の消去、FOCUS の移動も、そのまま再現されています。 十字キーによる項目間の上下移動も可能です。 機能キーもボタン操作以外に直接、ショート・カットとして使用することができます。

はい。

エラー・メッセージは alert ダイアログとしてわかりやすく表示されます。 もちろんエラー箇所へのカーソルの位置づけやエラー・フィールドの反転イメージによる表示も再現されます。

「戻るボタン」や「Ｘボタン」も「仮想対話式環境」によってサポートされています。「戻るボタン」は F12キーとして扱われますし、F12キーが定義されていない画面においては「戻るボタン」は使用不可となります。 (disable としてグレー表示されます。)

御社の事情で戻るキーが F12キー以外であっても設定ファイルにユーザー独自の機能キーを登録することができます。 「Ｘボタン」が押された場合はジョブは自動消滅して (ENDJOB) CGI が永続に待機することはありません。

このように「戻るボタン」と「Ｘボタン」の両方がサポートされているのは Alaska だけです。

できます。

Web化においてはご指摘のように単純に画面だけを HTML に変換するだけでは真のWeb化とはいえません。 EnterpriseSever はこの点に着目しています。 AutoWeb では フォーム認証で 装置名をCookieに保存する仕組みになっています。一度だけ装置名を登録すれば、次回からは装置名はCookieによって自動的に表示されます。 インターネット経由の遠隔地であっても問題ありません。

PCの名前を変更するのは簡単ですので、このような方法で明示的なジョブ名を与えることができます。 このように クライアントの名前を認識できる HTTPサーバーは Alaska だけです。

中断メッセージ(SNDBRKMSG)についてはサポートしていません。

子スレッドのMSGWの障害は自動的にキャンセル応答となりAlaskaのエラー画面が戻りますので、フリーズ状態になることはありません。

AutoWeb でも、STRPCCMD を従来どおりに利用することができます。 STRPCCMD はクライアント／サーバー・モデルである PCOMM やClientAccess のクライアント・モジュール上でのみ実行可能と思われがちですが実はそうではありません。 STRPCCMD の可能性は PCOMM や C/A のみに依存しているのではなく、エミュレータの機能そのものに依存しています。

AutoWeb では、この STRPCCMD もサポートすることに成功しました。

以下の機能は制約事項として、サポート外となります。

反転イメージによる画面構成

反転イメージを組み合わせて、ロゴや大きな文字列を表現している場合がありますが、 このような反転イメージは無視されます。 (エラー・フィールド等の反転イメージは有効です。)

System-Requestキー

システム要求キーの動作はサポートしていません。

ATTNキー

アテンション・キーの動作もサポートしいません。ただし今後のサポート予定があります。

その他

弊社で予想できなかった画面構成についてサポートされていない場合があることをご承知ください。 特殊環境や条件についての運用が必要である場合は弊社までお問い合わせください。

他社のWebFacing はTELNET による解析であり、AutoWeb は 5250ストリームを解析している
違いがあります。
これは、他社のWebFacingツールは、まず TELNET 端末として起動して画面イメージだけを読み取ります。
つまり画面イメージの投影を捉えているだけなので出力される文字列と入力フィールドがわかるだけです。
入力フィールドはわかっても属性はわかりませんので、数字の入力や漢字の入力が
可能であるかは一切、不明です。
そこで SE が元の画面を丹念に調べて人手によって調整を加えていくことになります。
ひとつの画面を HTML 化するのには、莫大な解析と修正する手間と時間が必要になります。

これに対して AutoWeb は 5250ストリームをリアル・タイムで解析しますので
従来の5250エミュレーターと原理的には同じです。
人手による変換の必要性は全くありません。

可能です。

実際に混在させて利用されている例もあります。
例えばオブジェクトしか存在しない、パッケージ・プログラムも Web化させて利用している例もあります。
( AutoWeb ではソースは必要ありません。)

Form 認証を使えば、各PCクライアント別に任意の装置名(ただし10桁まで)を命名してつけることができます。
装置名は Cookie として、そのPCクライアントに保存されますので最初だけ入力するだけの
簡単な操作で装置名を利用することができます。
これはどのような遠隔地やセグメントに関係なく利用することができます。

できます。
DDS ソースには IBM のよって提供されている HTMLキー・ワードがあります。
これは例えば、

 A                                 11 63HTML('<IMG SRC="/AS400-NET.USR/IMAG+
 A                                      E/AUTOWEB.GIF">')                   

のようにして、HTMLキー・ワードとして DDSソースに画像を示すイメージソース・タグ( <IMG SRC-)
を追加すればよいことになります。
HTML タグを含む DSPF をコンパイルして作成すれば 5250 エミュレータ画面上では
HTML タグの部分は無視されて、これまで同様、5250画面が表示されますが
AutoWeb を使って表示すれば HTMLタグの部分が挿入されて表示されます。
これは IBM によるDDS の拡張機能であり、今すぐどなたでも利用することができます。

AutoWeb であれば、情報を隠しフィールドで拡張することもできます。
無制限にというわけには行きませんが情報の拡張によって機能を高めることができます。
もちろん 80*24画面だけでなく 27*132 画面もサポートしています。

複数セッションの起動も問題はありません。
IE8 〜 や FireFox で複数セッションの起動が問題視されるのは、
複数個のセッションを起動したとしても、それより個数の少ないプロセス( .exe )だけが起動して、
複数のセッションを数少ないプロセス( .exe ) で共有して利用します。
このとき 通信 socket 識別子までもが共有されてしまいますので、
あるセッションの結果の画面が別のセッションの画面に表示されてしまう、という
いわゆる「入れ違い現象」という障害が発生してしまいます。
これは通信を保持( Keep-Alive )しただけでは避けることのできない、
Webでの「プロセス共有問題」という有名な大問題となっています。
他社製品で 「プロセス共有問題」が、ほとんど解決されておらず、
この問題への対応を語らずに伏せたままで販売していますが、
いずれ近いうちに「プロセス共有問題」は大きな問題となることは間違いありません。
AutoWeb では、速くからこの問題を重要視し、この度、「スマート・コネクション」という
新たな仮想的な接続方法を確立して、「プロセス共有問題」を解決しました。
「スマート・コネクション」とは、通信は直ちに切断されますが、
必ず元のジョブに戻って、再接続されることが保証される仕組みのことです。
「スマート・コネクション」によって AutoWeb という、WebFacing だけでなく
セッション管理も安全で確実な接続を可能にすることができるようになりました。
これは高度な基礎技術を研究開発してきた成果の結実といえます。

いいえ、AutoWeb は EnterpriseServer の主要機能の一部として無償でご利用頂くことができます。
それゆえ、複数の機能を組み合わせて活用していただくことが可能となります。

申し訳ありません。機能の分割をして販売することを行なっておりません。