JPS61248132A - バツチ・フアイル処理方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は一般に、ディスク・オペレーティング・システ
ム（ＯＯＳ）の下で実行させるアプリケーション・プロ
グラムの能率を改善するための方法、特にＤＯ８のバッ
チ（、ＢＡＴ）ファイルを処理する改良された方法に関
する。

Ｂ、従来技術 パーソナル・コンピュータは、ディスク・オペレーティ
ング・システム（ＤＯ５）を用いているが、これはコン
ピュータが特定のタスクを実行するために使用する１組
のコマンド又はプログラムである。しばしば、ユーザが
同じ１ｆｆｉのＤＯＳコマンドを繰り返して実行させた
い場合が存在する。

ＤＯ３は、コマンドが使用される毎にそれを再度タイプ
する必要なしに、上記の事を行なう方法を提供している
。即ち、それらのコマンドを１．ＢＡＴというファイル
・エクステンションの付いたテキスト・ファイルに保存
しておく、上記エクステンションはそのファイルがバッ
チ・ファイルである事を示すものである。ファイル名が
キーボードから入力された時、ＤＯＳは最初に、そのフ
ァイル名を有する実行可能プログラムを探す、もしその
ようなプログラムが見つからなければ、次にＤＯＳはそ
の入力されたファイル名を有するバッチ・ファイルを探
す、そのファイル名を持つバッチ・ファイルが見つかっ
たと仮定すると、ＤＯＳは、キーボードからの入力に応
答する代りに、バッチ・ファイルからコマンドを入力す
る。そして。

バッチ・ファイルの終りに至ると、キーボードからの入
力が再び受は入れられるようになる。

ＤＯＳの最近の版においては、バッチ・ファイルは、コ
マンドのシーケンスを変更するためにＧＯＴＯコマンド
及びＩＦ／ＴＨＥＮコマンドのようないくつかのプログ
ラム論理コマンドを含むことができる。またファイルの
存在をテストし、データ・ストリングの値を比較する事
ができる。さらに、プログラムが正しく終了したかどう
かをテストする）’＝めＬＣＥＲＲＯＲＬＥＶＥＬ　（
ｚラーラベル）検査を提供する事もできるが、それには
終了したプログラムがＥＲＲＯＲＬＥＶＥＬフィールド
をセットする必要がある。現在、このフィールドをセッ
トするＤＯＳプログラムはＢＡＣＫＵＰ及びＲＥＳＴＯ
ＲＥの２つのプログラムだけである。ＤＯＳの具体的な
インプリメンテーションについての詳細は、「ディスク
・オペレーティング・システムＪ　　（Ｄｉｓｋ　Ｏｐ
ｅｒａｔｉｎｇ　Ｓｙｓｔａｍ）と題するＩＢＭ　　Ｐ
Ｃのマニュアルを参照されたい、また「ディスク・オペ
レーティング・システム、テクニカル・リファレンスＪ
　　（Ｄｉｓｋ　Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ、
Ｔｅｃｈｎｉｃａｌ　Ｒｅｆｅｒｅｎｃｅ）と厘するＩ
ＢＭ　　ＰＣマニュアルを参照されたい。

Ｃ０発明が解決しようとする問題点 ＤＯ８のバッチ機能が有用である程、そのインプリメン
テーションは性能を配慮しなければならない、ＯＯＳの
バッチ・ファイル処理プログラムの外部動作の研究によ
れば、バッチ処理の性能は下記の因子の１つ以上によっ
て影響されている。

第１に、バッチ・ファイルのレコードは、可変長で且つ
復帰、改行（ＣＲ／ＬＦ）の文字列で終端している。Ｄ
ＯＳがバッチ・ファイルからレコードを読む毎に、ファ
イルが「オープン」される。

これはディレクトリにアクセスするためのディスク入力
機能を必要とする。第２に、ＤＯＳは、各ディスク・ア
クセス毎にファイルから１つの論理的バッチ・レコード
しか読取れない、第３に、もしＤＯＳがＧＯＴＯコマン
ドに出合うと、ＤＯＳはファイルを最初の論理レコード
から、必要なラベルを見つけるまで読取る。第４に、も
しプログラムが異常終了した場合、ＤＯＳは、バッチ・
ファイルの終端に至るまで、バッチ・ファイル・レコー
ドを処理し続ける。

ＤｏＳの前述の特性は、ある環境においてバッチ処理が
なぜ所望の速さよりも遅いのかを説明するのに役立つ、
バッチ・ファイルからの各論理レコードは、最小限２回
のディスク・アクセスを必要とする。もしバッチ・ファ
イルのディレクトリ記入項目が、読取られた最初のディ
レクトリ・ブロック中になければ、又は論理バッチ・フ
ァイル・レコードがバッチ・ファイルの最初のセクタに
存在しなければ、ＤＯＳは物理的ディスクに複数回アク
セスしなければならない、その結果、バッチ処理の性能
は、必要なディスク・アクセスの数に依存した因子だけ
劣化する。

従って、本発明の目的は、ＤＯＳの下におけるバッチ処
理の全体的性能を改善する事である。

Ｄ０問題点を解決するための手段 本発明の態様によれば、最も頻繁に使用されるＤＯＳバ
ッチ・コマンドは内部的に処理し、使用頻度の低いバッ
チ・コマンドは、第２コマンド処理プログラムに渡す、
最小限のサイズのプログラムが提供される。

バッチ・ファイル処理プログラムの基本的動作は次の通
りである。プログラムがＤＯＳから制御を受は取る時、
それは最初に、バッチ・ファイルのバッファに必要な記
憶域の大きさを計算する。

このバッチ・ファイル・バッファは、実際に必要なだけ
のバッファ用メモリをバッチ・ファイル処理プログラム
が使用する事を可能にするために。

大きさが可変になっている。バッチ・ファイル処環プロ
グラムによって行なわれる計算は、コマンド行からＤｏ
Ｓによって上記プログラムに渡されたパラメータを使用
し、残り全てのメモリは、プログラム実行のためにＤｏ
Ｓに戻される。コマンド行からバッチ・ファイル処理プ
ログラムに渡されるパラメータは、（１）バッファの大
きさ及び（２）ロードされる最初のバッチ・ファイルの
名前である０本発明の良好な且つ実際にインプリメント
された実施例においては、これらのパラメータはプログ
ラムによってアプリケーション・プログラム中のバッチ
・ファイルに書込まれた。しかしながら、アプリケーシ
ョン・プログラムの末端ユーザがコマンド行の上にパラ
メータをキー人力する事も可能である。また、バッチ・
ファイル・バッファの大きさは、バッチ・ファイル処理
プログラム中に固定的にプログラムされていてもよい。

