サーバー管理メニュー

TCP/IP

LOG

HTTPサーバーの PORT番号は 80番が一般的です。
しかし既に IBM HTTPサーバーなどを使用しているために PORT= 80が使用済みである場合には
HTTPサーバー開始 (STRHTPSVR) は PORT= 3009 を初期値として割り当てます。
PORT=80 が空きであれば STRHTPSVR は PORT= 80 で開始されます。
(Alaska を重複して開始しようとするときも PORT= 3009となります。)

Alaska はVer3.0 よりTCP/IP通信の分散を行います。

従来型の HTTPサーバーでは CGIの結果としての HTML出力はいったんHTTPサーバーに戻されて、
HTTPサーバー自身がブラウザへ結果を戻す仕組みでした。
特にオープン系の HTTPサーバーでは CGIの出力は印刷出力と同じ形の｢標準出力｣ でした。
標準出力はPIPE処理を通じてHTTPサーバーに戻されてからHTTPサーバーがブラウザへ出力していました。
(実際、V3R2M0 では CGI の出力は印刷スプールに出力されていたのです。）

これは CGI自身が TCP/IP通信を持たないためと、出力記述をやさしくするための手段ですが
非常に無駄な処理を二重に行っていたことになります。
ブラウザへの入出力はすべて HTTPサーバーに集約されているため負荷が HTTPサーバーのみに
集中していました。
HTTPサーバーは CGI の出力を行うと同時に別のクライアントからの要求に同時に応える必要があるからです。
確かに HTTPサーバーはマルチスレッドとしての処理を行いますので、同時にこれらのことを行うことは
できるのですが、IBM i だけでなく Windowsなどでも複数の処理はやはり別々のプロセス(JOB)が
行うほうが、結果として圧倒的に速くなるのです。

[従来型のHTTPサーバー処理]

このような従来型の HTTPサーバーの仕組みに対して EnterpriseServer Ver3.0 ではCGI が直接、
ブラウザへ結果を送出するように大幅な改訂が行われました。
さらに Ver4.0 ではリエンジニアリングによって Alaska は
IBMの推薦する理想的なクライアント/サーバー・モデルへ再作成されました。

Ver4.0 からは Alaska は、クライアントからの要求データそのものも読み取ることはありません。
Alaska Ver4.0 ではブラウザからの要求があるや否や、直ちに子スレッド達に要求を処理するように
伝達するだけです。
Ver3.0以前ではブラウザからの要求データを Alaska がすべて読み取っていましたがVer4.0 からは
いずれかの子スレッドが要求データを読み取るようになりました。

このようにして Alaska の処理は単なるロード・バランサーとしての機能を行っているだけになりました。
このことにより、一層負荷は分散されて多くのアクセス集中にも容易に対応できるようになったわけです。

[ Alaska Ver4.0 のロード・バランサー処理]

Alaska Ver4.0 で追加された「KEEP-ALIVE」機能は重要です。
HTTPプロトコル1.1 ではブラウザは HTTPサーバーとの接続を確立すると「Keep-Alive」という要求を
HTTPサーバーに送って、できるだけお互いのTCP/IP通信を保持しようと希望します。
これに対して一部の市販のHTTPサーバーでは静的な HTML の要求であれば
自分も「Keep-Alive」と応えて通信を持続させることができます。

しかし、従来のHTTPサーバーは CGI要求に対しては「Connection-close」を戻して通信を
切断してしまいます。
これでは折角、確立した通信を毎度遮断してしまって毎回、PCOMMなどの5250エミュレータを
接続しているようなもので、非効率的な処理であると言えます。

Alaska Ver4.0 では 静的なHTMLの要求はもちろんのこと、動的な CGI 要求であっても
「Keep-Alive」と応えて、できる限り通信を保持しようと努めます。
(「Keep-Alive」として応答するのは TONAKAI によって移行された CGI の処理のみです。)
これによってブラウザとの再接続のためのオーバーヘッドを無くすことに成功しています。

しかし Alaska が通信を保持させてもブラウザ(IE) ではユーザーが1分間何も操作が無いと
やはりブラウザ(IE) 自身が通信を切断してしまいます。
(この1分間という時間はレジストリに保管されている値ですがユーザー自身が
レジストリのこの値を修正することはお奨めできません。）
この場合でも再接続が行われると Alaska は元の同じ子スレッドで処理を再開して、
再び通信を継続することを試みます。

さらに何らかの理由によって通信が切断されたままになる場合ではAlaska は
自分自身でタイマーイベントを生成して、一定時間のうちに再接続がないとCGI を強制終了させます。
タイマーイベントの省略値は 5分間ですがユーザーは好みに値に変更させることができます。

このようにして Ver4.0 での Alaska での通信は二重三重にして通信を保持するように設計されています。

Ver3.0 で発表された「仮想対話式環境」とはブラウザとの通信が切断された状態においても
「 ボタン」や「 ボタン」の動作が正しく ALASKA に伝えられて、あたかも通信が持続している
かのような動作を再現するものでした。
ところが Ver4.0 では前述の「Keep-Alive」機能の追加によって物理的にもほとんど接続されている
状態が保持され、より仮想対話式を環境を確実なものとしています。

仮想対話式環境の動作は例え通信が切断されたとしても HTML には「AURORA_EGN=xxxxxx」として
CGI が実行されたときの子プロセスJOBのジョブ番号が埋め込まれていますので元の子プロセスJOB に
実行を戻すことができるような構造となっています。
これに加えて TONAKAI で移行された CGI は活動化グループ の名前が「*NEW」ではなくCGI と
同じ名前の活動化グループ として作成されています。

これは「 ボタン」などによって CGI を強制終了させる必要があるときには活動化グループを終了
させることによって CGI の実行を終了させるようになっているからです。

TONAKAI の CGI-JOB における HREF などによる新規SUBMIT について

TONAKAI によって移行された CGI が出力した HTML 上でHREF などによって新たに別の CGI を
投入するとどうなるでしょうか？
この場合であっても新規JOB の実行は以前に実行された親CGI の子プロセスに伝えられますが
「AURORA_EGN=xxxxxx」を投入しないようにしておけば、別の JOB であると判断されてALASKA に
SUBMITされた命令を戻します。
ALASKA はこのことを直ちに検知して別の子プロセスにこのSUBMIT を再配布します。
HREFで要求されたJOBは別の子プロセスで実行されることになります。

このように TONAKAI の CGI から HREF などで別の新規JOB を実行させたい場合は
「AURORA_EGN=xxxxxx」を投入しないようにしてください。

初めてのWeb化を行うときは5250エミュレータでのサインオン画面はどのように Web化されるのだろうか
と疑問に思うかも知れません。

Ver4.0 からは Alaska に「ログイン・サポート機能」が追加されました。
Alaska の「ログイン・サポート機能」はこのような疑問に対して明解でわかりやすい回答を提供しています。

これは Alaska に対して IPアドレスだけを要求すると Alaska がブラウザに対して
ログインを要求するという非常に便利な機能です。
結果として ブラウザ(IE) はログイン・ダイアログを表示して操作員に
iSeries/i5 のユーザー・プロフィールとパスワードを要求します。
操作員がログインを行うと Alaska は i5/OS 上でのユーザー・プロフィールとパスワードの妥当性検査を
行って、ユーザー・プロフィールの「ホームページ」として定義されている
ディレクトリーの中の「INDEX.HTML」をポータル・サイトとして表示を戻すという仕組みです。
これによって開発者は独自のログイン・ダイアログを設計する必要はなくなりました。
さらにブラウザ(IE) によって表示される、このログイン・ダイアログからのログイン機能は
ブラウザ(IE) によって6-bit ASCIIコードとしてコード化(エンコード）されますので
万一、他の不正なキャプチャーによるストリームの漏洩があったとしても
簡単にはユーザーおよびパスワードを解析することはできないという安全な仕組みとなっています。

以下にその手順の概要を示します。

1. URL= http://192.168.1.1 を要求

iSeries/i5 のIPアドレスだけを要求します。

2. ブラウザ(IE)によってログイン画面が表示されます。

ここではユーザー「KEIRI」でログインします。

3. 初期ポータル・サイトの表示

経理メニューが表示されました。
このメニューは /AS400-NET.USR/MENU/KEIRI/INDEX.HTMLとして保存されている
静的な HTML です。

ユーザー・プロフィールへのメニューの登録

ログイン・サポート機能を利用する利点

CGI は ｢AURORA_EGN｣ と呼ばれる子プロセス上で実行されます。
最初に Alaska が起動されたときには最初の AURORA_EGN 上でCGIが実行されますが
以降は空いている子プロセス(AURORA_EGN) が次々と利用されますのでCGI が
次にどのAURORA_EGN 上で実行されるかは特定することはできません。
特に TONAKAI で移行された CGI では AURORA_EGN 上で次のユーザーからの入力を待機し続けますので、
そのAURORA_EGN は他のクライアントからは利用できなくなってしまいます。

それでは最初に起動した子プロセスの数よりアクセス要求が多くなった場合はどうなるのでしょうか？
Alaska はクライアント要求に対して子プロセスが不足していると判断すると直ちに子プロセスの数を
ひとつずつ増やします。
そして処理を中断することなく続行します。
極端な話ですが子プロセスの数は 1だけとして開始しても構いません。
必要な子プロセス数が次々と増加していくからです。
しかし子プロセスを生成する時間が必要となるため、そのときの応答速度はやや低下してしまいます。
このことを考慮の上、御社のクライアント数にあった子プロセス数の数を決定して開始されるよう
お勧め致します。

   OPT  ｻﾌﾞｼｽﾃﾑ/ｼﾞｮﾌﾞ  ﾕｰｻﾞｰ       ﾀｲﾌﾟ  CPU %   機能            状況
        ENTPRSSVR      QSYS        SBS      .0                   DEQW
          ALASKA       QTMHHTTP    BCH      .0  PGM-ALASKA       TIMW
          AURORA_EGN   QTMHHTTP    BCH      .0  PGM-CGIPROCESS   DEQW
          AURORA_EGN   QTMHHTTP    BCH      .0  PGM-CGIPROCESS   DEQW
          AURORA_EGN   QTMHHTTP    BCH      .0  PGM-CGIPROCESS   DEQW
          AURORA_EGN   QTMHHTTP    BCH      .0  PGM-CGIPROCESS   DEQW
          AURORA_EGN   QTMHHTTP    BCH      .0  PGM-CGIPROCESS   DEQW
          AURORA_EGN   QTMHHTTP    BCH      .0  PGM-CGIPROCESS   DEQW

Alaska がリエンジニアリングされた Ver4.0以降では、CGI 障害の回復が容易なものとなりました。
何らかの理由で CGI の実行が子スレッド上でLOOP状態等の障害となった場合、WRKACTJOB 上で
その子プロセスだけを「4=終了」によって強制的に終了させてしまうことができます。

従来の Alaska や他の HTTPサーバーでは HTTPサーバーと次に使用可能な子スレッド情報が
データ待ち行列等を通じて密接に結びついていたからです。
これに対して Alaska Ver4.0以降ではすべての子スレッドに対して一斉にメッセージを配布するだけに
留まっていますのでデータ待ち行列も使用していません。
従っていくつかの子スレッドが終了したとしても構造的な矛盾は発生しません。
ユーザーは WRKACTJOB 上で「4=終了」を使って子プロセスを強制終了させてもかまいません。
処理は何事も無かったかのようにして継続されます。

前述でご説明したように同時アクセス数が増えると子プロセスも自動的に増加します。
しかし、運用とともに子プロセスが予想以上に増えていく傾向にある場合はCGI の障害を疑ってください。

CGI が MSGW によって停止となるとその子プロセスも停止状態となりますのでAlaska は子プロセス数が
不足と判断して次の子プロセスを生成するからです。
CGI の開発者はできうる限り CGI がどのようなエラーの場合も停止しないように設計する責任があります。

通常、HTTPサーバー(ALASKA) はひとつのサーバー( IBM i )内に対して、
ひとつだけのインスタンスとして起動されるのが通常の使用方法です。

しかし、本番稼動中であっても次の開発やテストのためにALASKAを使用したい場合があります。
このようなときに本番用のALASKAをテスト環境に同時に使用したのでは開発中のCGIの不具合のために
本番中のALASKAに影響を与えて業務が中断されてしまう恐れがあります。
このように本番稼動とテスト開発を併行させたい場合はテスト用のインスタンスをもうひとつ用意して
テストはテスト用のインスタンスを利用すると、本番のALASKAに与える影響を最小限に抑えることができます。

複数のサーバー・インスタンスを起動する仕組みを マルチ・インスタンスと呼びます。
次の画面では 本番用の ALASKA というインスタンスと、テスト用のインタンスであるPGMR が同時に
起動されるいる様子を表しています。

• インスタンスは ALASKA と PGMR という 2つのインタンスを利用できます。
• 2つのインスタンスを同時に稼動させたい場合はそれらは異なるPORT番号で起動させなければなりません。
• 通常、HTTPサーバー(ALASKA)は PORT= 80 で起動させるのが一般的です。
  したがってインスタンスPGMR は PORT= 3009 などで起動させることをお勧め致します。

• ブラウザからPORT番号を指定して接続するには例えば

  http://192.168.1.1:3009/HTML/INDEX.HTML

  のようにしてブラウザのアドレス(URL)欄にPORTを指定して接続します。
  最初にPORT番号を明示的に指定すれば以降の会話ではすべて最初に指定した同じPORTによって
  会話は継続されます。

                 追加のパラメーター

機密保護 :
 SSL 許可   . . . . . . . . . .   *NO           *YES, *NO, *ONLY

動作 :
  今すぐサーバーを再起動する      *NO           *YES, *NO
  障害時の再起動  . . . . . . .   *NO           *NO, *YES
設定値 :
  最大オープン・ファイル数  . .   200           200-9999
  ACCEPT 試行回数   . . . . . .   3             1-999
 CCSID  . . . . . . . . . . . .   5026          5026, 5035, *JOB
  タイムアウト ( 秒 ) . . . . .   300           0-36000, *NONE
SBMJOB スケジュール :
  開始日  . . . . . . . . . . .   *CURRENT      *CURRENT, *WEEKLY, *ALL
  開始時刻  . . . . . . . . . .   090000        000000-235959
ジョブ記述  . . . . . . . . . .   ASNETJOBD      名前 , *USRPRF, ASNETJOBD
  ライブラリー  . . . . . . . .     ASNET.COM    名前 , *LIBL, *CURLIB
ジョブ待ち行列  . . . . . . . .   ENTPRSSVR      名前 , *JOBD
  ライブラリー  . . . . . . . .     ASNET.COM    名前 , *LIBL, *CURLIB

メッセージ待ち行列  . . . . . .   *SYSOPR        名前 , *WRKSTN, *USRPRF...
  ライブラリー  . . . . . . . .                  名前 , *LIBL, *CURLIB
ユーザー  . . . . . . . . . . .   QTMHHTTP       文字値 , *CURRENT
プラグイン :
  拡張子  . . . . . . . . . . .   JSP            名前
   PORT 番号  . . . . . . . . .     8080        0001-9999
               値の続きは＋
CGI キャッシュ・サービス :
 CLIENT キャッシュ  . . . . . .   *OFF          *ON, *OFF
 SERVER キャッシュ  . . . . . .   *OFF          *ON, *OFF
ディバッグ :
  受信内容 (GETLINE)  . . . . .   *OFF          *ON, *OFF
  環境変数 (ENVVAR) . . . . . .   *OFF          *ON, *OFF
  値の取得 (CGIPARM)  . . . . .   *OFF          *ON, *OFF
  値のセット (SETFLD) . . . . .   *OFF          *ON, *OFF
  仮想端末 (VT5250) . . . . . .   *OFF          *ON, *OFF
  ＡｕｔｏＷｅｂ (CVT5250)  . .   *OFF          *ON, *OFF

「3. HTTPサーバー ALASKA 開始 (STRHTTPSVR) 」 画面で 「F10 ＝ 追加のパラメーター」を押すと
上図が表示されます。それぞれの詳細は次の通りです。

機密保護

動作

設定値

SBMJOBスケジュール

CGI キャッシュ・サービス

ディバッグ

CGI aと LIBRARY の欄に CGI を指定すると、その CGI が実行されるときだけのライブラリー・リストを
指定することができます。

CGI が Ver4.0 からの SPECIAL ファイルを使用している場合には CGI の実行時にDSPF オブジェクトが
存在している必要があります。このことに留意しておいてください。

TONAKAI の移行によって下記のようにプログラム情報 SDS が RPGソースに追加されます。

D INFDSP         SDS
    :
D  JOB_NAME             244    253
D  PGM_NAME             334    343
				

一方、SPECIAL ファイルの制御インターフェース・プログラム (HTMLFILE または HTMLIO)には、
次のパラメータが渡されます。

C*----------------------------------------------------+
C     HTML          PLIST
C                   PARM                    HTM_FILE
C                   PARM                    HTM_RECORD
C                   PARM                    OPCODE
C                   PARM                    JOB_NAME
C                   PARM                    CFKEYS
C                   PARM                    SFILE
C                   PARM                    INFDS_PTR
C                   PARM                    PGM_NAME
C*----------------------------------------------------+

HTMLFILE または HTMLIO は、このパラメータ内の JOB_NAME の欄に PC クライアントからの
IP アドレスを取得してから「遠隔装置名の登録」で登録された装置名を更新します。