アカウント名:
パスワード:
こういう言い方したらアレですが、もし後者なら100万件分増やすのも600万件分増やして許容数を一桁上げるのも費用的には実は大して変わらんのと違うのかなぁ。
桁数が変わるとレコード設計が変わるので大事です. 正しいプログラムならかなり機械的に修正できるはずですが, プログラム的には間違っているけどたまたま動いている, 例えば本来使用すべきレコード型ではないけど桁数が合っているので動いていたなんて物が火を吹く可能性が高いです.
というか, この種の古いシステムはたとえ10年前に改修されていたとしても, その当時の技術レベルで作られているなんて甘い期待はしちゃだめです. 特に設計については旧来のシステムとの継続性を最重視するので, 20〜30年程度前の思想に基づいて作られています. そのため, 最近のプログラムの様にヘッダやモジュールの修正で全体を一気に作り直すなんてことは不可能と思っておいた方が安全です.
それじゃ完全に一から作り直した方が速そうな気がしますけど, これもダメですね. 仕様を切れる人がいませんから. こうした大規模システムを扱っている人って, 下手に昔からやっているだけに, システムを大所高所からトップダウンで分析的に行うって手法に疎く, 個々の処理手順や出力といった末葉からボトムアップで積み上げることしかできませんから. 流通業なんかなら, 営業とか経理あたりの部門がイニシアチブを取って進めることで刷新するなんてこともありますけど, 証券取引業だとどうなんでしょ?
なんてか、業種とか産業毎の時間の流れって各々違うんですよ。 で、それをうまく調整しないと本当に良い仕事・良いものは作れないって言うのはあるので無いかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
改修って… (スコア:3, 興味深い)
処理件数がHDD容量に依存、ってことは
今回の改修ではそこしかいじってないわけですよねぇ。
となれば、これ以上の増強は不能なのか、まだ増強の余地があるものを小出ししてるだけなのか、
非常に気になるのですが。
こういう言い方したらアレですが、もし後者なら
100万件分増やすのも600万件分増やして許容数を一桁上げるのも
費用的には実は大して変わらんのと違うのかなぁ。
Re:改修って… (スコア:5, 興味深い)
桁数が変わるとレコード設計が変わるので大事です. 正しいプログラムならかなり機械的に修正できるはずですが, プログラム的には間違っているけどたまたま動いている, 例えば本来使用すべきレコード型ではないけど桁数が合っているので動いていたなんて物が火を吹く可能性が高いです.
というか, この種の古いシステムはたとえ10年前に改修されていたとしても, その当時の技術レベルで作られているなんて甘い期待はしちゃだめです. 特に設計については旧来のシステムとの継続性を最重視するので, 20〜30年程度前の思想に基づいて作られています. そのため, 最近のプログラムの様にヘッダやモジュールの修正で全体を一気に作り直すなんてことは不可能と思っておいた方が安全です.
それじゃ完全に一から作り直した方が速そうな気がしますけど, これもダメですね. 仕様を切れる人がいませんから. こうした大規模システムを扱っている人って, 下手に昔からやっているだけに, システムを大所高所からトップダウンで分析的に行うって手法に疎く, 個々の処理手順や出力といった末葉からボトムアップで積み上げることしかできませんから. 流通業なんかなら, 営業とか経理あたりの部門がイニシアチブを取って進めることで刷新するなんてこともありますけど, 証券取引業だとどうなんでしょ?
Re:改修って… (スコア:4, 興味深い)
結局、一から作り直したものに更新するしかないように思いますが、完全に新式のものと、旧式のものを二つ並行して半年ぐらい走らせながら検証して移行する、というわけにはいかないものでしょうか？
ソフト屋さん、システム屋さんには、すごく大きなビジネスチャンスのように思いますが。
Re:改修って… (スコア:3, 興味深い)
新システム系と旧システム系でまったくおなじデータを処理するならともかく、新システムに伴い周辺の接続システムも機能追加などでインターフェース要件が変更になることがままあります。すると、並行稼動のためには、両系のシステムのデータをさばく必要が出ます。しかし、現実には、そのためのインフラを保守する費用の問題や、それゆえのパフォーマンス問題などで、結局、どちらのシステムも危機的な状況に陥ってしまうことになります。
お客さんが、夢見なけりゃできるんだけどね＿|￣|○
でも、すんごいお金投資してオープン化するんだし、その分、便利になってよ、っていう気持ちもわかるのよ。そうして、すべてのシステムを一夜にして切り替える、というすばらしい計画ができる、と。
# やっぱりAC。
Re:改修って… (スコア:2, すばらしい洞察)
かと言って技術屋の理想だけのシステムとなると、年がら年中移行措置の為の作業ばかりで本番運用って存在するの？ってシステムすらありますから、その辺りはきちんと技術と営業のどちらも見れる人間が判断しないと変な物になりかねませんし。
と言うか、この手のシステムであれば１０年スパンで考えること自体は間違っているとは余り思いません。
けど、現状のコンピュータ関連は余りにも変化が早いってのが一つのネックになっているのも確かなんですよね。
うちは勘定系はやらないけど工場はやる。
で、そういう時のシステムでは１０年スパンでって話になるのは珍しくない。
が、現状では３年程度でリプレイスしないと安心して使わせる事は出来ないってものも多いんですよね。
でも、客から見れば「何で業務は変わらないのに３年程度で更新が」って例も多いですし。
なんてか、業種とか産業毎の時間の流れって各々違うんですよ。
で、それをうまく調整しないと本当に良い仕事・良いものは作れないって言うのはあるので無いかと。
Re:改修って… (スコア:2, 参考になる)
私の知っている限りでも、某大手金融機関でそのような事例があります。
東証との接続や全銀との接続など、外部とのインタフェースは基本的に変わらないので、そこにブリッジをおいてメッセージをコピーする方法をとります。
日締めをすると計算があわなかったりするんですよね。
Re:改修って… (スコア:2, 興味深い)
古き良きCOBOLで書いてあるとすると、1000万未満までは保つかと。だから逆に数カ月以内に７００万〜８００万件に増強する方針 [asahi.com]と小出しにし、何とか件数を押え込もうとている気がします。で問題なのはその３０日には予定されていた新コンピューターによる次期システム移行でしのぐ方針 [asahi.com]がこの縛りにあることで、次期システムとやらでも遠くは無い未来には行き詰まってしまい、その頃にハードウェアもソフトウェアも全面更改した次次期? システムが稼働できる当てが無いことかと。
Re:改修って… (スコア:1)
http://jp.opencobol.org/
次次期システム (スコア:1)
# できる頃には上海に市場(及び資本)を奪われてしまう気が…
Re:改修って… (スコア:0)
何も自分で作る必要はないのでは
Re:改修って… (スコア:1)
Re:改修って… (スコア:1)
/* Kachou Utumi
I'm Not Rich... */
Re:改修って… (スコア:0)
「で、どうして売れなかったんだい」
「建物が小さすぎて入らなかったんだよ。ＨＡＨＡＨＡ」
というアメリカンジョークでした。
すいません。すいません。
Re:改修って… (スコア:0)