バッチサーバ環境の全体的な設計要素は以下です。
文字コードの設計
ファイルシステムの設計
バッチジョブ定義データベースの設計
バッチ実行基盤で使用する文字コードを設計します。
Solaris/Linuxの場合
バッチ実行基盤が使用する文字コードを、設定および指定する箇所には以下があります。また、以下の文字コードはすべて合わせる必要があります。
バッチサーバのシステムロケール
/etc/default/initに設定するシステムのデフォルトのLANG環境変数
/etc/sysconfig/i18nに設定するシステムのデフォルトのLANG環境変数
バッチ実行基盤を構成する各サービス起動時のLANG環境変数
Interstage (イベントサービスを含む)
JMXサービス
バッチ受付サービス
バッチ実行サービス
バッチワークユニットの環境設定(Environment Variable：環境変数)
アプリケーション連携実行基盤定義ファイル(COBOL/C言語アプリケーション用、コマンド／スクリプト用)
バッチアプリケーションのコンパイルオプション
バッチ実行基盤を構成する各サービス起動時のLANG環境変数については、“3.2 環境変数の設定”を参照してください。
バッチワークユニットの環境設定(Environment Variable：環境変数)については、“4.2.4 バッチワークユニットの環境設定”を参照してください。
アプリケーション連携実行基盤定義ファイルについては、“6.4.1 アプリケーション連携実行基盤定義ファイルの編集”、または“4.2.4.3 コマンド／スクリプト用のアプリケーション連携実行基盤定義ファイルの編集”を参照してください。
Windows(R)の場合
バッチ実行基盤が使用する文字コードを、設定および指定する箇所には以下があります。また、以下の文字コードはすべて合わせる必要があります。
バッチ実行基盤が動作する文字コード
バッチセットアップ情報ファイルに、バッチ実行基盤が動作する文字コードを指定します。
アプリケーション連携実行基盤定義ファイル(COBOLアプリケーション用、コマンド／スクリプト用)
バッチアプリケーションのコンパイルオプション
バッチセットアップ情報ファイルについては、“4.1.1 バッチセットアップ情報ファイルの設定”を参照してください。
バッチワークユニットの環境設定(Environment Variable：環境変数)については、“4.2.4 バッチワークユニットの環境設定”を参照してください。
アプリケーション連携実行基盤定義ファイルについては、“6.4.1 アプリケーション連携実行基盤定義ファイルの編集”、または“4.2.4.3 コマンド／スクリプト用のアプリケーション連携実行基盤定義ファイルの編集”を参照してください。
使用可能な文字コード
バッチ実行基盤で使用可能な文字コードを以下に示します。
EUC
SJIS
UTF-8
UTF-8
EUC
SJIS
UTF-8
Windows Server(R) 2008では、JIS X 0213:2004に対応した文字セット（以降、“JIS2004”と記述します）が使用できます。この場合、以下の注意事項があります。
バッチ実行基盤の文字コードにはUTF-8を利用してください。バッチ実行基盤で動作するバッチアプリケーションでJIS2004を利用することが可能です。なお、バッチアプリケーションでJIS2004の文字セットを利用する方法については、バッチアプリケーションを開発する言語の仕様に従ってください。
コマンドプロンプトの仕様により、バッチ実行基盤が提供するコマンドの出力については、JIS2004の文字セットを正しく表示することができません。各種資源（ユーザ名、グループ名、バッチジョブ定義の内容、ジョブログへの出力内容）にJIS2004の文字を利用した場合には、これらの資源について正しく文字を表示することができませんので注意してください。
バッチサーバ環境で使用する以下のファイルシステムを専用で用意するかどうか設計します。
ファイル資源専用のファイルシステム
ファイルの事前容量チェック機能で使用するディレクトリ
ファイルパスの論理化機能で使用するディレクトリ
世代ファイルの格納先ディレクトリ
バッチジョブ定義データベース専用のファイルシステム
ジョブスプール専用のファイルシステム
ジョブログスプール専用のファイルシステム
専用のファイルシステムを用意したイメージを以下に示します。
上記ファイルシステムは必須ではありませんが、バッチ実行基盤およびバッチ業務を安定稼働させるために専用のファイルシステムを用意することを推奨します。また、ディスクのアクセス競合によるジョブ実行の遅延を考慮し、“ファイル資源専用のファイルシステム”および“ファイル管理機能で使用するファイルシステム”以外については、それ以外のファイルシステムとは異なる専用の物理ディスクに配置することを推奨します。
バッチサーバ環境を運用するマシンでは、複数のファイルシステムを同じマウントポイントに対してマウントしないように設計・運用を行ってください。複数のファイルシステムを同じマウントポイントに対してマウントした場合、バッチサービスの起動に失敗する場合があります。
セキュアな環境でバッチ実行基盤を運用するために、ファイルシステムには必ずNTFSを利用してください。
“ファイル資源専用のファイルシステム”および“ファイル管理機能で使用するファイルシステム”以外の以下については、それぞれの設計と同時に専用のファイルシステムを用意するかどうかを設計してください。
バッチジョブ定義データベース専用のファイルシステム
“2.3.1.3 バッチジョブ定義データベースの設計”
ジョブスプール専用のファイルシステム
“2.3.3.1 ジョブスプールの設計”
ジョブログスプール専用のファイルシステム
“2.3.3.2 ジョブログスプールの設計”
ファイル資源専用のファイルシステムについて以下に説明します。
バッチ業務の運用に合わせて、バッチジョブで使用するファイルシステムの数および容量を設計してください。
たとえば、ジョブの実行環境ごとにバッチ業務の運用をわけた場合には、ジョブの実行環境ごとにファイルシステムを割り当てることで、バッチジョブが使用するファイルの管理が容易になります。
バッチ実行基盤で実行するバッチジョブが使用するファイル資源のうち、データ転送製品などでデータ転送してきたファイルを扱いたい場合には、以下の図のように、転送してきたファイルは、ファイル資源専用ファイルシステムには配置せずに、その他のファイルシステムに配置するように設計してください。
ファイル資源専用のファイルシステムに対する容量見積もりの考え方
1つのファイル資源専用のファイルシステムの容量見積もりする場合には、対象のファイルシステムを使用して動作するバッチアプリケーションを明確にします。
バッチアプリケーションが動作する際に必要となるファイルの最大サイズの総合計を見積もります。
見積もったファイルサイズを十分格納できるだけのファイルシステムを用意してください。
バッチアプリケーションが同時に実行する場合は、使用するファイルシステムの容量は増加しますので、増加分を考慮して容量の見積もりを行ってください。
ファイルの世代管理機能を使用する場合には、“2.3.2.5 世代ファイルの設計”で設計した世代ファイルごとの管理対象世代数を考慮して容量の見積もりを行ってください。
本製品のサーバのプラットフォームがWindows(R)の場合は、ファイル容量の事前チェック機能はサポートしていません。このため、ジョブの実行中にディスクの容量不足が発生し、アプリケーションの書込みが失敗する可能性があります。ジョブで使用するファイルの容量を十分に見積もり、ディスクの容量不足が発生することがないようにしてください。
ファイルの事前容量チェック機能を利用する場合、事前容量チェックを行うファイル資源専用のファイルシステムをファイルシステム設定ファイルに指定してください。
ファイルの事前容量チェック機能は、ファイル管理機能の内部でファイルシステムの容量管理を行います。ファイル資源専用でないファイルシステムをファイルの事前容量チェック機能で使用した場合、ファイル管理機能は正しくファイルシステムの容量管理を行えません。したがって、ファイルの事前容量チェック機能を利用する場合は、“4.2.2 ファイル管理機能の設定”でファイル資源専用のファイルシステムを設定してください。
ZFSファイルシステムについて
ファイル資源専用のファイルシステムをZFSファイルシステムに作成する場合、以下の注意事項があります。
バッチ実行サービスを開始する直前に、ZFSファイルシステム上のファイル資源の操作を行わないでください。ZFSファイルシステムの特性上、ファイル容量の変更はOSが管理するディスク容量に直ちに反映されないため、ファイル資源の操作後すぐにバッチ実行サービスを開始するとファイル管理機能が論理的な容量を管理できない場合があります。ZFSファイルシステム上のファイル資源の操作を行った場合は、dfコマンドにより、ファイルシステムの変更情報がOSの管理するディスク容量に反映されたことを確認した上で、バッチ実行サービスを開始してください。
quotaプロパティを使用して、ファイルシステムが使用できる容量を予め設定してください。ZFSファイルシステムに使用できる容量を割当てる設定をしない場合、ZFSファイルシステムの使用できる容量はZFSのプールで現在使用できる容量になります。このため、ファイル管理機能は、ファイルシステム単位に容量を管理できません。
ZFSの割り当ての設定を行わない場合の、OSの管理する容量情報の出力は以下のとおりになります。
zfs listの場合
# zfs list NAME USED AVAIL REFER MOUNTPOINT tank 232K 33.5G 24.5K /tank tank/home 128K 33.5G 29.5K /export/zfs tank/home/test1 24.5K 33.5G 24.5K /export/zfs/test1 tank/home/test2 24.5K 33.5G 24.5K /export/zfs/test2 |
df -kの場合
# df -k -F zfs ファイルシステム kbytes 使用済み 使用可能 容量 マウント先 tank 35094528 24 35094354 1% /tank tank/home 35094528 27 35094354 1% /export/zfs tank/home/test1 35094528 24 35094354 1% /export/zfs/test1 tank/home/test2 35094528 24 35094354 1% /export/zfs/test2 |
ZFSファイルシステムの詳細および設定方法は、Solarisのマニュアルを参照してください。
ファイルパスの論理化機能を使用する場合、ジョブで使用するファイルの格納先のディレクトリについて設計します。
設計要素には以下があります。
絶対パス
論理ディレクトリ
デフォルト論理ディレクトリ
論理ディレクトリ選択
絶対パス
ファイルの格納先のディレクトリを、絶対パスで指定します。
バッチジョブ定義の資源定義で[ディレクトリを使用する]を選択し、絶対パスを指定します。
論理ディレクトリおよびデフォルト論理ディレクトリ
ファイルの格納先のディレクトリを、仮想化した名前（論理ディレクトリ名、デフォルト論理ディレクトリ名）で指定します。
ファイルを格納するディレクトリと論理的なディレクトリ名の対応関係を論理ディレクトリ定義に定義してください。
論理ディレクトリを使用する場合は、バッチジョブ定義の資源定義で[論理ディレクトリを使用する]を選択し、論理ディレクトリ名を指定してください。デフォルト論理ディレクトリを使用する場合は[デフォルト論理ディレクトリを使用する]を選択します。
論理ディレクトリ選択
ファイルの格納先のディレクトリを、ファイル名の命名規約にしたがって指定します。
ファイル名と論理ディレクトリの対応関係を論理ディレクトリ定義に定義します。
論理ディレクトリ選択を使用する場合は、バッチジョブ定義の資源定義で[デフォルト論理ディレクトリを使用する]を選択します。
論理ディレクトリ、デフォルト論理ディレクトリ、および論理ディレクトリ選択については、“Interstage Job Workload Server バッチ開発ガイド”の“ファイルパスの論理化機能”を参照してください。
論理ディレクトリ定義の詳細は、“4.2.2 ファイル管理機能の設定”を参照してください。
ジョブごとに論理ディレクトリを割当てる場合のイメージを以下に示します。(例でのパス名などは、SolarisおよびLinuxの形式で記載しています。)
世代ファイルとして管理される各世代のファイルは、自動的にファイル名が付与され、すべて同じディレクトリ配下に作成されます。
ファイル名の重複を避けるために、世代ファイルを配置するディレクトリは、世代ファイル以外のファイルを格納するディレクトリとは異なるディレクトリに配置してください。
世代ファイルの運用時に、ファイルの事前容量チェック機能を利用して容量不足を検知する場合は、世代ファイルごとにファイルシステムを割り当てることで、世代ファイルの管理が容易になります。
バッチジョブ定義データベースに“バッチジョブ定義格納ディレクトリ”を利用します。バッチジョブ定義は、バッチジョブ定義格納ディレクトリに格納され、管理されます。
バッチジョブ定義格納ディレクトリは、バッチサーバに1つ必要です。
バッチジョブ定義格納ディレクトリの設計要素には以下があります。
登録するバッチジョブ定義
バッチジョブ定義格納ディレクトリの配置場所
登録するバッチジョブ定義
バッチジョブ定義格納ディレクトリに登録するバッチジョブ定義について、以下の値を決定します。
ジョブ定義登録数
バッチジョブ定義格納ディレクトリに登録するジョブ定義数を決定します。
プロシジャ定義登録数
バッチジョブ定義格納ディレクトリに登録するプロシジャ定義数を決定します。
ジョブ定義内の最大ステップ数
1つのジョブ定義内に定義する最大ステップ数を決定します。
プロシジャ定義内の最大ステップ数
1つのプロシジャ定義内に定義する最大ステップ数を決定します。
ジョブ定義内の資源定義の最大数
1つのジョブ定義内に定義する資源定義の最大数を決定します。
プロシジャ定義内の資源定義の最大数
1つのプロシジャ定義内に定義する資源定義の最大数を決定します。
ファイルのNetCOBOL連携機能のファイルの連結やダミーファイルを使用する場合も、資源定義の見積り方法に変更はありません。
バッチジョブ定義格納ディレクトリの配置場所
バッチジョブ定義格納ディレクトリを配置する、ディレクトリを決定します。
バッチジョブ定義格納ディレクトリは、上記“登録するバッチジョブ定義”で決定した値により、必要なディスク容量が変わります。
したがって、バッチジョブ定義格納ディレクトリを配置するディレクトリは、必要なディスク容量の見積もりを行い、十分に空きのあるファイルシステムにしてください。バッチジョブ定義格納ディレクトリのディスク容量が不足すると、バッチジョブ定義を追加で登録することができなくなります。
他の用途で使用するファイルシステムに、バッチジョブ定義格納ディレクトリを配置しないことを推奨します。他の要因によりディスク容量の不足が発生する可能性があります。
バッチ業務を安定して運用するために、専用のファイルシステムにバッチジョブ定義格納ディレクトリを作成することを推奨します。使用するディスクに関しても、高信頼・高性能なディスクを選択したり、RAID構成にしたりすることにより、バッチ業務の運用をより安定させることができます。
以下に当てはまるディレクトリにはバッチジョブ定義格納ディレクトリを作成することはできません。
ジョブスプールが存在するディレクトリ、およびサブディレクトリ
ジョブログスプールが存在するディレクトリ、およびサブディレクトリ
代替ジョブログスプールが存在するディレクトリ、およびサブディレクトリ
Interstage Job Workload Serverのインストールディレクトリ 、およびサブディレクトリ
絶対パスで500バイトを超えるディレクトリ
“/”ディレクトリ
“/var/spool”ディレクトリ
絶対パスで100バイトを超えるディレクトリ
UNC形式のパス名
バッチジョブ定義格納ディレクトリのディスク容量の見積もりについては、“2.3.4.1 バッチジョブ定義格納ディレクトリのディスク容量見積もり”を参照してください。
