フレームはスタック領域に取っても、状況に応じてフレームをポップしない、という実装はありますね。例えば継続が捕捉されたらその時点でスタックにあるフレームはポップしないようにするとか。
スタックが溢れたらそこでGCを走らせて、生きているフレームをヒープに移すと。それを応用すれば、モニターしたい部分だけはフレームを残しておくなんてことも不可能ではないでしょう。
Cf. Scott L. Burson: "Continuations Without Copying", SIGPLAN Notices, 29(5), pp.27-30, 1994.
黒幕は誰だ？ (スコア:1)
僕が耳にした噂では、旧富士はI社のシステムで、旧一勧はF社のシステムだったが、統合の担当は1円入札とかやっちゃうH社だとか。
が、あくまで噂レベルなので、正確なところをご存知の方、詳しい情報をお願いします。
Re:だいたい予想通りだけど (スコア:2, 参考になる)
各行の担当者が、それぞれ案件を持ち帰って上にお伺いを立てなければいけないような状態だったとか。
強権のあるタスクフォースを編成してコトに当たる、という発想はできなかった、というあたりでもう終わっていたような気がしないではありません。
Re:だいたい予想通りだけど (スコア:0)
Re:だいたい予想通りだけど (スコア:0)
Re:黒幕は誰だ？ (スコア:1)
http://www.nikkei.co.jp/sp2/nt26/20020405kr545000_05.html
Re:黒幕は誰だ？ (スコア:3, 興味深い)
私も、担当業者がどうなっているかが気になっていたので、この記事では全くわかりませんでした。
本日の日経産業新聞の最終頁に詳細が書かれています。
Ｆ社が請け負うはずのところを、技術も無いのにＨ社がでしゃばって、トラブルが大きくなっているのに、
Ｆ社もＩ社も口を出せないようにしているらしいです。
でも、一番悪いのはやはり、みずほの情報システム部門の連中じゃないですかね。
Re:黒幕は誰だ？ (スコア:2, 興味深い)
というのであれば、納得。
Re:黒幕は誰だ？ (スコア:0)
Re:黒幕は誰だ？ (スコア:0)
Re:黒幕は誰だ？ (スコア:0)
あれぇ。Ｈの社員の人は「あまり絡んで無い（絡めなかった）」って言ってたんだけどなぁ。
こう言う事態になったら、誰も「俺がやった」とは言えないのかな
Re:黒幕は誰だ？ (スコア:0)
Re:黒幕は誰だ？ (スコア:0)
Re:黒幕は誰だ？ (スコア:1)
少し前の朝日新聞の記事によると、よく言われるように全部 ベンダ任せなんじゃなくて、銀行業務の基幹部分はそれぞれの銀行内 のシステム部門が担っているそうで、その部分は非公開なために ベンダ各社もとっても仕事を進めにくい、それが原因でトラブルが起こったんだとか。
だとすると、
>今回のシステム統合を担当した業者があまり前面に出てこないような気がする
にもうなずける気がする。
もちろん黒幕である銀行は自分の非を大きくは認めないだろうし、ベンダ各社もうんざりしながらも顧客(銀行)のことを責めるわけにはいかないだろうし。
Re:黒幕は誰だ？ (スコア:0)
統合しようってのに非公開とはどゆこと？
システム部門は統合されないわけ？
非公開→公開したくてもできない→仕様書がない→いゃぁーっ
Re:黒幕は誰だ？ (スコア:4, 興味深い)
>> 銀行業務の基幹部分はそれぞれの銀行内 のシステム部門が担っているそうで、その部分は非公開なために ベンダ各社もとっても仕事を進めにくい
これは無いっす。
>統合しようってのに非公開とはどゆこと？
>システム部門は統合されないわけ？
統合されます。＜案件内容の通りならね
でも、Cobolを生かしたまま、Javaへ移行ってのが絶対条件だったのと、
去年の６月に出た案件（１１月まで案件が生きていた）だったので、時間的に絶対無理と判断して
受けなかった経緯がありますです。しかも人/月単価が滅茶苦茶安かったし（笑）
まー今年の４月って時間を切った時点で、ダメダメなシステムになるのは火を見るより明らかだったな・・・。
更に、２５００人/月のＰＧとＳＥで１年が必要だと言いながら、半分以下の人数で半年って・・・
GOを出したTOPが馬鹿なだけだと思うっす。
Re:黒幕は誰だ？ (スコア:0)
Re:黒幕は誰だ？ (スコア:1)
Re:黒幕は誰だ？ (スコア:3, 興味深い)
ワタクシですと、勘定系でのcobolの利点というと数値の10進数型くらいしか思い浮かばないので。
# それでもJavaですともう標準でにたようなもの [sun.com]ありますし。
ワタクシが思うに、世のcobolプログラムの半数は『cobolで書いた方が良い』ではなくて、『cobolで既に書いちゃったからcobolのままの方が良い』あたりかしら、と。
同僚のヒトのオコトバ。
『cobolは永遠に不滅です。ソレが良き事か悪しき事かはさておき。』
Re:黒幕は誰だ？ (スコア:1)
インターフェースの統合より手間暇かかりそうですし。
１０進で計算 (スコア:0)
ＣＯＢＯＬや汎用機のＡＳＭが勘定系に強いのは１０進の計算に強く、２進では小数点下の計算が使い物にならない所にあります。
JAVAって１０進計算はどの程度使い物になりますか？
どの言語でも内部１０進演算のルーチンを用意してやりゃ一緒だけどね。
Re:１０進で計算 (スコア:1)
一応使えます。JDK 1.1 から COBOL などの勘定系を意識したのだと思うのですけど java.math.BigDecimal で、一通りの10進計算はできるようになっています。ほかの方も言ってましたけど、数億件のトランザクション処理となると心配になるかもしれません。(一応スケーラビリティは良くなってきてる。)できないわけじゃないです。
メリット軽いこと (スコア:0)
安定性と編集項目その他など (スコア:1)
後は数値編集項目とかがあって、画面や帳票の作成が楽とか、COBOL85からは数値編集項目から数値項目へのMOVEが可能になって、既存システムをネットワークを使って分散化するときに役立ったとか。
そう言えば「国内の規格で表示された製品名を海外用の規格に自動変換しろ」と言われて、STRING,UNSTRING,INSPECT命令使いまくりでLispのcar,cdr,appendに相当する機能作ったなあ。
スタック変数がない (スコア:2, 参考になる)
障害発生時が発生した場合には可能な限り早くバグの原因を特定して修正を行う必要があります。しかし、再現性のない、あるいは 再現させるためにもう一度プログラムを動かすことが許されないような状況で バグを発見・修正しなくてはならないという局面に立たされた場合どうします？
スタック変数のない COBOL だとコア(メモリイメージ)さえ入手できればプログラムのどこにバグがあったのか なんとか追跡可能です。
スタックの存在を前提とした構造化プログラム言語の場合はそうはいきません。「前の関数呼び出しの時のメモリの状態を知りたい」と思っても、スタックは別の関数呼び出しによって塗りつぶされているという状況になります。
Java のようなガーベージコレクションのある言語はさらに悲惨ですよ。
Java のバグって 潜伏期間中に GC が起こって それがトリガーになってバグが発火するという状況が多いのですが、 この場合 GC 後の ヒープイメージがあってもほとんど使えません。
Java の場合 それ以外にも GC のおこる時間が予測できなくて酷い時には 10秒ぐらい止まってくれるとか、スケーラビリティーが全然ないとか色々問題があるのですが...
コンタミは発見の母
Re:黒幕は誰だ？ (スコア:1)
これを書き換えることのアドバンテージが見出せないだけではないかなあ。
もちろん、COBOLの実行環境となる汎用機は10進命令が機械語レベルで用意されている、なんつーのもあるにはありますが。
みんつ
Re:スタック変数がない (スコア:0)
関係無いと思う。大域変数でも以前の値は現在値に書き換えられてるので同じですね。
それに現在実行中の関数でエラーが出てそのエラーが前に実行
された関数と関係が有るって事は何らかの状態を前に実行された
関数から引き継いでいるのだから十分追跡可能でしょう。GCがトリガーと成って表面
Re:スタック変数がない (スコア:1)
> 関係無いと思う。大域変数でも以前の値は現在値に書き換えられてるので同じですね。
いえオブジェクトの可視(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 を作る場合です。
コンタミは発見の母
Re:スタック変数がない (スコア:1)
>＃ だからローカル変数と書かずにスタック変数と書いたのに、、、
>COBOL → 構造化プログラム → Java になるに従って、オブジェクトの消滅が
>implicit になっていくのが障害対策を考えると問題だという話です。
それを問題だと呼ぶならば、もうひといき言って、
変数とobjectの対応(寿命とか)関係がimplicitになっているかどうか?も
ここでいう「問題」に、関わっていると思います。
javaみたいな参照だらけの言語だと、「変数を」ダンプしてみても、
その変数が意味する「値(objectとか…のアドレス??)」が
どう対応するかってのが、わかりにくくなっていると思います。
そういう意味では、スタック変数が無いというよりも、「変」数が無い言語を使うことを考えるほうが、
より正解に近かったりしませんか?
関数型言語とか。
よだん：
スタックかどうか、ではなく、スタックを「使いまわす」かどうかが問題なのでしょうね。
lispのlist経由の情報やりとりみたいなやりかたならば、
Cとかだとスタックが担う役割をlistが負うわけで、
そのlistを使いまわさない(一度しか使わない)ようにするのは
きっとなんとか出来ることですよね。
んで一度だけ使ったlistは別途なんらかの機構を用意して
ログとして情報を記録しておくようにすれば…。
よだん2：
もしやと思うけど念のため。
「構造化」言語かどうかは関係ないですよね。
ローカル変数禁止はもちろんとして、 (スコア:0)
必要が出たら全て new し直して新しい値を代入し、previous_value
とかいうフィールドに前のオブジェクトを繋いでおくとか?…遅そう。
Re:スタック変数がない (スコア:1)
>> 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：
> もしやと思うけど念のため。
> 「構造化」言語かどうかは関係ないですよね。
「構造化言語」と書いたのは
コンタミは発見の母
Re:スタック変数がない (スコア:1)
クラス情報の有無はまた別の問題であるような気もしますが、それはともかく、
スタックとヒープの両方をいっしょにダンプしとけば、ポインタを追跡するだけで済む、
という話でしょうか? だとすればナルホドです。
>関数型言語でコミットやロールバックを記述するのってどうやるのだろう？
俺もさっぱり知りません。どうするんでしょうね?(^^;
普通のやつらの上を行け [dreamhost.com]では、もろにエンタープライズな(^^;webアプリ分野でLispを使った話が紹介されてますが、
これってDBはどうしたんだろう?ってのは俺も疑問に思っています。
ぜんぶオンメモリだったんだろうか???
話は飛びますが、ログというかジャーナリングって、関数型言語のメモリ(?)の使いかたと
似ているような気がしたのは気のせいでしょうか?
ええ。いっそのこと「関数型データベース」とかいうものを考えたほうが話が早い
んじゃなかろうか?と一瞬思ったりしています。
>スタックは Last-In Fast-Out のルールで使いまわすメモリ領域を指すので、
>「使いまわさない」スタックというのは考え難いのですが
ええ。それはもはやスタックと呼びにくいものだ、と俺も思います。
>でも、それではかえってデバッグしづらいです。
言われてみれば、「一番(乱暴な例として)」デバッグしやすいメモリ使用形態ってのが
どんなものなのかってのは、考えたことが有りませんでした(^^;;;;;;;;
>フレーム領域をメソッドの終りでパージしないデータ構造
うわー……
蛇足ですが仕事でいじってた某環境で、関数呼び出し履歴がログファイルにどんどん追記
されてく奴がありまして、当然ですがあっという間に巨大なファイルになっちゃってくれまして…
Re:スタック変数がない (スコア:1)
> 俺もさっぱり知りません。どうするんでしょうね?(^^;
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.
Re:スタック変数がない (スコア:1)
> 実装はありますね。例えば継続が捕捉されたらその時点でスタックにあるフレームは
> ポップしないようにするとか。 スタックが溢れたらそこでGCを走らせて、生きている
> フレームをヒープに移すと。それを応用すれば、モニターしたい部分だけはフレーム
> を残しておくなんてことも不可能ではないでしょう。
> Cf. Scott L. Burson: "Continuations Without Copying",
> SIGPLAN Notices, 29(5), pp.27-30, 1994.
あぅ。遅いフォローですいません。
上記の論文を探したのですが、SIGPLAN Notices は ACM の DIGITAL LIBRARY では
読めないし、近場にも 94年のものはすでに取ってなかったので読めませんでした。
"Without Copying" という名前から予想するに、実装的にはフレームをポップする
時にはスタックが飛び地になっていないかどうか確認し、フレームをプッシュする
ときに自分のフレームより下位のメモリアドレスが使用済みでないかのチェックを
入れながら使うのでしょうね。
結構、重い処理になりそうですねぇ。
コンタミは発見の母
Re:黒幕は誰だ？ (スコア:1)
COBOLでOS作らない(作れない)のと同じで、勘定系をCでは書かないんでしょうね。
ましてやJavaなんて一日何千万件、へたすりゃ何億件もあるトランザクションはさばけないでしょう。
技術的なアプリはASM(随分昔の話ですが)からCへうまく移行していきましたが、
事務的はアプリはCOBOLから次のステップに移れてないと思います。
#ちょっと話の内容がそれてきましたか？すまそ
Re:黒幕は誰だ？ (スコア:1)
業務処理の効率なのかメンテナンスの効率なのかいまいち不明です。
銀行業務などではメンテナンス効率も大切でしょうがそれ以上に
業務処理の効率＆安定性が大事だと思いますよ。
今までに相当の実績があるCOBOLを捨てて新しいもの（JAVAとか）
を使うのであれば、そっちのほうが問題だと思います。
Re:黒幕は誰だ？ (スコア:0)
大量に捨てるとなると生ものだし大変だ。。。。
COBOLを生かしながらJavaに書き換えってどういう
事だろう？？？
すでにこの時点で死亡確定？
COBOLな人たちをJava使いに改造するのに手間取ったとか。。
Re:黒幕は誰だ？ (スコア:2, 興味深い)
仕様書にも作成者の記憶にも存在しないのに
COBOLソースの中に存在する
謎のコード(業務仕様)が捨てれないのでしょう。
Re:黒幕は誰だ？ (スコア:1)
> 事だろう？？？
COBOLの既存の"資産"を生かしながら、
全体としてはJavaで実装するというような話が、
先月の情報処理学会の全国大会(？)で出てました。
詳細は忘れましたが。
JAVAのプロジェクトって (スコア:1)
単にJava覚えられない化石ばかりで人材不足だと思うな。
もちろん新しい単語ばかり作ってまともな環境作れてない、
もしくはアンドキュメンテッドな仕様知らないと危なくて使えない
そんなJAVA自体の状態があるのかも知れないけど。
Javaにしろ、C++にしろ思想理解してる奴のいかに少ないことよ
でも (スコア:1)
Re:でも (スコア:2, すばらしい洞察)
要件定義と設計もね。問題はかなりの確率で、言語だのプラットフォームだの以前のところにあるものです。
Re:黒幕は誰だ？ (スコア:0)
何も銀行を騙して稼働させたワケじゃないでしょう？
そんな事態なら、とっくに晒されてるだろうし。
結局、「これでオッケーじゃん？」という判断をした銀行がアホなだけ。
一円入札は (スコア:0)
Re:黒幕は誰だ？ (スコア:0)
Re:黒幕は誰だ？ (スコア:0)