過去の桐井戸端ＢＢＳ　（桐ver.５）
5102 桐ver.３は２０００年問題に対応していますか？ みほ 2000/03/11-15:55
桐Ver.３では、２０００年問題を対応しているのでしょうか？
ご回答よろしくお願いします。

5103 Re 佐田　守弘 2000/03/11-21:56
記事番号5102へのコメント
みほさん
御質問の桐ver.3のY2K対応の件ですが、この問題に対する管理工研の正式コメントはないと思います。
桐ver.3が発売されたのが1989年頃だと思いますが、この頃のアプリなどでY2K問題を考慮しているものは
ほとんどなかったろうと思います。つまり、
「桐ver.3は、西暦二千年問題に対する考慮をしておりません。問題を起こすかどうかの確認もしておりません。」
という事になると思います。

では実際にはどうであるのかについて、私個人の見解を述べさせて頂きます。
もちろん桐ver.3で確認しているわけではないので、その点をお含みおき下さい。

■ MS-DOS版の桐の日付時刻の扱い方とY2Kの課題

●MS-DOS版桐での日付時刻の扱い方
まず最初に述べておく重要な事があります。
MS-DOS版の桐には、元来日付の概念がありません。
日付時刻を扱う機能が登場したのは、Windows版になってからの桐ver.6が初めてです。
それ以前の桐ver.5までは、日付文字列と言って、「昭和62年3月4日」あるいは「1988-9-10」の様な
単なる日付表記の文字列を文字列として扱うだけの機能しかありません。
そして、日付計算を行う時には、その中に含まれている数値を取り出して、日付や時刻の計算を行います。
この計算を行うのが日付処理関数、時間処理関数で、日差や時間差、あるいは日数や時間の加算などを行います。
ここで、年、月、日などのも時は単なる区切り記号であって、その意味の解釈も行いません（元号記号のみ解釈されます）。
ですから極端な話が、
　「１山５個１０円から３年９組18番までは何時間ですか？」
という計算をすると、２時間４分８秒の答えが返ってきます。

●Y2K問題を起こすかどうかはユーザーの課題
一番重要な事は、年号の扱い方を２年で扱うか、４年で扱うかの設定をどちらにしているかです。
４年で扱う方式にしてあり、年号データに４桁の年号が記録してあれば、2000年代の年号を1900年代の年号と
間違える問題は発生しません。しかし、２桁年号で処理している場合には、Y2K問題を確実に引き起こします。
つまり、現在のデータが４桁年号になっているかのチェックを行う事が必要です。

●気になるのは閏年の判定
４桁年号になっていれば日数計算や日付順での並べ替えに障害はありません。
しかし、今年の２月29日を閏年としてみなすかどうかの点ではチェックが必要です。
前述の様にMS-DOS版の桐での日付は単なる文字列ですから、2000年２月29日の入力は
問題なく行えます（13月32日といったあり得ない日付の入力も可能です）。
しかし、２月２８日から３月１日までの日数を２日と正しく計算するか、それとも2月29日がある事を忘れて、
１日と計算するか、ここがチェックポイントになります。
また、2000年2月29日から、あるいはこの日までの日数計算が正しく行えるかのチェックも必要です。
既に私の環境では桐ver.3を起動できないので、この確認は御自身で行って下さい。

佐田守弘(KS-00119)

私のHP「コンピュータ活用情報室(出版館)→「桐ver.5活用情報」→「西暦２千年問題と桐」に関連する情報を掲載して
あります。
桐ver.5の情報ですが、参考になると思います。

5109 Re みほ 2000/03/12-14:55
記事番号5103へのコメント
佐田守弘様、ご丁寧なコメントをありがとうございます。
こんなに親切なコメントを頂き、大変感謝しています。

