パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

メインフレーム専門書発売さる」記事へのコメント

  • M/Fっていうのの存在価値がよくわかりません。
    # 研修で実マシンそのものを見たこともあるし、Win上でコンソールエミュレータも触ったことあります。
    # 本当に触って一部の(おそらく簡単で定例的な)処理を打ち込ませてもらったことがある程度ですが。

    よくわかっていないので、M/Fの重要性は次のように認識しているけど間違いあるのかなぁ。
    ・整数型が扱いやすい(桁数で管理している。固定小数点10進数型。会計処理でDouble型を使って浮動小数点のバグを混在させられる心配が無い)
    ・既存の完成された仕掛けを移行する巨大なリスク。いわゆる「レガシー」の言葉で批判的に言

    • 可用性の高さもありますよ。メモリミラーなんてOpen系のシステムにはなかなかない(ごく一部にありますが)ですし。Open系のシステムに比べて冗長化の徹底さがかなり違うと思います。伊達に何十億も払うわけじゃないです……
      --
      人生は七転び八起き、一日は早寝早起き
      • Re: (スコア:1, 参考になる)

        by Anonymous Coward

        アベイラビリティ(可用性・故障しないで動く性質)の代わりに
        スケーラビリティ(拡張性・パワーを拡大させる性質)はあんまり無いかんじですかね。

        確かにOpen系は「壊れても仕方ない・壊れたら交換。どうせ安いし」って言う発想が強いですよね。
        M/Fあたりは「決して壊れない」という考え方なんでしょうか。
        (といいつつ、隣のM/Fオフィスはトラブル続き・・・ハードウェア障害ではないかもしれませんが)

        Win系やLinux・Unix系に比べても、チューニングしたりすることは少ないように思います。
        メーカーが標準で提供している機能の外のことは、「仕様外です」って言ってしまうような。(この辺は単に文化の違いかな?)

        それにしてもM/Fって何十億もかかるんですか・・・。
        コストがそんなにかかるならば、Open系の並列や大多数サーバ化になってもコストを取る戦略に入ってしまうのが理解できますね。

        やっぱり環境構築・運用ルール策定まで含めたトータルソリューションこそ、M/Fを知る上での重要ポイントなのかもしれませんね。

        • Re: (スコア:2, 参考になる)

          |スケーラビリティ(拡張性・パワーを拡大させる性質)はあんまり無いかんじですかね。
           逆だと思いますけど。
           一般的なラインナップに載っている範囲では、汎用機の方が広いです。
          (ハードの性能ではなく、リース料金で性能上限が決まる点に注意)

          |チューニングしたりすることは少ない
           OSの導入は非常に面倒です。導入作業=チューニング作業、ですから。
          (使用メモリ量を減らして月額リース料金を下げるという目的もあります)

          ・チューニング項目に関して
           OSそのものに大量のカスタマイズポイントが用意されています。
           また、APIの取捨選択も可能です。
          (unixならばカーネルソ
          --
          notice : I ignore an anonymous contribution.
          • Re: (スコア:1, 参考になる)

            by Anonymous Coward
            汎用機でアプリ開発をやっていましたがOSが落ちたのは1回だけでしたね(それもデータセンターのブレーカーが落ちたため)。
            昔は性能向上のためOSのモジュールをインストールする順番まで決まっていたそうです。
            バッチとかを流しても同じ処理であればCPU時間はどんなシステム負荷が高くても変わらないので重宝しました。
            DBの講習会も4泊5日であったりして、1回のI/Oが50msとして6時間以内でバッチが完了できるかと言う演習もありました。
            今では勘定系でもWindows系が使われるようですがやっぱり不安。
            • > 汎用機でアプリ開発をやっていましたがOSが落ちたのは1回だけでしたね(それもデータセンターのブレーカーが落ちたため)。

              OSは落ちないけど、RDBとかディスクをいじりたくなると、すぐに静的なな時間を確保してくださいという話になって、IPL(再起動)になりませんか。
              昔ながらの日中オンライン、夜間はバッチ処理という流れであれば作業時間をとれるので、静的な時間を確保するのは難しくないですが、24時間オンラインが一般的な現状にはちょっと辛い気がします。
              • by Anonymous Coward on 2009年04月07日 2時44分 (#1544833)
                >RDBとかディスクをいじりたくなると(中略)24時間オンラインが一般的な現状には
                >ちょっと辛い気がします。

                どういう場面か掴み難いですが、その手の状況が発生するのであれば
                多重化したシステムという構成になっているものではないでしょうか?
                更に、少なくとも「ちょっと構成をいじりたい」みたいな状況を作らない運用が
                汎用機では行われるのが普通だと感じます。つまり、計画をきちんと立てることが
                前提なので安易なシステム変更などは行わないので。

                その点、パソコン・ワークステーション系だとトライアンドエラーが結構安易に行われ
                る傾向がありますが、それを「柔軟な対応」と言えば聞こえはいいですが、
                計画の詰めが足りない裏返しだと感じることもあります。
                親コメント

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

処理中...