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

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

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

    僕が耳にした噂では、旧富士は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とか…のアドレス??)」が
                どう対
              • by Anonymous Coward on 2002年04月15日 19時12分 (#82428)
                全クラスの全フィールドを const にしておいて、値を書き換える
                必要が出たら全て new し直して新しい値を代入し、previous_value
                とかいうフィールドに前のオブジェクトを繋いでおくとか?…遅そう。
                親コメント

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

処理中...