Google
オフコン練習帳内を検索
インターネット全体を検索

NECオフコン関連
オフコン一般
情報

[掲示板に戻る]


RDBのレコード削除のバッチ処理の方... 江須扇 2004-8-24 16:33
Re:RDBのレコード削除のバッチ処理の... EXCHANGE 2004-8-24 18:27
Re:RDBのレコード削除のバッチ処理の... 江須扇 2004-8-24 20:39
Re:RDBのレコード削除のバッチ処理の... EXCHANGE 2004-8-26 23:23
Re: x4: RDBのレコード削除のバッチ... 江須扇 2004-8-27 22:21

1 RDBのレコード削除のバッチ処理の方法
江須扇 2004-8-24 16:33  [返信] [編集]

こんにちは江須扇です。

一ヶ月前のデータを削除したいというバッチ処理を考えた時。

RDBQ2のカタログでは一ヶ月前という条件指定が難しいです。

(もしご存知の方がお見えでしたら教えてください。)

SMART2は1ファイル更新でレコード削除は可能ですが

選択条件が働かず全件読込です。



COBOLはRDBのSELECTは条件と分類しかできなく

SQL文としてUPDATEやDELETEができません。



そこで、下記のようなコーディングを考えたのですが

GOTOレスではこんな感じでよいのでしょうか?

例1と例2ではどちらがよいのでしょうか?



例1
---------------------------------------------------------------------------

000010 IDENTIFICATION      DIVISION.
000020 PROGRAM-ID.         RDBDEL.
000030 ENVIRONMENT         DIVISION.
000040 CONFIGURATION      SECTION.
000050 SOURCE-COMPUTER.    EXPRESS5800.
000060 OBJECT-COMPUTER.    EXPRESS5800.
000070 INPUT-OUTPUT        SECTION.
000080 FILE-CONTROL.
000090     SELECT  RDBFILE  ASSIGN  TO RDBFILET-RDB.
000100 DATA          DIVISION.
000110 FILE          SECTION.
000120 FD  RDBFILE
000130     LABEL   RECORD  IS      STANDARD
000140     VALUE   OF      IDENTIFICATION   "RDBFILE-TBL".
000150     COPY RDBFILE-R  OF DDF.
000160 WORKING-STORAGE     SECTION.
000170 77  WRK-DATE     PIC 9(06).
000180 01  READ-FLG     PIC 9(01) VALUE 0.
000190 88  READ-END           VALUE 9.
000200 PROCEDURE        DIVISION.
000210 MAIN          SECTION.
000220 MAIN-RTN.
000230     ACCEPT WRK-DATE FROM DATE.
000240     IF WRK-DATE(3:2) = 01
000250                SUBTRACT 8900 FROM WRK-DATE
000260             ELSE SUBTRACT  100 FROM WRK-DATE
000270     END-IF.
000280     OPEN  I-O    RDBFILE.
000029     SELECT RDBFILE WHERE RDB-DATE     < WRK-DATE.
000300     PERFORM UNTIL READ-END
000310       READ RDBFILE AT  END SET READ-END TO TRUE
000320               NOT END DELETE RDBFILE
000330       END-READ
000340     END-PERFORM.
000350     CLOSE RDBFILE.
000360     STOP RUN.



例2

---------------------------------------------------------------------------

