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

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

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

    僕が耳にした噂では、旧富士は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とか…のアドレス??)」が
                > どう対応するかってのが、わかりにくくなっていると思います。

                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:
                > もしやと思うけど念のため。
                > 「構造化」言語かどうかは関係ないですよね。

                「構造化言語」と書いたのは COBOL や FORTRAN(77) のような「構造化」以前の言語と、C/C++ のようなプロシージャの呼び出し毎に独立したローカル変数を作る言語を区別したいと意図したためです。
                プログラム言語の区分的には正しくないですねぇ。

                # 構造化言語の肝は、結局再帰的に呼び出し可能なプロシージャで、
                # コンパイラ言語でこれをスタックを使って実装していますから、、、
                --
                コンタミは発見の母
                親コメント
              • 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" という名前から予想するに、実装的にはフレームをポップする
                時にはスタックが飛び地になっていないかどうか確認し、フレームをプッシュする
                ときに自分のフレームより下位のメモリアドレスが使用済みでないかのチェックを
                入れながら使うのでしょうね。
                結構、重い処理になりそうですねぇ。
                --
                コンタミは発見の母
                親コメント

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

処理中...