|
2000年問題修正の根本は、その解決方法により違いますが、データベースを年4桁にするならば、予めどんなものを修正すべきか、覚悟をしておく必要があります。
後で気づいて、やり直すのは労力の無駄です。ここに記すのは、もちろん今現在気づいている点だけです。他にもあるでしょう。
 データファイル
- フィールドの桁数の修正。年月日なら8桁へ、年月なら６桁へ、年だけなら４桁へ。できたら、編集ワードも付けておくと、QRYなどで楽になるでしょう。SSTやSELECT,OMITの内容にも注意です。
画面ファイル
- 参照フィールドにしていると、当然桁数が増えるので、別のフィールドと重なったり、EDTCDE(Y)もエラー※になるでしょう。
- データは8桁で、表示や入力を6桁にすると、レイアウトの変更は起こりません。でも、画面フィールドは、データファイルのフィールドとは違う名前でないと、RPGのコンパイルエラーとなります。それから、名前を変えたならば、当然、転送命令が必要です。何らかの都合で、日付を文字にしている場合は、MOVELではなくMOVEにしなくてはなりません。さらに、入力の場合は、足りない頭２桁を補う処理が必要です。
- すべて8桁とするか、表示は6桁、入力は8桁がいいでしょう。
 - ※DDSの中で、8バイトの数字フィールドにEDTCDE(Y)をつけると、コンパイルエラーで、CPD7560（編集コードYには、3-7桁のフィールド長が必要）というエラーになります。しかし、RPGのプログラムでo仕様書に8バイトの数字を定義して、編集コードYにしても、エラーになりません。DDSのエラーは、編集語で、解決しましょう。
OQPRINT H 101 1P
O .......
O O1DAT8Y 52
印刷ファイル
- これも、すべて8桁を基本としたいのですが、結構198ぎりぎりも多いのです。こんな場合は、もう6桁にしてしまいます。
QRY,DFU
- DFU,QRYの修正は、面倒です。今のところ、DFUやQRYが参照するファイルを一覧するプログラムが見つからないのです。DSPPGMREFでは検索してくれません。まあ、ファイル名をQRY名やDFU名に含めていれば、楽でしょう。
※追記：QRYの定義内容の取り出し方法がありました。
RPG
いろいろあると思いますが、無限に修正項目があるわけではありません。問題は修正しなくても、コンパイルが通ってしまうことです。実行して、結果をみて、あらら、ということに気づくのです。テストがとても重要です。なめてかかってはいけません。
- 日付のワークフィールドの桁数
- 日付を分解するＤＳの桁数
- 年月をセットする配列の桁数
- 日付がキーの時のKLISTの桁数
- パラメータの桁数
- 2つの日付の比較のときの、各々の桁数（同じでなくては当然だめ）
- UDATEならば*DATEへ、またTIME命令は桁数を14バイトへ
- 一時凌ぎに、年が40以下なら19000000をたして、それ以外なら20000000を足していた部分を無くす。（しょうがない時は残す。）
ほか
CLP
- 日付ののワークフィールドの桁数
- OPNQRYFのQRYSLT文
- CPYFのINCRELなど
- パラメータの桁数
- CVTDATの桁数
- 他
考えただけで気が重くなりますね。でも機械的に出来る方法を取った方がよさそうです。一本一本にそんなに時間がかけられないのですから。
| 