この場合、コマンド行からＤｏＳによってプログラムに
パラメータを渡す必要性は存在しない、この方式は上記
実施例の持つ柔軟性には欠ける。というのはバッチ・フ
ァイル処理プログラムのためのコードが書かれる時点で
、許される最大のバッチ・ファイル・バッファについて
の決定が行なわなければならないからである。また上記
実施例で採用された以上の柔軟性ある方式を採用する事
も可能である。具体的には、バッチ・ファイル処理プロ
グラムが、必要なバッファの大きさを決定するために、
ロードされるバッチ・ファイルに関するディスク・ディ
レクトリの内容を読取る事によって、バッチ・ファイル
・バッファの大さきを動的に決定する事もできる。いず
れの場合においても、コマンド行で指定されたバッチ・
ファイルが、処理のためにメモリ・バッファにロードさ
れ、そして主コマンド処理プログラム・モジュールが１
度に１論理レコードづつバッチ・ファイルに質問し続け
る。ＤｏＳバッチ・コマンドを処理するために適当なル
ーチンに制御が渡される。コマンドが終了すると、制御
は主コマンド処理プログラムに戻される。もしプログラ
ムが、他のバッチ・ファイルに関する要求に出会うと１
次のバッチ・ファイルがバッファにロードされる。次に
処理されるべきレコードは、この新しいバッチ・ファイ
ル中の最初のレコードである。

前述のよりＭ　ＰＣＤｏＳの場合、第２．０版以後の版
は、本発明に従ってバッチ処理プログラムを作成するの
に必要な機能を提供している。

最も重要な新しい機能はプログラム実行（ＥＸＥＣ）で
ある、これは、プログラムが他のプログラムをメモリに
ロードし、それを実行する事を可能にする。第２のプロ
グラムが終了した時、元のプログラムは再び制御を与え
られる。この時、要求の成功又は失敗を示すために元の
プログラムに標識が戻される。別の重要な新しい機能は
、５ＥＴＢＬＯＣＫ機能である。これは、プログラムが
その必要とするメモリの大きさを指定し且つ他のプログ
ラムによる使用のために残部を解放する事を可能にする
。この機能は、本発明によるバッチ処理プログラムにお
いて、ユーザがバッチ・ファイル・バッファの大きさを
指定し、アプリケーション・プログラムのためにメモリ
を解放する事を可能にするために使われている。これら
の機能の使用法に関するより詳細な情報は、前掲のマニ
ュアルｒＤｉｓｋ　Ｏｐｅｒａｔｉｎｇ　５ｙｓｔａ＋
ｓＪ及びｒＤｉｓｋ　Ｏｐｅｒａｔｉｎｇ　５ｙｓｔｅ
＋ｍ、Ｔｅｃｈｎｉｃａｌ　ＲｅｆｅｒｅｎｃｅＪを参
照されたい。

アプリケーション・プログラムの実行に関して、バッチ
・ファイル処理プログラムは、ＥＸＥＣ機能を使用して
、アプリケーション・プログラムをロードし実行するよ
うにＤｏＳに要求を出す、アプリケーション・プログラ
ムが終了する時、制御はバッチ・ファイル処理プログラ
ムに戻される。

この時、バッチ・ファイル処理プログラムがアプリケー
ション・プログラムの異常終了条件を検出し、バッチ・
ファイルの処理を中断する事を可能にする標識がＤｏＳ
から返される。プログラムが異常終了した時にバッチ・
ファイルの処理を中断する能力は、ＤｏＳを上回る改善
である。ＤｏＳのバッチ・ファイル処理では、プログラ
ムの異常終了の後にバッチ・ファイルの残りが処理され
るであろう。

プログラム内部で処理されない全てのＤＯＳバッチ・コ
マンドは、第２コマンド処理プログラムを起動する事に
よって実行される。ＣＯＭＭＡＮＤ、００Ｍプログラム
の第２のコピーをロードし実行させるためには、前記と
同じＤＯ８のＥＸＥＣ機能が使われる。ＤＯＳバッチ・
コマンドは、ＣＯＭＭＡＮＤ、ＣＯＭのプログラム・セ
グメント・接頭部領域中のコマンド行に渡される。上記
領域は、プログラム実行中に制御情報を記憶するために
ＤＯ８によって形成される１２８バイトの領域である。

ＣＯＭＭＡＮＤ、００Ｍプログラムの第２のコピーをロ
ードし実行させる能力は、ＰＣ−ＤＯ８の第２．０版以
後によって提供される拡張機能の１つである。

本発明によるバッチ・ファイル処理プログラムは、それ
がバッチ・ファイル処理の間にシステムの制御を維持す
るという点で「シェル（ＳＨＥＬＬ）Ｊ型のプログラム
である。このプログラムはシステム及びアプリケーショ
ンの性能を改善する。

Ｅ、実施例 本発明の良好な実施例は、ＩＢＭ　　ＰＣＥＬＯ８第２
．０版以後の版と共に使用するように設計され、ＩＢＭ
　　ＰＣに提供さたれ基本人出力シス−７−Ａ　（Ｂ　
Ｉ　Ｏ８）　及びＰＣＤＯ８（７）機能ノミを使用する
。従って、プログラムは、修正なしに、ＰＣＤＯ８の将
来の版の上でも動作する事ができる。ＢＩＯ８のリスト
に関しては、ＩＢＭ　　ＰＣ用のｒＴｅｃｈｎｉｃａｌ
　ＲａｆｅｒａｎｃｅＪの付録Ａを参照されたい。プロ
グラムが固定ディスク上で最小限のスペースを占め且つ
メモリの′使用量を最小限に保つために、プログラムの
大きさはアセンブリ言語において最大４０９６バイトに
制限されている。

４０９６バイトのプログラムでは全てのバッチ・コマン
ドのシミュレーションは不可能である。従って最も頻繁
に使用されるＰＣＤＯＳコマンドのみが内部的に処理さ
れる。使用頻度の低いバッチ・コマンドは第２コマンド
処理プログラムを用いて処理するためにＰＣＤＯ３に渡
される。これはＰＣＤＯ８第２．０版において導入され
た新しい機能である。プログラムは、コマンドをＰＣＤ
Ｏ３に渡し、そのコマンドが処理された後、制御を取り
戻すことができる。第２コマンド処理プログラムを使用
する時にバッチ・ファイル・レコードを読取るための付
加的なディスク・アクセスは必要でないが、第２コマン
ド処理プログラムが使用される度に毎回ＣＯＭＭＡＮＤ
、ＣＯＭプログラムの余分のコピーをロードするために
付加的なディスク・アクセスが必要である。この負担は
、プログラムのサイズを大幅に増加させる事に対するト
レード・オフである。本発明の良好な実際にインプリメ
ントされた実施例においては、次のＰＣＤＯＳバッチ・
コマンドが内部的に処理される。

ＣＤ／ＣＨＤＩＲＰＡＵＳＥ ＭＤ／ＭＫＤＩＲＭＯＲＥ ＲＤ／ＲＭＤＩＲ５ＯＲＴ ＥＲＡＳＥ／ＤＥＬ　　　ＥＣＨ○ ＲＥＮ　（ＡＭＥ）　　　　　ＧＯＴＯＣＬＳ　　　　
　　　　　　ＩＦ ＳＨＩＦＴ　　　　　　　ＲＥＭ 次のＰＣＤＯＳコマンドはＰＣＤＯ３に渡される。

