TONAKAI/2.0 で SPECIAL ファイルがサポートされて変換率は大幅に向上しました。
ただし DSPF から HTML への変換は、お客様独自の記述によって弊社で予想できなかった
ような場合は正しい HTML に変換されない場合が予想されますが、結果の HTML を
HTMLデザイナー を使って簡単に編集することができます。

TONAKAI/2.0 では RPG の DSPF は装置 WORKSTN から SPECIAL に変更されます。
SPECIAL に変更することによって CGI で DSPF (SPECIAL) に対して READ/WRITE が
実行されるとOS400 が EnterpriseServer が提供している「HTMLDVR」という名前の
プログラムを呼び出して、DSPF の入出力バッファーを「HTMLDVR」に渡します。

「HTMLDVR」は HTML とのインターフェースの役割を果たしていて、CGI は READ/WRITE を
行うだけでHTML との入出力を行うことができるようになります。
結果的に RPG開発者はこれまでの DSPF と同じような感覚で READ/WRITE によって HTML を
やさしく扱うことができるようになりました。

米国の BBS (掲示板) で ユーザーが HTML という装置を IBM が提供して欲しいとあったことがきっかけでした。
つまり 装置 WORKSTN を HTML と書き換えるだけの機能が欲しいというものです。
これを実現できるのが SPECIAL ファイルです。

さらに調べていくうちに SPECIAL ファイルでも外部記述を利用できることが判明致しました。
これまでの CGI による Web開発ではユーザーはそのWeb化製品の独自のプロシージャーを学習する必要があり、
しかもフィールド個別に入出力を記述することが必要なため CGI ソースはどうしても冗長になりがちでした。
これに対して SPECIAL ファイルの (外部記述としての)利用は

• フィールド個別の記述が必要なく、READ/WRITE だけで HTMLを制御することができる。

• CGI の記述が非常に見やすくまとまったものとなる。

• 独自のプロシージャーをほとんど学習する必要がない。

• RPG III であっても CGI を作成することができる。

などの優れた点があります。

できます。

変換後はネイティブなHTMLになっていますので、24×80桁の制約はもはやありません。
自由に情報を拡張する事が出来ます。

いいえ。内部的なDSPFはバッファーとして利用されているだけですので24×80桁の制約はありません。

変換後のHTMLを修正してください。

あります。

TONAKAI/2.0 では 「HTMLデザイナー」 を使えば、HTMLのパーツとして構成している
入力ボックス、テキスト、････ などのオブジェクトをドラッグ＆ドロップで移動することに始まって、
コピーや削除、新規追加、プロパティなどの多くの機能があり、特に System i ユーザーのための
独自の HTML編集ツールですのでフィールドに対応した処理を行うことができるという画期的な
機能を持っています。

市販の HTML編集ツールでは学習に時間がかかりますが 「HTMLデザイナー」 であれば、
HTML に馴染みの無いSystem i ユーザーでもすぐに HTML の編集をビジュアルに
やさしく行うことができます。

ログイン機能がありますので、サインオンのためにダイアログを作成する必要はありません。
IPアドレスだけでアクセスすれば IE によるログイン・ダイアログが表示され、
そこで System i で使用していたユーザーとパスワードを入れてログインすることができます。

メニューに関しては移行することもできますが、Web上でわかりやすいのは左サイド・ペインの
ツリー構造によるメニューが流行であり、お奨めできます。

しかし残念ながら既存のメニューをこのようなツリー構造のメニューに移行する機能はまだありません。
リリースアップをお待ちください。
現在では手作りになってしまいますが弊社サイトの「ワークショップ」にメニューのサンプルが
ありますのでご参照ください。

すべてが 100 % というわけではありません。
例えば POPUPウィンドウからの戻り値の更新などは JavaScript によって
( 「ワークショップ」 の契約照会を参照) 戻り値を親画面に直接、書き込むようにしたほうが
パフォーマンスは圧倒的によくなります。

このようにやはり Webには適した方法がありますので、それを考慮されることをお奨め致します。

できます。

ユーザー別のライブラリー・リストや CGI 個別のライブラリー・リストも設定することができます。
また、TONAKAI/2.0 によって移行した CGI は常に同じ子スレッド上で動作しますので
QTEMP も利用することができます。

移行することができます。

SFL としての HTML にも READC, CHAIN, WRITE/UPDATE を行うことができます。 もちろん SFLCLR, SFLDLT, SFLINZ も同じ RPG標識で行うことができます。

できます。

