COBOLでの使用COMPを持つ変数

Question

私は、COMP Usage節のCOBOL変数がどのように値を格納しているかを理解しようとしています。

VAR14の値が0000として来ているSPOOLで

01 VAR14   PIC S9(5) USAGE COMP. 

    MOVE 12345 TO VAR14 
    DISPLAY VAR14 

以下のように私は1つの例を試してみました。 S9(5) COMPサイズはマニュアルごとに4バイトなので、VAR14は000と表示されます。 以下のようにバイナリ表現：

0000 0000 0000 0000 0011 0000 0011 0100‬ 

は、誰かが出力値0000を理解する上で助けてくださいことはできますか？

おかげ

IBMのエンタープライズ・COBOLで

Answer 1

は、バイナリフィールドを定義する4つの方法があります。COMP。 COMP-4;バイナリ; COMP-5。

これはどうやって起こりますか？ COMPUTATIONALフィールド（略してCOMP、および "すべてのCOMPUTATIONALフィールド"の略）は、 "implementor defined"です。つまり、あるコンパイラではCOMPとは何か、別のコンパイラではCOMPであるか、それとも直接の同等のコンパイラではないかもしれません。

はい、必要に応じてCOMPUTATIONAL、COMPUTATIONAL-4、COMPUTATIONAL-5を記述できます。コンパイラは満足しています。

標準化するために、1985 COBOL標準では、BINARYとPACKED-DECIMALをUSAGEとして導入しました。他のCOBOLコンパイラへの移植性のために、これらはCOMPとCOMP-3（パック10進）フィールドのための最良のUSAGEです。

これらの異なるバイナリフィールドの違いは何ですか？大部分は、なし。 COMP、COMP-4およびBINARYは実際にはコンパイラ内で互いに同義語です（より正確には、COMP-4およびBINARYはCOMPの同義語です）。

「ネイティブバイナリ」としても知られているCOMP-5は異なります。 COBOLには、「10進バイナリ」フィールド（COMPと兄弟）と呼ばれるものがあります。つまり、データはバイナリとして保存されますが、その最大値と最小値は、定義で使用されるPICture句の数と完全な値です。

COMP PIC 9 - can contain zero to nine. 
COMP PIC S99 - (signed) can contain -99 to +99. 
COMP PIC 999 - can contain zero to 999. 

COMP-5は異なります。 COMP-5のために何が起こる

COMP PIC 9 - can contain zero to 65535. 
COMP PIC S99 - (signed) can contain -32768 to +32767. 
COMP PIC 999 - can contain zero to 65535. 

は、画像が（他のバイナリフィールドを持つように）フィールドのサイズを定義するために使用されるが、すべての可能なビット値が有効であることです。

PICtureはどのように定義のサイズに関係していますか？ PIC9〜PIC9（4）はハーフワードサイズのフィールド（2バイト）に格納されます。 PIC 9（5）〜PIC 9（9）は、ワードサイズのフィールド（4バイト）に格納されます。 PIC 9（10）〜PIC 9（18）は、ダブルワードサイズのフィールド（8バイト）に格納されます。

OK、この違い（COMP-5はすべてのビットを使用します、COMPはPICtureの小数点のみを表すことができます）は何が定義されているかに影響しますか？ 「ネイティブバイナリ」は、「非ネイティブ」なんかよりもはるかに良く、明らかに速くはありませんか？

違いは、どのように切り捨てられるかです。また、「ネイティブバイナリ」のような音がしているので、打ち切りのためCOMP & COを使用するよりも一般的に遅くなります。

COMPはPICtureの小数点以下を切り捨てます。 COMP-5はフィールドのサイズに切り詰められます。

（名前はちょうどデモのために、しかわかりやすい名前を使用）考えてみましょう：

01 PROGA COMP PIC 9(4). 
01 PROGB COMP-5 PIC 9(5). 
01 PROGC BINARY PIC 9(4) VALUE 9999. 

