|
|
構成ファイルはバッチ・ランタイムのCONFディレクトリ内に実装されます。
このような変数はバッチ・ランタイムを使用する前に設定する必要があります。
このファイルにはRTBatchによって使用されるメッセージが含まれます。
このファイルには、メッセージに関連付けられた内部コードが含まれます。
このファイルには、メッセージに関連付けられKSHスクリプトに返されるリターン・コードが含まれます。
ORACLE_SID、COBDIR、LIBPATH、COBPATHなど、いくつかの変数は、様々なコンポーネントで共有されている変数なので、現在のドキュメントでは説明しません。
詳細は、『Oracle Tuxedo Application Rehosting Workbenchインストレーション・ガイド』を参照してください。
表3-1には、KSHスクリプトで使用され、ソフトウェアを使用する前に定義しておく必要がある環境変数が一覧表示されています。
表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構成ファイルを参照)
|
表3-3には、バッチ・ランタイムで使用される、オプションの環境変数が一覧表示されています。
ユーザーが、異なるマシンからリソース(通常はファイル)を共有する可能性のあるジョブを実行するためにEJRを使用するか、MPモードTuxJESドメインを構成し、TuxJESで提供されているユーティリティを使用して任意のノードからジョブを送信する場合は、MPモードでうまく機能するようにバッチ・ランタイム(EJR)を特に構成する必要があります。
後者の場合、ノードAから送信されたジョブは、ノードBで実行される可能性があり、実行順序はまったくランダムです。同様に、異なるノードから送信されたこれらのジョブは、リソースを共有する可能性があります。
この項では、MPモードをサポートするためのバッチ・ランタイム(EJR)構成の詳細を具体的に説明します。
MT_ACC_FILE_PATHは、ドメイン内のすべてのマシンで同じマウント・ポイントを持つ共有記憶域(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.CUSTOMERJUMP_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.KBPRO001m_OutputAssign -c “*” SYSOUT
m_FileAssign -i LOGIN
IN-STREAM DATA
_end
m_FileAssign -d MOD LOGOUT ${DATA}/PJ01DDD.BT.QSAM.KBPRO091m_ProgramExec BPRAB001 "20071120"
JUMP_LABEL=END_JOB
;;
実行中のプログラムからabendルーチンのILBOABNOを呼び出して中断し、abendコードをKSHスクリプトに返すことができます。ILBOABNOは、ソースおよびバイナリのgntファイルの両方として提供されます。ユーザー定義の任意のCOBOLプログラムから直接呼び出せます。
(STEPPR15)
m_ProgramExec USER
JUMP_LABEL=END_JOB
;;
PROCEDURE DIVISION.
PROGRAM-BEGIN.
DISPLAY "USER: HELLO USER".
MOVE 2 TO RT-PARAM.
CALL "ILBOABNO" USING RT-PARAM.
DISPLAY "USER: CAN'T REACH HERE WHEN ILBOABNO 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.KBPRO001m_OutputAssign -c “*” SYSOUT
m_FileAssign -d SHR LOGIN ${DATA}/PJ01DDD.BT.SYSIN.SRC/BPRAS002 m_FileAssign -d MOD LOGOUT ${DATA}/PJ01DDD.BT.QSAM.KBPRO091m_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.KBIF001m_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.KBIF002m_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.KBIF003m_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.KBIF001m_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.KBIF002m_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によって暗黙的に作成されます。
(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.KBIFO091m_ProgramExec BIFAB090
…
バッチ・ランタイムには、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.FILE1m_GenDefine -s 30 -r ${DATA}/PJ01DDD.BT.FILE1m_GenDefine ${DATA}/PJ01DDD.BT.FILE2m_FileAssign -d NEW,CATLG -g +1 SYSUT2 ${DATA}/PJ01DDD.BT.FILE3m_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.GDGGDGベースのみをカタログ化できます。その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_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の書式で指定する必要があります。
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.KBDDI001m_ProgramExec BDDAB001
実行するコマンドを含む外部sysinファイルを使用するには、m_UtilityExec関数を使用します。
m_FileAssign -d OLD SYSIN ${SYSIN}/SYSIN/MUEX07
m_UtilityExec ファイル(世代ファイルを含む)は、m_FileDelete関数を使用して削除できます。
m_FileDelete ${DATA}/PJ01DDD.BT.QSAM.KBSTO045z/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.REPO001m_ProgramExec -b DBREP001
m_ProgramExec関数は、3種類の実行可能ファイル(COBOL実行可能ファイル、コマンド言語スクリプト、またはC実行可能ファイル)を送信できます。これによって、runbプログラムが起動されます。$ARTDIR/Batch_RT/ejr_mf_ora (Linux)およびejr_ora (その他のプラットフォーム)用のrunbを提供しています。Microfocus COBOLコンパイラもOracle Databaseも使用しない場合は、$ARTDIR/Batch_RT/ejrに移動して「make.sh」を実行し、必要なrunbを生成します。
runbプログラムは、データベース・ライブラリを使用してコンパイルされたランタイムで、runbatchプログラムを実行します。
INTRDRファシリティによって、sysoutのコンテンツをTuxJESに送信できます(TuxJESドキュメントを参照してください)。TuxJESが存在しない場合、コマンド「nohup EJR」が使用されます。
m_FileAssign -d SHR SYSUT1 ${DATA}/MTWART.JCL.INFOm_OutputAssign -w INTRDR SYSUT2
m_FileRepro -i SYSUT1 -o SYSUT2
${DATA}/MTWART.JCL.INFOファイルのコンテンツ(ddname SYSUT1)は、ddnameがSYSUT2のファイルにコピーされ、オプション「-w INTRDR」の使用が送信されます。
出力ファイルには有効なksh構文が含まれる必要がありますのでご注意ください。
| 注意: | 実行時に生成されたバッチ・ジョブ・スクリプトがJCL言語の場合、それはINTRDRでは発行できません。 |
バッチ・ランタイムを使用する場合は、TuxJESを使用してジョブを起動できます(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.ABEND02m_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.ABEND02m_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つのマッピングを表しています。
3つの構成変数をBatchRT.confに追加するか、環境変数として設定する必要があります。
MT_VOLUME_DEFAULTで定義されるボリュームが使用されます。MT_VOLUME_DEFAULTには、1つのボリュームのみを含めます。たとえば、MT_VOLUME_DEFAULT=volume1と指定します。
MT_DB_LOGINを通じてこれにアクセスします。Oracleの場合、その値はusername/password@sidです(たとえば、scott/tiger@gdg001)。Db2の場合、その値はyour-database USER your-username USING your-passwordです(たとえば、db2linux USER db2svr USING db2svr)。
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ユーザー・ガイド』を参照してください。
  
|