				Wiki
	updated on 2004.06.23

a.20. 2000年問題其の弐拾

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

2000年のデータを表示したら、変

さて、修正も一気にやってしまい、そのテストをしています。

レベルチェックエラー
データ入力テスト（特に日付の範囲指定や、曜日検査、閏年検査など）
集計テスト
画面、帳票の日付その他のレイアウト（数字と文字がかぶっていないか、8桁あるのに6桁しか表示していないとか）
パラメータの受け渡し

など、テストをしています。

テストしていて、パラメータの桁数の未修正や、SBMJOBの起動画面の修正もれなどを発見したりしました。検索でヒットしているのに、一部修正して、完了したと勘違いしているのがほとんどでした。あまり、前向きにやれないので「仕方ないや」。パラメータの桁・属性違いやその数の違いは、コンパイルで検査してくれません。多分どんな言語もそうでしょうね。あーあ、検査できないのかなぁ。

ところで、

「年月」は本来 YYYY/MMとなるはずですが、サブファイルの画面の様に、1行にどうしても収まらないとき、YY/MMのままにしていました。また、YY/MM/DDのスラッシュをはずして、YYYYMMDDで表示したものもありました。（両方とも、占有するバイト数は10バイトなので、レイアウト変更は起きません。）

しかし、実際表示すると、

以前は、98/10と出ていたものが、2000年1月だと、0/01と表示されます。また、以前は、98/01/10となっていたものが、YYYYMMDDでは、20000110と表示されます。これが、19980110だとあまり違和感は無いのですが、2000年を回ると、なんか、変です。

99/10
99/11
99/12
0/01
0/02

は、なんか変だなぁ。

19991227
19991228
19991229
19991230
19991231
20000101
20000102
20000103

も日付に見えないなぁ。慣れ、の問題かなぁ。

同僚と相談しましたが、このままで行くことにしました。YYYYMMDDはフィールド名を変えて、YY/MM/DDに出来るので、気づくかぎり、そうしようかと思っていますが、桁の入りきらない、YY/MMはどうしようもありません。0/01でも仕方ないか。どうして、編集コードＹはゼロサプレスするのだろう。もしかすると、MDYの文化系統だから、月のゼロサプレスはいいと思っているのだろうか。まだ、00/01のほうが、しっくりする。編集コードを作ってみたけど、編集コードＹは特殊なようです。数字の桁数で、/の数が変わるのです。自分で定義したものは、 / / と登録すると、4桁は0/01/ と変に表示してしまいます（SDAで確認）。

システム値のシステム年はどうして２桁のままなの？

CLPで、システム値QYEARはどういう訳か、2桁のままです。QYEAR4とかで、4桁も欲しかった。QCENTURYで判断するよう（V4R1現在）ですが、これだと、コードが増えていきます。文字の意味からしても、QCENTURYは年4桁の上2桁にして欲しかったです。（V3R1では、PTFを入れないと、QCENTURYは使えないらしいです。）2000年の対象プログラムは、膨大なので、重要な問題なのです。

DCL &QYEAR    *CHAR 2
DCL &QYEAR4   *CHAR 4
DCL &QCENTURY *CHAR 1

RTVSYSVAL QYEAR    &QYEAR
RTVSYSVAL QCENTURY &QCENTURY

IF (&QCENTRUY = '0') CHGVAR &QYEAR4 ('19' |< &QYEAR )
     ELSE            CHGVAR &QYEAR4 ('20' |< &QYEAR )

をいちいちするのは、面倒です。QCENTURYが2桁なら、IF文はなくて、単純に文字合成だけだったのですが。まだ、&QYEARの内容が40以上か未満かで判定した方が、コードが少なくてすみます。（2000年修正まえから、もともとそのようになっているソースが多いので、この方が楽です。それから、本番機はV3R1M0なんですよね...）

DCL &QYEAR    *CHAR 2
DCL &QYEAR4   *CHAR 4

RTVSYSVAL QYEAR  &QYEAR

IF (&QYEAR *GE '40') CHGVAR &QYEAR4 ('19' |< &QYEAR )
     ELSE            CHGVAR &QYEAR4 ('20' |< &QYEAR )

というわけです。

尚、6桁のシステム日付から、CVTDATして、*YYMDで、8桁にして、頭4桁の年をとる方法もあります。

DCL &QDATE6  *CHAR 6
DCL &QDATE8  *CHAR 8
DCL &QYEAR4  *CHAR 4

RTVSYSVAL QDATE &QDATE6
CVTDAT  &QDATE6 &QDATE8 *SYSVAL *YYMD TOSEP(*NONE)
CHGVAR  &QYEAR4 %SST(&QDATE8 1 4)

しかし、一発で年4桁とれないのは、なんだかなぁ...

これが、システム値のシステム年に、（重複するけど、）2桁と4桁のシステム値があったら、

実際は無いけど

DCL &QYEAR4   *CHAR 4

RTVSYSVAL QYEAR4 &QYEAR4

で終わりだけど、現行V4R1では、できません。まあ、これからサポートされても、迷惑ですけど。修正対象プログラムは、膨大ですので。

CLPで去年と来年を求める部分

さて、CLPで、「昨年の年」や「来年の年」を求めるときに、注意しなくてはなりません。うっかり、「このプログラムは2桁のままでいいや」と安易に年のフィールドの桁数を2桁のままにすると、面倒なことがあります。次の例では、システム値QYEARを数字フィールド&QYEARNにCHGVARしたもの、とします。

DCL &LASTYR *DEC (2 0)
DCL &NEXTYR *DEC (2 0)
DCL &QYEARN *DEC (2 0)

/* 今年を、&QYEARN　とします */

/* 来年は、今年 + 1　です。*/

CHGVAR &NEXTYR (&QYEARN + 1)

/* 昨年は、今年 - 1　です。*/

CHGVAR &LASTYR (&QYEARN - 1)

これで行くと、

2000年では、&QYEARNは00なので、昨年&LASTYRは-1になります。+100してやると、99年になりますが...
1999年では、&QYEARNは99ですで、来年&NEXTYRは100となり、MCH1210を引き起こします。2桁で入りきらないので、MONMSG MCH1210をしなくてはなりません...

やはり、下手な小細工はせずに、ワークフィールドも4桁にしましょう。

（CVTDATEで、ジュリアンデートで+365する手もありますが、コードが多すぎて、2000年修正に組み込むのは面倒です。それから、よっぽど、去年、今年、来年を4桁でデータエリアに作成しようか、と思いましたが、やっぱり、全プログラムの修正が面倒でやめました。）

編集語に注意

日付のフィールドを、編集語で、' / / 'とすると、もし値が0の場合、なにも表示されません。'0 / / 'だと、 0/00/00と出てきます。入力フィールドで、YYYY/MM/DDを、' / / 'としてしまうと、入力するとき初期値が0だと、と、いやに長い10バイト（スラッシュ込みの桁数）が出てくるだけで、オペレータは面食らうでしょう。まだ 000/00/00 の方が、親切かもしれません。出来れば、初期値もあるといいですね。尚、EDTCDE(Y)を、EDTWRD('0 / / ')で一括して置き換えるときは、その他の6桁の日付の編集コードに注意しましょう。かえって面倒になることもあります。逐次置き換えの方がいいでしょうね。

それから、物理ファイルで、編集語を指定して、画面などでは、それとは違う編集コードや編集語を使うときは、DDSの中に変更したい編集コードの指定が必要です。初期値が、物理ファイルの編集語となるので、その指定変更をコードしなくてはならないのです。

外は雨。「巷に雨の降るごとく...」ああ、あれは失恋の詩か。

1998/08/04

続く...