アカウント名:
パスワード:
M/Fっていうのの存在価値がよくわかりません。# 研修で実マシンそのものを見たこともあるし、Win上でコンソールエミュレータも触ったことあります。# 本当に触って一部の（おそらく簡単で定例的な）処理を打ち込ませてもらったことがある程度ですが。
よくわかっていないので、M/Fの重要性は次のように認識しているけど間違いあるのかなぁ。・整数型が扱いやすい（桁数で管理している。固定小数点１０進数型。会計処理でDouble型を使って浮動小数点のバグを混在させられる心配が無い）・既存の完成された仕掛けを移行する巨大なリスク。いわゆる「レガシー」の言葉で批判的に言
アベイラビリティ（可用性・故障しないで動く性質）の代わりにスケーラビリティ（拡張性・パワーを拡大させる性質）はあんまり無いかんじですかね。
確かにOpen系は「壊れても仕方ない・壊れたら交換。どうせ安いし」って言う発想が強いですよね。M/Fあたりは「決して壊れない」という考え方なんでしょうか。（といいつつ、隣のM/Fオフィスはトラブル続き・・・ハードウェア障害ではないかもしれませんが）
Win系やLinux・Unix系に比べても、チューニングしたりすることは少ないように思います。メーカーが標準で提供している機能の外のことは、「仕様外です」って言ってしまうような。（この辺は単に文化の違いかな？）
それにしてもM/Fって何十億もかかるんですか・・・。コストがそんなにかかるならば、Open系の並列や大多数サーバ化になってもコストを取る戦略に入ってしまうのが理解できますね。
やっぱり環境構築・運用ルール策定まで含めたトータルソリューションこそ、M/Fを知る上での重要ポイントなのかもしれませんね。
まだ若かりし頃、夜間バッチのトラブル対処で 最優先の処理クラスのイニシエータを１個もらって 夜明けまでにプログラムを修正してコンパイルして 処理を完了させたこともしばしば...ええ、そうして もらわないとコンパイルが終わらなかったです。
当時はまだMVSでしたがCPU使用率80%なんかどうってことないです。 さすがに95%を越えると処理が重いって感じます。
> アベイラビリティ（可用性・故障しないで動く性質）の代わりに> スケーラビリティ（拡張性・パワーを拡大させる性質）はあんまり無いかんじですかね。
「ブレードサーバーでLinux動かすぐらいなら、メインフレームでLinux動かしてください」という、IBMの営業さんの台詞から受けた印象からすると、逆ですね。
「数十台のLinuxサーバーを構築するのに、 他社だとブレードサーバーで何十枚もブレードを搭載するのでしょうが、 IBMならメインフレーム1台を何十個もの仮想空間に論理分割することで実現できます。
ちなみに、この程度の負荷、オープン系の製品にしてみると一苦労なレベルなのでしょうが、 わが社の製品でみれば標準構成程度で済みますので、屁でもありません。（意訳）」
# もっと上品におっしゃてました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
Open系しか実際には知らない平成生まれだけど (スコア:0)
M/Fっていうのの存在価値がよくわかりません。
# 研修で実マシンそのものを見たこともあるし、Win上でコンソールエミュレータも触ったことあります。
# 本当に触って一部の（おそらく簡単で定例的な）処理を打ち込ませてもらったことがある程度ですが。
よくわかっていないので、M/Fの重要性は次のように認識しているけど間違いあるのかなぁ。
・整数型が扱いやすい（桁数で管理している。固定小数点１０進数型。会計処理でDouble型を使って浮動小数点のバグを混在させられる心配が無い）
・既存の完成された仕掛けを移行する巨大なリスク。いわゆる「レガシー」の言葉で批判的に言
Re: (スコア: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台を何十個もの仮想空間に論理分割することで実現できます。
ちなみに、この程度の負荷、オープン系の製品にしてみると一苦労なレベルなのでしょうが、
わが社の製品でみれば標準構成程度で済みますので、屁でもありません。（意訳）」
# もっと上品におっしゃてました。