フォーム

インターネットプログラムのビルド

第 3 章サーバ側のプログラミング

この章では、インターネットアプリケーションのサーバ側プログラムを作成する方法について説明します。この章で説明するテクニックは、NSAPI および CGI のプログラミングに同じように適用できます。

3.1 概要

Server Express を使用すると、COBOL の機能が拡張され、他の言語よりもインターネットのサーバ側プログラムを簡単に作成できます。ACCEPT 動詞を使用すると、フォームからデータを受け取ることができます。また、DISPLAY 動詞か、埋め込み HTML (EHTML) を使用すると、Web ブラウザに結果を返すことができます。EHTML では、COBOL プログラムの中から HTML ページを作成することができます。この章では、主に次の 4 分野について説明します。

資源の競合
サーバ側プログラムへの入力
サーバ側プログラムからの出力
アプリケーションの状態の維持

3.2 資源の競合

サーバ側プログラムは、異なるユーザに対して同時に複数回、実行することができます。サーバ側プログラムが CGI プログラムである場合は、プログラムが実行されるたびに、別のプロセスとして実行されます。サーバ側プログラムが NSAPI プログラムである場合は、プログラムが実行されるたびに、別のスレッドで実行されます。NSAPI プログラムの利点を最大に活用するには、マルチスレッドプログラムとして作成する必要があります。マルチスレッドプログラミングについての詳細は、マニュアル、 『Multi-threaded Programming』 を参照してください。サーバ側プログラムが共有資源にアクセスする必要がある場合 (たとえば、ファイルやデータベースなど)は、資源競合を処理するためのロジックを記述する必要があります。

COBOL ファイルを使用する場合は、COBOL に、共有ファイルに対する関数セットが豊富に含まれています。詳細については、マニュアル 『Fileshare ユーザガイド』 を参照してください。

3.3 プログラミングの制約

インターネットプログラムで COBOL 構文を使用するには、さまざまな制約があります。また、CGI プログラムおよび NSAPI プログラムからダイアログシステムを使用できません。構文の制約を次に説明します。

CGI プログラムおよび NSAPI プログラム

CGI プログラムおよび NSAPI プログラムでは次の構文を使用できません。

スクリーン節
ACCEPT および DISPLAY を使用したコンソール入出力
ダイアログシステム

NSAPI プログラム

上記で説明した制約の他に、次の処理も実行しないようにしてください。

ls や chmod などの UNIX コマンドを実行可能にする構文の使用。
PATH、COBDIR、cd などのコマンドによるプロセスの状態の変更。

Web サーバで実行される NSAPI アプリケーションはすべて同じ環境を共有するため、このような制約が適用されます。環境を変更すると、その Web サーバのプロセスで実行中のすべてのスレッドに影響を与えます。あるスレッドが環境を変更すると、その他のスレッドの結果が不確定になります。

3.4 サーバ側プログラムへの入力

フォームの各コントロールには、名前と値があります。『フォーム』 の章で説明したように、エンドユーザがフォームを送信すると、フォームの情報は、名前と値の組み合わせとしてサーバ側プログラムに送信されます。COBOL 構文の拡張機能を使用すると、フォームのコントロールの名前を、サーバ側プログラムの COBOL データ項目に直接関連付けることができます。フォームのデータがサーバ側プログラムにポストされると、データ項目はフォームのコントロールの値に設定されます。

次のフォームには、Name という名前のフィールドがあります。ここに、エンドユーザが値、 Bob を入力しています。

Working-Storage 節で次のように宣言すると、サーバ側プログラムを各名前付きコントロールに結合できます。

01 inputdata is external input-form.
   03 name-field      pic x(30) identified by "name".
   03 email           pic x(15) identified by "emailid".
   03 phone-no        pic x(30) identified by "phone".

エンドユーザが [Send Form] ボタン ( この例では、Submit コントロール) をクリックし、サーバ側プログラムを実行すると、次の文が実行されたときに値、 Bob がデータ項目、 NAME-FIELD に転送されます。

accept input-form

3.4.1 構文

