Japedia logo
japedia.wiki
🔍

ジョブ制御言語

J
Japedia 編集部
|更新日: 不明

ジョブ制御言語( JCL ) は、IBM メインフレームオペレーティング システムで使用されるスクリプト言語で、バッチ ジョブの実行方法やサブシステムの起動方法をシステムに指示します。[1] JCL の目的は、どのプログラムを実行するか、どのファイルまたはデバイス[2]を入力または出力に使用するかを指定することであり、場合によっては、どのような条件でステップをスキップするかを示すこともあります。JCL のパラメーターは、ジョブで使用されるリソースを追跡するためのアカウンティング情報や、ジョブを実行するマシンも指定できます。

IBM ジョブ制御言語には 2 つの異なる言語があります。

  • 1つはDOS/360から始まり、最新のメンバーがz/VSEであるオペレーティングシステム系統用です。
  • もう 1 つはOS/360からz/OSへの系統であり、後者には現在JES拡張機能であるジョブ エントリ制御言語 (JECL) が含まれています。

これらはいくつかの基本的な構文規則といくつかの基本的な概念を共有していますが、それ以外は非常に異なります。[3]

VMオペレーティング システムにはJCL 自体はありませんが、CP および CMSコンポーネントにはそれぞれコマンド言語があります。

用語

JCL と組み合わせて使用​​される特定の単語またはフレーズは、IBM メインフレーム テクノロジーに固有のものです。

  • データセット: 「データセット」はファイルであり、一時的または永続的であり、ディスクドライブ、テープストレージ、またはその他のデバイス上に配置されます。[4] [5]
  • メンバー: パーティションデータセット (PDS) の「メンバー」は、PDS 内の個別のデータセットです。メンバーにアクセスするには、メンバー名を括弧で囲んで PDS の名前を指定します。たとえば、SYS1.MACLIB のシステムマクロ GETMAIN は、SYS1.MACLIB(GETMAIN) として参照できます。[6]
  • パーティション データセット: 「パーティション データセット」または PDS は、メンバーのコレクション、またはアーカイブです。パーティション データセットは、ソース コード、アセンブラ マクロ (SYS1.MACLIB)、システム構成 (SYS1.PARMLIB)、再利用可能な JCL プロシージャ (SYS1.PROCLIB) などのテキスト データを格納するためによく使用されます。そのため、アーカイブ ファイル (ZIP、TAR など) や他のオペレーティング システムのディレクトリと共通点があります。また、バイナリ コード (ロード モジュールまたはプログラム オブジェクト) を格納するためにも使用されます。その意味では、 Unix ベースのシステムのar ベースの静的ライブラリにほぼ類似しています。このような構造のほとんどと同様に、メンバーは一度格納されると更新できません。メンバーは、IEBUPDTEユーティリティなどを使用して削除して置き換える必要があります。[6] 1989 年の MVS DFP 3.2 リリース以来、PDSE (Partitioned Data Set Extended) が PDS の改良版として存在しています。[7]ユーザーやアプリケーションプログラマの観点から見ると、それらはほとんど変更されていません（いくつかの目立たないレガシー機能の削除を除く）が、内部実装は大きく異なります。
  • USS: Unix システム サービス。MVS ベース制御プログラムの一部として実行される完全な Unix 環境であり、仮想化なしで完全に POSIX 準拠の Unix 環境のメインフレーム上で Unix ファイル、スクリプト、タスク、およびプログラムを実行できます。

モチベーション

もともと、メインフレーム システムはバッチ処理を指向していました。多くのバッチ ジョブは、主記憶装置、磁気テープ、専用ディスク ボリューム、特別なフォームでセットアップされたプリンタなどの専用デバイスに対する特定の要件を伴うセットアップを必要とします。 [8] JCL は、ジョブの実行をスケジュールする前に、必要なすべてのリソースが利用可能であることを保証する手段として開発されました。たとえば、Linuxなどの多くのシステムでは、必要なデータセットの識別をコマンド ラインで指定できるため、シェルによる置換の対象になったり、実行時にプログラムによって生成されたりします。これらのシステムでは、オペレーティング システムの ジョブ スケジューラはジョブの要件をほとんどまたはまったく認識していません。対照的に、JCL は必要なすべてのデータセットとデバイスを明示的に指定します。スケジューラは、ジョブの実行を解放する前にリソースを事前割り当てできます。これにより、「デッドロック」を回避できます。デッドロックとは、ジョブ A がリソース R1 を保持してリソース R2 を要求し、同時に実行中のジョブ B がリソース R2 を保持して R1 を要求する状態です。このような場合、唯一の解決策は、コンピュータ オペレータがジョブの 1 つを終了し、その後ジョブを再起動することです。ジョブ制御では、ジョブ A の実行がスケジュールされている場合、ジョブ A が完了するか必要なリソースを解放するまで、ジョブ B は開始されません。

DOS と OS JCL に共通する機能

仕事、ステップ、手順

DOS と OS の両方で、作業の単位はジョブです。ジョブは 1 つまたは複数のステップで構成され、各ステップは 1 つの特定のプログラムを実行する要求です。たとえば、リレーショナル データベースが登場する前は、管理者用の印刷レポートを作成するジョブは、次のステップで構成されていました。適切なレコードを選択して一時ファイルにコピーするユーザー作成プログラム、通常は汎用ユーティリティを使用して一時ファイルを必要な順序に並べ替えるユーザー作成プログラム、エンド ユーザーが読みやすく、小計などのその他の有用な情報も含む形で情報を提示するユーザー作成プログラム、およびエンド ユーザー情報の選択したページをモニターまたは端末に表示するためにフォーマットするユーザー作成プログラムです。

DOSとOS JCLの両方において、最初の「カード」はJOBカードでなければなりません。[9]

  • ジョブを識別します。
  • 通常、コンピュータ サービス部門が適切なユーザー部門に請求できるようにするための情報を提供します。
  • ジョブ全体の実行方法 (キュー内の他のジョブに対する優先順位など) を定義します。

