a.23. 2000年問題其の弐拾参

				Wiki
	updated on 2004.06.23

五百里まで来た。千里はまだ遠い。

やっと、現在のシステム日付での、テストが終わった。実行して、結果を、見る。日付のパラメータはちゃんと渡っているか、データエリアに日付を持つものの中身は、きちんと変わっているか、OPNQRYFのQRYSLTで日付を参照するものが、きちんと8桁になっているか、画面帳票の日付は表示、印刷はきちんと出来ているか、エトセトラ、エトセトラ。もう、うんざりだった。でも、ちょんぼミスがよくあったので、単純実行テストだけでも、してよかった。今度は、システム日付を1999年12月末にする。

何日にしようか。

最初、1999年12月25日にしてみた。活動中のジョブ日付は、システム日付が変わっても、変化はない。システム日付に合わせて、すべての活動中のジョブの日付は、変わってはくれない。（活動中のジョブ日付を変更するジョブを流すのは、WRKJOBSCDEとツールで出来そうだが）。どうせ、テスト機なんだから、ENDSBS *ALL *IMMEDをして、システム日付を、991225にした。その後、サインオフ、オンをして(システム日付を変更したジョブ自身も、変更を反映させるため）、STRSBS QCTLを実行。どうなるだろう。と思ったが、なにも起きなかった。ジョブが動き出したのは、やはり、WRKJOBSCDEだった。でも、一個だけ。というより、テスト環境のWRKJOBSCDEは、自分で指定した一個＋BACKUPジョブだけ。また、動きだしたのは、*SBMRLSを指定していたものだった。多分これが原因だろう。BACKUPの方は、*NOSBMになっている。また、いろいろ試して気づいたが、次回実行は、投入後、その時点で判定されるらしく、1年分動き出すことはなかった。

その後、1999年12月25日が土曜日のため、現実の曜日（そのときは、98/10/7 火曜日だった。）と合わない。曜日が重要な判定になったりするとき、混乱する。また、テストをのんびりしていると、日毎に、2000年に近くなる（テスト機も動いている）ので、もっと、前にして、1999年12月21日に変更した。これは火曜日なので、曜日が現在のカレンダーと一致する。つまり、1999年12月25日を1999年12月21に戻したのだ。

あれ、変だな。

おかしいことに気づいたのは、WRKJOBSCDEだ。次の実行日が、変わらないのだ。相変わらず、12月26日に実行しようとしてる。前に戻したのだから、12月22日が、次の実行日だ。うーん。それに、BACKUPジョブも日付が、25日以降のままだった。そこで、一度、GO BAKUPから、バックアップを保留にしてみた。WRKJOBSCDEでは、エントリーがHOLDに変わったが、次の実行日は変わらない。仕方なく、WRKJOBSCDEのエントリーをすべて、消してみた。すると、GO BACKUPの画面で、月曜日　*DAILYと指定した部分が、空欄になった。WRKJOBSCDEのエントリーを検査しているのかなぁ。仕方なく、もう一度、*DAILYとポチポチ入力して、実行する指定をしたら、WRKJOBSCDEにエントリーが増えて、正しい日付でスケジュールされた。これ以外にも方法が有ると思うけど、もういいや。残りの26日実行になっているものは、オプション10番（即時実行）をしたら、次の実行日が、22日に書き変わった。実行の時点で、次の実行日を判定していると思ったのは、これを見たときだった。

また、システム日付を前に戻したら、QSECOFRのパスワードの期限満了になってしまった。30日間のインターバルなのに、前に戻すと、すぐ、満了するらしい。

ソースの修正行に日付が、991221になってしまった。これを、本番機に移すと、そのままの日付になる。（ファイル内に日付をデータとして持っているので）。これでは、後々、面倒だ。ノートに日付の対応をちょこちょこ、書いて、1対1対応するのなら、一気に変換するプログラムを作ることにした。簡単だ。

現在の日付		テスト機の日付
98/10/06	火曜日	99/12/21	火曜日
98/10/07	水曜日	99/12/22	水曜日
98/10/08	木曜日	99/12/23	木曜日
98/10/09	金曜日	99/12/24	金曜日
98/10/10	土曜日	99/12/25	土曜日
98/10/11	日曜日	99/12/26	日曜日

これを元に、ソースファイルのSRCDATを変換してしまうのだ。1号機に移すときに、行う。どうせ、コピーするのだから、メンバーの変更日は変わってしまうし、メンバー日付は、気にしない（ことにする）。

QCENTURYて、なんか変だぞ。

CLPの日付を、40以上か、40より小さいか、で1900年代、2000年代に振り分けるやり方をしてしまったことを、気にしていた。これでは、1940年から2039年までのサポートになってしまう。いいかなー。固定ウインドウではなく、スライディングウインドウ方式（これに関しては、IBMのウエッブに詳しい）にすべきだったのだろうか。いや、CLPだから、やはり、QCENTURYの方が、いいのだろうか。QCENTURYなんだから、世紀だから、100年間サポートするんだろうなぁ。...と思ったら、違っていた、

OS/400 システム値

QCENTURY (世紀)

世紀 (QCENTURY) システム値は、世紀を指定するために使用されます。これは、システム値 QDATE および QYEAR と共に使用されて、システムが現在使用している特定の日付を決定します。次の値を指定できます。

0 (1928 年から 1999 年まで)

1 (2000 年から 2053 年まで)

ユーザーは QCENTURY の値を世紀標識を使って設定できます。あるいは、システムが以下の 2 つの状態に基づいて QCENTURY の値を設定します。最初の IPL 時に、システムは次の規則にしたがって QCENTURY の初期値を設定します。

QYEAR が 40 と等しいかそれより大きい場合、システムは 0 をQCENTURY に割り当てます。

QYEAR が 40 より小さい場合、システムは 1 を QCENTURY に割り当てます。

QYEAR、または QDATE の中の年が変更された場合に、 QYEAR が 54 から 99 の範囲の値であれば、QCENTURY は 0 に設定されます。

QYEAR が 00 から 27 の範囲の値であれば、QCENTURY は 1 に設定されます。

たとえば、ユーザーが QYEAR を 95 から 13 に変更すると、システムはQCENTURY を 0 から 1 に変更して、2013 年であることを示します。しかし、ユーザーが QYEAR を 95 から 45 に変更しても、システムは QCENTURY を変更しません。1945 と 2045 はどちらも有効な日付だからです。

この値を変更すると、その変更は即座に有効になります。また、この値を変更すると、システム値 QDATE も影響を受けます。

まとめると、

システム年	工場出荷直後の最初のIPL （初期値）	システム年の変更
00	QCENTURY=1 (2000年代）	QCENTURY=1 (2000年代）
01
...
20
...
27
28		どうやら、QCENTURYを手動変更出来るらしい。変更しようとしたら、エラーが出た。システム年との整合性を検査するらしい。確かめるほど、暇ではなかった。
29
...
30
...
39
40	QCENTURY=0 (1900年代）
41
...
50
...
52
53
54		QCENTURY=0 (1900年代）
55
...
60
...
70
...
80
...
90
...
98
99