アカウント名:
パスワード:
メインフレームからオープン系への移行で一番キモになるところってどこなんでしょう。計算結果が合わないとか、端数処理がとかそういうお話なんでしょうか。
話は違うと思いますが銀行系システムで COBOL から他の言語に移行できない理由って、メインフレーム用の COBOL 以外の言語がないからとかそういう理由なのかなーとか安易に妄想したり。教えてエロい人。
・停止時間がほとんど許されない（年間で数時間からせいぜい48時間程度まで。緊急パッチあてるのも含めて）・顧客が求めているのは既存のシステムの再実装＋α、でも既存のシステムの仕様を完全に把握しきれていないし、ソース以外に”正しい”ドキュメントが無い。・他のソフトウェアやOS含め、発生した障害やバグ全て、発生原因を確実に突き止めないといけない。再起動したら直った、とかじゃ話にならない。
この状態で開発するってのがキモです。
> 発生原因を確実に突き止めないといけない。再起動したら直った、とかじゃ話にならない。
これは確かに厳しい。しかし、発注側が自分らのポカに対しても同じ態度で臨んでるところだと成功する。
自分にはぬるいくせに発注先にだけ超厳格な態度の所は失敗する。いや失敗して欲しい。絶対に失敗しろ。
ということでBW21ざまー
それのきついところは、自社製パッケージやプロジェクトで開発したソフトと、使用したミドルウェア以外に、他社製だったりオープンソースだったりする、OSに入ってるソフト全部が対象な点です。メインフレームでも同じ条件な訳ですが、メインフレームはオープンプラットホームじゃないから、NならNでほぼ閉じていたんでそこまで厳しくないんです。まぁ早い話、メインフレームでやっていたこと・できていたこと全て、システムの機能以外の部分も、オープンで実現しようとすることが問題なんでしょうね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
いつも思うのですが (スコア:1)
メインフレームからオープン系への移行で一番キモになるところってどこなんでしょう。計算結果が合わないとか、端数処理がとかそういうお話なんでしょうか。
話は違うと思いますが銀行系システムで COBOL から他の言語に移行できない理由って、メインフレーム用の COBOL 以外の言語がないからとかそういう理由なのかなーとか安易に妄想したり。教えてエロい人。
Hiroki (REO) Kashiwazaki
Re:いつも思うのですが (スコア:1)
・停止時間がほとんど許されない（年間で数時間からせいぜい48時間程度まで。緊急パッチあてるのも含めて）
・顧客が求めているのは既存のシステムの再実装＋α、でも既存のシステムの仕様を完全に把握しきれていないし、ソース以外に”正しい”ドキュメントが無い。
・他のソフトウェアやOS含め、発生した障害やバグ全て、発生原因を確実に突き止めないといけない。再起動したら直った、とかじゃ話にならない。
この状態で開発するってのがキモです。
Re: (スコア:0)
> 発生原因を確実に突き止めないといけない。再起動したら直った、とかじゃ話にならない。
これは確かに厳しい。
しかし、発注側が自分らのポカに対しても同じ態度で臨んでるところだと成功する。
自分にはぬるいくせに発注先にだけ超厳格な態度の所は失敗する。
いや失敗して欲しい。絶対に失敗しろ。
ということでBW21ざまー
Re: (スコア:0)
それのきついところは、自社製パッケージやプロジェクトで開発したソフトと、使用したミドルウェア以外に、他社製だったりオープンソースだったりする、OSに入ってるソフト全部が対象な点です。
メインフレームでも同じ条件な訳ですが、メインフレームはオープンプラットホームじゃないから、NならNでほぼ閉じていたんでそこまで厳しくないんです。
まぁ早い話、メインフレームでやっていたこと・できていたこと全て、システムの機能以外の部分も、オープンで実現しようとすることが問題なんでしょうね。