Web適用業務が 5250エミュレータと最も異なるのはステートレスである、と
いうことである。
5250エミュレータによる対話式の適用業務では RPG の EXFMT 命令によって
同じJOB 上で継続して実行されるので、RPG の中で使用していたフィールドの値や
QTEMP や *LDA の情報も保持されている。
ところが Web適用業務では、そうではない。
Web適用業務としての CGI は HTML を出力すると、直ちに LR終了してしまう。
従って次に起動されてもフィールド値は保持されていない。
このような実行形式のことを「ステートレス」と呼ぶ。
また CGI は次のように HTTPサーバー : ALASKA の配下の、AURORA_EGN (オーロラ・エンジン)
という子ジョブのどこかで、実行され、次に呼び出されたときも同じ AURORA_EGN 上で
実行される保証はない。

従って QTEMP や *LDA は利用することはできなくなってしまう。
しかし同じ情報を保持したいという事情は少なからず出てくるものである。
そこで意図的にフィールド情報だけでも残しておいて次回に検索して利用するという機能が
必要となってくる。
このような機能のことを「セッション管理」と呼ぶ。
セッション管理をサポートしているという他社製品もあったが、これはブラウザから受け取った
フィールド情報をファイルとして保管しておくという単純な処理構造のために
セッション・ファイルが莫大に次々と増大していって DISK を圧迫する結果を招いてしまう。
一度ご欄になればセッション・ファイルの莫大な残骸が残っていて驚くかも知れない。
このメーカーは当初はセッション管理を有利なものとして大々的に唄っていたが今では
すっかりなりを潜めてしまっている。
RPG# のセッション管理について紹介しよう。
RPG# のセッション管理は極めてシンプルで、簡単に問題を解決している。
まず CGI が同じ子ジョブに戻らないという問題であるが、HTML ソースのどこかに

<input type="hidden" name="AURORA_EGN" value="######">

というタグを追加して忍ばしておくだけで十分である。
このタグを HTMLテンプレートに保存しておけば RPG# は HTML 出力時には value 値に
自分が実行した AURORA_EGN のジョブ番号を更新してからブラウザへ出力してくれる。
次に HTTPサーバー : ALASKA は、このジョブ番号の記述をブラウザから受け取ると
元のジョブ番号の AURORA_EGN へ制御を渡して実行させるのである。
このようにして 上記の AURORA_EGN のタグが埋め込まれている処理は同じジョブ上での
継続が保証されるのである。
この機能はもちろん他の Apache や IBM HTTPサーバーではできない。
Alaska だけが持つ機能である。
このことによって QTEMP や *LDA の使用が可能となる。
Wizard によって自動生成する場合には「セッションを維持する」にチェックを入れて
生成すると上記のタグは自動的に組み込まれる。

次にフィールド値の保持であるが SET_SESSION と GET_SESSION というプロシージャーが
用意されている。
最初に SET_SESSION とは、

    SET_SESSION(ユーザー・キー(*):セッション・データ(*):長さ(10I0)) 

として定義されており、

    CALLP SET_SESSION(%ADDR(SSNKEY) : %ADDR(SSNDTA) : LEN)

のようにして指定して実行する。
ここで SSNKEY とはセッションを識別するためにユーザーが指定するキーであり、
SSNDTA とはセッション情報として保持したいデータである。
次に

    GET_SESSION(ユーザー・キー(*):セッション・データ(*):長さ(10I0)) 

を使って、例えば

    CALLP GET_SESSION(%ADDR(SSNKEY) : %ADDR(SSNDTA) : LEN) 

によってセッション・データ SSNDTA をいつでも復元することができる。
また HTML には非表示で

    <input type="hidden" name=SESSION value="################################">

というタグを用意しておく必要がある。
SET_SESSION によってこのタグの SESSION の value値には 32桁のバイナリー・コードが
保管されて GET_SESSION によってセッション情報を取り出すときに唯一、一意的な
キーとして利用される。
ここに書き込まれる 32桁のバイナリ・コードは GUID ( Globally Unique Identifier) と
呼ばれる API による自動発生によって得られる値であり、IBM によって世界中で
絶対に重複が起こらない一意的な値として保証されている。
OS の中でも実はプログラムやサービス・プログラムに、このような一意的な GUID が
識別子として登録されており、GUID によってプログラムは呼び出されているのである。
CALL MYPGM として実行したときに自分の呼んだプログラムではない別のプログラムが
呼び出されてしまったという経験は無いはずである。
このように 信頼性の高い識別子 GUID を RPG# はセッション管理に利用している。

ところで RPG# によるセッション情報はどこに保管されているのかいうと
ライブラリー : QRPLOBJ に最速にアクセスできるオブジェクトとしてのユーザー待ち行列
( *USRQ ) として保管されている。
ライブラリー : QRPLOBJ とは System i の「ゴミ箱」のような存在のライブラリーであって
CRTPGM , RSTOBJ, ... によって上書きされたオブジェクトは BACKUP のために
QRPLOBJ に一時的に保管され、次の IPL では QRPLOBJ の中身は自動的にクリーンアップされる。

このようにして RPG# のセッション情報は最速にアクセスできて、重複のない唯一絶対的な
データとして保管される一方で、再編成の必要のない情報として管理の手間もなくしている。
これこそが RPG# の提唱するセッション管理である。