COBOL データ項目を CGI 入力にマップするには、次の構文を使用します。

level-number data-name-1 IS EXTERNAL-FORM.

この宣言では、グループ項目、 data-name-1 とその従属フィールドに HTML フォームからの入力により値を設定できることを示しています。基本データ項目を NAME 属性にマップする方法は、次のとおりです。

sub-level-number data-name-2 picture-string IDENTIFIED BY name.

パラメータの内容は、次のとおりです。

`sub-level-number`	COBOL データ項目のレベル番号
`data-name-2`	COBOL データ名
`picture-string`	COBOL ピクチャ文字列。PIC X(n)、PIC 9(n) および数字編集フィールドを使用できます。n 文字よりも長い文字列は右端を切り捨てられ、n 文字よりも短い文字列は左側から空白文字を埋められます。
`name`	フォームのコントロールに対応する Name プロパティまたは Groupname プロパティの値

3.4.2 例

この例は、フォームのフィールドにマップされるデータ項目セットを示します。

01 input-form is external-form.
    03  name-field pic x(30) identified by "Name".
    03  phone-no   pic x(30) identified by "Phone".
    03  email      pic x(15) identified by "EmailID".

3.5 サーバ側プログラムからの出力

Server Express では、COBOL プログラムから Web ブラウザに HTML を出力する方法が 2 種類あります。どちらの方法でも、COBOL 変数の値を HTML 出力に置き換えることができます。

埋め込み HTML (EHTML)
EHTML を使用すると、COBOL プログラムで EXEC HTML と END-EXEC の区切り文字の間に HTML を記述することができます。HTML 文は、コードを原始プログラムに直接作成するか、コピーファイルとしてインクルードすることができます。

EXEC HTML 機構は、HTML の出力に対してプログラムを完全に制御します。HTML ソースは、実際にはサーバ側プログラムにリンクされるため、HTML コピーファイルを変更すると、プログラムを再コンパイルしてから、再リンクする必要があります。
DISPLAY
DISPLAY を使用すると、外部ファイルに保持された HTML ページを表示することができます。

3.5.1 EHTML の使用方法

埋め込み HTML (EHTML) では、COBOL プログラムから直接、HTMLを出力することができます。

EHTML では、完全な HTML ページをコピーファイルとしてプログラム中にインクルードすることができるうえに、特別なデータ宣言を必要としないという利点があります。また、部分的な HTML ページをコピーファイルとして使用したり、個別の HTML 文を出力し、完全なプログラム制御のもとで完全なページをビルドすることもできます。このような機能により、柔軟性がたいへん高くなります。

EXEC HTML 文を使用して、COBOL プログラムに HTML を埋め込みます。この部分は、EHTML プリプロセッサ、 htmlpp により翻訳されます。

キーワード、 EXEC HTML および END-EXEC を使用すると、HTML を直接 COBOL ソースコードに埋め込むことができます。キーワード、 EXEC およびHTML は、同じ行に記述する必要があります。その他に書式の制約はありません。

次の書式は、一般的な書式です。

EXEC HTML
  [htmloutput] 
  [copy "file.htm".]
END-EXEC

パラメータの内容は、次のとおりです。

`htmloutput`	Web ブラウザへ出力する HTML マークアップ
`file.htm`	HTML マークアップを含むファイル

EHTML プリプロセッサは、HTML マークアップの検証や解析は行いません。CGI プログラムを起動する Web サーバに直接 HTML マークアップを出力するのみです。

固定フォーマットの COBOL ソースコードでは、EHTML プリプロセッサは、埋め込み HTML を出力するときに、列 8 を仮想列 1 として処理します。そのため、HTML の <PRE> タグを簡単に使用できます。ただし、拡張子が .htm のコピーファイルをインクルードした場合は、プリプロセッサによりコピーファイルが書式のないソースとして処理されます。この動作を無効にするには、プリプロセッサへの指令 NOAUTOFORMAT を指定します。

3.5.1.1 代入マーカー