アドバイスして下さったとおり、桐ver.５以降であればデータ年号を４桁で扱えば問題ないという
情報は知っていましたが、ユーザが年号を２桁で扱うか４桁で扱うかの意味がよく分かりません。
と言うのは、私が使用しているMS-DOS版の桐ver.３では、伝票を起こす画面を開くと現在日付で
年号の下２桁が自動表示（２桁の表示エリアしかない）されていまい、ユーザが４桁で扱う選択の余地がないのです。
現在は月次更新が出来ない状態で（99/11、99/12のデータがあるからでしょうね？）データが溜まる一方です。
日次更新は、何故か現在日付を1999/12/31に戻すと何とか出来ます。
もうバージョンアップするしかないと思うのですが、上記のような運用を現在まで続けてきたので
１月〜３月までに起こしたデータに関してはとりあえず上記のようにごまかし、ごまかし運用するしかないのでしょうね。

99/11、99/12のデータを自分で消去すれば、１月〜３月までに起こした伝票を1900年としてデータを扱い、
日次更新も月次更新も出来て正常に運用出来るのかなと思いましたが、どうやってデータを消去すれば良いかが
分かりませんでした。
いずれにしてもバージョンアップしようと考えていますが、99/11、99/12のデータを自分で消去する
という方法はいかがなものでしょうか？

古いシステムでレベルの低い質問ですが、何かアドバイスがあればよろしくお願い致します。

　　　　　　　　　　　　　Ｂｙ　みほ

5117 この２０００年問題は一括処理の問題 佐田　守弘 2000/03/12-17:19
記事番号5109へのコメント
みほさん

>情報は知っていましたが、ユーザが年号を２桁で扱うか４桁で扱うかの意味がよく分かりません。
の意味は、表の定義およびデータを表示する帳票画面、および表を扱う一括処理の上で、４桁日付で扱っているかと言う意味です。

今回のみほさんのケースでは、
>と言うのは、私が使用しているMS-DOS版の桐ver.３では、伝票を起こす画面を開くと現在日付で
>年号の下２桁が自動表示（２桁の表示エリアしかない）されていまい、ユーザが４桁で扱う選択の
>余地がないのです。
との事ですので、みほさん自身はどなたかの作られた一括処理を運用している事が分かりました。
つまり、この場合には、そのシステムを作った社内の人、あるいは納入したVAR業者さんがここで言う桐のユーザーという事になります。
ですからこの問題は、現システムを導入した段階、おそらくそれは1990年の頃に、2000年問題を考慮して表の定義や画面と印刷用の帳票の定義、一括処理の作成を行っておかなければならない問題でした。

従いまして、でき上がっている一括処理を運用しているだけの立場であるみほさんの立場で、でき上がってる一括処理を運用するだけの立場では、この問題を解決する事は大変に難しいと思います。
もし2000問題対応するとしたら、単に桐をバージョンアップすれば済む話ではなく、一括処理のプログラムの方も手直しをするか作り替える必要があります。
現在の桐の機能などの状況を考えれば、従来のデータを踏襲しながら、全く新しくシステムを組み直す事になると思います。
実際問題として、桐ver.3の状態では手直しのしようがないと考えられるからです。

この手直しは、そこそこの費用が掛ると考えておいて下さい。
みほさん御自身の手で手直しあるいは作り直しをする事も不可能ではないのですが、そのためには、桐に関してかなりのレベルまで勉強される必要があると思います。
みほさんがどの程度桐を扱える力量があるかを教えて頂ければ、それに合わせたアドバイスが可能かと思います。

●当面の対処方法として
>いずれにしてもバージョンアップしようと考えていますが、99/11、99/12のデータを自分で消去する
>という方法はいかがなものでしょうか？
それで取りあえず対処可能であれば、それも１つの方法です。ただし、マスタデータを消してしまうのは後々で困る事になると思います。
別のデータファイルとして保存しておくなり、何らかの方法で残しておかないと決算の時に困るはずです。

佐田守弘(KS-00119)
5153 Re:この２０００年問題は一括処理の問題 みほ 2000/03/13-21:26
記事番号5117へのコメント
佐田守弘様、今回も親切な回答をありがとうございます。

何が問題となっているのかが、やっと理解できました。
また、単に桐ソフトをバージョンアップするだけでは、解決できないのですね。
色々と検討してがんばってみます。

こんな無知な私の質問に色々と答えて下さって、誠にありがとうございました。

　　　　　　　　　　　　　By　みほ

戻る