アカウント名:
パスワード:
M/Fっていうのの存在価値がよくわかりません。# 研修で実マシンそのものを見たこともあるし、Win上でコンソールエミュレータも触ったことあります。# 本当に触って一部の（おそらく簡単で定例的な）処理を打ち込ませてもらったことがある程度ですが。
よくわかっていないので、M/Fの重要性は次のように認識しているけど間違いあるのかなぁ。・整数型が扱いやすい（桁数で管理している。固定小数点１０進数型。会計処理でDouble型を使って浮動小数点のバグを混在させられる心配が無い）・既存の完成された仕掛けを移行する巨大なリスク。いわゆる「レガシー」の言葉で批判的に言われること。・管理するマシンが１台か、せいぜい３台くらいなのでサーバ増設しまくった場合におきる「常に１台は壊れている日」の確率が下がる。 ->Googleみたいに大量にサーバを持っていると、常に毎日どれかのサーバは壊れているらしいですね。・リースなので安い（のかどうかはよくわからない）。従量課金（買い切りもあるの？）。・ハードウェア的な問題が起きたら、販売メーカーの顧客エンジニア（CE）に依頼して直してもらえる。
後半はいわゆる「クラウドコンピューティング」で何とかなりそうでもある・・・・。物理的に遠隔地にDBを置きたくないという心情的・セキュリティ的な問題さえなんとかなれば、ですが。
アベイラビリティ（可用性・故障しないで動く性質）の代わりにスケーラビリティ（拡張性・パワーを拡大させる性質）はあんまり無いかんじですかね。
確かにOpen系は「壊れても仕方ない・壊れたら交換。どうせ安いし」って言う発想が強いですよね。M/Fあたりは「決して壊れない」という考え方なんでしょうか。（といいつつ、隣のM/Fオフィスはトラブル続き・・・ハードウェア障害ではないかもしれませんが）
Win系やLinux・Unix系に比べても、チューニングしたりすることは少ないように思います。メーカーが標準で提供している機能の外のことは、「仕様外です」って言ってしまうような。（この辺は単に文化の違いかな？）
それにしてもM/Fって何十億もかかるんですか・・・。コストがそんなにかかるならば、Open系の並列や大多数サーバ化になってもコストを取る戦略に入ってしまうのが理解できますね。
やっぱり環境構築・運用ルール策定まで含めたトータルソリューションこそ、M/Fを知る上での重要ポイントなのかもしれませんね。
まだ若かりし頃、夜間バッチのトラブル対処で 最優先の処理クラスのイニシエータを１個もらって 夜明けまでにプログラムを修正してコンパイルして 処理を完了させたこともしばしば...ええ、そうして もらわないとコンパイルが終わらなかったです。
当時はまだMVSでしたがCPU使用率80%なんかどうってことないです。 さすがに95%を越えると処理が重いって感じます。
> アベイラビリティ（可用性・故障しないで動く性質）の代わりに> スケーラビリティ（拡張性・パワーを拡大させる性質）はあんまり無いかんじですかね。
「ブレードサーバーでLinux動かすぐらいなら、メインフレームでLinux動かしてください」という、IBMの営業さんの台詞から受けた印象からすると、逆ですね。
「数十台のLinuxサーバーを構築するのに、 他社だとブレードサーバーで何十枚もブレードを搭載するのでしょうが、 IBMならメインフレーム1台を何十個もの仮想空間に論理分割することで実現できます。
ちなみに、この程度の負荷、オープン系の製品にしてみると一苦労なレベルなのでしょうが、 わが社の製品でみれば標準構成程度で済みますので、屁でもありません。（意訳）」
# もっと上品におっしゃてました。
自分なりに整理してみました。＞・整数型が扱いやすいこれは、COBOL系のシステムが多いということで、メインフレームの特徴とは、言えないのでは？
＞・既存の完成された仕掛けを移行する巨大なリスク。いわゆる「レガシー」の言葉で批判的に言われることこれは、メインフレーム内でも起きえる問題ですね。Ex)IMSとそれに対応するGDDMが、上位互換で無い場合、起きえます。このために、複数Revisionのランタイムの実行許可を許しているくらいですから。
＞・管理するマシンが１台か、・・・「常に１台は壊れている日」の確率が下がる。これは、冗長性の問題でしょうね。マシンは１台でも、CPUは、４つなんて運用が、結構されていますから。ただ、プリズムみたいなCPU分散ツールによるシステムダウンの回避CCPやIOPみたいなサブプロセッサを含めた、I/Oアクセスチャネルの冗長化で、リカバーしている部分もありますから
＞・リースなので・・・これは、税法上の問題ではなかったかと記憶してます。買いきりで減価償却５年とした場合とリースでは、リースのほうが、有利だったのでは・・・（正しい解答できる識者の方、お願いします。）
＞・ハードウェア的な問題が起きたら、販売メーカーの顧客エンジニア（CE）に依頼して直してもらえる。保守契約の問題ですね。これは、メインフレームに限らず、保守契約次第で可能です。むしろ、CEを駐在させ必要なパーツを最短で集めることができる体制をとらせられるということでしょうね。
これ以外にも、CEは、PMをかけてT&Dを実行し、部品劣化の恐れのあるパーツに関しては、予防保守で取り替えたりします。
これらは、安定稼動のためにとりうるあらゆる対策をとろうとすることができる・・・と換言できるのでは？
＞->Googleみたいに大量にサーバを持っていると、常に毎日どれかのサーバは壊れているらしいですね。当然ですね。何台かのサーバの故障発生確率から、ハードウェアを物理的に準備することで、システムとしての稼働率を確保するという発想からきていますからね。DBサーバは、多重化してデータを守り、WEBサーバが壊れても、再送でリカバーすればよいと考えれば、それでトレードオフが成立すると言うことでしょう。
とある製造業の会社では、システムがダウンすると、１秒１億の損失が発生するくらいのクリティカルミッションの真ん中を、メインフレームが支えていますから、そこにコストをさいて安定運用を求めるのは、当然のことだったりします。
で、答えになっていますか？
>とある製造業の会社では、システムがダウンすると、１秒１億の損失が発生するくらいの>クリティカルミッションの真ん中を、メインフレームが支えていますから、そこにコスト>をさいて安定運用を求めるのは、当然のことだったりします。
そうなんですよねぇ通信系と製造業はミッションクリティカルです。冗長系は当たり前で固いハードも必須なんですよね。安物買いの銭失いになっては困るのです。＃通信系に革命を起こした孫氏はある意味偉大かも(笑)
FACOM Mシリーズを数台使った計算センターにいましたが、終電が出でしまった後に泊まりなもので暇にあかせて設置説明書を読んだことがあります。それが実に細かい。建物の基本構造から床や壁の材質、空調機の能力や冗長化、自家発電を含む電力管理や地震、火災、浸水時の対応まで、起こりうる障害に対して、とことん事細かに指示があるわけです。つまりメインフレームの信頼性というのはマシン室内だけじゃなく、周辺環境まで含めたハードの耐障害性と、障害発生時の対応手順とノウハウ、そのドキュメント化という、ソフトの耐障害性をあわせたものなんだなと納得しました。そりゃ高価くなりますよね。
>FACOM Mシリーズを数台使った計算センターにいましたが、終電が出でしまった後に泊まりなもので>暇にあかせて設置説明書を読んだことがあります。
FACOM Mは大学時代計算機センターで使ってました。1回目にマシン室の見学があり驚きました。子守のメーカー要員が常駐しているのだから‥入社後中型汎用機のマシン室(冷蔵庫)に何度も入っていたので‥
よくは覚えてないんですが、鼠や虫の対策もありましたよ。通気口に金網とか。鼠はケーブル類ですね。当時は鼠避けケーブルは無かったんじゃないかな。
大型トラックは中小型トラックに比べて信頼性がものすごく高いわけではないのでたとえとしてはいまいちだと思う
戦車→汎用機タリバンも愛用してますっ！ TOYOTAのピックアップ→パソコン・WS系
まあ、特徴はあるんだけど新しもの好きのエンジニアには向かないんですよね・・・・
# みんな古いのが嫌いなんじゃなくて新しいのが好きなだけなんですよ・・・
トヨタは比較的最近(といっても7,8年前)メインフレームを中心としたシステムを導入してますな。
# 確か日経コンピュータあたりでも記事を見た気がする。
ミドルウェアががんばれば、本来バックエンドなんてなんだっていいはず。Open系だからUNIXサーバ使わなきゃいけないというものでもないでしょ。クラウドで何とかなりそ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
Open系しか実際には知らない平成生まれだけど (スコア:0)
M/Fっていうのの存在価値がよくわかりません。
# 研修で実マシンそのものを見たこともあるし、Win上でコンソールエミュレータも触ったことあります。
# 本当に触って一部の（おそらく簡単で定例的な）処理を打ち込ませてもらったことがある程度ですが。
よくわかっていないので、M/Fの重要性は次のように認識しているけど間違いあるのかなぁ。
・整数型が扱いやすい（桁数で管理している。固定小数点１０進数型。会計処理でDouble型を使って浮動小数点のバグを混在させられる心配が無い）
・既存の完成された仕掛けを移行する巨大なリスク。いわゆる「レガシー」の言葉で批判的に言われること。
・管理するマシンが１台か、せいぜい３台くらいなのでサーバ増設しまくった場合におきる「常に１台は壊れている日」の確率が下がる。
->Googleみたいに大量にサーバを持っていると、常に毎日どれかのサーバは壊れているらしいですね。
・リースなので安い（のかどうかはよくわからない）。従量課金（買い切りもあるの？）。
・ハードウェア的な問題が起きたら、販売メーカーの顧客エンジニア（CE）に依頼して直してもらえる。
後半はいわゆる「クラウドコンピューティング」で何とかなりそうでもある・・・・。
物理的に遠隔地にDBを置きたくないという心情的・セキュリティ的な問題さえなんとかなれば、ですが。
Re:Open系しか実際には知らない平成生まれだけど (スコア:3, 興味深い)
Re:Open系しか実際には知らない平成生まれだけど (スコア:2)
人生は七転び八起き、一日は早寝早起き
Re:Open系しか実際には知らない平成生まれだけど (スコア:1, 参考になる)
アベイラビリティ（可用性・故障しないで動く性質）の代わりに
スケーラビリティ（拡張性・パワーを拡大させる性質）はあんまり無いかんじですかね。
確かにOpen系は「壊れても仕方ない・壊れたら交換。どうせ安いし」って言う発想が強いですよね。
M/Fあたりは「決して壊れない」という考え方なんでしょうか。
（といいつつ、隣のM/Fオフィスはトラブル続き・・・ハードウェア障害ではないかもしれませんが）
Win系やLinux・Unix系に比べても、チューニングしたりすることは少ないように思います。
メーカーが標準で提供している機能の外のことは、「仕様外です」って言ってしまうような。（この辺は単に文化の違いかな？）
それにしてもM/Fって何十億もかかるんですか・・・。
コストがそんなにかかるならば、Open系の並列や大多数サーバ化になってもコストを取る戦略に入ってしまうのが理解できますね。
やっぱり環境構築・運用ルール策定まで含めたトータルソリューションこそ、M/Fを知る上での重要ポイントなのかもしれませんね。
Re:Open系しか実際には知らない平成生まれだけど (スコア:2, 参考になる)
逆だと思いますけど。
一般的なラインナップに載っている範囲では、汎用機の方が広いです。
（ハードの性能ではなく、リース料金で性能上限が決まる点に注意）
｜チューニングしたりすることは少ない
OSの導入は非常に面倒です。導入作業＝チューニング作業、ですから。
（使用メモリ量を減らして月額リース料金を下げるという目的もあります）
・チューニング項目に関して
OSそのものに大量のカスタマイズポイントが用意されています。
また、APIの取捨選択も可能です。
（unixならばカーネルソースの修正＆コンパイルに相当する作業が、外付けの定義で可能になってます）
冗長化を利用したボトルネックの回避もあちこちにあります。
一例を挙げると、周辺機器とインタフェースボードが格子状のバスで接続されてたりします。
（unixの場合は負荷が上がってくるとIO待ちに起因する性能低下が発生しますが、
このような構成の場合、滅多に発生しません。）
# その替わり、月額使用料が億の単位になったりする訳ですが…
※ 特筆すべきは、権限設定，優先順位設定の異様な細かさとワークロード管理でしょう。
「多数の処理を同時並行で処理し、期限までに完了させる」事に関しては汎用機に敵うシステムはありません。
# これも「信頼性」に含めて良い思いますけど。（税務署に提出する資料や振り込みが期日に間に合わない、なんて事になったら会社が潰れます）
notice : I ignore an anonymous contribution.
Re:Open系しか実際には知らない平成生まれだけど (スコア:3, 参考になる)
体は汎用機運用者でも心はunix運用な人です(笑)
> 一般的なラインナップに載っている範囲では、汎用機の方が広いです。
> （ハードの性能ではなく、リース料金で性能上限が決まる点に注意）
富士通機だとCPUは1個から16個まで乗りますね。
足りなければクラスタ化かな。ただ途中からクラスタにするのは難しいかも。
http://globalserver.fujitsu.com/jp/products/gs21900/index.html
レンタル代も上記にでているけど、高いよな。
> ※ 特筆すべきは、権限設定，優先順位設定の異様な細かさとワークロード管理でしょう。
> 「多数の処理を同時並行で処理し、期限までに完了させる」事に関しては汎用機に敵うシステムはありません。
> # これも「信頼性」に含めて良い思いますけど。（税務署に提出する資料や振り込みが期日に間に合わない、なんて事になったら会社が潰れます）
確かに、このあたりの制御は素晴らしいと思いますが、同じコストをかけたオープン系との比較は
無いものですかね。
取り留めないですが....
M/F畑の人は結構、HWが壊れること自体に否定的で、オープン系の壊れても活性交換すればよいし2重化で危なければ3重化という考え方は馴染めない人が多い気がする。
あとIO性能の為だと思うけどディスクの管理が辛いなぁ...... X37ってOS標準にいれてよ。
PDL/SMFは便利かな。
Re:Open系しか実際には知らない平成生まれだけど (スコア:1, 参考になる)
昔は性能向上のためOSのモジュールをインストールする順番まで決まっていたそうです。
バッチとかを流しても同じ処理であればCPU時間はどんなシステム負荷が高くても変わらないので重宝しました。
DBの講習会も4泊5日であったりして、1回のI/Oが50msとして6時間以内でバッチが完了できるかと言う演習もありました。
今では勘定系でもWindows系が使われるようですがやっぱり不安。
Re:Open系しか実際には知らない平成生まれだけど (スコア:2)
OSは落ちないけど、RDBとかディスクをいじりたくなると、すぐに静的なな時間を確保してくださいという話になって、IPL(再起動)になりませんか。
昔ながらの日中オンライン、夜間はバッチ処理という流れであれば作業時間をとれるので、静的な時間を確保するのは難しくないですが、24時間オンラインが一般的な現状にはちょっと辛い気がします。
Re: (スコア:0)
>ちょっと辛い気がします。
どういう場面か掴み難いですが、その手の状況が発生するのであれば
多重化したシステムという構成になっているものではないでしょうか？
更に、少なくとも「ちょっと構成をいじりたい」みたいな状況を作らない運用が
汎用機では行われるのが普通だと感じます。つまり、計画をきちんと立てることが
前提なので安易なシステム変更などは行わないので。
その点、パソコン・ワークステーション系だとトライアンドエラーが結構安易に行われ
る傾向がありますが、それを「柔軟な対応」と言えば聞こえはいいですが、
計画の詰めが足りない裏返しだと感じることもあります。
Re:Open系しか実際には知らない平成生まれだけど (スコア:1)
> OSそのものに大量のカスタマイズポイントが用意されています。
> また、APIの取捨選択も可能です。
>（unixならばカーネルソースの修正＆コンパイルに相当する作業が、外付けの定義で可能になってます）
メインフレームのインストールってSYSGENって言ってけど、
ひたすらSYSGENパラメータを切る作業ですよね。
いや自分じゃやったことないけど、見てたことはあるんで。
で、あれって結局アセンブラマクロのパラメータ切る作業で、
GENするってアセンブラソースを生成してアセンブルするこ
とじゃないんですか（見ててそう思った）。
Re:Open系しか実際には知らない平成生まれだけど (スコア:1)
ど～ゆ～わけか、端末定義に至るまで定義はマクロで記述して、
バイナリの定義テーブルを作成する流れになっているのです。
# 専用のconfigureを容易せず、アセンブラのマクロで済ましている理由が泣けてきます。
# リース料金をケチったマシンだとメモリ不足でconfigureが動かない可能性があるからだそうで…
notice : I ignore an anonymous contribution.
Re:Open系しか実際には知らない平成生まれだけど (スコア:1)
まだ若かりし頃、夜間バッチのトラブル対処で 最優先の処理クラスのイニシエータを１個もらって 夜明けまでにプログラムを修正してコンパイルして 処理を完了させたこともしばしば...ええ、そうして もらわないとコンパイルが終わらなかったです。
当時はまだMVSでしたがCPU使用率80%なんかどうってことないです。 さすがに95%を越えると処理が重いって感じます。
Re: (スコア:0)
Re:Open系しか実際には知らない平成生まれだけど (スコア:2)
> アベイラビリティ（可用性・故障しないで動く性質）の代わりに
> スケーラビリティ（拡張性・パワーを拡大させる性質）はあんまり無いかんじですかね。
「ブレードサーバーでLinux動かすぐらいなら、メインフレームでLinux動かしてください」という、IBMの営業さんの台詞から受けた印象からすると、逆ですね。
「数十台のLinuxサーバーを構築するのに、
他社だとブレードサーバーで何十枚もブレードを搭載するのでしょうが、
IBMならメインフレーム1台を何十個もの仮想空間に論理分割することで実現できます。
ちなみに、この程度の負荷、オープン系の製品にしてみると一苦労なレベルなのでしょうが、
わが社の製品でみれば標準構成程度で済みますので、屁でもありません。（意訳）」
# もっと上品におっしゃてました。
Re:Open系しか実際には知らない平成生まれだけど (スコア:2, 参考になる)
自分なりに整理してみました。
＞・整数型が扱いやすい
これは、COBOL系のシステムが多いということで、メインフレームの特徴とは、言えないのでは？
＞・既存の完成された仕掛けを移行する巨大なリスク。いわゆる「レガシー」の言葉で批判的に言われること
これは、メインフレーム内でも起きえる問題ですね。
Ex)IMSとそれに対応するGDDMが、上位互換で無い場合、起きえます。
このために、複数Revisionのランタイムの実行許可を許しているくらいですから。
＞・管理するマシンが１台か、・・・「常に１台は壊れている日」の確率が下がる。
これは、冗長性の問題でしょうね。
マシンは１台でも、CPUは、４つなんて運用が、結構されていますから。
ただ、
プリズムみたいなCPU分散ツールによるシステムダウンの回避
CCPやIOPみたいなサブプロセッサを含めた、I/Oアクセスチャネルの冗長化
で、リカバーしている部分もありますから
＞・リースなので・・・
これは、税法上の問題ではなかったかと記憶してます。
買いきりで減価償却５年とした場合とリースでは、リースのほうが、有利だったのでは・・・
（正しい解答できる識者の方、お願いします。）
＞・ハードウェア的な問題が起きたら、販売メーカーの顧客エンジニア（CE）に依頼して直してもらえる。
保守契約の問題ですね。
これは、メインフレームに限らず、保守契約次第で可能です。
むしろ、CEを駐在させ必要なパーツを最短で集めることができる体制をとらせられる
ということでしょうね。
これ以外にも、CEは、PMをかけてT&Dを実行し、部品劣化の恐れのあるパーツに関しては、予防保守で取り替えたりします。
これらは、安定稼動のためにとりうるあらゆる対策をとろうとすることができる・・・と換言できるのでは？
＞->Googleみたいに大量にサーバを持っていると、常に毎日どれかのサーバは壊れているらしいですね。
当然ですね。何台かのサーバの故障発生確率から、ハードウェアを物理的に準備することで、システムとしての稼働率を確保するという発想からきていますからね。
DBサーバは、多重化してデータを守り、WEBサーバが壊れても、再送でリカバーすればよいと考えれば、それでトレードオフが成立すると言うことでしょう。
とある製造業の会社では、システムがダウンすると、１秒１億の損失が発生するくらいのクリティカルミッションの真ん中を、メインフレームが支えていますから、そこにコストをさいて安定運用を求めるのは、当然のことだったりします。
で、答えになっていますか？
Re:Open系しか実際には知らない平成生まれだけど (スコア:2)
>とある製造業の会社では、システムがダウンすると、１秒１億の損失が発生するくらいの
>クリティカルミッションの真ん中を、メインフレームが支えていますから、そこにコスト
>をさいて安定運用を求めるのは、当然のことだったりします。
そうなんですよねぇ
通信系と製造業はミッションクリティカルです。
冗長系は当たり前で固いハードも必須なんですよね。
安物買いの銭失いになっては困るのです。
＃通信系に革命を起こした孫氏はある意味偉大かも(笑)
Re:Open系しか実際には知らない平成生まれだけど (スコア:3, 参考になる)
FACOM Mシリーズを数台使った計算センターにいましたが、終電が出でしまった後に泊まりなもので
暇にあかせて設置説明書を読んだことがあります。
それが実に細かい。建物の基本構造から床や壁の材質、空調機の能力や冗長化、自家発電を含む
電力管理や地震、火災、浸水時の対応まで、起こりうる障害に対して、とことん事細かに指示が
あるわけです。
つまりメインフレームの信頼性というのはマシン室内だけじゃなく、周辺環境まで含めた
ハードの耐障害性と、障害発生時の対応手順とノウハウ、そのドキュメント化という、
ソフトの耐障害性をあわせたものなんだなと納得しました。
そりゃ高価くなりますよね。
〜◍
Re:Open系しか実際には知らない平成生まれだけど (スコア:1)
>FACOM Mシリーズを数台使った計算センターにいましたが、終電が出でしまった後に泊まりなもので
>暇にあかせて設置説明書を読んだことがあります。
FACOM Mは大学時代計算機センターで使ってました。1回目にマシン室の見学があり驚きました。
子守のメーカー要員が常駐しているのだから‥
入社後中型汎用機のマシン室(冷蔵庫)に何度も入っていたので‥
Re:Open系しか実際には知らない平成生まれだけど (スコア:1)
>自家発電を含む電力管理や地震、火災、浸水時の対応まで、起こりうる障害に対して、
>とことん事細かに指示があるわけです。
「マウス(ねずみ)の害について」の説明はありませんでしたか。
Re:Open系しか実際には知らない平成生まれだけど (スコア:1)
よくは覚えてないんですが、鼠や虫の対策もありましたよ。
通気口に金網とか。鼠はケーブル類ですね。
当時は鼠避けケーブルは無かったんじゃないかな。
〜◍
存在価値。それは信頼性。 (スコア:1, 参考になる)
パソコンでも信頼性を確保しようとなるとサーバ系なら電源を二重にしたり
フォールトトレラントな仕組みを色々入れたり、と、やることがやたら増える。
それが当たり前に、基本にあるのがメインフレーム。
ただ、安くはならないから、信頼性を削ってでも安くという市場の要求が
現在のパソコン系の利用を増やしている。それとパソコンの処理能力が増えて
適用範囲を広げたからというのも大きい。
大型トラック(汎用機)でないと無理という場面はあるけど、
中小型トラック(パソコン・WS系)の使える場面は多くなったというのが現在。
Re: (スコア:0)
大型トラックは中小型トラックに比べて信頼性がものすごく高いわけではないので
たとえとしてはいまいちだと思う
Re: (スコア:0)
でもワークロード(負荷)単位で見たら大型トラックの信頼性は高くなるんだよね。
メインフレーム相手の負荷だと中・小ではオーバーロード気味とか負荷に耐えられないとか状況も発生するので。
そちら方面の視点で見たのでそういう例えになりました。
ただ、距離単位でみるとそういう視点にはならないのが難な例えではあったね。
Re: (スコア:0)
戦車→汎用機
タリバンも愛用してますっ！ TOYOTAのピックアップ→パソコン・WS系
Re: (スコア:0)
例えば今はコンシューマ相手の商売ではオンラインのサービスが停止しない信頼性が必要，
ただし平均的な稼働率維持が重要で，短時間のシステムダウンでちょっとぐらいオンラインでの発注をロストしたって大丈夫って感じですから.........（受け取ったデータはロスト出来ないが，短時間データを受け取れない状態になっても無問題． 受け取っていないデータは相手のものだからこっちにデータ紛失の責任があるわけじゃ無いよ）
何事にも絶対的な信頼性が要求された時代とは感覚がちょっと違う
Re:Open系しか実際には知らない平成生まれだけど (スコア:1)
Re: (スコア:0)
まあ、特徴はあるんだけど
新しもの好きのエンジニアには向かないんですよね・・・・
# みんな古いのが嫌いなんじゃなくて新しいのが好きなだけなんですよ・・・
Re:Open系しか実際には知らない平成生まれだけど (スコア:1, すばらしい洞察)
Re:Open系しか実際には知らない平成生まれだけど (スコア:2, 参考になる)
このVM/SPや現在のZ/VMの原型のCP-xx/CMSは1967年、約40年前に実用化されています。
数十年前というと、5,60年位前なので電子計算機の黎明期にあたります。
IBMが仮想記憶をサポートしたDOS/VS、OS/VS1、OS/VS2が実用化されたのは1970年とCP/CMSよりも後になっています。
ちなみに、IBMメインフレーム上で動作するZ/LinuxはVM上のゲストOSとして実装されています。
http://premium.nikkeibp.co.jp/linux/case/case08/4.shtml [nikkeibp.co.jp]
適材適所で考えればいいだけ (スコア:0)
トヨタは比較的最近(といっても7,8年前)メインフレームを中心としたシステムを導入してますな。
# 確か日経コンピュータあたりでも記事を見た気がする。
ミドルウェアががんばれば、本来バックエンドなんてなんだっていいはず。Open系だからUNIXサーバ使わなきゃいけないというものでもないでしょ。クラウドで何とかなりそ