アカウント名:
パスワード:
終わるわけないと思うけどなぁ。SCモデル化でダウンサイジングとお題目を唱えたところで、それが適用できない業務処理って厳然と実在するんだから。
従業員総数が数千人以上の企業・企業グループの月次決算処理などを一括してひっかき回せるのは、やっぱりそっちの方面のマシンしかないでしょ。まぁたしかに
…で、この規模以上の企業ってのは結構「あたりまえ」にあるわけじゃないですか。
何か規模に拘ってるみたいですが、 「メインフレームはUn*xマシンよりCPUやディスクアクセスなどの能力が上」という神話はいまだに健在なのでしょうか? 最近の情勢だと、メインフレームと上位のUn*xマシンだとCPU能力の点でも、扱えるメモリ、ディスク資源なんかもそれ程差はありません。 下位クラスのメインフレームだと、PCサーバにもCPUパワーで負けるヤツがいくらでもある。
現在では、メインフレームの真価というのは、規模ではなくて耐障害性や復旧体制などの信頼性にある
これには同意。たしかにこの要素もありますね。
たとえ、従業員が1万人いる会社でも、信頼性をそれ程必要としない部分にメインフレームを使うのは無駄かもしれないし、従業員が10人でも、要求される信頼性からメインフレームを使った方が良い場合もあるかもしれない。
…というよりも、いわゆるオンデマンドな環境である TSS ではなく、JCL を使うような(元祖)バッチ処理環境の下で処理する
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
たしかに激減するだろうけど… (スコア:2, 興味深い)
終わるわけないと思うけどなぁ。SCモデル化でダウンサイジングとお題目を唱えたところで、それが適用できない業務処理って厳然と実在するんだから。
従業員総数が数千人以上の企業・企業グループの月次決算処理などを一括してひっかき回せるのは、やっぱりそっちの方面のマシンしかないでしょ。まぁたしかに
--- Toshiboumi bugbird Ohta
Re:たしかに激減するだろうけど… (スコア:5, 参考になる)
何か規模に拘ってるみたいですが、 「メインフレームはUn*xマシンよりCPUやディスクアクセスなどの能力が上」という神話はいまだに健在なのでしょうか?
最近の情勢だと、メインフレームと上位のUn*xマシンだとCPU能力の点でも、扱えるメモリ、ディスク資源なんかもそれ程差はありません。
下位クラスのメインフレームだと、PCサーバにもCPUパワーで負けるヤツがいくらでもある。
現在では、メインフレームの真価というのは、規模ではなくて耐障害性や復旧体制などの信頼性にある
Re:たしかに激減するだろうけど… (スコア:2, すばらしい洞察)
これには同意。たしかにこの要素もありますね。
たとえ、従業員が1万人いる会社でも、信頼性をそれ程必要としない部分にメインフレームを使うのは無駄かもしれないし、従業員が10人でも、要求される信頼性からメインフレームを使った方が良い場合もあるかもしれない。
…というよりも、いわゆるオンデマンドな環境である TSS ではなく、JCL を使うような(元祖)バッチ処理環境の下で処理する
--- Toshiboumi bugbird Ohta
Re:たしかに激減するだろうけど… (スコア:1)
結局はこの部分が大きいのだと思います。
メインフレームは、大昔の処理能力が少なかった頃から、いかにCPUなどの資源を無駄なく使うかを第一に、ハードもOSも、その上で動くシステムもデータも進化、蓄積してます。
#と言うことですよね?
その結果、専門家以外には非常に理解し難いものにもなっています
Re:たしかに激減するだろうけど… (スコア:0)
>ものにもなっています。
>パソコンで出来るのに何でメインフレームでは
>出来ないの?って事もある、というレベルの話ですが。
メインフレーム担当者と仕事をしていると、我々の
感覚では理解できないことが多いのですが、その辺も
やはり過去の資産|負債の蓄積なのでしょうか。
JC
担当者の言い分 (スコア:2, 興味深い)
感覚では理解できないことが多いのですが、その辺も
やはり過去の資産|負債の蓄積なのでしょうか。
メインフレーム担当者の端くれとして書いてみます。
#とはいえ、昔のIBMと、NECの小さいのしか使ってないので、最新のシステムに当てはめると、外してる部分もあるかと思いますが。
メインフレームでシステムを構築する場合、設計上の余裕も考慮しますが、すべての資源は理由があって確保されます。
PCのように資源が安ければ大きい(速い)の入れとけ、で済むのですが、メインフレームは、ここの資源のレベルに応じて維持費がかかるので、必要以上のスペックは厳禁です。
またメインフレームでは、すべての資源は、基本的に静的に確保しておく必要があるため、ファイル1つとっても、どのディスクに、どういう編成で、何トラック確保するか、運用者が人手で指定しておくのが基本です。
(もちろん、ある程度OSに任す事も出来ますが、常に把握は必要ですし、OSに任すと見積から外れた場合の処置が遅れるので、人手が基本だと思います)
すべての資源がこの調子ですから、どこかに余裕の無い状態が発生していると、ちょっとした拡張でも、手間をかけて全体をすべて見直すか、追加の資源(≒お金)が必要です。
この元コメントの中で18本がOKで、20本が駄目ってこだわったのも、根本的にはなんらかが不足する、見積値を超えると言う話があったのではないかと思います。
同様にJCLをループうんぬんも、18本すべて同じなら問題ありませんが、違う部分がある以上、使う資源の確保も違うはずで、それを18本中の最大で揃えられたらたまらん、って事情もあるかも知れません。