1. Application Runtime for Batchユーザーズ・ガイド
  2. バッチ・ランタイムの使用方法

2 バッチ・ランタイムの使用方法

この章のトピックは、次のとおりです:

2.1 構成ファイル

構成ファイルはバッチ・ランタイムのCONFディレクトリ内に実装されます。

親トピック: バッチ・ランタイムの使用方法

2.1.1 BatchRT.conf

このファイルには変数の定義が含まれます。

このような変数はバッチ・ランタイムを使用する前に設定する必要があります。

親トピック: 構成ファイル

2.1.2 Messages.conf

このファイルにはRTBatchによって使用されるメッセージが含まれます。

メッセージはローカル言語に翻訳できます。

親トピック: 構成ファイル

2.1.3 FunctionReturnCode.conf

このファイルには、メッセージに関連付けられた内部コードが含まれます。

親トピック: 構成ファイル

2.1.4 ReturnCode.conf

このファイルには、メッセージに関連付けられKSHスクリプトに返されるリターン・コードが含まれます。

親トピック: 構成ファイル

2.1.5 Writer.conf

このファイルには、ライターの使用法とサンプルが収められています。

ユーザーはこのファイルに自分のライターを追加できます。

親トピック: 構成ファイル

2.2 環境変数の設定

ORACLE_SID、COBDIR、LIBPATH、COBPATHなど、いくつかの変数は、様々なコンポーネントで共有されている変数なので、現在のドキュメントでは説明しません。詳細は、 『Rehosting Workbenchインストレーション・ガイド』を参照してください。

親トピック: バッチ・ランタイムの使用方法

2.2.1 EJRの環境変数

次の表には、KSHスクリプトで使用され、ソフトウェアを使用する前に定義しておく必要がある環境変数が一覧表示されています。

表2-1 KSHスクリプトの環境変数

変数 使用方法
DATA 永久ファイルのディレクトリ
TMP 一時アプリケーション・ファイルのディレクトリ。
SYSIN sysinが保存されるディレクトリ。
MT_JOB_NAME バッチ・ランタイムによって管理されるジョブ名。
MT_JOB_PID バッチ・ランタイムによって管理されるジョブのPID (プロセスID)。

ノート:

DATAおよびTMPでは、フルパスには[a-zA-Z0-9_/.]のみを含めることができます。
次の表には、バッチ・ランタイムで使用され、ソフトウェアを使用する前に定義しておく必要がある環境変数が一覧表示されています。

表2-2 Oracle Tuxedo Application Runtime for Batchの環境変数

変数 使用方法
JESDIR TuxJESのインストール先のディレクトリ
PROCLIB 変換フェーズ中に使用されるPROCおよびINCLUDEファイルのディレクトリ。
MT_ACC_FILEPATH AccLockおよびAccWaitファイルを格納するファイル同時実行性アクセスのディレクトリ。これらのファイルは、バッチ・ランタイムを実行する前に空の状態で作成する必要があります()。
MT_COBOL 使用されるCOBOLに従って次を含める必要があります。
  • Micro Focus COBOLの場合は「COBOL_MF」
  • COBOL-ITの場合は「COBOL_IT」
  • 実行するCOBOLプログラムが何もなく、COBOL製品を使用しない場合、「“COBOL_NONE"」。また、この設定では、GDG、LSEQ、固定幅のSEQ、およびPDSの各ファイルのみがサポートされます。
MT_CTL_FILES m_DBTableLoad関数によって使用される制御ファイル(CTL)のディレクトリ(ORACLEではsqlldr、UDBではloadとexport)。
MT_DSNUTILB_LOADUNLOAD

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_DB_DEFAULT_SCHEMA MT_DSNUTILB_LOADUNLOADがyesに設定されている場合に、DBのデフォルトのスキーマを示します。デフォルト値はDEFSCHEMAです。この変数は、COBOLプログラムschema-table-Lおよびschema-table-Uのスキーマを指定するために使用されます。
MT_DB

ターゲット・データベースに従って次を含める必要があります。

- 「DB_ORACLE」: ORACLEを意味します

- 「DB_DB2LUW」: UDBを意味します

MT_DB_LOGIN データベース接続ユーザー。
MT_FROM_ADDRESS_MAIL 「-f」オプションを省略するときにm_SendMail関数によって使用されるFrom-Address。
MT_FTP_TEST 転送を実行するまたは実行しない(テスト・モード)ためにm_Ftp関数によって使用される変数。
MT_GENERATION GDGテクニカル関数へのディレクトリを示す必須環境変数。

デフォルトのディレクトリはGENERATION_FILEです。データベースでGDGファイルを管理するには、値をGENERATION_FILE_DBに設定し、MT_GDG_DB_ACCESSを適切に構成する必要があります。値がNULLとして指定されているか、不正なディレクトリ名が指定されている場合、この環境変数を使用するとエラーが発生します。
MT_KSH

使用される「ksh」のパス(pdkshまたはksh88のみ)。

ノート:

  • 他のマシンからpdkshをコピーしないでください。公式のWebサイトからソース・コードをダウンロードして、そこからpdksh実行可能ファイルをビルドするか、対応するOSリリースのイメージに含まれている正式なインストーラでpdkshをインストールしてください。
  • 最新のLinux/UNIXプラットフォームはデフォルトのCPU周波数として100を使用するため、ソース・コードからpdkshをビルドする場合は、CPU周波数(ksh_time.hのCLK_TCK)を60HZから100HZの範囲で決定することをお薦めします。
  • pdkshの詳細は、https://github.com/Orc/pdkshを参照してください
MT_LOG Logsディレクトリ(TuxJesを使用しない)。
MT_ROOT バッチ・ランタイム・アプリケーションがインストールされるディレクトリ。(BatchRT.conf構成ファイルを参照)
MT_SMTP_PORT m_Smtpおよびm_SendMail関数によって使用されるポート(デフォルトではlocalhost)。
MT_SMTP_SERVER m_Smtpおよびm_SendMail関数によって使用されるサーバー(デフォルトでは25)。
MT_SORT 使用されるSORTに従って次を含める必要があります。

- Micro Focus Sort Utilityの場合は「SORT_MicroFocus」

- SyncSortソート・ユーティリティの場合、「SORT_SyncSort」

- citsortユーティリティの場合、「SORT_CIT」
MT_SYSOUT Sysoutディレクトリ(TuxJesを使用しない)。
MT_TMP

一時内部ファイルのディレクトリ
MT_EXCI

EXCIインタフェース(デフォルトはOracle Tuxedoです)。
MT_JESDECRYPT MT_JESDECRYPTはjesdecryptオブジェクト・ファイルに設定する必要があります。
MT_EXCI_XA

XAのリソース・マネージャの名前。

MT_EXCIGRPNAME

ARTDPLサーバーのTUXEDO SRVGRP値。

関連項目:

詳細は、「BatchRT.conf」を参照してください

ノート:

次の環境変数では、フルパスには[a-zA-Z0-9_/.]のみを含めることができます
  • JESDIR
  • MT_KSH
  • MT_LOG
  • MT_REFINEDIR
  • MT_SYSOUT
  • MT_TMP

次の表には、バッチ・ランタイムで使用される、オプションの環境変数が一覧表示されています。

表2-3 Oracle Tuxedo Application Runtime for Batchの環境変数(オプション)

変数 使用方法
MT_ACC_WAIT 他のジョブによってロックされているファイルにジョブがアクセスするときの、ファイル・ロックを取得するための再試行間隔(秒)。
MT_ACC_MAXWAIT ファイル・ロックを取得するときの最大待機時間(秒)。この時間内にロックを取得できない場合は、関連するファイル操作が失敗します。
MT_CATALOG_DB_LOGIN データベース・ファイル・カタログへアクセスするための、有効なデータベース・ログイン情報で使用される変数。MT_DB_LOGINと同じ形式です

ノート:

ファイル・カタログへのアクセスでは、MT_DB_LOGINよりも前に来ます。ファイル・カタログDBがデータDBと同じである場合、構成が必要なのはMT_DB_LOGINのみです。それ以外の場合、両方とも構成する必要があります。
MT_CLEANUP_EMPTY_SYSOUT ジョブ実行の最後に、空のSYSOUTファイルをクリーン・アップするかどうかを制御します。
  • MT_CLEANUP_EMPTY_SYSOUT=Y: 空のSYSOUTファイルをクリーン・アップします。
  • MT_CLEANUP_EMPTY_SYSOUT=N: 空のSYSOUTファイルをクリーン・アップしません。

デフォルト値は、Yです。

MT_CONFIG_FILE ejr/CONF下のデフォルト構成ファイルBatchRT.confのかわりに指定した構成ファイルを使用するための変数。
  • EJRから送信されるジョブの場合、あらかじめこの変数をエクスポートします。この変数を設定解除すると、デフォルト構成ファイルBatchRT.confをリストアできます。
  • TUXJesから送信されるジョブの場合、TuxJesサーバーを再起動する前にこの変数をエクスポートします。この変数を設定解除し、TUXJesサーバーを再起動すると、デフォルト構成ファイルBatchRT.confをリストアできます。

    この変数が設定されていない場合、"ejr/CONF"の下の構成ファイル BatchRT.confが使用されます。

MT_CPU_MON_STEP すべてのジョブのステップのCPU使用時間率のモニターを有効化するのに使用される変数。MT_CPU_MON_STEP=yesを設定して、すべてのジョブのステップのCPU使用時間率のモニターを有効化します。

MT_CPU_MON_STEPが構成されていない、またはその値がyesと等しくない場合は、この機能は無効になります。

MT_DB_LOGIN2

データベースにアクセスする場合に有効なデータベース・ログイン情報とともに使用されます。

MT_DB_LOGIN2がnull以外の値の場合、BatchRTはrunb2 (OracleおよびDB2の並列アクセスをサポートする)を使用します。
MT_DB_SQL_PREPROCESS SQLの実行前に実行するDBプリプロセッサを指定します。ビルトインのDB2-to-Oracle SQL Converterは${JESDIR}/tools/sql/oracle/BatchSQLConverter.shです。
MT_DB2_SYSTEM_MAPPING

フル・ファイル・パスを指定します。このファイルは、"DB SYSTEM"からDB接続資格証明文字列へのマッピングを格納するために使用されます。ファイルの書式は次のとおりです。

<DB SYSTEM NAME>:<DB TYPE>:<Connection String>
  • <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"は無視されます)。

m_FileAssign -i SYSIN

m_ProgramExec -s ORA02 -b COBOL_PGM

_end

m_UtilityExec -s ORA01 SYSIN

MT_DSNTIAUL これが"Y"に構成されている場合、バッチ・ランタイムは、Oracle Database表からデータをアンロードするためにDSNTIAULユーティリティを提供します。このユーティリティには、DB2を使用したメインフレームのDSNTIAULユーティリティと同じ機能があります。これが"N"に構成されているか、何も構成されていない場合、バッチ・ランタイムはSQL文を実行し、特定のファイルにプレーン・テキストで出力を書き込みます。デフォルト値は、"Y"です。
MT_EJRLOG "Y"に設定されている場合、BatchRTはEJRログ・ファイルを生成し、各フェーズのログをそこに書き込みます。"N"に設定されている場合、BatchRTはEJRログ・ファイルを生成しません。デフォルト値は、"Y"です。
MT_EXCI_PGM_LIST 実行プログラムのリスト。プログラムは、runbではなく、runbexciによって起動されます。このリスト内の各プログラムの場合、-nがm_ProgramExecで指定されているかどうかにかかわらず、プログラムはrunbexciでのみ起動されます。

デフォルト値は空です。プログラムはカンマで区切ります。例:

MT_EXCI_PGM_LIST=PGM1,PGM2

MT_FTP_PASS JESセキュリティ・プロファイルに保存され、実行時に使用されるftpパスワードを設定します。
MT_GDG_DB_ACCESS GDG管理用にOracle Databaseにアクセスする際の、有効なデータベース・ログイン情報で使用される変数。たとえば、user/password@sid。MT_GENERATIONがGENERATION_FILE_DBに設定されている場合は必須です。
MT_GDG_DB_BUNCH_OPERATION "Y"に設定されている場合、GDGの変更は1回のデータベース・アクセスでコミットされます。

"N"に設定されている場合、GDGの変更は1回以上のデータベース・アクセスでコミットされます。デフォルト値は「N」です。

MT_GDG_USEDCB GDG用にDCBサポート機能を有効にするときに使用する変数。
  • MT_GDG_USEDCB=Y: GDG用の.dcbファイルを作成します(デフォルト動作)。このモードでは、m_FileAssign文のGDGメンバーのファイル・タイプとしてLSEQまたはSEQを指定できます。
  • MT_GDG_USEDCB=N: GDG用の.dcbファイルを作成しません。このモードでは、GDGメンバーのファイル・タイプはLSEQのみで、m_FileAssign文で指定したファイル・タイプは無視されます。
MT_META_DB ファイル・カタログとGDGメタ・データに使用されるデータベース。デフォルトはnullです
  • ORACLEの場合はDB_ORACLE
  • UDBの場合はDB_DB2LUW

MT_META_DBにNULL以外の値が入っている場合、BatchRTはMT_META_DBで定義されたデータベース・タイプをメタ・データに使用します。これ以外の場合はMT_DBが使用されます。

MT_REFINEDIR Workbench refineの完全インストール・パス。JCLジョブをKSHジョブに変換するために起動されます。例:

MT_REFINEDIR=/newspace/public/WB_Test/wb12110/refine
MT_REFINEDISTRIB 環境変数REFINEDISTRIBの値。WorkbenchがJCLジョブを変換するときに使用されます。例:
  • MT_REFINEDISTRIB = Linux64: REFINEDISTRIBをLinux64に設定します
  • MT_REFINEDISTRIB = Linux32: REFINEDISTRIBをLinux32に設定します
MT_RUNB_SIGNAL_TO_TRAP

バッチ・ランタイムによって処理されるユーザー・アプリケーションの実行によって生じるすべての信号が含まれます。デフォルト値は、サポートしているすべての信号です。例:

MT_RUNB_SIGNAL_TO_TRAP=${MT_RUNB_SIGNAL_TO_TRAP:-"1 2 3 4 6 7 8 11 13 14 15"}
MT_SYS_IO_REDIRECT BatchRT.confでは、この項目は、m_ProgramExecによって実行されるCOBOLプログラムのSYSINおよびSYSOUTをrunbでリダイレクトするために使用されます。
  • SYSINが設定されている場合は、ユーティリティのstdinがファイル${DD_SYSIN}にリダイレクトされます。
  • SYSOUTが設定されている場合は、ユーティリティのstdoutおよびstderrがファイル${DD_SYSOUT}にリダイレクトされます。
  • デフォルトはMT_SYS_IO_REDIRECT=SYSIN,SYSOUT
MT_SYSLOG EJRモードで"Y"に設定されている場合、BatchRTはSYSLOGファイルを生成します。"N"に設定されている場合、BatchRTはSYSLOGログ・ファイルを生成しません。デフォルト値は、"Y"です。
MT_SYSLOG_MILLISECOND "Y"に設定されている場合、SYSLOGファイルのステップ開始時刻とステップ終了時刻には時、分、秒またはミリ秒を使用します。"N"に設定されている場合、時、分または秒を使用します(ミリ秒は使用できません)。デフォルト値は「N」です。
MT_USERENTRYEXIT ユーザー・エントリ/終了関数を有効にするかどうかを制御します。
  • MT_USERENTRYEXIT=Y: ユーザー・エントリ/終了関数を有効にします。
  • MT_USERENTRYEXIT=N: ユーザー・エントリ/終了関数を無効にします。

