1

Cobol について聞いたことがあり、見るのが楽しいと思ったので、Cobol を学ぼうとしています。私は MicroFocus Cobol に出くわしましたが、それがこの投稿に関連しているかどうかはよくわかりませんが、Visual Studio で書くのが好きなので、それを試して学ぶのに十分なインセンティブでした。

私はそれについて多くのことを読んでおり、ドキュメントと例に従おうとしています。これまでのところ、コンソールへのユーザー入力と出力が機能しているので、ファイル IO を試してみることにしました。一度に「レコード」を読み込んでいたときは問題ありませんでしたが、「レコード」が間違った専門用語である可能性があることに気付きました。私はしばらくの間プログラミングをしていますが、cobol の極端な初心者です。

私は以前に書いた C++ プログラムを持っています。これは単に .csv ファイルを取得して解析し、ユーザーが望む列でデータを並べ替えます。cobolで同じことをするのは難しくないと思いました。どうやら私はこの点で判断を誤ったようです。

Windows でメモ帳 ++ を使用して編集した、test.csv というファイルがあります。

4001942600,140,4
4001942700,141,3
4001944000,142,2

このデータは、GEOID、SUMLEV、STATE というタイトルの列ヘッダーを持つ米国の国勢調査からのものです。その時点でそれを読み込んでから他のデータを読み込む方法がわからなかったので、ヘッダー行を削除しました。誰でも...

Visual Studio 2015 の Windows 7 Pro 64 ビットで、Micro Focus を使用し、ステップ デバッグを行うと、データの最初の行を含むインレコードを確認できます。unstring はその実行で正常に動作しますが、次にプログラムが「ループ」するときにデバッグをステップ実行し、インレコードを表示して、新しいデータが含まれていることを確認できますが、ウォッチ要素を展開すると、ウォッチの表示は次のようになります。 

        REC-COUNTER 002 PIC 9(3) 
+       IN-RECORD   {Length = 42} : "40019427004001942700             000      "    GROUP
-       GEOID   {Length = 3}    PIC 9(10) 
        GEOID(1)    4001942700  PIC 9(10) 
        GEOID(2)    4001942700  PIC 9(10) 
        GEOID(3)    <Illegal data in numeric field> PIC 9(10) 

-       SUMLEV  {Length = 3}    PIC 9(3) 
        SUMLEV(1)   <Illegal data in numeric field> PIC 9(3) 
        SUMLEV(2)   000 PIC 9(3) 
        SUMLEV(3)   <Illegal data in numeric field> PIC 9(3) 

-       STATE   {Length = 3}    PIC X
        STATE(1)        PIC X
        STATE(2)        PIC X
        STATE(3)        PIC X

そのため、2 回目の Unstring 操作の直前に適切なデータが表示される理由がわかりませんが、unstring が発生した後、誤ったデータが「テーブル」に格納されます。また興味深いのは、3 回目に続行すると、正しいデータが「テーブル」に格納されることです。 

         identification division.
         program-id.endat.
         environment division.
         input-output section.
         file-control.
             select in-file assign to "C:/Users/Shittin Kitten/Google Drive/Embry-Riddle/Spring 2017/CS332/group_project/cobol1/cobol1/test.csv"
                organization is line sequential.
         data division.     
         file section.
         fd in-file.  
         01 in-record.
             05 record-table.
                 10 geoid     occurs 3 times        pic 9(10).
                 10 sumlev   occurs 3 times       pic 9(3).
                 10 state       occurs 3 times       pic X(1).
         working-storage section.
    01 switches.
     05 eof-switch pic X value "N".
  *  declaring a local variable for counting
    01 rec-counter pic 9(3).
  *  Defining constants for new line and carraige return. \n \r DNE in cobol!
    78 NL  value X"0A".
    78 CR  value X"0D".
    78 TAB value X"09".

  ******** Start of Program ******
   000-main.
     open input in-file.
       perform 
       perform 200-process-records
         until eof-switch = "Y".
       close in-file;
     stop run.
  *********** End of Program ************

  ******** Start of Paragraph  2 *********
   200-process-records.
       read in-file into in-record
         at end move "Y" to eof-switch
         not at end compute rec-counter = rec-counter + 1;
       end-read.
       Unstring in-record delimited by "," into 
           geoid in record-table(rec-counter), 
           sumlev in record-table(rec-counter), 
           state in record-table(rec-counter).

     display "GEOID  " & TAB &">> " & TAB & geoid of record-table(rec-counter).
     display "SUMLEV  >> " & TAB & sumlev of record-table(rec-counter).
     display "STATE  "  & TAB &">> " & TAB & state of record-table(rec-counter) & NL.
  ************* End of Paragraph 2  **************

