構成ファイルはバッチ・ランタイムのCONFディレクトリ内に実装されます。
このような変数はバッチ・ランタイムを使用する前に設定する必要があります。
このファイルにはRTBatchによって使用されるメッセージが含まれます。
このファイルには、メッセージに関連付けられた内部コードが含まれます。
このファイルには、メッセージに関連付けられKSHスクリプトに返されるリターン・コードが含まれます。
このファイルには、ライターの使用法とサンプルが収められています。
ORACLE_SID
、COBDIR
、LIBPATH
、COBPATH
など、いくつかの変数は、様々なコンポーネントで共有されている変数なので、現在のドキュメントでは説明しません。
詳細は、Rehosting Workbenchインストレーション・ガイドを参照してください。
表3-1には、KSHスクリプトで使用され、ソフトウェアを使用する前に定義しておく必要がある環境変数が一覧表示されています。
注: | DATA およびTMP の場合、フル・パスに[a-zA-Z0-9_/.] のみを含めることができます。 |
表3-2には、バッチ・ランタイムで使用され、ソフトウェアを使用する前に定義しておく必要がある環境変数が一覧表示されています。
AccLockおよびAccWaitファイルを格納するファイル同時実行性アクセスのディレクトリ。これらのファイルは、バッチ・ランタイムを実行する前に空の状態で作成する必要があります(BatchRT.conf構成ファイルを参照してください)。
|
|||
- 実行するCOBOLプログラムが何もなく、COBOL製品を使用しない場合、「COBOL_NONE」。また、この設定では、GDG、LSEQ、固定幅のSEQ、およびPDSの各ファイルのみがサポートされます。
(BatchRT.conf構成ファイルを参照)
|
|||
(BatchRT.conf構成ファイルを参照)
|
|||
|
|||
(BatchRT.conf構成ファイルを参照)
|
|||
(BatchRT.conf構成ファイルを参照)
|
|||
(BatchRT.conf構成ファイルを参照)。
|
|||
(BatchRT.conf構成ファイルを参照)
|
|||
(BatchRT.conf構成ファイルを参照)
|
|||
(BatchRT.conf構成ファイルを参照)
|
|||
(BatchRT.conf構成ファイルを参照)
|
注: | 次の環境変数の場合、フル・パスに[a-zA-Z0-9_/.] のみを含めることができます。 |
表3-3には、バッチ・ランタイムで使用される、オプションの環境変数が一覧表示されています。
ユーザーがバッチ・ランタイム(EJR)を使用して異なるマシンからジョブを実行する(リソース(通常はファイル)を共有する場合がある)か、MPモードのTuxJESドメインを構成し、TuxJESが提供するユーティリティを使用して任意のノードからジョブを送信する場合、EJRを特別に構成して、MPモードで問題なく機能するようにする必要があります。
後者の場合、ノードAから送信されたジョブは、ノードBで実行される可能性があり、実行順序はまったくランダムです。同様に、異なるノードから送信されたこれらのジョブは、リソースを共有する可能性があります。
この項では、MPモードをサポートするためのバッチ・ランタイム(EJR)構成の詳細を具体的に説明します。
MT_ACC_FILEPATH
は共有ストレージ(NFS)に置かれ、そのストレージはドメイン上のすべてのマシンで同じマウント・ポイントを持つ必要があります。これは、ファイル・ロッキングの制御ファイルがこのディレクトリに置かれるためです。さらに、ユーザーは、このディレクトリの下のAccLockとAccWaitファイルを、ジョブを実行しているプロセスの実効ユーザーが読み書きできるようにしておく必要があります。
Oracle Tuxedo Application Runtime for Batchは、ジョブの異なる実行フェーズが明確に識別されるスクリプト・モデルを提案することによって、Kornシェル・スクリプトを正規化します。
Oracle Tuxedo Application Runtime for Batchスクリプトは、固有の書式を尊重することで、KSH (JOB)の異なるフェーズの定義とチェイニングを可能にします。
バッチ・ランタイム内のフェーズは、ソース・システム上のアクティビティまたは手順に対応します。
フェーズはラベルによって識別され、次のフェーズによって区切られます。
各フェーズの終わりでJUMP_LABEL
変数が更新され、次に実行されるフェーズのラベルを提供します。
次の例では、最後の機能フェーズが、JUMP_LABEL
をJOBEND
に設定します。このラベルにより、ジョブの正常終了(フェーズ・ループを終了)が可能になります。
表3-4に示されているように、スクリプトの必須の部分(最初と最後の部分)は太字で表示され、スクリプトの機能部分(中間の部分)は通常の書式で表示されます。スクリプトのオプションの部分には、次に示すように、ラベル、分岐および手順の終了が含まれる必要があります。変更されるスクリプトの項目は、斜体で表示されます。
リスト3-1に、Kornシェル・スクリプトのサンプルを示します。
#!/bin/ksh
#@(#)--------------------------------------------------------------
#@(#)-
m_JobBegin -j METAW01D -s START -v 1.00 -c A
while true ;
do
m_PhaseBegin
case ${CURRENT_LABEL} in
(START)
# -----------------------------------------------------------------
# 1) 1st Step: DELVCUST
# Delete the existing file.
# 2) 2nd Step: DEFVCUST
# Allocates the Simple Sample Application VSAM customers file
# -----------------------------------------------------------------
#
# -Step 1: Delete...
JUMP_LABEL=DELVCUST
;;
(DELVCUST)
m_FileAssign -d OLD FDEL ${DATA}/METAW00.VSAM.CUSTOMER
m_FileDelete ${DD_FDEL}
m_RcSet 0
#
# -Step 2: Define...
JUMP_LABEL=DEFVCUST
;;
(DEFVCUST)
# IDCAMS DEFINE CLUSTER IDX
m_FileBuild -t IDX -r 266 -k 1+6 ${DATA}/METAW00.VSAM.CUSTOMER
JUMP_LABEL=END_JOB
;;
(ABORT)
break
;;
(END_JOB)
break
;;
(*)
m_RcSet ${MT_RC_ABORT} "Unknown label : ${JUMP_LABEL}"
break
;;
esac
m_PhaseEnd
done
m_JobEnd
#@(#)--------------------------------------------------------------
記号は内部スクリプト変数で、スクリプト文を簡単に修正できるようにします。リスト3-2で示すように、m_SymbolSet
関数によって値が記号に割り当てられます。記号を使用するには、次の構文を使用します: $[symbol]
注: | 中カッコ({})のかわりに大カッコ([])を使用するのは、記号と標準のKornシェル変数を明確に区別するためです。 |
(STEP00)
m_SymbolSet VAR=40
JUMP_LABEL=STEP01
;;
(STEP01)
m_FileAssign -d SHR FILE01 ${DATA}/PJ01DDD.BT.QSAM.KBSTO0$[VAR]
m_ProgramExec BAI001
手順(フェーズとも呼ばれる)は、普通は、機能(またはテクニカル)アクティビティの実行を可能にするバッチ・ランタイム関数に対する呼出しの、一貫性の取れたセットです。
最もよく使用される手順は、アプリケーションまたはユーティリティ・プログラムを実行するものです。これらの種類の手順は、通常、1つ以上のファイル割当て操作と、それに続く、目的のプログラムの実行で構成されます。ファイル割当て操作はすべて、リスト3-3に示すプログラム実行操作に先行する必要があります。
(STEPPR15)
m_FileAssign -d SHR INFIL ${DATA}/PJ01DDD.BT.QSAM.KBPRO099
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBPRO001
m_OutputAssign -c “*” SYSOUT
m_FileAssign -i LOGIN
IN-STREAM DATA
_end
m_FileAssign -d MOD LOGOUT ${DATA}/PJ01DDD.BT.QSAM.KBPRO091
m_ProgramExec BPRAB001 "20071120"
JUMP_LABEL=END_JOB
;;
ABEND
ルーチン(ILBOABN0
、CEE3ABD
、およびART3ABD
)を実行中のプログラムから呼び出して、このプログラムを強制的に中止し、abend
コードをKSHスクリプトに返すことができます。たとえば、ILBOABN0
は、ソースおよびバイナリのgnt
ファイルの両方として提供されます。これはユーザー定義の任意のCOBOLプログラムから直接呼び出せます。
(STEPPR15)
m_ProgramExec USER
JUMP_LABEL=END_JOB
;;
PROCEDURE DIVISION.
PROGRAM-BEGIN.
DISPLAY "USER: HELLO USER".
MOVE 2 TO RT-PARAM.
CALL "ILBOABN0" USING RT-PARAM.
DISPLAY "USER: CAN'T REACH HERE WHEN ILBOABN0 IS CALLED".
PROGRAM-DONE.
...
Oracle Tuxedo Application Runtime for Batchには、プロシージャを定義して、使用するために一連の関数が用意されています。これらのプロシージャは、一般に、z/OS JCLのプロシージャと同じ原則に従います。
z/OS JCL規則とは異なり、ストリーム内プロシージャは主要JOBの末尾の後に記述する必要があります。つまり、ジョブに属するすべてのストリーム内プロシージャは、関数m_JobEnd
の呼出しの後に出現する必要があります。
Kornシェル・スクリプトのストリーム内プロシージャは、常にまずm_ProcBegin
関数を呼び出し、次にプロシージャを構成するすべてのタスクが続き、m_ProcEnd
関数を呼び出して終了します。リスト3-6はサンプルです。
m_ProcBegin PROCA
JUMP_LABEL=STEPA
;;
(STEPA)
m_FileAssign -c “*” SYSPRINT
m_FileAssign -d SHR SYSUT1 ${DATA}/PJ01DDD.BT.DATA.PDSA/BIEAM00$[SEQ]
m_FileAssign -d MOD SYSUT2 ${DATA}/PJ01DDD.BT.QSAM.KBIEO005
m_FileLoad ${DD_SYSUT1} ${DD_SYSUT2}
JUMP_LABEL=ENDPROC
;;
(ENDPROC)
m_ProcEnd
外部プロシージャはm_ProcBegin
関数とm_ProcEnd
関数の使用を必要としません。単にリスト3-7に示すプロシージャの一部であるタスクをコーディングします。
プロシージャのコードと呼出しジョブの統合を簡素化するには、常に、プロシージャの先頭を次のようにします。
JUMP_LABEL=FIRSTSTEP
;;
(FIRSTSTEP)
JUMP_LABEL=ENDPROC
;;
(ENDPROC)
JUMP_LABEL=PR2STEP1
;;
(PR2STEP1)
m_FileAssign -d SHR INFIL ${DATA}/PJ01DDD.BT.QSAM.KBPRI001
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBPRO001
m_OutputAssign -c “*” SYSOUT
m_FileAssign -d SHR LOGIN ${DATA}/PJ01DDD.BT.SYSIN.SRC/BPRAS002
m_FileAssign -d MOD LOGOUT ${DATA}/PJ01DDD.BT.QSAM.KBPRO091
m_ProgramExec BPRAB002
JUMP_LABEL=ENDPROC
;;
(ENDPROC)
Kornシェル・スクリプト内部のプロシージャの使用は、m_ProcInclude
関数の呼出しを介して行われます。
「スクリプト実行フェーズ」で説明したとおり、Kornシェル・スクリプトは、変換フェーズで、m_ProcInclude
関数の呼出しのたびに、プロシージャのコードをインクルードして展開されます。この操作の結果として展開されたKornシェル・スクリプトは、操作後も、「スクリプトの一般的な構造」で定義された、スクリプトの一般的な構造のルールを依然として尊重している必要があります。
リスト3-8に示した前述の原則が尊重されていれば、ストリーム内プロシージャまたは外部プロシージャを、呼出しジョブのいかなる場所でも使用できます。
…
(STEPPR14)
m_ProcInclude BPRAP009
JUMP_LABEL=STEPPR15
…
プロシージャ内で定義されているタスクの実行は、2つの異なる手段で変更できます。
m_ProcBegin PROCE
JUMP_LABEL=STEPE
;;
(STEPE)
m_FileAssign -d SHR SYSUT1 ${DATA}/DATA.IN.PDS/DTS$[SEQ]
m_FileAssign -d MOD SYSUT2 ${DATA}/DATA.OUT.PDS/DTS$[SEQ]
m_FileLoad ${DD_SYSUT1} ${DD_SYSUT2}
JUMP_LABEL=ENDPROC
;;
(ENDPROC)
m_ProcEnd
(COPIERE)
m_ProcInclude PROCE SEQ="1"
JUMP_LABEL=COPIERF
;;
「ベスト・プラクティス」で規定されているとおり、プロシージャをコーディングするこの方法は、主にz/OS JCL変換の結果として得られるKornシェル・スクリプトをサポートするために用意されており、ターゲット・プラットフォーム用に新しく作成されるKornシェル・スクリプトでは推奨されません。
ファイル割当てのオーバーライドは、プロシージャに存在する割当ての置換を指定するm_FileOverride
関数を使用して行われます。m_FileOverride
関数の呼出しは、呼出し側スクリプト内のプロシージャ呼出しに続いて行われる必要があります。
リスト3-11は、m_FileOverride
関数を使用して論理ファイルSYSUT1
の割当てを置換する方法を示しています。
m_ProcBegin PROCE
JUMP_LABEL=STEPE
;;
(STEPE)
m_FileAssign -d SHR SYSUT1 ${DATA}/DATA.IN.PDS/DTS$[SEQ]
m_FileAssign -d MOD SYSUT2 ${DATA}/DATA.OUT.PDS/DTS$[SEQ]
m_FileLoad ${DD_SYSUT1} ${DD_SYSUT2}
JUMP_LABEL=ENDPROC
;;
(ENDPROC)
m_ProcEnd
(COPIERE)
m_ProcInclude PROCE SEQ="1"
m_FileOverride -i -s STEPE SYSUT1
Overriding test data
_end
JUMP_LABEL=COPIERF
;;
スクリプト内で1つまたは複数の手順の実行を条件付けるために、m_CondIf
、m_CondElse
およびm_CondEndif
関数を使用できます。動作は、z/OS JCL文のコンストラクト、IF
、THEN
、ELSE
およびENDIF
と類似しています。
リスト3-13
に示すように、m_CondIf関数は、常に関係式をパラメータとして持つ必要があります。この関数は、15回までネストできます。
…
(STEPIF01)
m_FileAssign -d SHR INFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF000
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF001
m_ProgramExec BAX001
m_CondIf "STEPIF01.RC,LT,5"
JUMP_LABEL=STEPIF02
;;
(STEPIF02)
m_FileAssign -d SHR INFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF001
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF002
m_ProgramExec BAX002
m_CondElse
JUMP_LABEL=STEPIF03
;;
(STEPIF03)
m_FileAssign -d SHR INFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF000
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF003
m_ProgramExec BAX003
m_CondEndif
m_CondExec
関数は、手順の実行を条件付けるために使用されます。m_CondExec
は、少なくとも1つの条件をパラメータとして持つ必要があり、同時に複数の条件を持つこともできます。複数の条件の場合、手順は、すべての条件が満たされる場合のみ実行されます。
リスト3-14
に示すように、m_CondExec関数は、関係する手順の中で最初に呼び出される関数である必要があります。
…
(STEPEC01)
m_FileAssign -d SHR INFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF000
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF001
m_ProgramExec BACC01
JUMP_LABEL=STEPEC02
;;
(STEPEC02)
m_FileAssign -d SHR INFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF001
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF002
m_ProgramExec BACC02
JUMP_LABEL=STEPEC03
;;
(STEPEC03)
m_CondExec 4,LT,STEPEC01 8,GT,STEPEC02 EVEN
m_FileAssign -d SHR INFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF000
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBIF003
スクリプトの実行フローは、次の方法で、決定および制御できます。
m_JobBegin
関数で指定された開始ラベル: このラベルは、通常、スクリプトの最初のラベルですが、ユーザーが特定の手順からスクリプトの実行を開始したい場合は、スクリプト内に存在するいかなるラベルにも変更できます。JUMP_LABEL
変数に割り当てられる値: この割当ては各手順に必須ですが、値が必ず次の手順のラベルであるとはかぎりません。m_CondExec
、m_CondIf
、m_CondElse
およびm_CondEndif
関数の使用方法。「手順実行の条件付け」を参照してください。 バッチ・ランタイム管理者がデフォルト・メッセージを変更する場合(たとえば言語を変更する場合)、環境変数MT_DISPLAY_MESSAGE_FILE
でパスが指定された構成ファイルを介して行うことができます。
このファイルは、区切り記号としてセミコロンを使用するCSVファイルです。このファイルの各レコードには、特定のメッセージが記載され、6つのフィールドで構成されます。
z/OSでは、ジョブが実行される前に、JESがその構文をチェックします。エラーが検出されると、JESはこれをレポートし、ジョブは何も実行されません。たとえば、GDGのgeneration(0)にNEWを適用するJCL文がある場合、既存のファイルにNEWを適用することはできないため、JESはこのエラーをレポートし、ジョブを実行しません。
しかし、ART for Batchでは、JCLジョブはOracle Tuxedo ART Workbenchによってまずkshジョブに変換され、ART for Batchは変換後のkshジョブのksh構文のみをチェックします。この文の実行時に文法エラーが検出されると、誤った文以降の文が実行され、それより以前の文は影響なく実行されます。
ファイルはm_FileBuild
またはm_FileAssign
関数を使用して作成されます。
作成されるファイルのファイル構成を指定する必要があります。索引編成ファイルの場合は、長さと主キーの仕様も記述する必要があります。
バッチ・ランタイムを使用する場合、バッチ・ランタイム関数(m_FileSort
、m_FileRename
など)またはプログラム(COBOLプログラムなど)でファイルを使用できます。
どちらの場合も、ファイルを使用する前に、先に割り当てる必要があります。ファイルは、次のことを行うm_FileAssign
関数を使用して割り当てられます。
m_FileAssign
関数を介して定義される環境変数は、DD_IFN
と命名されます。この命名規則は、Micro Focus COBOLが内部ファイル名を外部ファイル名にマップするために使用する変数であるという事実に基づいています。
割当てが済んだファイルは、${DD_IFN}
変数を使用することにより、ファイルを処理するバッチ・ランタイム関数のいずれかに、引数として渡すことができます。
COBOLプログラムの場合は、リンクはMicro Focus COBOLによって暗黙的に作成されます。COBOL-ITは、Micro Focus COBOLとDD割当てに関する互換性があります。
(STEPCP01)
m_FileAssign -d SHR INFIL ${DATA}/PJ01DDD.BT.QSAM.KBIDI001
m_FileAssign -d SHR OUTFIL ${DATA}/PJ01DDD.BT.VSAM.KBIDU001
m_FileLoad ${DD_INFIL} ${DD_OUTFIL}
…
(STEPCBL1)
m_FileAssign -d OLD INFIL ${DATA}/PJ01DDD.BT.QSAM.KBIFI091
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBIFO091
m_ProgramExec BIFAB090
…
ART/BatchRTを強化し、DISP=MODについてメイン・フレームとの一貫性を維持します。つまり、ART/BatchRTの対象の運用システムでのDISP=MODの動作をメイン・フレームと同様にします。現在では、BatchRTは次の2種類のCOBOLコンパイル/ランタイム環境に依存しています。
注: | VSAMデータ・セットについては、常にDISP=MODはDISP=OLD (ファイルが存在)およびDISP=NEW(ファイルが存在しない)として扱われます。これは、z/OSと同じです。 |
Micro Focus COBOLの場合は、DISP=MODの動作を正しくするために、新しいファイル・ハンドラ(ARTEXTFH.gnt)が1つBatchRTに追加されます。ユーザーは、そのCOBOLプログラムをこのファイル・ハンドラとコンパイルする必要があります。つまり、次のコンパイル・オプションを追加する必要があります。
このコンパイル・オプションを指定しない場合は、オープン・モードopen outputをCOBOLプログラムに書き込むと、既存のファイル内容が消去されます。これは予期しない操作です。
COBOLプログラムのコンパイルの際には、このコンパイル・オプションを常に追加することをお薦めします。表3-5に、DDNをサポートするAPIの動作を示します。
INPUTとは入力ファイルを意味し、入力ファイルに対する読取り動作のみが発生します。DISP=MODは入力ファイルには適切ではありません。入力ファイルにデータが書き込まれることはありませんが、許可されているため、入力ファイルについてDISP=MODは常にDISP=OLDと同様に機能するからです。
出力とは出力ファイルを意味し、出力ファイルに対する読取りおよび書込み動作が発生します。出力ファイルに書き込まれるデータはすべて元のファイルに追加されます。COBOLプログラムがオープン・モードかどうか(open outputまたはopen extend)は関係ありません。
COBOL-ITの場合、(Micro Focus COBOLのような)DISP=MODに対するファイル・ハンドラ・レベルのサポートはありません。したがって、COBOLプログラムのコンパイルには特別な要件はありません。表3-6に、DDNをサポートするAPIの動作を示します。
INPUTとは入力ファイルを意味し、入力ファイルに対する読取り動作のみが発生します。DISP=MODを入力ファイルに指定することは適切ではなく、COBOL-ITでは許可されていません。ある入力ファイルがDISP=MODとして割り当てられている場合、その内容を読み取ることはできません。
出力とは出力ファイルを意味し、出力ファイルに対する読取りおよび書込み動作が発生します。出力ファイルに書き込まれるデータはすべて元のファイルに追加されます。COBOLプログラムがオープン・モードかどうか(open outputまたはopen extend)は関係ありません。
バッチ・ランタイムには、2つのジョブで1つのファイルに同時に書込みが行われないようにするロック・メカニズムが備わっています。
同時ファイル・アクセス制御を有効にするには、次のようにします。
注: |
Oracle Tuxedo Application Runtime for Batchでは、世代別データ・グループ(GDG)ファイルをファイルまたはデータベース(DB)のいずれかに基づいて管理できます。ファイルベースの管理方法では、バッチ・ランタイムによりGDGファイルが別々の*.gensファイルで管理され、1つの*.gensが1つのGDGファイルに対応します。DBベースの管理方法では、ART for BatchによりユーザーはGDG情報をOracleデータベースまたはDB2データベースで管理できます。
世代ファイルの概念をエミュレートし、UNIX標準ではないz/OSメインフレーム上に存在するために、バッチ・ランタイムには、この種のファイルを管理するための一連の関数が用意されています。これらの関数は、ファイルベースの管理とDBベースの管理の両方で使用できます。
注: | GDGのコピーや名称変更はサポートされません。 |
GDGファイルは、m_GenDefine
関数を介して定義または再定義されます。GDGの定義または再定義の操作は即時にコミットされ、ロールバックできません。
リスト3-17に示すように、1行目ではGDGを定義し、その最大世代数を15に設定します。2行目では同じGDGの最大世代数を30に再定義します。3行目では-sオプションを指定せずにGDGを定義します(その最大世代数は9999に設定されます)。4行目ではGDGを暗黙的に定義し、その最大世代数を9999に設定します。5行目ではGDGユース・モデル・ファイル$DATA/FILE
を定義します。このファイルは、GDGファイルまたは通常のファイルです。
m_GenDefine -s 15 ${DATA}/PJ01DDD.BT.FILE1
m_GenDefine -s 30 -r ${DATA}/PJ01DDD.BT.FILE1
m_GenDefine ${DATA}/PJ01DDD.BT.FILE2
m_FileAssign -d NEW,CATLG -g +1 SYSUT2 ${DATA}/PJ01DDD.BT.FILE3
m_FileAssign -d NEW,CATLG -g +1 -S $DATA/FILE FILE1 $DATA/GDG
新しい世代ファイル(GDS)をGDGに追加するには、-d NEW/MOD,…
および-g +n
というパラメータを指定してm_FileAssign
を呼び出します。GDSファイル・タイプは、LSEQまたはSEQのみです。
GDGに世代ファイルを追加する場合、次の4つの点に注意してください。
m_FileAssign
で指定される世代番号を使用して、<current GDS number> + <GenNum>
の形式で生成されます。例については、「リスト3-20」を参照してください。(STEP1)
m_FileAssign -d NEW,KEEP,KEEP -g +1 SYSUT1 "$DATA/GDG1"
m_FileAssign -d MOD,KEEP,KEEP -g +5 SYSUT2 "$DATA/GDG1"
(STEP2)
m_FileAssign -d NEW,KEEP,KEEP -g +9 SYSUT1 "$DATA/GDG1"
m_FileAssign -d NEW,KEEP,KEEP -g +2 SYSUT2 "$DATA/GDG1"
(STEP1)
m_FileAssign -d NEW,KEEP,KEEP -g +1 SYSUT1 "$DATA/GDG1"
m_FileAssign -d NEW,KEEP,KEEP -g +5 SYSUT2 "$DATA/GDG1"
(STEP2)
m_FileAssign -d NEW,KEEP,KEEP -g +4 SYSUT1 "$DATA/GDG1"
m_FileAssign -d NEW,KEEP,KEEP -g +5 SYSUT2 "$DATA/GDG1"
前述の例は、世代番号(+5)が2回追加されるという間違った使用方法を示しています。
m_FileAssign -d NEW,KEEP,KEEP -g +1 SYSUT1 "$DATA/GDG1"
m_FileAssign -d MOD,KEEP,KEEP -g +5 SYSUT2 "$DATA/GDG1"
前述の例では、$DATA/GDG1
に1、2、4という番号の3つのGDSがあるものとします。対応するGDSファイルが次のようにリストされます。
前述のジョブの実行後、$DATA/GDG1
には1、2、4、5、9という番号の5つのGDSが含まれます。対応するGDSファイルが次のようにリストされます。
(STEP1)
m_FileAssign -d NEW,KEEP,KEEP -g +1 SYSUT1 "$DATA/GDG1"
m_FileAssign -d MOD,KEEP,KEEP -g +5 SYSUT2 "$DATA/GDG1"
(STEP2)
m_FileAssign -d NEW,KEEP,KEEP -g +2 SYSUT3 "$DATA/GDG1"
前述の例で、RGNが+5に等しいGDSが最新のGDSになります。つまり、ジョブが正常終了すると、そのRGNが0になります。
GDGで既存の世代ファイル(GDS)を参照するには、-d OLD/SHR/MOD…
,および-g 0
、-g all
または-g -n
というパラメータを指定してm_FileAssign
を呼び出します。-g 0
は最新世代を、-g all
はすべての世代ファイルを、-g -n
は最新世代(0世代)からn世代逆算した世代ファイルを参照します。
相対世代番号(RGN)を使用してGDSを参照する場合、相対世代番号は、世代番号が0である最新のGDSを基準とした相対位置であることに注意してください。
たとえば、GDG1
に1、4、6、7、9、10という番号のGDSがそれぞれ含まれている場合、GNとRGNのマッピングは次のとおりです。
次のジョブでは、RGN=-1
を使用してGNが9に等しいGDSを参照し、RGN=-4
を使用してGNが4に等しいGDSを参照します。
(STEP1)
m_FileAssign -d SHR,KEEP,KEEP -g -1 SYSUT1 "$DATA/GDG1"
m_FileAssign -d SHR,KEEP,KEEP -g -4 SYSUT2 "$DATA/GDG1"
m_FileAssign
のDISPOSITION
フィールドにDELETEが指定された場合、現在の手順が終了した後に対応するGDSが削除され、GNとRGNのマッピングが変更されます。変更後のマッピングは次の手順で表示されます。
たとえば、GDG1
に1、4、6、7、9、10という番号のGDSがそれぞれ含まれている場合、GNとRGNのマッピングは次のとおりです。
次のジョブでは、RGN=-1
を使用してGNが9に等しいGDSを参照し、RGN=-4
を使用してGNが4に等しいGDSを参照します。
(STEP1)
m_FileAssign -d OLD,DELETE,DELETE -g -1 SYSUT1 "$DATA/GDG1"
m_FileAssign -d OLD,DELETE,DELETE -g -4 SYSUT2 "$DATA/GDG1"
(STEP2)
m_FileAssign -d OLD,DELETE,DELETE -g -1 SYSUT1 "$DATA/GDG1"
m_FileAssign -d OLD,DELETE,DELETE -g -2 SYSUT2 "$DATA/GDG1"
前述の例でSTEP1が終了すると、GNとRGNのマッピングは次のようになります。
STEP2では、SYSUT1でポイントされるGDS (GNが7であるGDS)およびSYSUT2でポイントされるGDS (GNが6であるGDS)が削除されます。
STEP2が終了すると、GNとRGNのマッピングは次のようになります。
ART for Batchでは、新しく追加された生成ファイルまたは現在の既存の生成ファイルを、m_FileAssign
で指定するDD
の配置によって削除できます。
(STEP1)
m_FileAssign -d NEW,DELETE,DELETE -g +1 SYSUT1 "$DATA/GDG1"
m_FileAssign -d NEW,DELETE,DELETE -g +5 SYSUT2 "$DATA/GDG1"
(STEP2)
m_FileAssign -d NEW,DELETE,DELETE -g +1 SYSUT1 "$DATA/GDG1"
m_FileAssign -d NEW,DELETE,DELETE -g +5 SYSUT2 "$DATA/GDG1"
(STEP1)
m_FileAssign -d NEW,DELETE,DELETE -g -1 SYSUT1 "$DATA/GDG1"
m_FileAssign -d NEW,DELETE,DELETE -g -3 SYSUT2 "$DATA/GDG1"
(STEP2)
m_FileAssign -d NEW,DELETE,DELETE -g -1 SYSUT3 "$DATA/GDG1"
m_FileAssign -d NEW,DELETE,DELETE -g -3 SYSUT4 "$DATA/GDG1"
前述の例では、GDG1には1、4、6、7、9、10という番号の6つのGDSがそれぞれ含まれています。SYSUT1でポイントされるGDS (GNが9であるGDS)、SYSUT2でポイントされるGDS (GNが6であるGDS)、SYSUT3でポイントされるGDS (GNが7であるGDS)およびSYSUT4でポイントされるGDS (GNが1であるGDS)が削除されます。
注: | GDGのすべてのGDSを削除してもGDG自体は削除されませんが、GDGに含まれるGDSは0個です。 |
リスト3-26に示すように、GDGベース名を指定してm_FileDelete
を呼び出すことで、GDG全体を削除できます。この方法で、すべてのGDGのGDSが適切に削除されます。GDGの削除の操作は即時にコミットされ、ロールバックできません。
m_FileDelete ${DATA}/PJ01DDD.BT.GDG
GDGベースのみをカタログ化できます。そのGDSを個別にカタログ化することはできません。
ART for Batchのファイル・カタログ化関数を有効にしてGDGをカタログ化する必要があります。また、カタログ・モードでは、m_FileAssign
に指定されるパラメータ[-v volume]
は無視されます。
注: | GDGは、定義されるとカタログ化されます。 |
現在の手順で変更されるすべてのGDGは、現在の手順が正常終了するかどうかにかかわらずコミットされます。
GDGのコミットにより、Oracle DataBaseやファイル(*.gens
)といったGDG管理システムの情報が更新され、一時的な世代ファイルがコミットされます。ただし、GDGのコミットによってGNとRGNのマッピング関係に変更はありません。つまり、ジョブの1つの手順の中で、RGNは常に同じGDSを参照します。
たとえば、GDG1
には1、4、6、7、9、10という番号の6つのGDSがそれぞれ含まれています。
(STEP1)
m_FileAssign -d NEW,KEEP,KEEP -g +1 SYSUT1 "$DATA/GDG1"
m_FileAssign -d NEW,KEEP,KEEP -g +2 SYSUT2 "$DATA/GDG1"
m_FileAssign -d NEW,KEEP,KEEP -g -1 SYSUT3 "$DATA/GDG1"
(STEP2)
m_FileAssign -d NEW,KEEP,KEEP -g -1 SYSUT4 "$DATA/GDG1"
STEP1で、GNとRGNのマッピング(ジョブおよびGDG管理システムの両方)は次のようになります。SYSUT3は、GNが9であるGDSを参照します。
STEP2で、GDG管理システムのGNとRGNのマッピングは次のようになります。
しかし、現在実行中のジョブにおけるGNとRGNのマッピングは変更されません。次の例では、SYSUT4は、GNが11であるGDSではなく、GNが9であるGDSを引き続き参照します。
MT_GENERATION
変数には、GDGファイルの管理方法を指定します。*.gens
ファイルでGDGを管理するには、値をGENERATION_FILE
に設定する必要があります。
ファイルベースのGDG管理メカニズムでは、1つのGDGファイルに常にアクセスできるのは1つのジョブのみで、1つのGDGに同時に複数のジョブでアクセスすることはできません。GDGファイルにアクセスするには、既存の内部関数mi_FileConcurrentAccessReservation
によりファイル・ロックを取得する必要があります。
ファイルベースのGDG管理では、同時実効性および認可の制御に*.gens
ファイル(*はGDGのベース名)を使用します。ユーザー・アクセスのチェックは、*.gens
ファイルにアクセスできるかできないかによって行われます。
DBベース管理では、Oracle DatabaseおよびDB2データベースがサポートされています。
注: | この機能を有効にするには、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_FILE_NAME
(物理世代ファイル名)は、GDG_DEFINE
のGDG_BASE_NAME
からとGDG_DETAIL
のGDG_ABS_NUM
から構成される可能性があるため、表GDG_DETAIL
には格納されません。
注: | GDG情報をバックアップするには、GDG_DEFINE およびGDG_DETAILE の2つのデータベース表をバックアップする必要があります。 |
MT_GENERATION
GENERATION_FILE_DB
に設定し、MT_GDG_DB_ACCESS
を適切に構成する必要があります。
MT_GDG_DB_ACCESS
GENERATION_FILE_DB
に設定されている場合、MT_GENERATION
とともに使用され、有効なデータベース・ログイン・アカウントで設定する必要があります。Oracleデータベースにアクセスするには、たとえばscott/tiger@orcl
のように、userid/password@sid
の書式で指定する必要があります。
MT_GDG_DB_BUNCH_OPERATION
GENERATION_FILE_DB
に設定されている場合は、MT_GENERATION
とともに使用します。これは、コミット・フェーズでデータベースにGDG変更をコミットする方法を示します。"Y
"に設定されている場合、GDGの変更は1回のデータベース・アクセスでコミットされます。"N"に設定されている場合、GDGの変更は、1回または複数のデータベース・アクセスを使ってコミットされます。
2つの外部シェル・スクリプトを使用すれば、新規のデータベース表を自動的に作成および削除できます。
データベースに表GDG_DEFINE
およびGDG_DETAIL
を作成します。
CreateTableGDG.sh <DB_LOGIN_PARAMETER>
CreateTableGDG.sh scott/tiger@orcl
データベースから表GDG_DEFINEおよびGDG_DETAILを削除します。
DropTableGDG.sh <DB_LOGIN_ PARAMETER>
DropTableGDG.sh scott/tiger@orcl
DBベースのGDG管理メカニズムでは、同時実効性制御動作はファイルベースのGDG管理メカニズムと同じですが、*.ACS (*はGDGベース名)ファイルの書式は異なります。GDGに対応する行にアクセスするジョブでは、まずGDGのファイル・ロックを取得する必要があるため、DBベースのGDG管理メカニズムでは、「データベース表」で述べた表をロックする必要はありません。つまり、データベースのアクセス・レベルでは、同時実行性制御を実行する必要はありません。対応する*.ACS
ファイルへのアクセス権限(読取りまたは書込み)がない場合、データベースにはアクセスできません。GDGファイルを変更する必要がある場合、世代ファイルおよび世代ファイルを保持するディレクトリへの書込み権限が必要であり、MT_GDG_DB_ACCESS
は、「データベース表」で述べた表への適切な権限を持つように正しく構成する必要があります。
DBベースのGDG管理の記述全体をコピーし、ファイル名を置換するしかありません。
DBベースのGDG管理メカニズムには4種類の情報があります。
これらの情報は、GDGファイル用に一貫して保持する必要があります。バッチ・ランタイムでは、ジョブで初めてGDGファイルにアクセスする際に、GDG_DEFINE
から物理ファイルへの一貫性をチェックします。例外が発生し、これらの情報の一貫性がなくなった場合、バッチ・ランタイムにより現在のジョブが終了され、エラーが報告されます。
この動作は、一貫性のチェックはせず、プロセスで発生した例外の報告のみをする既存のファイルベースのメカニズムと異なります。
ファイル・ベースのGDGとDBベースのGDGの両方がData Control Block (DCB)をサポートします。
.dcb
ファイルは、"-t <file type>
"および"-r <record length>
"の2つの値をとります。
m_FileAssign
で-t <file type>
にLSEQ
またはSEQ
のどちらかを指定する必要があります。job ksh
ファイルにファイル・タイプを指定しなかった場合は、デフォルトでLSEQ
が使用されます。
最初の世代ファイルを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
ファイルが自動的に削除されます。
ただし、GDG内のすべての世代ファイルが削除されてもGDG自体が存在する場合、.dcb
ファイルは削除されません。
データがKornシェル・スクリプトに直接書き込まれるファイルを定義して使用するには、-i
パラメータを指定してm_FileAssign
関数を使用します。デフォルトでは、文字列_end
はリスト3-28で示されるようにストリーム内フローの「最終」デリミタです。
(STEP1)
m_FileAssign -i INFIL
data record 1
data record 2
…
_end
一連のファイルを連結入力として使用するには、リスト3-29
に示すように-
Cパラメータを指定して m_FileAssign関数を使用します(z/Os JCLでは、最初の1つだけがラベルを含むDDカードとしてコーディングされていました)。
(STEPDD02)
m_FileAssign -d SHR INF ${DATA}/PJ01DDD.BT.QSAM.KBDDI002
m_FileAssign -d SHR -C ${DATA}/PJ01DDD.BT.QSAM.KBDDI001
m_ProgramExec BDDAB001
実行するコマンドを含む外部sysinファイルを使用するには、m_UtilityExec
関数を使用します。
m_FileAssig
n -d OLD SYSIN ${SYSIN}/SYSIN/MUEX07
m_UtilityExec
ファイル(世代ファイルを含む)は、m_FileDelete
関数を使用して削除できます。
m_FileDelete ${DATA}/PJ01DDD.BT.QSAM.KBSTO045
z/OsからUNIX/Linuxへの移行プロジェクトでは、一部の恒久データ・ファイルが関係表に変換される場合があります。Oracle Tuxedo Application Runtime WorkbenchのファイルからOracle」への移行に関する章を参照してください。
ファイルが関係表に変換される場合、この変更はそれを使用するコンポーネントに影響を与えます。具体的には、そのようなファイルがz/Os JCLで使用されると、そのJCLに対応する変換済Kornシェル・スクリプトが、このファイルを含む操作を取り扱うことができなくてはなりません。
変換されたKornシェル・スクリプトを、可能なかぎり標準的にしておくために、この変更は変換プロセスでは処理されません。かわりに、この種のファイルのすべての管理は、バッチ・ランタイム内で実行時に行われます。
つまり、z/OS JCLに、変換されるファイルが関係するファイル・コピー操作があった場合、バッチ・ランタイムではファイルの標準コピー操作に変換されます(つまりm_FileLoad
操作)。
表に変換されたファイルの管理は、RDBファイルを介して可能になります。RDBファイルは、表に変換されたファイルと名前が同じで、接尾辞.rdb
が追加されたファイルです。
ファイル関連の関数がバッチ・ランタイムによって実行されるたびに、対応する.rdbファイルが存在するかどうかをテストして、ファイルが表に変換されたことを確認します。関係するファイルのいずれかが表に変換された場合、関数は必要な中間操作(表をファイルにアンロードして再ロードするなど)を実行し、その後で最終的なアクションを実行します。
RDBMSに接続する必要があるアプリケーション・プログラムを実行する場合、m_ProgramExec
関数を呼び出すときに-b
オプションを使用する必要があります。
接続と切断(およびコミットとロールバック操作)は、バッチ・ランタイムによって暗黙的に処理され、次の2つの方法を使用して定義できます。
MT_DB_LOGIN
の値は、dbuser/dbpasswd[@ssid]
または「/
」という形式でなければなりません。
注: | RDBMSが、データベース接続ユーザーに対してUNIX認証を使用でき、RDBMS認証を使用できないように構成されている場合は「/ 」を使用する必要があります。 |
注: | 「/」を使用するべきかどうかは、データベース管理者に確認してください。 |
リスト3-30
に示すように、実行される主プログラムはRDBMSを直接使用しないが、その後に続くサブプログラムのいずれかが使用する場合は、-bオプションも使用する必要があります。
(STEPDD02)
m_FileAssign -d MOD OUTF ${DATA}/PJ01DDD.BT.QSAM.REPO001
m_ProgramExec -b DBREP001
m_ProgramExec
関数が送信する可能性のあるファイルは次の3種類です。
.gnt
のファイル)。 .gnt
ファイルが$COBPATH
(Micro Focus COBOLの場合)、または$COB_LIBRARY_PATH
(COBOL-ITの場合)にあることを確認してください。
.so
のファイル)。 呼び出し可能な共有ライブラリ・ファイルが$COBPATH
(Micro Focus COBOLの場合)、または$COB_LIBRARY_PATH
(COBOL-ITの場合)、もしくはシステム・ライブラリのファイル検索パス(LIBPATH
、LD_LIBRARY_PATH
など)に存在することを確認してください。
このタイプのファイルには、ファイル名と同じ名前を持つエントリ関数が必要です。
たとえば、呼び出し可能な共有ライブラリ・ファイルProgA.so
には、次のいずれかで宣言された関数が含まれていなければなりません。
実行プログラムが$PATH
に存在することを確認してください。
m_ProgramExec
は、COBOLプログラム(.gnt
)、呼び出し可能な共有ライブラリ内のCプログラム(.so
)、その他の実行可能プログラムの順にプログラムの成果物の種類を決定します。COBOLプログラムが実行されると、m_ProgramExec
は同じ名前を持つ別のプログラムを実行しません。たとえば、ProgA.gnt
の実行後、ProgA.so
など、ProgA
という名前のプログラムは実行されません。
.gnt
ファイルと.so
ファイルについては、m_ProgramExec
はrunb
プログラムを起動して、実行します。ARTは、次のようなrunb
を提供します。
前述の4種類の組合せを使用していない場合は、$JESDIR/ejr
にアクセスして、make.sh
を実行し、自分専用のrunb
を生成してください。
runbプログラムは、データベース・ライブラリを使用してコンパイルされたランタイムで、runbatchプログラムを実行します。
INTRDR
ファシリティによって、sysoutのコンテンツをTuxJESに送信できます(Tuxedo Job Enqueueing Service (TuxJES)の使用に関するドキュメントを参照してください)。TuxJESが存在しない場合、コマンド「nohup EJR」が使用されます。
m_FileAssign -d SHR SYSUT1 ${DATA}/MTWART.JCL.INFO
m_OutputAssign -w INTRDR SYSUT2
m_FileRepro -i SYSUT1 -o SYSUT2
この例では、ファイルの内容${DATA}/MTWART.JCL.INFO
(ddname SYSUT1
)が、オプション-w INTRDR
を使用しているファイル(ddname SYSUT2
)にコピーされ、その後、このファイル(ddname SYSUT2
)が送信されます。
出力ファイルには有効なksh構文が含まれる必要がありますのでご注意ください。
COBOLプログラムにより生成されるINTRDR
ジョブは、リアルタイムで自動的に送信されます。COBOLプログラムがINTRDR
を閉じると、ジョブINTRDR
はその時に実行されている作業の完了を待たずに、即座に送信されます。この機能を有効化するには、ファイル・ハンドラARTEXTFH.gnt
をCOBOLプログラムにリンクする必要があります。
この機能が有効化されていない場合、INTRDR
ジョブは、その時に実行されている作業が完了した後で送信されます。
注: | ランタイムで生成されるバッチ・ジョブ・スクリプトがJCL言語で記述されている場合、INTRDR で送信することができません。 |
バッチ・ランタイムを使用する場合は、TuxJESを使用してジョブを起動できます(Tuxedo Job Enqueueing Service (TuxJES)の使用に関するドキュメントを参照)が、EJRスポーナを使用してジョブを直接実行することもできます。
この種の実行を行う前に、全体のコンテキストが正しく設定されていることを確認します。これには、バッチ・ランタイムが必要とする環境変数やディレクトリも含まれます。
# EJR DEFVCUST.ksh
EJRスポーナの完全な説明は、『Oracle Tuxedo Application Runtime for Batchリファレンス・ガイド』を参照してください。
バッチ・ランタイムを使用すれば、パブリックAPI用にカスタムの事前または事後アクションを追加できます。m_* (*は関数名)関数ごとに、m_*_Begin
およびm_*_End
関数を指定し、それらをejr/USER_EXIT
ディレクトリに置くことができます。それらは、ジョブ実行がm_*
API.に入るまたは出るときに、自動的に呼び出されます。
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
にあります。
注: | ユーザーのエントリ/終了関数では、ART for Batchで提供される関数を使用できません。しかし、ユーザーのスクリプトでは、return文で呼出し元に値が戻され、ART for Batchはリターン・コードを通じてユーザーのエントリ/終了関数が正しく動作したかどうかをチェックします。リターン・コード0 はジョブを続行し、ゼロ以外の値はジョブを終了します。 |
注: | ユーザーのエントリ/終了関数では、exitを呼び出さないことをお薦めします。これは、フレーム・ワークでは、exit は内部関数mif_ExitTrap の別名であり、ユーザー・エントリ/終了関数でexit が呼び出された場合、最終的に呼び出されるためです。exit 0 が呼び出されると、フレームワークでは何も行われず、ジョブは続行され、exit not_0 が呼び出されると、グローバル変数が設定されて、現在のジョブを終了できます。 |
関数と同じ名前の1つのファイルでは、含めるのは1つの関数のみ(m_*_Begin
または m_*_End
など)で、そのようなファイルはすべてejr/USER_EXIT
に置きます。
バッチ・ランタイムで提供されているmi_
接頭辞の関数には、カスタム・エントリ/終了関数は指定できません。
CONF/Messages.conf
で定義されている各ログ・メッセージは、表3-8に示すように、6つのフィールドで構成されます。
これらのメッセージのレベルは、デフォルトでは4に設定されています。
ジョブ・ログにあるこれら3つのメッセージを印刷するかどうかを制御するために、バッチ・ランタイムのメッセージ・レベルを指定できます。
表3-9では、バッチ・ランタイムに用意されているログ・メッセージのレベルを示しています。
ジョブ・ログでメッセージを表示するデフォルトのレベルは3です。レベルの変更には、次の方法のいずれかを選択することもできます。
EJRで設定された表示レベルにより、MT_DISPLAY_LEVEL
で設定されたレベルをオーバーライドできます。
バッチ・ランタイムは、起動された各ジョブに対して、実行された各ステップの情報を含むログ・ファイルを作成します。このログ・ファイルには、リスト3-31で示されているような構造体が含まれます。
JOB Jobname BEGIN AT 20091212/22/09 120445
BEGIN PHASE Phase1
Log produced for Phase1
.......
.......
.......
END PHASE Phase1 (RC=Xnnnn, JOBRC=Xnnnn)
BEGIN PHASE Phase2
Log produced for Phase2
.......
.......
.......
END PHASE Phase2 (RC=Xnnnn, JOBRC=Xnnnn)
..........
..........
BEGIN PHASE END_JOB
..........
END PHASE END_JOB (RC=Xnnnn, JOBRC=Xnnnn)
JOB ENDED WITH CODE (C0000})
JOB ENDED ABNORMALLY WITH CODE (S990})
TuxJesを使用しない場合、ログ・ファイルは、<Job name>_<TimeStamp>_<Job id>.log
という名前で ${MT_LOG}
ディレクトリ配下に作成されます。
詳細は、Tuxedo Job Enqueueing Service (TuxJES)の使用に関する項を参照してください。
バッチ・ランタイムのロギング機能では、各ログ行の前に情報提供のログ・ヘッダーが次の書式で示されます。
YYYYmmdd:HH:MM:SS:TuxSiteID:JobID:JobName:JobStepName
ログ・ヘッダーの書式は構成できますが、既存の特定のメッセージ・ヘッダー、タイプ0、1およびbの構成や動作に影響を与えないようにしてください。
表3-10では、汎用ログ・ヘッダーの指定に使用できる変数を示しています。
MT_LOG_HEADER
は、CONF/BatchRT.conf
に追加された新しい構成変数で、次のようになります。
MT_LOG_HEADER='$(date'+%Y%m%d:%H%M%S'):${MTI_SITE_ID}:${MTI_JOB_NAME}:${MTI_JOB_ID}:${MTI_JOB_STEP}
: '
MT_LOG_HEADER
の値がnull文字列でなければ、その内容はログ・ヘッダーとして印刷される実際の値を取得するためのシェル・ステートメントとして評価され、それ以外の場合、この機能は無効です。
注: | MT_LOG_HEADER に対して構成された文字列は、ソース・コードでシェル・ステートメントとして処理され、ログ・ヘッダーとして使用される対応文字列を生成するeval コマンドによって解釈されます。 |
注: | 構文の内部: eval mt_MessageHeader=\"${MT_LOG_HEADER}\" |
前述の例は、書式の必要に応じて、表3-10に示した変数のみを使用して変更できます。
この構成変数は、デフォルトではコメント化されるため、この機能を有効にするには、非コメント化する必要があります。
ロギング・システムでは、ジョブ・ログの詳細なファイル情報の他、ファイルがDDに割り当てられるときや、解除されるときの情報も記録できます。
次のメッセージ識別子は、ファイルの割当ておよびファイル情報ログの書込みでのmi_DisplayFormat
の使用をサポートするために、CONF/Messages.conf
で定義されています。
注: |
注: | CONF/Messages.conf は構成できません。このファイルは編集しないでください。 |
注: | 各識別子の最後の文字列%s は、それがログ・ファイルに書き込まれることを表します。その値は、CONF/Batch.conf で定義されている次の変数を使用して構成できます。詳細は、表3-12を参照してください。 |
詳細なファイル情報の書式を決定するには、3つの構成変数をCONF/BatchRT.conf
で定義する必要があります。表3-11で示されているプレースホルダを使用すれば、ファイル・ログ情報をより柔軟に構成できます。
|
これらのMT_LOG_FILE_*
変数に文字列を構成するには、プレースホルダを対応する値に置換します(文字列置換)。結果はシェル・ステートメントとして処理され、eval
コマンドにより解釈され、ログに書き込む対応文字列を生成します。
構文の内部: eval mt_FileInfo=\"${MT_LOG_FILE_INFO}\"
これらの変数を構成するには、次のルールに従う必要があります。
FileInfo
メッセージのレベルがバッチ・ランタイムに対して指定されたメッセージ・レベルと等しいかそれより低い場合、およびMT_LOG_FILE_*
がnull文字列に設定されている場合、FileInfo
メッセージは、ジョブ・ログに表示されません。MT_LOG_FILE_*
が、ファイル情報を表示されなくする間違ったコマンドに設定されている場合も、FileInfoメッセージはジョブ・ログで表示されませんが、ジョブの実行には影響がありません。
注意: | これらの変数は書式上の必要に応じてカスタマイズできますが、コマンドが有効であることを確認しないと、ファイル情報は記録されません。 |
一部の関数(m_JobBegin
、m_JobEnd
、m_PhaseBegin
、m_PhaseEnd
)には、選択されたジョブ・スケジューラとの関係で行われる特定のアクションを挿入するためのエントリ・ポイントが用意されています。
SQLリクエストは、m_ExecSQL
関数を使用して実行できます。
ターゲット・データベースに従い、この関数はORACLEデータベースでは「sqlplus」コマンドを実行し、UDBでは「db2 -tsx」コマンドを実行します。
環境変数MT_DB_LOGIN
を設定する必要があります(データベース接続ユーザー・ログイン)。
SYSIN
ファイルにはSQLリクエストを含める必要があり、ユーザーはデータベース・ターゲットに関するコンテンツを検証する必要があります。
COBOL ITによってコンパイルされたBatch COBOLプログラムは、ART Workbenchを使用してMainframe VSAMファイルから変換される索引編成ISAMファイルにアクセスできます。VSAMファイルは、COBOL-ITを使用してBDBに格納できます。
この機能をバッチ・ランタイムで有効にするには、ランタイム中に次を実行してください。
Oracle Tuxedo ART Batch Runtimeでは、ネイティブのJCLジョブを、事前変換することなく、リアルタイムのworkbench変換で管理することをサポートしています。詳細は、 JCL変換に関する項を参照してください。
Oracle Tuxedo ART Workbenchをインストールして実行可能にする必要があります。
Oracle Tuxedo ART Workbenchがリモート・マシン(host1
)にデプロイされ、ARTJESCONV
サーバーが別のマシン(host2
)にデプロイされている場合、次に示す2つの追加要件を満たす必要があります。
注意: | JESドメインで複数のマシンに複数のARTJESCONV サーバーが構成されている場合、ARTJESCONV を搭載したマシンごとに、信頼できるSSH接続を構成する必要があります。 |
注: | Workbenchがローカル・マシンにデプロイされている場合、host の設定はオプションです。 |
たとえば、Oracle Tuxedo ART WorkbenchとARTJESCONV
が異なるマシンにデプロイされている場合は、次を実行してuser2@host2
をuser1@host1
に追加する必要があります。
JCL変換のテンプレート作業フォルダは$JESROOT/jcl_conv_dir
です。起動時にこのフォルダが存在しない場合は、自動的に作成されます。バッチ・ランタイムが起動すると、$JESDIR/Batch_RT/jcl_conv_dir
の内容が、この作業フォルダに自動的にコピーされます。JCLジョブが送信されると、JESはこのテンプレート・フォルダをフォルダ$JESROOT/<JOBID>/JCL
にコピーし、Workbenchが操作するフォルダ$JESROOT/<JOBID>/JCL/source/JCL/
にJCLジョブ・ファイルを配置します。
ユーザーは、JCLジョブごとに、すべてのINCL
、PROC
およびSYSIN
を、テンプレート作業フォルダにコピーする必要があります。JCLジョブの変換および実行時に、$JESROOT/<JOBID>/JCL/target/PROC:$JESROOT/<JOBID>/JCL/target /INCL
が環境変数PROCLIB
の先頭に追加され、$JESROOT/<JOBID>/JCL/target/Master-SYSIN
が環境変数SYSIN
に設定されます。
JCL変換用の作業フォルダ内のWorkbench構成ファイルは、param/config-trad-JCL.desc
です。ユーザーがこれをカスタマイズする必要があります。カスタマイズが行われない場合、デフォルト値が使用されます。詳細は、JCL変換構成ファイルに関する項を参照してください。
MT_REFINEDIR
およびMT_REFINEDISTRIB
を構成する必要があります。詳細は、表3-3を参照してください。
JCL変換をサポートするために、キューCONV_JCL
がキュー・スペースJES2QSPACE
に追加されます。詳細は、 表8「TuxJESキュー」を参照してください。
JCLジョブを送信するには、オプション-l
を次のように使用します。
[-t JCL|KSH]
を次のようにフィルタとして使用します。
列job type
が、次のいずれかの値を使用して結果に追加されます。
変換フェーズが完了する前、JCLのジョブ名とクラスはNULLで、優先度は0として表示されます。
JCL変換ログは$JESROOT/<JOBID>/LOG/<JOBID>.jcllog
です。
NJEサポートにより、JCLジョブの場合と同様、ユーザーはバッチ・ランタイムで次の機能を実装できます。
バッチ・ランタイムのm_SetJobExecLocation
APIにより、ユーザーはNJEサポートを使用するKSHジョブを開発できます。例:
API m_JobSetExecLocation
でジョブ実行グループとして指定されているサーバー・グループを指定する場合は、次のことを確認してください。
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はジョブを処理できません。
m_JobBegin -j SAMPLEJCL -s START -v 2.0 -c R
m_JobSetExecLocation "ATLANTA"
while true ;
do
m_PhaseBegin
case ${CURRENT_LABEL} in
(START)
# XEQ ATLANTA
JUMP_LABEL=STEP01
;;
(STEP01)
m_OutputAssign -c "*" SYSPRINT
m_FileAssign -i SYSIN
m_FileDelete ${DATA}/GBOM.J.PRD.ABOMJAW1.ABEND02
m_RcSet 0
_end
m_UtilityExec
JUMP_LABEL=END_JOB
;;
(END_JOB)
break
;;
(*)
m_RcSet ${MT_RC_ABORT:-S999} "Unknown label : ${CURRENT_LABEL}"
break
;;
esac
m_PhaseEnd
done
m_JobEnd
前述の例では、ジョブは任意のJESノードで送信できますが、実行できるのはJESのTuxedoサーバー・グループATLANTA
に属するARTJESINITIATOR
のみです。
m_JobBegin -j JOBA -s START -v 2.0
while true;
do
m_PhaseBegin
case ${CURRENT_LABEL} in
(START)
m_FileAssign -i -D \_DML_XMIT_TEST1 SYSIN
m_JobBegin -j TEST1 -s START -v 2.0 -c B
m_JobSetExecLocation "ATLANTA"
while true ;
do
m_PhaseBegin
case ${CURRENT_LABEL} in
(START)
JUMP_LABEL=STEP01
;;
(STEP01)
m_OutputAssign -c "*" SYSPRINT
m_FileAssign -i SYSIN
m_FileDelete ${DATA}/GBOM.J.PRD.ABOMJAW1.ABEND02
m_RcSet 0
_end
m_UtilityExec
JUMP_LABEL=END_JOB
;;
(END_JOB)
break
;;
(*)
m_RcSet ${MT_RC_ABORT:-S999} "Unknown label : ${CURRENT_LABEL}"
break
;;
esac
m_PhaseEnd
done
m_JobEnd
_DML_XMIT_TEST1
m_ProgramExec artjesadmin -i ${DD_SYSIN}
JUMP_LABEL=END_JOB
;;
(END_JOB)
break
;;
(*)
m_RcSet ${MT_RC_ABORT:-S999} "Unknown label : {CURRENT_LABEL}"
break
;;
esac
m_PhaseEnd
done
m_JobEnd
前述の例では、ジョブTEST1
は現在のジョブによって送信され、JESのTuxedoサーバー・グループATLANTA
に属するARTJESINITIATOR
によって実行されます。
バッチ・ランタイムのファイル・カタログ・サポートにより、ユーザーはボリュームの下にあるデータセットにアクセスできます。ボリュームとはデータセット・キャリアであり、フォルダとして存在します。各データセットはボリュームに属します。
ファイル・カタログには、各データセットから各ボリュームへのマッピングが含まれています。メインフレームにある既存のカタログ化されたファイルを参照すると、ファイル・カタログがリクエストされてファイルが位置するボリュームを検出してから、ファイルがアクセスされます。
ファイル・カタログ機能が無効の場合、バッチ・ランタイムの動作は、この機能がないだけで他は変わりません。
次の表は、バッチ・ランタイムによるファイル・カタログ機能の一般的な管理を示しています。この表では、各行が、ファイルとボリュームの1つのマッピングを表しています。
次の4つの構成変数をBatchRT.conf
に追加するか、環境変数として設定する必要があります。
MT_USE_FILE_CATALOG
MT_VOLUME_DEFAULT
MT_VOLUME_DEFAULT
で定義されるボリュームが使用されます。MT_VOLUME_DEFAULT
には、1つのボリュームのみを含めます。たとえば、MT_VOLUME_DEFAULT=volume1
と指定します。
MT_DB_LOGIN
your-database USER your-username USING your-password
" (例:"db2linux USER db2svr USING db2svr
")です。
MT_CATALOG_DB_LOGIN
MT_DB_LOGIN
と同じ形式です。ファイル・カタログはデータベースに保存されているので、BatchRTはMT_DB_LOGIN
、またはMT_CATALOG_DB_LOGIN
経由でアクセスする必要があります。
MT_CATALOG_DB_LOGIN
はMT_DB_LOGIN
よりも優先されます。ファイル・カタログDBがデータDBと同じである場合、構成が必要なのはMT_DB_LOGIN
のみです。それ以外の場合、両方とも構成する必要があります。
CreateTableCatalog[Oracle|Db2].sh
またはDropTableCatalog[Oracle|Db2].sh
を使用して、データベース表を新規作成または削除できます。
データベースに表ART_BATCH_CATALOG
を作成します。
CreateTableCatalog[Oracle|Db2].sh <DB_LOGIN_PARAMETER>
CreateTableCatalogOracle.sh scott/tiger@orcl
データベースから表ART_BATCH_CATALOG
を削除します。
DropTableCatalog[Oracle|Db2].sh <DB_LOGIN_PARAMETER>
DropTableCatalogOracle.sh scott/tiger@orcl
バッチ・ランタイムでファイル・カタログ機能を使用するには、ART Workbenchのファイル・コンバータおよびJCLコンバータがカタログ機能を有効にする必要があります。詳細は、 『Oracle Tuxedo Application Rehosting Workbenchユーザー・ガイド』を参照してください。
MT_REXX_PATH
のデフォルト値はありません。これは、すべてのREXX EXECが存在するメイン・パスで設定する必要があります。REXXプログラムを${MT_REXX_PATH}
の下の適切なサブディレクトリに入れます。これらのサブディレクトリは、REXXプログラムのあるメインフレーム上のPDSに対応します。
SYSEXEC
が定義されている場合、BatchRTは、m_ProgramExec
が実行するプログラムをREXX EXEC
として受け入れます。
DD SYSEXEC
は、オブジェクトREXXプログラムの場所を示します。
関連するREXXファイル(REXX APIとTSOコマンド)はすべて、Batch_RT/tools/rexx
ディレクトリに配置します。そのディレクトリ構造は次のとおりです。
TSOコマンドは、Batch_RT/tools/rexx/tso
にあります。REXX APIは、Batch_RT/tools/rexx/lib
ディレクトリに保存する必要があります。
注意: | TSOコマンドにはロック・メカニズムが用意されています。REXXプログラムでTSOコマンドがアクセスするファイルは、コマンドの起動時にロックされます。TSOコマンドの実行が完了すると、ファイルのロックはすべて解除されます。 |