プロシージャ (一般にprocsと呼ばれる) は、ジョブに挿入されるステップまたはステップのグループ用に事前に記述された JCL です。両方の JCL でこのようなプロシージャを使用できます。procs は、1 つのジョブまたは複数の異なるジョブで複数回使用されるステップを繰り返すために使用されます。これにより、プログラマの時間が節約され、エラーのリスクが軽減されます。プロシージャを実行するには、指定されたファイルからプロシージャをコピーしてジョブストリームに挿入する単一の「カード」を JCL ファイルに含めるだけです。また、procs には、使用ごとにプロシージャをカスタマイズするための パラメータを含めることができます。

基本的な構文

DOSとOSのJCLはどちらも、使用可能な最大行長が80文字です。これは、DOS/360とOS/360が最初に使用されたとき、コンピュータシステムに新しい入力を提供する主な方法が80列のパンチカードだったためです。[10]その後、より長いレコード長のディスクファイルまたはテープファイルを介してジョブを送信できるようになりましたが、オペレーティングシステムのジョブ送信コンポーネントは80文字目以降のすべてを無視しました。

厳密に言えば、どちらのオペレーティング システム ファミリも 1 行あたり 71 文字しか使用しません。文字 73 ～ 80 は通常、システムがジョブ終了レポートに印刷するカード シーケンス番号であり、オペレーティング システムによって報告されたエラーの場所を識別するのに役立ちます。文字 72 は通常は空白のままですが、JCL ステートメントが次のカードに続くことを示すために、空白以外の文字を含めることができます。

USSファイル名を除き、すべてのコマンド、パラメータ名、値は大文字にする必要があります。