ADD PROGC TO PROGA 
ADD PROGC TO PROGB 

PROGAは9999の最大値を持っていることを思い出し、および19998は、フィールドの既存のサイズ内に簡単に収まることを指摘し、コンパイラは加算を行い、10進値に切り捨てて、すべてのインプレースで切り捨てることができます。

PROGBの最大値は65535で、元のフィールドに十分な余裕があり、65535を追加することができます。コンパイラは元のサイズの2倍の一時フィールドを生成する必要があります。加算し、元の最大値に切り捨てて元のフィールドに戻します。これら二つで、それが9999未満であることから、まだ（明らかに）ADDが所定の位置で行うことを可能にするが、PROGBに1を加えます、PROGAに1を加えること

ADD 1 TO PROGA 
ADD 1 TO PROGB 

注まだは、拡張が必要になりますPROGBはすでに65535の値を持っている可能性があるので、コンパイラはこれを許さなければなりません。

DISPLAYに来ています。 COMP PIC S9（5）があり、10桁の出力が得られます。どうして？ OK、サイズは4バイトです。しかし、それは-99999から+99999の範囲で5桁の出力を得るはずです。あなたのフィールドが代わりにCOMP-5 PIC S9（5）だったというふりをしましょう。

COMP-5では、すべてのビットが有効です。署名付きフィールドの場合、フルワード/ワードの範囲は-2,147,483,648から+2,147,483,647です。それは10桁です。あなたの出力にある10桁の数字に一致します。何が起こった？

コンパイラオプションTRUNC。コンパイラオプションTRUNC（BIN）を使用すると、すべてのCOMP/COMP-4/BINARYフィールドはCOMP-5として扱われます。物語の終わり。 TRUNC（BIN）は、あなた、プロジェクト、またはサイトのデフォルトとして選択されたものです。これは必ずしも良い選択ではありません。

コンパイラオプションTRUNCのその他の値は、COMP/COMP-4/BINARYの「通常の」切り捨てと、その時点で最適な（パフォーマンスの）OPTです。

TRUNC（OPT）がプログラマに契約を課すことは強くないことに注意してください。 「COMP/COMP-4/BINARYフィールドの値がPICtureに適合しないようにすることはできませんし、絶対に考慮しないこともありません。終わりの話、そして私からの泣き声はありません。

どのように動作するかを調査する目的を除いて、TRUNC設定を変更してください。あなたがすると、あなたは物事を壊すことができ、それは非常に、非常に微妙な休憩になることができます。

私の助言：TRUNC（BIN）は、（誰かが決めた、選択肢がない）場合を除き、使用しないでください。サイトが契約を怖がっている場合はTRUNC（STD）を使用します。 TRUNC（OPT）は、サイトが契約に慣れている場合に使用します。

個々のフィールド定義に必要なCOMP-5を使用します。あなたはどこにいる必要がありますか？どの場所でも、範囲がPICtureの「小数値」を超えるバイナリフィールドを持っています。例えば、CICS COMMAREAのサイズと個々の例の大きさを示すフィールドを調べます。 COBOLプログラムのVARCHARホスト・フィールドを調べます。 JAVAやC/C++と通信するデータはそうかもしれません。それ以外の場合は、新しいプログラムの場合は、1985年に最新の状態になっていることを示すBINARYを使用してください。

調査目的でTRUNCを設定します。

 CBL TRUNC(STD) 
     ID (or IDENTIFICATION) DIVISION. 

コンパイラオプションも、コンパイルのためのJCLでPARMステートメントによって設定することができますが、あなたはそれへのアクセス権を持っていないかもしれません。 CBLは、PARMに設定された値を上書きします。 CBL（PROCESSとも呼ばれます）の使用を妨げるインストールオプションがあります。個々のオプションは、インストール時に「固定」することもできます。あなたのサイトがTRUNCを修正した場合、またはCBLを阻止した場合、これらのことを試すことはできません。