[掲示板に戻る]
 
Re:ＲＤＢのレコード削除のバッチ処理の... 江須扇 2004-8-24 20:39
|
|
Re:ＲＤＢのレコード削除のバッチ処理の... ＥＸＣＨＡＮＧＥ 2004-8-26 23:23
|
|
Re: x4: ＲＤＢのレコード削除のバッチ... 江須扇 2004-8-27 22:21
|
| 3 | Re:ＲＤＢのレコード削除のバッチ処理の方法 |
| 江須扇 2004-8-24 20:39
[返信] [編集] ＥＸＣＨＡＮＧＥさん今晩は いつも即行の対応ありがとう御座います。 > 「２月２８日の１ヶ月前は？」ときたら > 「１月２８日」？ 「１月３１日」？ > これはソフトを運用する状況によって違ってきそうな気がします。 これはアバウトに作ってあるの約一ヶ月と考えてください。 「３月３１日」の時は「２月３１日」になってしまいますが、 それより小さいで比較しておりますのでこれは問題ありません。 また、「２月２８日」の時は「１月２８日」で「１月２７日」以前しか消えませんが 「３月１日」の時は「２月１日」でそれより小さい１月分は消えるので 問題ないと思います。 > > ☆ もし、「１月３１日」でしたら単に−１００とするのはマズイかも。。 > > 000240 IF WRK-DATE(3:2) = 01 > > 000250 SUBTRACT 8900 FROM １月の時は−８９００にしているので問題は無いと思いますが？ |
|
| 4 | Re:ＲＤＢのレコード削除のバッチ処理の方法 |
| ＥＸＣＨＡＮＧＥ 2004-8-26 23:23
[返信] [編集] ☆ 江須扇さん、こんばんわ。 すみません、書き方が舌足らずで。。 > ☆ もし、「１月３１日」でしたら単に−１００とするのはマズイかも。。 の言わんとするところですが、直前の文章から（なんと指示語もなしに）続いておりまして、 >「２月２８日の１ヶ月前は？」ときたら の答えが−−＞（Ａ）「１月２８日」でなく、（Ｂ）「１月３１日」でしたら と言う意味でした。 （Ｂ）の解釈の場合、「２月２８日の１ヶ月前」というのは「１月３１日」になりますので、 ０４０２２８ − １００ ＝ ０４０１２８ としてしまうと、（Ａ）タイプの解釈になってマズイ、 という意味です。 ☆ ただし、いずれにせよ江須扇さんの目的は約１ヶ月前までのデータを削除することにあるとのことですので、そこまで心配することはなかったようです。 ☆ ところでこのような場合（というよりこのようなケースを想定して）私が良くやる方法は、 （１）所詮、データベースは項目単位でしか取り扱い出来ないので、 （２）初めからデータ上に「年月日」以外にもう一つ「年月度」という項目を取っておく。 というふうにしています。 例えば、年月日「２００４０８２６」でしたら年月度「２００４０８」となりますし、 年月日「０４０８２６」でしたら年月度「０４０８」となります。 そして、 （３）データ削除のＰＧでは初期条件の入力でユーザに「削除年月度を指定して下さい」とやります。 あとは、 ＣＯＢＯＬにて ＳＥＬＥＣＴ ＲＤＢＦＩＬＥ ＷＨＥＲＥ ＲＤＢーＧＥＴＵＤＯ ＜＝ ＩＮ−ＧＥＴＵＤＯ という調子です。 ☆ これの方が面倒くさくなくて便利に思うのですが。。 ただし、また容量無駄遣いしてしまいますけどね！！ |
|
| 5 | Re: x4: ＲＤＢのレコード削除のバッチ処理の方法 |
| 江須扇 2004-8-27 22:21
[返信] [編集] 今晩は、ＥＸＣＨＡＮＧＥさん > >「２月２８日の１ヶ月前は？」ときたら > の答えが−−＞（Ａ）「１月２８日」でなく、（Ｂ）「１月３１日」でしたら と言う意味でした。 （Ｂ）と解釈した場合は ２月２７日の一ヶ月前は１月３０日 ２月１日の一ヶ月前は１月４日 １月３１日の一ヶ月前は１月３日 ３月３１日の一ヶ月前は２月２８日 ３月３０日の一ヶ月前は２月２７日 では３月１日の一ヶ月前は？？？？ 解からなくなってしまいました。混乱、混乱、 > （３）データ削除のＰＧでは初期条件の入力でユーザに「削除年月度を指定して下さい」とやります。 > あとは、 ＣＯＢＯＬにて > ＳＥＬＥＣＴ ＲＤＢＦＩＬＥ > ＷＨＥＲＥ ＲＤＢーＧＥＴＵＤＯ ＜＝ ＩＮ−ＧＥＴＵＤＯ > という調子です。 > ☆ これの方が面倒くさくなくて便利に思うのですが。。 む?、私はアバウトＳＥなので、オペレーションが入ると忘れてしまいますので、 目指しているのはノンオペレーションの夜間バッチです。 バッチ完了メールが朝入っていれはＯＫ、入ってなければ、障害発生としています。 > ただし、また容量無駄遣いしてしまいますけどね！！ 所で話は長くなりますが、 旧１００（赤１００、１９７８年以前）のＣＯＢＯＬはパックデータが使えませんでした。 その事を他社（多分Ｆ）に突かれて急遽サブルーチン提供がされました。 ファイルをＲＥＡＤしたあと ＣＡＬＬ ”ＵＮＰＡＣＫ” ＵＳＩＮＧ ＦＩＬＥ−Ａ ＷＯＲＫ−Ａ ＳＩＺＥ−Ａ ＣＡＬＬ ”ＵＮＰＡＣＫ” ＵＳＩＮＧ ＦＩＬＥ−Ｂ ＷＯＲＫ−Ｂ ＳＩＺＥ−Ｂ ・ ・ の様に一項目毎、アンパックに戻して処理をして、 終わったら ＣＡＬＬ ”ＰＡＣＫ” ＵＳＩＮＧ ＷＯＲＫ−Ａ ＦＩＬＥ−Ａ ＳＩＺＥ−Ａ ＣＡＬＬ ”ＰＡＣＫ” ＵＳＩＮＧ ＷＯＲＫ−Ｂ ＦＩＬＥ−Ｂ ＳＩＺＥ−Ｂ ・ ・ でファイルをＲＥＷＲＩＴＥします。 （記憶ですのであくまでもこんな感じでしたと思ってください） 大変面倒くさかったです。 その後、新１００が出てからＣＯＭＰ−３でパックデータが使えるようになりました。 当時はディスク容量は小さくパックデータにするのが当たりまででした。 メモリは内部処理でアンパックに戻して処理をするのであまり効果はなかったようです。 またＮＥＣの場合はパックデータの符号無しにしても１桁は１バイト、２桁は２バイトで 処理フラグや区分で１桁２桁を使う場合はあまり効果はありませんでした。 しかし現在はディスク容量も増えたのでパックにする意味は少なくなったと思います。 特にＮＥＣの場合はＦＩＬＬＥＲの項目を後で使う場合など不正十進数エラーが パックデータは符号無しでもスペースはＬＯＷ−ＶＡＬＵＥでもおきてしまうので使い勝手が悪いです。 設計時はパックデータ、追加項目はアンパックとデータベースの各項目がゴチャゴチャになっているのが実体です。 時代の流れでパックデータを採用した時代もありましたが、今にして思えは、本来のシステム１００の基本である アンパックにしていればと思っております。 ここで本題に戻ります。 > （１）所詮、データベースは項目単位でしか取り扱い出来ないので、 > （２）初めからデータ上に「年月日」以外にもう一つ「年月度」という項目を取っておく。 > 例えば、年月日「２００４０８２６」でしたら年月度「２００４０８」となりますし、 年月日「０４０８２６」でしたら年月度「０４０８」となります。 確かめてないので解かりませんが、アンパックであればＣＯＢＯＬ側フィールドを階層構造にしておけば、 上６桁や上４桁も可能ではとおもいます。 データベース定義も階層構造でしてすれば可能を思います。（これも確かめていません。） ８桁＋６桁のパックの場合５＋４＝９バイト、アンパックの８桁階層構造８バイト ６桁＋４桁のパックの場合４＋３＝７バイト、アンパックの６桁階層構造６バイト と考えた場合でもアンパックが良いのでは思いますが皆様は如何お考えでしょうか？ |
BluesBB ©Sting_Band