インストリーム入力 (下記参照) を除くすべての行はスラッシュ " /" で始まる必要があり、オペレーティング システムによって処理されるすべての行は 2 つのスラッシュで始まる必要があります(常に最初の列//から始まります)。ただし、区切り文とコメント文という 2 つの例外があります。区切り文はスラッシュとアスタリスク ( ) で始まり、OS JCL のコメント文はスラッシュとアスタリスクのペア ( ) で始まり、DOS JCL ではアスタリスクで始まります。 /*//*

多くの JCL ステートメントは長すぎて 71 文字以内に収まりきりませんが、次の方法で無制限の数の継続カードに拡張できます。

最も一般的なタイプのカードの構造は次のとおりです。[11]

ストリーム内入力

DOS と OS JCL はどちらもインストリーム入力、つまりオペレーティング システムではなくアプリケーション プログラムによって処理される「カード」を許可します。長期間保存されるデータは通常ディスクに保存されますが、対話型端末の使用が一般的になる前は、そのようなディスク ファイルを作成および編集する唯一の方法は、新しいデータをカードに提供することでした。

DOSとOSのJCLはインストリーム入力の開始を通知する方法が異なりますが、どちらも/*最後のインストリームデータカードに続くカードの列1でインストリーム入力を終了します。これにより、オペレーティングシステムはカードの次のカードでJCLの処理を再開します/*。[12]

  • OS JCL: DD ステートメントは、データ セットだけでなく、インストリーム データも記述するために使用できます。インストリーム データを扱う DD ステートメントには、DD 識別子の後にアスタリスク (*) が付きます (例 ) //SYSIN DD *。DD DATA ステートメントを使用することで、JCL ステートメントをインストリーム データの一部として含めることができます。
DLMというオペランドでは、区切り文字を指定できます (デフォルトは「/*」)。別の区切り文字を指定すると、JCL をデータとして読み取ることができ、たとえば、ライブラリ メンバーにプロシージャをコピーしたり、ジョブを内部リーダーに送信したりできます。
  • [13]では、ジョブを内部リーダー（INTRDR）に送信し、2つのファイルを削除します。
// SUBM EXEC PGM = IEBGENER // SYSPRINT DD    SYSOUT = Z // SYSUT2    DD    SYSOUT = ( A 、INTRDR ) // SYSIN     DD    DUMMY // SYSUT1    DD    DATA 、DLM = ZZ // RUNLATR JOB ACCT 、MANIX 、CLASS = A 。TYPRUN = HOLD //* ^ 後で実行するジョブ// CPUHOG EXEC PGM = PICALC1K // OUTPUT    DD    DSN = PICALC .1000 DGTS 、SPACE = ( TRK 、1 )、DISP = (、KEEP ) ZZ //* ^ DLM=ZZ で指定されたとおり// DROPOLDR EXEC PGM = IEFBR14 // DELETE4   DD    DSN = PICALC .4 DGTS 、DISP = ( OLD 、DELETE ) // DELETE5   DD    DSN = PICALC .5 DGTS 、DISP = ( OLD 、DELETE )
  1. PICALC1Kと呼ばれるプログラムは、手動で解放されるのを待ちます（TYPRUN=HOLD）。
  2. IEFBR14というプログラムが今すぐ実行され、完了すると、既存の 2 つのファイル (PICALC.4DGTS と PICALC.5DGTS) が削除されます。
  • DOS JCL: プログラムの EXEC カードの後に​​インストリーム データを入力するだけです。

複雑

JCLが作成されたOS/360プロジェクトを監督したフレッド・ブルックスは、著書『デザインの設計』の中で、JCLを「これまでに誰かが考案した最悪のコンピュータプログラミング言語」と呼び、「熟練した設計者が間違える理由」の章で例として挙げている。[14]彼は、その理由を、設計者がJCLが実際にはプログラミング言語であることを理解できなかったためだとした。

特に、OS JCL の複雑さの多くは、データセット情報を指定するためのオプションが多数あることに起因しています。Unix 系オペレーティング システム上のファイルは、順序付けられたバイト ストリームに抽象化され、構造化データの読み取りと書き込みのタスクはユーザー レベルのプログラム (最終的には、そのようなストリームを取り込んで出力する) のみに属し、データの保存とアクセスの実際の詳細は、ユーザー プログラムが認識することなく、オペレーティング システムによって大部分が処理されます。一方、OS/360 およびその後継システムのデータセットは、ファイルの種類とサイズ、レコードの種類と長さ、ブロック サイズ、磁気テープ密度などのデバイス固有の情報、およびラベル情報を公開します。多くのオプションにシステム デフォルトがありますが、JCL とプログラムにコード化された情報の組み合わせによって、プログラマーが指定するオプションはまだ多くあります。プログラムにコード化された情報が多いほど、柔軟性が低くなります。これは、プログラム内の情報が JCL 内の情報を上書きするためです。したがって、ほとんどの情報は通常、JCL を通じて提供されます。

たとえば、Unixオペレーティング システムでファイルをコピーするには、ユーザーは次のようなコマンドを入力します。 

cp 古いファイル 新しいファイル

次の例では、JCL を使用して OS/360 上のファイルをコピーできます。 

// IS198CPYジョブ( IS198T30500 )、'コピー ジョブ' 、CLASS = L 、MSGCLASS = X // COPY01 EXEC PGM = IEBGENER // SYSPRINT DD SYSOUT = * // SYSUT1    DD DSN = OLDFILE 、DISP = SHR // SYSUT2    DD DSN = NEWFILE 、// DISP = ( NEW 、CATLG 、DELETE )、// SPACE = ( CYL 、( 40 、5 )、RLSE )、// DCB = ( LRECL = 115 、BLKSIZE = 1150 ) // SYSIN   DDダミー

JCL の複雑さの 2 つ目の説明は、ジョブの実行に対する期待がPCや Unix のような環境とは異なることです。

  • ローエンドの System/360 CPU は、MS-DOS が設計された 1980 年代半ばの PC よりも性能が低く、高価でした。OS/360 は最小メモリ サイズが 32 KB のシステム向けであり、DOS/360 は最小メモリ サイズが 16 KB のシステム向けでした。1964年に System/360 が発表された当時はローエンドだった360/30 CPU は、1 秒あたり 1.8K ～ 34.5K の命令を処理しました。 [15] 1981 年の最初の IBM PC は 16 KB または 64 KB のメモリを持ち、1 秒あたり約 330K の命令を処理しました。[16] [17]その結果、JCL はコンピュータが処理しやすいものでなければならず、プログラマーにとっての使いやすさは優先度が低くなりました。この時代、プログラマーはコンピュータよりもはるかに安価でした。
  • JCL はバッチ処理用に設計されています。そのため、ステップの結果に応じて何をすべきかを含め、オペレーティング システムにすべてを指示する必要があります。たとえば、はDISP=(NEW,CATLG,DELETE)「プログラムが正常に実行された場合は、新しいファイルを作成してカタログ化し、そうでない場合は新しいファイルを削除する」ことを意味します。PC で実行されるプログラムは、多くの場合、処理の問題のクリーンアップをユーザーに依存しています。
  • System/360 マシンは、組織内のすべてのユーザーが共有できるように設計されています。したがって、JOBカードは、ユーザーのアカウントへの課金方法 ( IS198T30500)、割り当て可能なストレージおよびその他のリソースの定義済み量 ( CLASS=L)、およびその他のいくつかのことをオペレーティング システムに指示します。は、白紙の小切手がセットされている可能性のある他のプリンターではなく、通常の用紙がセットされている既定のプリンター//SYSPRINT DD SYSOUT=*でプログラムのレポートを印刷するようにコンピューターに指示します。 は、他のプログラムが同時に読み取ることができることをオペレーティング システムに指示します。DISP=SHROLDFILE

DOS/360 および OS/360 オペレーティング システムの後のバージョンでは、元の JCL のほとんどの機能が保持されていますが、顧客がすべての JCL ファイルを書き直す必要がないように、ある程度の簡素化が行われています。[要出典]多くのユーザーは、1 回または 2 回以上使用される可能性のある JCL ステートメントのセットをプロシージャとして保存します。 [18]

OS JCL の構文は、System/360アセンブリ言語のマクロの構文に似ているため、多くのプログラムがアセンブリ言語でコーディングされていた時代のプログラマーには馴染み深いものだったでしょう。

DOS JCL

位置パラメータ

// TLBL TAPEFIL、'COPYTAPE.JOB'、,,,2 // ASSGN SYS005、200 // DLBL DISKFIL、'COPYTAPE.JOB'、0、SD // EXTENT SYS005、VOL01、1、0、800、1600

DOS JCL パラメータは位置指定型であるため、読み取りや書き込みは難しくなりますが、システムによる解析は容易になります。

  • プログラマーは、あらゆる種類のステートメントでどの項目がどの位置に配置されるかを覚えておく必要があります。
  • 一部のオプション パラメータが省略されているが、後続のパラメータが含まれている場合、省略されたパラメータは、上記の TLBL ステートメントのように、スペースなしのコンマで表す必要があります。

DOS JCL は、OS JCL よりも少ないパラメータでより多くのステートメントを使用することにより、位置パラメータの難しさをある程度軽減します。例では、ASSGN、DLBL、および EXTENT ステートメントは、OS JCLDDの単一のステートメントと同じ作業 (新しいディスク ファイルを保存する場所の指定) を実行します。

デバイス依存

オリジナルの DOS/360 およびほとんどのバージョンの DOS/VS では、各ディスク ファイルまたはテープ ファイルに使用するデバイスのモデル番号を指定する必要がありました。これは、ジョブの終了時に削除される既存のファイルや一時ファイルに対しても同様でした。つまり、顧客がより新しい機器にアップグレードする場合、多くの JCL ファイルを変更する必要がありました。

DOS/360 ファミリの後継製品では、デバイス モデル番号が必要となる状況が減りました。

手動ファイル割り当て

DOS/360 では、当初プログラマーがDASD上のすべてのファイルの場所とサイズを指定する必要がありました。EXTENTカードは、エクステントが存在するボリューム、開始絶対トラック、およびトラックの数を指定します。z/VSE の場合、ファイルは異なるボリューム上に最大 256 のエクステントを持つことができます。

OSJCL

OS JCLは3つの基本的なステートメントタイプで構成されています: [19]

  • JOBジョブの開始を識別し、課金、実行の優先順位、時間とスペースの制限など、ジョブ全体に関する情報を示すステートメント。
  • EXECジョブのこのステップで実行されるプログラムまたは手順[20]と、ステップを実行またはスキップするための条件
    を含むステップに関する情報を識別するステートメント。
  • DD(データ定義) ステートメント。ステップで使用するデータ ファイルとそのファイルに関する詳細情報を識別します。DDステートメントは、ステップ内で任意の順序で配置できます。

当初から、OS ファミリー ( z/OSまでを含む) の JCL はより柔軟で使いやすかったです。

次の例では、1964 年のSystem/360の発売当初から提供されていた古いスタイルの構文を使用しています。この古い構文は、わずかな変更のみで数十年にわたって実行されているジョブでは今でもかなり一般的です。

JCLステートメントのコーディング規則

各JCLステートメントは5つのフィールドに分かれています。[21] 

識別子フィールド 名前フィールド 操作フィールド パラメータフィールド コメントフィールド
                 ^ ^ ^ ^
              スペースなし スペース スペース スペース

識別子フィールドは名前フィールドと連結する必要があります。つまり、間にスペースを入れないでください。

  • 識別子フィールド( //): 識別子フィールドは、ステートメントがデータではなく JCL ステートメントであることをシステムに示します。識別子フィールドは次の要素で構成されます。
    • 区切り文を除くすべてのJCL文の列1と2には、//
    • 区切り文の列1と2には、/*
    • JCLコメント文の列1、2、3には、//*
  • 名前フィールド: 名前フィールドは特定のステートメントを識別し、他のステートメントやシステムがそれを参照できるようにします。JCL ステートメントの場合は、次のようにコーディングする必要があります。
    • 名前は 3 列目から始まる必要があります。
    • 名前は 1 ～ 8 文字の英数字または国別文字 ( $、#、@) です。
    • 最初の文字はアルファベットである必要があります。
    • 名前の後には少なくとも 1 つの空白が必要です。
  • 操作フィールド: 操作フィールドは、ステートメントのタイプ、またはコマンド ステートメントの場合はコマンドを指定します。操作フィールドは次のようにコーディングする必要があります。
    • 操作フィールドは、ステートメントの構文ボックス内の文字で構成されます。
    • 操作は名前フィールドに従います。
    • 演算の前後には少なくとも 1 つの空白が必要です。
    • 操作はJOB、、EXECおよびのいずれかになりますDD。
  • パラメータ フィールド: パラメータ フィールド (オペランド フィールドとも呼ばれる) には、カンマで区切られたパラメータが含まれます。パラメータ フィールドは次のようにコーディングする必要があります。
    • パラメータ フィールドは操作フィールドの後に続きます。
    • パラメータ フィールドの前には少なくとも 1 つの空白が必要です。
    • パラメータ フィールドには、プログラム名やデータセット名などの情報を提供するためにステートメント内で使用されるキーワードであるパラメータが含まれます。
  • コメント フィールド: ここにコメントが含まれます。コメント フィールドは次のようにコーディングする必要があります。
    • コメント フィールドはパラメーター フィールドの後に続きます。
    • コメント フィールドの前には少なくとも 1 つの空白が必要です。

キーワードパラメータ

// NEWFILE DD DSN = MYFILE01 、UNIT = DISK 、SPACE = ( TRK 、80、10 ) 、// DCB = ( LRECL = 100 、BLKSIZE = 1000 ) 、// DISP = ( NEW 、CATLG 、DELETE )

OS JCL ステートメントのすべての主要なパラメータはキーワードによって識別され、任意の順序で指定できます。これらのいくつかには、上記の例のSPACE(新しいファイルに割り当てるディスク領域の量) やDCB(ファイルのレイアウトの詳細な指定) など、2 つ以上のサブパラメータが含まれます。サブパラメータは、 のように位置指定される場合もありますがSPACE、 などの最も複雑なパラメータには、DCBキーワード サブパラメータがあります。

位置パラメータはキーワードパラメータの前に置く必要があります。キーワードパラメータは常に等号（=）を使用してキーワードに値を割り当てます。[22]

データアクセス（DDステートメント）

ステートメントDDは、データを参照するために使用されます。このステートメントは、プログラムの内部データセット記述を、ディスク、テープ、カード、プリンターなどの外部デバイス上のデータにリンクします。DD は、デバイス タイプ (例: '181'、'2400-5'、'TAPE')、テープまたはディスクのボリューム シリアル番号、およびデータ ファイル記述 (ファイルの識別に使用されるプログラム内のデータ制御ブロックDCB(DCB)にちなんでサブパラメータと呼ばれる) などの情報を提供します。

ファイルを記述する情報は、DD カード情報、テープまたはディスクに保存されている既存のファイルのデータセット ラベル情報、プログラムにコード化された DCB マクロの 3 つのソースから取得できます。ファイルが開かれると、このデータはマージされ、DD 情報がラベル情報よりも優先され、DCB 情報がその両方よりも優先されます。更新された記述は、データセット ラベルに書き戻されます。誤った DCB 情報が提供されると、予期しない結果につながる可能性があります。[23]

上記のパラメータと、さまざまなアクセス方法やデバイスに関する特定の情報があるため、DD ステートメントは最も複雑な JCL ステートメントです。ある IBM リファレンス マニュアルでは、DD ステートメントの説明に 130 ページ以上が費やされています。これは、JOB ステートメントと EXEC ステートメントを合わせた長さの 2 倍以上です。[24]

DD ステートメントを使用すると、インライン データをジョブ ストリームに挿入できます。これは、IDCAMS、SORT などのユーティリティに制御情報を提供したり、プログラムに入力データを提供したりする場合に役立ちます。

デバイスの独立性

OS ファミリーのオペレーティング システム用の JCL は、当初から高度なデバイス独立性を提供していました。ジョブ終了後も保持される新しいファイルに対しても、デバイス タイプを一般的な用語で指定できます (例: 、、UNIT=DISKまたはUNIT=TAPE(UNIT=SYSSQテープまたはディスク))。もちろん、必要な場合はモデル番号や特定のデバイス アドレスを指定することもできます。[25]

手順

プロシージャは、 1つ以上の「EXEC PGM =」およびDDステートメントをグループ化し、「EXEC PROC = procname」または単に「EXEC procname」で呼び出すことを可能にする[26]

手順ライブラリと呼ばれる機能により、手順を事前に保存できるようになりました。

処理と保留

// PENDプロシージャをステートメントで終了し、プロシージャ ライブラリ内にある場合と同じように名前で呼び出すことによって、 プロシージャをジョブ ストリームに含めることもできます。

例えば： 

// SUMPRINT PROC
 // PRINT EXEC PGM=IEBGENER // SYSUT1    DD    DSN = CEO . FILES . DAYEND . RPT24A , DISP = SHR // SYSUT2    DD    SYSOUT = A // SYSIN     DD    DUMMY // PEND // EXEC SUMPRINT

パラメータ化された手順

OS JCLプロシージャは最初からパラメータ化されており、マクロや単純なサブルーチンのようなもので、さまざまな状況で再利用性が向上しています。 [27] 

// MYPROC PROC FNAME = MYFILE01 、SPTYPE = TRK 、SPINIT = 50 、SPEXT = 10 、LR = 100 、BLK = 1000 
..... 
// NEWFILE DD DSN =& FNAME 、UNIT = DISK 、SPACE = ( & SPTYPE 、& SPINIT 、& SPEXT )、
// DCB = ( LRECL =& LR 、BLKSIZE =& BLK )、DISP = ( NEW 、CATLG 、DELETE ) ....

この例では、アンパサンド " " で始まるすべての値は、&ジョブがプロシージャの使用を要求するときに指定されるパラメータです。 PROC ステートメントは、プロシージャに名前を付けるだけでなく、プログラマが各パラメータのデフォルト値を指定できるようにします。 したがって、この例の 1 つのプロシージャを使用して、さまざまなサイズとレイアウトの新しいファイルを作成できます。 たとえば、次のようになります。 

// JOB01ジョブ.......... // STEP01 EXEC MYPROC FNAME=JOESFILE、SPTYPE=CYL、SPINIT=10、SPEXT=2、LR=100、BLK=2000または// JOB02ジョブ.......... // STEP01 EXEC MYPROC FNAME=SUESFILE、SPTYPE=TRK、SPINIT=500、SPEXT=100、LR=100、BLK=5000

リファバック

複数ステップのジョブでは、前のステップで既に指定されているファイルを後続のステップで完全に指定する代わりに、 参照バックを使用できます。例:

// MYPROC ................ // MYPR01 EXEC PGM = .......... // NEWFILE DD DSN =& MYFILE 、UNIT = DISK 、SPACE = ( TRK 、50、10 ) 、// DCB = ( LRECL = 100 、BLKSIZE = 1000 ) 、DISP = ( NEW 、CATLG 、DELETE ) .... // MYPR02 EXEC PGM = .......... // INPUT01 DD DSN = * . MYPR01 . NEWFILE

ここでは、ステップでMYPR02識別されたファイルを使用します（は「データセット名」を意味し、ファイルの名前を指定します。DSNは44文字を超えることはできません[28]）。 NEWFILEMYPR01DSN

ジョブ固有の JCL とプロシージャ呼び出しが混在するジョブでは、ジョブ固有のステップは、プロシージャで完全に指定されたファイルを参照できます。次に例を示します。 

// MYJOB JOB .......... // STEP01 EXEC MYPROCプロシージャの使用// STEP02 EXEC PGM = .........このジョブに固有のステップ// INPUT01 DD DSN = * . STEP01 . MYPR01 . NEWFILE

ここで、は「このジョブのステップで使用されるプロシージャのステップでDSN=*.STEP01.MYPR01.NEWFILE識別されるファイルを使用する」ことを意味します。プロシージャの名前ではなく、プロシージャを呼び出したステップの名前を使用すると、プログラマーは、参照バックで使用されるプロシージャのインスタンスについて混乱することなく、同じジョブで同じプロシージャを複数回使用できます。 NEWFILEMYPR01STEP01

コメント

JCL ファイルは長くて複雑になる可能性があり、言語は読みにくいです。OS JCL では、プログラマーが 2 種類の説明コメントを含めることができます。

  • XJCL ステートメントと同じ行にあります。継続文字 (慣例的には " ") を列 72 に配置し、// 次の行の列 1 ～ 3 に " "を配置することで拡張できます。
  • コメントのみを含む行。多くの場合、ローカルの詳細ではなく、JCL の全体的な構造に関する主要なポイントを説明するために使用されます。コメントのみの行は、長くて複雑な JCL ファイルをセクションに分割するためにも使用されます。
// MYJOB JOB .......... //* コメントのみの行。//******** JCL リストをセクションに分割するためによく使用されます ******** // STEP01 EXEC MYPROCコメント 2 はステートメントと同じ行にあります// STEP02 EXEC PGM = .........コメント 3 が拡張され、X //が別の行にオーバーフローしています。// INPUT01 DD DSN = STEP01 . MYPR01 . NEWFILE

入力ファイルの連結

OS JCLを使用すると、プログラマーは入力ファイルを連結（「チェーン」）して、プログラムに1つのファイルとして表示することができます。たとえば、 

// INPUT01 DD DSN = MYFILE01 、DISP = SHR 
// DD DSN=JOESFILE、DISP=SHR // DD DSN=SUESFILE、DISP=SHR

2 番目と 3 番目のステートメントの名前フィールドには値がないため、OS はそれらを連結として扱います。ファイルは同じ基本タイプ (ほとんどの場合連続) であり、同じレコード長である必要がありますが、ブロック長は同じである必要はありません。

OSの初期バージョン（OS/360 R21.8以前）では、ブロック長は降順でなければなりません。または、ユーザーが各インスタンスを調べて、見つかった最大ブロック長を名前付きDDステートメントに追加する必要があります。たとえば、 

// INPUT01 DD DSN = MYFILE01 、DISP = SHR 、BLKSIZE = 800 
// DD DSN=JOESFILE、DISP=SHR (BLKSIZE は 800 以下と想定) // DD DSN=SUESFILE、DISP=SHR (BLKSIZE は 800 以下と想定)

OS のそれ以降のバージョン (適切な「選択可能なユニット」を備えた OS/MVS R3.7 以降) では、割り当て中に OS 自体が連結内の各インスタンスを検査し、見つかった最大ブロック長を代入します。

通常のフォールバックは、デバイス上で可能な最大ブロック長を単純に決定し、それを名前付きDDステートメントで指定することでした。たとえば、 

// INPUT01 DD DSN = MYFILE01 、DISP = SHR 、BLKSIZE = 8000 
// DD DSN=JOESFILE、DISP=SHR (BLKSIZE は 8000 以下と想定) // DD DSN=SUESFILE、DISP=SHR (BLKSIZE は 8000 以下と想定)

このフォールバックの目的は、アクセス メソッドが、指定されたデータセットのすべてを収容するのに十分な大きさの入力バッファー セットを割り当てるようにすることです。

条件付き処理

OSはプログラムがどの程度成功したかを示す戻りコードを設定することを期待している。最も一般的な慣例的な値は以下のとおりである: [29] : p.87 

  • 0 = 正常 - すべて正常
  • 4 = 警告 - 軽微なエラーまたは問題
  • 8 = エラー - 重大なエラーまたは問題
  • 12 = 重大なエラー - 重大なエラーまたは問題。結果 (生成されたファイルやレポートなど) は信頼できません。
  • 16 = 端末エラー - 非常に深刻な問題なので、結果を使用しないでください。

OS JCL は戻りコードをCOND(「条件コード」) と呼び、それを使用して後続のステップを実行するかどうかを決定できます。ただし、ほとんどの最新のプログラミング言語とは異なり、OS JCL の条件付きステップは、指定された条件が true の場合は実行されません。そのため、「true の場合は [コードを実行せずに] 通過する」というニーモニックが生まれます。さらに複雑なことに、条件は参照するステップの後にのみ指定できます。たとえば、 次のようになります。

// MYJOB JOB ........... // STEP01 EXEC PGM = PROG01 .... // STEP02 EXEC PGM = PROG02 、COND = ( 4 、GT 、STEP01 ) .... // STEP03 EXEC PGM = PROG03 、COND = ( 8 、LE ) .... // STEP04 EXEC PGM = PROG04 、COND = ( ONLY 、STEP01 ) .... // STEP05 EXEC PGM = PROG05 、COND = ( EVEN 、STEP03 ) ....

手段：

  1. を実行しSTEP01、その戻りコードを収集します。
  2. STEP02数値 4 が のSTEP01戻りコードより大きい場合は実行しないでください。
  3. STEP03数字 8 が以前の戻りコード以下の場合は実行しないでください。
  4. STEP04異常終了した場合にのみ実行しますSTEP01。
  5. 異常終了したSTEP05場合でも実行します。STEP03

これは次の疑似コードに変換されます。 

STEP01を実行します。STEP01
の戻りコードが4以上の場合は
    STEP02を実行する
終了
前の戻りコードが8未満の場合
    STEP03を実行する

STEP01が異常終了した場合
    STEP04を実行する
終了
if STEP03が異常終了した場合then
    STEP05を実行する
それ以外
    STEP05を実行する
終了の場合

ステートメントを含むステップをCOND逆から読むと、かなり簡単に理解できることに注意してください。これは論理転置の例です。ただし、IBM は後に JCL に IF 条件を導入し、パラメーターを保持しながらプログラマーのコーディングをいくらか容易にしましたCOND( が使用されている既存の JCL に変更を加えないようにするためCOND parm)。

パラメータはステートメントCOND上で指定することもできますJOB。その場合、システムは「ジョブのすべてのステップで同じ戻りコードテストを実行します。JOBステートメントの戻りコードテストが満たされると、ジョブは終了します。」[30]

ユーティリティ

ジョブは、データの処理を支援するために、いくつかのIBM ユーティリティ プログラムを使用します。ユーティリティはバッチ処理で最も役立ちます。ユーティリティは次の 3 つのセットにグループ化できます。

  • データ セット ユーティリティ - データ セットを作成、印刷、コピー、移動、削除します。
  • システム ユーティリティ - カタログやその他のシステム情報を維持および管理します。
  • アクセス方式サービス -仮想記憶アクセス方式(VSAM) および非 VSAM データ セットを処理します。

使いにくさ

OS JCL は紛れもなく複雑であり[31]、「ユーザーにとって不親切」と評されてきた[32] [33] 。ある JCL の指導書は、「なぜ熟練したプログラマーでさえジョブ制御言語となると躊躇するのか」と問いかけている[34]。 この本には、多くのプログラマーが、制御カードを実際に何をするのか理解せずにコピーするか、「JCL はひどいもので、理解できるのは「頑固な」コンピューター ユーザーだけという噂を信じ」、JCL ステートメントを理解する作業を他の人に任せている、と書かれている。 [34] このような態度は、プログラミング言語の教科書に見られる。これらの教科書は、言語自体に重点を置き、プログラムの実行方法には重点を置かない傾向がある。あるFortran IV の教科書は、 WATFORコンパイラーから発生する可能性のあるエラー メッセージを列挙する際に、「自分で 'DD' システム制御カードを書こうとするほど愚かなことをしたのか。直ちに中止し、助けを求めよ。歩いてはいけない」と述べている[35]。

それでも、JCL を詳細に解説した書籍の中には、ある程度習熟すればインストール全体のデフォルト設定から解放され、IBM システムがワークロードを処理する方法をより適切に制御できるようになると強調しているものもある。[34] [31] 別の書籍では、複雑さについて触れつつも、「安心してください。[前の章] で習得する JCL 機能は、ほとんどのプログラマーが必要とする機能のすべてです」と述べている。[31]

ジョブエントリ制御言語

IBMメインフレームシステムでは、ジョブ入力制御言語（JECL）は、スプーリングサブシステム（z/OSの場合はJES2またはJES3、z/VSEの場合はVSE/POWER）に情報を提供するコマンド言語制御ステートメントのセットです。JECLステートメントは、「どのネットワークコンピュータでジョブを実行するか、いつジョブを実行するか、および結果の出力先をどこに送信するかを指定します。」 [29]

JECL は、ジョブの実行 方法をオペレーティング システムに指示するジョブ制御言語(JCL)とは異なります。

3 つの環境にはそれぞれ異なるバージョンの JECL があります。

オペレーティングシステム

OS/360 リモートジョブエントリ用のジョブエントリ制御言語の初期バージョン (プログラム番号 360S-RC-536) では、入力レコードの 1 列目から 2 列目に識別子が使用され  、単一の制御ステートメント(ジョブエントリ定義)..  で構成されていました。 、、などの「ワークステーションコマンド」も で始まっていました   。[36]JEDLOGONLOGOFFSTATUS..

JES前 JECL

この用語はまだ開発されていませんでしたが、HASP には構文を含め、JESの JECL となるものと同様の機能がありました/*。

オペレーティングシステム

JES2 の場合、JECL ステートメントは で始まり、JES3 の場合、リモート コマンド  と  コマンドを除いて  /*で始まります  。2 つのシステムのコマンドは完全に異なります。 //*/*SIGNON/*SIGNOFF

JES2 ジェックル

以下のJES2 JECL文はz/OS 1.2.0で使用されている。[37]

JES3 ジェックル

以下のJES3 JECL文はz/OS 1.2.0で使用されている[39]

VSE の

VSE の場合、JECL ステートメントは ' * $$' で始まります ( 1 つのスペースに注意)。ジョブ エントリ制御言語は、JCL ジョブの開始行と終了行を定義します。これは、VSE / POWERにこのジョブの処理方法を指示します。JECL ステートメントは、ジョブ名 (VSE/POWER によって使用される)、ジョブが処理されるクラス、およびジョブの処理 (つまり、、、、D)を定義します。 LKH

例： 

* $$ ジョブ JNM=NAME、DISP=K、CLASS=2

[ここに JCL ステートメントをいくつか示します]

* $$ EOJ

その他のシステム

他のメインフレームバッチシステムには、ジョブ制御言語 (そう呼ばれるかどうかは別として) がいくつかありました。その構文は IBM バージョンとはまったく異なりますが、通常は同様の機能を提供していました。 対話型システムには「コマンド言語」が含まれます。コマンド ファイル (PCDOS の「.bat」ファイルなど) は非対話型で実行できますが、通常は JCL ほど無人ジョブを実行するための堅牢な環境を提供しません。一部のコンピュータ システムでは、ジョブ制御言語と対話型コマンド言語が異なる場合があります。たとえば、 z/OS システム上のTSO は、バッチ作業用のコマンド言語として JCL とともにCLISTまたはRexx を使用します。他のシステムでは、これらは同じである可能性があります。

参照

参考文献

  1. ^ 「実行のために送信されたすべてのジョブには、JCL ステートメントが含まれている必要があります」 -- ibm.com
  2. ^ ファイルを保持するか削除するか、最大ディスク容量、事前にマウントするテープの名前など、より複雑な詳細も多数あります。
  3. ^ AshleyとFernandez、「ジョブ制御言語」、p.1。
  4. ^ AshleyとFernandez、「ジョブ制御言語」、5ページ。
  5. ^ McQuillen、System/360–370アセンブラ言語、pp.385–386。
  6. ^ ab McQuillen、System/360–370 アセンブラ言語、pp. 288–289、400。
  7. ^ Lewis, Cecilia (2011年8月8日). 「PDSEで最近皆さんのためにやったこと」(PDF) . SHARE in Orlando . 2023年3月3日閲覧。
  8. ^ McQuillen、System/360–370アセンブラ言語、pp.22–24。
  9. ^ McQuillen、System/360–370アセンブラ言語、pp.380–382。
  10. ^ スターンとスターン、「構造化COBOLプログラミング」、pp.528-529。
  11. ^ SternとStern、「構造化COBOLプログラミング」、pp.529、531。
  12. ^ SternとStern、「構造化COBOLプログラミング」、pp.529、537。
  13. ^ https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.hasc300/has2z1_Submitting_to_the_internal_reader_from_jobs_or_tasks.htm をモデルに、グリーンカードが IBM から発行され、Manix が IBM カード ソーターを所有する会社で働いていた時代にまで遡る知識を使用しています。
  14. ^ ブルックス、フレデリック P. (2010)。デザインのデザイン。アディソン・ウェズレー。pp. 167–173。ISBN 978-0-201-36298-5。
  15. ^ 「IBM アーカイブ: System/360 モデル 30」www-03.ibm.com 2003 年 1 月 23 日。2004 年 12 月 17 日時点のオリジナルよりアーカイブ。2016年 4 月 25 日閲覧。
  16. ^ 「IBM PC」。2006年7月5日時点のオリジナルよりアーカイブ。2007年10月21日閲覧。
  17. ^ IBM互換機 PCの歴史 2007年8月14日アーカイブ、Wayback Machine
  18. ^ ブラウン、ゲイリー・デワード（2002年）。zOS JCL（第5版）。ジョン・ワイリー・アンド・サンズ。p.248。ISBN 0471-236357。
  19. ^ Ashley と Fernandez、「Job Control Language」、pp. 8、23。また、JCL プロシージャをテストするために使用される PROC と PEND という 2 つの追加ステートメントもあります。
  20. ^ パラメータ化可能な「EXEC PGM=」および「DD」JCLコマンドの事前保存セット
  21. ^ アシュリーとフェルナンデス、「ジョブ制御言語」、pp.12-16。
  22. ^ アシュリーとフェルナンデス、「ジョブ制御言語」、pp.13-15。
  23. ^ IBM Corporation (1978 年 8 月). OS/VS MVS データ管理サービス ガイド(PDF) . 2014 年10 月 17 日閲覧。
  24. ^ IBM Corporation (1971 年 6 月). IBM System/360 オペレーティング システム: ジョブ制御言語リファレンス(PDF) . 2019 年6 月 25 日閲覧。
  25. ^ McQuillen、System/360–370アセンブラ言語、pp.297、406–407。
  26. ^ EXEC ステートメントのデフォルトは PROC= です。
  27. ^ アシュリーとフェルナンデス、「ジョブ制御言語」、pp.129-131。
  28. ^ 「データ セット名」。IBM。2014年3 月 27 日。データ セット名は、名前セグメントとピリオドすべてを含めて 44 文字を超えてはなりません。
  29. ^ ab Brown, Gary DeWard (2002). zOS JCL. John Wiley & Sons. ISBN 9780471426738. 2014年5月5日閲覧。
  30. ^ IBM Corporation. 「JOB ステートメントと EXEC ステートメントの COND パラメータの関係」。IBM Knowledge Center。2018年2 月 21 日閲覧。
  31. ^ abc McQuillen、System/360–370アセンブラ言語、pp.406–407。
  32. ^ Charley, Alfred (1993). NetView: IBM のネットワーク管理製品。ニューヨーク: Van Nostrand Reinhold。p. 93。ISBN 0-442-01407-4。
  33. ^ Mathew W. Blode (2020 年 4 月 6 日). 「Newly unemployed New Yorkers are being frustrated by 1970s-era technology(nytimes.com)」 。 2020 年5 月 7 日閲覧。特に JCL はユーザーに不親切なことで有名で、Fred Brooks 氏によって「史上最悪のプログラミング言語」と呼ばれています... (http://dtsc.dfw.ibm.com/MVSDS/'HTTPD2.APPS.ZOSCLASS.PDF(ZCLA...)[link in original].
  34. ^ abc AshleyとFernandez、「ジョブ制御言語」、pp. vii–viii、裏表紙。
  35. ^ Blatt, John M. (1971). 『FORTRAN IV プログラミング入門: WATFOR/WATFIV コンパイラの使用』 カリフォルニア州パシフィックパリセーズ: Goodyear Publishing Company. p. 276. ISBN 0-87620-440-X。
  36. ^ IBM Corporation (1968). IBM System/360 オペレーティング・システム・リモート・ジョブ・エントリ(PDF) . 2014年5月5日閲覧。
  37. ^ IBM Corporation. 「Job Entry Subsystem 2 (JES2) 制御ステートメント」。z/OS V1R2.0 MVS JCL。2015年10月18日時点のオリジナルよりアーカイブ。2013年2月25日閲覧。
  38. ^その他の例は 、Houston Automatic Spooling Priority#Operator Commandsで参照できます。
  39. ^ IBM Corporation. 「Job Entry Subsystem 3 (JES3) 制御ステートメント」。z/OS V1R2.0 MVS JCL。2015年10月18日時点のオリジナルよりアーカイブ。2013年2月25日閲覧。
  40. ^ IBM Corporation (1974). DOS/VS POWER/VS のインストールと操作(PDF) .

出典

  • 「z/OS V1R6.0 MVS JCL ユーザーズ ガイド」(PDF) (第 5 版)。IBM。2004 年 9 月。2013 年 8 月 19 日にオリジナル(PDF)からアーカイブ。2006年 10 月 12 日に取得。
  • 「z/OS V1R7.0 MVS JCL リファレンス」(PDF) (第 11 版)。IBM。2006 年 4 月。2013 年 8 月 19 日にオリジナル(PDF)からアーカイブ。2006年 10 月 12 日に取得。
  • Johnston, Jerry (2005 年 4 月 1 日)。「VSE: 過去 40 年間の振り返り」。z/Journal。Thomas Communications。2009 年 3 月 4 日時点のオリジナルよりアーカイブ。
  • 「コンピュータクロニクル: 1972 - 1981」。ThinkQuest。Oracle Corporation。1998年。2009年6月21日時点のオリジナルよりアーカイブ。
  • デワード・ブラウン、ゲイリー（2002年6月7日）。zOS JCL（第5版）。Wiley。ISBN 978-0-471-23635-1。
  • 「JCL ステートメント フィールド」。z /OS V1R11.0 MVS JCL リファレンス z/OS V1R10.0-V1R11.0。IBM。2010年。
  • IBM コーポレーション (2007 年 3 月)。新しいメインフレームの紹介: z/VSE の基礎(PDF)。IBM、国際技術サポート組織。ISBN 978-0-73-848624-6. 2017年12月6日閲覧。
  • アシュリー、ルース、フェルナンデス、ジュディ N. (1978)。ジョブ制御言語：自己学習ガイド。ニューヨーク：ジョン ワイリー アンド サンズ。ISBN 0-471-03205-0。
  • McQuillen, Kevin (1975). System/360–370 アセンブラ言語 (OS) . カリフォルニア州フレズノ: Mike Murach & Associates. LCCN  74-29645.
  • スターン、ナンシー; スターン、ロバート A. (1980)。構造化 COBOL プログラミング(第 3 版)。ニューヨーク: John Wiley & Sons。ISBN 0-471-04913-1。
Retrieved from "https://en.wikipedia.org/w/index.php?title=Job_Control_Language&oldid=1242251433"
ジョブ制御言語 | japedia.wiki