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

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

よく使うマニュアルです

Wiki

updated on 2004.06.23

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

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


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

やっと、現在のシステム日付での、テストが終わった。実行して、結果を、見る。日付のパラメータはちゃんと渡っているか、データエリアに日付を持つものの中身は、きちんと変わっているか、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年間サポートするんだろうなぁ。...と思ったら、違っていた、

IBM 西暦 2000 年対応 計画・導入ガイドより、抜粋

OS/400 システム値

QCENTURY (世紀)

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

0 (1928 年から 1999 年まで)

1 (2000 年から 2053 年まで)

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

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

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

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

  4. 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

となる。システム年、28年から、53年までが、自動では判定できない範囲らしい。

変更しようとしたら出た、エラー。

qcentury1.gif (8404 バイト)

qcentury2.gif (9222 バイト)

qcentury3.gif (12122 バイト)

もう、固定ウインドウでいいや。一番単純で、将来も(そのとき、私は、停年だ)修正はらくだろうし。いいよ。これでもー。

システム年だけではだめだ

結局、システム年は変更したものの、今あるテストデータは、1998年のもの。これを、1999年や2000年にしなくては、アプリケーションテストが出来ない。ああ、面倒だな。これから、データを入力しては、日締め処理を毎日繰り返す予定。最後の、心臓破りの坂が、待っていた。

1998/10/7

続く... 


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

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

 

Ads by TOK2