想定しないで日付を検索
最近、誰か他の人が作成した CL コードをたくさん読んでいるのですが、正直に言って欲求不満になっています。なぜ CL プログラマーはシステム日付について頑固にあれこれ想定するのでしょうか。さらに言えば、ジョブ日付についてもそうです。何度も何度も目にするのです。CL プログラムは日付を検索しなければならず、日付が特定のフォーマットになるよう無差別な想定をします。こうしたプログラマーは、システム日付の形式が変わる可能性があることをわかっていないんじゃないでしょうか。通常、米国では、日付形式は m/d/y に設定しますが、ヨーロッパではほとんどの国で d/m/y が好まれ、y/m/d という形式を使用する人もいます。
これで、なぜ人は想定するのかわかりました。結局、ほとんどの CL プログラムは企業内で使用するよう作成されているのです。自分のショップにその日付形式を変更するよう期待する人がいるでしょうか。しかし、日付形式を変更する場合、無理やり日付を処理するあらゆるプログラムを見つけ出し、それを修正したいと本当に思いますか。つまり、山のようなコードがあるわけです。少なくとも私のショップでは。あらゆるものを探す努力は法外な値段になり、ましてやそれを修正してテストするなど何をか言わんや、という感じです。安全に日付を検索するのは驚くほど簡単なので、なぜ皆それをしないのか理解できません。
CL プログラムに安全に日付を検索させるには、まずその日付を検索し、Convert Date (CVTDAT) コマンドを使用して必要なフォーマットに変換します。ほとんどの人は、CVTDAT で日付をあるフォーマットから別のフォーマットに変換できることを知っています。十分に簡単です。単純に、入力日付形式と出力日付形式を教え、手品を使うのです。しかし、CVTDAT が日付形式に *SYSVAL および *JOB を受け入れることができるとは気が付いていなかったかもしれません。それだから、努力しなくても日付を安全に検索できるのです。
例えば、システム・クロックからシステム日付を検索するとしましょう。プログラムのロジックでは、日付は YYYYMMDD 形式でなければなりません。よく目にするコードの悪い例を下に示します。
PGM
DCL VAR(&SYSDATE) TYPE(*CHAR) LEN(6)
DCL VAR(&YYYYMMDD) TYPE(*CHAR) LEN(8)
RTVSYSVAL SYSVAL(QDATE) RTNVAR(&SYSDATE)
CHGVAR VAR(&YYYYMMDD) VALUE('20' *CAT %SST(&SYSDATE 5 2) +
*CAT %SST(&SYSDATE 1 4))
オェ! ゲッ! クー! ウェー!という感じです。
このコードでは、日付形式が常に *MDY になると想定しているだけでなく、世紀も常に 20xx になると想定しています。われわれは Y2K から学んだはずでしょう。私なら、次のようにコーディングするよう提案します。
PGM
DCL VAR(&SYSDATE) TYPE(*CHAR) LEN(6)
DCL VAR(&YYYYMMDD) TYPE(*CHAR) LEN(8)
RTVSYSVAL SYSVAL(QDATE) RTNVAR(&SYSDATE)
CVTDAT DATE(&SYSDATE) FROMFMT(*SYSVAL) +
TOVAR(&YYYYMMDD) TOFMT(*YYMD) TOSEP(*NONE)
前のコードのほうが読みやすく、システム日付のフォーマットをあれこれ想定していません。システム日付が変更されても、このコードは以前のように動作し続けます。また、現在の世紀についてもあれこれ想定していません。すごく単純なのです。どうして皆こうやらないのでしょうか。
同じように、(システム日付の代わりに) ジョブ日付が必要な場合は、次のようにコーディングできます。
PGM
DCL VAR(&JOBDATE) TYPE(*CHAR) LEN(6)
DCL VAR(&YYYYMMDD) TYPE(*CHAR) LEN(8)
RTVJOBA DATE(&JOBDATE)
CVTDAT DATE(&JOBDATE) FROMFMT(*JOB) +
TOVAR(&YYYYMMDD) TOFMT(*YYMD) TOSEP(*NONE)
これ以上難しくないなら、なぜ正しくやらないのでしょう。
