|
|
構成ファイルはバッチ・ランタイムのCONFディレクトリ内に実装されます。
このような変数はバッチ・ランタイムを使用する前に設定する必要があります。
このファイルにはRTBatchによって使用されるメッセージが含まれます。
このファイルには、メッセージに関連付けられた内部コードが含まれます。
このファイルには、メッセージに関連付けられKSHスクリプトに返されるリターン・コードが含まれます。
ORACLE_SID、COBDIR、LIBPATH、COBPATHなど、いくつかの変数は、様々なコンポーネントで共有されている変数なので、現在のドキュメントでは説明しません。Rehosting Workbenchのインストレーション・ガイドを参照してください。
表3-1には、KSHスクリプトで呼び出され、ソフトウェアを使用する前に定義されている必要がある環境変数が一覧表示されています。
表3-2には、バッチ・ランタイムで呼び出され、ソフトウェアを使用する前に定義されている必要がある環境変数が一覧表示されています。
Oracle Tuxedo Application Runtime for Batchは、ジョブの異なる実行フェーズが明確に識別されるスクリプト・モデルを提案することによって、Kornシェル・スクリプトを正規化します。
Oracle Tuxedo Application Runtime for Batchスクリプトは、固有の書式を尊重することで、KSH(JOB)の異なるフェーズの定義とチェイニングを可能にします。
バッチ・ランタイム内のフェーズは、ソース・システム上のアクティビティまたは手順に対応します。
フェーズはラベルによって識別され、次のフェーズによって区切られます。
各フェーズの終わりでJUMP_LABEL変数が更新され、次に実行されるフェーズのラベルを提供します。
次の例では、最後の機能フェーズが、JUMP_LABELをJOBENDに設定します。このラベルにより、ジョブの正常終了(フェーズ・ループを終了)が可能になります。
表3-3に示されているように、スクリプトの必須の部分(最初と最後の部分)は太字で表示され、スクリプトの機能部分(中間の部分)は通常の書式で表示されます。スクリプトのオプションの部分には、次に示すように、ラベル、分岐および手順の終了が含まれる必要があります。変更されるスクリプトの項目は、斜体で表示されます。
リスト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=ENDJOB
;;
(ABORT)
break
;;
(ENDJOB)
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
;;
Oracle Tuxedo Application Runtime for Batchには、プロシージャを定義して、使用するために一連の関数が用意されています。これらのプロシージャは、一般に、z/OS JCLのプロシージャと同じ原則に従います。
z/OS JCL規則とは異なり、ストリーム内プロシージャは主要JOBの末尾の後に記述する必要があります。つまり、ジョブに属するすべてのストリーム内プロシージャは、関数m_JobEndの呼出しの後に出現する必要があります。
Kornシェル・スクリプトのストリーム内プロシージャは、常にまずm_ProcBegin関数を呼び出し、次にプロシージャを構成するすべてのタスクが続き、m_ProcEnd関数を呼び出して終了します。リスト3-4はサンプルです。
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-5に示すプロシージャの一部をなすタスクをコーディングするだけです。
プロシージャのコードと呼出しジョブの統合を簡素化するには、常に、プロシージャの先頭を次のようにします。
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-6に示した上記の原則が尊重されていれば、ストリーム内プロシージャまたは外部プロシージャを、呼出しジョブのいかなる場所でも使用できます。
…
(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-9は、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-11に示すように、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-12に示すように、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_CondEnd関数の使用方法。「手順実行の条件付け」を参照してください。 バッチ・ランタイム管理者がデフォルト・メッセージを変更する場合(たとえば言語を変更する場合)、環境変数MT_DISPLAY_MESSAGE_FILEでパスが指定された構成ファイルを介して行うことができます。
このファイルは、区切り記号としてセミコロンを使用するCSVファイルです。このファイルの各レコードには、特定のメッセージが記載され、6つのフィールドで構成されます。
ファイルは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
…
z/OSメインフレームにはあるが、UNIX標準ではない世代ファイルの概念を再現するために、バッチ・ランタイムは、一連の関数を用意してこの種のファイルを取り扱います。
GDG(世代データ・グループ)ファイルは、m_GenDefine function関数を介して定義されます。指定する唯一のパラメータは、ディスク上に保持するバージョンの数の最大値です。
m_GenDefine -s 31 ${DATA}/PJ01DDD.BT.GDG注意: m_GenDefine関数はGDGファイルを定義するために必須ではありません。リスト3-15で示されるように、GDGファイルは9999を限度として作成されます。
(STEP03)
m_FileAssign -d SHR SYSUT1 ${DATA}/PJ01DDD.BT.FILE1 m_FileAssign -d NEW,CATLG -g +1 SYSUT2 ${DATA}/PJ01DDD.BT.GDGm_FileRepro -i SYSUT1 -o SYSUT2
m_FileAssign関数には、割り当てるファイルを世代ファイルとして指定し、目的のファイル・バージョンをリスト3-16どおりに設定する特別なパラメータ(-g)があります。
(STEPDD05)
m_FileAssign -d SHR -g +1 INFIL ${DATA}/PJ01DDD.BT.GDG m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBDDO002m_ProgramExec BDDAB001
m_FileAssign関数は、GDGのすべての世代を指定するために使用できます。
リスト3-17で示すように、SORT関数にはAP.GDGという名前のGDGファイルのすべての世代が含まれます。
(PT0010)
m_FileAssign -d SHR SORTIN ${DATA}/APP.GDG m_FileAssign -d NEW,CATLG,DELETE SORTOUT ${DATA}/AP.GDG.SORTm_FileAssign -i SYSIN
SORT FIELDS=COPY
_end
m_FileSort -s SYSIN -i SORTIN -o SORTOUT
データがKornシェル・スクリプトに直接書き込まれるファイルを定義して使用するには、-iパラメータを指定してm_FileAssign 関数を使用します。デフォルトでは、文字列_endはリスト3-18で示されるようにストリーム内フローの「最終」デリミタです。
(STEP1)
m_FileAssign -i INFIL
data record 1
data record 2
…
_end
一連のファイルを連結入力として使用するには、リスト3-19に示すように-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 NEW 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-20に示すように、実行される主プログラムはRDBMSを直接使用しないが、その後に続くサブプログラムのいずれかが使用する場合は、-bオプションも使用する必要があります。
(STEPDD02)
m_FileAssign -d MOD OUTF ${DATA}/PJ01DDD.BT.QSAM.REPO001m_ProgramExec -b DBREP001
m_ProgramExec関数は、3種類の実行可能ファイル(COBOL実行可能ファイル、コマンド言語スクリプト、またはC実行可能ファイル)を送信できます。これによって、runbプログラムが起動されます。
runbプログラムは、データベース・ライブラリを使用してコンパイルされたランタイムで、runbatchプログラムを実行します。
INTRDRファシリティによって、sysoutのコンテンツをTuxJESに送信できます(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)は、ddnameがSYSUT2のファイルにコピーされ、オプション「-w INTRDR」の使用が送信されます。
出力ファイルには有効なksh構文が含まれる必要がありますのでご注意ください。
バッチ・ランタイムを使用する場合は、TuxJESを使用してジョブを起動できます(TuxJESのドキュメントを参照)が、EJRスポーナを使用してジョブを直接実行することもできます。
この種の実行を行う前に、全体のコンテキストが正しく設定されていることを確認します。これには、バッチ・ランタイムが必要とする環境変数やディレクトリも含まれます。
# EJR DEFVCUST.ksh
EJRスポーナの完全な説明は、『Oracle Tuxedo Application Runtime for Batchリファレンス・ガイド』を参照してください。
バッチ・ランタイムは、起動された各ジョブに対して、実行された各手順(フェーズ)の情報を含むログ・ファイルを作成します。このログ・ファイルには、リスト3-21で示されるように、次の構造体が含まれます。
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)の使用に関する項を参照してください。
一部の関数(m_JobBegin、m_JobEnd、m_PhaseBegin、m_PhaseEnd)には、選択されたジョブ・スケジューラとの関係で行われる特定のアクションを挿入するためのエントリ・ポイントが用意されています。
SQLリクエストは、m_ExecSQL関数を使用して実行できます。
ターゲット・データベースに従い、この関数はORACLEデータベースでは「sqlplus」コマンドを実行し、UDBでは「db2 -tsx」コマンドを実行します。
環境変数MT_DB_LOGINを設定する必要があります(データベース接続ユーザー・ログイン)。
SYSINファイルにはSQLリクエストを含める必要があり、ユーザーはデータベース・ターゲットに関するコンテンツを検証する必要があります。
  
|