ＣＨＫＤＳＫ　　　　　　Ｃ０ＰＹ 傘ＣＯＭＰ　　　　　　　　　ＤＡＴＥ傘ＤＩＳＫＧＯ
ＭＰ　　　　ＤＩＲ 中ＤＩＳＫＣＯＰＹ　　　　ＴＩＭＥ ＊ＲＥｃｏｖＥＲＴＹＰＥ ＄ＳＹＳ　　　　　　　　　　ＦＯＲ ＣＴＴＹ　　　　　　　　ＶＥＲＩ　ＦＹＰＲＯＭＰＴ
　　　　　　ＶＯＬ ＊ＦＯＲＭＡＴ　　　　　＊ＥＸＥ２ＢＩＮＢ　ＲＥ　
ＡＫ　　　　　　虐ＴＲＥＥＵＥＲ拳ＰＲＩＮＴ ＳＥＴ　　　　　　　　　ＡＳＳＩＧＮＦＩＮＤ　　　
　　　　　串ＧＲＡＰＨＩＣ８＊ＭＯＤＥ 星印（串）を付けたコマンドは内部コマンドではなく、
実行可能プログラムである。バッチ・ファイル・メモリ
・バッファは大きさが可変であり。

それが実際に必要とするだけのファイル・バッファ用の
メモリを使用する。

実施例にはいくつかの制限が加えられている。

第１に、グローバル・ファイル名又は入出力の変更（リ
ダイレクシミン）を用いるバッチ・コマンドは、コマン
ドの前にｒｃＯＭＭＡＮＤ／ＣＪを用いて、バッチ・フ
ァイル中で呼び出されなければならない。入出力の変更
は、ＰＣＤＯ８第２゜０版で導入された別の拡張機能で
ある。第２に、全てのバッチ・ファイル要求は１．ＢＡ
Ｔのエクステンションを含まなければならない、これは
ＰＣＤＯ８がファイル名しか要求しないのとは異なって
いる。第３に、バッチ・ファイル中に含まれるプログラ
ム名は１．ＥＸＥ又は、ＣＯＭのエクステンションを含
まなければならない、第４に、コマンド区切り文字とし
て等号（＝）を使用する事はできない、第５に、２つの
呼び出しパラメータが必要である。パラメータ１はバッ
チ・バッファのキロバイト単位の大きさであり、パラメ
ータ２はロードされる最初のバッチ・ファイルの名前で
なければならない。例えば、ＢＡＴＣＨ２ＴＥＳＴ、Ｂ
ＡＴ　　ＰＡＲＭＩ　　ＰＡＲＭ２である。付加的なパ
ラメータを入れる事もできる。それらは、最初のバッチ
・ファイルがこのプログラムによって処理される時に、
％１乃至％ｎと表わされる置き換え可能パラメータとし
て使用される。

図面において、通常の流れ図の規約が用いられている。

具体的には、ダイヤモンド形のブロックはテスト又は比
較機能等の論理演算を表わし、長方形のブロックは初期
設定、ロード、記憶等のステップの系列中の１ステツプ
を表わす。しかしながら、多くのそのようなステップは
、サブルーチンと呼ばれる一連のステラップによって実
行される。サブルーチンは当業者に周知の方法で主プロ
グラムによって呼び出される。所定のサブルーチンは、
主プログラム中で何回も使用される事があるので、主プ
ログラムの本体中でサブルーチンのステップを繰り返す
よりも、必要な時にサブルーチンを呼び出す方が便利で
ある。図面中で、サブルーチンの呼び出しは、処理ステ
ップの長方形ブロック中で他の図面番号を参照する事に
よって表わされている。

第１図を参照すると、プログラムはブロック１でＤＯ５
から入る事によって開始する。実行される最初の動作は
、ブロック２及び３における。スタック・ポインタとｒ
ＥＸＥｃＪ制御ブロックの初期設定である０次にブロッ
ク４で、ｒｃＯＭＭＡＮＤ、ＣＯＭＪに関するディスク
・ドライブ、バス及びファイル名が見つけられる６次に
ＤＯＳコマンド行を構文解析するためにブロック５で、
第３９図に示す構文解析ルーチンが起動され、そしてビ
デオ表示装置をクリアするために、ブロック６で、第２
３図に示すクリア・スクリーン・ルーチンが起動される
。ブロック７に示すように、バッチ・ファイル・コード
に必要なメモリの大きさが決定され、ブロック８でバッ
チ・ファイル・バッファの開始アドレスが保存される。

ブロック７で行なわれるバッチ・ファイル・バッファに
必要なメモリの大きさの決定は、いつくかの方法で行な
う事ができる。実施例では、その決定はプログラマによ
って行なわれる。プログラマは、バッチ・ファイル処理
プログラム上で実行されるアプリケーション・プログラ
ムのバッチ・ファイル中の最初にロードされるバッチ・
ファイルの名前とバッファの大きさをコーディングする
。それらのパラメータはＤＯ８によってコマンド行から
バッチ・ファイル処理プログラムに渡され、上記プログ
ラムはバッチ・ファイル・バッファの開始アドレスを計
算し、この開始アドレスはブロック８で保存される。ま
たアプリケーション・プログラムの末端ユーザがそれら
のパラメータをコマンド行にキー人力する事も可能であ
るが、末端ユーザをそのような作業に関与されるのは好
ましくないので、これはより好ましくない方式である。

また。

これらのステップは、バッチ・ファイル・バッファの大
きさをバッチ・ファイル処理プログラム中に固定的にコ
ーディングする事によって達成する事もできる。この場
合、バッチ・ファイル処理プログラムを書くプログラマ
が、許されるバッチ・ファイル・バッファの最大の大き
さを決定しなければならない。この方式の非柔軟性は一
見して明らかであろう。もう１つの方式は、必要なバッ
チ・ファイル・バッファの大きさを動的に決定する事で
ある。この場合、ロードされる特定のバッチ・ファイル
の大きさに基いて、必要なバッファの大きさを決定する
ために、バッチ・ファイル処理プログラムはそのバッチ
・ファイルのディレクトリ記入項目を読取る事になるで
あろう。

流れ図のこの時点で、パラメータ１が入力されているか
どうかに関して、ブロック９で判定が行なわれる。もし
そうであれば、判定ブロック１０で、パラメータ１が１
文字か否かの判定が行なわれる。もしそれらの判定結果
のいずれかが否定的であれば、流れ図は第２４図に進む
、第２４１！Ｉにおいて、エラー・メツセージが表示さ
れ、プログラムは第３図にジャンプする。しかしながら
、ブロック９及び１０による判定の両者が肯定的であれ
ば、流れ図は第２図に進む。

第２図の判定ブロック１１で、パラメータ１がゼロかど
うかテストされる。もしそうであれば、流れ図は第２４
図に進む、逆に、パラメータ１がゼロに等しくなければ
、ブロック１２において。

