最初のページに戻ります。

総合の目次があるページに戻ります。

よく使うマニュアルです

Wiki

updated on 2004.06.23

a.15. 2000年問題 其の拾伍

[ Previous ] [ HOME ] [ Upper ] [ Next ]


どこまで、話しましたっけ、昨日は。

そうそう、エンハンスをした話でしたね。エンハンスは、主に、実行効率を挙げるため、無駄を省くことにありました。結局、数字フィールドに、一つでもマイナスの数字があれば、ほぼ間違いなく日付ではないですよね。そこで、負数を含むフィールドはいきなり、負数を見つけたら即、チェックをやめるか、それとも、かまわず続けるか、のオプションをつけました。さらに、数字フィールドがゼロの場合、ゼロでない(有数)のカウントと、単純にカウントをした回数の2つのフィールドを設けました。これは、たとえば、取引停止日のように、ずーっと、000000なのに、いくつか日付が入っていても、単純カウントでは、日付となる確率がとても低い(0では日付とは、判断できない。)ので、有数のカウントで、確率的に日付(らしき)数字がいくつか、判断しようとしたものです。

日付フォーマット ヒット数 単純カウント 有数のカウント 単純カウントから出現確率 有数のカウントから出現確率
YMD 10 5000 10 0.2% 100%
*ZERO 4990 5000 0 99.8% +++++

さらに、別プログラムだった、オブジェクトAPIを、この検索コマンドの中に組み込んだりしました。結構、このAPIは、*machineプールの非DBフォールトを上げてくれます。瞬間で60以上もありました。

さて、今日行ったのは、昨晩実行した内容(さらに早くなっていた)を元に、実際にDDSを修正すると言うものでした。覚えていらっしゃるでしょうか、以前、カラムヘディングやフィールド名で、日付を洗い出したことがありました。そのデータはまだ取ってあって、これと、検索結果を比較したのです。

あ、誕生日が

検索結果を比較してみると、ほとんど同じフィールドをヒットしていました。たまに、「納期」というのフィールドに日付が入っていたり(カラムヘディングの検索では出なかった;「納期」を指定してなかった)※、思わぬカラムヘディングを探し当てたり、パラメータデータを持つファイルでは、年の開始から終了を00から99になっているため、開始年をヒット出来なかったり、したのですとにかく、リストには低い確率で出てきます。

※訪問者の方から、「期限」を検索すべきだった、という情報を頂きました。ありがとうございます。「期」とつくのは、あと、「納期」「期間」あたりですね。それから、この方から、システム日付を2000年にしたら、クリーンアップががんがん起きたそうです。もし、ジョブスケジューラ(WRKJOBSCDE)を使われていれば、たぶん同じ事が起きますね。気をつけましょう!

しかし、やばいと思ったものがあります。カラムヘディングに「誕生日」として、間違いなく日付フィールドが出ているのに、このデータからの検索がヒットしていません。ああ!そうです。私は、年を80以上の数字として、勝手に考えていました。これ以上古いデータは、緊急変換データではない(2000年のあとでもいい)と考えていたのです。でも、誕生日は別です。80以上では、偶然アクセスしたデータが18才以下の人のものになります。しかも、人事データと違って、顧客のデータでは、(化粧品なので)おばさまが多く、誕生月日は報告しても、誕生年を入れない人が多いのです。つまり、4桁の数字となってしまいます。かといって、年の部分を00から判定対象にしてしまうと、日付のロジックが狂ってしまいます。そこで、仕方なく、日付判定ロジックを以下のようにしました。

1 2 3 4 5 6 7 8 日付フォーマットコード 注意
0 0 0 0 0 0 3 2 Y
32 - 99
0 0 0 0 3 2 0 1 YM
32 - 99 01 - 12
0 0 0 0 1 9 3 2 YY
1932 - 1999
0 0 3 2 1 2 0 1 YMD
32 - 99 01 - 12 01 - 31
0 0 1 9 3 2 1 2 YYM
1932 - 1999 01 - 12
0 0 0 1 1 2 3 2 MDY 5桁と6桁にまたがる
01 - 12 01 - 31 32 - 98
0 9 3 2 1 2 0 1 YMD7
932 - 999 01 - 12 01 - 31
1 9 3 2 1 2 3 1 YYMD
1932 - 1999 01 - 12 01 - 31
0 5 1 2 1 9 3 2 MDYY 7桁と8桁にまたがる
01 - 05 1 - 31 1932 - 1999

結局年を32からにしました。31では、MDYとYMDが区別つかないのです。最後の2桁が31の時、日の31日か、年の31年か判定できません。そこで、32を最小値にしました。これで行くと、誕生年32以上とは、1998年の今年では、66才以下です。67才以上の人はそれほど、この化粧品会社では登録されていませんので、確率が低いでしょうが、少なくとも、日付らしきデータとしてヒットしてくれます。

但し、8桁変換となると難しいです。00年があるので、最初から、誕生年で、日付だけど、日付としての妥当性が壊れたものとして扱うしかありません。たぶん、0101から1231を00年の日付と判定できそうですが、やはり、合理性を欠くものは、例外として扱うことが、「真の合理性」だと思います。そこで、仕方ないので、「誕生日専用変換プログラム」を作成して、手作業で、例の自動生成プログラムに組み込みます。それほど数はないのですし、もう、いくら何でも分かっているフィールドなのです。(または、テキストに何か入れようか?)※変換経過、たとえば570512 -> 19570512などのログをスプールしたほうがよさそうですね。

さて、32からとせざるを得なくなったので、上記のように修正したプログラムは、やたら、時間を日付として、MDYとか、YYMとかに判定してしまいます。これは、10:10:45を10月10日45年とか、19:32:11を1932年11月と判定してまうためです。仕方ないでしょう。

本日は、FORMATとREFを調査して、また、データの無い(つまり、データを判定する上記プログラムの対象外)ファイルと、カラムヘディングから抜き出したフィールド群をぶつけたりして、ほぼ、DDSは終了しました。変換プログラムを作成すれば、対象フィールドの一覧が勝手に出来ますので、それを来週にします。結構このプログラムは、早いので、すぐに結果が出るでしょう。苦労のかいあって、結構精度が高くなったと思っています。本当は、ボタン一発ですべて解決なんて思っていましたが、やはり、現実は厳しかったです。あの誕生日が無ければなぁ。1932年以前のデータってほかにないですよねぇ。

続く...


[ Previous ] [ HOME ] [ Upper ] [ Next ]

You are at K's tips-n-kicks of AS/400

 

Ads by TOK2