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

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

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

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

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

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

        非公開→公開したくてもできない→仕様書がない→いゃぁーっ
        • by Anonymous Coward
          銀行案件がきたときに、打ち合わせで実際に出た話では、

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

          これは無いっす。

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

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

          でも、Cobolを生かしたまま、Javaへ移行ってのが絶対条件だったのと、
          去年の6月に出た案件(11月まで案件が
          • by Anonymous Coward
            いまだにCOBOLを捨てきれてないのか・・・ COBOL+ASMのシステムなんか捨て去って 新たに書き起こした方がどれだけ効率的か・・・
            • 勘定系の業務プログラムとかならば、COBOLの方が良いという場合もあるんじゃないかなぁ。
              • 具体的な勘定系でのcobolの他言語に対するアドバンテージってのはどのようにお考えでしょう?
                ワタクシですと、勘定系でのcobolの利点というと数値の10進数型くらいしか思い浮かばないので。
                # それでもJavaですともう標準でにたようなもの [sun.com]ありますし。

                ワタクシが思うに、世のcobolプログラムの
              • ミッションクリティカルなプログラムではスタック機構由来の局所変数がないことがアドバンテージになると聞きます。

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

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

                スタックの存在を前提とした構
                --
                コンタミは発見の母
              • 普通、どんな変数も書き換えられるからローカルだからってのは
                関係無いと思う。大域変数でも以前の値は現在値に書き換えられてるので同じですね。
                それに現在実行中の関数でエラーが出てそのエラーが前に実行
                された関数と関係が有るって事は何らかの状態を前に実行された
                関数から引き継いでいるのだから十分追跡可能でしょう。GCがトリガーと成って表面
              • > 普通、どんな変数も書き換えられるからローカルだからってのは
                > 関係無いと思う。大域変数でも以前の値は現在値に書き換えられてるので同じですね。
                いえオブジェクトの可視(visible)/不可視(invisible)を問題にしているのではなく、
                オブジェクトの寿命(life time)が問題なのです。
                # だからローカル変数と書かずにスタック変数と書いたのに、、、

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

                > それに現在実行中の関数でエラーが出てそのエラーが前に実行
                --
                コンタミは発見の母
              • >オブジェクトの寿命(life time)が問題なのです。
                ># だからローカル変数と書かずにスタック変数と書いたのに、、、

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

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

                javaみたいな参照だらけの言語だと、「変数を」ダンプしてみても、
                その変数が意味する「値(objectとか…のアドレス??)」が
                どう対
              • >> COBOL → 構造化プログラム → Java になるに従って、オブジェクトの消滅が
                >> implicit になっていくのが障害対策を考えると問題だという話です。
                > それを問題だと呼ぶならば、もうひといき言って、
                > 変数とobjectの対応(寿命とか)関係がimplicitになっているかどうか?も
                > ここでいう「問題」に、関わっていると思います。
                > javaみたいな参照だらけの言語だと、「変数を」ダンプしてみても、
                > その変数が意味する「値(objectとか…のアドレス??)」が
                > どう対応するかってのが、わかりにくくなっていると思います。
                --
                コンタミは発見の母
              • 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" という名前から予想するに、実装的にはフレームをポップする
                時にはスタックが飛び地になっていないかどうか確認し、フレームをプッシュする
                ときに自分のフレームより下位のメモリアドレスが使用済みでないかのチェックを
                入れながら使うのでしょうね。
                結構、重い処理になりそうですねぇ。
                --
                コンタミは発見の母
                親コメント

日本発のオープンソースソフトウェアは42件 -- ある官僚

処理中...