バッファ・サイズがコード・サイズに加算される。

次にブロック１３で、メモリの残りがｒＳＥＴＢＬＯＣ
ＫＪ　ＤＯ８機能を用いて解放され、ブロック１４でバ
ッチ・ファイル・バッファの大きさが保存される１次に
判定ブロック１５で、パラメータ２が入力されたかどう
かの判定が行なわれる。

もしそうであれば、判定ブロック１６で、バッチ・ファ
イル名が有効か者かについて判定が行なわれる。これは
ファイル名の最後の４文字をｒ、　ＢＡＴ」と比較する
事によって行なわれる。もし判定ブロック１５又は１６
のいずれかの結果が否定的であれば、流れ図は第２４図
に進む。両者が肯定的であれば、ブロック１７で、バッ
チ・ファイル名を初期設定するために第３０図に示すサ
ブルーチンが起動される０次にブロック１８で、最初の
バッチ・ファイルをメモリにロードするために第３２図
のルーチンが起動される。パラメータ０の情報は、ブロ
ック１９で保存され、次に流れ図は第３図に進む。

ブロック２０で、第１０図のルーチン（用いて、第２図
からの全てのパラメータは左に２パラメ一タ分シフトさ
れる６次にブロック２１で、保存されたパラメータ０の
情報が回復される６次に、ブロック２２で、ｒｓＩＪレ
ジスタ及び次論理行ポインタが初期設定される。そして
流れ図は第４図に進む。

第４図はバッチ・ファイルを処理するループを開始させ
る。このループは、ファイルの終端（ＥＯＦ）に到達し
たか否かについて判定ブロック２３で判定する事によっ
て最終的に脱出できる。しかしながら最初、この判定結
果は否定的である。

そしてブロック２４で第３０図に示すサブルーチンを起
動する事によって、次のバッチ・コマンド行がセット・
アップされる。バッチ・コマンド行は最初に、それがラ
ベルかどうか、そしてもしそうでなければ、それが空行
かどうかが判定ブロック２５及び２６でテストされる。

もしこれらのテストのいずれかが肯定的であれば、プロ
グラムは判定ブロック２３に戻り、再びＥＯＦ条件につ
いてテストされる。バッチ・コマンド行がラベルでも空
行でもないと仮定すると、ブロック２７で。

コマンド長を得るために第４０図に示す構文解析ルーチ
ンが起動される０次にブロック２８で「ＥＣＨＯＪスイ
ッチがオンかどうかを判定するテストが行なわれる。も
しそうであれば、ブロック２９でコマンドが表示され、
さもなければ表示されない０次にブロック３０で、コマ
ンド・テーブルをサーチするための準備が行なわれる６
次に判定ブロック３１でコマンドが見い出されたか否か
の判定が行なわれる。もしコマンドが見つかれば。

第７図、第９図、第１１図〜第１８図、第２０図に示す
適当なコマンド処理ルーチンに制御が与えられる。もし
そうでなければ、流れ図は第５図に進む。

第５図に示すプログラム部分は、一連のテストである。

最初のブロック３２では、コマンド名の中にピリオド「
、」が存在するか否かが判定される。以前に述べたよう
に、これは実施例における内部的処理のための要求であ
る。もしコマンド名にピリオドが含まれていなければ、
第２コマンド処理プログラムのための準備を行なうルー
チンが起動され、流れ図は第８図へ進む、しかし、ピリ
オドがコマンド名の中に存在していると仮定すると、次
にブロック３４でコマンド名がファイル・エクステンシ
ョンｒ、ＥＸＥＪを有するか否かが判定される。そうで
あれば、流れ図は第７図へ進む、もしそうでなければコ
マンド名がファイル・エクステンションｒ、ＢＡＴＪを
含むか否かがブロック３５でテストされる。もしそれが
含まれていれば流れ図は第６図へ行く、含まれていなけ
ればブロック３６で、コマンド名がファイル・エクステ
ンションｒ、ＣＯＭＪを有するか否かが判定される。も
しそうでなければ、ブロック３３で第２コマンド処理プ
ログラムのための準備が行なわれ、それが含まれていれ
ば流れ図は第７図に進む。

最初に、コマンド・ファイルがテストされ、エクステン
ションｒ、ＢＡＴＪを有する事が見い出されたと仮定す
ると、第６図に示すブロック３８でバッチ・ファイル名
が初期設定される。次にブロック３８で、パラメータが
コマンド行に移動される。ブロック３９で、コマンド・
パラメータを構文解析するために第３９図の構文解析ル
ーチンが起動される０次にブロック４０で、第３２図に
示すルーチンが起動され、新しいバッチ・ファイルがロ
ードされる。この時点で１判定ブロック４１において、
ロード・エラーが起きたか否かが判定される。もしエラ
ーが発生していれば、ブロック４２でｒロード」エラー
・メツセージが表示され、流れ図は第３図に戻る。もし
そうでなければ、流れ図は第４図に戻り、ファイル終了
（Ｅ　ＯＦ）のテストが再び行なわれる。この時、ＥＯ
Ｆが見つかれば、流れ図は第３図に戻る。

第３図に戻って、もしブロック４２で「ロード」エラー
・メツセージが表示されていれば、ブロック４３で第３
８図に示すルーチンが起動され、ＰＡＵＳＥメツセージ
を出し、プログラムはキー・ストロークを待機する。キ
ー・ストロークが検出されると、ブロック４４で、第３
３図に示すルーチンが起動され、フル・スクリーン処理
プログラム（ＦＳＰ）及び索引順次アクセス法（ＩＳＡ
Ｍ）がアンロードされる。第４図において判定ブロック
２３でＥＯＦ条件が検出された時にも同じ事が起きる０
次にブロック４５で、ビデオ・カーソルをオンにするた
めに、第３６図に示すルーチンが起動され、そしてブロ
ック４６でＤＯ８に制御が戻される。

第５図のブロック３４に戻り、ファイルがエクステンシ
ーンｒ、ＥＸＥＪを持っているとすると。

処理は第７図に進む。同じ事は、ファイルがエクステン
ションｒ、ＣＯＭＪを有している時にも起きる。第５図
から第７図に示す流れ図への入口はブロック４９にあり
、そこでファイル名及びフィールドが第３０図のルーチ
ンを呼び出す事によって更新される６次にブロック５０
で、第４０図に示すルーチンを呼び出す事によってＥＸ
ＥＣパラメータ・ブロックが更新される。ファイルは、
ブロック５１で、それが特定のプログラムかどうかを判
定するためにテストされる。具体的には、このプログラ
ムは、スクリーンをクリアし、「処理中」のメツセージ
を表示するためのコードを含む。