デフォルト値は、Yです。詳細は、「ユーザー定義のエントリ/終了」を参照してください。

MT_UTILITY_LIST_UNSUPPORT 実行可能プログラムのリスト。これらのプログラムが存在しなくても、どのジョブも失敗させないようにします。m_ProgramExecが、存在しないプログラムを呼び出しても、それらのプログラムがこのリストに指定されている場合、JOBは継続されます。例:

MT_UTILITY_LIST_UNSUPPORT=IEHINITT,IEHLIST,IEHMOVE,IEHSTATR,IEHPROGM,IEBCOMPR,IEBEDIT,IEBIMAGE,IEBUPDTE,IEBDG,IEBPTPCH
MT_WB_HOSTNAME Workbenchがインストールされ、JCLジョブをKSHジョブに変換するために起動される、ホスト名(またはIPアドレス)。Workbenchがローカルホストにある場合、MT_WB_HOSTNAMEの値はNULLです。ユーザー名をオプションで追加できます。例:
  • MT_WB_HOSTNAME=host1: MT_WB_HOSTNAMEの値をhost1に設定します
  • MT_WB_HOSTNAME=user1@host1: MT_WB_HOSTNAMEの値をuser1@host1に設定します

    ノート:

    Workbenchがリモート・マシンにデプロイされ、ARTJESCONVサーバーが別のマシンにデプロイされている場合は、設定が必要です。
MT_SORT_BY_EBCDIC

"Y"に設定されている場合、レコード・シーケンシャルASCIIファイルはEBCDIC順にソートされます。

"N"に設定されている場合、レコード・シーケンシャルASCIIファイルはASCII順にソートされます。

デフォルト値は「N」です。

MT_SIGN_EBCDIC "Y"に設定されている場合、DISPLAY符号付き数値項目の符号はEBCDIC規則に従って解釈されます。

"N"に設定されている場合、DISPLAY符号付き数値項目の符号はASCII規則に従って解釈されます。

デフォルト値は、"Y"です。

MT_PROG_RC_ABORT この環境変数は、データセットの終了操作を制御します。MT_PROG_RC_ABORT以上のリターン・コードは中断とみなされ、MT_PROG_RC_ABORT未満のコードはコミットとみなされます。

デフォルト値は1です。

親トピック: 環境変数の設定

2.2.2 ネイティブJCLの環境変数

次の表には、ネイティブJCLバッチ・ランタイムで使用され、ソフトウェアを使用する前に定義しておく必要がある環境変数が一覧表示されています。

表2-4 Oracle Tuxedo Application Runtime for Native JCL Batchの環境変数

変数 使用方法
JESDIR TuxJESのインストール先のディレクトリ
DATA 永久ファイルのディレクトリ
TMP 一時アプリケーション・ファイルのディレクトリ。
PROCLIB PROCおよびINCLUDEファイルの検索に使用されるディレクトリ。
MT_ACC_FILEPATH AccLockおよびAccWaitファイルを格納するファイル同時実行性アクセスのディレクトリ。これらのファイルは、バッチ・ランタイムを実行する前に空の状態で作成する必要があります。
MT_COBOL 使用されるCOBOLに従って次を含める必要があります。
  • COBOL_MF: Micro Focus COBOLを使用することを意味します
  • COBOL_IT: COBO-IT COBOLを使用することを意味します
MT_DB ターゲット・データベースに従って次を含める必要があります。
  • DB_ORACLE: Oracleを使用することを意味します
  • DB_DB2LUW: DB2を使用することを意味します
MT_DB_LOGIN データベース接続情報。
MT_LOG ログ・ディレクトリ。
MT_TMP 一時内部ファイルのディレクトリ。

次の表には、ネイティブJCLバッチ・ランタイムで使用される、オプションの環境変数が一覧表示されています。

表2-5 Oracle Tuxedo Application Runtime for Native JCL Batchの環境変数(オプション)

変数 使用方法
DSNUTILB_PARALLEL_NUM ユーティリティDSNUTILBのロード・プロセスで表にレコードを挿入するためのスレッドの数を設定します。デフォルト値は、5です。
JESTRACE ログ出力のレベルを制御します。次のいずれかの値を指定できます。ERROR、WARN、INFO、DEBUGおよびDUMP。デフォルト値はINFOです。
MT_VOLUME_DEFAULT MT_VOLUME_DEFAULTが空でない値に設定された場合、カタログ機能が有効になります。これは、新しいデータセットの作成時にボリュームが指定されない場合、ボリューム値として使用されます。MT_VOLUME_DEFAULTが設定されない場合、カタログ機能は無効になります。
MT_E2A_FILE カスタマが指定したEBCDICからASCIIのマッピング表ファイルを識別します。

ファイル形式は1行1文字です。

00;61

01;50

...

MT_ACC_WAIT 他のジョブによってロックされているファイルにジョブがアクセスするときの、ファイル・ロックを取得するための再試行間隔(秒)。デフォルト値は5です。
MT_ACC_MAXWAIT ファイル・ロックを取得するときの最大待機時間(秒)。この時間内にロックを取得できない場合は、関連するファイル操作が失敗します。デフォルト値は0です。
MT_DB_LOGIN2 データベースにアクセスする場合に有効なデータベース・ログイン情報とともに使用されます。MT_DB_LOGIN2がnull以外の値の場合、BatchRTはOracleおよびDB2の並列アクセスを使用します。
MT_DB2_SYSTEM_MAPPING ファイル名をフル・パスで指定します。このファイルは、"DB SYSTEM"からDB接続資格証明文字列へのマッピングを格納するために使用されます。ファイルの書式は次のとおりです。

<DB SYSTEM NAME>:<DB TYPE>:<Connection String>

  • <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接続資格証明文字列へのマッピング機能が有効になります。それ以外の場合、この機能は無効になります。

MT_DSNTIAUL これが"Y"に構成されているか、何も構成されていない場合、バッチ・ランタイムは、Oracle Database表からデータをアンロードするためにDSNTIAULユーティリティを提供します。このユーティリティには、DB2を使用したメインフレームのDSNTIAULユーティリティと同じ機能があります。これが"N"に構成されている場合、バッチ・ランタイムはSQL文を実行し、特定のファイルにプレーン・テキストで出力を書き込みます。デフォルト値は、"Y"です。
MT_SORT 使用されるSORTによって異なります。次を含める必要があります
  • Micro Focus Sort Utilityの場合はSORT_MicroFocus。
  • SyncSortソート・ユーティリティの場合はSORT_SyncSort
  • citsortユーティリティの場合はSORT_CIT

指定されない場合、MT_COBOLによって異なります。

  • MT_COBOL=MFが設定された場合は、SORT_MicroFocus
  • MT_COBOL=ITが設定された場合は、SORT_CIT
MT_SIGN_EBCDIC 符号付き数値DISPLAY項目の解釈方法を指定します。
  • Y: デフォルト。EBCDIC規則に従って解釈されます。
  • N: ASCII規則に従って解釈されます。
MT_SORT_BY_EBCDIC レコード・シーケンシャルASCIIファイルのソート方法を指定します。
  • Y: ファイルはEBCDIC順にソートされます。
  • N: デフォルト。ファイルはASCII順にソートされます。
MT_RUNB_SIGNAL_TO_TRAP BatchRTが処理するユーザー・アプリケーションの実行によって生じるすべての信号を一覧表示します。

次に示すように、値はスペースで区切られます。

MT_RUNB_SIGNAL_TO_TRAP="1 2 3 4 6 7 8 11 13 14 15"
MT_SYS_IO_REDIRECT ARTCOBRUNが実行するユーティリティについてSYSINおよびSYSOUTがリダイレクトされるかどうかを指定します。
  • SYSINが設定された場合、ユーティリティのstdinはファイル${DD_SYSIN}にリダイレクトされます。
  • SYSOUTが設定された場合、ユーティリティのstdoutおよびstderrはファイル${DD_SYSOUT}にリダイレクトされます。
  • SYSINとSYSOUTの両方を同時に設定できます。その場合は、SYSIN,SYSOUTのようにカンマで区切ってください。

デフォルト値はSYSOUTです。

MT_PROG_RC_ABORT MT_PROG_RC_ABORT以上のリターン・コードは中断とみなされ、MT_PROG_RC_ABORT未満のコードはコミットとみなされます。

デフォルト値は1です。

親トピック: 環境変数の設定

2.3 MPモードでのバッチ・ランタイムの構成

ユーザーがバッチ・ランタイム(EJR)を使用して異なるマシンからジョブを実行する(リソース(通常はファイル)を共有する場合がある)か、MPモードのTuxJESドメインを構成し、TuxJESが提供するユーティリティを使用して任意のノードからジョブを送信する場合、EJRを特別に構成して、MPモードで問題なく機能するようにする必要があります。

後者の場合、ノードAから送信されたジョブは、ノードBで実行される可能性があり、実行順序はまったくランダムです。同様に、異なるノードから送信されたこれらのジョブは、リソースを共有する可能性があります。

この項では、MPモードをサポートするためのバッチ・ランタイム(EJR)構成の詳細を具体的に説明します。

  1. あるマシンから送信されたジョブは別のマシンで実行される可能性があるため、どのファイルも各ノードのビューから必ず同じパスを持つように、すべてのリソースを、ドメイン内のすべてのマシンで同じマウント・ポイントを持つ共有記憶域(NFS)に置く必要があります。たとえば、ユーザーがすべてのファイルを前の項で説明した環境変数DATAの下で保存することを希望する場合、${DATA}は、ファイルが置かれていて、すべてのマシンで同じ値を持つ共有ルート・ディレクトリを指す必要があります。
  2. MT_ACC_FILEPATHは共有ストレージ(NFS)に置かれ、そのストレージはドメイン上のすべてのマシンで同じマウント・ポイントを持つ必要があります。これは、ファイル・ロッキングの制御ファイルがこのディレクトリに置かれるためです。さらに、ユーザーは、このディレクトリの下のAccLockとAccWaitファイルを、ジョブを実行しているプロセスの実効ユーザーが読み書きできるようにしておく必要があります
  3. NLM (Network Lock Manager)は、NFSサーバーおよびドメイン内のすべてのマシンで有効にする必要がありますが、これは、NFSにある一部の共有リソースを、ジョブによる破損を防ぐためにロックする必要があるからです。構成はバッチ・ランタイムと直接関係はありませんが、MPモードでは緊密な関係があります。
  4. MPドメイン内のノードごとにARTJESADMサーバーを構成および起動して、このノードのジョブが実行されているかどうかを他のノードで確認する必要があります。これは、バッチ・ランタイムのファイル・ロック・メカニズムの一部です。1つのノード上のARTJESADMサーバーが異常終了したり、ノード自体が異常終了すると、そのノードで実行されているジョブが所有するファイル・ロックは自動的には解放されません。その場合は、ユーティリティartjescleanlockを使用して非アクティブなファイル・ロックを解放できます。artjescleanlockの詳細は、「Tuxedo Job Enqueueing Service (TuxJES)の使用」を参照してください。

親トピック: バッチ・ランタイムの使用方法

2.4 スクリプトの作成

この項には次の情報が含まれます:

親トピック: バッチ・ランタイムの使用方法

2.4.1 スクリプトの一般的な構造

Oracle Tuxedo Application Runtime for Batchは、ジョブの異なる実行フェーズが明確に識別されるスクリプト・モデルを提案することによって、Kornシェル・スクリプトを正規化します。

Oracle Tuxedo Application Runtime for Batchスクリプトは、固有の書式を尊重することで、KSH (JOB)の異なるフェーズの定義とチェイニングを可能にします。

バッチ・ランタイム内のフェーズは、ソース・システム上のアクティビティまたはステップに対応します。

フェーズはラベルによって識別され、次のフェーズによって区切られます。

各フェーズの終わりでJUMP_LABEL変数が更新され、次に実行されるフェーズのラベルを提供します。

次の例では、最後の機能フェーズが、JUMP_LABELをJOBENDに設定します。このラベルにより、ジョブの正常終了(フェーズ・ループを終了)が可能になります。

次の表に示されているように、スクリプトの必須の部分(最初と最後の部分)は太字で表示され、スクリプトの機能部分(中間の部分)は通常の書式で表示されます。スクリプトのオプションの部分には、次に示すように、ラベル、分岐およびステップの終了が含まれる必要があります。変更されるスクリプトの項目は、斜体で表示されます。

表2-6 スクリプトの構造

スクリプト 説明
#!/usr/bin/ksh -
m_JobBegin -j JOBNAME -s START -v 2.00 m_JobBeginは必須で、少なくとも次のオプションを含む必要があります。
  • -j: 内部ジョブ名
  • -s: 実行を開始する最初のラベルの名前(通常はSTARTのはず)
  • -v: このスクリプトに必要な、バッチ・ランタイムの最小バージョン番号(上位互換)。
while true ;do 「while true; do」ループは、1つのステップから次のステップへの移行をシミュレーションする機構を提供します。
m_PhaseBegin m_PhaseBeginは、ステップの最初でパラメータを初期化できるようにします。
case ${CURRENT_LABEL} in case文は、現在のステップへの分岐を可能にします。
(START) 開始ラベル(m_JobBeginの-sオプションで使用)
JUMP_LABEL=STEP1 JUMP_LABELはすべてのステップに必須で、次のステップの名前を指定します。
;; 「;;」はステップを終了するもので、必須です。
(STEP1) 機能のステップは(LABEL)で開始されます。ここで、LABELはステップの名前です。
m_*

m_*

典型的なステップでは、バッチ・ランタイム関数に対する一連の呼び出しに続きます。
JUMP_LABEL=STEP2 次のステップへの分岐(JUMP_LABEL=)が常に存在します。
;; そして各ステップの終わりには常に「;;」があります。
(PENULTIMATESTEP) -
m_*

m_*

 機能の最後のステップは、他と同じ書式ですが、次の点のみ異なります。
JUMP_LABEL=END_JOB

;;

END_JOBを参照する必要のあるラベルのためです。「_」が必須ですが、これはこの文字がz/OS上で禁じられているためです。

(END_JOB)

break

;;

 このステップは、処理ループをブレークされるようにします。

(*)

m_RcSet ${MT_RC_ABORT:-S999} "Unknown label : ${CURRENT_LABEL}"

break

;;

esac

これは、不明なステップへの分岐をあらゆる場合に捕捉するステップです。
m_PhaseEnd done m_PhaseEndは、配置とリターン・コードに従って、ファイル管理を含むステップの終了を管理します。
m_JobEnd m_JobEndは、一時ファイルを整理して、ジョブ呼出し側に完了コードを戻すジョブの終了を管理します。

親トピック: スクリプトの作成

2.4.2 スクリプト例

リスト2-1 Kornシェル・スクリプト例 

#!/bin/ksh
#@(#)--------------------------------------------------------------
#@(#)-
m_JobBegin -j METAW01D -s START -v 2.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
#@(#)--------------------------------------------------------------

親トピック: スクリプトの作成

2.4.3 記号の定義と使用

