メインフレーム専門書発売さる 57
ストーリー by soara
zを使う新人たちへ 部門より
zを使う新人たちへ 部門より
変なJCL?の印刷された奴しか見たことない 曰く、
21世紀も初めの十年が過ぎようとしていますが、この時期に「メインフレーム」の書籍が発売されました。書名は、「メインフレーム実践ハンドブック(z/OS,MSP,VOS3のしくみと使い方)」(リックテレコム)。
●21世紀に贈る唯一のメインフレーム専門書
メインフレーム(汎用機)のように多彩な機能をもつOSのシステムプログラマーには多くの幅広い知識を要求されるにもかかわらず、自己研鑽しようにも市販の日本語の専門書が、一冊も存在しないという特異な状況…。この状況を打破する1冊です！
監修者によると、
ここ20年以上、メインフレームの市販本はなかったかと思います。しかし、周囲の悪口をよそにメインフレームは台数こそ増え、減る気配はありません。これは、メインフレームでなければできない業務、とくにミッション・クリティカルな基幹業務が多数あることを意味していると思います。
市販の本がないため、情報処理試験の入門書を見たり、メインフレームの学習自体をあきらめてしまわざるを得なかったり、よくわからないまま「言い伝え」で使っていたりする会社、部署も多いはずです。
ということで、入門からプロの初級の上レベルまでを対象としているそうなので、興味のある方は読んでみてはいかがでしょうか?
かってのメインフレーマー (スコア:4, 興味深い)
私も、何を隠そう、かってメインフレーマーの関係者です。
大昔（歳がばれるので、明記はしません）は、
「オペレーテイング・システムへの構造的アプローチ」 江村潤郎著 全３巻 日本コンピュータ協会発刊
がバイブルでした。
今読んでも名著だったと思います。1977年発刊なので、入手出来るのか分かりませんが、タレコミの本
に飽き足らない人にお勧めです。
Re:かってのメインフレーマー (スコア:2, 興味深い)
今は「メインフレーム」と言ってもプロセッサ本体は（かつての）オフコン／ミニコンなみの小ささで，
今のデータセンターのラックいっぱいのサーバー群と比べたら実に可愛い（？）もんです．
過去の遺物であるかのように扱われる名前はやめて「ミッション・クリティカル・マシン」とでも呼び変えた方が良いのではないかと思います．
Re:かってのメインフレーマー (スコア:3, 参考になる)
いや, それは「トランザクション・プロセッサ」の方が適切でしょう. 単にミッションクリティカルと言うなら, ファクトリコントロール等に使われるかつてのミニコンの類や, 最近の大規模UNIXサーバでもメインフレームに準ずる機能・性能を持っています. メインフレームをメインフレームたらしめているのは, 強力な入出力性能と, それをベストエフォートではなく確実に出しうるOS・モニタでしょう.
ただ, 特に日本においてこうした本来のトランザクション・プロセッサとして使われていたのがどれだけ有ったか? ってことですね. おそらくユーザとしては大規模金融機関や国家レベルの公共機関ぐらいで, 多くの民間企業や地方公共団体は文字通り「汎用機」としてのみ使っていたのでしょう. 実際, 日本では中小型汎用機の出荷が他国と比べて突出して多いという統計もありましたから.
ですから, メインフレームがこの先無くなることはないでしょうし, 処理能力の拡大要求に対応して台数も増えていくんでしょうが, 今日のスパコンがそうであるように(昔は数値計算も汎用機でやってたんですよ), 実際にシステムとして携われる機会はどんどん減っていくと思います.
Re:かってのメインフレーマー (スコア:1)
余計なものかもしれませんが・・・
「ミッション・クリティカル・マシン」だと、
タンデムのNonStopやIBMのS/88みたいな、FTミニコンの印象を感じますし、
「トランザクション・プロセッサ」だと、
オンライン機の印象を受けてしまいます。
DBトランザクションの世界では、東芝のミニコン＋ORACLEで、座席予約システムが、構築されている関係もあるのでしょうが
（あくまでも、私にとってですが）
＞強力な入出力性能と, それをベストエフォートではなく確実に出しうるOS・モニタ
が生み出している、高速バッチ処理というポイントが、あらわされていないような気が・・・
高信頼汎用機であることを表現するというのは、難しいですね。
汎用機というけど、事務計算がメインになってるのは、否めないですけど。
ですから、今でも・・・メインフレームという言葉が、死語になっていないのかも
Re:かってのメインフレーマー (スコア:2, おもしろおかしい)
Re: (スコア:0)
＃AC にしておいて、個人的にはメインフレームをメインフレームたらしめているのは強力なエラー検出とリトライ機能のハードウェア作り込みだと思う。
エンタープライズサーバ（オフトピ気味） (スコア:1)
メインフレームで名をはせた大手の企業は、エンタープライズ・サーバといっていましたね。
IOPやチャネルがめちゃめちゃ強いし、収集したデータは、ほとんどロストしない。
ESAプロダクトなんてものもあったような気が・・・
Re:かってのメインフレーマー (スコア:1)
でも高いんですよね、あそこの本って。
もう少し最近（っていっても1986年頃だけど）だと、
近代科学社の「MVSの機能と構造」千田 正彦著
がありました。これも重宝しましたね。
さっきamazonで検索したら新刊はもう売ってないようです。
中古予約を見てみたら平均価格が\7500くらい、って
これって新刊のときの値段より高くね？
プレミア付きってことでしょうか。
日本コンピュータ協会(オフトピ) (スコア:0)
# オレンジ色の高い本出してるとこですよね？
Re:日本コンピュータ協会(オフトピ) (スコア:3, 興味深い)
># オレンジ色の高い本出してるとこですよね？
よくご存知ですね。昔は、日本コンピュータ協会しか、安心出来る本はなかったですしね。
原書でも、今みたいにアマゾンなんか勿論無くて、丸善で注文しても、入荷はいつなのか
分からない時代でしたから、日本コンピュータ協会本に頼らざるを得なかったのです。
翻訳本でも、故・後藤英一先生訳の「Lispの解剖」とかありました。
>そういや、昔の「インターフェース」誌の祐安重夫氏のコラムで、ここが出してた
>(Wirthの)A+D=Pの初版は仕方が無く買ったとか載ってたけど、何かあったんでしょうか？
A+D=Pの初版は、改訂版より遥に優れてました。訳者が片山先生でしたしね。
日本コンピュータ協会は、コンピュータ本の岩波でしたから、採算が取れなくなったからでは？
Re: (スコア:0)
原著の前半しか訳されていないまま鬼籍に入られました。
Re:日本コンピュータ協会(オフトピ) (スコア:2)
>原著の前半しか訳されていないまま鬼籍に入られました。
そうでしたね。後半がいつ出るのか分からないので、
原書のJOHN ALLEN "Anatomy of LISP" McGraw-Hill computer science series
を取り寄せました。索引も含めて500ページ足らずの薄い本なのに、何故中途半端な
ことをされたのか、私はその当時理解出来ませんでしたが、いい加減な歳になって想像
するに、多分、先生は飽きたからじゃないかと思っています:)
メインフレームというと (スコア:2)
暖気運転が必要なシステム、という記憶が。
週末のメンテ後に「暖まるのに30分かかるからそれまで待ってて」と言われてお茶してたのを思い出した。
Re: (スコア:0)
DISK本数に比例すると聞いていますので、DISKを個別・順次にチェックしているって事？
Re:メインフレームというと (スコア:2)
かれころ10年以上前の話で、システム以外はDiskにいれずに1/2インチテープとオープンリールを使っているような古いシステムのところだったけど、ウォームアップを待たずに急いでジョブを流すとかなりの高確率でエラーはくって話だったような。
8年前に欲しかった (スコア:2, 興味深い)
それまで触っていたOS(Windows,UNIX)とまるで違うので戸惑いばかりが先立ちました。
先輩に、ざっくり概要がわかるような本ってないですかねー、と言ったら
「んなもんない、っつーか知らなくても別に仕事はできる」と言われて衝撃でした。
まぁ実際そうだったんですけど、得体の知れないもんな感じが最後まで抜けませんでした。
その頃にこういう本があったらまだ親しみを覚える事ができたかもなー、と思いました。
しかし今考えるとストレスフルな環境でしたね。高負荷なのか、画面をスクロールするのに4秒くらい待たされたり、
コンパイルすると金がかかるから印刷してしっかり机上デバッグしてからコンパイルのジョブ流せ、と
言われたり。。。。
Re:8年前に欲しかった (スコア:1, すばらしい洞察)
Re:8年前に欲しかった (スコア:2)
無限ループなんて起こそうものならば･･････。
机上デバッグの大切さが身にしみる環境でしたわ。
印刷するのも結果は次の日にならないと届かないので、
ソースリストはコーディング用紙に当然手書き。
このときのコーディング用紙への書き方のクセで、未だに
「I」は小文字で書いたり、「O」と「0」を区別つけるために斜め線
入れたりとかしてるけど、他の分野の人でもこういう書き方するのかしらん？
メインフレーム本 (スコア:1)
メインフレーム本と言えば、ソフト、ミドル、ハードともメーカーが提供するマニュアル、資料が一番役に立つと思うけど。
Re:メインフレーム本 (スコア:1, すばらしい洞察)
その通りなんですがいかんせんこれらは詳しいことが売りなのでこの本のような俯瞰する視点の本は結構入門者には重要です
トップレベルのポインタっつーか
それにしても付属のMVSってなんだろ？
V3.8?
VMやLinuxはついてないの？
Re:メインフレーム本 (スコア:1, 参考になる)
目次によるとHerculesというのでMVS3.8を動かすみたいです。Cygwin上で動かすやり方が見つかりました。
http://www.genny.or.jp/kaz/hercules/mvs38j_top.html [genny.or.jp]
全体の俯瞰 (スコア:1)
なるほど了解です (スコア:1)
なる研修コースの網羅範囲が近いかも知れませんが、投資効果を考えると話題となっている書籍が良いのかも知れませんね。
Open系しか実際には知らない平成生まれだけど (スコア:0)
M/Fっていうのの存在価値がよくわかりません。
# 研修で実マシンそのものを見たこともあるし、Win上でコンソールエミュレータも触ったことあります。
# 本当に触って一部の（おそらく簡単で定例的な）処理を打ち込ませてもらったことがある程度ですが。
よくわかっていないので、M/Fの重要性は次のように認識しているけど間違いあるのかなぁ。
・整数型が扱いやすい（桁数で管理している。固定小数点１０進数型。会計処理でDouble型を使って浮動小数点のバグを混在させられる心配が無い）
・既存の完成された仕掛けを移行する巨大なリスク。いわゆる「レガシー」の言葉で批判的に言われること。
・管理するマシンが１台か、せいぜい３台くらいなのでサーバ増設しまくった場合におきる「常に１台は壊れている日」の確率が下がる。
->Googleみたいに大量にサーバを持っていると、常に毎日どれかのサーバは壊れているらしいですね。
・リースなので安い（のかどうかはよくわからない）。従量課金（買い切りもあるの？）。
・ハードウェア的な問題が起きたら、販売メーカーの顧客エンジニア（CE）に依頼して直してもらえる。
後半はいわゆる「クラウドコンピューティング」で何とかなりそうでもある・・・・。
物理的に遠隔地にDBを置きたくないという心情的・セキュリティ的な問題さえなんとかなれば、ですが。
Re:Open系しか実際には知らない平成生まれだけど (スコア:3, 興味深い)
Re:Open系しか実際には知らない平成生まれだけど (スコア: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: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:Open系しか実際には知らない平成生まれだけど (スコア:2)
> アベイラビリティ（可用性・故障しないで動く性質）の代わりに
> スケーラビリティ（拡張性・パワーを拡大させる性質）はあんまり無いかんじですかね。
「ブレードサーバーでLinux動かすぐらいなら、メインフレームでLinux動かしてください」という、IBMの営業さんの台詞から受けた印象からすると、逆ですね。
「数十台のLinuxサーバーを構築するのに、
他社だとブレードサーバーで何十枚もブレードを搭載するのでしょうが、
IBMならメインフレーム1台を何十個もの仮想空間に論理分割することで実現できます。
ちなみに、この程度の負荷、オープン系の製品にしてみると一苦労なレベルなのでしょうが、
わが社の製品でみれば標準構成程度で済みますので、屁でもありません。（意訳）」
# もっと上品におっしゃてました。
Re:Open系しか実際には知らない平成生まれだけど (スコア:2, 参考になる)
自分なりに整理してみました。
＞・整数型が扱いやすい
これは、COBOL系のシステムが多いということで、メインフレームの特徴とは、言えないのでは？
＞・既存の完成された仕掛けを移行する巨大なリスク。いわゆる「レガシー」の言葉で批判的に言われること
これは、メインフレーム内でも起きえる問題ですね。
Ex)IMSとそれに対応するGDDMが、上位互換で無い場合、起きえます。
このために、複数Revisionのランタイムの実行許可を許しているくらいですから。
＞・管理するマシンが１台か、・・・「常に１台は壊れている日」の確率が下がる。
これは、冗長性の問題でしょうね。
マシンは１台でも、CPUは、４つなんて運用が、結構されていますから。
ただ、
プリズムみたいなCPU分散ツールによるシステムダウンの回避
CCPやIOPみたいなサブプロセッサを含めた、I/Oアクセスチャネルの冗長化
で、リカバーしている部分もありますから
＞・リースなので・・・
これは、税法上の問題ではなかったかと記憶してます。
買いきりで減価償却５年とした場合とリースでは、リースのほうが、有利だったのでは・・・
（正しい解答できる識者の方、お願いします。）
＞・ハードウェア的な問題が起きたら、販売メーカーの顧客エンジニア（CE）に依頼して直してもらえる。
保守契約の問題ですね。
これは、メインフレームに限らず、保守契約次第で可能です。
むしろ、CEを駐在させ必要なパーツを最短で集めることができる体制をとらせられる
ということでしょうね。
これ以外にも、CEは、PMをかけてT&Dを実行し、部品劣化の恐れのあるパーツに関しては、予防保守で取り替えたりします。
これらは、安定稼動のためにとりうるあらゆる対策をとろうとすることができる・・・と換言できるのでは？
＞->Googleみたいに大量にサーバを持っていると、常に毎日どれかのサーバは壊れているらしいですね。
当然ですね。何台かのサーバの故障発生確率から、ハードウェアを物理的に準備することで、システムとしての稼働率を確保するという発想からきていますからね。
DBサーバは、多重化してデータを守り、WEBサーバが壊れても、再送でリカバーすればよいと考えれば、それでトレードオフが成立すると言うことでしょう。
とある製造業の会社では、システムがダウンすると、１秒１億の損失が発生するくらいのクリティカルミッションの真ん中を、メインフレームが支えていますから、そこにコストをさいて安定運用を求めるのは、当然のことだったりします。
で、答えになっていますか？
Re:Open系しか実際には知らない平成生まれだけど (スコア:2)
>とある製造業の会社では、システムがダウンすると、１秒１億の損失が発生するくらいの
>クリティカルミッションの真ん中を、メインフレームが支えていますから、そこにコスト
>をさいて安定運用を求めるのは、当然のことだったりします。
そうなんですよねぇ
通信系と製造業はミッションクリティカルです。
冗長系は当たり前で固いハードも必須なんですよね。
安物買いの銭失いになっては困るのです。
＃通信系に革命を起こした孫氏はある意味偉大かも(笑)
Re:Open系しか実際には知らない平成生まれだけど (スコア:3, 参考になる)
FACOM Mシリーズを数台使った計算センターにいましたが、終電が出でしまった後に泊まりなもので
暇にあかせて設置説明書を読んだことがあります。
それが実に細かい。建物の基本構造から床や壁の材質、空調機の能力や冗長化、自家発電を含む
電力管理や地震、火災、浸水時の対応まで、起こりうる障害に対して、とことん事細かに指示が
あるわけです。
つまりメインフレームの信頼性というのはマシン室内だけじゃなく、周辺環境まで含めた
ハードの耐障害性と、障害発生時の対応手順とノウハウ、そのドキュメント化という、
ソフトの耐障害性をあわせたものなんだなと納得しました。
そりゃ高価くなりますよね。
〜◍
Re:Open系しか実際には知らない平成生まれだけど (スコア:1)
>FACOM Mシリーズを数台使った計算センターにいましたが、終電が出でしまった後に泊まりなもので
>暇にあかせて設置説明書を読んだことがあります。
FACOM Mは大学時代計算機センターで使ってました。1回目にマシン室の見学があり驚きました。
子守のメーカー要員が常駐しているのだから‥
入社後中型汎用機のマシン室(冷蔵庫)に何度も入っていたので‥
Re:Open系しか実際には知らない平成生まれだけど (スコア:1)
>自家発電を含む電力管理や地震、火災、浸水時の対応まで、起こりうる障害に対して、
>とことん事細かに指示があるわけです。
「マウス(ねずみ)の害について」の説明はありませんでしたか。
Re:Open系しか実際には知らない平成生まれだけど (スコア:1)
よくは覚えてないんですが、鼠や虫の対策もありましたよ。
通気口に金網とか。鼠はケーブル類ですね。
当時は鼠避けケーブルは無かったんじゃないかな。
〜◍
存在価値。それは信頼性。 (スコア:1, 参考になる)
パソコンでも信頼性を確保しようとなるとサーバ系なら電源を二重にしたり
フォールトトレラントな仕組みを色々入れたり、と、やることがやたら増える。
それが当たり前に、基本にあるのがメインフレーム。
ただ、安くはならないから、信頼性を削ってでも安くという市場の要求が
現在のパソコン系の利用を増やしている。それとパソコンの処理能力が増えて
適用範囲を広げたからというのも大きい。
大型トラック(汎用機)でないと無理という場面はあるけど、
中小型トラック(パソコン・WS系)の使える場面は多くなったというのが現在。
Re: (スコア:0)
大型トラックは中小型トラックに比べて信頼性がものすごく高いわけではないので
たとえとしてはいまいちだと思う
Re: (スコア:0)
でもワークロード(負荷)単位で見たら大型トラックの信頼性は高くなるんだよね。
メインフレーム相手の負荷だと中・小ではオーバーロード気味とか負荷に耐えられないとか状況も発生するので。
そちら方面の視点で見たのでそういう例えになりました。
ただ、距離単位でみるとそういう視点にはならないのが難な例えではあったね。
Re: (スコア:0)
戦車→汎用機
タリバンも愛用してますっ！ TOYOTAのピックアップ→パソコン・WS系
Re: (スコア:0)
例えば今はコンシューマ相手の商売ではオンラインのサービスが停止しない信頼性が必要，
ただし平均的な稼働率維持が重要で，短時間のシステムダウンでちょっとぐらいオンラインでの発注をロストしたって大丈夫って感じですから.........（受け取ったデータはロスト出来ないが，短時間データを受け取れない状態になっても無問題． 受け取っていないデータは相手のものだからこっちにデータ紛失の責任があるわけじゃ無いよ）
何事にも絶対的な信頼性が要求された時代とは感覚がちょっと違う
Re:Open系しか実際には知らない平成生まれだけど (スコア:1)
Re: (スコア:0)
まあ、特徴はあるんだけど
新しもの好きのエンジニアには向かないんですよね・・・・
# みんな古いのが嫌いなんじゃなくて新しいのが好きなだけなんですよ・・・
Re:Open系しか実際には知らない平成生まれだけど (スコア:1, すばらしい洞察)
Re:Open系しか実際には知らない平成生まれだけど (スコア:2, 参考になる)
このVM/SPや現在のZ/VMの原型のCP-xx/CMSは1967年、約40年前に実用化されています。
数十年前というと、5,60年位前なので電子計算機の黎明期にあたります。
IBMが仮想記憶をサポートしたDOS/VS、OS/VS1、OS/VS2が実用化されたのは1970年とCP/CMSよりも後になっています。
ちなみに、IBMメインフレーム上で動作するZ/LinuxはVM上のゲストOSとして実装されています。
http://premium.nikkeibp.co.jp/linux/case/case08/4.shtml [nikkeibp.co.jp]