アクセス法ローダ−・プログラムである。このプログラ
ムは本発明によるバッチ処理プログラムに密接な関係が
あるわけではないが、実施例では単に便宜のために使用
されている。ブロック５１のテストが肯定的であれば、
ファイルは次にブロック５２でｒＩＪパラメータをテス
トされる。「工」パラメータは「処理中（Ｉｎ　　Ｐｒ
ｏｃｅｓｓ）Ｊメツセージが表示されるべきであるとい
う標識である。もしｒＩＪパラメータが見つかれば、ブ
ロック５３でスクリーン上に「処理中・・・お待ち下さ
い（ＰＲＯＣＥＳＳＩＮＧ・・・ＰＬＥＡＳＥ　ＷＡＩ
Ｔ）Ｊのメツセージが表示され、処理は第４図に戻る。

一方、もしブロック５１又は５２のテスト結果が否定的
であれば、ブロック５４でファイルがＣＯＭＭＡＮＤ、
００Ｍプログラムかどうかがテストされる。もしＣＯＭ
ＭＡＮＤ、００Ｍプログラムであれば、ブロック５５で
コマンド・ポインタが初期設定され、流れ図は第８図に
進む。

しかしながら、ＣＯＭＭＡＮＤ、００Ｍプログラムでは
なかった場合、ブロック５６で、要求されたプログラム
がロードされ実行される。要求されたプログラムが実行
された時、ブロック５７で、処理エラーが検出されたか
どうかのテストが行なわれ、もし何の処理エラーも検出
されなければ。

処理は第４図に戻る。一方、もしエラーが検出されたな
らば、エラー・メツセージを表示するためにプログラム
は第２４図のルーチンにジャンプする。

再び第５図に戻ると、コマンド名の中にピリオド「、」
が含まれていないか又は、エクステンシｘンｒ、ｃＯＭ
Ｊ、ｒ、ＥＸＥＪもしくは「、ＢＡＴＪを有していない
ならば、ブロック３３で。

第２コマンド処理プログラムの準備が行なわれる。

ブロック３３から処理は第８図に進む、第８図へは第７
図のブロック５５からも入る事ができる。

前述のように、内部的な処理されない全てのＤＯＳバッ
チ・コマンドは第２コマンド処理プログラムを起動する
事によって実行される。ＤＯ８のＥＸＥＣ機能は、ＣＯ
ＭＭＡＮＤ、００Ｍプログラムの第２のコピーをロード
して実行させるた°めに使われる。ＤＯＳバッチ・コマ
ンドはＣＯＭＭＡＮＤ、ＣＯＭに渡され、処理が終了す
ると、制御はバッチ処理プログラムに戻される。この事
は第８図に示されている。ここで、ブロック５８におい
て、ファイルは「／Ｃ」のパラメータが見い出されるか
否かが検査される。これは制御をバッチ処理プログラム
に戻すパラメータである。もし「／Ｃ」が見つからなけ
れば、ブロック５９で、そのバッチ・コマンドが表示さ
れ、続いてブロック６０で「無効な第２コマンド処理要
求です（工ＮＶＡＬＩＤ　　５ＥＣＯＮＤＡＲＹ　　Ｃ
ＯＭＭＡＮＤ　　ＰＲＯＣＥＳＳ　　ＲＥＱＵＥＳＴ）
Ｊ　というエラー・メツセージが表示され、この時点で
処理は第３図に戻る。しかしｒ／ＣＩパラメータが見つ
かると、ブロック６１で「残りのデータがコマンド行に
移動され、ブロック６２で「／Ｃ」パラメータがコマン
ド行に挿入される０次にブロック６３で、第３３図に示
すサブルーチンを起動する事によって、第２コマンド処
理プログラムがロードされ実行される。実行が終了する
と、ブロック６４で、処理エラーが検出されたか否かが
テストされる。もしエラーが検出されると、「第２コマ
ンド処理・プログラムの実行中にエラーが発生しました
（ＥＲＲＯＲ０ＣＣＵＲＲＥＤ　　ＷＨＩ’　　ＬＥ　
　ＥＸＥＣＵＴＩＮＧ　　ＳＥＣＯＮＤＡＲＹＣＯＭＭ
ＡＮＤ　　ＰＲＯＣＥＳＳＯＲ）Ｊ　というエラー・メ
ツセージがブロック６５で準備され、処理は第２４図に
移る。もしエラーが検出されなければ、処理は第４図に
戻る。

これでバッチ処理プログラムの主モジュールの説明を終
了し、以下種々のコマンド処理ルーチンについて説明す
る。前述の通り、第４図の判定ブロック３１から、適当
なコマンド処理ルーチンが起動される。コマンド処理ル
ーチンの最初のものは第９図に示す５ＨＩＦＴコマンド
処理ルーチンである。これは単一のブロック６６のみか
ら成り、そこでパラメータは左にシフトされる。しかし
ながら、この処理は第１０図に示すシフト・サブルーチ
ンを起動する事によって実行される。

第１０図で、シフト・サブルーチンの最初のスチップは
、ブロック６７でパラメータ・テーブルを上に１要素シ
フトする事である６次にブロック６８で、パラメータを
計数値が更新される。その結果得られたパラメータ計数
値は、ブロック６９で、それが８という計数値を越えた
か否かがテストされる。もしその通りであれば、ブロッ
ク７０でバッチ・コマンドから次のパラメータが見つれ
られ、そしてブロック７１で第３９図に示すサブルーチ
ンを呼び出す事によってパラメータ・テーブルが更新さ
れる。この時点で、リターン・ブロック７２に示される
ようにシフト・サブルーチンを呼び出したプログラムに
戻る。もしブロック６９のテストが否定的であれば、同
様の結果が得られる。

ディレクトリ・コマンド処理ルーチンは第１１図に示さ
れている。ＤＯＳディレクトリ・コマンドには数種のも
のが存在する。それらはディレクトリ作成コマンド（Ｍ
Ｄ）　、ディレクトリ変更コマンド（ＣＤ）及びディレ
クトリ削除コマンド（ＲＤ）である、コマンドに続くデ
ータは、Ｄ。

Ｓ機能３９Ｈ１３ＡＨ及び３ＢＨを用いてサブディレク
トリを変更するようにＤＯ８に要求を出すために使われ
る。どのコマンドｒが与えられたかに依存して、ブロッ
ク７３．７４及び７５に示すようにそのコマンドに関す
る初期設定が行なわれる。

初期設定が行なわれると、それらのコマンドの各々に関
する処理は同一である。次にブロック７６で、第４０図
のサブルーチンを呼び出す事によって、コマンドの残り
が見つけられる。次にブロック７７で呼び出される第３
０図のサブルーチンはデータを名前フィールドに移動さ
せる０次に、ブロック７８で、ＩＮＴ２１の機能呼び出
し機構（前掲のＤｉｓｋ　Ｏｐｅｒａｔｉｎｇ　５ｙｓ
ｔａ＋ｍ、ＴｅｃｈｎｉｃａｌＲｅｆｅｒｅｎｃｅ参照
）を用いる事によってコマンドが実行される。コマンド
が実行された時、ブロック７９で、処理エラーが起きた
か否かを判定するテストが行なわれる。もしエラーが存
在すれば、ブロック８ｏで、第２７図のサブルーチンを
呼び出す事によってエラー・メツセージが表示され、処
理はバッチ・ファイル中の次のコマンドを探すために第
４図に戻る。エラーがなければ、処理は即座に第４図に
戻る。

