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

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

[掲示板に戻る]

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