TONAKAI/2.0 による仮想対話式環境は通常の EXFMT による待機と何ら変わることのない
自然な入力待機であり、 CGI は次のユーザーからの入力をスタック上で待機しています。

つまり見せかけではない本来の入力待機ですので COMMIT/ ROLLBK も何の問題もありません。

できます。

ご指摘のとおりセッション・ファイル等による独自のセッション管理であれば、
レコード・ロックを利用することはできませんが TONAKAI/2.0 で移行された
仮想対話式環境であれば EXFMT による待ち状態と全く同じですので、
レコード・ロックもそのまま利用することができます。

いいえ。

Webアプリケーションでは歴史的な難問とされているこの問題も EnterpriseServer では
「仮想対話式環境」として解決されています。
「戻るボタン」 や 「Xボタン」 はそこに存在している以上、「押すな」とは言うことはできません。

TONAKAI/2.0 で移行したWebアプリケーションは 「戻るボタン」 は F12キーとして扱われ、
「Xボタン」はF3= LR終了として扱われますので画面遷移の不一致は発生しません。

これは Microsoft社の支援を得て約半年の歳月を要して弊社が独自に解決を見出したものです。
System i にこれらの情報が伝わり、適切に処理されます。

また PC の電源が落ちたような場合でも iSeriesサーバー側ではタイマーが起動して一定時間経過後の
応答が無ければ自動的に CGI は終了される仕組みとなっています。
さらに、これらの終結処理は強制キャンセルではなく、正常な LR 終了ですので LR 時の演算も
適切に行われます。

できます。

PCクライアントに固定 IPを割り振っておけば EnterpriseServer の「遠隔装置名の登録」に
IPアドレスを登録することによって CGI の SDS情報には自動的に装置名が書き込まれますので、
そのままのロジックを使用することができます。

できます。

INFDS のこれらの値も SPECIAL ファイルに用意された HTMLインターフェースのプログラムが
自動的にこれらの値を更新しますので、これまで同様のロジックを生かすことができます。

RPG 標識による反転イメージは入力ボックスの背景色として移行されます。
カーソルの位置づけもサポートしています。

大丈夫です。

オーバーレイの WRITE 命令もそのまま使用することができます。

/COPY メンバーも変換対象として検索されます。

/COPY に EXFMT が含まれていれば、これも正しく変換されます。

DSPF ソース中にメッセージ・ファイルや他のデータ・ベース参照があれば、
それらはすべて漏れなく検索されて必要な情報が取り出されます。
たとえテキストや見出しをメッセージ・ファイルとしていても問題ありません。

変換されます。

エラーメッセージの表示は JavaScript の ALERT メッセージとして、
Windows ダイアログのように非常にわかりやすいメッセージに変換されます。
しかもメッセージ・ファイルを使用されていたのであればメッセージ・ファイルの
検索はそのまま継承されます。

SFLMSGKEY もサポートしています。

サポートしています。
マウスポインターを項目に位置づけて左ボタンを押して項目をフォーカスしてから機能キーを押すと、
その項目の位置が CGI の INFDS 情報として CGI に渡されますので、CGI 演算上では従来の
カーソル位置として、ソースを全く変更することなくカーソル位置を読み取ることができます。

このように TONAKAI/2.0 では SPECIAL ファイルとして DSPF も記述されていますので、
従来DSPF で行なっていた多くの機能のサポートが可能となりました。

いいえ、その必要はありません。

Javascript が数字フィールドに数字以外の文字が入力されたときは不正な数字として
ALERT メッセージを出力して入力を受付けないようになっています。
もちろん数字とは言っても 0-9, カンマ, 小数点, 符号, / などは正しい入力として扱われます。

余談ですが CGI でこのような数値の妥当性検査を持っているプラットフォームは他にはありません。
内部ではフィールドを取り出して途中でこのような不正が見つかるとエラーを出力するだけでは不十分です。
内部スタックは直ちに元の入力待ちの状態に戻されます。
これはあたかも入力されていない状態に戻るような処置が施されています。

これも数字の妥当性検査と良く似ているのですが、Javascriptによって漢字の両端の
シフト文字用のスペースが計算されます。

できます。

CGI は何も RPG-CGI を直接、呼び出す必要はありません。
CLP を CGI として呼び出して、そこから OVRDBF, OVRPRTF を実行して RPG-CGI を
CALL するようにすれば良いのです。
TONAKAI/2.0 によって移行された適用業務は仮想対話式環境によって、必ず同じ子スレッド上で
実行されますので OVRDBF, OVRPRTF などによる一時変更もそのまま維持されます。