ＩＦ　　コマンド処理ルーチンは第１２図及び第１３図
に示されている。この処理はＩＦコマンドの方向（肯定
又は否定）を判定する。ＩＦコマンドがストリングの等
しさ、ファイルの存在の検査又はエラー・レベルの検査
のいずれのテストを行なうかを見るために、比較が行な
われる。この処理はまた、テストされる条件が真か又は
偽きも判定している。ＩＦコマンドの方向及びテストさ
れる条件に依存して、次論理行ポインタは、ＴＨＥＮコ
マンドに位置付けられるか又はＥＬＳＥコマンドに位置
付けられる。ブロック８１の最初のステップは、「方向
」機能を背定にセットする事である０次にブロック８２
で、第１４図に示すサブルーチンを起動する事によって
最初のパラメータが取得される。これはそれ自身サブル
ーチン呼び出しから成る短かいサブルーチンである。第
１４図に示すように、ブロック８３の最初のステップは
、第４０図のサブルーチンを起動する事による次のトー
クンの走査である１次にブロック８４で、再び第４０図
のサブルーチンを用いてパラメータの終端まで走査が行
なわれる。リターン・ブロック８５で処理は第１２図の
ブロック８２に戻る。

この時、一連のテストが行なわれる。最初に、ブロック
８６で、パラメータ長が３に等しいかどうかテストされ
る８等しくなければ、ブロック８７でパラメータ長が５
に等しいかどうかがテストされる。もし等しくなければ
ブロック８８でパラメータ長が１０に等しいかどうかが
テストされる。

これも等しくなければ、処理はストリング−比較動作の
ために次のトークンを取得するためブロック８９に進む
。これは再び第１４図に示すサブルーチンを呼び出す事
によって行なわれる。次にブロック９０で、ストリング
が等しいかどうかが比較される。もしそれらが等しけれ
ば、処理は第１３図のブロック９１に進み、さもなけれ
ば処理は第１３図のブロック９２に進む。

第１３図のブロック９１で、「方向」機能は「真」と排
他的ＯＲされ、一方ブロック９２では「偽」と排他的Ｏ
Ｒされる１両者のブロックの結果は、ＩＦ条件が満足さ
れたか否かを判定するためにブロック９３でテストされ
る。もし条件が成立しなければ、処理は直接第４図に飛
び、次のコマンドを待機する。一方、テストの結果が肯
定的であれば、処理はブロック９４に進み、再び第１４
図のサブルーチンを起動して、次のコマンドを取得する
６次にブロック９５でトークンの計数値がゼロかどうか
テストされる。ゼロであれば、処理はブロック９４にル
ープ・バックする。ゼロならば、ブロック９６で法論的
コマンド行がセットされ、その後第４図に戻る。

第１２図に戻り、ブロック８６のテスト結果が肯定的で
あったと仮定する。この場合、ブロック９７で、トーク
ンがｒＮＯＴＪと比較される。もしこの比較結果が否定
的であれば、そのパラメータは、ストリングでなければ
ならず、処理はブロック８９に進む。一方比較結果が背
定的であれば、ブロック９８で否定の「方向」がセット
される。

次にブロック９９で再び第１４図のサブルーチンを起動
する事によって次のトークンが取得される。

この処理は次にブロック８７に進む。

この時ブロック８７で行なわれるテスト結果が背定的で
あったと仮定する。この場合、ブロック１００で、トー
クンはｒＥＸＩｓＴＪと比較される。もし比較結果が不
一致であれば、処理は再びブロック８９に行き、ストリ
ング比較のために次のトークンを取得する。しかしｒＥ
ＸＩｓＴＪの比較結果が肯定的であれば、ブロック１０
１で、次のトークンが取得される。次にブロック１０２
で、第３４図に示すサブルーチンが起動され、ファイル
の存在が検査される。もしファイルが存在するとブロッ
ク１０３で判定されれば、処理は第１３図のブロック９
１に進む、さもなければブロック９２に進む。

ブロック８８に戻って、長さが１０に等しかったと仮定
する。この場合、ブロック１０４で「ＥＲＲＯＲＬＥＶ
ＥＬＪとの比較が行なわれる。比較結果が不一致であれ
ば、処理はブロック８９に進み、ストリング比較のため
に次のトークンが取り出される。さもなければ、ブロッ
ク１０５で次のトークンが取り出される。このトークン
はブロック１０６で数字かどうかが判定される。もしそ
うでなければ、ブロック１０７でｒＩＦコマンド構文エ
ラー（ＩＦ　　ＣＯＭＭＡＮＤ　　５ＹＮＴＡＸ　　Ｅ
ＲＲＯＲ）Ｊのエラー・メツセージが表示され、処理は
第３図に戻り、ＤｏＳへ制御を戻す準備が行なわれる。

もし、数字であればブロック１０８で、パラメータが「
エラーレベル」に等しいかどうかがテストされる。もし
等しければ、処理は第１３図のブロック９１に進み、さ
もなければブロック９２に進む。

ＧＯＴＯコマンド処理ルーチンは、第１５図に示されて
いる。その目的はＧＯＴＯラベル及びその長さを見い出
すことである。処理ルーチンは、バッチ・ファイル・バ
ッファの先頭でスタートし、ＧＯＴＯラベルに等しいタ
グを求めて走査する。

それが見つかれば、次論理行ポインタは、そのラベルに
セットされ、従ってその地点から実行が再開される。第
１５図に示すように、最初のステップは、ブロック１０
９で行なわれる。走査の長さを計算するステップである
。次にブロック１１０で、ラベル名が分離される。この
次にブロック１１１で、そのラベルを探すため、バッチ
・ファイル・バッファの探索が行なわれる。ブロック１
１２では、バッファの終端に到達したか否かがテストさ
れる。もしそうであれば、ブロック１１３で「ラベルが
見つかりませんでした（ＬＡＢＥＬＮＯＴ　　ＦＯＵＮ
Ｄ）Ｊというエラー・メツセージが表示され、処理は第
３図に戻り、ＤｏＳへ制御を戻す準備が行なわれる。し
かしながら、もし判定ブロック１１２におけるテストの
結果が否定的であれば、ブロック１１４でラベルが見つ
かったか否かがテストされる。見つからなければ、プロ
グラムはブロック１１１ヘループ・バックする。

見つかれば、ブロック１１５で次論理行ポインタが更新
され、処理は第４図に進んで、次のコマンドを待機する
。

ＥＣＨＯコマンド処理ルーチンは第１６図に示されてい
る。その目的は最初のパラメータが［ＯＮ」又はｒｏＦ
ＦＪか否かを判定する事である。

