アカウント名:
パスワード:
終わるわけないと思うけどなぁ。SCモデル化でダウンサイジングとお題目を唱えたところで、それが適用できない業務処理って厳然と実在するんだから。
従業員総数が数千人以上の企業・企業グループの月次決算処理などを一括してひっかき回せるのは、やっぱりそっちの方面のマシンしかないでしょ。まぁたしかに "Sun On Sun" のような実例がないわけじゃないが、これはあくまで特殊事例。普通のベンダならメインフレームで同じシステムを組む方が合理的と考えるハズ…だし、そう考えてくれなきゃ、それはそれで相当恐ろしいことだったりする。
…で、この規模以上の企業ってのは結構「あたりまえ」にあるわけじゃないですか。
現在では、メインフレームの真価というのは、規模ではなくて耐障害性や復旧体制などの信頼性にあるのではないでしょうか。 たとえ、従業員が1万人いる会社でも、信頼性をそれ程必要としない部分にメインフレームを使うのは無駄かもしれないし、従業員が10人でも、要求される信頼性からメインフレームを使った方が良い場合もあるかもしれない。 そういう事を置いといて「おたくぐらいの規模の会社ならメインフレームが良い」と、規模だけで言うベンダはそろそろ切り捨てられるべき時期でしょうね。
ダウンサイジングとお題目を唱えたところで、それが適用できない業務処理って厳然と実在するんだから。
これには同意。たしかにこの要素もありますね。
たとえ、従業員が1万人いる会社でも、信頼性をそれ程必要としない部分にメインフレームを使うのは無駄かもしれないし、従業員が10人でも、要求される信頼性からメインフレームを使った方が良い場合もあるかもしれない。
…というよりも、いわゆるオンデマンドな環境である TSS ではなく、JCL を使うような(元祖)バッチ処理環境の下で処理するのに適している業務処理ってあるわけでしょ(厳密にはそうした環境の下で、最適の処理が出来るようにあれこれと資源が蓄積されてきているということだが)。これは CPU の能力とか信頼性云々とは直接関係ない。だから業務処理の特性を考えて『餅は餅屋』ソリューションを適用するべきじゃない? ってことなんだけど。
バッチ処理で処理できてしまう業務処理を、TSS のマルチユーザで実行できたとして、それが本当に嬉しいのかど~かは、よ~く考えてみる必要あると思いますです。
たいていの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なんて小さすぎるので扱ってません。」だったりするし。
> UNIXマシンの場合,大量の帳票印刷のためのプリンタを多数接続したりするのはどうしているんでしょう?
メインフレームのプリンタ室で一気に印刷しても、現場に帳票を輸送する時間が必要になります。現場で印刷すれば輸送時間が削減できるので、その分をプリンタの能力不足を補うのにまわす、ということでしょう。
それでもまだ能力が足りないから「紙に印刷する量」自体を減らそうと、ディスプレイ上で帳票イメージを見れるアプリケーションを売っていたりするのでしょうか(笑)
帳票が必要な「現場」が、身内の事務室なら上記の分散印刷でまかなえるでしょうが、個人の自宅宛てのように郵送しなきゃならん「現場」相手だと、まだまだメインフレーム式の集中印刷でないとダメですね。
(閑話) それに、現場で印刷させるとなったら、紙の補充などを現場の人間にやらせないといかんじゃないか。「休日に大量印刷させるから、用紙補充と印刷物の整理に各地で2、3名ずつ、合計数十名、出社しろ。その前日までに印刷用紙をいっぱい送りつけるから、倉庫の整理も忘れずに」なんて業務命令 、受けたい?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
たしかに激減するだろうけど… (スコア:2, 興味深い)
終わるわけないと思うけどなぁ。SCモデル化でダウンサイジングとお題目を唱えたところで、それが適用できない業務処理って厳然と実在するんだから。
従業員総数が数千人以上の企業・企業グループの月次決算処理などを一括してひっかき回せるのは、やっぱりそっちの方面のマシンしかないでしょ。まぁたしかに "Sun On Sun" のような実例がないわけじゃないが、これはあくまで特殊事例。普通のベンダならメインフレームで同じシステムを組む方が合理的と考えるハズ…だし、そう考えてくれなきゃ、それはそれで相当恐ろしいことだったりする。
…で、この規模以上の企業ってのは結構「あたりまえ」にあるわけじゃないですか。
--- Toshiboumi bugbird Ohta
Re:たしかに激減するだろうけど… (スコア:5, 参考になる)
最近の情勢だと、メインフレームと上位のUn*xマシンだとCPU能力の点でも、扱えるメモリ、ディスク資源なんかもそれ程差はありません。
下位クラスのメインフレームだと、PCサーバにもCPUパワーで負けるヤツがいくらでもある。
現在では、メインフレームの真価というのは、規模ではなくて耐障害性や復旧体制などの信頼性にあるのではないでしょうか。
(現時点では)メインフレームでなくてはならない業務が存在するという点では同意しますが、「メインフレームでなくてはならないと考えられている業務」のうち、 「メインフレームの方がUn*xより能力が上」という神話のためにそう考えられている業務が、かなりの割合であるのではないかと思います。たとえ、従業員が1万人いる会社でも、信頼性をそれ程必要としない部分にメインフレームを使うのは無駄かもしれないし、従業員が10人でも、要求される信頼性からメインフレームを使った方が良い場合もあるかもしれない。
そういう事を置いといて「おたくぐらいの規模の会社ならメインフレームが良い」と、規模だけで言うベンダはそろそろ切り捨てられるべき時期でしょうね。
Re:たしかに激減するだろうけど… (スコア:2, すばらしい洞察)
これには同意。たしかにこの要素もありますね。
たとえ、従業員が1万人いる会社でも、信頼性をそれ程必要としない部分にメインフレームを使うのは無駄かもしれないし、従業員が10人でも、要求される信頼性からメインフレームを使った方が良い場合もあるかもしれない。
…というよりも、いわゆるオンデマンドな環境である TSS ではなく、JCL を使うような(元祖)バッチ処理環境の下で処理するのに適している業務処理ってあるわけでしょ(厳密にはそうした環境の下で、最適の処理が出来るようにあれこれと資源が蓄積されてきているということだが)。これは CPU の能力とか信頼性云々とは直接関係ない。だから業務処理の特性を考えて『餅は餅屋』ソリューションを適用するべきじゃない? ってことなんだけど。
バッチ処理で処理できてしまう業務処理を、TSS のマルチユーザで実行できたとして、それが本当に嬉しいのかど~かは、よ~く考えてみる必要あると思いますです。
--- Toshiboumi bugbird Ohta
Re:たしかに激減するだろうけど… (スコア:1)
結局はこの部分が大きいのだと思います。
メインフレームは、大昔の処理能力が少なかった頃から、いかにCPUなどの資源を無駄なく使うかを第一に、ハードもOSも、その上で動くシステムもデータも進化、蓄積してます。
#と言うことですよね?
その結果、専門家以外には非常に理解し難いものにもなっています。
パソコンで出来るのに何でメインフレームでは出来ないの?って事もある、というレベルの話ですが。
バッチ処理も、業務の形態と共に進化してきた処理の形態に過ぎないので、どんな方法でも、目的の出力が得られる仕組みが出来れば良い訳で、まったく違ったアプローチの解決を期待したいところ。
そういった別のアプローチが出来るまでは、『餅は餅屋』なんでしょうね。
Re:たしかに激減するだろうけど… (スコア:0)
>ものにもなっています。
>パソコンで出来るのに何でメインフレームでは
>出来ないの?って事もある、というレベルの話ですが。
メインフレーム担当者と仕事をしていると、我々の
感覚では理解できないことが多いのですが、その辺も
やはり過去の資産|負債の蓄積なのでしょうか。
JC
担当者の言い分 (スコア:2, 興味深い)
感覚では理解できないことが多いのですが、その辺も
やはり過去の資産|負債の蓄積なのでしょうか。
メインフレーム担当者の端くれとして書いてみます。
#とはいえ、昔のIBMと、NECの小さいのしか使ってないので、最新のシステムに当てはめると、外してる部分もあるかと思いますが。
メインフレームでシステムを構築する場合、設計上の余裕も考慮しますが、すべての資源は理由があって確保されます。
PCのように資源が安ければ大きい(速い)の入れとけ、で済むのですが、メインフレームは、ここの資源のレベルに応じて維持費がかかるので、必要以上のスペックは厳禁です。
またメインフレームでは、すべての資源は、基本的に静的に確保しておく必要があるため、ファイル1つとっても、どのディスクに、どういう編成で、何トラック確保するか、運用者が人手で指定しておくのが基本です。
(もちろん、ある程度OSに任す事も出来ますが、常に把握は必要ですし、OSに任すと見積から外れた場合の処置が遅れるので、人手が基本だと思います)
すべての資源がこの調子ですから、どこかに余裕の無い状態が発生していると、ちょっとした拡張でも、手間をかけて全体をすべて見直すか、追加の資源(≒お金)が必要です。
この元コメントの中で18本がOKで、20本が駄目ってこだわったのも、根本的にはなんらかが不足する、見積値を超えると言う話があったのではないかと思います。
同様にJCLをループうんぬんも、18本すべて同じなら問題ありませんが、違う部分がある以上、使う資源の確保も違うはずで、それを18本中の最大で揃えられたらたまらん、って事情もあるかも知れません。
Re:たしかに激減するだろうけど… (スコア:2, 参考になる)
と言うか、すでに最低クラスは、Pentiumで動いてたり、HDDも3.5inchでSCSIのRAIDだったりするので、技術的にはOSの違いくらいしか無いでしょう。
まぁ、周辺のバランスとかはそれなりに考えられてはいるはずですが。
Re:たしかに激減するだろうけど… (スコア:1)
オフコンなんかも、AMDのbitスライス、独自、MIPS、IA-32と渡り歩いているようだし。
Re:たしかに激減するだろうけど… (スコア:1)
そういう観点からみるとcpuやhddが早くても、という事は依然としてあると思います。今のpcが早いのはあくまでpcとi/oがほぼ一対一の様な関係にあるものだけだという気がしますが、識者の方いかがでしょう。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:たしかに激減するだろうけど… (スコア:2, 興味深い)
たいていの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なんて小さすぎるので扱ってません。」だったりするし。
Re:たしかに激減するだろうけど… (スコア:0)
>やUNIXサーバーの類とはI/Oまわりは比較にならないほど高
>性能だと思うな。
UNIXマシンの場合,大量の帳票印刷のためのプリンタを多数接続したりするのはどうしているんでしょう?
もちろんメインフレームでは普通に実現出来ることですが.... メインフレームはやはりI/O周りは非常に強
Re:たしかに激減するだろうけど… (スコア:3, すばらしい洞察)
# 印刷データ格納→印刷イメージ作成→長時間印刷に加えて、
# 印刷には直接かかわり無いTCP/IP処理も必要になるから、
# 余計なところに能力を食われてないか?>UNIXなど用高速プリンタ
メインフレームのプリンタ室で一気に印刷しても、現場に帳票を輸送する時間が必要になります。現場で印刷すれば輸送時間が削減できるので、その分をプリンタの能力不足を補うのにまわす、ということでしょう。
それでもまだ能力が足りないから「紙に印刷する量」自体を減らそうと、ディスプレイ上で帳票イメージを見れるアプリケーションを売っていたりするのでしょうか(笑)
帳票が必要な「現場」が、身内の事務室なら上記の分散印刷でまかなえるでしょうが、個人の自宅宛てのように郵送しなきゃならん「現場」相手だと、まだまだメインフレーム式の集中印刷でないとダメですね。
Re:たしかに激減するだろうけど… (スコア:2)
ただ、メインフレームは、それを買えばメーカが責任もって対処してくれる事実なのではないかと。つまり、一番重要なのはサービスモデルであって、マシンの構成はあまり関係ないのではないでしょうか?
だからこそ、オフコンより速いファミコン などという状況がありえるにもかかわらず、 本州産業が全社システムをオフコンで再構築,NTサーバーの信頼性に満足できずなんてことになるのでしょう。
これが正しければ、Linuxクラスタマシンにオンサイトサービスをつけて, メインフレームだと言う所があっても不思議ではない気がします。サーバ用にPCハードを厳選したり、それこそメインフレームのVMを利用したりして。
#というのが、IBMのねらい?