000010 IDENTIFICATION     DIVISION.
000020 PROGRAM-ID.       RDBDL2.
000030 ENVIRONMENT       DIVISION.
000040 CONFIGURATION      SECTION.
000050 SOURCE-COMPUTER.    EXPRESS5800.
000060 OBJECT-COMPUTER.    EXPRESS5800.
000070 INPUT-OUTPUT      SECTION.
000080 FILE-CONTROL.
000090     SELECT  RDBFILE  ASSIGN  TO RDBFILET-RDB.
000100 DATA          DIVISION.
000110 FILE          SECTION.
000120 FD  RDBFILE
000130     LABEL   RECORD  IS      STANDARD
000140     VALUE   OF      IDENTIFICATION   "RDBFILE-TBL".
000150     COPY RDBFILE-R  OF DDF.
000160 WORKING-STORAGE     SECTION.
000170 77  WRK-DATE     PIC 9(06).
000180 01  READ-FLG     PIC 9(01) VALUE 0.
000190 88  READ-END           VALUE 9.
000200 PROCEDURE        DIVISION.
000210 FLOW          SECTION.
000220 FLOW-RTN.
000230     PERFORM INIT.
000240     PERFORM MAIN UNTIL READ-END.
000250     PERFORM FINE.
000260 INIT          SECTION.
000270 INIT-RTN.
000280     ACCEPT WRK-DATE FROM DATE.
000290     IF WRK-DATE(3:2) = 01
000300               SUBTRACT 8900 FROM WRK-DATE
000310            ELSE SUBTRACT  100 FROM WRK-DATE
000320     END-IF.
000330     OPEN  I-O    RDBFILE.
000340     SELECT RDBFILE WHERE RDB-DATE      <WRK-DATE.
000350 MAIN          SECTION.
000360 MAIN-RTN.
000370     READ RDBFILE AT  END SET READ-END TO TRUE
000380                  NOT END DELETE RDBFILE
000390     END-READ.
000400 FINE          SECTION.
000410 FINE-RTN.
000420     CLOSE RDBFILE.
000430     STOP RUN.

2 Re:RDBのレコード削除のバッチ処理の方法
EXCHANGE 2004-8-24 18:27  [返信] [編集]


> 000240     IF WRK-DATE(3:2) = 01
> 000250                SUBTRACT 8900 FROM WRK-DATE
> 000260             ELSE SUBTRACT  100 FROM WRK-DATE
> 000270     END-IF.



☆ ここの部分で、ハタ、と 分からなくなってしまいました。

 江須扇さんのロジックが間違っているということではなく、



☆ 「3月28日の1ヶ月前は?」と来たら問題なしに「2月28日」。

 でも、

 「2月28日の1ヶ月前は?」ときたら

 「1月28日」? 「1月31日」?

  これはソフトを運用する状況によって違ってきそうな気がします。



☆ もし、「1月31日」でしたら単に?100とするのはマズイかも。。



3 Re:RDBのレコード削除のバッチ処理の方法
江須扇 2004-8-24 20:39  [返信] [編集]

EXCHANGEさん今晩は

いつも即行の対応ありがとう御座います。



>  「2月28日の1ヶ月前は?」ときたら

>  「1月28日」? 「1月31日」?

>   これはソフトを運用する状況によって違ってきそうな気がします。

これはアバウトに作ってあるの約一ヶ月と考えてください。

「3月31日」の時は「2月31日」になってしまいますが、

それより小さいで比較しておりますのでこれは問題ありません。

また、「2月28日」の時は「1月28日」で「1月27日」以前しか消えませんが

「3月1日」の時は「2月1日」でそれより小さい1月分は消えるので

問題ないと思います。



>

> ☆ もし、「1月31日」でしたら単に−100とするのはマズイかも。。

> > 000240     IF WRK-DATE(3:2) = 01
> > 000250                SUBTRACT 8900 FROM



1月の時は−8900にしているので問題は無いと思いますが?
4 Re:RDBのレコード削除のバッチ処理の方法
EXCHANGE 2004-8-26 23:23  [返信] [編集]

☆ 江須扇さん、こんばんわ。

 すみません、書き方が舌足らずで。。



> ☆ もし、「1月31日」でしたら単に−100とするのはマズイかも。。



 の言わんとするところですが、直前の文章から(なんと指示語もなしに)続いておりまして、



>「2月28日の1ヶ月前は?」ときたら 



 の答えが−−>(A)「1月28日」でなく、(B)「1月31日」でしたら と言う意味でした。



 (B)の解釈の場合、「2月28日の1ヶ月前」というのは「1月31日」になりますので、 040228 − 100 = 040128 としてしまうと、(A)タイプの解釈になってマズイ、 という意味です。



☆ ただし、いずれにせよ江須扇さんの目的は約1ヶ月前までのデータを削除することにあるとのことですので、そこまで心配することはなかったようです。



☆ ところでこのような場合(というよりこのようなケースを想定して)私が良くやる方法は、



(1)所詮、データベースは項目単位でしか取り扱い出来ないので、

(2)初めからデータ上に「年月日」以外にもう一つ「年月度」という項目を取っておく。



 というふうにしています。

例えば、年月日「20040826」でしたら年月度「200408」となりますし、 年月日「040826」でしたら年月度「0408」となります。

 そして、