もしそうであれば、それに従ってＥＣＨＯスイッチがセ
ットされる。もし最初のワードが「ＯＮ」又はｒｏＦＦ
Ｊではないとすると、ＥＣＨＯコマンドの先の行全体が
印刷される。第１６図に示すように、最初ブロック１１
６で、パラメータの存在がテストされる。何も存在しな
ければ、ブロック１１７で空行が表示され、処理は即座
に第４図に行き、次のコマンドを待機する。もしパラメ
ータが存在すれば、一連のテストが行なわれる。その最
初のものは、ブロック１１８における、パラメータ長が
２に等しいか否かのテストである。もしそうであれば、
パラメータはブロック１１９でｒｏＮＪ　と比較される
。もしパラメータがｒＯＮＪであれば、ブロック１２０
でｒＥＣＨＯＪスイッチがセットされ、ブロック１２１
でＥＣＨＯ行が表示される。もしブロック１１９でパラ
メータが「ＯＮ」でないと判定されたならば、ＥＣＨＯ
スイッチはセットされず、処理は直接ブロック１２１に
進む。

ブロック１１８におけるテストが否定的な結果であれば
、次にブロック１２２で、パラメータ長が３に等しいか
否かがテストされる。もしそうであればパラメータはブ
ロック１２３でｒｏ　Ｆ　ＦＪと比較される。もしパラ
メータがｒＯＦＦＪであれば、ブロック１２４でＥＣＨ
Ｏスイッチがオフにセットされる。そうでなければ処理
は直接ブロック１２１に進む、ブロック１２４でＥＣＨ
Ｏスイッチがオフにセットされた後、ブロック１２５で
、以前にＥＣＨＯがオンであったかどうかが判定される
。もしそうであれば処理はブロック１２１に進む。また
そうでなければ処理は第４図に進み、次のコマンドを待
機する。ブロック１２１でＥＣＨＯ行を表示した後、処
理は第４図に移り。

次のコマンドを待機する。

ＥＲＡＳＥコマンド処理ルーチンは第１７図に示されて
いる。その目的はディスクからデータ又はプログラムの
ファイルを削除する事である。第１７図に示すように、
ブロック１２６における最初のステップは、削除される
べきファイル名を準備する事である０次にブロック１２
７で、ファイルを削除するためにＤＯ８機能呼び出しＩ
ＮＴ２１が行なわれる。それが終了すると、エラーが検
出されたかどうかがブロック１２８で判定される。

もしエラーがあれば、処理は第２４図に進んでエラーメ
ツセージを表示し、その後第３図に進んでＤＯ８に制御
を戻す準備をする。一方、エラーが検出されなければ、
処理は第４図に進んで次のコマンドを待機する。

ＰＡＵＳＥコマンド処理ルーチンは第１８図に示されて
いる。その目的はメツセージ「続行するためにキーをど
れか押して下さい（Ｓｔｒｉｋａ　ａ　ｋｅｙｔｏ　ｃ
ｏｎｔｉｎｕｅ・・・）」を表示し１次のキーストロー
クを待う事である。第１８図に示すように、ＰＡＵＳＥ
コマンド処理ルーチンは１つだけのステップから成って
いる。このブロック１２９は上記メツセージを出すもの
である。このステップは第１９図に示すＰＡＵＳＥサブ
ルーチンによって実行される。

第１９図に示すＰＡＵＳＥサブルーチンはそれ自身、一
連のサブルーチン呼び出しである。その最初のもの、ブ
ロック１３０は第２７図に示すサブルーチンを起動する
事によってメツセージを表示する０次にブロック１３１
で、第２６図示すサブルーチンを起動する事によってカ
ーソルをターン・オンする。ブロック１３２で、第２８
図に示すサブルーチンが起動され、キーストロークを待
機する。次にブロック１３３で、ＤＯ８機能呼び出しＩ
ＮＴ２１を用いて復帰（ＣＲ）及び改行（ＬＦ）の記号
が表示装置に送られる。この時点で、処理は第１８図の
ブロック１２９′に戻る。このようにしてＰＡＵＳＥコ
マンドが終了し、処理は次のコマンドを待機するために
第４図に戻る。

ＲＥＮＡＭＥコマンド処理ルーチンは第２０図に示され
ている。その目的はファイルの名前を変更する事である
。ブロック１３５の最初のステップは古いファイル名を
見つけるステップであり、次のブロック１３６は新しい
ファイル名を見つけるものである。ブロック１３７で、
ファイルの名前を変更するためにＤＯ８機能呼び出しＩ
ＮＴ２１が行なわ九る。それが終了すると、ブロック１
３８で、エラーが検出されたか否かがテストされる。も
しエラーが検出されていれば、処理は第２４図に進み、
そうでなければ処理は第４図に進んで、バッチ・ファイ
ル中の次のコマンドを待機する。

第２１図、第２２図、及び第２３図は共通のスクリーン
処理ルーチンである。第２１図のルーチンはブロック１
３９で示される。単一のステップより成っている。これ
は第２３図のクリア・スクリーン処理を起動する。次に
処理は第４図に戻り、バッチ・ファイル中の次のコマン
ドを待機する。

第２２図に示すサブルーチンも、ブロック１４０で第２
３図のクリア・スクリーン・ルーチンを呼び出すが、ブ
ロック１４１で、「処理中（ＩｎＰｒｏｃｅｓｓ）　Ｊ
というメツセージを表示する。ブロック１４１の後、ボ
ックス１４２に示すように、そのサブルーチンを呼び出
したプログラムに処理が戻る。

第２４図は、処理を実行している時に検出されたエラー
に関するテストに関連して以前に何回か説明されている
。もしエラーが検出されていると、処理は常に第２４図
のルーチンに行き、ブロック１４３でエラー・メツセー
ジが表示される０次に処理は第３図に行き、００Ｓに制
御を戻す準備が行なわれる。

第２５図及び第２６図は共通のカーソル・ルーチンを示
す、第２７図及び第２８図は共通の入力／出力ルーチン
を示す。これらの図の意味は図から明らかなので、特に
説明はしない。

第２９図に示すサブルーチンは初期設定処理の間に第２
図のブロック１７によって呼び出される。

この処理の最初のステップは、ブロック１４３の。

ファイル名フィールドを空白にするステップである０次
にブロック１４４で１次のファイル名の文字が取得され
る。この文字はブロック１４５で。

区切り文字か否かがテストされる。もし区切り文字でな
ければ、再びそれはブロック１４６で、１％」文字が否
かがテストされる。１％」はバッチ・コマンド中の変数
を示す。もし、それがｒ％Ｊ文字であれば、第３１図に
示すサブルーチンを起動する事によって、それがパラメ
ータで置換される。次にブロック１４８で、文字がファ
イル名フィールドに置かれる。同じ事は、ブロック１４
６でのテスト結果が否定的であった場合にも起きる。

いずれの場合にも、次のファイル名文字を得るために、
ルーチンはブロック１４４にループ・パックする。再び
、ブロック１４５で文字がテストされ、それが区切り文
字か否かが判定される。もしそうであれば、ブロック１
４９で、ファイル名フィールドにＡＳＳＩＩＺストリン
グが形成される。

