パネル・グループはWebに向いている

過去に何度も説明しているようにi5/OSのユーティリティのインターフェースは
95%以上はパネル・グループ(*PNLGRP)によってできている。

そして調べていくうちにわかったのはパネル・グループ(*PNLGRP)は非常に
Web化に向いているという事実である。

その理由は次のとおりである。

(1) HTMLと同じタグ言語である

パネル・グループはわずか26～30個以下の種類のタグ言語で構成されており
非常にやさしく習得ができる。
行・桁の位置の概念はなくOSが自動的に最適なレイアウトを
してくれる。
WRKOUTQの画面を24*80で見ても27*132でも見ても違和感は
なかったはずである。
これもHTMLと同じである。

(2) イベント駆動型による開発である

パネル・グループを動作させようと思うと自然とイベント・ドリブンによる
書き方になる。
つまり最初は画面を出力するだけで終わり。

次はイベントが発生したときのイベント・ハンドラーを
呼び出すだけでよい。
つまり最初に画面だけを表示したプログラム(=これを仮にメイン・ルーチンと呼ぶ)
とイベント・ハンドラーとは何の変数も共有しない互いに独立した関係である。

(3) セッション管理の必要がない。

ウォーター・フォール型のプログラムの場合はHTMLやDSPFの表示の前後でも
同じプログラム内であるので変数値などの情報が維持されなければならない。
すなわちセッションが維持される必要がある。(=セッション管理が必要)
これに対してイベント駆動型のパネル・グループでは各々のイベント処理だけで
処理が完結するのでセッション管理の必要がない。
　　これはまさしくWebにおけるCGIの動作と同じである。

　　もう少し具体的に説明するとあるHTTPサーバーのスレッドで画面を表示したものを
実行すると別のスレッドで処理されてもよいのである。
さらには画面を表示した後も何のプログラムもエンド・ユーザーの入力を
待機していない。この次にエンド・ユーザーが入力したときに初めて
イベント・ハンドラーなるプログラムが呼び出されて実行される。
これは大量の入力処理にも向いているしWebシステムの目的とする理想的な型式である。

(4) 画面サイズの制約がない。

パネル・グループ(*PNLGRP)もコンパイル(CRTPNLGRP)のときには24*80を
超えてはコンパイル・エラーとなるではないかというご意見はあると思うが
実はパネル・グループ(*PNLGRP)は基本的に画面サイズの制約はない。
よくIBM iのユーティリティで画面の右下に「続く..」とか「終わり」という
表示を見たことがあると思う。
あれは実際画面の定義は後ろまで続いていてi5/OSのほうで表示を
制約しているに過ぎない。
横方向にしても画面項目はひとつの画面だけでも横方向に最大50個まで
定義することができる。
画面の大きさではなくフィールドの個数で制限しているだけである。
しかし実際には横方向はそのうち少しずつ画面に収まるように
選択して表示しているだけであって決してサイズでの制約は
加えていない。
設計者は将来に備えて非常に柔軟な構造としていたのである。
従ってパネル・グループ(*PNLGRP)には基本的な画面サイズの制約はないのである。

　…どうだろうか?
HTMLと親和性があるだけでなくイベント駆動型による開発であり
セッション管理もしなくてよい、CPUの消費は最小限で大量の竜力処理に
向いている。まさにWebシステムのための処理構造である。
IBM iの処理能力を最大限に引き出すことができる。

これこそをWeb化しない手はないだろう。
パネル・グループこそ最も理想的なWeb化の対象である。