RPGIIIによる開発は終了しました。

多くの適用業務は、そのまま機械的な作業のよって移行することは可能ですが、
構造的に5250エミュレータの世界と HTML の表示の違いがありますので単純に
すべてが変換できると言えません。
最も代表的であるのが POPUP-WINDOW の処理です。
Web 化すると単純な CALL 命令をそのまま実行するのでは正しくPOPUP を表示することはできません。

EnterpriseServer ではこのような POPUP を移行して単純に再現できる機能も持っていますが、
やはりWeb には Webなりの適した POPUP表示の手法がありますので是非、それらに移行することを
お奨め致します。

これは若干の手作業による JavaScript の組み込みが必要になりますが、Web ならではの最適な
パフォーマンスを得ることができるようになります。
作業はそんなに難しいものではありませんので、ご心配するには足りません。

System i のデータ・ベース内の漢字のシフト文字は HTML 上ではスペースとして表示されます。
逆にブラウザから入力すると漢字の前後にはシフト文字が自動的に挿入されます。
しかしスペースつきで表示されたフィールドを、そのまま SUBMIT すると前後に余計なスペースが
さらに増えてしまうことはありません。
これは漢字に変換したときに、前後にあるスペースは1桁ずつ除去されるような仕組みになっているからです。

もちろん漢字半角混じりのデータを投入して、シフト文字を追加した結果、初めてフィールド長を
オーバーするようであれば ALERT メッセージがブラウザへ戻されて入力は受け付けられません。
このような処理方式によって、エミュレータと同じような 入力の妥当性検査 が行われており、
漢字フィールドも適正なものに保つことができます。
ユーザーはこのために JavaScript を用意する必要もありません。

TONAKAI/2.0 の変換で生成されるHTMLソースに、AjaxによるCGIへのリクエストの
記述を加えることで、データベースからデータを取得することができます。
(Ajax とは、Javascript とXML による非同期通信のことです。詳しくは こちら で。)

あとは取得したデータを作成したコンボボックスの中に挿入することで、
動的にコンボボックスを生成することができます。

Ajax による動的なコンボボックスを生成する例をTechNetの
「Ajax サンプル 動的コンボボックスの作成」で紹介しております。

はいできます。
TONAKAI/2.0でサブファイルを変換した場合、スクロールバー付きのサブファイル
として変換されます。
また全一覧データをスクロールバーのみで閲覧するには、変換後のRPGのデータベース
の読み取りを SFLSIZではなく、EOF(ファイルの最後)まで読み取るように変更すれば、
スクロールバーが表示され機能キーを使用せずに閲覧することができます。

はいできます。
eStudio からの「既存業務のWEB移行」からの変換では１回の変換で１つのプログラムしか
変換できませんが、PCOMM で [ASNET.COM/CVTWEBSRC + F4] コマンドにより表示される
「CGIソースへの移行」画面で、プログラムに「*ALL」を指定するとライブラリー内のすべての
プログラムを一度にまとめてCGI変換することができます。

QTEMP や *LDA, COMMIT & ROLLBK も、そのまま利用することができます。
これは他社製品にはない TONAKAI/2.0 だけの機能です。
TONAKAI/2.0 では通信は、すべて論理的に、あるいは物理的にサーバー( IBM System i )と
接続が保持されていますので、一旦、接続を開始すると、ジョブ(セッション)が終了するまで
同じジョブ(セッション)上での動作が継続されます。
従って 5250 エミュレータと同じような処理を行ないますので、+LDA や QTEMP, CIMMIT & ROKKBK も
5250 エミュレータと同じように処理することができます。

これに対して他社製品ではセッション管理とは言ってもセッションによるデータ(変数値)が
保持されるだけであり、セッションが実行されるジョブは、毎回のように異なりますので
QTEMP, *LDA さらに COMMI & ROLLBK の処理は全くできません。
また、製品によっては莫大なセッション・ファイルの残骸が残ってしまい、DISK 容量を圧迫する
障害も報告されているようです。

TONAKAI/2.0 ではシンプルな変換であるため、相当、高い変換率を誇っていますが
どのような記述にも 100% 対応済みであるとは言い切れません。
お客様独自のコーディングがお客様社内では普通であっても
TONAKAI/2.0 では想定されていない、という場合も考えられます。
このためお買い上げ後、お問い合わせ頂ければ保守の範囲内として無償で対応させて頂くことが可能です。

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

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