表3-1には、KSHスクリプトで使用され、ソフトウェアを使用する前に定義しておく必要がある環境変数が一覧表示されています。
|
注意:
|
DATAおよび TMPの場合、フルパスに [a-zA-Z0-9_/.]のみを含めることができます。
|
表3-2には、バッチ・ランタイムで使用され、ソフトウェアを使用する前に定義しておく必要がある環境変数が一覧表示されています。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
m_DBTableLoadおよび m_DBTableUnloadの動作モードを示します。
これがyesに設定されている場合は、 m_DBTableLoadおよび m_DBTableUnloadはCOBOLプログラムを呼び出します。このモードでは、ロード/アンロードに関連するデータ・ファイルは、ユーティリティ DSNUTILB (ロード/アンロード)およびユーティリティ DSNTIAUL (アンロード)のz/OSと同じ形式です。COBOLプログラム名は、 schema-table-L ( DSNUTILBロード)、 schema-table-U ( DSNUTILBアンロード)または schema-table-u ( DSNTIAULアンロード)のいずれかになります。
これがyes以外の値に設定されている場合は、m_DBTableLoadおよび m_DBTableUnloadに MT_CTL_FILESが必要です。
|
|
|
MT_DSNUTILB_LOADUNLOADが yesに設定されている場合に、DBのデフォルトのスキーマを示します。デフォルト値は DEFSCHEMAです。この変数は、COBOLプログラムschema-table-Lおよびschema-table-Uのスキーマを指定するために使用されます。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
デフォルトのディレクトリはGENERATION_FILEです。データベースでGDGファイルを管理するには、値を GENERATION_FILE_DBに設定し、 MT_GDG_DB_ACCESSを適切に構成する必要があります。値がNULLとして指定されているか、不正なディレクトリ名が指定されている場合、この環境変数を使用するとエラーが発生します。
|
|
|
使用されるkshのパス( pdkshまたは ksh88のみ)。
|
•
|
他のマシンからpdkshをコピーしないでください。公式のWebサイトからソース・コードをダウンロードして、そこから pdksh実行可能ファイルをビルドするか、対応するOSリリースのイメージに含まれている正式なインストーラで pdkshをインストールしてください。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MT_JESDECRYPTは jesdecryptオブジェクト・ファイルに設定する必要があります。
|
|
|
|
|
|
ARTDPLサーバーの TUXEDO SRVGRP値。
|
表3-3には、バッチ・ランタイムで使用される、オプションの環境変数が一覧表示されています。
|
|
|
|
|
|
|
|
|
|
|
|
注意:
|
ファイル・カタログへのアクセスでは、MT_DB_LOGINよりも前にきます。ファイル・カタログDBがデータDBと同じである場合、構成が必要なのは MT_DB_LOGINのみです。それ以外の場合、両方とも構成する必要があります。
|
|
|
|
ジョブ実行の最後に、空のSYSOUTファイルをクリーンアップするかどうかを制御します。
|
|
|
ejr/CONFの下のデフォルト構成ファイル BatchRT.confのかわりに指定した構成ファイルを使用するための変数。
この変数が設定されていない場合、ejr/CONFの下の構成ファイル BatchRT.confが使用されます。
|
|
|
すべてのジョブのステップのCPU使用時間率のモニターを有効化する場合に使用される変数。MT_CPU_MON_STEP=yesを設定して、すべてのジョブのステップのCPU使用時間率のモニターを有効化します。 MT_CPU_MON_STEPが構成されていない、またはその値がyesと等しくない場合は、この機能は無効になります。
|
|
|
MT_DB_LOGIN2がnull以外の値の場合、BatchRTはrunb2 (OracleおよびDB2の並列アクセスをサポートする)を使用します。
|
|
|
|
|
|
ファイルのフルパスを指定します。このファイルは、DB SYSTEMからDB接続資格証明文字列へのマッピングを格納するために使用されます。ファイルの書式は次のとおりです。
|
•
|
<DB TYPE>が ORAの場合、 <connection string>の書式は <user>/<pwd>@<instance id>です。たとえば、 ORA01:ORA:tigger/scot@orains01のようになります。
|
|
•
|
<DB TYPE>が DB2の場合、 <connection string>の書式は <instance id> user <user> using <pwd>です。たとえば、 DB202:DB2:db2ins02 user tom using catのようになります。
|
このファイルがアクセスされるのは、DB SYSTEMが次のEJR APIで指定されている場合です。 m_ProgramExec、 m_DBTableLoad、 m_DBTableUnload、 m_ExecSQL、 m_DSNUTILBおよび m_UtilityExec。
|
注意:
|
DB SYSTEMがネスト方式で指定されている場合、外側の設定のみが有効になります。たとえば、次の場合は" ORA01"のみが有効になります(" ORA02"は無視されます)。
|
|
|
|
これがYに設定されている場合、バッチ・ランタイムは、Oracle Database表からデータをアンロードするために DSNTIAULユーティリティを提供します。このユーティリティには、DB2を使用したメインフレームの DSNTIAULユーティリティと同じ機能があります。これが" N"に構成されているか、何も構成されていない場合、バッチ・ランタイムはSQL文を実行し、特定のファイルにプレーン・テキストで出力を書き込みます。デフォルト値は、"Y"です。
|
|
|
これがYに設定されている場合、BatchRTはEJRログ・ファイルを生成し、各フェーズのログをそこに書き込みます。" N"に設定されている場合、BatchRTはEJRログ・ファイルを生成しません。デフォルト値は、" Y"です。
|
|
|
実行可能プログラムのリスト。プログラムは、runbではなく、 runbexciによって起動されます。このリスト内の各プログラムの場合、 -nが m_ProgramExecで指定されているかどうかにかかわらず、プログラムは runbexciでのみ起動されます。
|
|
|
|
|
|
|
注意:
|
MT_GENERATIONが GENERATION_FILE_DBに設定されている場合は必須です。
|
|
|
|
Yに設定されている場合、GDGの変更は1回のデータベース・アクセスでコミットされます。
Nに設定されている場合、GDGの変更は1回以上のデータベース・アクセスでコミットされます。デフォルト値はNです。
|
|
|
|
•
|
MT_GDG_USEDCB=Y: GDG用の .dcbファイルを作成します(デフォルト動作)。このモードでは、 m_FileAssign文のGDGメンバーのファイル・タイプとして LSEQまたは SEQを指定できます。
|
|
•
|
MT_GDG_USEDCB=N: GDG用の .dcbファイルを作成しません。このモードでは、GDGメンバーのファイル・タイプは LSEQのみで、 m_FileAssign文で指定したファイル・タイプは無視されます。
|
|
|
|
MT_META_DBにNULL以外の値が入っている場合、 BatchRTは MT_META_DBで定義されたデータベース・タイプをメタデータに使用します。これ以外の場合は MT_DBが使用されます。
|
|
|
Workbench refineの完全インストール・パス。JCLジョブをKSHジョブに変換するために起動されます。例:
|
|
|
環境変数REFINEDISTRIBの値。WorkbenchがJCLジョブを変換するときに使用されます。例:
|
|
|
|
|
|
BatchRT.confでは、この項目は、 m_ProgramExecによって実行されるCOBOLプログラムの SYSINおよび SYSOUTをrunbでリダイレクトするために使用されます。
SYSINが設定されている場合は、ユーティリティのstdinがファイル ${DD_SYSIN}にリダイレクトされます。 DD_SYSINが存在しない場合は、リダイレクトしないでください。例: MT_SYS_IO_REDIRECT=SYSIN
SYSOUTが設定されている場合は、ユーティリティのstdoutおよびstderrがファイル ${DD_SYSOUT}にリダイレクトされます。 DD_SYSOUTが存在しない場合は、リダイレクトしないでください。
例: MT_SYS_IO_REDIRECT=SYSOUT
SYSINと SYSOUTは同時に設定できます(その場合は、 SYSIN,SYSOUTのようにカンマで区切ってください)
例: MT_SYS_IO_REDIRECT=SYSIN,SYSOUT
デフォルト: MT_SYS_IO_REDIRECT=SYSIN,SYSOUT
|
|
|
EJRモードでこれがYに設定されている場合、BatchRTはSYSLOGファイルを生成します。" N"に設定されている場合、BatchRTはSYSLOGログ・ファイルを生成しません。デフォルト値は、" Y"です。
|
|
|
これがYに設定されている場合、SYSLOGファイルのステップ開始時刻とステップ終了時刻には時、分、秒またはミリ秒を使用します。" N"に設定されている場合、時、分または秒を使用します(ミリ秒は使用できません)。デフォルト値は「 N」です。
|
|
|
|
|
|
実行可能プログラムのリスト。これらのプログラムが存在しない場合に、そのことによってジョブが失敗しないようにします。m_ProgramExecが存在しないプログラムを呼び出しても、それらのプログラムがこのリストに指定されている場合、ジョブは続行します。例:
MT_UTILITY_LIST_UNSUPPORT=IEHINITT,IEHLIST,IEHMOVE,IEHSTATR,IEHPROGM,IEBCOMPR,IEBEDIT,IEBIMAGE,IEBUPDTE,IEBDG,IEBPTPCH
|
|
|
|
|
|
Yに設定されている場合、レコード・シーケンシャルASCIIファイルはEBCDIC順にソートされます。
Nに設定されている場合、レコード・シーケンシャルASCIIファイルはASCII順にソートされます。
|
|
|
Yに設定されている場合、 DISPLAY符号付き数値項目の符号はEBCDIC規則に従って解釈されます。
Nに設定されている場合、 DISPLAY符号付き数値項目の符号はASCII規則に従って解釈されます。
|
|
|
MT_PROG_RC_ABORT以上のリターン・コードは中断とみなされ、 MT_PROG_RC_ABORT未満のコードはコミットとみなされます。
|
表3-4には、ネイティブJCLバッチ・ランタイムで使用され、ソフトウェアを使用する前に定義しておく必要がある環境変数が一覧表示されています。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PROCおよび INCLUDEファイルの検索に使用されるディレクトリ。
|
|
|
AccLockおよび AccWaitファイルを格納するファイル同時実行性アクセスのディレクトリ。これらのファイルは、バッチ・ランタイムを実行する前に空の状態で作成する必要があります。
|
|
|
|
•
|
COBOL_MF: Micro Focus COBOLを使用することを意味します
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表3-5には、ネイティブJCLバッチ・ランタイムで使用される、オプションの環境変数が一覧表示されています。
|
|
|
|
|
ユーティリティDSNUTILBのロード・プロセスで表にレコードを挿入するためのスレッドの数を設定します。デフォルト値は5です。
|
|
|
ログ出力のレベルを制御します。次のいずれかの値を指定できます。ERROR、 WARN、 INFO、 DEBUGおよび DUMP。デフォルト値は INFOです。
|
|
|
MT_VOLUME_DEFAULTが空でない値に設定された場合、カタログ機能が有効になります。これは、新しいデータセットの作成時にボリュームが指定されない場合、ボリューム値として使用されます。 MT_VOLUME_DEFAULTが設定されない場合、カタログ機能は無効になります。
|
|
|
|
|
|
|
|
|
|
|
|
MT_DB_LOGIN2がnull以外の値の場合、BatchRTはOracleおよびDB2の並列アクセスを使用します。
|
|
|
ファイル名をフルパスで指定します。このファイルは、DB SYSTEMからDB接続資格証明文字列へのマッピングを格納するために使用されます。ファイルの書式は次のとおりです。
|
•
|
<DB TYPE>が ORAの場合、 <connection string>の書式は <user>/<pwd>@<instance id>です。たとえば、 ORA01:ORA:tigger/scot@orains01のようになります。
|
|
•
|
<DB TYPE>が DB2の場合、 <connection string>の書式は <instance id> user <user> using <pwd>です。たとえば、 DB202:DB2:db2ins02 user tom using catのようになります。
|
MT_DB2_SYSTEM_MAPPINGが定義されている場合、 DB SYSTEMからDB接続資格証明文字列へのマッピング機能が有効になります。それ以外の場合、この機能は無効になります。
|
|
|
これがYに設定されているか、何も構成されていない場合、バッチ・ランタイムは、Oracle Database表からデータをアンロードするために DSNTIAULユーティリティを提供します。このユーティリティには、DB2を使用したメインフレームの DSNTIAULユーティリティと同じ機能があります。これが" N"に構成されている場合、バッチ・ランタイムはSQL文を実行し、特定のファイルにプレーン・テキストで出力を書き込みます。デフォルト値は、" Y"です。
|
|
|
指定されない場合、MT_COBOLによって異なります。
|
|
|
符号付き数値DISPLAY項目の解釈方法を指定します。
|
•
|
Y: デフォルト。EBCDIC規則に従って解釈されます。
|
|
|
|
|
|
|
|
|
|
ARTCOBRUNが実行するユーティリティについて SYSINおよび SYSOUTがリダイレクトされるかどうかを指定します。
|
•
|
SYSINが設定された場合、ユーティリティの stdinはファイル ${DD_SYSIN}にリダイレクトされます。
|
|
•
|
SYSOUTが設定された場合、ユーティリティの stdoutおよび stderrはファイル ${DD_SYSOUT}にリダイレクトされます。
|
|
•
|
SYSINと SYSOUTの両方を同時に設定できます(その場合は、 SYSIN,SYSOUTのようにカンマで区切ってください)。
|
|
|
|
MT_PROG_RC_ABORT以上のリターン・コードは中断とみなされ、 MT_PROG_RC_ABORT未満のコードはコミットとみなされます。
|
|
2.
|
MT_ACC_FILEPATHは共有ストレージ(NFS)に置かれ、そのストレージはドメイン上のすべてのマシンで同じマウント・ポイントを持つ必要があります。これは、ファイル・ロッキングの制御ファイルがこのディレクトリに置かれるためです。さらに、ユーザーは、このディレクトリの下のAccLockとAccWaitファイルを、ジョブを実行しているプロセスの実効ユーザーが読み書きできるようにしておく必要があります。
|
各フェーズの終わりでJUMP_LABEL変数が更新され、次に実行されるフェーズのラベルを提供します。
表3-6に示されているように、スクリプトの必須の部分(最初と最後の部分)は太字で表示され、スクリプトの機能部分(中間の部分)は通常の書式で表示されます。スクリプトのオプションの部分には、次に示すように、ラベル、分岐および手順の終了が含まれる必要があります。変更されるスクリプトの項目は、斜体で表示されます。
|
|
|
|
|
|
m_JobBegin -j JOBNAME -s START -v 2.00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
END_JOBを参照する必要のあるラベルのためです。「_」が必須ですが、これはこの文字がz/OS上で禁じられているためです。
|
|
|
|
|
|
|
|
|
|
|
|
|
リスト3-1に、Kornシェル・スクリプトのサンプルを示します。
ABENDルーチン(
ILBOABN0、
CEE3ABD、および
ART3ABD)を実行中のプログラムから呼び出して、このプログラムを強制的に中止し、
abendコードをKSHスクリプトに返すことができます。たとえば、
ILBOABN0は、ソースおよびバイナリの
gntファイルの両方として提供されます。これはユーザー定義の任意のCOBOLプログラムから直接呼び出せます。
DISPLAY "USER: HELLO USER".
CALL "ILBOABN0" USING RT-PARAM.
DISPLAY "USER: CAN'T REACH HERE WHEN ILBOABN0 IS CALLED".
外部プロシージャではm_ProcBegin関数と
m_ProcEnd関数を使用する必要がありません。単に
リスト3-7に示すプロシージャの一部であるタスクをコーディングします。
「スクリプト実行フェーズ」で説明したとおり、Kornシェル・スクリプトは、変換フェーズで、
m_ProcInclude関数の呼出しのたびに、プロシージャのコードをインクルードして展開されます。この操作の結果として展開されたKornシェル・スクリプトは、操作後も、
「スクリプトの一般的な構造」で定義された、スクリプトの一般的な構造のルールに従っている必要があります。
リスト3-8に示すように、前述の原則に従っていれば、ストリーム内プロシージャまたは外部プロシージャを、呼出しジョブのいかなる場所でも使用できます。
「ベスト・プラクティス」で規定されているとおり、プロシージャをコーディングするこの方法は、主にz/OS JCL変換の結果として得られるKornシェル・スクリプトをサポートするために用意されており、ターゲット・プラットフォーム用に新しく作成されるKornシェル・スクリプトではお薦めできません。
リスト3-11は、
m_FileOverride関数を使用して論理ファイル
SYSUT1の割当てを置換する方法を示しています。
リスト3-13に示すように、
m_CondIf関数は、常に関係式をパラメータとして持つ必要があります。この関数は、15回までネストできます。
m_CondExec関数は、手順の実行を条件付けるために使用されます。
m_CondExecは、少なくとも1つの条件をパラメータとして持つ必要があり、同時に複数の条件を持つこともできます。複数の条件の場合、手順は、すべての条件が満たされる場合のみ実行されます。
リスト3-14に示すように、
m_CondExec関数は、関係する手順の中で最初に呼び出される関数である必要があります。
|
•
|
m_JobBegin関数で指定された開始ラベル: このラベルは、通常、スクリプトの最初のラベルですが、ユーザーが特定の手順からスクリプトの実行を開始する場合は、スクリプト内に存在するいかなるラベルにも変更できます。
|
|
•
|
各手順でJUMP_LABEL変数に割り当てられる値: この割当ては各手順に必須ですが、その値が必ず次の手順のラベルであるとはかぎりません。
|
|
•
|
m_CondExec、 m_CondIf、 m_CondElse および m_CondEndif関数の使用方法。 「手順実行の条件付け」を参照してください。
|
ファイルはm_FileBuildまたは
m_FileAssign関数を使用して作成されます。
m_FileAssign関数を介して定義される環境変数は、
DD_IFNと命名されます。この命名規則は、Micro Focus COBOLが内部ファイル名を外部ファイル名にマップするために使用する変数であるという事実に基づいています。
割当てが済んだファイルは、${DD_IFN}変数を使用することにより、ファイルを処理するバッチ・ランタイム関数のいずれかに、引数として渡すことができます。
|
1.
|
環境変数MT_ACC_FILEPATHを使用して、同時アクセス制御メカニズムで必要なロック・ファイル用のディレクトリを指定します。
|
|
•
|
AccLockおよび AccWaitのファイル名では、大文字と小文字が区別されます。
|
|
•
|
ejr/CONF/BatchRT.confの次の2行は、コメント・アウトする必要があります。
|
GDGファイルは、m_GenDefineを介して定義または再定義されます。GDGの定義または再定義の操作は即時にコミットされ、ロールバックできません。
リスト3-17に示すように、1行目ではGDGを定義し、その最大世代数を15に設定します。2行目では同じGDGの最大世代数を30に再定義します。3行目では-sオプションを指定せずにGDGを定義します(その最大世代数は9999に設定されます)。4行目ではGDGを暗黙的に定義し、その最大世代数を9999に設定します。5行目ではGDGユース・モデル・ファイル
$DATA/FILEを定義します。このファイルは、GDGファイルまたは通常のファイルです。
前述の例では、$DATA/GDG1に1、2、4という番号の3つのGDSがそれぞれあるものとします。対応するGDSファイルが次のようにリストされます。
前述のジョブの実行後、$DATA/GDG1には1、2、4、5、9という番号の5つのGDSがそれぞれ含まれます。対応するGDSファイルが次のようにリストされます。
GDGで既存の世代ファイル(GDS)を参照するには、-d OLD/SHR/MOD,…および
-g 0、
-g allまたは
-g -nというパラメータを指定して
m_FileAssignを呼び出します。
-g 0は最新世代を、
-g allはすべての世代ファイルを、
-g -nは最新世代(0世代)からn世代逆算した世代ファイルを参照します。
たとえば、GDG1に1、4、6、7、9、10という番号の6つのGDSがそれぞれ含まれている場合、GNとRGNのマッピングは次のとおりです。
次のジョブでは、RGN=-1を使用してGNが9に等しいGDSを参照し、
RGN=-4を使用してGNが4に等しいGDSを参照します。
m_FileAssignの
DISPOSITIONフィールドにDELETEが指定された場合、現在の手順が終了した後に対応するGDSが削除され、GNとRGNのマッピングが変更されます。変更後のマッピングは次の手順で表示されます。
たとえば、GDG1に1、4、6、7、9、10という番号の6つのGDSがそれぞれ含まれている場合、GNとRGNのマッピングは次のとおりです。
次のジョブでは、RGN=-1を使用してGNが9に等しいGDSを参照し、
RGN=-4を使用してGNが4に等しいGDSを参照します。
リスト3-26に示すように、GDGベース名を指定して
m_FileDeleteを呼び出すことで、GDG全体を削除できます。この方法で、すべてのGDGのGDSが適切に削除されます。GDGの削除の操作は即時にコミットされ、ロールバックできません。
たとえば、GDG1には1、4、6、7、9、10という番号の6つのGDSがそれぞれ含まれています。
MT_GENERATION変数は、GDGファイルの管理方法を指定します。
*.gensファイルでGDGを管理するには、値を
GENERATION_FILEに設定する必要があります。
|
注意:
|
この機能を有効にするには、MT_GENERATIONを GENERATION_FILE_DBに、 MT_DBを DB_ORACLEまたは DB_DB2LUWに(または MT_META_DBを DB_ORACLEもしくは DB_DB2LUWに)設定し、 MT_GDG_DB_ACCESSをOracle DatabaseまたはDB2データベースにアクセスするための有効なデータベース接続文字列に設定する必要があります。
|
表3-5では、バッチ・ランタイムによって管理されるGDGごとの一般的な管理を示しています。この表では、各行が1つのGDGを表しています。すべてのGDGファイルでは、1つの
GDG_DETAIL表が共有されています。
表3-6では、すべてのGDG世代ファイルの詳細情報を示しています。この表では、各行がGDGの1つの世代ファイルを表しています。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
主キー: GDG_BASE_NAME+ GDG_ABS_NUM
|
GDG_FILE_NAME (物理世代ファイル名)は、
GDG_DEFINEの
GDG_BASE_NAMEからと
GDG_DETAILの
GDG_ABS_NUMから構成される可能性があるため、表
GDG_DETAILには格納されません。
表3-7では、世代ファイル名のルールを示しています。
この変数は、GENERATION_FILE_DBに設定されている場合、
MT_GENERATIONとともに使用され、有効なデータベース・ログイン・アカウントで設定する必要があります。Oracleデータベースにアクセスするには、たとえば
scott/tiger@orclのように、
userid/password@sidの書式で指定する必要があります。
GENERATION_FILE_DBに設定されている場合は、
MT_GENERATIONとともに使用されます。これは、コミット・フェーズでデータベースにGDG変更をコミットする方法を示します。"
Y"に設定されている場合、GDGの変更は1回のデータベース・アクセスでコミットされます。"N"に設定されている場合、GDGの変更は、1回または複数のデータベース・アクセスを使ってコミットされます。
.dcbファイルは、
-t <file type>および
-r <record length>の2つの値をとります。
最初の世代ファイルを作成するには、
m_FileAssignで
-t <file type>に
LSEQまたは
SEQのどちらかを指定する必要があります。
job kshファイルにファイル・タイプを指定しなかった場合は、デフォルトで
LSEQが使用されます。
SEQファイルの場合、この値は必須で、数値を1つ、または
number1-number2の形式で指定する必要があります。
LSEQファイルの場合、この値はオプションです。設定する場合、この値には数値を1つ、または"
number1-number2"の形式で指定する必要があります。
最初の世代ファイルをm_FileAssign -g +1で作成するときに、GDGデータ・セット用の
.dcbファイルを作成します。
|
注意:
|
m_FileAssignではなく m_GenDefineを使用してGDGを作成する場合、 .dcbファイルは、 m_FileAssign -g +1を使用して世代ファイルが作成されるまで存在しません。
|
.dcbファイルが作成されると、
m_FileAssignによって最初の世代ファイルが再作成されないかぎり、そのコンテンツはその後実行される他の
m_FileAssign文によって変更されることはありません。
GDGがm_FileDeleteで削除されると、対応する
.dcbファイルが自動的に削除されます。
m_FileAssign -d OLD SYSIN $
{SYSIN}/SYSIN/MUEX07
MT_DB_LOGINの値は、
dbuser/dbpasswd[@ssid]または「
/」という形式を使用する必要があります。
|
注意:
|
RDBMSが、データベース接続ユーザーに対してUNIX認証を使用でき、RDBMS認証を使用できないように構成されている場合は「 /」を使用する必要があります。 |
リスト3-30に示すように、実行される主プログラムはRDBMSを直接使用しないが、その後に続くサブプログラムのいずれかが使用する場合は、
-bオプションも使用する必要があります。
m_ProgramExec関数が送信する可能性のあるファイルは次の3種類です。
.gntファイルが
$COBPATH (Micro Focus COBOLの場合)、または
$COB_LIBRARY_PATH (COBOL-ITの場合)に存在することを確認してください。
呼出し可能な共有ライブラリ・ファイルが$COBPATH (Micro Focus COBOLの場合)、または
$COB_LIBRARY_PATH (COBOL-ITの場合)、もしくはシステム・ライブラリのファイル検索パス(
LIBPATH、
LD_LIBRARY_PATHなど)に存在することを確認してください。
m_ProgramExecは、COBOLプログラム(
.gnt)、呼出し可能な共有ライブラリ内のCプログラム(
.so)、その他の実行可能プログラムの順にプログラムの成果物の種類を決定します。COBOLプログラムが実行されると、
m_ProgramExecは同じ名前を持つ別のプログラムを実行しません。たとえば、
ProgA.gntの実行後、
ProgA.soなど、
ProgAという名前のプログラムは実行されません。
.gntファイルと
.soファイルについては、
m_ProgramExecは
runbプログラムを起動して、実行します。ARTは、次のような
runbを提供します。
runbプログラムは、データベース・ライブラリを使用してコンパイルされたランタイムで、
runbatchプログラムを実行します。
runbatchプログラムには次の役割があります。
この例では、ファイルの内容${DATA}/MTWART.JCL.INFO (ddname
SYSUT1)が、オプション
-w INTRDRを使用しているファイル(ddname
SYSUT2)にコピーされ、その後、このファイル(ddname
SYSUT2)が送信されます。
COBOLプログラムにより生成される
INTRDRジョブは、リアルタイムで自動的に送信できます。COBOLプログラムが
INTRDRを閉じると、ジョブ
INTRDRはその時に実行されている作業の完了を待たずに、即座に送信されます。この機能を有効化するには、ファイル・ハンドラ
ARTEXTFH.gntをCOBOLプログラムにリンクする必要があります。
m_* APIでそのユーザー定義のエントリ/終了関数を呼び出すかどうかは、
m_*_Beginと
m_*_Endが
ejr/USER_EXITにあるかどうかで決まります。
一般的なユーザー・エントリ/終了APIのペア、mi_UserEntryおよび
mi_UserExitは、各外部APIのエントリおよび終了ポイントで呼び出されます。これらのAPIに対する引数は、それらを呼び出す関数名と、その関数の元の引数リストで構成されます。これら2つのAPIは変更する必要はありませんが、m_*外部APIのカスタム・エントリ/終了を指定することは必要です。
mi_UserEntryおよび
mi_UserExitは、
ejr/COMMONにあります。
CONF/Messages.confで定義されている各ログ・メッセージは、
表3-8に示すように、6つのフィールドで構成されます。
表3-9では、バッチ・ランタイムに用意されているログ・メッセージのレベルを示しています。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
レベル3と、-d regexpオプションに対応する高レベル関数と同じ
|
|
|
7と、-d regexpオプションに対応するテクニカル・レベル関数と同じ
|
|
|
|
表3-10では、汎用ログ・ヘッダーの指定に使用できる変数を示しています。
|
|
|
|
|
|
|
|
|
|
|
ジョブ・スクリプトでm_JobBeginによって割り当てられたジョブの名前。
|
|
|
|
|
|
|
|
|
m_ProcIncludeによってプロセスから含められたコードが実行中の場合はそのプロセスの名前。それ以外の場合は空。
|
MT_LOG_HEADERの値がnull文字列でなければ、その内容はログ・ヘッダーとして出力される実際の値を取得するためのシェル・ステートメントとして評価され、それ以外の場合、この機能は無効です。
|
注意:
|
MT_LOG_HEADERに対して構成された文字列は、ソース・コードでシェル・ステートメントとして処理され、ログ・ヘッダーとして使用される対応文字列を生成する evalコマンドによって解釈されます。
|
構文の内部: eval mt_MessageHeader=\"${MT_LOG_HEADER}\"
|
•
|
MT_LOG_HEADERで使用される変数はすべて、 ${}で囲む必要があります。たとえば、 ${ MTI_JOB_STEP }のようになります。
|
|
•
|
MT_LOG_HEADERで使用されるコマンド行はすべて、 $()で囲む必要があります。たとえば、 $(date '+%Y%m%d:%H%M%S')のようになります。
|
各識別子の最後の文字列%sは、それがログ・ファイルに書き込まれることを表します。その値は、
CONF/Batch.confで定義されている次の変数を使用して構成できます。詳細は、
表3-12を参照してください。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注意:
|
操作は、ソース・コード(FileCopy source、 FileCopy Destinationおよび FileDeleteなど)にハードコードされています。
|
|
|
これらのMT_LOG_FILE_*変数に文字列を構成するには、プレースホルダを対応する値に置換します(文字列置換)。結果はシェル・ステートメントとして処理され、
evalコマンドにより解釈され、ログに書き込む対応文字列を生成します。
構文の内部: eval mt_FileInfo=\"${MT_LOG_FILE_INFO}\"
|
•
|
プレースホルダの置換後、MT_LOG_FILE_*は evalに対して有効なシェル・ステートメントであることが必要で、一重引用符で囲む必要があります。
|
|
•
|
MT_LOG_FILE_*では、 表3-11のプレースホルダのみを使用できます。
|
|
•
|
MT_LOG_HEADERで使用されるコマンド行はすべて、 $()で囲む必要があります。たとえば、 $(ls -l --time-style=+'%Y/%m/%d %H:%M:%S' --no-group <%FULLPATH%> )のようになります。
|
FileInfoメッセージのレベルがバッチ・ランタイムに対して指定されたメッセージ・レベルと等しいかそれより低い場合、および
MT_LOG_FILE_*がnull文字列に設定されている場合、
FileInfoメッセージは、ジョブ・ログに表示されません。
MT_LOG_FILE_*が、ファイル情報を表示されなくする間違ったコマンドに設定されている場合も、FileInfoメッセージはジョブ・ログで表示されませんが、ジョブの実行には影響がありません。
一部の関数(m_JobBegin、
m_JobEnd、
m_PhaseBegin、
m_PhaseEnd)には、選択されたジョブ・スケジューラとの関係で行われる特定のアクションを挿入するためのエントリ・ポイントが用意されています。
環境変数MT_DB_LOGINを設定する必要があることに注意してください(データベース接続ユーザー・ログイン)。
SYSINファイルにはSQLリクエストを含める必要があり、ユーザーはデータベース・ターゲットに関するコンテンツを検証する必要があります。
|
•
|
bdb:yesを指定して、COBOLプログラムをCOBOL-ITコンパイラでコンパイルします。
|
|
•
|
BDBで必要なため、DB_HOMEを正しく設定します。 DB_HOMEは、BDBによって一時ファイルが配置される場所を指します。
|
設定項目JOBLANG=JCLを
jesconfigファイルに追加する必要があります。
オプション-Iを次のように使用して、JCLジョブを送信できます。
このenvファイル内のすべての項目は、次のように
"<NAME>=<VALUE>"形式に従う必要があります
JCL変換ログは$JESROOT/<JOBID>/LOG/<JOBID>.traceです。
表3-17に、サポートされるJCL文を示します。
表3-18に、サポートされるユーティリティを示します。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PROCおよび INCLUDEファイルのディレクトリ
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
たとえば、MYUTILITYユーティリティを定義する場合は、
ADDUTILITYLIST=MYUTILITYを指定する必要があります。複数のユーティリティを定義する場合は、カンマ(
,)を使用してユーティリティを区切って
ADDUTILITYLIST=MYUTILITY1,MYUTILITY2,…と指定する必要があります。
|
•
|
-rを指定して -iを指定しないと、このコマンドは個別レポートのすべてについてカテゴリ・レポートおよびサマリー・レポートを -dディレクトリに生成します。
|
|
•
|
-rを指定して -iを指定すると、このコマンドは -iで指定されるすべてのジョブの個別レポートを生成し、その後これらの個別レポートについてのみカテゴリ・レポートおよびサマリー・レポートを生成します。
|
|
•
|
-rを指定しないと、カテゴリ・レポートもサマリー・レポートも生成されません。
|
|
注意:
|
artjclchkツールを同じ -iおよび -dオプション値を使用して2回実行すると、2回目の実行の結果で最初の実行の結果が置き換えられます。
|
artjclchkが生成するレポート・ファイルは3種類あります。
サマリー・レポート・ファイルは、カテゴリ・レポートの簡略版です。artjclchkにより生成されます。カテゴリ・レポート・ファイルと異なり、サマリー・レポート・ファイルは問題と問題の出現数のみを記録します。サマリ・レポート・ファイルは対応するカテゴリ・レポート・ファイルと同じ名前ですが、"
Occurences"はありません。
このファイルの名前は<JOBFILENAME>.rptの形式で、各行のフィールドがカンマで区切られています。これらのフィールドについて、次の表を参照してください。
|
•
|
表3-21は IKJEFTxxユーティリティのフィールドを示します
|
|
•
|
表3-22はその他のユーティリティのフィールドを示します
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PROC、 INCLUDE、 PROGRAMおよび DATASETオブジェクトが検出されたかされなかったかを識別します
|
|
|
STATEMENT、 PARAMおよび UTILITYオブジェクトがサポートされているかいないかを識別します
|
|
|
SYMBOLオブジェクトが定義されているかいないかを識別します
|
|
|
STATEMENTまたは PARAMが認識されるが無視されることを識別します
|
|
|
STATEMENTまたは PARAMが認識されないことを識別します
|
|
|
|
|
|
|
オブジェクト名。これは、PROC名、 INCLUDE名、 PROGRAM名、 UTILITY名、 PARAM名、 DATASET名またはその他のオブジェクト名になります
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PROGRAMオブジェクトが検出されたかされなかったかを識別します
|
|
|
COMMAND、 PARAMおよび UTILITYオブジェクトがサポートされているかいないかを識別します
|
|
|
COMMANDまたは PARAMが認識されるが無視されることを識別します
|
|
|
COMMANDまたは PARAMが認識されないことを識別します
|
|
|
|
|
|
|
オブジェクト名。これは、PROC名、 INCLUDE名、 PROGRAM名、 UTILITY名またはその他のオブジェクト名になります
|
|
|
|
|
|
|
|
行の場所を識別します。FILEおよび LINEの場所はJCLジョブ自体に関連しており、たとえば、現在のユーティリティが起動した STEPの場所です。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
COMMANDおよび PARAMオブジェクトがサポートされているかいないかを識別します
|
|
|
COMMANDまたは PARAMが認識されるが無視されることを識別します
|
|
|
COMMANDまたは PARAMが認識されないことを識別します
|
|
|
|
|
|
|
オブジェクト名。これは、PROC名、 INCLUDE名、 PROGRAM名、 UTILITY名またはその他のオブジェクト名になります
|
|
|
|
|
|
|
|
行の場所を識別します。FILEおよび LINEの場所はJCLジョブ自体に関連しており、たとえば、現在のユーティリティが起動した STEPの場所です。
|
|
|
|
レポート行を生成するユーティリティの名前、たとえばIEBGENER、 SORTおよび PKZIPを識別します
|
|
|
|
|
|
|
|
|
|
|
|
|
項目タイプ。これはUTILITY、 STATEMENT、 COMMANDまたは PARAMになります。
|
|
|
|
|
|
|
|
|
|
|
|
|
サマリー・レポート・ファイルは、カテゴリ・レポートの簡略版です。artjclchkにより生成されます。カテゴリ・レポート・ファイルと異なり、サマリー・レポート・ファイルは問題と問題の出現数のみを記録します。サマリ・レポート・ファイルは対応するカテゴリ・レポート・ファイルと同じ名前ですが、"
Occurences"はありません。
|
|
|
|
|
|
|
|
項目タイプ。これはUTILITY、 STATEMENT、 COMMANDまたは PARAMになります。
|
|
|
|
|
|
|
|
|
|
バッチ・ランタイムのm_SetJobExecLocation APIにより、ユーザーはNJEサポートを使用するKSHジョブを開発できます。例:
API m_JobSetExecLocationでジョブ実行グループとして指定されているサーバー・グループ名を指定する場合は、次のことを確認してください。
|
•
|
少なくとも1つのARTJESINITIATORサーバーがそのサーバー・グループにデプロイされている必要があります。
|
NJEサポートがjesconfigで無効化されると、
m_SetJobExecLocation <SvrGrpName>文がTuxJESに無視され、ジョブは任意のサーバー・グループ内の任意の
ARTJESINITIATORで実行される可能性があります。
MPモードでは、MT_TMPをNFSで構成する必要があり、Tuxedoドメイン内のすべてのノードが同じ値の
MT_TMPを持ち、これを共有する必要があります。
MT_TMPは、ファイル
$MT_ROOT/CONF/BatchRT.confで構成するか、各ノードでtlistenが開始する前に環境変数としてエクスポート(
export)できます。
NJESUPPORTが
jesconfigで有効な場合、
EXECGRPという名前の新しいキューを、既存のキュー・スペース
JES2QSPACEに作成する必要があります。
EXECGRPが作成されないと、JESはジョブを処理できません。
前述の例では、ジョブTEST1は現在のジョブによって送信され、JESのTuxedoサーバー・グループ
ATLANTAに属する
ARTJESINITIATORによって実行されます。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
主キー: PK_ART_BATCH_CATALOG
|
これがyesに設定されると(MT_USE_FILE_CATALOG=yes)、ファイル・カタログ機能は有効です。それ以外の場合、この機能は無効です。
Db2では、この値はyour-database USER your-username USING your-password (例:
db2linux USER db2svr USING db2svr)です。
ファイル・カタログへのアクセスの際、
MT_CATALOG_DB_LOGINは
MT_DB_LOGINよりも優先されます。ファイル・カタログDBがデータDBと同じである場合、構成が必要なのは
MT_DB_LOGINのみです。それ以外の場合、両方とも構成する必要があります。
CreateTableCatalog[Oracle|Db2].shまたは
DropTableCatalog[Oracle|Db2].shを使用して、データベース表を新規作成または削除できます。
MT_REXX_PATHのデフォルト値はありません。これは、すべてのREXX EXECが存在するメイン・パスで設定する必要があります。REXXプログラムを
${MT_REXX_PATH}の下の適切なサブディレクトリに入れます。これらのサブディレクトリは、REXXプログラムのあるメインフレーム上のPDSに対応します。
SYSEXECが定義されている場合、BatchRTは、
m_ProgramExecが実行するプログラムを
REXX EXECとして受け入れます。