読み取り操作後に実際にデータを表示できるのに、テーブルに格納されていない理由について非常に混乱しています。テーブルの宣言をpic 9（ある程度の長さ）にも変更しようとしましたが、結果は変わりますが、これについて何が得られていないのかを特定できないようです。

4

2 に答える 2

1

まだ把握していないことがいくつかあると思いますが、それらは把握する必要があります。

にDATA DIVISIONはいくつかの SECTION があり、それぞれに特定の目的があります。

ファイル上のFILE SECTIONデータを表すデータ構造 (入力、出力、または入出力) を定義する場所です。各ファイルには がありFD、FD の下位には 1 つまたは複数の 01 レベルの構造があり、非常に単純な場合も複雑な場合もあります。

正確な動作の一部は、コンパイラの特定の実装に依存しますが、このように処理する必要があります。これは、自分自身の「最小限の驚き」と、後でプログラムを修正する必要がある人の同じことです。 t READ の後にデータを変更する、レコードを更新する場合を除きます (キー付き READ を使用している場合など)。「入力領域」をデータファイルの「ウィンドウ」と見なすことができます。次の READ で、ウィンドウは別の位置を指しています。または、「次のレコードが到着し、以前にあったものを消去する」と見なすこともできます。UNSTRING の「結果」をレコード領域に入れました。結果は、次の読み取りで確実に消えます。「次の」データも同様にスキッシュする可能性があります (ウィンドウがコンパイラに当てはまる場合、および IO に使用するメカニズムに応じて)。

結果は WORKING-STORAGE にあるはずで、新しいレコードが読み取られても影響を受けません。

READ filname INTO data-description は、record-area から data-description へのデータの暗黙の MOVE です。指定したように、data-description がレコード領域の場合、結果は「未定義」になります。レコード領域のデータのみが必要な場合は、単純な READ ファイル名だけで十分です。

元の UNSTRING にも同様の問題があります。同じストレージを参照するソース フィールドとターゲット フィールドがあります。「未定義」であり、希望する結果ではありません。これが、不要な UNSTRING が「機能した」理由です。

冗長なインライン PERFORM があります。ファイルの終わりの後に「何か」を処理します。PROCEDURE DIVISION で不要な「句読点」を使用することにより、物事をより複雑にします (貼り付けを省略したようです)。そこで COMPUTE の代わりに ADD を使用してみてください。FILE STATUS と 88 レベルの条件名の使用に注目してください。

DISPLAYを使用しない限り、無料で取得できるため、「改行」は必要ありませんNO ADVANCING。

DISPLAY で「連結」する必要はありません。これも無料で取得できるためです。

DISPLAY とそのいとこである ACCEPT は動詞です (組み込み関数のみが COBOL の関数です (コンパイラーがユーザー定義関数をサポートする場合を除く))。これはコンパイラーごとに最も異なります。コンパイラSCREEN SECTIONが DATA DIVISION をサポートしている場合は、「画面」でユーザー入力をフォーマットして処理できます。IBM の Enterprise COBOL を使用する場合は、非常に基本的な DISPLAY/ACCEPT を使用します。

「ローカル変数を宣言」します。あなたは？どのような意味で？プログラムに対してローカル。

ここ数年の COBOL に関する質問を見ると、非常に多くのヒントを得ることができます。

于 2017-04-18T16:55:40.830 に答える