パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

依然として続くみずほ銀行基幹系障害」記事へのコメント

  • みずほ、みずほ、と連日騒がれてますが、今回のシステム統合を担当した業者があまり前面に出てこないような気がするのは単に僕が世間のニュースに疎いせいですか?

    僕が耳にした噂では、旧富士はI社のシ
    • by who-am-i (2922) on 2002年04月09日 9時30分 (#79852)
      ちょっと探したけど、web上では見つからないので勘弁。
      少し前の朝日新聞の記事によると、よく言われるように全部 ベンダ任せなんじゃなくて、銀行業務の基幹部分はそれぞれの銀行内 のシステム部門が担っているそうで、その部分は非公開なために ベンダ各社もとっても仕事を進めにくい、それが原因でトラブルが起こったんだとか。

      だとすると、

      >今回のシステム統合を担当した業者があまり前面に出てこないような気がする

      にもうなずける気がする。
      もちろん黒幕である銀行は自分の非を大きくは認めないだろうし、ベンダ各社もうんざりしながらも顧客(銀行)のことを責めるわけにはいかないだろうし。
      親コメント
      • by Anonymous Coward
        > 銀行業務の基幹部分はそれぞれの銀行内 のシステム部門が担っているそうで、その部分は非公開なために ベンダ各社もとっても仕事を進めにくい

        統合しようってのに非公開とはどゆこと?
        システム部門は統合されないわけ?

        非公開→公開したくてもできない→仕様書がない→いゃぁーっ
        • by Anonymous Coward on 2002年04月09日 10時48分 (#79881)
          銀行案件がきたときに、打ち合わせで実際に出た話では、

          >> 銀行業務の基幹部分はそれぞれの銀行内 のシステム部門が担っているそうで、その部分は非公開なために ベンダ各社もとっても仕事を進めにくい

          これは無いっす。

          >統合しようってのに非公開とはどゆこと?
          >システム部門は統合されないわけ?

          統合されます。<案件内容の通りならね

          でも、Cobolを生かしたまま、Javaへ移行ってのが絶対条件だったのと、
          去年の6月に出た案件(11月まで案件が生きていた)だったので、時間的に絶対無理と判断して
          受けなかった経緯がありますです。しかも人/月単価が滅茶苦茶安かったし(笑)
          まー今年の4月って時間を切った時点で、ダメダメなシステムになるのは火を見るより明らかだったな・・・。
          更に、2500人/月のPGとSEで1年が必要だと言いながら、半分以下の人数で半年って・・・
          GOを出したTOPが馬鹿なだけだと思うっす。
          親コメント
          • by Anonymous Coward
            いまだにCOBOLを捨てきれてないのか・・・ COBOL+ASMのシステムなんか捨て去って 新たに書き起こした方がどれだけ効率的か・・・
            • 勘定系の業務プログラムとかならば、COBOLの方が良いという場合もあるんじゃないかなぁ。
              親コメント
              • by es++ (5434) on 2002年04月09日 13時57分 (#79969) 日記
                具体的な勘定系でのcobolの他言語に対するアドバンテージってのはどのようにお考えでしょう?
                ワタクシですと、勘定系でのcobolの利点というと数値の10進数型くらいしか思い浮かばないので。
                # それでもJavaですともう標準でにたようなもの [sun.com]ありますし。

                ワタクシが思うに、世のcobolプログラムの半数は『cobolで書いた方が良い』ではなくて、『cobolで既に書いちゃったからcobolのままの方が良い』あたりかしら、と。

                同僚のヒトのオコトバ。
                『cobolは永遠に不滅です。ソレが良き事か悪しき事かはさておき。』
                親コメント
              • by NO DATA (7774) on 2002年04月09日 14時03分 (#79972)
                メインフレーム系は専門外なのでよくわからないんですが、COBOLの処理系がDB構造と一体化してて、そっちがスキル的/時間的に新システムに落とし込めないと判断したのでは。
                  インターフェースの統合より手間暇かかりそうですし。
                親コメント
              • by Anonymous Coward
                私も同意。

                COBOLや汎用機のASMが勘定系に強いのは10進の計算に強く、2進では小数点下の計算が使い物にならない所にあります。

                JAVAって10進計算はどの程度使い物になりますか?

                どの言語でも内部10進演算のルーチンを用意してやりゃ一緒だけどね。
              • JAVAって10進計算はどの程度使い物になりますか?

                どの言語でも内部10進演算のルーチンを用意してやりゃ一緒だけどね。

                一応使えます。JDK 1.1 から COBOL などの勘定系を意識したのだと思うのですけど java.math.BigDecimal で、一通りの10進計算はできるようになっています。

                ほかの方も言ってましたけど、数億件のトランザクション処理となると心配になるかもしれません。(一応スケーラビリティは良くなってきてる。)できないわけじゃないです。

                親コメント
              • by Anonymous Coward
                しっかり設計をやって、人材も豊富に投入出来たとしても、JavaはCOBOLよりは重くなってしまいます。これが高トランザクションなシステムでは致命傷になります。みずほ銀行くらいの規模になると、Javaでやると「要
              • 何と言っても殆どのCOBOLコンパイラは、コンパイラ自身のバグを気にしなくて済む。(10数年前に初めてC言語をいじった時は自分のコーディングが悪いのか、コンパイラが悪いのかで結構悩むことがあった)。
                後は数値編集項目とかがあって、画面や帳票の作成が楽とか、COBOL85からは数値編集項目から数値項目へのMOVEが可能になって、既存システムをネットワークを使って分散化するときに役立ったとか。

                そう言えば「国内の規格で表示された製品名を海外用の規格に自動変換しろ」と言われて、STRING,UNSTRING,INSPECT命令使いまくりでLispのcar,cdr,appendに相当する機能作ったなあ。
                親コメント
              • ミッションクリティカルなプログラムではスタック機構由来の局所変数がないことがアドバンテージになると聞きます。

                障害発生時が発生した場合には可能な限り早くバグの原因を特定して修正を行う必要があります。しかし、再現性のない、あるいは 再現させるためにもう一度プログラムを動かすことが許されないような状況で バグを発見・修正しなくてはならないという局面に立たされた場合どうします?

                スタック変数のない COBOL だとコア(メモリイメージ)さえ入手できればプログラムのどこにバグがあったのか なんとか追跡可能です。

                スタックの存在を前提とした構造化プログラム言語の場合はそうはいきません。「前の関数呼び出しの時のメモリの状態を知りたい」と思っても、スタックは別の関数呼び出しによって塗りつぶされているという状況になります。

                Java のようなガーベージコレクションのある言語はさらに悲惨ですよ。
                Java のバグって 潜伏期間中に GC が起こって それがトリガーになってバグが発火するという状況が多いのですが、 この場合 GC 後の ヒープイメージがあってもほとんど使えません。

                Java の場合 それ以外にも GC のおこる時間が予測できなくて酷い時には 10秒ぐらい止まってくれるとか、スケーラビリティーが全然ないとか色々問題があるのですが...
                --
                コンタミは発見の母
                親コメント
              • シーケンシャル処理からぬけだせないマスターファイル、固定長レコードのバッチ処理バリバリ、一度に数十のデバイス上に散在するファイルを更新。

                これを書き換えることのアドバンテージが見出せないだけではないかなあ。

                もちろん、COBOLの実行環境となる汎用機は10進命令が機械語レベルで用意されている、なんつーのもあるにはありますが。
                --
                みんつ
                親コメント
              • 普通、どんな変数も書き換えられるからローカルだからってのは
                関係無いと思う。大域変数でも以前の値は現在値に書き換えられてるので同じですね。
                それに現在実行中の関数でエラーが出てそのエラーが前に実行
                された関数と関係が有るって事は何らかの状態を前に実行された
                関数から引き継いでいるのだから十分追跡可能でしょう。GCがトリガーと成って表面
              • > 普通、どんな変数も書き換えられるからローカルだからってのは
                > 関係無いと思う。大域変数でも以前の値は現在値に書き換えられてるので同じですね。
                いえオブジェクトの可視(visible)/不可視(invisible)を問題にしているのではなく、
                オブジェクトの寿命(life time)が問題なのです。
                # だからローカル変数と書かずにスタック変数と書いたのに、、、

                COBOL → 構造化プログラム → Java になるに従って、オブジェクトの消滅が
                implicit になっていくのが障害対策を考えると問題だという話です。

                > それに現在実行中の関数でエラーが出てそのエラーが前に実行
                > された関数と関係が有るって事は何らかの状態を前に実行された
                > 関数から引き継いでいるのだから十分追跡可能でしょう。
                絶対に不可能とはいいませんが、現場でやるのは無理でしょう。

                    int result = do_work();
                    destroy_stacks_functions();
                    // ここでメモリダンプ

                do_work() が使ったスタック領域は、destroy_stacks_functions() が
                呼び出されることによって破壊されます。
                手元に残ったメモリダンプだけで、do_work がどのように動作したの
                か類推できますか?

                > GCがトリガーと成って表面化するバグってどんなバクでしょう?
                > 参考のために是非教えてください。
                色々パターンがあるのですが、私が一番 頻繁に遭遇するのは JavaVM
                あるいは JNI のコードがバグのため dangling pointer を作る場合です。
                --
                コンタミは発見の母
                親コメント
              • by G7 (3009) on 2002年04月14日 14時05分 (#82014)
                >オブジェクトの寿命(life time)が問題なのです。
                ># だからローカル変数と書かずにスタック変数と書いたのに、、、

                >COBOL → 構造化プログラム → Java になるに従って、オブジェクトの消滅が
                >implicit になっていくのが障害対策を考えると問題だという話です。

                それを問題だと呼ぶならば、もうひといき言って、
                変数とobjectの対応(寿命とか)関係がimplicitになっているかどうか?も
                ここでいう「問題」に、関わっていると思います。

                javaみたいな参照だらけの言語だと、「変数を」ダンプしてみても、
                その変数が意味する「値(objectとか…のアドレス??)」が
                どう対応するかってのが、わかりにくくなっていると思います。

                そういう意味では、スタック変数が無いというよりも、「変」数が無い言語を使うことを考えるほうが、
                より正解に近かったりしませんか?
                関数型言語とか。

                よだん:
                スタックかどうか、ではなく、スタックを「使いまわす」かどうかが問題なのでしょうね。
                lispのlist経由の情報やりとりみたいなやりかたならば、
                Cとかだとスタックが担う役割をlistが負うわけで、
                そのlistを使いまわさない(一度しか使わない)ようにするのは
                きっとなんとか出来ることですよね。
                んで一度だけ使ったlistは別途なんらかの機構を用意して
                ログとして情報を記録しておくようにすれば…。

                よだん2:
                もしやと思うけど念のため。
                「構造化」言語かどうかは関係ないですよね。
                親コメント
              • 全クラスの全フィールドを const にしておいて、値を書き換える
                必要が出たら全て new し直して新しい値を代入し、previous_value
                とかいうフィールドに前のオブジェクトを繋いでおくとか?…遅そう。
              • >> COBOL → 構造化プログラム → Java になるに従って、オブジェクトの消滅が
                >> implicit になっていくのが障害対策を考えると問題だという話です。
                > それを問題だと呼ぶならば、もうひといき言って、
                > 変数とobjectの対応(寿命とか)関係がimplicitになっているかどうか?も
                > ここでいう「問題」に、関わっていると思います。
                > javaみたいな参照だらけの言語だと、「変数を」ダンプしてみても、
                > その変数が意味する「値(objectとか…のアドレス??)」が
                > どう対応するかってのが、わかりにくくなっていると思います。

                JavaVM 側でバグが起きてヒープを破壊した場合にはその通りなのですが、アプリケーション側で起きたバグや未補足な例外を追っている際には Java が参照だらけということはあまり問題にならないと思います。
                JavaVM の実装に依存しますが、Java のオブジェクトのメモリイメージには所属クラスへの情報が C++ の VTBL ポインタのような形で入っていまので、C++ のデータのメモリイメージを見るよりもむしろ楽だというのが実感です。

                > そういう意味では、スタック変数が無いというよりも、「変」数が無い言語を使うことを
                > 考えるほうが、 より正解に近かったりしませんか?
                > 関数型言語とか。

                プログラムの堅牢性という意味では関数型言語でいいのかも知れませんが、関数型言語は書きづらいのが難点で。。。
                特にエンタープライズ系の業務に使おうとするとデータベースとの相性が問題になると思うのですが、関数型言語とデータベースは相性が悪いと言うイメージを私は持っていますが本当はどうでしょうか?
                # 関数型言語でコミットやロールバックを記述するのってどうやるのだろう?

                > よだん:
                > スタックかどうか、ではなく、スタックを「使いまわす」かどうかが問題なのでしょうね。
                > lispのlist経由の情報やりとりみたいなやりかたならば、
                > Cとかだとスタックが担う役割をlistが負うわけで、
                > そのlistを使いまわさない(一度しか使わない)ようにするのは
                > きっとなんとか出来ることですよね。

                スタックは Last-In Fast-Out のルールで使いまわすメモリ領域を指すので、
                「使いまわさない」スタックというのは考え難いのですが...

                <余談>
                    スタックがメモリを「使いまわす」のにはメモリ空間の効率性を高める
                    以外にも巨大なメリットがあります。プログラムの実行はマイクロプロ
                    セッサが担っていますが、そこではキャッシュミスペナルティが常に問題
                    になっています。
                    スタック型メモリ管理がメモリを「使いまわす」ことによってキャッシュ
                    の空間・時間的局所性が高まり、高速動作が可能になっています。

                    プロセッサもスタックの存在を強く意識しています。例えば x86
                    系の石は極小の L1 データキャッシュを高速で動かすことによってスタック
                    をレジスタの延長のように使おうとしています。
                    逆に、レジスタをスタック的に使おうとする SPARC や IA-64 のような
                    石もあります。
                </余談>

                私の知っている Lisp の実装系の多くは Garbage Collection によってメモリを管理していますし、Java のパラメータスタックのようなインタプリタスタックを持っています。
                このような実装の Lisp では スタックフレーム中にスタック変数を作る代わりに、すべてのオブジェクトを(GC の対象となる)ヒープ空間中に作っています。結局 このような Lisp の実装系はプリミティブ型のローカル変数を禁じた Java と同じような実行イメージで処理されることになります。
                でも、それではかえってデバッグしづらいです。

                スタックのようにローカル変数を含んだフレーム領域をメソッドの終りでパージしないデータ構造を考えることも出来ます。
                例えば親メソッドのフレームへのポインタを保持した linked frame 構造でフレームを管理し、メソッドが終了する時には対応するフレームを FIFO のフリーリスト(フリーフレーム?)に繋げてやります。
                フリーリストの長さが N であれば、N 回まえに実行したメソッドの履歴が残るので、その分までローカル変数を覗き見ることが可能になります。
                このようなデータ構造は Lisp でも Java でも実装可能です。

                # でもメモリ効率やキャッシュ効率が悪くなるし、分岐が増えちゃうので誰もやらない。

                > よだん2:
                > もしやと思うけど念のため。
                > 「構造化」言語かどうかは関係ないですよね。

                「構造化言語」と書いたのは
                --
                コンタミは発見の母
                親コメント
              • by G7 (3009) on 2002年04月17日 1時39分 (#83002)
                >JavaVM の実装に依存しますが、Java のオブジェクトのメモリイメージには所属クラスへの情報が C++ の VTBL ポインタのような形で入っていまので

                クラス情報の有無はまた別の問題であるような気もしますが、それはともかく、
                スタックとヒープの両方をいっしょにダンプしとけば、ポインタを追跡するだけで済む、
                という話でしょうか? だとすればナルホドです。

                >関数型言語でコミットやロールバックを記述するのってどうやるのだろう?

                俺もさっぱり知りません。どうするんでしょうね?(^^;

                普通のやつらの上を行け [dreamhost.com]では、もろにエンタープライズな(^^;webアプリ分野でLispを使った話が紹介されてますが、
                これってDBはどうしたんだろう?ってのは俺も疑問に思っています。
                ぜんぶオンメモリだったんだろうか???

                話は飛びますが、ログというかジャーナリングって、関数型言語のメモリ(?)の使いかたと
                似ているような気がしたのは気のせいでしょうか?
                ええ。いっそのこと「関数型データベース」とかいうものを考えたほうが話が早い
                んじゃなかろうか?と一瞬思ったりしています。

                >スタックは Last-In Fast-Out のルールで使いまわすメモリ領域を指すので、
                >「使いまわさない」スタックというのは考え難いのですが

                ええ。それはもはやスタックと呼びにくいものだ、と俺も思います。

                >でも、それではかえってデバッグしづらいです。

                言われてみれば、「一番(乱暴な例として)」デバッグしやすいメモリ使用形態ってのが
                どんなものなのかってのは、考えたことが有りませんでした(^^;;;;;;;;

                >フレーム領域をメソッドの終りでパージしないデータ構造

                うわー……
                蛇足ですが仕事でいじってた某環境で、関数呼び出し履歴がログファイルにどんどん追記
                されてく奴がありまして、当然ですがあっという間に巨大なファイルになっちゃってくれまして…
                親コメント
              • >>関数型言語でコミットやロールバックを記述するのってどうやるのだろう?
                > 俺もさっぱり知りません。どうするんでしょうね?(^^;

                APIレベルの話なら、たとえばFranz Inc. [franz.com]の AllegroStoreでは

                (with-transaction () ... DB処理 ...)

                と書いておくと、処理が正常に終了すればコミット、 例外が投げられた場合はロールバックされます。 実装レベルではunwind-protectでやっているのでしょう。

                >>スタックは Last-In Fast-Out のルールで使いまわすメモリ領域を指すので、
                >>「使いまわさない」スタックというのは考え難いのですが
                >ええ。それはもはやスタックと呼びにくいものだ、と俺も思います。

                フレームはスタック領域に取っても、状況に応じてフレームをポップしない、という実装はありますね。例えば継続が捕捉されたらその時点でスタックにあるフレームはポップしないようにするとか。 スタックが溢れたらそこでGCを走らせて、生きているフレームをヒープに移すと。それを応用すれば、モニターしたい部分だけはフレームを残しておくなんてことも不可能ではないでしょう。 Cf. Scott L. Burson: "Continuations Without Copying", SIGPLAN Notices, 29(5), pp.27-30, 1994.

                親コメント
              • > フレームはスタック領域に取っても、状況に応じてフレームをポップしない、という
                > 実装はありますね。例えば継続が捕捉されたらその時点でスタックにあるフレームは
                > ポップしないようにするとか。 スタックが溢れたらそこでGCを走らせて、生きている
                > フレームをヒープに移すと。それを応用すれば、モニターしたい部分だけはフレーム
                > を残しておくなんてことも不可能ではないでしょう。
                > Cf. Scott L. Burson: "Continuations Without Copying",
                > SIGPLAN Notices, 29(5), pp.27-30, 1994.

                あぅ。遅いフォローですいません。
                上記の論文を探したのですが、SIGPLAN Notices は ACM の DIGITAL LIBRARY では
                読めないし、近場にも 94年のものはすでに取ってなかったので読めませんでした。

                "Without Copying" という名前から予想するに、実装的にはフレームをポップする
                時にはスタックが飛び地になっていないかどうか確認し、フレームをプッシュする
                ときに自分のフレームより下位のメモリアドレスが使用済みでないかのチェックを
                入れながら使うのでしょうね。
                結構、重い処理になりそうですねぇ。
                --
                コンタミは発見の母
                親コメント
            • やはり難しいのではないかと・・・。適用業務専用のCOBOLと汎用言語では生産性も保守性も違うでしょうからねぇ。
              COBOLでOS作らない(作れない)のと同じで、勘定系をCでは書かないんでしょうね。
              ましてやJavaなんて一日何千万件、へたすりゃ何億件もあるトランザクションはさばけないでしょう。

              技術的なアプリはASM(随分昔の話ですが)からCへうまく移行していきましたが、
              事務的はアプリはCOBOLから次のステップに移れてないと思います。

              #ちょっと話の内容がそれてきましたか?すまそ
              親コメント
            • by sinn (8383) on 2002年04月09日 15時02分 (#79996) ホームページ
              効率的とは何に対しての効率でしょうか?
              業務処理の効率なのかメンテナンスの効率なのかいまいち不明です。

              銀行業務などではメンテナンス効率も大切でしょうがそれ以上に
              業務処理の効率&安定性が大事だと思いますよ。
              今までに相当の実績があるCOBOLを捨てて新しいもの(JAVAとか)
              を使うのであれば、そっちのほうが問題だと思います。
              親コメント
            • by Anonymous Coward
              COBOLしか出来ない人を捨てきれないのでは?
              大量に捨てるとなると生ものだし大変だ。。。。

              COBOLを生かしながらJavaに書き換えってどういう
              事だろう???
              すでにこの時点で死亡確定?

              COBOLな人たちをJava使いに改造するのに手間取ったとか。。
              • by Anonymous Coward on 2002年04月09日 12時52分 (#79928)
                COBOL が捨てられないというよりは

                仕様書にも作成者の記憶にも存在しないのに
                COBOLソースの中に存在する
                謎のコード(業務仕様)が捨てれないのでしょう。
                親コメント
              • by Daicki (4060) on 2002年04月09日 23時34分 (#80193) 日記
                > COBOLを生かしながらJavaに書き換えってどういう
                > 事だろう???
                COBOLの既存の"資産"を生かしながら、
                全体としてはJavaで実装するというような話が、
                先月の情報処理学会の全国大会(?)で出てました。
                詳細は忘れましたが。
                親コメント
        • by dove (4947) on 2002年04月09日 16時27分 (#80020)
          最近はかなり基幹系が多い気がするけど。

          単にJava覚えられない化石ばかりで人材不足だと思うな。

          もちろん新しい単語ばかり作ってまともな環境作れてない、
          もしくはアンドキュメンテッドな仕様知らないと危なくて使えない
          そんなJAVA自体の状態があるのかも知れないけど。
          Javaにしろ、C++にしろ思想理解してる奴のいかに少ないことよ
          親コメント

人生unstable -- あるハッカー

処理中...