記号は内部スクリプト変数で、スクリプト文を簡単に修正できるようにします。次のリストで示すように、m_SymbolSet関数によって値が記号に割り当てられます。記号を使用するには、次の構文を使用します: $[symbol]

ノート:

中カッコ({})のかわりに大カッコ([])を使用するのは、記号と標準のKornシェル変数を明確に区別するためです。
リスト2-2 記号の使用例
(STEP00)
m_SymbolSet VAR=40
JUMP_LABEL=STEP01
;;
(STEP01)
m_FileAssign -d SHR FILE01 ${DATA}/PJ01DDD.BT.QSAM.KBSTO0$[VAR]
m_ProgramExec BAI001

親トピック: スクリプトの作成

2.4.4 プログラムを実行するステップの作成

ステップ(フェーズとも呼ばれる)は、普通は、機能(またはテクニカル)アクティビティの実行を可能にするバッチ・ランタイム関数に対する呼出しの、一貫性の取れたセットです。

最もよく使用されるステップは、アプリケーションまたはユーティリティ・プログラムを実行するものです。これらの種類のステップは、通常、1つ以上のファイル割当て操作と、それに続く、目的のプログラムの実行で構成されます。ファイル割当て操作はすべて、次のリストに示すプログラム実行操作に先行する必要があります。

リスト2-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
;;

親トピック: スクリプトの作成

2.4.5 アプリケーション・プログラムのAbend実行

ABENDルーチン(ILBOABN0、CEE3ABD、およびART3ABD)を実行中のプログラムから呼び出して、このプログラムを強制的に中止し、abendコードをKSHスクリプトに返すことができます。たとえば、ILBOABN0は、ソースおよびバイナリのgntファイルの両方として提供されます。これはユーザー定義の任意のCOBOLプログラムから直接呼び出せます。

リスト2-4 アプリケーション・プログラムのAbend実行の例(KSH) 
(STEPPR15)
m_ProgramExec USER
JUMP_LABEL=END_JOB
;;

リスト2-5 USER.cblの例 

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.
...

親トピック: スクリプトの作成

2.4.6 プロシージャの作成

Oracle Tuxedo Application Runtime for Batchには、プロシージャを定義して、使用するために一連の関数が用意されています。これらのプロシージャは、一般に、z/OS JCLのプロシージャと同じ原則に従います。

プロシージャの利点は、次のとおりです。

  • 一連のタスクを一度作成して、複数回使用できます。
  • このタスク・セットを動的に修正できるようにします。

プロシージャには、2つのタイプがあります。

  • ストリーム内プロシージャ:呼出し側スクリプトに含まれるこの種のプロシージャは、現在のスクリプトでのみ使用できます。
  • 外部プロシージャ:別のソース・ファイル内でコーディングされているこの種のプロシージャは、複数のスクリプトで使用できます。

次の各トピックでは、前述の手順を作成する方法について説明します。

親トピック: スクリプトの作成

2.4.6.1 ストリーム内プロシージャの作成

z/OS JCL規則とは異なり、ストリーム内プロシージャは主要JOBの末尾の後に記述する必要があります。つまり、ジョブに属するすべてのストリーム内プロシージャは、関数m_JobEndの呼出しの後に出現する必要があります。

Kornシェル・スクリプトのストリーム内プロシージャは、常にまずm_ProcBegin関数を呼び出し、次にプロシージャを構成するすべてのタスクが続き、m_ProcEnd関数を呼び出して終了します。次のリストに例を示します。

リスト2-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

親トピック: プロシージャの作成

2.4.6.2 外部プロシージャの作成

外部プロシージャはm_ProcBegin関数とm_ProcEnd関数の使用を必要としません。単に次のリストに示すプロシージャの一部であるタスクをコーディングします。

プロシージャのコードと呼出しジョブの統合を簡素化するには、常に、プロシージャの先頭を次のようにします。
JUMP_LABEL=FIRSTSTEP
;;
(FIRSTSTEP)

末尾は次のようにします。

JUMP_LABEL=ENDPROC
;;
(ENDPROC)

リスト2-7 外部プロシージャの例 

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)

親トピック: プロシージャの作成

2.4.7 プロシージャの使用

Kornシェル・スクリプト内部のプロシージャの使用は、m_ProcInclude関数の呼出しを介して行われます。

「スクリプト実行フェーズ」で説明したとおり、Kornシェル・スクリプトは、変換フェーズで、m_ProcInclude関数の呼出しのたびに、プロシージャのコードをインクルードして展開されます。この操作の結果として展開されたKornシェル・スクリプトは、操作後も、「スクリプトの一般的な構造」で定義された、スクリプトの一般的な構造のルールに従っている必要があります。

次のリストに示すように前述の原則に従っていれば、ストリーム内プロシージャまたは外部プロシージャを、呼出しジョブのいかなる場所でも使用できます。

リスト2-8 m_ProcInclude関数の呼出し例
…
(STEPPR14)
m_ProcInclude BPRAP009
JUMP_LABEL=STEPPR15
…

親トピック: スクリプトの作成

2.4.8 実行時のプロシージャ変更

プロシージャ内で定義されているタスクの実行は、2つの異なる手段で変更できます。

  • 記号やパラメータの変更
  • プロシージャ内では記号を使用でき、プロシージャの呼び出し時に、これらの記号の値を指定できます。

リスト2-9 プロシージャの定義例 

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

リスト2-10 プロシージャの呼出し例 

(COPIERE)
m_ProcInclude PROCE SEQ="1"
JUMP_LABEL=COPIERF
;;

親トピック: スクリプトの作成

2.4.8.1 ファイル割当てでのオーバーライドの使用

「ベスト・プラクティス」で規定されているとおり、プロシージャをコーディングするこの方法は、主にz/OS JCL変換の結果として得られるKornシェル・スクリプトをサポートするために用意されており、ターゲット・プラットフォーム用に新しく作成されるKornシェル・スクリプトではお薦めできません。

ファイル割当てのオーバーライドは、プロシージャに存在する割当ての置換を指定するm_FileOverride関数を使用して行われます。m_FileOverride関数の呼出しは、呼出し側スクリプト内のプロシージャ呼出しに続いて行われる必要があります。

次のリストは、m_FileOverride関数を使用して論理ファイルSYSUT1の割当てを置換する方法を示しています。

リスト2-11 m_FileOverride関数の例

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

リスト2-12 m_FileOverrideプロシージャの呼出し 

(COPIERE)
m_ProcInclude PROCE SEQ="1"
m_FileOverride -i -s STEPE SYSUT1
Overriding test data
_end
JUMP_LABEL=COPIERF
;;

2.5 スクリプトの動作の制御

この項には次の情報が含まれます:

親トピック: バッチ・ランタイムの使用方法

2.5.1 ステップ実行の条件付け

この項には次の情報が含まれます:

親トピック: スクリプトの動作の制御

2.5.1.1 m_CondIf、m_CondElseおよびm_CondEndifの使用

スクリプト内で1つまたは複数のステップの実行を条件付けるために、m_CondIf、m_CondElseおよびm_CondEndif関数を使用できます。動作は、z/OS JCL文のコンストラクト、IF、THEN、ELSEおよびENDIFと類似しています

次のリストに示すように、m_CondIf関数は、常に関係式をパラメータとして持つ必要があります。この関数は、15回までネストできます。

リスト2-13 m_CondIf、m_CondElseおよびm_CondEndifの例 

