パスワードを忘れた? アカウント作成
1462 story

メインフレームの行き先 43

ストーリー by wakatono
しばらくは残るだろうけど… 部門より

nak 曰く,"ZDNNの米速報によるとRed Hat,IBMメインフレーム用のLinuxをリリースへという話らしいが、過去にあった一家に一台、メインフレームLinuxといい、メインフレームはどこへ行くのだろうか?
日本電気では、Win2K/NTサーバー付属のメインフレームなんてのが主力になりつつあるのだが、今ひとつ大丈夫か?という気がしてしまう。"

国内のメインフレーマもいまや激減し、その存亡が危ぶまれる状態になって久しい。でも、メインフレームは単なる汎用コンピュータという機械にとどまらず、そのソフトウェア開発手法、そして長期にわたる(!)維持管理フェーズをも含んだ一つのコンピューティングパラダイムという見方もある。IBMのz/900シリーズにいたっては、MTBFが数十年オーダーというボードを搭載している。ここまでするかという議論はあるだろうが、その長期にわたるライフサイクルを現在のアーキテクチャのPC/WS/サーバマシンやソフトウェアが担保できるのだろうか?それができたとき、はたして本当にメインフレームの時代は終わるのか?いろいろと考えは尽きない…

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by LightSpeed-J (4514) on 2001年11月05日 15時04分 (#35652) ホームページ
    基本的にホストベンダってのは,
    他社にホストの業務を置き換えられることが一番怖いので,
    「他社に置き換えられてしまうくらいなら」,
    業務の一部を開発しなおさずに安くできます。と,
    言い切れるのには劇的なメリットがあるのでしょう。

    やっぱり本当の基幹業務は専用のホストマシンでやるのでしょう。
    信頼性と性能が違いますから。

    余談ですが,今ホストって小さい奴は安いんですけどね。
    →運用ができないけど。
    --
    -- LightSpeed-J
  • はたして本当にメインフレームの時代は終わるのか?

    終わるわけないと思うけどなぁ。SCモデル化でダウンサイジングとお題目を唱えたところで、それが適用できない業務処理って厳然と実在するんだから。

    従業員総数が数千人以上の企業・企業グループの月次決算処理などを一括してひっかき回せるのは、やっぱりそっちの方面のマシンしかないでしょ。まぁたしかに "Sun On Sun" のような実例がないわけじゃないが、これはあくまで特殊事例。普通のベンダならメインフレームで同じシステムを組む方が合理的と考えるハズ…だし、そう考えてくれなきゃ、それはそれで相当恐ろしいことだったりする。

    …で、この規模以上の企業ってのは結構「あたりまえ」にあるわけじゃないですか。

    --
    --- Toshiboumi bugbird Ohta
    • by seldon (5637) on 2001年11月05日 16時57分 (#35678)
      …で、この規模以上の企業ってのは結構「あたりまえ」にあるわけじゃないですか。
      何か規模に拘ってるみたいですが、 「メインフレームはUn*xマシンよりCPUやディスクアクセスなどの能力が上」という神話はいまだに健在なのでしょうか?
      最近の情勢だと、メインフレームと上位のUn*xマシンだとCPU能力の点でも、扱えるメモリ、ディスク資源なんかもそれ程差はありません。
      下位クラスのメインフレームだと、PCサーバにもCPUパワーで負けるヤツがいくらでもある。

      現在では、メインフレームの真価というのは、規模ではなくて耐障害性や復旧体制などの信頼性にあるのではないでしょうか。
      たとえ、従業員が1万人いる会社でも、信頼性をそれ程必要としない部分にメインフレームを使うのは無駄かもしれないし、従業員が10人でも、要求される信頼性からメインフレームを使った方が良い場合もあるかもしれない。
      そういう事を置いといて「おたくぐらいの規模の会社ならメインフレームが良い」と、規模だけで言うベンダはそろそろ切り捨てられるべき時期でしょうね。

      ダウンサイジングとお題目を唱えたところで、それが適用できない業務処理って厳然と実在するんだから。
      (現時点では)メインフレームでなくてはならない業務が存在するという点では同意しますが、「メインフレームでなくてはならないと考えられている業務」のうち、 「メインフレームの方がUn*xより能力が上」という神話のためにそう考えられている業務が、かなりの割合であるのではないかと思います。
      親コメント
      • by bugbird (4706) on 2001年11月05日 17時34分 (#35686) ホームページ 日記
         現在では、メインフレームの真価というのは、規模ではなくて耐障害性や復旧体制などの信頼性にあるのではないでしょうか。

        これには同意。たしかにこの要素もありますね。

         たとえ、従業員が1万人いる会社でも、信頼性をそれ程必要としない部分にメインフレームを使うのは無駄かもしれないし、従業員が10人でも、要求される信頼性からメインフレームを使った方が良い場合もあるかもしれない。

        …というよりも、いわゆるオンデマンドな環境である TSS ではなく、JCL を使うような(元祖)バッチ処理環境の下で処理するのに適している業務処理ってあるわけでしょ(厳密にはそうした環境の下で、最適の処理が出来るようにあれこれと資源が蓄積されてきているということだが)。これは CPU の能力とか信頼性云々とは直接関係ない。だから業務処理の特性を考えて『餅は餅屋』ソリューションを適用するべきじゃない? ってことなんだけど。

        バッチ処理で処理できてしまう業務処理を、TSS のマルチユーザで実行できたとして、それが本当に嬉しいのかど~かは、よ~く考えてみる必要あると思いますです。

        --
        --- Toshiboumi bugbird Ohta
        親コメント
        • (厳密にはそうした環境の下で、最適の処理が出来るようにあれこれと資源が蓄積されてきているということだが)。

           結局はこの部分が大きいのだと思います。

           メインフレームは、大昔の処理能力が少なかった頃から、いかにCPUなどの資源を無駄なく使うかを第一に、ハードもOSも、その上で動くシステムもデータも進化、蓄積してます。
          #と言うことですよね?

           その結果、専門家以外には非常に理解し難いものにもなっています。
           パソコンで出来るのに何でメインフレームでは出来ないの?って事もある、というレベルの話ですが。

           バッチ処理も、業務の形態と共に進化してきた処理の形態に過ぎないので、どんな方法でも、目的の出力が得られる仕組みが出来れば良い訳で、まったく違ったアプローチの解決を期待したいところ。
           そういった別のアプローチが出来るまでは、『餅は餅屋』なんでしょうね。
          親コメント
          • >その結果、専門家以外には非常に理解し難い
            >ものにもなっています。
            >パソコンで出来るのに何でメインフレームでは
            >出来ないの?って事もある、というレベルの話ですが。

            メインフレーム担当者と仕事をしていると、我々の
            感覚では理解できないことが多いのですが、その辺も
            やはり過去の資産|負債の蓄積なのでしょうか。

            JC
            • by nak (5484) on 2001年11月06日 12時05分 (#35887) ホームページ 日記
              メインフレーム担当者と仕事をしていると、我々の
              感覚では理解できないことが多いのですが、その辺も
              やはり過去の資産|負債の蓄積なのでしょうか。


               メインフレーム担当者の端くれとして書いてみます。
              #とはいえ、昔のIBMと、NECの小さいのしか使ってないので、最新のシステムに当てはめると、外してる部分もあるかと思いますが。

               メインフレームでシステムを構築する場合、設計上の余裕も考慮しますが、すべての資源は理由があって確保されます。
               PCのように資源が安ければ大きい(速い)の入れとけ、で済むのですが、メインフレームは、ここの資源のレベルに応じて維持費がかかるので、必要以上のスペックは厳禁です。

               またメインフレームでは、すべての資源は、基本的に静的に確保しておく必要があるため、ファイル1つとっても、どのディスクに、どういう編成で、何トラック確保するか、運用者が人手で指定しておくのが基本です。
              (もちろん、ある程度OSに任す事も出来ますが、常に把握は必要ですし、OSに任すと見積から外れた場合の処置が遅れるので、人手が基本だと思います)

               すべての資源がこの調子ですから、どこかに余裕の無い状態が発生していると、ちょっとした拡張でも、手間をかけて全体をすべて見直すか、追加の資源(≒お金)が必要です。

               この元コメントの中で18本がOKで、20本が駄目ってこだわったのも、根本的にはなんらかが不足する、見積値を超えると言う話があったのではないかと思います。

               同様にJCLをループうんぬんも、18本すべて同じなら問題ありませんが、違う部分がある以上、使う資源の確保も違うはずで、それを18本中の最大で揃えられたらたまらん、って事情もあるかも知れません。
              親コメント
      • 下位クラスのメインフレームだと、PCサーバにもCPUパワーで負けるヤツがいくらでもある。

         と言うか、すでに最低クラスは、Pentiumで動いてたり、HDDも3.5inchでSCSIのRAIDだったりするので、技術的にはOSの違いくらいしか無いでしょう。
         まぁ、周辺のバランスとかはそれなりに考えられてはいるはずですが。
         
        親コメント
        • メインフレームって、昔から下層レイヤで命令をマイクロコード化しているので、IPの下が何でも良いように、OSの下も何でも良いのでIA-32を使っているのだと思う。

          オフコンなんかも、AMDのbitスライス、独自、MIPS、IA-32と渡り歩いているようだし。
          親コメント
      • オフコンやってた人間に昔聞いたところでは、だいたいI/OにCPUを一個割り当てたりしているので、I/O自体の足腰が断然違うそうで。
        そういう観点からみるとcpuやhddが早くても、という事は依然としてあると思います。今のpcが早いのはあくまでpcとi/oがほぼ一対一の様な関係にあるものだけだという気がしますが、識者の方いかがでしょう。
        --
        -----------------
        #そんなワタシはOS/2ユーザー:-)
        親コメント
        • by yasiyasi (5450) on 2001年11月05日 20時44分 (#35743)
           メインフレームのチャネル・アーキテクチャの場合、PCやUNIXサーバーの類とはI/Oまわりは比較にならないほど高性能だと思うな。

           たいていのIBM-PC互換機の場合、ディスク類は133~266MBytes/sのPCIバス1本にぶら下がってますよね。
          SCSIだ、ファイバーチャネルだといっても、それらが最後につながるPCIバスで、トータルのI/O転送の最大能力が制限されちゃう。
           最近のメインフレームだと、チャネル1本は最大でも100MB/s程度だけど、チャネルが100本以上あって、それぞれが他のチャネルからもCPUからも独立してメモリとやり取りできる。

           あえて単純にモデル化するけど、「トータル最大233MBytes/secのPC」と「トータル100*100=10,000MBytes/secのメインフレーム」でI/O性能が勝負になるわけが無い。
           もちろん、「1本のチャネルにHDDが1個」なんて豪勢な使い方はせず、「4本のチャネルにHDDが60個」というような使い方が普通だろうから、上記はモデルが単純すぎて実態にそぐわないけど。

           メモリも日立の新型機だと、「ラインアップ上、最低でも2GB。1GBや512MBなんて小さすぎるので扱ってません。」だったりするし。

          親コメント
          • > メインフレームのチャネル・アーキテクチャの場合、PC
            >やUNIXサーバーの類とはI/Oまわりは比較にならないほど高
            >性能だと思うな。

            UNIXマシンの場合,大量の帳票印刷のためのプリンタを多数接続したりするのはどうしているんでしょう?
            もちろんメインフレームでは普通に実現出来ることですが.... メインフレームはやはりI/O周りは非常に強
            • by yasiyasi (5450) on 2001年11月05日 22時16分 (#35771)
              > UNIXマシンの場合,大量の帳票印刷のためのプリンタを多数接続したりするのはどうしているんでしょう?
               UNIXマシンやPCサーバで大量印刷をする場合、「帳票が必要な現場にプリンタを1台ずつ置いて、ネットワーク接続で印刷させる」というのが代表的なソリューションだったと思います。つまり、チャネルでもパラレル・ポートでもなく、イーサネットでプリンタ接続しているわけですね。
              # 印刷データ格納→印刷イメージ作成→長時間印刷に加えて、
              # 印刷には直接かかわり無いTCP/IP処理も必要になるから、
              # 余計なところに能力を食われてないか?>UNIXなど用高速プリンタ

               メインフレームのプリンタ室で一気に印刷しても、現場に帳票を輸送する時間が必要になります。現場で印刷すれば輸送時間が削減できるので、その分をプリンタの能力不足を補うのにまわす、ということでしょう。

               それでもまだ能力が足りないから「紙に印刷する量」自体を減らそうと、ディスプレイ上で帳票イメージを見れるアプリケーションを売っていたりするのでしょうか(笑)

               帳票が必要な「現場」が、身内の事務室なら上記の分散印刷でまかなえるでしょうが、個人の自宅宛てのように郵送しなきゃならん「現場」相手だと、まだまだメインフレーム式の集中印刷でないとダメですね。

              (閑話)
               それに、現場で印刷させるとなったら、紙の補充などを現場の人間にやらせないといかんじゃないか。「休日に大量印刷させるから、用紙補充と印刷物の整理に各地で2、3名ずつ、合計数十名、出社しろ。その前日までに印刷用紙をいっぱい送りつけるから、倉庫の整理も忘れずに」なんて業務命令 、受けたい?
              親コメント
    • 私も「終らない」に一票。
       
      ただ、メインフレームは、それを買えばメーカが責任もって対処してくれる事実なのではないかと。つまり、一番重要なのはサービスモデルであって、マシンの構成はあまり関係ないのではないでしょうか?
       
      だからこそ、オフコンより速いファミコン などという状況がありえるにもかかわらず、 本州産業が全社システムをオフコンで再構築,NTサーバーの信頼性に満足できずなんてことになるのでしょう。
       
      これが正しければ、Linuxクラスタマシンにオンサイトサービスをつけて, メインフレームだと言う所があっても不思議ではない気がします。サーバ用にPCハードを厳選したり、それこそメインフレームのVMを利用したりして。
       
      #というのが、IBMのねらい?
      親コメント
  • by tma20 (3064) on 2001年11月05日 21時08分 (#35747)
    なんかよっぽどのことがない限り、ですが。
    いままでの資源(資産)をすこしづつ他の手段に
    代替されていくのでしょうねぇ。
    ちなみに、帳票出力なんてのもホストの
    つよみだと思うんですけど、どーすかね?
    数十「箱」単位でサクッと印刷できる仕掛けって
    Win や unix方面にあるかな。
  • by atrib (5512) on 2001年11月05日 14時26分 (#35645)
    >日本電気では、Win2K/NTサーバー付属のメイン
    >フレームなんてのが主力になりつつあるのだが
      本当に「大丈夫なのか!?」ですね(^^;
     ・週一でリブートしないとダメなメインフレーム。
     ・"\t\t\b\b\b\b\b\b"でリブートするメインフレーム。
     ・一般保護法メインフレーム

     コ、コワイ・・・(笑)
    • by visha (779) on 2001年11月05日 14時47分 (#35649) 日記

      あくまで Win2k/NTサーバベースのメインフレームではなく、Win2k/NTサーバ付属のメインフレームだからねぇ。中心になってるのはACOSなんじゃなかろか。戦略としては、

      • 落ちてもいい機能をくくり出して付属のWin系サーバ上に載せる。理由はたぶんコストと手軽さ。
      • 落ちては困る機能は多少の金と手間をかけてでもACOS上に載せる。
      • 両者をうまくつなぐ。

      ってとこでしょう。悪くはないと思うけどね。まぁ、SIのバランス感覚が問われそうだけど。

      親コメント
      • たしかに良くある話な気がします。社員が使う端末は大体Windowsだろうから、それ用のPDCを無料でプレゼントみたいな乗りの気もするし。1つのOSで全てを賄おうってのも、土台無理な気もしますな。特に経済的に。

        何にせよ、技術に固執するのはね・・・
        親コメント
      • by nak (5484) on 2001年11月05日 18時25分 (#35701) ホームページ 日記
        #タレコミ者です。

         大筋において、サーバー付属の理由は、vishaさんが書かれている感じの理由なんだろうと思います。

         ついでに補足しておくと、現在のACOSに付属のサーバーは、ACOS本体内に用意されたラックに設置されますが、あくまで独立したサーバーなので、ACOS自体が落ちることは無いそうです。
         とはいえ、のっとられたら怖いですが。

         で、このサーバーは、メールサーバーとか、Webサーバーとか、DBサーバーとか、必要な機能単位にパッケージになっているソフトと共に、任意の台数簡単に導入できる。というのが売りの1つです。

         なお、この1つ前のACOSまで(今もオプションで残ってますが)は、外付けのEWSにUNIXが入っており、FTP、TELNET、MAILの各サーバーの運用が可能でした。
        #コンソールにHP200LXが付いてるので、わかる人ならさらにいじることもできましたが。

         あと個人的には、ACOSはデータベースが弱いので、Oracleをのっけたいって考えがあるのでは無いかと思います。
        親コメント
        • #コンソールにHP200LXが付いてるので、わかる人ならさらにいじることもできましたが。

          え、その構成に標準でですか? そいつぁものすごくソソられるんですけど、わたしって変ですかね(笑)。

          親コメント
        • #コンソールにHP200LXが付いてるので、わかる人ならさらにいじることもできましたが。

          そうか、この前見たHP200LXはそう言う事だったのか。

          某所でそのものをみて以来、きっとオペレータの趣味に違いないと思っていました。
          身元が分かるとまずいのでACにしておきます。
      • 「Win系メインフレームって」のコメントを書いた者です。

        >Win2k/NTサーバ付属のメインフレームだからねぇ。
        なるほど。そういうことですか(^^;

        さっと元記事を読んだだけで反応してしまいました。 明後日の方向に勘違いしたコメントを書いてすみませんでした。m(_ _)m

        親コメント
    • by yasiyasi (5450) on 2001年11月05日 20時20分 (#35735)
      ・週一でリブートしないとダメなメインフレーム。
      私の勤め先のメインフレームは「毎日リブートが必須」だ。

      んで、WinNTのBDCサーバどもは、「リブートは年1回」

      運用の原則の差もあるし、
      「業務時間中、絶対、不都合が置きてはいかん」メインフレームと、
      「1台が止まっても、代替機があと10台ある」BDCサーバの違いもあるだろうな。

      親コメント
    • 前にいた会社(金融系ですよ)はOSはWindozeじゃなかったけど、毎日リブート「は」していたよ。マジで。もちろん、週末はシャットダウンしてましたよ。

      まあ、計算処理しかしないからだろうけど。

      親コメント
    • いくら,ハードを強固にしたらかって,ソフトが 糸引いていたらダメなのでは?
      --
      ★田舎に生息する時代遅れのFortran&COBOLガイなオタク★
      親コメント
  • by Anonymous Coward on 2001年11月05日 22時41分 (#35775)

    「メインフレームの行き先」というと。

    やっぱりその9割は、

    1.ごみ箱
    2.東京湾夢の島
    3.鉄クズ業者
    4.会社の裏の物置場(屋根なし)

    のどれかだろうなぁ。
    昔は高かったんだよ、これ。なんて。

    あとの1割はやっぱ用途が少々あると思う。
    冬場の暖房とか。

    • by yasiyasi (5450) on 2001年11月05日 22時53分 (#35777)
      > 冬場の暖房とか。

      Athlonの「焼き鳥」程度じゃ済まんだろうな(笑)

      # 一度は引きたい、メインフレームの「緊急停止スイッチ」
      ## メインフレームから煙が立ち昇ったときだけ、使用が許可される。
      ## リプレースでお持ち帰りの機材でも、「引いたらアカン」と
      ## メンテナンス屋さんにも、営業さんにも頼み込まれてしまった。

      親コメント
      • by zzztkf (4496) on 2001年11月06日 8時52分 (#35841) 日記
        前の会社で停止スイッチおしちゃったえらいさんが いたそうです。

        「なんだこりゃ」みたいな感じで、、、ハードウェアは 日立のメインフレームだったそうな。

        やはり、後始末は大変だったそうです。

        --
        life is too short to hate each other.
        親コメント
      • by NickName.Kom (5985) on 2001年11月06日 18時57分 (#36031)
        ># 一度は引きたい、メインフレームの「緊急停止スイッチ」

        本体の緊急停止ではありませんが、メインフレーム用のHDDのブレーカを落としたことがあります。
        瞬停で本体が落ちたのにHDDが生き残っていて、本体の再起動時にHDD電源のリモート起動エラーになり、
        HDDには緊急停止スイッチが「無い」ために電源のブレーカを落としました。
        #やっぱり、「緊急停止」は必要です。
        --
        Kom
        親コメント
        • by yasiyasi (5450) on 2001年11月07日 20時06分 (#36387)
          > 瞬停で本体が落ちたのにHDDが生き残っていて、本体の再起動時にHDD電源の
          > リモート起動エラーになり、HDDには緊急停止スイッチが「無い」ために電源のブレーカを
          > 落としました。
           もしや、分電盤のブレーカーを落としたのですか? わが勤め先では、分電盤の接続先表示ラベルにいまいち信頼がおけないので、それをするには度胸がいるなぁ(汗)
           復旧のために、メンテナンス屋さんを呼んだり、大騒ぎになったのではないでしょうか。ご苦労、しのばれます。

          # HDDの緊急停止スイッチの有無より、「瞬停で本体が落ちた」
          # ほうに驚愕してしまった(汗)

          親コメント

      • それを引くのが天邪鬼の天邪鬼たる所以。

        • by sham (4555) on 2001年11月06日 3時45分 (#35825)
          印刷指示したやつが自分で取りに来れる場所に置いていたプリンタでの話。
          勝手にプリンタの赤レバー引いた奴がいました。
          復旧がむちゃくちゃ大変・・・

          /.jpの方々ならご存知の方が多いと思いますが・・
          汎用機のプリンタで帳票を印刷するって実物見た事ある人しかイメージわかないぐらいすごいです。
          目の前を印刷した文字が見えない速度で流れ、紙が箱単位で消えていきます。

          それと、汎用機のMIPSって今のPCと比べるとたいした事ない程度ですが、1命令でできる事が桁違います。
          文字列比較がアセンブラ1命令って感動したなぁ。

          By シャム
          親コメント
          • > 汎用機のプリンタで帳票を印刷するって実物見た事ある人しかイメージわかないぐらいすごいです。
            > 目の前を印刷した文字が見えない速度で流れ、紙が箱単位で消えていきます。

             ちなみに、わが職場では、15×11インチ応用用紙(B4判ぐらいの大きさ)について、

            • 1箱あたり2000ページ詰め込まれてる
            • 1箱あたり15分で用紙交換
            が目安です。計算すると、だいたい133ページ/分か。この程度のスペックなら、メインフレーム界隈じゃたいしたことあるまいて。

             で、このプリンタを3台たばねて、ひぃひぃ言いながら印刷をこなしてます。

            # ひぃひぃ言っているのは、私らじゃなくて、
            # はやりの圧着葉書が出す臭い匂いの中、用紙交換するオペレータさんと、
            # オンボロ・プリンタを相手にするメンテナンス屋さんだが。

            親コメント
          • なんて、怪物が稼動していると聞いたことがあります。(笑)

            ちょいと、PCやWSとは、次元が違うんだよねぇ。
            親コメント
    • 1. 横倒しにして公園のベンチ
      2. 駅のベンチ
      3. トーテムポール
      4. モノリス
      5. 墓石
      6. 滑り台
      7. 机
      8. 中身ぬいてタンス
      9. ウルトラ警備隊ごっこ用コンピュータ
      --
      (´д`;)
      親コメント
  • by WindKnight (1253) on 2001年11月06日 9時45分 (#35850) 日記
    飛行機の牽引車みたいなものですかね。

    そう簡単に無くなることはないでしょう。

    代替するにしても、似たような代物になってしまうだろうなぁ。
    • 技術的な方向で見るなら PC を乗用車とすれば F1 マシンみたいなもんですかね。

      高い、速いのほかにもメンテ、いろいろセッティングが細かい等々、UNIX や Windows といった「普通の」OS がやるようなことを人手でやりますからね。

      用途で考えたら、トラクタかトラックか(笑)

      親コメント
  • なので, メインフレームを希望する利用者があるかぎり メインフレームは無くなってほしくない. また,今年 (に限った話ではないか?)はM$系ウィルスの当たり年の ため,一部オフコンやメインフレームを再検討する 利用者がでてきたとか... でも,企業は利益のでない商品をいつまでも売るとは 限らないのです. もし,メインフレームが欲しくても それに見合う費用を利用者が負担できないのであれば, 無くなるでしょうね... メインフレーム国内メーカは風前の灯火状態...結局,Iの 独り勝ちか...
    --
    ★田舎に生息する時代遅れのFortran&COBOLガイなオタク★
  • by Anonymous Coward on 2001年11月06日 11時32分 (#35876)
     PCやUNIXサーバの個体は、十数年間というスパンでは生き残れまい。メインフレームなら、大丈夫、生き延びる。

     PCやUNIXサーバの場合、基本アーキテクチャやOSの改変が頻繁すぎる。メインフレームが取り扱うような基幹システムで、こんなに頻繁にシステムの根幹を書き換えられては、仕事にならない。

    • by nekopon (1483) on 2001年11月06日 13時15分 (#35903) 日記
      そんなあなたにオープンソース。
      親コメント
      • by oku (4610) on 2001年11月06日 14時47分 (#35926) 日記

        オープンソースでなくても 「2001年現在において CP/M-80 を使う」 覚悟があれば構わないかと思いますが。

        で、件の話について言えばオープンソースは あまり役には立たないと思います。
        OS だのミドルウェアだのが 頻繁に更新されて上位のアプリケーションが 影響を受けたりするのはかなわん、 という文脈でしょうから。
        もちろんオープンソースなら自前でメンテナンスできる というメリットがあるわけですが

        • OS だのミドルウェアだのを自前でメンテナンスする
        • 更新された下位層に合わせてアプリケーションをメンテナンスする
        の二者択一であれば どちらも「頻繁に更新」に該当してしまいますので。

        ホスト屋さんの世界なら 「アプリケーションをいじる理由は業務要件のみ」に限定できます(大抵の場合は、ですが)。

        親コメント
typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...