代入マーカーを使用すると、COBOL プログラムからの変数データを、直接 HTML 出力に代入することができます。代入マーカーは、次のように、コロン (:) が先頭に付く COBOL データ名です。

:data-name

表示項目は、常に、EHTML 中で使用する必要があります。バイナリのデータ項目を使用すると、ユーザはフォームに表示されたデータを判読できません。

コロンの後に空白文字または区切り文字マーカーが続く場合は、常にコロンとして出力され、代入マーカーとして処理されません。また、コロンの前に \ を付けて、コロンをコロンとして出力させることもできます。

注 :

:literal 参照が次の文字列の後に続けて記述されている場合は、大文字と小文字の別にかかわらず、代入マーカーとして処理されません。

data
clsid
layout
javascript
about
http
file
ftp
mailto
news
gopher

例

 working-storage section.
 01 acct-code    pic 9(8). 
 ...
 procedure division. 
 ...
*> 最初のコロンの後に空白文字が続くため、
*> EXEC HTML では代入マーカーとして処理されません。
*> 2 番目のコロンの後にはデータ名が続くので
*> 代入マーカーとして処理されます。
*> 3 番目のコロンの前には \ が付くため、
*> コロンとして処理されます。
 EXEC HTML
     Account Code: :acct-code <BR>
     \:acct-code
 END-EXEC

代入マーカーを修飾するには、グループ項目のデータ名と基本項目のデータ名の間にピリオド (.) を使用します。たとえば、次のように記述します。

 working-storage section.
 01 customer.
  03 name         pic x(80).
  03 acct-code    pic 9(8). 
 ...
 procedure division. 
 ...
*> EXEC HTML ブロック中にある customer.acct-code は、
*> COBOL ソース中にある顧客の acct-code に相当します。
 EXEC HTML
     Account Code: :customer.acct-code <BR>
 END-EXEC

また、代入マーカーの参照を修正することもできます。

 working-storage section.
 01 acct-code    pic 9(8). 
 ...
 procedure division. 
 ...
*> 参照を修正し、acct-code の
*> 最初の 4 文字を出力します。
 EXEC HTML
     Account Code: :acct-code(1:4) <BR>
 END-EXEC

3.5.1.2 EHTML プリプロセッサ指令

EHTML プリプロセッサを実行するには、次のコンパイラ指令を設定する必要があります。

preprocess(htmlpp) [preprocessor-directives] end

注 : ツール、 Form Express または Form Designer を使用すると、NetExpress で作成したプログラムを UNIX システムへ移行することができます。この場合、PREPROCESS 指令はすでに $SET 文に設定されています。

また、htmlpp.dir という ASCII ファイルを作成して、Server Express システムの $COBDIR パスに置くと、EHTML プリプロセッサ指令を設定することができます。次の表は、EHTML プリプロセッサ、 htmlpp に使用できるすべての指令を示します。これらの指令は、キーワード、 preprocess(htmlpp) と endp の間に配置して設定してください。

[NO]AUTOFORMAT または [NO]AF	コピーファイル、 .htm を書式のないソースとして処理しません。COBOL が固定フォーマットでコンパイルされた場合は、列 8 から 72 のみが .htm ファイルへ読み込まれます。
DEBUG または D	デバッグの追加情報を指定の出力ファイルへ出力します。
NOWARN または NW	htmlpp が生成する可能性のある警告メッセージを報告しません。
OUT(name) または O(name)	name という名前で、前処理した出力ソースファイルを作成します。
PREPROCESS(name) または P(name)	ソースファイルを読み込んで COPY 文を処理する、入れ子プリプロセッサを指定します。

3.5.2 DISPLAY 文の使用方法

DISPLAY 動詞を使用すると、Web ブラウザに HTML ページを送信することができます。HTML ページには、プログラムから提供される変数データを格納する代入マーカーを含めることができます。代入マーカーは、標準 HTML ではありません。そのため、COBOL システムは、代入マーカーを変数データに置換してから、Web ブラウザにページを送信します。代入マーカーは、次のいずれかの形式をとります。

%%name%%
%%!s name%%
%%!e name%%

