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