アカウント名:
パスワード:
友人にPL/Iプログラマが居ます。(まだ20代なのに…)過去の資産があるのと、それを動かす処理系が現役なのも、原因なのかなと思いました。特にメインフレームなどは過去の資産(負の遺産とも…)がバカにならないため古いシステムをオープン系に移行し損ねる → それを動かすメインフレームに需要が出て処理系が存続 → メインフレーム上の資産がまた増えるというようなループがあり、なかなか言語・処理系共に滅びないと。
何でメインフレームが負の遺産なんだ?自分がCOBOLを理解できないor嫌いだから、とかいう下らない理由じゃないよな?
メインフレームが負の遺産なんて一言もかいてないじゃない。メインフレームにある過去の資産が負の遺産(の場合もある)ていう意味だろ?たぶん。
地球に優しくないことは確かだろう。ワットパフォーマンスという意味で。
ワットパフォーマンスの点でいうと、PCよりもよほどいいが?
確かに電力消費的には悪いでしょうけど、本来の処理系の信頼性や可用性はオープン系より全然よろしいかと。
オープン系は小回り利くのが良かったけど、リソースの有難味が全然無くなってきた昨今では、メモリ馬鹿食い、余計なサービス立って割り込み遅れとか、更にはネットワークリソースまでめんどくさい事になってて、何かにつけてウンザリしてしまうことが多くなった。
いろいろな意味での拡張性かな?パフォーマンスを向上させるには、機器を高性能なものにリプレースするより低性能の機器を複数台運用した方が簡単で安価であるとgoogleが証明しました。そうすると、プログラム言語も分散処理やスケーラビリティを考えたものにした方が良くなります。結果として機器の需要もプログラマの需要も減少方向にあり、現在使用しているプログラムも確保しているプログラマもつぶしがきかないものになっています。
メインフレームを負の遺産としないためには今後もメインフレームを使い続ける必要がありますが、機器およびプログラマの需要減によるコストと確保労力の増大は避けられません。
Googleが手掛けている業務については分散型の方が有利であるということが証明されただけ。金融機関やエアラインの基幹システムのような業務ではいまだに分散型に移行する兆しはないでしょ。
>金融機関やエアラインの基幹システムのような業務ではいまだに分散型に移行する兆しはないでしょ。
分散型に移行する兆しはないけど、ホスト離れは(業界の速度なりに)進んでますよ。今や、金融機関の基幹系システムも Linux サーバ上で Java で書かれはじめたりしてる時代です。まあ、それが IBM の z サーバで動いてたりもしますけど、まあ、昔ながらのホスト-COBOLシステムではない。
この方はなんで分散化していないと思い込んだのだろう。
では基幹業務で分散化が一般化してきている実例をどうぞ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
処理系が滅びぬ限り (スコア:4, 興味深い)
友人にPL/Iプログラマが居ます。(まだ20代なのに…)
過去の資産があるのと、それを動かす処理系が現役なのも、原因なのかなと思いました。
特にメインフレームなどは過去の資産(負の遺産とも…)がバカにならないため
古いシステムをオープン系に移行し損ねる → それを動かすメインフレームに需要が出て処理系が存続 → メインフレーム上の資産がまた増える
というようなループがあり、なかなか言語・処理系共に滅びないと。
Re:処理系が滅びぬ限り (スコア:-1)
何でメインフレームが負の遺産なんだ?
自分がCOBOLを理解できないor嫌いだから、とかいう下らない理由じゃないよな?
Re: (スコア:0)
メインフレームが負の遺産なんて一言もかいてないじゃない。
メインフレームにある過去の資産が負の遺産(の場合もある)ていう意味だろ?
たぶん。
Re: (スコア:0)
地球に優しくないことは確かだろう。
ワットパフォーマンスという意味で。
Re: (スコア:0)
ワットパフォーマンスの点でいうと、PCよりもよほどいいが?
Re: (スコア:0)
確かに電力消費的には悪いでしょうけど、
本来の処理系の信頼性や可用性はオープン系より全然よろしいかと。
オープン系は小回り利くのが良かったけど、
リソースの有難味が全然無くなってきた昨今では、
メモリ馬鹿食い、余計なサービス立って割り込み遅れとか、
更にはネットワークリソースまでめんどくさい事になってて、
何かにつけてウンザリしてしまうことが多くなった。
Re: (スコア:0)
いろいろな意味での拡張性かな?
パフォーマンスを向上させるには、機器を高性能なものにリプレースするより低性能の機器を複数台運用した方が簡単で安価であるとgoogleが証明しました。
そうすると、プログラム言語も分散処理やスケーラビリティを考えたものにした方が良くなります。
結果として機器の需要もプログラマの需要も減少方向にあり、現在使用しているプログラムも確保しているプログラマもつぶしがきかないものになっています。
メインフレームを負の遺産としないためには今後もメインフレームを使い続ける必要がありますが、
機器およびプログラマの需要減によるコストと確保労力の増大は避けられません。
Re: (スコア:0)
Googleが手掛けている業務については分散型の方が有利であるということが証明されただけ。金融機関やエアラインの基幹システムのような業務ではいまだに分散型に移行する兆しはないでしょ。
Re:処理系が滅びぬ限り (スコア:1)
>金融機関やエアラインの基幹システムのような業務ではいまだに分散型に移行する兆しはないでしょ。
分散型に移行する兆しはないけど、ホスト離れは(業界の速度なりに)進んでますよ。
今や、金融機関の基幹系システムも Linux サーバ上で Java で書かれはじめたりしてる時代です。
まあ、それが IBM の z サーバで動いてたりもしますけど、まあ、昔ながらのホスト-COBOLシステムではない。
Re: (スコア:0)
この方はなんで分散化していないと思い込んだのだろう。
Re: (スコア:0)
では基幹業務で分散化が一般化してきている実例をどうぞ