パラメータの内容は、次のとおりです。

`%%`	代入マーカーを区切ります。
`name`	データ宣言の IDENTIFIED BY 句により COBOL データ項目にマップされる名前。`!s` または `!e` を指定しない場合は、name の内容がそのまま出力されます。
`!s`	データ項目から後続の空白を削除します。プログラムが標準テキストを出力する場合は、Web ブラウザが通常、自動的に後続の空白文字を削除しますが、DISPLAY 動詞を使用してフォーム要素に値を入れる場合は、この機能を使用して、後続の空白文字を削除する必要があります。
`!e`	二重引用符 (")、アンパサンド (&)、大なり (>)、および小なり (<) の各記号をそれぞれ同等のエンティティに変換します。

次の構文は、COBOL のグループデータ項目を出力ページにマップするための構文です。

level-number data-name-1 IS EXTERNAL-FORM identified by "pagefile.htm".

パラメータの内容は、次のとおりです。

`level-number`	グループ項目の COBOL データ項目レベル番号
`data-name-1`	COBOL データ名
`pagefile.htm`	出力する HTML ページのファイル名

この宣言では、HTML フォーム、 pagefile.htm にグループ項目 data-name-1 とその従属フィールドからのデータセットを使用するように指定しています。基本データ項目をフォーム名にマップする方法は、次のとおりです。

sub-level-number data-name-2 picture-string IDENTIFIED BY name.

パラメータの内容は、次のとおりです。

`sub-level-number`	COBOL データ項目のレベル番号
`data-name-2`	COBOL データ名
`picture-string`	COBOL ピクチャ文字列。PIC X(n)、PIC 9(n) および数字編集フィールドを使用できます。n 文字よりも長い文字列は右端を切り捨てられ、n 文字よりも短い文字列は左側から空白文字で埋められます
`name`	出力する HTML ページの代入マーカーの名前

例

この例は、フォームのフィールドにマップされるデータ項目セットを示します。

01 output-form is external-form identified by "outpage1.htm".
    03  name-field pic x(30) identified by "Name".
    03  phone-no   pic x(30) identified by "Phone".
    03  email      pic x(15) identified by "EmailID".

次のコードは、上記の名前に対して代入マーカーを設定した HTML ページの例です。

<HTML><BODY>
<H1>This is the output-form </H1>
<P>Dear %%Name%%,</P>
<P>You entered the following information</P>
<UL>
<LI>'phone number - <B>%%Phone%%</B></LI>
<LI>Email id - <B>%%EmailID%%</B></LI>
</UL>
</BODY></HTML>

3.6 CGI 環境変数

すべての CGI プログラムは、環境変数を経由してブラウザとサーバの情報を受け取ります。この処理は、プログラムへフォームデータを渡しても渡さない場合も行われます。

CGI 環境変数は、次のような情報を提供します。

ネットワーク上でブラウザが保存されている位置
ブラウザの種類と、そのブラウザが判読可能な文書の種類
CGI プログラムを呼び出したサーバの名前とバージョン
ブラウザが送信したデータの受信方法および解釈方法についての指示

一部の環境変数は、CGI プロトコルに準拠したサーバによって設定されます。その他に、CGI プロトコルに準拠していない場合でも、CGI プログラムに渡される環境変数もあります。

CGI 環境変数の一覧は、 Web サイト、http://hoohoo.ncsa.uiuc.edu/cgi/env.html に掲載されています。

環境変数を読み込んで変更するには、次の構文を使用します。

DISPLAY ... UPON ENVIRONMENT-NAME。変更する環境変数を定義します。
ACCEPT ... ENVIRONMENT-NAME。環境変数の値を読み込みます。

たとえば、サーバソフトウェアの名前とバージョンを含む CGI 環境変数 SERVER_SOFTWARE の値を得るには、次のように記述します。

procedure division.
display "server_software" upon environment-name
accept env from from environment-value
display "Server software is: " env
...

例

次の例では、さまざまな CGI 環境変数を読み込んで、それらをフォームへ書き出します。

$set mf preprocess(htmlpp) endp
 *参照
 * http://www.w3.org/CGI/
 *
 program-id. "cgivars".
 working-storage section.
 01 cgi-var-content-type         pic x(128).
 01 cgi-var-server-name          pic x(128).
 01 cgi-var-server-port          pic x(20).
 01 cgi-var-server-software      pic x(128).
 01 cgi-var-gateway-interface    pic x(40).
 01 cgi-var-remote-host          pic x(128).
 01 cgi-var-remote-addr          pic x(128).
 01 cgi-var-http-user-agent      pic x(128).
 01 cgi-var-http-referer         pic x(128).
 
 procedure division.
 main section.

 * CGI 環境変数をクエリー

 display "CONTENT_TYPE" upon environment-name
 accept cgi-var-content-type from environment-value

 display "SERVER_NAME" upon environment-name
 accept cgi-var-server-name from environment-value

 display "SERVER_PORT" upon environment-name
 accept cgi-var-server-port from environment-value

 display "SERVER_SOFTWARE" upon environment-name
 accept cgi-var-server-software from environment-value

 display "GATEWAY_INTERFACE" upon environment-name
 accept cgi-var-gateway-interface from environment-value

 display "REMOTE_HOST" upon environment-name
 accept cgi-var-remote-host from environment-value

 display "REMOTE_ADDR" upon environment-name
 accept cgi-var-remote-addr from environment-value

 display "HTTP_USER_AGENT" upon environment-name
 accept cgi-var-http-user-agent from environment-value

 display "HTTP_REFERER" upon environment-name
 accept cgi-var-http-referer from environment-value


 * HTML の見出しをエージェントに出力
 exec html
     <HTML>
      <HEAD>
       <TITLE>CGI Environment information</TITLE>
      </HEAD>
      <BODY>
       <H1>CGI Environment information</H1>
 end-exec
 
 exec html
     <B>Server Information</B><BR>
     This server is using :cgi-var-server-software and is
     called :cgi-var-server-name on port :cgi-var-server-port<BR>

     :cgi-var-server-name is using :cgi-var-gateway-interface<BR>
     <BR>
     <B>Form information</B><BR>
     The content-type is :cgi-var-content-type<BR><BR>
 end-exec

 * エージェントのドメイン名の完全パスを検索します。
 * 一部のサーバではこの情報を返さないことがあります。CGI/1.1
 * では、REMOTE_HOST を指定するようになっています。
 
 if cgi-var-remote-host not equal spaces
 
     exec html
       <B>Client Information</B><BR>
       The remote hosts is called :cgi-var-remote-host, and
       the IP address of the agent is :cgi-var-remote-addr<BR>
     end-exec
 else
 
     exec html
       <B>Client Information</B><BR>
       The IP address of the agent is :cgi-var-remote-addr<BR>
     end-exec
 end-if

 *
 * HTTP_* 変数は、エージェント経由で送信される
 * HTTP ヘッダーに固有です。
 *
 if cgi-var-http-user-agent not equal space
     exec html
       The agent is identified as :cgi-var-http-user-agent <BR>
     end-exec
 end-if

 if cgi-var-http-referer not equal space
     exec html
       The cgi program was referered to us by:
       :cgi-var-http-referer <BR>
     end-exec
 end-if

 exec html
      </BODY>
     </HTML>
 end-exec

 exit program

 end program "cgivars".

3.7 アプリケーションの状態の維持

Web ベースのアプリケーションで問題となるのは、アプリケーションの状態を維持することです。CGI プログラムは、実行時に、前回の処理内容や現在プログラムを使用しているクライアントを記憶していません。プログラムを使用する各クライアントについてアプリケーションの状態を維持するには、次の 2 つの機構を使用します。

非表示フィールド
状態情報は、エンドユーザのブラウザに送信されるフォームの、ブラウザに表示されないフィールドに保存されます。非表示フィールドは、フォームをサポートするブラウザならどれでも機能します。ただし、状態をセッション間で維持することはできません。これは、エンドユーザのマシンからフォームがなくなると、ただちにすべての状態情報が失われるためです。
cookie
エンドユーザが自分のブラウザを他のページやサイトに送信してからアプリケーションに戻る場合でも、状態情報が維持されます。cookie は、セッション間でも状態を維持できます。ただし、エンドユーザが cookie をサポートするブラウザを使用している必要があります。

これらの機構の使用には、2 つの難点があります。

ネットワークを介して大量の状態情報を送信すると、アプリケーションの実行速度が遅くなることがあります。ダイヤルアップ回線で接続されたインターネットクライアントの場合は、特に顕著です。
セキュリティやその他の理由で、イントラネットやインターネットにより詳細情報を送信したくない場合には、これらの機構は適切ではありません。

Server Express には、すべての状態情報をサーバに記憶させ、サーバ側プログラムによりこの情報に素早くアクセスできる追加機構があります。call-by-name ルーチンを使用すると、サーバ側プログラムは、接続する各クライアントに一意のクライアント ID を要求し、索引ファイルにクライアントの状態データを格納します。

下図は、クライアント ID を含む cookie とフォームをクライアントのブラウザに送信するサーバ側プログラムを示します。クライアントのブラウザから次に Web サーバに要求を出すときに cookie を戻します。サーバ側プログラム (最初のプログラムである場合と別のプログラムである場合があります) は、クライアント ID を使用して状態データを格納したレコードを検索します。

図 3-1: サーバ側の状態ファイル

注 : 状態ファイルに重要な情報 (たとえば、クレジットカードの明細など) を格納する場合は、セキュリティが確保されたネットワークリンクのみを介してアプリケーションにアクセスしたり、暗号化するようなセキュリティ手段を追加で実装することが必要です。悪意のあるユーザが、フォームを再送信する前に別のクライアント ID を捏造し、他人の状態レコードにアクセスする可能性があります。その場合に、悪意のユーザが実際の状態情報を表示できるかどうかは、アプリケーションの設計や Web ブラウザに返される情報の種類によって決まります。

次の 3 項では、次の内容を説明します。

非表示フィールドの使用方法
Cookie の使用方法
Server Express のサーバ側状態ルーチンの使用方法

3.7.1 非表示フィールド

HTML フォームでは、非表示フィールドを使用することができます。非表示フィールドは、HTML 入力 (エントリフィールド) と同様に機能します。ただし、フォームを読み込むエンドユーザ側では表示されません。

フォームを入力フォームや出力フォームとして使用する CGI を作成すると、エントリフィールドの場合と同様に、非表示フィールドに対応する COBOL データ項目が生成されます。フォームの出力時に非表示フィールドにアプリケーションの状態情報を格納し、フォームが別の CGI に送信されたときに読み返すことができます。

3.7.2 Cookie

cookie は、HTML ページと一緒に Web ブラウザに送信される名前と値の組み合わせです。cookie にアプリケーションの状態情報を記録し、次に特定のクライアントがサーバ側プログラムにアクセスするときにこの情報を検索することができます。Netscape Navigator 2.0 以降のバージョンと Microsoft Internet Explorer 3.0 以降のバージョンは、ともに cookie をサポートしています。他のブラウザでは、サポートしていない場合があります。

cookie の完全な規格は、Netscape サイトに掲載されています。ここをクリックしてください。

デフォルトでは、エンドユーザがブラウザを閉じるまで、cookie は Web ブラウザに存在します。cookie には有効期限を設定することができます。その場合は、ブラウザによりキャッシュに記憶された情報が有効期限まで維持されます。

cookie の使用は、次の 2 つに分けられます。

cookie の送信
cookie の検索

デモンストレーションプログラム、 howmany.cbl では、cookie を使用して、ページへアクセスする各エンドユーザの個別のページカウントと全体のカウントを維持します。デモンストレーションプログラムを検索するには、Infomgr を使用してください。

3.7.2.1 EHTML または DISPLAY を使用した cookie の送信

フォームでブラウザに送信する HTML ページの <HEAD> セクションに次のように記述すると、cookie を設定することができます。

<META HTTP-EQUIV="Set-Cookie"
CONTENT="name=value"[;expires=expiry]>

パラメータの内容は、次のとおりです。

`name`	cookie の名前
`value`	cookie の値
`expiry`	有効期限の日時。この情報はオプションです。デフォルトでは、ブラウザがシャットダウンされるとすべての cookie が消去されます。/TD>

名前と値には、合わせて最大 4 KB の長さの文字列を指定できます。COBOL プログラムからフォームを出力する場合は、name、value、および expiry に代入マーカーを使用できます。また、EHTML 動詞または DISPLAY 動詞を使用してフォームを出力できます。

3.7.2.2 Cookie の受信

Web ブラウザは、cookie を送信したサーバのドメインに基づいて cookie を識別します。ドメインは URL の一部で、Web サイトを識別します (たとえば、merant.com は Micro Focus の Web サイトのドメインです)。サーバ側プログラムが Web ブラウザに cookie を送信した場合は、そのブラウザが同じサーバの資源にアクセスするたびにその cookie を返します。返された情報は、ACCEPT 動詞を使用してサーバ側プログラム内に読み込むことができます。

この処理を行うには、cookie の名前で識別される、入力フォーム用のデータ項目を宣言します。たとえば、mycookie という名前の cookie の値を得るには、次のように記述します。

 01 inputdata is external input-form.
    03 name-field      pic x(30) identified by "name".
    03 phone-no        pic x(30) identified by "phone".
    03 email           pic x(15) identified by "emailid".
    03 cookie-data     pic x(40) identified by "mycookie".
    ...
 procedure division. 
 ...
 accept inputdata
 ...

フォーム上に同じ名前のコントロールと cookie がある場合は、cookie が返す値が優先されます。

3.7.3 サーバ側の状態機構の使用方法

サーバ側の状態機構を使用すると、定義したレコード形式でアプリケーションの状態に関する情報を保存することができます。この機構を使用すると、常にサーバ側プログラムによりアプリケーションの最初のフォームを出力し、セッションの開始時にクライアント ID を割り当てる必要があります。

cookie を使用してクライアント ID を保存する場合は、状態情報がユーザの現在のセッションよりも長い間保存されるように有効期限情報を設定することができます。つまり、アプリケーションを永続化させることができます。この場合、ユーザは、アプリケーションを翌日に再起動し、前回作業していた場所に戻ることができます。永続的なアプリケーションに対して作成されたプログラムは、クライアント ID を持つ cookie をテストして、初めて実行されるものであるかどうかを判断します。クライアント ID の値が空白文字である場合は、ID を割り当て、新しいセッションを開始する必要があります。それ以外の場合は、状態情報を復元して、適切なフォームを表示する必要があります。

注 :

サーバ側の状態機構は、Sstate と呼ばれるモジュールにより実装されます。このモジュールは、状態維持ルーチンと呼ばれる、多くの呼び出し可能なルーチンを提供します。Sstate のソースコードは提供されているため、暗号化のような機能を追加する場合は、ソースコードのサブルーチンを修正します。

ソースコード、 sstate.cbl は、$COBDIR/src/mfclient フォルダにあります。変更を加える場合は、sstate.cbl をソースディレクトリにコピーします。アプリケーションで新しい sstate モジュールを使用するには、sstate.so バージョンをビルドして、コンパイラ指令 INITCALL(SSTATE) で主プログラムをコンパイルします。たとえば次のように記述します。

cob -z sstate.cbl -o sstate.so
cob -xU -C 'initcall(sstate)' pizza.cbl

状態維持ライブラリルーチンについては、『状態維持ライブラリルーチン』 の章を参照してください。

図 3-2 は、サーバ側の状態機構を使用するためのロジックを示します。

図 3-2: サーバ側状態機構の使用方法

次の例は、このロジックに従い、状態維持ルーチンを使用したプログラムの要約です。斜体で書かれているコメントは、フローチャート中のボックスに該当します。

 working-storage section.
 ...
 01 state-filename           pic x(255) value
                             "MF-STATE-SAVE.DAT".
 01 client-length            pic xxxx comp-x.
 01 client-state.
  03 ...
  *> クライアント状態レコードに任意のフォーマット
  *> を定義することができます。長さをクライアント
  *> 長フィールドに保管してください。
 01 state-status             pic x comp-x.
 01 browserInput is external-form.
  03 name-field      pic x(30) identified by "name".
  03 phone-no        pic x(30) identified by "phone".
  03 email           pic x(15) identified by "emailid".
*> cookie
  03 client-id               pic x(30) identified by "clientid". 
 ...
 
 procedure division.
   *> クライアント状態ファイルを指定します。
   call "MF_CLIENT_STATE_FILE" using state-filename
                                     state-status
   ...
   *> クライアント ID をブラウザから提出された情報から
   *> 入手します。
   accept browserInput
   move length of client-state to client-length
   if client-id = spaces
   *> cookie は、空白です。- 初めて、状態レコードを
   *> 割り当て、新しいクライアント ID を入手しています。 
   call "MF_CLIENT_STATE_ALLOCATE" using client-id 
                                         client-length 
                                         state-status
   *> COOKIE の初期化: cookie を使用してクライアント ID を      
   *> ユーザのマシンに保管している場合は、クライアント ID の
   *> cookie の出力に使用しているデータ項目を初期化してくだ
   *> さい。cookie は、作成したプログラムのフォーム出力とと
   *> もに送信されます。
   ...

   else
   *> クライアント状態を取得します。
   call "MF_CLIENT_STATE_RESTORE" using client-id
                                        client-state
                                        client-length
                                        state-status
   end-if
   ...
   *> 入力フォームの処理：この時点では、フォームからの全情報
   *> と、状態維持ファイルから取得したクライアント状態を入手
   *> しています。
   ...
   *> クライアント状態を保存します。
   call "MF_CLIENT_STATE_SAVE" using client-id 
                                     client-state
                                     client-length
                                     state-status

   *> 次のフォームの出力：クライアント ID を、フォーム上の隠
   *> しコントロールに保管している場合は、この情報でフォームを
   *> 初期化する必要があります。クライアント ID がある場合は、
   *> ユーザに再送する必要はありません。
   ...

これらのルーチン全体については、『状態維持ライブラリルーチン』 の章を参照してください。

3.7.4 クライアント状態レコードの削除

クライアント状態レコードが不要になり、削除する場合には、2 つのルーチンが関係します。一方のルーチンは、1 つのレコードを削除するもので、もう一方のルーチンは、特定の日数が経過したレコードを削除します。

1 つのレコードを削除するには、MF_CLIENT_STATE_DELETE を呼び出します。たとえば、次のように記述します。

 working-storage section. 
 ... 
 01 state-status             pic x comp-x.
 01 client-id                pic x(30).
 01 state-filename           pic x(255) value
                             "MF-STATE-SAVE.DAT".
 
 procedure division. 
 ... 
*>  クライアント状態ファイルを開きます。
 call "MF_CLIENT_STATE_FILE" using state-filename
 ...  
 call "MF_CLIENT_STATE_DELETE " using client-id
                                      server-status

特定の日数が経過したレコードをすべて削除するには、MF_CLIENT_STATE_PURGE を呼び出します。たとえば、次のように記述します。

 working-storage section. 
 ... 
 01 state-status             pic x comp-x.
 01 age-in-days              pic x(4) comp-x. 
 01 state-filename           pic x(255) value
                             "MF-STATE-SAVE.DAT".
 
 procedure division. 
 ... 
*>  クライアント状態ファイルを開きます。
 call "MF_CLIENT_STATE_FILE" using state-filename
 ...  
 move 5 to age-in-days *> 6 日以上経過したレコードをすべて削除します。
 call "MF_CLIENT_STATE_PURGE " using age-in-days
                                     server-status

これらのルーチンについては、『状態維持ライブラリルーチン』 の章で詳細に説明しています。

フォーム

インターネットプログラムのビルド