(3)データ削除のPGでは初期条件の入力でユーザに「削除年月度を指定して下さい」とやります。

 あとは、 COBOLにて

 

 SELECT RDBFILE

   WHERE RDBーGETUDO <= IN−GETUDO  

 という調子です。



☆ これの方が面倒くさくなくて便利に思うのですが。。

  ただし、また容量無駄遣いしてしまいますけどね!!



 

5 Re: x4: RDBのレコード削除のバッチ処理の方法
江須扇 2004-8-27 22:21  [返信] [編集]

今晩は、EXCHANGEさん



> >「2月28日の1ヶ月前は?」ときたら 

>  の答えが−−>(A)「1月28日」でなく、(B)「1月31日」でしたら と言う意味でした。



(B)と解釈した場合は

2月27日の一ヶ月前は1月30日

2月1日の一ヶ月前は1月4日

1月31日の一ヶ月前は1月3日

3月31日の一ヶ月前は2月28日

3月30日の一ヶ月前は2月27日

では3月1日の一ヶ月前は????

解からなくなってしまいました。混乱、混乱、



> (3)データ削除のPGでは初期条件の入力でユーザに「削除年月度を指定して下さい」とやります。

>  あとは、 COBOLにて

>  SELECT RDBFILE

>    WHERE RDBーGETUDO <= IN−GETUDO  

>  という調子です。

> ☆ これの方が面倒くさくなくて便利に思うのですが。。



む?、私はアバウトSEなので、オペレーションが入ると忘れてしまいますので、

目指しているのはノンオペレーションの夜間バッチです。

バッチ完了メールが朝入っていれはOK、入ってなければ、障害発生としています。



>   ただし、また容量無駄遣いしてしまいますけどね!!



所で話は長くなりますが、

旧100(赤100、1978年以前)のCOBOLはパックデータが使えませんでした。

その事を他社(多分F)に突かれて急遽サブルーチン提供がされました。



ファイルをREADしたあと

CALL ”UNPACK” USING FILE−A WORK−A SIZE−A

CALL ”UNPACK” USING FILE−B WORK−B SIZE−B





の様に一項目毎、アンパックに戻して処理をして、

終わったら

CALL ”PACK” USING WORK−A FILE−A SIZE−A

CALL ”PACK” USING WORK−B FILE−B SIZE−B





でファイルをREWRITEします。

(記憶ですのであくまでもこんな感じでしたと思ってください)

大変面倒くさかったです。



その後、新100が出てからCOMP−3でパックデータが使えるようになりました。

当時はディスク容量は小さくパックデータにするのが当たりまででした。

メモリは内部処理でアンパックに戻して処理をするのであまり効果はなかったようです。

またNECの場合はパックデータの符号無しにしても1桁は1バイト、2桁は2バイトで

処理フラグや区分で1桁2桁を使う場合はあまり効果はありませんでした。



しかし現在はディスク容量も増えたのでパックにする意味は少なくなったと思います。

特にNECの場合はFILLERの項目を後で使う場合など不正十進数エラーが

パックデータは符号無しでもスペースはLOW−VALUEでもおきてしまうので使い勝手が悪いです。

設計時はパックデータ、追加項目はアンパックとデータベースの各項目がゴチャゴチャになっているのが実体です。



時代の流れでパックデータを採用した時代もありましたが、今にして思えは、本来のシステム100の基本である

アンパックにしていればと思っております。



ここで本題に戻ります。



> (1)所詮、データベースは項目単位でしか取り扱い出来ないので、

> (2)初めからデータ上に「年月日」以外にもう一つ「年月度」という項目を取っておく。

> 例えば、年月日「20040826」でしたら年月度「200408」となりますし、 年月日「040826」でしたら年月度「0408」となります。



確かめてないので解かりませんが、アンパックであればCOBOL側フィールドを階層構造にしておけば、

上6桁や上4桁も可能ではとおもいます。

データベース定義も階層構造でしてすれば可能を思います。(これも確かめていません。)



8桁+6桁のパックの場合5+4=9バイト、アンパックの8桁階層構造8バイト

6桁+4桁のパックの場合4+3=7バイト、アンパックの6桁階層構造6バイト



と考えた場合でもアンパックが良いのでは思いますが皆様は如何お考えでしょうか?

BluesBB ©Sting_Band