ＡＳＣＩ工ｚストリングは、ＡＳＣＩ　ＩＸトリングが
２進数ゼロ（ＯＯ）のバイトで終端したものである０次
にブロック１５０で示されるように、処理は第２図のブ
ロック１７に戻る。　。

第３０図に示すサブルーチンは、第４図のブロック２４
から呼び出される。これは次のバッチ・コマンド行の準
備を行なう、このサブルーチンの最初のステップはブロ
ック１５１に示すように、バッチ・バッファ中の次のコ
マンドを見つける事である０次に、ブロック１５２で、
最初又は次の文字がバッチ・ファイル・バッファから取
り出される。この文字はブロック１５３で、置換可能な
変数を示す１％」文字か否かが判定される。もしそうで
あれば、ブロック１５４で変数は置換され、処理はブロ
ック１５２に戻る。もし文字が１％」文字でなければ、
ブロック１５５で文字はＥＸＥＣＭＤ　　ＬＩＮフィー
ルドに記憶される。次に行の終りかどうかがテストされ
、終りでなければ処理はブロック１５２にループ・バッ
クする８行の終りであれば、ブロック１５７に示すよう
にサブルーチンのリターンが行なわれる。

第３１図に示すサブルーチンは、第３０図のブロック１
５４及び第２９図のブロック１４７から呼び出される。

このサブルーチンは、１％」文字を置換するパラメータ
の番号を取得する。この手続きは図の内容から明らかな
ので、これ以上は説明しない。

第３２図はバッチ・ファイルをメモリにロードするため
のサブルーチンを示している。このサブルーチンは第２
図のブロック１８及び第６図のブロック４０から呼び出
される。このルーチンの最初のステップは、ブロック１
５８に示すようにファイル名をオープンする事である。

これはＤＯ５機能呼び出しＩＮＴ２１を用いて行なわれ
る。ブロック１５９で、オープン・エラーについてのテ
ストが行なわれる。もしエラーが検出されたならば、サ
ブルーチンはそれが呼び出された主プログラム中の場所
に戻る事によって終了する。そうでなければ、ブロック
１６０でファイルがバッチ・バッファに読取られ、ブロ
ック１６１でファイル名がクローズされる。これらは共
にＤＯ８機能呼び出しＩＮＴ２１を用いて行なわれる０
次に、ブロック１６２で、クローズ・エラーについての
テストが行なわれる。もしエラーがあれば、サブルーチ
ンは終了し、そうでなければブロック１６３で、バッチ
・バッファにおけるオーバーフローがテストされる。も
しオーバーフローが検出されると、処理は第２４図に進
み、エラー・メツセージを表示してから、ＤＯ５へ制御
を戻す準備を行なう、もしバッファのオーバーフローが
検出されなければ、ブロック／６４でバッチ１フアイル
・バッファの終端にマークが付けられる。そしてブロッ
ク１６５でファイル名が％０の置換のために保存される
。ここで処理は、それが呼び出された主プログラム中の
地点に戻る。

第３３図〜第３７図は付加的な共通のサブルーチンを示
している。これらの多くは図からその意味が明白である
。但し、第３４図を参照すると、このサブルーチンの最
初のステップはディスク転送領域（ＤＴＡ）をセットす
る事である。ＤＴＡは一般にバッファとも呼ばれ、旧式
な機能呼び出しの組で用いられる全ての読取り及び書込
みデータを含むためにＤＯＳが使用するメモリ領域であ
る。ＤＴＡについてのより詳細な情報は、前掲のｒＤｉ
ｓｋ　Ｏｐｅｒａｔｉｎｇ　５ｙｓｔｅ＋ｓ、Ｔｅｃｈ
ｎｉｃａｌ　ＲｅｆｅｒｅｎｃｅＪに含まれている。

最後の３つの図は構文解析サブルーチンを示している。

その目的はＤＯＳコマンド行からパラメータ情報のテー
ブルを、プログラム・セグメント接頭部の８０Ｈに形成
する事である。各テーブルの記入項目は、見い出さたれ
パラメータ各々の１バイトの長さ及び２バイトのオフセ
ットを含んでいる。第３９図の構文解析サブルーチンは
例えば第１図のブロック５及び第６図のブロック３９で
呼び出される。また第３９１！ｌのサブルーチンは第１
０図のブロック７１でも呼び出される。第４０図のサブ
ルーチンは、例えば第１４図のブロック　　′８４で呼
び出される。

Ｆ０発明の効果 本発明のバッチ処理プログラムを用いれば、ディスク・
アクセスの回数が減少し、高い効率でバッチ・ファイル
を実行する事ができる。

【図面の簡単な説明】

第１図乃至第８図は本発明の１実施例のバッチ・ファイ
ル処理プログラムの全体的な流れ図を構成する図。 第９図及び第１０図は５ＨＩＦＴコマンド処理ルーチン
の流れ図、 第１１１１！Ｗはディレクトリ・コマンド処理ルーチン
の流れ図。 第１２図及び第１３図はＩＦコマンド処理ルーチンの流
れ図、 第１４図はＩＦコマンド処理ルーチン中で使用されるサ
ブルーチンの流れ図、 第１５図はＧＯＴＯコマンド処理ルーチンの流れ図、 第１６図はＥＣＨＯコマンド処理ルーチンの流れ図、 第１７図はＥＲＡＳＥコマンド処理ルーチンの流れ図、 第１８図及び第１９図はＰＡＵＳＥコマンド処理ルーチ
ンの流れ図、 第２０＠はＲＥＮＡＭＥコマンド処理ルーチンの流れ図
。 第２１図乃至第４０図はバッチ処理プログラム及び種々
のコマンド処理ルーチン中で共通に使用される種々のサ
ブルーチンの流れ図である。 才　１　図 才３Ａ口　　　　才３Ｂ回 第５口 オ　６　回 才　８　回 ケ　：Ｏ図 ｚｌｌ　　日 オ　１３　　日　　　　　才１４図 矛１５　図 ？１Ｂ　　日 矛２１　回　　　　　　　　　才２５日才　２９　図 才　３９　５ａ

Claims (1)

1. 【特許請求の範囲】 処理すべきバッチ・ファイルに必要な大きさのバッチ・
   ファイル・バッファを形成し、 上記バッチ・ファイルを上記バッファにロードし、 上記バッチ・ファイル中に含まれるコマンドを見い出す
   ために、一度に１論理レコードづつ上記バッファ中の上
   記バッチ・ファイルに質問し、上記バッチ・ファイル中
   に見い出されたコマンドのうち少なくとも１つをディス
   ク・アクセスを必要とする事なく処理するために、内部
   のルーチンに制御を渡し、 上記コマンドの処理が終了した時、バッチ・ファイル中
   の他のコマンドを処理するために制御を戻すステップを
   含む バッチ・ファイル処理方法。