  |
作ったやつが元号でいいやと判断したら元号で取り扱う。そして、システムの修正というのは大きな手間がかかる。
例えば、昭和40年に最初にシステムを作ったとする。昭和が終わるのは遠いと感じるだろうし、当時は本当にITの様々な作りやすい方式なんてのもなかった。データ量の制約も厳しく、西暦の4桁ですらロスに感じた。
そうして昭和64年に元号が変わったが、昭和1－39年は使ってなかったから、昭和1－39年を平成に充てた。
で、令和になったが、さて、その年度は何年で取り扱うのかな？
ってか、そもそも、昭和1－39年のイレギュラーケースとして平成1－39年だとしていたことに気付けるかな？
うん、かなーりお馬鹿なケースだと思うし、銀行系でここまでザルなことはしてないとは信じたいが、関連しているシステムのどれか一つがこう言うバカな処理をしてたら、、、、？
いやいや、今見えている、元号表記の不具合という状況から察するに、だよ 勘定系の処理でわざわざ元号日付を使うかね
昭和に作られたシステムが噛んでたらあり得るかもね。 平成に代わるときになおざりな改修でごまかしてそのまま忘れ去られて、令和に代わるときに炎上したというのもありえる。 えて...
勘定系で元号日付を使うかどうかについてが、昭和にシステムが作られたか平成にシステムを作られてかで違ってくるん？あまり想像つかないけど
昭和に作られて、内部日付を昭和で取り扱ってるんだよ！
なんで勘定系処理の内部日付を元号で持っていると思うわけ？元号を何に使うん？
作ったやつが元号でいいやと判断したら元号で取り扱う。そして、システムの修正というのは大きな手間がかかる。 例えば、昭和40年に最初にシステムを作ったとする。昭和が終わるの...
西暦から和暦に変換することでソースが長くなるし、CPU時間も食うよね データなんて外部媒体があるわけだし、西暦と和暦で2桁しか変わらないんだからCPUのほうがよっぽど気を使うべき...
君が「いや違う」と反論したって意味がないんよ。 事実、古いシステムだと内部を昭和で取り扱ってる。 ITが進展して、西暦のほうが使い勝手がいいから、西暦で当たり前だろって、今...
へえそうなのか、それはすまなかった。 わざわざ西暦のマシン日付を和暦に変換して使ってたのか。奇っ怪だなあ
横だけどメインフレーム＋COBOLの環境は我々の身近な環境とは相当違うぞ
オンラインが始まった当初はメモリがなにより節約対象やったんやで CPU時間が長くなろうが人間なんて待たせとけばええしな
横だけど当時の一時しのぎな発想を垣間見れた感じで面白い ありそう
全銀データは和暦使ってるけど内部的には西暦だろうね 今どき内部的に和暦を使ってるとも思えないけど
だよなあ いちいち西暦を和暦に変換する必要性が思いつかない 帳票に打つ処理なら分かるけど、それはそれで別のシステムだろうしなあ
togetterのアレは、コレでしょうね。 http://www.tottoribank.co.jp/oshirase/other/kaigen_07.pdf
ああ、大したことがなくてよかった。つーか、今でも和暦使うなよとは思うが、鳥取の地方銀行ってことはシステム改修費ケチったのかもなぁ。
総動員したところで昭和→平成対応をした連中は軒並み退職してる頃合いだから、 ソースコード（もしかしてCOBOL？）を今の現役連中が解読するところから始めるのかな。 もう無理じゃ...
13