…
(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
2.5.1.2 m_CondExecの使用

m_CondExec関数は、ステップの実行を条件付けるために使用されます。m_CondExecは、少なくとも1つの条件をパラメータとして持つ必要があり、同時に複数の条件を持つこともできます。複数の条件の場合、ステップは、すべての条件が満たされる場合のみ実行されます。

条件は、次の3つの形式が可能です。

  • 前のリターン・コードをテストする関係式。

    m_CondExec 4,LT,STEPEC01

  • EVEN: 前のステップが異常終了した場合でも、ステップが実行されることを示します。

    m_CondExec EVEN

  • ONLY: 前のステップが異常終了した場合にだけ、ステップが実行されることを示します。

    m_CondExec ONLY

次のリストに示すように、m_CondExec関数は、関係するステップの中で最初に呼び出される関数である必要があります。

リスト2-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

2.5.2 実行フローの制御

スクリプトの実行フローは、次の方法で、決定および制御できます。

  • m_JobBegin関数で指定された開始ラベル: このラベルは、通常、スクリプトの最初のラベルですが、ユーザーが特定のステップからスクリプトの実行を開始したい場合は、スクリプト内に存在するいかなるラベルにも変更できます。
  • 各ステップでJUMP_LABEL変数に割り当てられる値: この割当ては各ステップに必須ですが、値が必ず次のステップのラベルであるとはかぎりません。
  • m_CondExec、m_CondIf、m_CondElseおよびm_CondEndif関数の使用方法。「ステップ実行の条件付け」を参照してください
  • リターン・コードとステップの異常終了。

親トピック: スクリプトの動作の制御

2.5.3 デフォルト・エラー・メッセージの変更

バッチ・ランタイム管理者がデフォルト・メッセージを変更する場合(たとえば言語を変更する場合)、環境変数MT_DISPLAY_MESSAGE_FILEでパスが指定された構成ファイルを介して行うことができます。

このファイルは、区切り記号としてセミコロンを使用するCSVファイルです。このファイルの各レコードには、特定のメッセージが記載され、6つのフィールドで構成されます。

  1. メッセージ識別子。
  2. メッセージを表示できる関数(「*」を使用すると汎用名も可能です)。
  3. 表示のレベル。
  4. 表示先。
  5. 将来使用するために予約済
  6. 表示されるメッセージ。

親トピック: スクリプトの動作の制御

2.6 z/OSと異なる動作

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構文のみをチェックします。この文の実行時に文法エラーが検出されると、誤った文以降の文は実行されず、それより前の文は影響なく実行されます。

親トピック: バッチ・ランタイムの使用方法

2.7 ファイルの使用

この項には次の情報が含まれます:

親トピック: バッチ・ランタイムの使用方法

2.7.1 ファイル定義の作成

ファイルはm_FileBuildまたはm_FileAssign関数を使用して作成されます。

次の4つのファイル組織がサポートされます。

  • 順編成ファイル
  • 行順編成ファイル
  • 関係ファイル
  • 索引編成ファイル

作成されるファイルのファイル構成を指定する必要があります。索引編成ファイルの場合は、長さと主キーの仕様も記述する必要があります。

親トピック: ファイルの使用

2.7.1.1 m_FileBuildの例
  • ライン・シーケンシャル・ファイルの定義

    m_FileBuild -t LSEQ ${DATA}/PJ01DDD.BT.VSAM.ESDS.KBIDO004

  • レコード長が266バイトで、キーが1バイト目から始まりサイズが6バイトである索引編成ファイルの定義。

    m_FileBuild -t IDX -r 266 -k 1+6 ${DATA}/METAW00.VSAM.CUSTOMER

親トピック: ファイル定義の作成

2.7.1.2 m_FileAssignの例
  • レコード長が80バイトの新規シーケンシャル・ファイルの定義。

    m_FileAssign -d NEW -t SEQ -r 80 ${DATA}/PJ01DDD.BT.VSAM.ESDS.KBIDO005

親トピック: ファイル定義の作成

2.7.2 ファイルの割当てと使用

バッチ・ランタイムを使用する場合、バッチ・ランタイム関数(m_FileSort、m_FileRenameなど)またはプログラム(COBOLプログラムなど)でファイルを使用できます。

どちらの場合も、ファイルを使用する前に、先に割り当てる必要があります。ファイルは、次のことを行うm_FileAssign関数を使用して割り当てられます。

  • DISPモードの指定(読取りまたは書込み)
  • ファイルが世代ファイルかどうかの指定
  • ファイルの論理名(IFN)をファイルへの実際のパス(EFN)にリンクする環境変数の定義。

m_FileAssign関数を介して定義される環境変数は、DD_IFNと命名されます。この命名規則は、Micro Focus COBOLが内部ファイル名を外部ファイル名にマップするために使用する変数であるという事実に基づいています。

割当てが済んだファイルは、${DD_IFN}変数を使用することにより、ファイルを処理するバッチ・ランタイム関数のいずれかに、引数として渡すことができます。

COBOLプログラムの場合は、リンクはMicro Focus COBOLによって暗黙的に作成されます。COBOL-ITは、Micro Focus COBOLとDD割当てに関する互換性があります。

リスト2-15 ファイル割当ての例 

(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}
…

リスト2-16 COBOLプログラムによるファイル使用の例 

(STEPCBL1)
m_FileAssign -d OLD INFIL ${DATA}/PJ01DDD.BT.QSAM.KBIFI091
m_FileAssign -d MOD OUTFIL ${DATA}/PJ01DDD.BT.QSAM.KBIFO091
m_ProgramExec BIFAB090
…

親トピック: ファイルの使用

2.7.2.1 DD DISP=MODについて

ART/BatchRTを強化し、DISP=MODについてメインフレームとの一貫性を維持します。つまり、ART/BatchRTの対象の運用システムでのDISP=MODの動作をメインフレームと同様にします。現在では、BatchRTは次の2種類のCOBOLコンパイル/ランタイム環境に依存しています。

ノート:

VSAMデータ・セットについては、常にDISP=MODはDISP=OLD (ファイルが存在)およびDISP=NEW (ファイルが存在しない)として扱われます。これは、z/OSと同じです。
2.7.2.1.1 Micro Focus COBOL

Micro Focus COBOLの場合は、1つの新しいファイル・ハンドラ(ARTEXTFH.gnt)がBatchRTに追加されます。DISP=MODを正しく動作させるには、次のオプションを使用して、ユーザーCOBOLプログラムをこのファイル・ハンドラでコンパイルする必要があります。

CALLFH("ARTEXTFH")

このコンパイル・オプションを指定しない場合は、モード"open output"をCOBOLプログラムに書き込むと、既存のファイルの内容が消去されます。これは予期しない操作です。

COBOLプログラムをコンパイルする際には、このコンパイル・オプションを常に追加することをお薦めします。次の表に、DDNをサポートするAPIの動作を示します。

表2-7 Micro Focus COBOL DISP=MODの動作

API DISP=MODの許可 出力ファイルの読取りの許可 出力ファイルの書込みの結果
- INPUT OUTPUT - -
m_FileRepro はい はい 当該要件なし 追加
m_FilePrint はい はい 当該要件なし 追加
m_FileSort はい はい 当該要件なし 追加
m_ProgramExec: 他のプログラム はい はい はい 追加
m_ProgramExec: 他のプログラム はい はい はい 書き込まれますが、既存の内容が消去されます
DDNをサポートするその他すべてのAPI はい はい 当該要件なし 当該要件なし

INPUTとは入力ファイルを意味し、入力ファイルに対する読取り動作のみが発生します。DISP=MODは入力ファイルには適切ではありません。入力ファイルにデータが書き込まれることはありませんが、許可されているため、入力ファイルについてDISP=MODは常にDISP=OLDと同様に機能するからです。

出力とは出力ファイルを意味し、出力ファイルに対する読取りおよび書込み動作が発生します。出力ファイルに書き込まれるデータはすべて元のファイルに追加されます。COBOLプログラムのオープン・モード(open outputまたはopen extend)は関係ありません。

親トピック: DD DISP=MODについて

2.7.2.1.2 COBOL-IT

COBOL-ITの場合、(Micro Focus COBOLのような)DISP=MODに対するファイル・ハンドラ・レベルのサポートはありません。したがって、COBOLプログラムのコンパイルには特別な要件はありません。次の表に、DDNをサポートするAPIの動作を示します。

表2-8 Micro Focus COBOL DISP=MODの動作

API DISP=MODの許可 出力ファイルの読取りの許可 出力ファイルの書込みの結果
- INPUT OUTPUT - -
m_FileRepro いいえ はい 当該要件なし 追加
m_FilePrint いいえ はい 当該要件なし 追加
m_FileSort いいえ はい 当該要件なし 追加
m_ProgramExec: COBOLプログラム いいえ はい はい 追加
m_ProgramExec: 他のプログラム いいえ はい はい 書き込まれますが、既存の内容が消去されます
DDNをサポートするその他すべてのAPI いいえ はい 当該要件なし 当該要件なし

INPUTとは入力ファイルを意味し、入力ファイルに対する読取り動作のみが発生します。DISP=MODを入力ファイルに指定することは適切ではなく、COBOL-ITでは許可されていません。ある入力ファイルがDISP=MODとして割り当てられている場合、その内容を読み取ることはできません。

出力とは出力ファイルを意味し、出力ファイルに対する読取りおよび書込み動作が発生します。出力ファイルに書き込まれるデータはすべて元のファイルに追加されます。COBOLプログラムのオープン・モード(open outputまたはopen extend)は関係ありません。

親トピック: DD DISP=MODについて

2.7.3 同時ファイル・アクセス制御

バッチ・ランタイムには、2つのジョブで1つのファイルに同時に書込みが行われないようにするロック・メカニズムが備わっています。

同時ファイル・アクセス制御を有効にするには、次のようにします。

  1. 環境変数MT_ACC_FILEPATHを使用して、同時アクセス制御メカニズムで必要なロック・ファイル用のディレクトリを指定します。
  2. ステップ1で指定したディレクトリに、2つの空のファイル、AccLockおよびAccWaitを作成します。

    ジョブを実行する実効ユーザーに、これら2つのファイルに対する読取り/書込み権限があることを確認します。

    ノート:

    • AccLockおよびAccWaitのファイル名では、大文字と小文字が区別されます。
    • 世代ファイルにアクセスすると、世代ファイルではなくGDGがロックされます。つまり、GDGが全体としてロックされます。
    • ejr/CONF/BatchRT.confの次の2行は、コメント・アウトする必要があります。

      ${MT_ACC_FILEPATH}/AccLock

      ${MT_ACC_FILEPATH}/AccWait

親トピック: ファイルの使用

2.7.4 世代別データ・グループ(GDG)の使用

Oracle Tuxedo Application Runtime for Batchでは、世代別データ・グループ(GDG)ファイルをファイルまたはデータベース(DB)のいずれかに基づいて管理できます。ファイルベースの管理方法では、バッチ・ランタイムによりGDGファイルが別々の*.gensファイルで管理され、1つの*.gensが1つのGDGファイルに対応します。DBベースの管理方法では、ART for BatchによりユーザーはGDG情報をOracleデータベースまたはDB2データベースで管理できます。

親トピック: ファイルの使用

2.7.4.1 GDG管理機能
UNIX標準ではないz/OSメインフレーム上に存在する世代ファイルの概念をエミュレートするために、バッチ・ランタイムには、この種のファイルを管理するための一連の関数が用意されています。これらの関数は、ファイルベースの管理とDBベースの管理の両方で使用できます。

ノート:

GDGのコピーや名称変更はサポートされません。
2.7.4.1.1 GDGの定義または再定義

GDGは使用する前に定義する必要があります。

GDGファイルは、m_GenDefine関数を介して定義または再定義されます。GDGの定義または再定義の操作は即時にコミットされ、ロールバックできません。

次のリストに示すように、1行目ではGDGを定義し、その最大世代数を15に設定します。2行目では同じGDGの最大世代数を30に再定義します。3行目では-sオプションを指定せずにGDGを定義します(その最大世代数は9999に設定されます)。4行目ではGDGを暗黙的に定義し、その最大世代数を9999に設定します。5行目ではGDGユース・モデル・ファイル$DATA/FILEを定義します。このファイルは、GDGファイルまたは通常のファイルです。

リスト2-17 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

親トピック: GDG管理機能

2.7.4.1.2 GDGへの世代ファイルの追加

新しい世代ファイル(GDS)をGDGに追加するには、-d NEW/MOD,…および-g +nというパラメータを指定してm_FileAssignを呼び出します。GDSファイル・タイプは、LSEQまたはSEQのみです。

GDGに世代ファイルを追加する場合、次の4つの点に注意してください。

  • 複数の世代ファイル(GDS)を、1つのジョブまたはステップに不連続および不規則に追加できます。例については、リスト2‑18を参照してください。
  • 1つの世代番号(GenNum)は、ジョブに1回のみ追加できます。リスト2-19は、間違った使用方法を示しています。
  • 新規作成されるGDSのファイル名は、m_FileAssignで指定される世代番号を使用して、<current GDS number> + <GenNum>の形式で生成されます。例については、リスト2‑20を参照してください。
  • ジョブ内で複数の世代ファイル(GDS)が新規作成される場合、ジョブの終了後、最大RGNのGDSが最新のGDSになります。例については、リスト2‑21を参照してください。

次の4つの例は、この重要な点を個々に表しています。

リスト2-18 複数の世代ファイルを不連続および不規則に追加する例

(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"

前述の例では、次のGDSファイルがGDGに追加されます。

$DATA/GDG1.Gen.0001

$DATA/GDG1.Gen.0002

$DATA/GDG1.Gen.0005

$DATA/GDG1.Gen.0009

リスト2-19 1つの世代番号を1つのジョブに複数回追加する例(間違った使用方法) 

(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回追加されるという間違った使用方法を示しています。

リスト2-20 GDSファイル名をリストする例 

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.Gen.0001

$DATA/GDG1.Gen.0002

$DATA/GDG1.Gen.0004

前述のジョブの実行後、$DATA/GDG1には1、2、4、5、9という番号の5つのGDSが含まれます。対応するGDSファイルが次のようにリストされます。

$DATA/GDG1.Gen.0001

$DATA/GDG1.Gen.0002

$DATA/GDG1.Gen.0004

$DATA/GDG1.Gen.0005

$DATA/GDG1.Gen.0009

リスト2-21 最新の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管理機能

2.7.4.1.3 GDG内の既存の世代ファイルの参照

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のマッピングは次のとおりです。

GN 1 4 6 7 9 10
RGN -5 -4 -3 -2 -1 0

次のジョブでは、RGN=-1を使用してGNが9に等しいGDSを参照し、RGN=-4を使用してGNが4に等しいGDSを参照します。

リスト2-22 既存の世代ファイルを参照する例 

(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のマッピングは次のとおりです。

GN 1 4 6 7 9 10
RGN -5 -4 -3 -2 -1 0

次のジョブでは、RGN=-1を使用してGNが9に等しいGDSを参照し、RGN=-4を使用してGNが4に等しいGDSを参照します。

次のようにジョブを実行できます。

リスト2-23 DELETEを指定して既存の世代ファイルを参照する例 

(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のマッピングは次のようになります。

GN 1 6 7 10
RGN -3 -2 -1 0

STEP2では、SYSUT1でポイントされるGDS (GNが7であるGDS)およびSYSUT2でポイントされるGDS (GNが6であるGDS)が削除されます。

STEP2が終了すると、GNとRGNのマッピングは次のようになります。

GN 1 10
RGN -1 0

親トピック: GDG管理機能

2.7.4.1.4 GDG内の世代ファイルの削除

ART for Batchでは、新しく追加された生成ファイルまたは現在の既存の生成ファイルを、m_FileAssignで指定するDDの配置によって削除できます。

  • 新しく追加されたGDSの削除(例は、リスト2-24を参照)
  • 既存のGDSの削除(例は、リスト2-25を参照)

リスト2-24 新しく追加されたGDSの削除 

(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"

前述の例では、最終的に、GDG1にGDSは追加されません。

リスト2-25 既存のGDSの削除 

(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個です。

親トピック: GDG管理機能

2.7.4.1.5 GDGの削除

次のリストに示すように、GDGベース名を指定してm_FileDeleteを呼び出すことで、GDG全体を削除できます。この方法で、すべてのGDGのGDSが適切に削除されます。GDGの削除の操作は即時にコミットされ、ロールバックできません。

リスト2-26 GDGの削除

m_FileDelete ${DATA}/PJ01DDD.BT.GDG

親トピック: GDG管理機能

2.7.4.1.6 GDGのカタログ化

GDGベースのみをカタログ化できます。そのGDSを個別にカタログ化することはできません。

ART for Batchのファイル・カタログ化関数を有効にしてGDGをカタログ化する必要があります。また、カタログ・モードでは、m_FileAssignに指定されるパラメータ[-v volume]は無視されます。

ノート:

GDGは、定義されるとカタログ化されます。

親トピック: GDG管理機能

2.7.4.1.7 GDGのコミット

現在のステップで変更されるすべてのGDGは、現在のステップが正常終了するかどうかにかかわらずコミットされます。

GDGのコミットにより、Oracle DataBaseやファイル(*.gens)といったGDG管理システムの情報が更新され、一時的な世代ファイルがコミットされます。ただし、GDGのコミットによってGNとRGNのマッピング関係に変更はありません。つまり、ジョブの1つのステップの中で、RGNは常に同じGDSを参照します。

たとえば、GDG1には1、4、6、7、9、10という番号の6つのGDSがそれぞれ含まれています。

リスト2-27 GDGをコミットする例 

(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を参照します。

GN 1 4 6 7 9 10 11 12
RGN -5 -4 -3 -2 -1 0 1 2

STEP2で、GDG管理システムのGNとRGNのマッピングは次のようになります。

GN 1 4 6 7 9 10 11 12
RGN -7 -6 -5 -4 -3 -2 -1 0

しかし、現在実行中のジョブにおけるGNとRGNのマッピングは変更されません。次の例では、SYSUT4は、GNが11であるGDSではなく、GNが9であるGDSを引き続き参照します。

GN 1 4 6 7 9 10 11 12
RGN -5 -4 -3 -2 -1 0 1 2

親トピック: GDG管理機能

2.7.4.2 ファイルベースの管理

この項には次の情報が含まれます:

2.7.4.2.1 構成

MT_GENERATION変数には、GDGファイルの管理方法を指定します。*.gensファイルでGDGを管理するには、値をGENERATION_FILEに設定する必要があります。

2.7.4.2.2 同時実効性制御および認可

ファイルベースのGDG管理メカニズムでは、1つのGDGファイルに常にアクセスできるのは1つのジョブのみで、1つのGDGに同時に複数のジョブでアクセスすることはできません。GDGファイルにアクセスするには、既存の内部関数mi_FileConcurrentAccessReservationによりファイル・ロックを取得する必要があります。ファイルベースのGDG管理メカニズムでは、同時実効性および認可の制御に*.gensファイル(*はGDGのベース名)を使用します。ユーザー・アクセスのチェックは、*.gensファイルにアクセスできるかできないかによって行われます。

2.7.4.3 DBベースの管理
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データベースにアクセスするための有効なデータベース接続文字列に設定する必要があります。
2.7.4.3.1 データベース表

次の表では、バッチ・ランタイムによって管理されるGDGごとの一般的な定義を示しています。この表では、各行が1つのGDGを表しています。すべてのGDGファイルでは、1つのGDG_DETAIL表が共有されています。

表2-9 GDG_DEFINE

名前 タイプ 説明
GDG_BASE_NAME VARCHAR(1024) GDGのフルパス名。

1つのリポジトリに対する相対パスを1つでも含めることはできません。

GDG_BASE_NAMEの長さは1024までで、これは異なるUNIXプラットフォームでの最低のPATH_MAXです。
GDG_MAX_GEN INT 世代ファイルの最大数。

-sオプションで指定した上限の世代が含まれます。-sオプションは1-9999の範囲で設定できます。

GDG_CUR_GEN INT GDGの現在の世代番号
主キー: GDG_BASE_NAME

次の表では、すべてのGDG世代ファイルの詳細な情報を示しています。この表では、各行がGDGの1つの世代ファイルを表しています。

表2-10 GDG_DETAIL

名前 タイプ 説明
GDG_BASE_NAME VARCHAR(1024) GDGプリンシパル名のフルパス。
GDG_REL_NUM INT 世代ファイルの相対世代番号。
GDG_ABS_NUM INT 世代ファイルの絶対世代番号。
GDG_JOB_ID VARCHAR(8) ファイルを作成するジョブのID。
GDG_JOB_NAME VARCHAR(32) ファイルを作成するジョブの名前。
GDG_STEP_NAME VARCHAR(32) ファイルを作成するステップの名前。
GDG_CRE_TIME TIMESTAMP ファイル作成時のタイムスタンプ。
主キー: GDG_BASE_NAME+GDG_ABS_NUM

GDG_FILE_NAME (物理世代ファイル名)は、GDG_DEFINEのGDG_BASE_NAMEからとGDG_DETAILのGDG_ABS_NUMから構成される可能性があるため、表GDG_DETAILには格納されません。

ノート:

GDG情報をバックアップするには、GDG_DEFINEおよびGDG_DETAILの2つのデータベース表をバックアップする必要があります。

親トピック: DBベースの管理

2.7.4.3.2 世代ファイルのネーミング・ルール
次の表に、世代ファイル名のルールを示します。

表2-11 世代ファイルのネーミング・ルール

条件 ファイル名 説明
GDG_REL_NUM > 0 ${GDG_BASE_NAME}.Gen.${GDG_ABS_NUM}.tmp 未コミット
GDG_REL_NUM <= 0 ${GDG_BASE_NAME}.Gen.${GDG_ABS_NUM} コミット済

親トピック: DBベースの管理

2.7.4.3.3 構成変数

MT_GENERATION

この変数には、GDGファイルの管理方法を指定します。データベースでGDGファイルを管理するには、値をGENERATION_FILE_DBに設定し、MT_GDG_DB_ACCESSを適切に構成する必要があります。

MT_GDG_DB_ACCESS

この変数は、GENERATION_FILE_DBに設定されている場合、MT_GENERATIONとともに使用され、有効なデータベース・ログイン・アカウントで設定する必要があります。Oracleデータベースにアクセスするには、たとえばscott/password@orclのように、userid/password@sidの書式で指定する必要があります。

MT_GDG_DB_BUNCH_OPERATION

GENERATION_FILE_DBに設定されている場合は、MT_GENERATIONとともに使用します。これは、コミット・フェーズでデータベースにGDG変更をコミットする方法を示します。"Y"に設定されている場合、GDGの変更は1回のデータベース・アクセスでコミットされます。"N"に設定されている場合、GDGの変更は、1回または複数のデータベース・アクセスを使ってコミットされます。

親トピック: DBベースの管理

2.7.4.3.4 外部シェル・スクリプト

2つの外部シェル・スクリプトを使用すれば、新規のデータベース表を自動的に作成および削除できます。

CreateTableGDG.sh

説明

データベースに表GDG_DEFINEおよびGDG_DETAILを作成します。

使用方法

CreateTableGDG.sh <DB_LOGIN_PARAMETER>

サンプル

CreateTableGDG.sh scott/password@orcl

DropTableGDG.sh

説明

データベースから表GDG_DEFINEおよびGDG_DETAILを削除します。

使用方法

DropTableGDG.sh <DB_LOGIN_ PARAMETER>

サンプル

DropTableGDG.sh scott/password@orcl

親トピック: DBベースの管理

2.7.4.3.5 同時実効性制御および認可

DBベースのGDG管理メカニズムでは、同時実効性制御動作はファイルベースのGDG管理メカニズムと同じですが、*.ACS (*はGDGベース名)ファイルの書式は異なります。GDGに対応する行にアクセスするジョブでは、まずGDGのファイル・ロックを取得する必要があるため、DBベースのGDG管理メカニズムでは、「データベース表」で述べた表をロックする必要はありません。つまり、データベースのアクセス・レベルでは、同時実行性制御を実行する必要はありません。対応する*.ACSファイルへのアクセス権限(読取りまたは書込み)がない場合、データベースにはアクセスできません。GDGファイルを変更する必要がある場合、世代ファイルおよび世代ファイルを保持するディレクトリへの書込み権限が必要であり、MT_GDG_DB_ACCESSは、「データベース表」に記載されている表への適切な権限を持つように正しく構成する必要があります。

DBベースのGDG管理の記述全体をコピーし、ファイル名を置換するしかありません。

親トピック: DBベースの管理

2.7.4.3.6 例外処理

DBベースのGDG管理メカニズムには4種類の情報があります。

  • GDG_DEFINE
  • *.ACSファイル
  • GDG_DETAIL
  • ディスク上の物理ファイル

これらの情報は、GDGファイル用に一貫して保持する必要があります。バッチ・ランタイムでは、ジョブで初めてGDGファイルにアクセスする際に、GDG_DEFINEから物理ファイルへの一貫性をチェックします。例外が発生し、これらの情報の一貫性がなくなった場合、バッチ・ランタイムにより現在のジョブが終了され、エラーが報告されます。

この動作は、一貫性のチェックはせず、プロセスで発生した例外の報告のみをする既存のファイルベースのメカニズムと異なります。

親トピック: DBベースの管理

2.7.4.4 Data Control Block (DCB)のサポート

ファイル・ベースのGDGとDBベースのGDGの両方がData Control Block (DCB)をサポートします。

2.7.4.4.1 .dcbファイルの定義

.dcbファイルは、"-t <file type>"および"-r <record length>"の2つの値をとります。

-t <file type>

最初の世代ファイルを作成するには、m_FileAssignで-t <file type>にLSEQまたはSEQのどちらかを指定する必要があります。job kshファイルにファイル・タイプを指定しなかった場合は、デフォルトでLSEQが使用されます。

-r <record length>

SEQファイルの場合、この値は必須で、数値を1つ、または"number1-number2"の形式で指定する必要があります。

LSEQファイルの場合、この値はオプションです。設定する場合、この値には数値を1つ、または"number1-number2"の形式で指定する必要があります。

ノート:

m_FileAssignではなくm_GenDefineを使用してGDGを作成する場合、.dcbファイルは、m_FileAssign -g +1を使用して世代ファイルが作成されるまで存在しません。

.dcbファイルがいったん作成されると、m_FileAssignによって最初の世代ファイルが再作成されないかぎり、そのコンテンツはその後実行されるm_FileAssign文によって変更されることはありません。

2.7.4.4.2 .dcbファイルの作成
最初の世代ファイルをm_FileAssign -g +1で作成するときに、GDGデータ・セット用の.dcbファイルを作成します。

ノート:

m_FileAssignではなくm_GenDefineを使用してGDGを作成する場合、.dcbファイルは、m_FileAssign -g +1を使用して世代ファイルが作成されるまで存在しません。

.dcbファイルがいったん作成されると、m_FileAssignによって最初の世代ファイルが再作成されないかぎり、そのコンテンツはその後実行されるm_FileAssign文によって変更されることはありません。

2.7.4.4.3 .dcbファイルの削除

GDGをm_FileDeleteで削除すると、対応する.dcbファイルが自動的に削除されます。

ただし、GDG内のすべての世代ファイルが削除されてもGDG自体が存在する場合、.dcbファイルは削除されません。

2.7.5 ストリーム内ファイルの使用

データがKornシェル・スクリプトに直接書き込まれるファイルを定義して使用するには、-iパラメータを指定してm_FileAssign 関数を使用します。デフォルトでは、文字列_endは次のリストで示されるようにストリーム内フローの「最終」デリミタです。

リスト2-28 ストリーム内データの例

(STEP1)
m_FileAssign -i INFIL
data record 1
data record 2
…
_end

親トピック: ファイルの使用

2.7.6 一連の連結ファイルの使用

一連のファイルを連結入力として使用するには、下のリスト2-29に示すように-Cパラメータを指定してm_FileAssign関数を使用します(z/Os JCLでは、最初の1つだけがラベルを含むDDカードとしてコーディングされていました)。

リスト2-29 連結された一連のファイルの使用例

(STEPDD02)
m_FileAssign -d SHR INF ${DATA}/PJ01DDD.BT.QSAM.KBDDI002
m_FileAssign -d SHR -C ${DATA}/PJ01DDD.BT.QSAM.KBDDI001
m_ProgramExec BDDAB001

親トピック: ファイルの使用

2.7.7 外部sysinの使用

実行するコマンドを含む外部sysinファイルを使用するには、m_UtilityExec関数を使用します。
m_FileAssign -d OLD SYSIN ${SYSIN}/SYSIN/MUEX07
m_UtilityExec

親トピック: ファイルの使用

2.7.8 ファイルの削除

ファイル(世代ファイルを含む)は、m_FileDelete関数を使用して削除できます。

m_FileDelete ${DATA}/PJ01DDD.BT.QSAM.KBSTO045

親トピック: ファイルの使用

2.7.9 RDBファイル

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ファイルが存在するかどうかをテストして、ファイルが表に変換されたことを確認します。関係するファイルのいずれかが表に変換された場合、関数は必要な中間操作(表をファイルにアンロードして再ロードするなど)を実行し、その後で最終的なアクションを実行します。

この管理の全ては、エンド・ユーザーに対して透過的です。

親トピック: ファイルの使用

2.7.10 RDBMS接続の使用

RDBMSに接続する必要があるアプリケーション・プログラムを実行する場合、m_ProgramExec関数を呼び出すときに-bオプションを使用する必要があります。

接続と切断(およびコミットとロールバック操作)は、バッチ・ランタイムによって暗黙的に処理され、次の2つの方法を使用して定義できます。

  • TuxJESシステムを起動する前に環境変数MT_DB_LOGINを設定します。

    ノート:

    この場合、すべての実行中のジョブがこの変数を使用します。
  • TuxJESセキュリティ構成ファイル内の値をそれぞれのユーザーごとに設定します。
MT_DB_LOGINの値は、dbuser/dbpasswd[@ssid] または「/」という形式でなければなりません。

ノート:

RDBMSが、データベース接続ユーザーに対してUNIX認証を使用でき、RDBMS認証を使用できないように構成されている場合は「/」を使用する必要があります。

実行プログラムが$PATHに存在することを確認してください。

「/」を使用するべきかどうかは、データベース管理者に確認してください。

次のリストに示すように、実行される主プログラムはRDBMSを直接使用しないが、その後に続くサブプログラムのいずれかが使用する場合は、-bオプションも使用する必要があります。

リスト2-30 RDBMS接続の例 
(STEPDD02)
m_FileAssign -d MOD OUTF ${DATA}/PJ01DDD.BT.QSAM.REPO001
m_ProgramExec -b DBREP001

m_ProgramExec関数が送信する可能性のあるファイルは次の3種類です。

  • COBOLソース・コード・ファイルからコンパイルされた生成済みコード・ファイル(拡張子が.gntのファイル)。

    .gntファイルが$COBPATH (Micro Focus COBOLの場合)、または$COB_LIBRARY_PATH (COBOL-ITの場合)にあることを確認してください。

  • Cソース・コード・ファイルからコンパイルされた呼び出し可能な共有ライブラリ(拡張子が.soのファイル)。

    呼び出し可能な共有ライブラリ・ファイルが$COBPATH (Micro Focus COBOLの場合)、または$COB_LIBRARY_PATH (COBOL-ITの場合)、もしくはシステム・ライブラリのファイル検索パス(LIBPATH、LD_LIBRARY_PATHなど)に存在することを確認してください。

    このタイプのファイルには、ファイル名と同じ名前を持つエントリ関数が必要です。

    たとえば、呼出し可能な共有ライブラリ・ファイルProgA.soには、次のいずれかで宣言された関数が含まれていなければなりません。

    • ProgA(short* arglen, char* argstr): パラメータが必要である場合
    • ProgA(): パラメータが必要ない場合
  • その他の種類の実行可能プログラム(システム・ユーティリティ、シェル・スクリプト、サード・パーティ・ユーティリティなど)

    m_ProgramExecは、COBOLプログラム(.gnt)、呼出し可能な共有ライブラリ内のCプログラム(.so)、その他の実行可能プログラムの順にプログラムの成果物の種類を決定します。COBOLプログラムが実行されると、m_ProgramExecは同じ名前を持つ別のプログラムを実行しません。たとえば、ProgA.gntの実行後、ProgA.soなど、ProgAという名前のプログラムは実行されません。

.gntファイルと.soファイルについては、m_ProgramExecはrunbプログラムを起動して、実行します。ARTは、次のようなrunbを提供します。

  • $JESDIR/ejr_mf_ora : Micro Focus COBOLとOracleデータベースの組合せで使用
  • $JESDIR/ejr_mf_db2: Micro Focus COBOLとDB2データベースの組合せで使用
  • $JESDIR/ejr_cit_ora: COBOL-ITとOracleデータベースの組合せで使用
  • $JESDIR/ejr_cit_db2: COBOL-ITとDB2データベースの組合せで使用

前述の4種類の組合せを使用していない場合は、$JESDIR/ejrにアクセスして、make.shを実行し、自分専用のrunbを生成してください。

runbプログラムは、データベース・ライブラリを使用してコンパイルされたランタイムで、runbatchプログラムを実行します。

runbatchプログラムには次の役割があります。

- データベースへの接続の実行(必要に応じて)

- ユーザー・プログラムの実行

- コミットまたはロールバックの実行(必要に応じて)

- データベースへの接続切断の実行(必要に応じて)

親トピック: ファイルの使用

2.8 INTRDRファシリティを使用したジョブの発行

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プログラムにリンクする必要があります。

  • Micro Focus COBOLでは、次のコンパイル・オプションを追加します。

    CALLFH("ARTEXTFH")

  • COBOL-ITでは、次のコンパイル・オプションを追加します。

    flat-extfh=ARTEXTFH

    flat-extfh-lib="<fullpath of ARTEXTFH.gnt>"

    ARTEXTFH.gntは、"${MT_ROOT}/COBOL_IT/ARTEXTFH.gnt"に保存されます。

この機能が有効化されていない場合、INTRDRジョブは、現在のステップが終了した後で送信されます。

ノート:

ランタイムで生成されるバッチ・ジョブ・スクリプトがJCL言語で記述されている場合、INTRDRで送信することができません。

親トピック: バッチ・ランタイムの使用方法

2.9 EJRを使用したジョブの送信

バッチ・ランタイムを使用する場合は、TuxJESを使用してジョブを起動できます(「Tuxedo Job Enqueueing Service (TuxJES)の使用」のドキュメントを参照)が、EJRスポーナを使用してジョブを直接実行することもできます。

この種の実行を行う前に、全体のコンテキストが正しく設定されていることを確認します。これには、バッチ・ランタイムが必要とする環境変数やディレクトリも含まれます。

EJRを使用してジョブを起動する例

# EJR DEFVCUST.ksh

EJRスポーナの完全な説明は、『Oracle Tuxedo Application Runtime for Batchリファレンス・ガイド』を参照してください。

親トピック: バッチ・ランタイムの使用方法

2.10 ユーザー定義のエントリ/終了

バッチ・ランタイムを使用すれば、パブリック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が呼び出された場合は、グローバル変数が設定され、現在のジョブを終了できます。

親トピック: バッチ・ランタイムの使用方法

2.10.1 構成

関数と同じ名前の1つのファイルに1つの関数のみを含める必要があります。たとえば、m_*_Beginやm_*_Endなどです。さらに、このようなファイルはすべてejr/USER_EXITの下に配置する必要があります。

バッチ・ランタイムで提供されているmi_接頭辞の関数には、カスタム・エントリ/終了関数は指定できません。

親トピック: ユーザー定義のエントリ/終了

2.11 バッチ・ランタイムのロギング

この項には次の情報が含まれます:

親トピック: バッチ・ランタイムの使用方法

2.11.1 概要

この項には次の情報が含まれます:

親トピック: バッチ・ランタイムのロギング

2.11.1.1 ログ・メッセージの形式

CONF/Messages.confで定義されている各ログ・メッセージは、「COBOL-IT」のトピックの表2-8に示すように、6つのフィールドで構成されます

表2-12 ログ・メッセージの形式

フィールド コンテンツ
1 メッセージ識別子
2 メッセージを表示できる関数(*を使用する汎用名)
3 表示のレベル。デフォルト値: 4
4 表示の宛先(u、e、o)。
  • U: ユーザー出力
  • E: エラー出力(stderr)
  • O: 標準出力(stdout)
5 ヘッダー・フラグ(0、1、b)。デフォルト値: 0
  • 0: ヘッダーは表示されません。
  • 1: ハードコード・ヘッダー形式が表示されます。
  • b: 例外メッセージFatal/Error/Warningに特有
6 考えられる動的な値とともに表示されるメッセージ

これらのメッセージのレベルは、デフォルトでは4に設定されています。

ジョブ・ログにあるこれら3つのメッセージを印刷するかどうかを制御するために、バッチ・ランタイムのメッセージ・レベルを指定できます。

親トピック: 概要

2.11.1.2 ログ・メッセージのレベル

表2-13 ログ・メッセージのレベル

レベル メッセージ
1 FATALのみ
2 以前のレベルとエラー
3 以前のレベルと情報
4 以前のレベルとファイル情報ログ
5 以前のレベルと高レベルの関数
6 以前のレベルとテクニカル関数
7 レベル3と、-d regexpオプションに対応する高レベル関数と同じ
8 7と、-d regexpオプションに対応するテクニカル・レベル関数と同じ
9 予約済

親トピック: 概要

2.11.1.3 ログ・レベルの制御

ジョブ・ログでメッセージを表示するデフォルトのレベルは3です。レベルの変更には、次の方法のいずれかを選択することもできます。

  • EJRの-Vオプションの使用
  • 環境変数MT_DISPLAY_LEVELの使用

EJRで設定された表示レベルにより、MT_DISPLAY_LEVELで設定されたレベルをオーバーライドできます。

親トピック: 概要

2.11.1.4 ログ・ファイルの構造

バッチ・ランタイムは、起動された各ジョブに対して、実行された各ステップの情報を含むログ・ファイルを作成します。このログ・ファイルには、次のリストで示されているような構造体が含まれます。

リスト2-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})
Or
JOB ENDED ABNORMALLY WITH CODE (S990})

TuxJesを使用しない場合、ログ・ファイルは、<Job name>_<TimeStamp>_<Job id>.logという名前で${MT_LOG}ディレクトリ配下に作成されます。

詳細は、「Tuxedo Job Enqueueing Service (TuxJES)の使用」を参照してください。

親トピック: 概要

2.11.2 ログ・ヘッダー

バッチ・ランタイムのロギング機能では、各ログ行の前に情報提供のログ・ヘッダーが次の書式で示されます。

YYYYmmdd:HH:MM:SS:TuxSiteID:JobID:JobName:JobStepName

ログ・ヘッダーの書式は構成できますが、既存の特定のメッセージ・ヘッダー、タイプ0、1およびbの構成や動作に影響を与えないようにしてください。

次の表では、汎用ログ・ヘッダーの指定に使用できる変数を示しています。

表2-14 汎用ログ・ヘッダーを指定するための変数

変数 説明
MTI_SITE_ID ジョブがTuxJESから発行された場合は、TuxJESによってマシン用に構成された論理マシンIDで、それ以外の場合は空です。
MTI_JOB_ID ジョブがTuxJESから発行された場合は、JESによって割り当てられたジョブID。
MTI_JOB_NAME ジョブ・スクリプトでm_JobBeginによって割り当てられたジョブの名前。
MTI_STEP_NAME 現在実行中のジョブのステップの名前。
MTI_SCRIPT_NAME ジョブ・スクリプトの名前。
MTI_PROC_NAME m_ProcIncludeによってプロセスから含められたコードが実行中の場合、そのプロセスの名前。

親トピック: バッチ・ランタイムのロギング

2.11.2.1 構成

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}\"

この変数を構成するには、次のルールに従う必要があります。

  • MT_LOG_HEADERは、evalに対して有効なシェル・ステートメントであることが必要で、一重引用符で囲む必要があります。
  • MT_LOG_HEADERで使用される変数はすべて、${}で囲む必要があります。例:

    ${ MTI_JOB_STEP }

  • MT_LOG_HEADERで使用されるコマンド行はすべて、$()で囲む必要があります。たとえば、$(date '+%Y%m%d:%H%M%S')のようになります。

前述の例は、書式の必要に応じて、「データベース表」のトピックの表2-10に示した変数のみを使用して変更できます。

この構成変数は、デフォルトではコメント化されるため、この機能を有効にするには、非コメント化する必要があります。

親トピック: ログ・ヘッダー

2.11.3 ファイル情報のロギング

ロギング・システムでは、ジョブ・ログの詳細なファイル情報の他、ファイルがDDに割り当てられるときや、解除されるときの情報も記録できます。

ファイル割当て情報は、次の関数で記録されます。

m_FileAssign

ファイル・リリース情報は、次の関数で記録されます。

m_PhaseEnd

ファイル情報は、次の関数で記録されます。

  • m_FileBuild
  • m_FileClrData
  • m_FileConcatenate
  • m_FileCopy
  • m_FileDelete
  • m_FileEmpty
  • m_FileExist
  • m_FileLoad
  • m_FileRename
  • m_FilePrint
  • m_FileRepro

次のトピックでは、詳細なファイル情報を記録するために必要な構成について説明します。

親トピック: バッチ・ランタイムのロギング

2.11.3.1 構成

この項には、次のファイルが含まれています。

2.11.3.1.1 Messages.conf

次のメッセージ識別子は、ファイル割当ておよびファイル情報ログ・メッセージの形式の書込みでのmi_DisplayFormatの使用をサポートするために、CONF/Messages.confで定義されています。

  • FileAssign;m_FileAssign;4;ueo;0;%s
  • FileRelease;m_PhaseEnd;4;ueo;0;%s
  • FileInfo;m_File*;4;ueo;0;%s

    ノート:

    CONF/Messages.confは構成できません。このファイルは編集しないでください。

    各識別子の最後の文字列%sは、それがログ・ファイルに書き込まれることを表します。その値は、CONF/Batch.confで定義されている次の変数を使用して構成できます。詳細は、「ログ・メッセージの形式」のトピックの表2-12を参照してください

    • MT_LOG_FILE_ASSIGN (FileAssignの場合)
    • MT_LOG_FILE_RELEASE (FileReleaseの場合)
    • MT_LOG_FILE_INFO (FileInfoの場合)

親トピック: 構成

2.11.3.1.2 BatchRT.conf

詳細なファイル情報の書式を決定するには、3つの構成変数をCONF/BatchRT.confで定義する必要があります。「世代ファイルのネーミング・ルール」の表2-11に示されているプレースホルダを使用すれば、ファイル・ログ情報をより柔軟に構成できます。

表2-15 プレースホルダ

プレースホルダ 説明 値とサンプル
<%DDNAME%> 操作中のファイルの名前 SYSOUT1
<%FULLPATH%> 操作中のファイルのフルパス /local/simpjob/work/TEST001.Gen.000000001
<%FILEDISP%> 操作中のファイルのDISP SHRまたはNEW

表2-16 CONF/BatchRT.confの構成変数

名前 値とサンプル 使用可能なプレースホルダ
MT_LOG_FILE_ASSIGN FileAssign: DDNAME=(<%DDNAME%>); FILEINFO=($(ls -l --time-style=+'%Y/%m/%d %H:%M:%S' --no-group <%FULLPATH%>)';FILEDISP=(<%FILEDISP%>)

<%DDNAME%>

<%FULLPATH%>

<%FILEDISP%>

MT_LOG_FILE_RELEASE FileRelease: DDNAME=(<%DDNAME%>); FILEINFO=($(ls -l --time-style=+'%Y/%m/%d %H:%M:%S' --no-group <%FULLPATH%>)';FILEDISP=(<%FILEDISP%>) <%DDNAME%>

<%FULLPATH%>

<%FILEDISP%>

MT_LOG_FILE_INFO FILEINFO=($(ls -l --time-style=+'%Y/%m/%d %H:%M:%S' --no-group <%FULLPATH%>))leCopy source、FileCopy Destination、FileDeleteなど。 <%FULLPATH%>

これらの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メッセージはジョブ・ログで表示されませんが、ジョブの実行には影響がありません。

ノート:

これらの変数は書式上の必要に応じてカスタマイズできますが、コマンドが有効であることを確認しないと、ファイル情報は記録されません。

親トピック: 構成

2.12 ジョブ・スケジューラでのバッチ・ランタイムの使用

一部の関数(m_JobBegin、m_JobEnd、m_PhaseBegin、m_PhaseEnd)には、選択されたジョブ・スケジューラとの関係で行われる特定のアクションを挿入するためのエントリ・ポイントが用意されています。

親トピック: バッチ・ランタイムの使用方法

2.13 SQLリクエストの実行

SQLリクエストは、m_ExecSQL関数を使用して実行できます。

ターゲット・データベースに従い、この関数はORACLEデータベースでは「sqlplus」コマンドを実行し、UDBでは「db2 -tsx」コマンドを実行します。

ノート:

環境変数MT_DB_LOGINを設定する必要があります(データベース接続ユーザー・ログイン)。

SYSINファイルにはSQLリクエストを含める必要があり、ユーザーはデータベース・ターゲットに関するコンテンツを検証する必要があります。

親トピック: バッチ・ランタイムの使用方法

2.14 COBOL-IT / BDBにおけるSimple Application

COBOL ITによってコンパイルされたBatch COBOLプログラムは、ART Workbenchを使用してMainframe VSAMファイルから変換される索引編成ISAMファイルにアクセスできます。VSAMファイルは、COBOL-ITを使用してBDBに格納できます。

この機能をバッチ・ランタイムで有効にするには、ランタイム中に次を実行してください。

  • bdb:yesを指定して、COBOLプログラムをCOBOL-ITコンパイラでコンパイルします。
  • BDBで必要なため、DB_HOMEを正しく設定します。DB_HOMEは、BDBによって一時ファイルが配置される場所を指します。
  • ART for Batchがジョブを起動する前に、次の環境変数を設定します。
    • export COB_EXTFH_INDEXED=BDBEXTFH
    • export COB_EXTFH_LIB=/path_to_Cobol-IT/lib/libbdbextfh.so (例: export COB_EXTFH_LIB=/opt/cobol-it-64/lib/libbdbextfh.so)
  • TuxJESシステムを起動する前に環境変数COB_ENABLE_XAを設定解除します。

    unset COB_ENABLE_XA

    ノート:

    COBOL-ITをART CICS Runtimeとともに使用する場合、COB_ENABLE_XAを設定する必要があります。

親トピック: バッチ・ランタイムの使用方法

2.15 ネイティブJCLジョブの実行

この項には次の情報が含まれます:

親トピック: バッチ・ランタイムの使用方法

2.15.1 概要

Oracle Tuxedo ART Batch Runtimeでは、ネイティブのJCLジョブをART Workbenchによる事前変換なしで管理することをサポートしています。

親トピック: ネイティブJCLジョブの実行

2.15.2 構成

ジョブを管理するには、データベースを使用してTuxJESを設定する必要があります。詳細は、「Oracle TuxedoアプリケーションとしてのTuxJESの設定(データベースを使用)」を参照してください。

次の設定項目をjesconfigファイルに追加する必要があります。JOBLANG=JCL。

ネイティブJCLの実行では、「環境変数を設定する」で説明されているすべての環境変数も使用できます。

親トピック: ネイティブJCLジョブの実行

2.15.3 JESクライアントを使用したJCLジョブの管理

使用方法はKSHジョブと同じです。

親トピック: ネイティブJCLジョブの実行

2.15.3.1 JCLジョブの送信

オプション-Iを次のように使用して、JCLジョブを送信できます。

  • artjesadmin -I JCLScriptName (シェル・コマンド行の場合)
  • submitjob -I JCLScriptName (artjesadminコンソールの場合)

また、ジョブを送信する場合は、envファイルを次のように指定できます。:

  • artjesadmin -o "-e <envfile_path>" -I JCLScriptName
  • submitjob -o "-e <envfile_path>" -I JCLScriptName (artjesadminコンソールの場合)

このenvファイル内のすべての項目は、次のように"<NAME>=<VALUE>"書式に従う必要があります。

  • DATA=/home/testapp/data
  • PROCLIB=${PROCLIB}:${APPDIR}/proc
  • JESTRACE=DEBUG
2.15.3.2 ジョブの出力

[-t JCL|KSH]を次のようにフィルタとして使用します。

  • すべてのジョブの出力: printjob
  • JCLジョブの出力: printjob -t JCL
  • KSHジョブの出力: printjob -t KSH

列job typeが、次のいずれかの値を使用して結果に追加されます。

  • JCL (JCLジョブの場合)
  • KSH (KSHジョブの場合)

変換フェーズが完了する前、JCLのジョブ名とクラスはNULLで、優先度は0として表示されます。

2.15.3.3 JCLジョブの保留/解放/取消し/パージ

使用方法はKSHジョブと同じです。

2.15.3.4 JCLエンジンのデバッグ・トレース・ファイル

JCL変換ログは$JESROOT/<JOBID>/LOG/<JOBID>.traceです。

このトレース・ファイルは、デバッグの目的でのみ使用されます。

2.15.4 JCL文およびユーティリティのサポート範囲

表2-17に、サポートされるJCL文を示します。表2-18に、サポートされるユーティリティを示します。

表2-17 サポートされるJCL文

項目 サブ項目
DD文 パラメータDISP
パラメータDUMMY
パラメータSYSOUT=CLASS
パラメータDCB/RECFM/LRECL
パラメータDSN
パラメータDSN (後方参照)
パラメータDDNAME (前方参照)
パラメータLIKE
一時DD、&&TEMP
ストリーム内DD
連結DD
データセットMOD (追加)
データセット・カタログ機能、およびパラメータVOLUMN
データセット期限切れ機能
単一ステップでのDDの複製
排他的データセット(DDロックおよびロック解除)
特殊DD JOBLIB
特殊DD STEPLIB
EXEC文 パラメータPARM
パラメータCOND
ユーティリティの実行
COBOLプログラムの実行
パラメータでのCOBOLプログラムの実行
JOB文 パラメータCLASS
パラメータCOND
パラメータTYPERUN(COPY/HOLD/JCLHOLD/SCAN)
パラメータMSGCLASS
パラメータRESTART(*/stepname/stepname.procstepname)
JCLLIB文 -
SET文 -
IF/ELSE/ENDIF文 -
INCLUDE文 -
OUTPUT文 -
JCL変数 -
PROC/PEND文 -
PROCの起動 記号オーバーライド
PARMオーバーライド
CONDオーバーライド
DDオーバーライド

表2-18 サポートされるユーティリティ

ユーティリティ 説明
DSNTEP2 SQL DMLの実行
DSNTEP4 SQL DMLの実行
DSNTIAUL SQL DMLの実行
DSNTIAD SQL DMLの実行
FTP FTPクライアント
ICETOOL 多目的データセット操作の実行
IEBUPDTE PS/PDSの作成または変更
IEHLIST PDS/PDSEのエントリの一覧表示
IEHPROGM システム制御データの変更
IKJEFT01 アプリケーションの起動
IKJEFT1A
IKJEFT1B
PKZIP ZIP形式へのファイルの圧縮
PKUNZIP ZIP形式のファイルの解凍
IEBDG 記述に基づいたデータセットの作成
IEBGENER PSまたはPDSのメンバーのコピー
IEBPTPCH 順次またはパーティション化されたデータ・セットまたはPDSEのすべてあるいは設定された部分を単一ステップで出力またはパンチ
IEBCOPY PDS/PDSEのメンバーのコピーまたはマージ
FILEAID 多数の標準IBMユーティリティの機能の統合
IEFBR14 NULLユーティリティ
SORT データセットのソート、マージまたはフィルタ
ICEGENER IEBGENERの別名
ICEMAN SORTの別名
IDCNOGFL IDCAMSの別名
IEBFR14 IEFBR14の別名
IDCAMS VSAMデータセットおよび非VSAMデータセットを生成および変更します。
REXEC リモート・ホストでのコマンドの実行
DFSRRC00 IMSでのBMPプログラムの呼出し
DSNUTILB 表をロード/アンロードするために使用するDB2ユーティリティ

親トピック: ネイティブJCLジョブの実行

2.16 ネイティブJCLテスト・モード

この項には次の情報が含まれます:

親トピック: バッチ・ランタイムの使用方法

2.16.1 概要

ネイティブJCLテスト・モードは、ネイティブJCLの実行モードです。このモードは、ユーザー・ジョブ/プロセス内の欠陥の分析、ネイティブJCL機能の使用のずれの検索、およびジョブの実行を妨げる環境依存問題の検出に役立ちます。

親トピック: ネイティブJCLテスト・モード

2.16.2 構成

ネイティブJCLテスト・モードを使用するために次のように構成します。

親トピック: ネイティブJCLテスト・モード

2.16.2.1 環境変数の構成(必須)

テスト・モード・ジョブを発行する前に、必要な環境変数を設定します。次の表に、設定する必要のあるすべての環境変数を示します。

表2-19 ネイティブJCLテスト・モードに必要な環境変数

環境変数 説明
JESDIR TuxJESのインストール先のディレクトリ
JESROOT JES2システムのルート・ディレクトリ
DATA 永久ファイルのディレクトリ
PROCLIB PROCおよびINCLUDEファイルのディレクトリ
MT_COBOL COBOLを指定します。以下の値のいずれかを使用します。
  • COBOL_MF: Micro Focus COBOL
  • COBOL_IT: COBOL-IT COBOL
MT_DB ターゲット・データベースを指定します。以下の値のいずれかを使用します。
  • DB_ORACLE: Oracleデータベース
  • DB_DB2LUW: DB2データベース
MT_LOG ログ用ディレクトリ
MT_TMP 一時内部ファイルのディレクトリ
MT_SORT SORTを指定します。以下の値のいずれかを使用します。
  • SORT_MicroFocus: Micro Foucs COBOLソート・ユーティリティ
  • SORT_SyncSort: Syncsortソート・ユーティリティ
  • SORT_CIT: COBOL-IT COBOLソート・ユーティリティ

親トピック: 構成

2.16.2.2 ネイティブJCL構成ファイルの構成(オプション)

ネイティブJCL構成ファイルで使用する必要がある追加のユーティリティを構成します。この構成ファイルは、${JESDIR}/jclexec/conf/JCLExecutor.confの下にあり、そのADDUTILITYLIST項目が追加ユーティリティ・リストの定義に使用されます。

たとえば、MYUTILITYユーティリティを定義する場合はADDUTILITYLIST=MYUTILITYを指定する必要があります。複数のユーティリティを定義する場合は、カンマ(',')を使用してユーティリティを区切ってADDUTILITYLIST=MYUTILITY1,MYUTILITY2,…と指定する必要があります。

親トピック: 構成

2.16.3 クライアントを使用したテスト・モードの管理

ジョブまたはジョブのグループのテスト・モードを起動するにはartjclchkツールを使用できます。artjclchkツールのコマンドライン構文は次のとおりです。

artjclchk -d <destdir> [-i <job_file|job_dir>] [-p <parallel number>] [-r]

-d <destdir>

出力レポート・ファイルを保存する宛先ディレクトリを指定します。3種類の出力レポート・ファイルがあり、すべてがここで生成されます。詳細は、テスト・モード・レポート・ファイルを参照してください。

-i <job_file|job_dir>

テスト・モードで分析するジョブを指定します。個々のジョブまたはディレクトリを指定できます。ディレクトリを指定すると、このディレクトリの下のすべてのジョブが分析されます。

-p <parallel number>

同時に処理可能なジョブの数を指定します。

-r

カテゴリ・レポートおよびサマリー・レポートの生成を指定します。

  • -rを指定して-iを指定しないと、このコマンドは個別レポートのすべてについてカテゴリ・レポートおよびサマリー・レポートを-dディレクトリに生成します。
  • -rを指定して-iを指定すると、このコマンドは-iで指定されるすべてのジョブの個別レポートを生成し、その後これら個別レポートについてのみカテゴリ・レポートおよびサマリー・レポートを生成します。
  • -rを指定しないと、カテゴリ・レポートもサマリー・レポートも生成されません。

ノート:

artjclchkツールを同じ-iおよび-dオプション値を使用して2回実行すると、2回目の実行の結果で最初の実行の結果が置き換えられます。

親トピック: ネイティブJCLテスト・モード

2.16.4 テスト・モード・レポート・ファイル

artjclchkが生成する出力レポート・ファイルは3種類あります。

  • 個別レポート・ファイル

    個別レポート・ファイルはジョブ固有のレポート・ファイルです。artjclchkは、各ジョブごとに個別レポート・ファイルを生成し、ジョブで検出されたすべてがこのファイルに報告されます。

  • カテゴリ・レポート・ファイル

    カテゴリ・レポート・ファイルは、情報のタイプに従って編成されます。artjclchkは、情報のタイプごとにサマリー・レポート・ファイルを生成し、そのカテゴリに該当するオカレンスがジョブの場所および行番号とともにこのファイルに報告されます。

  • サマリー・レポート・ファイル

    サマリー・レポート・ファイルは、カテゴリ・レポートの簡略版です。artjclchkにより生成されます。カテゴリ・レポート・ファイルと異なり、サマリー・レポート・ファイルは問題と問題の出現数のみを記録します。サマリ・レポート・ファイルは対応するカテゴリ・レポート・ファイルと同じ名前ですが、"Occurences"はありません。

    次のトピックでは、各レポートについて詳しく説明します。

親トピック: ネイティブJCLテスト・モード

2.16.4.1 個別レポート・ファイル

個別レポート・ファイルはジョブ固有のレポート・ファイルです。artjclchkは、各ジョブごとに個別レポート・ファイルを生成し、ジョブで検出されたすべてがこのファイルに報告されます。

このファイルの名前は<JOBFILENAME>.rptの形式で、各行のフィールドがカンマで区切られています。これらのフィールドについて、次の表を参照してください。

  • 表2-20はJCL要素のフィールドを示します
  • 表2-21はIKJEFTxxユーティリティのフィールドを示します
  • 表2-22はその他のユーティリティのフィールドを示します

表2-20 JCL要素のレポート・フィールド

フィールド 値 説明
TYPE ROC PROCの問題を識別します
INCLUDE INCLUDEの問題を識別します
STATEMENT JCL文の問題を識別します
PARAM JCLパラメータの問題を識別します
SYMBOL JCL記号の問題を識別します
UTILITY ユーティリティの問題を識別します
PROGRAM プログラムの問題を識別します
DATASET データセットの問題を識別します
DD DDの問題を識別します
STEP STEPの問題を識別します
INTERNAL メモリー・フォルト、I/O欠陥など、内部の問題を識別します
STATUS FOUND

NOTFOUND

PROC、INCLUDE、PROGRAMおよびDATASETオブジェクトが検出されたかされなかったかを識別します
SUPPORTED

UNSUPPORTED

STATEMENT、PARAMおよびUTILITYオブジェクトがサポートされているかいないかを識別します

DEFINED

UNDEFINED

SYMBOLオブジェクトが定義されているかいないかを識別します
IGNORED STATEMENTまたはPARAMが認識されるが無視されることを識別します
INVALID STATEMENTまたはPARAMが認識されないことを識別します
ERROR システム/内部エラーが発生したことを識別します
NAME オブジェクト名 オブジェクト名。PROC名、INCLUDE名、PROGRAM名、UTILITY名、PARAM名、DATASET名またはその他のオブジェクト名が可能です。
FILE ファイルの場所 ファイルの場所を識別します
LINE 行の場所 行の場所を識別します
JCL JCL JCLの問題でありユーティリティの問題ではないことを識別します
DETAIL 詳細情報 この問題の詳細

表2-21 IKJEFTxxユーティリティのレポート・フィールド

フィールド 値 説明
TYPE COMMAND ユーティリティ・コマンドの問題を識別します
PARAM ユーティリティ・パラメータの問題を識別します
UTILITY ユーティリティの問題を識別します
PROGRAM プログラムの問題を識別します
DD DDの問題を識別します
STEP STEPの問題を識別します
INTERNAL メモリー・フォルト、I/O欠陥など、内部の問題を識別します
STATUS FOUND NOTFOUND PROGRAMオブジェクトが検出されたかされなかったかを識別します
SUPPORTED UNSUPPORTED COMMAND、PARAMおよびUTILITYオブジェクトがサポートされているかいないかを識別します
IGNORED COMMANDまたはPARAMが認識されるが無視されることを識別します
INVALID COMMANDまたはPARAMが認識されないことを識別します
ERROR システム/内部エラーが発生したことを識別します
NAME オブジェクト名 オブジェクト名。PROC名、INCLUDE名、PROGRAM名、UTILITY名またはその他のオブジェクト名が可能です。
FILE ファイルの場所 ファイルの場所を識別します
LINE 行の場所 行の場所を識別します。FILEおよびLINEの場所はJCLジョブ自体に関連しており、たとえば、現在のユーティリティが起動したSTEPの場所です。
UTILITY <UTILITYNAME> レポート行を生成するユーティリティの名前、たとえばIKJEFT01を識別します。
DETAIL 詳細情報 この問題の詳細

表2-22 その他のユーティリティのレポート・フィールド

フィールド 値 説明
TYPE COMMAND ユーティリティ・コマンドの問題を識別します
PARAM ユーティリティ・パラメータの問題を識別します
DD DDの問題を識別します
INTERNAL メモリー・フォルト、I/O欠陥など、内部の問題を識別します
STATUS SUPPORTED

UNSUPPORTED

COMMANDおよびPARAMオブジェクトがサポートされているかいないかを識別します
IGNORED COMMANDまたはPARAMが認識されるが無視されることを識別します
INVALID COMMANDまたはPARAMが認識されないことを識別します
ERROR システム/内部エラーが発生したことを識別します
NAME オブジェクト名 オブジェクト名。PROC名、INCLUDE名、PROGRAM名、UTILITY名またはその他のオブジェクト名が可能です。
FILE ファイルの場所 ファイルの場所を識別します
LINE 行の場所 行の場所を識別します。FILEおよびLINEの場所はJCLジョブ自体に関連しており、たとえば、現在のユーティリティが起動したSTEPの場所です。
UTILITY <UTILITYNAME> レポート行を生成するユーティリティの名前、たとえばIEBGENER、SORTおよびPKZIPを識別します
DETAIL 詳細情報 この問題の詳細
2.16.4.2 カテゴリ・レポート・ファイル

カテゴリ・レポート・ファイルは、情報のタイプに従って編成されます。artjclchkは、情報のタイプごとにサマリー・レポート・ファイルを生成し、そのカテゴリに該当するオカレンスがジョブの場所および行番号とともにこのファイルに報告されます。

次のレポートが生成されます。

  • 欠落した項目のレポート

    これは欠落した項目のカテゴリ・レポート・ファイルです。このレポート・ファイルの名前の書式は"Missing_Item_<DATETIME>_Occurences.csv"です。列については、表2-23を参照してください。

  • サポートされていない項目のレポート

    これはサポートされていない項目のカテゴリ・レポート・ファイルです。このレポート・ファイルの名前の書式は"Unsupported_Item_<DATETIME>_Occurences.csv"です。列については、表2-24を参照してください。

  • 無視された項目のレポート

    これは無視された項目のカテゴリ・レポート・ファイルです。このレポート・ファイルの名前の書式は"Ignored_Item_<DATETIME>_Occurences.csv"です。列については、表2-25を参照してください。

    疑わしいコード欠陥のレポート

    これは無視された項目のカテゴリ・レポート・ファイルです。このレポート・ファイルの名前の書式は" Ignored_Item_<DATETIME>_Occurences.csv "です。列については、表2-26を参照してください。

    欠落したデータセットのレポート

    これは欠落したデータセットのカテゴリ・レポート・ファイルです。このレポート・ファイルの名前の書式は"Missing_Dataset_<DATETIME>_Occurences.csv"です。列については、表2-27を参照してください。

    内部エラーのレポート

    これは内部エラーのカテゴリ・レポート・ファイルです。このレポート・ファイルの名前の書式は"Add content"です。列については、表2-28を参照してください。

    サポートされているユーティリティのレポート

    これはサポートされているユーティリティのカテゴリ・レポート・ファイルです。このレポート・ファイルの名前の書式は"Supported_Utility_<DATETIME>_Occurences.csv"です。列については、表2-29を参照してください。

表2-23 カテゴリ・レポート・ファイル: 欠落した項目のレポート

列名 説明
名前 欠落した項目の名前。
タイプ 項目タイプ。PROC、INCLUDEまたはPROGRAMが可能です。
ファイルの場所 呼び出されたファイル。
行番号 対応する行番号。

表2-24 レポート・ファイル: サポートされていない項目のレポート

列名 説明
名前 欠落した項目の名前。
タイプ 項目タイプ。PROC、INCLUDEまたはPROGRAMが可能です。
JCL/ユーティリティ JCLまたはユーティリティ名。
ファイルの場所 呼び出されたファイル。
行番号 対応する行番号。
説明 対応する行番号。

表2-25 カテゴリ・レポート・ファイル: 無視された項目のレポート

列名 説明
名前 無視された項目の名前。
タイプ 項目タイプ。STATEMENT、COMMANDまたはPARAMが可能です。
JCL/ユーティリティ JCLまたはユーティリティ名。
ファイルの場所 呼び出されたファイル。
行番号 対応する行番号。

表2-26 カテゴリ・レポート・ファイル: 疑わしいコード欠陥のレポート

列名 説明
文 無効な文。
タイプ 項目タイプ。
JCL/ユーティリティ JCLまたはユーティリティ名。
ファイルの場所 呼び出されたファイル。
行番号 対応する行番号。
説明 エラーの説明。

ノート:

検出された場所は、実際の根本原因ではなく解析が失敗した場所にすぎない場合があります。実際のコード欠陥は前の行にある場合があります。確認の際にエラーが報告されたコンテキストに注意してください。

表2-27 カテゴリ・レポート・ファイル: 欠落したデータセットのレポート

列名 説明
データセット 欠落したデータセット名。
ファイルの場所 呼び出されたファイル。
行番号 対応する行番号。
DD DD名。

表2-28 カテゴリ・レポート・ファイル: 内部エラーのレポート

列名 説明
エラー サポートされていない、無視された、または無効なパラメータ。
タイプ 項目タイプ。
ファイルの場所 呼び出されたファイル。
行番号 対応する行番号。
説明 エラーの説明。

表2-29 カテゴリ・レポート・ファイル: サポートされているユーティリティのレポート

列名 説明
名前 ユーティリティ名。
2.16.4.3 サマリー・レポート・ファイル

サマリー・レポート・ファイルは、カテゴリ・レポートの簡略版です。artjclchkにより生成されます。カテゴリ・レポート・ファイルと異なり、サマリー・レポート・ファイルは問題と問題の出現数のみを記録します。サマリ・レポート・ファイルは対応するカテゴリ・レポート・ファイルと同じ名前ですが、"Occurences"はありません。

次のレポートが生成されます。
  • 欠落した項目のレポート

    このレポート・ファイルの名前の書式は"Missing_Item_<DATETIME>.csv"です。列については表2-23を参照してください。

    ノート:

    これは、「欠落した項目のレポート」カテゴリ・レポート・ファイルの簡略版です。
  • サポートされていない項目のレポート

    このレポート・ファイルの名前の書式は"Unsupported_Item_<DATETIME>.csv"です。列については表2-24を参照してください。

    ノート:

    これは、「サポートされていない項目のレポート」カテゴリ・レポート・ファイルの簡略版です。
    無視された項目のレポート

    このレポート・ファイルの名前の書式は"Ignored_Item_<DATETIME>.csv"です。列については表2-25を参照してください。

    ノート:

    これは、「無視された項目のレポート」カテゴリ・レポート・ファイルの簡略版です。
  • 疑わしいコード欠陥のレポート
    このレポート・ファイルの名前の書式は"CodeDefect_<DATETIME>.csv"です。列については表2-26を参照してください。

    ノート:

    これは、「疑わしいコード欠陥のレポート」の簡略版です。
  • 欠落したデータセットのレポート
    このレポート・ファイルの名前の書式は"Missing_Dataset_<DATETIME>.csv"です。列については表2-27を参照してください。

    ノート:

    これは、「欠落したデータセットのレポート」カテゴリ・レポート・ファイルの簡略版です。
  • 内部エラーのレポート

    このレポート・ファイルの名前の書式は"Internal_Error_<DATETIME>.csv"です。列については表2-28を参照してください。

    ノート:

    これは、「内部エラーのレポート」カテゴリ・レポート・ファイルの簡略版です。
  • サポートされているユーティリティのレポート

    このレポート・ファイルの名前の書式は

    "Supported_Utility_<DATETIME>.csv"です。列については表2-29を参照してください。

    ノート:

    これは、「サポートされているユーティリティのレポート」カテゴリ・レポート・ファイルの簡略版です。

表2-30 サマリー・レポート・ファイル: 欠落した項目のレポート

列名 説明
名前 欠落した項目の名前。
タイプ 項目タイプ。PROC、INCLUDEまたはPROGRAMが可能です。
出現数 繰返し回数。

表2-31 サマリー・レポート・ファイル: サポートされていない項目のレポート

列名 説明
名前 サポートされていない項目の名前。
タイプ 項目タイプ。UTILITY、STATEMENT、COMMANDまたはPARAMが可能です。
JCL/ユーティリティ JCLまたはユーティリティ名。
説明 エラーの説明。
出現数 繰返し回数。

表2-32 サマリー・レポート・ファイル: 無視された項目のレポート

列名 説明
名前 無視された項目の名前。
タイプ 項目タイプ。STATEMENT、COMMANDまたはPARAMが可能です。
JCL/ユーティリティ JCLまたはユーティリティ名。
出現数 繰返し回数。

表2-33 疑わしいコード欠陥のレポート

列名 説明
文 無効な文。
タイプ 項目タイプ。
JCL/ユーティリティ JCLまたはユーティリティ名。
説明 エラーの説明。
出現数 繰返し回数。

表2-34 サマリー・レポート・ファイル: 欠落したデータセットのレポート

列名 説明
データセット 欠落したデータセット名。
DD DD名。
出現数 繰返し回数。

表2-35 サマリー・レポート・ファイル: 内部エラーのレポート

列名 説明
エラー サポートされていない、無視された、または無効なパラメータ。
タイプ 項目タイプ。
説明 エラーの説明。
出現数 繰返し回数。

表2-36 サマリー・レポート・ファイル: サポートされているユーティリティのレポート

列名 説明
名前 ユーティリティ名。
出現数 繰返し回数。

2.17 ネットワーク・ジョブ入力(NJE)のサポート

この項には次の情報が含まれます:

親トピック: バッチ・ランタイムの使用方法

2.17.1 概要

NJEサポートにより、JCLジョブの場合と同様、ユーザーはバッチ・ランタイムで次の機能を実装できます。

  • /* ROUTE XEQ
  • /* XEQ
  • /* XMIT

バッチ・ランタイムのm_SetJobExecLocation APIにより、ユーザーはNJEサポートを使用するKSHジョブを開発できます。例:

  • ジョブが実行されるサーバー・グループを指定します。
  • ジョブ内で、ストリーム内ジョブを別のサーバー・グループに送信し、そのサーバー・グループで実行します。

親トピック: ネットワーク・ジョブ入力(NJE)のサポート

2.17.2 構成

この項には次の情報が含まれます:

親トピック: ネットワーク・ジョブ入力(NJE)のサポート

2.17.2.1 ジョブ実行サーバー・グループ

API m_JobSetExecLocationでジョブ実行グループとして指定されているサーバー・グループを指定する場合は、次のことを確認してください。

  • 指定したサーバー・グループがJESドメインのubbconfigファイルに存在している必要があります。
  • 少なくとも1つのARTJESINITIATORサーバーがそのサーバー・グループにデプロイされている必要があります。

親トピック: 構成

2.17.2.2 NJEサポートのオン/オフ設定
対応する設定項目はJES構成ファイルにあります。

表2-37 <APPDIR>/jesconfig内の構成

名前 値 デフォルト値
NJESUPPORT ON: NJEサポートの有効化OFF: NJEサポートの無効化 OFF

NJEサポートがjesconfigで無効化されると、m_SetJobExecLocation <SvrGrpName>文がTuxJESに無視され、ジョブは任意のサーバー・グループ内の任意のARTJESINITIATORで実行される可能性があります。

親トピック: 構成

2.17.2.3 MPモードの環境変数MT_TMP

MPモードでは、MT_TMPをNFSで構成する必要があり、tuxedoドメイン内のすべてのノードが同じ値のMT_TMPを持ち、これを共有する必要があります。

MT_TMPは、ファイル$MT_ROOT/CONF/BatchRT.confで構成するか、各ノードでtlistenが開始する前に環境値としてエクスポート(export)できます。

親トピック: 構成

2.17.2.4 キューEXECGRP

NJESUPPORTがjesconfigで有効な場合、EXECGRPという名前の新しいキューを、既存のキュー・スペースJES2QSPACEに作成する必要があります。EXECGRPが作成されないと、JESはジョブを処理できません。

親トピック: 構成

2.17.3 NJEジョブの例

リスト2-32 ジョブ実行サーバー・グループを指定する例(XEQ) 

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

リスト2-33 ジョブを別のサーバー・グループに送信する例(XMIT) 

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によって実行されます。

親トピック: ネットワーク・ジョブ入力(NJE)のサポート

2.18 ファイル・カタログ・サポート

この項には次の情報が含まれます:

親トピック: バッチ・ランタイムの使用方法

2.18.1 概要

バッチ・ランタイムのファイル・カタログ・サポートにより、ユーザーはボリュームの下にあるデータセットにアクセスできます。ボリュームとはデータセット・キャリアであり、フォルダとして存在します。各データセットはボリュームに属します。

ファイル・カタログには、各データセットから各ボリュームへのマッピングが含まれています。メインフレームにある既存のカタログ化されたファイルを参照すると、ファイル・カタログがリクエストされてファイルが位置するボリュームを検出してから、ファイルがアクセスされます。

ファイル・カタログ機能が無効の場合、バッチ・ランタイムの動作は、この機能がないだけで他は変わりません。

親トピック: ファイル・カタログ・サポート

2.18.2 データベース表

次の表は、バッチ・ランタイムによるファイル・カタログ機能の一般的な管理を示しています。この表では、各行が、ファイルとボリュームの1つのマッピングを表しています。

表2-38 バッチ・ランタイム・カタログ

名前 タイプ 説明
FILENAME VARCHAR(256) ファイル名。スラッシュを含めることはできません。
VOLUME VARCHAR(256) ボリューム名。スラッシュを含めることはできません。
VOLUME_ATTR CHAR(1) 予約済。
EXPDT_DATE CHAR(7) ファイルの有効期限
CREATE_DATE CHAR(7) ファイルの作成日。
FILE_TYPE VARCHAR(8) ファイル編成。
JOB_ID VARCHAR(8) エントリを作成するジョブのID。
JOB_NAME VARCHAR(32) エントリを作成するジョブの名前。
STEP_NAME VARCHAR(32) エントリを作成するステップの名前。
主キー: PK_ART_BATCH_CATALOG

親トピック: ファイル・カタログ・サポート

2.18.3 構成変数

次の4つの構成変数をBatchRT.confに追加するか、環境変数として設定する必要があります。

MT_USE_FILE_CATALOG

yesに設定すると(MT_USE_FILE_CATALOG=yes)、ファイル・カタログ機能は有効です。それ以外の場合、機能は無効です。

MT_VOLUME_DEFAULT

新しいデータセットの作成時にボリュームが指定されない場合、MT_VOLUME_DEFAULTで定義されるボリュームが使用されます。MT_VOLUME_DEFAULTには、1つのボリュームのみを含めます。たとえば、MT_VOLUME_DEFAULT=volume1と指定します。

MT_DB_LOGIN

この変数には、データベース・アクセス情報が含まれます。Oracleでは、この値は"username/password@sid" (たとえば、"scott/password@gdg001")です。

Db2では、"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のみです。それ以外の場合、両方とも構成する必要があります。

親トピック: ファイル・カタログ・サポート

2.18.4 外部シェル・スクリプト

CreateTableCatalog[Oracle|Db2].shまたはDropTableCatalog[Oracle|Db2].shを使用して、データベース表を新規作成または削除できます。

親トピック: ファイル・カタログ・サポート

2.18.4.1 説明

データベースに表ART_BATCH_CATALOGを作成します。

2.18.4.2 使用方法

CreateTableCatalog[Oracle|Db2].sh <DB_LOGIN_PARAMETER>

2.18.4.3 サンプル

CreateTableCatalogOracle.sh scott/password@orcl

2.18.4.4 DropTableCatalog[Oracle|Db2].sh

この項には次の情報が含まれます:

2.18.4.4.1 説明

データベースから表ART_BATCH_CATALOGを削除します。

2.18.4.4.2 使用方法

DropTableCatalog[Oracle|Db2].sh <DB_LOGIN_PARAMETER>

2.18.4.4.3 サンプル

DropTableCatalogOracle.sh scott/password@orcl

2.18.5 外部依存関係

バッチ・ランタイムでファイル・カタログ機能を使用するには、ART Workbenchのファイル・コンバータおよびJCLコンバータがカタログ機能を有効にする必要があります。詳細は、『Oracle Tuxedo Application Rehosting Workbenchユーザー・ガイド』を参照してください。

親トピック: ファイル・カタログ・サポート

2.19 REXX EXECの起動

この項には次の情報が含まれます:

親トピック: バッチ・ランタイムの使用方法

2.19.1 MT_REXX_PATHの設定

MT_REXX_PATHのデフォルト値はありません。これは、すべてのREXX EXECが存在するメイン・パスで設定する必要があります。REXXプログラムを${MT_REXX_PATH}の下の適切なサブディレクトリに入れます。これらのサブディレクトリは、REXXプログラムのあるメインフレーム上のPDSに対応します。

親トピック: REXX EXECの起動

2.19.2 REXX EXECの起動

SYSEXECが定義されている場合、BatchRTは、m_ProgramExecが実行するプログラムをREXX EXECとして受け入れます。

DD SYSEXECは、オブジェクトREXXプログラムの場所を示します。

親トピック: REXX EXECの起動

2.19.3 TSOバッチ・コマンド

関連するREXXファイル(REXX APIとTSOコマンド)はすべて、Batch_RT/tools/rexxディレクトリに配置します。そのディレクトリ構造は次のとおりです。

-- lib

/-- outtrap.rex

/ -- regis_tso_cmd

-- tso

/-- DELETE

/-- LISTDS

/- RENAME

/-- libTSO.so

TSOコマンドは、Batch_RT/tools/rexx/tsoにあります。REXX APIは、Batch_RT/tools/rexx/libディレクトリに保存する必要があります。

ノート:

TSOコマンドにはロック・メカニズムが用意されています。REXXプログラムでTSOコマンドがアクセスするファイルは、コマンドの起動時にロックされます。TSOコマンドの実行が完了すると、ファイルのロックはすべて解除されます。

親トピック: REXX EXECの起動

2.20 COBOLプログラムのOracleおよびTimesTenデータベースへのアクセス

ART for Batchは、この機能で次のシナリオをサポートします。

  • COBOLプログラムがOracleデータベースとTimesTenデータベースの両方にアクセス
  • COBOLプログラムがTimesTenデータベースにのみアクセス

次のトピックでは、OracleおよびTimesTenデータベースにアクセスする手順について説明します。

親トピック: バッチ・ランタイムの使用方法

2.20.1 環境変数の設定

この機能を有効にするには、次の環境変数を設定する必要があります。

表2‑39 必須の環境変数

シナリオ 環境変数
MT_TT_CONN MT_DB MT_DB_LOGIN MT_DB_LOGIN2
OracleデータベースおよびTimesTenデータベース 必須。TimesTen接続名を指定します。 必須。ORAを指定します。 必須。Oracle接続資格証明を指定します。 必須。TimesTen接続資格証明を指定します。
TimesTenデータベースのみ 必須。TimesTen接続名を指定します。

ノート:

指定する必要があるのは、TimesTenのみを使用していることを示すために使用される擬似接続名のみです。この名前は、実際にはCOBOLプログラムでは使用されません。
必須。ORAを指定します。 必須。TimesTen接続資格証明を指定します。 必須ではない

さらに、次の環境変数を設定する必要があります。

  • LD_LIBRARY_PATHには、TimesTenライブラリおよびバンドルされたインスタント・クライアント・ライブラリを含める必要があります。
  • TNS_ADMINは、TimesTenとOracleの両方のTNS情報が含まれているtnsnames.oraファイルを含むディレクトリに設定する必要があります。詳細は、 Oracle TimesTen In-Memory Databaseのドキュメントを参照してください。

親トピック: OracleおよびTimesTenデータベースへのCOBOLプログラムのアクセス

2.20.2 COBOLでのプログラミング

OracleデータベースへのすべてのEXEC SQL文で、接続名を指定する必要はありません。ただし、TimesTenへのすべての操作では、MT_TT_CONNに設定されているとおりにTimesTen接続名を指定する必要があります。

親トピック: OracleおよびTimesTenデータベースへのCOBOLプログラムのアクセス

2.20.3 COBOLプログラムの前処理

この機能では、OracleデータベースまたはTimesTenデータベースにアクセスするすべてのCOBOLプログラムはTimesTen Pro*COBOLによって処理される必要があります。

親トピック: OracleおよびTimesTenデータベースへのCOBOLプログラムのアクセス

2.20.4 例

例のリストを次に示します。

親トピック: OracleおよびTimesTenデータベースへのCOBOLプログラムのアクセス

2.20.4.1 環境変数の設定の例

リスト2‑34 環境変数の設定の例 

export MT_TT_CONN=TTNAME1
export MT_DB=ORA
export MT_DB_LOGIN=user1/pass1@oracle
export MT_DB_LOGIN2=user2/pass2@tt
export TIMESTEN_HOME=/opt/TimesTen/tt
export LD_LIBRARY_PATH=${TIMESTEN_HOME}/lib:${TIMESTEN_HOME}/ttoracle_home/instantclient_11_2:${LD_LIBRARY_PATH}

親トピック: 例

2.20.4.2 OracleデータベースにアクセスするCOBOLプログラムの例

リスト2‑35 OracleデータベースにアクセスするCOBOLプログラムの例 

EXEC SQL
SELECT B
INTO :H-VALUE-B
FROM ORATBL01
END-EXEC.

親トピック: 例

2.20.4.3 TimesTenデータベースにアクセスするCOBOLプログラムの例

リスト2‑36 TimesTenデータベースにアクセスするCOBOLプログラムの例 

EXEC SQL DECLARE TTNAME1 DATABASE END-EXEC.
EXEC SQL
AT TTNAME1
SELECT NAME
INTO :H-VALUE-NAME
FROM TTTBL01
END-EXEC.

親トピック: 例

2.20.4.4 COBOLプログラムの前処理の例

リスト2‑37 COBOLプログラムの前処理の例 

export LD_LIBRARY_PATH=${TIMESTEN_HOME}/ttoracle_home/instantclient_11_2;${TIMESTEN_HOME}/ttoracle_home/instantclient_11_2/sdk/procob sqlcheck=syntax lname=SELECTTT.lis iname=SELECTDB.pco oname=SELECTDB.cob

親トピック: 例

2.20.4.5 COBOLプログラムのコンパイルの例(CIT)

リスト2‑38 COBOLプログラムのコンパイルの例(CIT) 

cobc -fthread-safe -m -g -G -fmf-gnt SELECTDB.cob -w -fixed -ffcdreg -lcitextfh -t SELECTDB.lst -conf=cit.conf

親トピック: 例