メインフレームってこの先どうなの？

メインフレームってこの先どうなの？

まったくなくなるって事はありえないな〜。
ある程度は残るわな。

ちなみにいまだに基幹系がメインフレームな企業って結構おおいのよね。

>>2に同意。
信頼性が違いすぎるしな。

情報系もメインフレームというところが、多々アリ
別に悪かないけど

複雑なわりに・・・、でも、捨てられないしなあ。
クラッシック・カメラみたいなもんだね。

人材育成が大変だわな。
いまさらJCLを若い人に勉強させるのもなぁ。
でも信頼性ではまだUnixは追いつけないみたいだ。
あと昔のアプリを再構築する余裕がないというのもある。

金がないからそのままという会社も結構あるらしいよ。
でもメインフレームの方が維持費が高いはずなんだよね〜。

>>7
処理能力が飛躍的に向上してるから、別にそんなことないんじゃない？
IBMとか、WebServerぶち込めるやつあるし･･･
うちは、2CPUから1にしました。早いんだもん

７でいう「メインフレーム」というのは昔のままのマシン/SYSTEMって意味ね。
電気代も食うし空調代も高いしオペレータも必須の頃のやつね。

システム更新する金がないんで10年前のバブル期の奴をいまだにつかってんのよ。

システム更新する労力がないので10年前のいまだに使っております。

信頼性が全く違から、基幹系の重要なところは当分替えられないでしょう。
メモリ１２８で億の値段だからね〜。
それに、予防保守、定期保守、パフォーマンス監視と、関わる人間も多いしね。
金食い虫ではあるが、それなりの存在では在ると。
でも、コスト面からアウトソースされて自社所有は減ってくんじゃないかな。
無くなりはしないが、メインフレームをいじる人は減っていくでしょう。

なくなるかどうかって以前に
消えて欲しいんですけど。
あんなバカなOSの面倒見てると頭が腐る。

セキュリティや運用やらの手法と手順が確立してるって意味で他の
カテゴリの機械に比べて扱いやすいって面で残してる様な所もあるみたい。
やはり金を食うけどその金に見合う信頼性を他のカテゴリが持ち合わせる
までは残るでしょう。

残りそうなのはどんな分野ですか？
また､新規市場の存在する可能性についてはどうですか？

まず、メインフレーム経験は無いので、的外れなことを書いていたら
無視してくださるようお願いします。

日経BPのIT PRO のMETA Group 特約記事を鵜呑みにするのも何なんですけど
その記事
＃見るにはユーザ登録(無料)が必要

http://itpro.nikkeibp.co.jp/members/ITPro/ANALYST/20001218/1/

にはあくまでSAP R/3 の稼動プラットフォーム選定というテーマですが
その中にかかれていることを抜粋すると

1.メインフレームのスキルが社内になければ
　メインフレームを選択してはならない
2.3000ユーザー級以上ならメインフレームがコストで優位
　今後５年間はUNIXに負けない

ということらしいです。ただし、やっぱり若い技術者に
メインフレームの技術を習得させるモチベーションをどう
与えていくかという問題はあるわけで、以下の記事に
あるように

http://itpro.nikkeibp.co.jp/members/ITPro/ANALYST/20001225/1/

外部資源(パッケージ・アウトソース)の活用やメインフレーム技術者
へのインセンティブや後継技術者の育成策支援が必要であるという
結論になるのでしょう。

まぁ、メインフレームでの新規開発は極力避けて外部システム(UNIX?)
でやるようにして、全システムにおけるメインフレームの割合を下げて
行くようにして最後には｢メインフレームの緩やかな死」を迎えられる
ような中長期計画を描いておくのが妥当なんでしょうか？

日本ではほとんどすべての銀行で
勘定系にはメインフレーム使っています。
たぶんこれからも使い続けるでしょう。

メインフレーム：業務用途
ＵＮＩＸ：技術者のお遊び(研究用途？)

という事なんで管理面(システム管理、障害管理等)では
まだまだメインフレームの方がこなれてるのよね。

大手企業が安定したシステムをメインフレームに頼る限り、無くならないでしょう。
連続して負荷が掛かる状況ではUNIXでさえもトラブルを起こしちゃうから。
汎用機はそこら辺だけ集中して金掛けてあるから一応は安心。
でもメインフレーム専任のＳＥ、ＰＧ開発者は間違いなく減るだろうね。
きっとメインフレーム、UNIXとも出来るエンジニアはこれから重宝されると思う。

っつーかこれからメインフレームがUNIX に近づいていくんじゃないかな。
中身はそのままで。

OS/390 がUNIX95 認定受けているし
http://www.opengroup.org/regproducts/xu007.htm

>19さんの言う通りかなー。
メインフレームにUNIX入れる需要は多いですから。
ま、UNIXもどきのPPを入れるっちゅう事ですけど。

欧米では、
あるレベル以上のホストは一定の需要があるそうだ。

>>19
旧来のＯＳとＵＮＩＸの両方を勉強しないといけないから、大変だね。
ゴクロウサン。

最近のIBMなんかは新入社員さんは１年間みっちり汎用のOS(OS/390かな)
をたたき込まれて、汎用の実務を３年ぐらいやった後でAIX(unix)を
やらされるってなケースが多いらしいですよ。

昔は専門特化でもよかったみたいですが最近はなんでも出来るスーパー
マンでないと要らないらしい。

数万人の社員の給与計算・明細印刷なんかはメインフレームでしょう・・
すでに安定稼動していて、アプリケーション変更をともなうＵＮＩＸ等
への移行は、リスクとしてできないシステムなんか使いつづけるしかないです
（例．列車の運行管理システム（バグで満員の旅客列車が衝突したらシャレ
にならん）

某大手都銀の某勘定システムもJAVAによる開発を検討したものの
結局はCOBOLに落ち着いたしね。あと8年は残るかな〜。

COBOLも始めはそうだった．．．．．．

>>23
それ本当？
俺は例外ですか？

川崎と幕張に居る５〜６人ぐらいの３年目ぐらいの人に
聞いた話なのでサンプルが少ないと言われればそうかも
しれませんが…。

いまのクライアントサーバー流行ってなんなんでしょうね？

メインフレームで動いてるからいかんと基幹業務システムを
ＳＡＰに移行。アプリケーションサーバーもデータベースサーバーも
結局一極集中。画面はキャラクターベース。
「そうかあ、クライアントサーバーってハードをすりかえればいいんだあ」

もう一丁。
メインフレームとサーバーのハード的な信頼性の議論はこの板の
どこかで読んだ記憶があるがＴＣＰ／ＩＰとＳＮＡの信頼性の違い
をなぜ言及しないのだろう？

SNAが信頼性高いって話は見方によっては意見が変わってくるから難しいな。
というかSNAはEthernetに流すとトラフィック増えて黒いんで嫌われるって傾向はあるかな。

>>29,30
もっと勉強したほうが良いね。

そうかなぁ？
この間、三菱電機製作所のＸＸ工場内でＭＲＰ展開による自動発注データ生成部の心臓部分を
Unixサーバーに載せかえたよ。
載せ変えに使った言語はＣね。
関連仕様書(既成)はキングファイル５冊
ＯＳ／３９０で動いていた時のプログラム数は約20本で一回の処理時間が15分程でした。
それを、Ｃ言語で1500ステップ程度のプログラム１本に載せ変えました。
処理速度は約１分となって重宝してます。

やはり、組み合わせが大切だと思いますよ。

>>33
何を否定しているのか不明？？？

>>34
指摘ありがとう。
>>24番さんの考え方を否定してます。

ついでに、
>>29
クラサバと分散処理は別次元のお話だよ。
因みに、分散処理は多大な開発コストが必要です。

3日以上かかるような開発は極力しないほうがよい。
無形固定資産として計上し減価償却しなければならない。
ハードが老朽化してもソフトが使えるなら、
そのまま使い続けるのが面倒でなくてよい。
税制改正がメインフレームの延命に寄与しそうだ。

>>33
自動発注データまちがっても、直接人は死なないでしょ。
超大量のデータ印刷したりフロア全体をテープライブラリにして
やんなきゃいけない超大規模とかは汎用機でしょ。

みなさんおっしゃる様に処理のスケールだデカい業務って案外多いし。
浸食はされるけど、無くなりはしないってのが順当な見方じゃないかしら。

むしろ汎用機が要らないような（もしくはボリューム減でスケール的に
要らなくなった）処理のスケールのシステムが未だに残ってるってのは
新規に金掛けられないか、システムのデザインをする人間がタコかの
どっちかなワケで。

あなたも人を殺すことができる！！

出版業界前代未聞！史上最大の衝撃作！
「人を呪い殺す方法」ついに発売へ！

日本古来より実際に行われてきた、人を呪い
殺すための様々な秘術を紹介、その実践方法
をわかりやすく解説した「殺人術の本」です！！
今までにこんなに詳しく調べ上げた本はありません！
どこの出版社もこんな本を出すことなど不可能だった！

「キライなあいつを誰にもばれずに殺したい！」
「呪いというものが本当にあるのか？呪いたい！」

そんなあなたの心を満たすための本です。
呪いならば証拠もなく相手を殺すことが出来ます！
殺せるかどうかはあなたの信念次第！！
読んで見ればわかるでしょう…呪いというものが
過去の歴史で「実在」したということが…。
各マスコミも取り上げています！！

(注・殺人を推奨する本ではありません。あくまで「呪い」に関する研究書です)

http://www5a.biglobe.ne.jp/~kongen/

>>37
>超大量のデータ印刷したりフロア全体をテープライブラリにして
>やんなきゃいけない超大規模とかは汎用機でしょ。
超古くない？

>>40
超古いけど代えようがないからこのまま・・

汎用機と同等の稼働率をUNIX及びその周辺機器で確保しようと思ったら大変だぞ。
そこら中2重化・3重化しなきゃならんし。
人件費を含めた保守費用も莫大だ。

>>42
そりゃ１０年以上前のハナシだね。

>>43
そうそう、汎用機側が下がってきただけだが(藁

>>42

HPのおえらいさんが「汎用機なみの年間稼働率９９．９９％（９９．９９９％だったかも？）を目指す」とかいってたのは
数年前なんだけど・・

メインフレームにWebインタフェース、UNIX認定、最近じゃXMLインタフェースってか？
それって体よく囲い込まれてるだけじゃん
IBMに囲い込まれんならともかく、国産に囲い込まれるのはやめようね
付け焼刃

このスレッドの趣旨から言うと、「メインフレームはCPUパワーでは増えます/台数でも増えるかも/金額は少し減るかな」
ってところでしょう。ただしこの10年程度でね。
そのあとは分らん｡

なんでＯＳＩやＳＮＡでなくＴＣＰ/ＩＰになってしまったかも分らないから、10年後以降なんて皆目。
とにかく、計算機ニーズは深く広くなっているので、10年前のようにネオダマと言っていればよいわけではないな。
汎用機にも出番はたくさんあるし。
でも、ユビキタス化でＡＳＩＣが一番増えそうだけど・････、問題はＯＳか。
まあ、研究者でない我々は、これからはやりそうなものを急いで勉強するしかありませんね｡

>>47
>なんでＯＳＩやＳＮＡでなくＴＣＰ/ＩＰになってしまったかも分らない・・・
なんで分からないのか分からない。

　　　　　　　　■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■死■■
　　　　　　　　■■健一■■■■健一健一■■■■■■■健一■■■健一健一健■死■死■
　　　　　　　　■■健一■■■■健一健一■■■■■■■健一■■■健一健一健■■死■■
　　　　　　　　■■健一■■■■■■■■■■■健一■■健一■■■■■■健一■■■■■
　　　　　　　　■■健一健一■健一健一健一■■健一■■健一■■■■■■健一■■■■■
　　　　　　　　■■健一健一■健一健一健一■■■■■■健一■■■■■■健一■■■■■
　　　　　　　　■■健一■■■■■■■健一■■■■■■健一■■■■■■健一■■■■■
　　　　　　　　■■健一■■■■■■■健一■■■■■■健一■■■■■■健一■■■■■
　　　　　　　　■■健一■■■■■■■健一■■健一健一健一■■■■■■健一■■■■■
　　　　　　　　■■健一■■■■■■■健一■■健一健一健一■■■■■■健一■■■■■
　　　　　　　　■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

みんな何にも知らないんだな。
銀行・証券の基幹系システムに汎用機がなぜいまだに使われているのか
知っているのか？

＞４５
UNIXで「９９．９９９％」の稼働率の実現ははかなり厳しいな。
汎用機だと実際それ以上確保できるが、UNIXはカタログスペック上
(あてにならんが)でも無理だろ。
あ、Winは論外ね。

激しく同意。

地銀とかでは少しずつUNIXやNTに移行してるよ

>>51
カタログスペック見たって分かることじゃないよ。
稼働率の計算方法知らないようだね。こういう人は論外ね。

Winのでーたせんたぁが、稼働率９９．９％めざすとかいってたなぁ
ＰＣサーバのＨＷもたしかそんなもん・・

NTServerのMTBFは1日くらい？困ったもんだ。
クラスタリングしてスイッチする？

>>50
うん知ってるよ！
それは、技術者が不足してるからだよ。
基本的に、COBOL系しか知らない技術者が多すぎるんですよ。

>>54
スペックなど当てにならんよ。
稼動実績も殆ど意味無いしね。

＞５４
稼働率の計算方法？
まさか情報処理２種レベルの話か？
そういうのを机上の空論って言うんだよ。
実際に厳しい稼働率を求められるシステムやったことないだろ。

＞５７
全然分かってないじゃん。
COBOL系の技術者が多いということが全てではない。
単なる理由の一つ。
それだけ安く開発・保守の人間が安く調達できる＝総コストが安くなる。
ま、ビジネスの世界では常識だな。

アホ。UNIXでもできるよ。

なぜ汎用機が使用されるのか？実績がその主因だよ。

まとめですが、稼働率９９．９％程度ならＵＮＩＸでも十分可能。
汎用機が今なお使用される原因は「実績」。
経済コストの絡みからＵＮＩＸ系に移行しかけた時期もあったが、
結局のところ保守要員等人間がらみも含めてシステムとしての
稼動実績がメインフレームに劣る、という事。
そもそもメインフレームの高い安定性って
システムとしての「人間（保守要員）」がかなり介在してるんだが。
どうにかして安定性を高めようと四苦八苦してきた歴史の前には
ＵＮＩＸなんか適いません。ＰＣなんて論外。

>>61
まとめではなく、一個人の意見として聞いとくよ。

>>58
全然反論になってませんよ。
逆に肯定してるように思えるけどね。

>>61
だから、技術者不足が原因だって言ってるのです。

会話が成立してないな

＞５７
お前バ○だな。
情けなくて涙が出るよ。

10年後にも所謂”汎用機”は残ってるよ。
基幹システムとして立派にね。
ただし名前だけは”サーバ”になってるかもしれんが、IBMのようにね。

６１の意見は妥当だな。
信頼性が最も要求される業種の一つである大手金融機関では、
基幹部分のシステムは当然汎用機だ。
「どうにかして安定性を高めようと四苦八苦してきた歴史の
前にはＵＮＩＸなんか適いません」
という６１の意見は、経験者にしか分らない”現実”が現れている。

>>67
「今さらＵＮＩＸなんか勉強したくない。」という”現実”が
表れているね。

大手金融機関の基幹システムに限らず、システムの安定稼働には厳格な運用ポリ
シーの策定が大前提となる。現在のUNIXやPCには、現在でもシステムとして永続
的に適用できる決定的な解消方法がみつかっていない問題点がいくつもある。

セキュリティの問題・・・パスワード管理負荷の増大、ユーザID管理負荷の増大、
アクセスログチェックの未実施をいかに防ぐかなど

運用の問題・・・本番と開発が同居してること、設置スペースが逼迫すること、
機種によって運用方法が異なること、システムごとにバックアップ採取する必要
があること、システム毎にレベルアップしてしまうことなど

開発の問題・・・パッケージの限界、個々に一から開発することが多く品質にバ
ラつきがでやすいなど

これらはすべて汎用機では当然問題にならないこと。あとは、CPUを何十個も積
んでそのうち数個は「予備」として使われないままになってるなど、汎用機のコ
スト度外視のつくりはUNIX機しかみたことのない技術者には驚きだろう。

>>69
これって、マルチベンダー・システムの問題点じゃん。
なんか、誤解してるね。

unixでマルチベンダしないですむ会社があるのか。>>70

>>71
あるよ。

しかしホントに何も知らないんだな＞６８
オレが例に挙げた「大手金融機関」でも厳しい信頼性が求められない
部分ではUNIX、PCサーバが進出してきている。
開発しているところも、そこらへんのソフトハウスよりよっぽど技術力
がある。
つまり、汎用機、UNIX、PCサーバのことを熟知した上で、基幹系には
汎用機を使っているんだよ。
ここのスレで「汎用機はいらない、時代遅れだ」みたいなことを言ってる
ヤツは、本で読んだか、学校で勉強したかレベルの知識しかないようだな。

実際に構築してみれば全て分かるよ。

＞７２
それは小規模システム、つまり「汎用機の代替」という領域ではない
部分に限定される。
汎用機でやっている大規模かつクリティカルなシステムをUNIXで実現
しようとするならばマルチベンダにならざるを得ない。
当然、ディスク、テープ、プリンタ、ネットワーク制御等の周辺装置
を含めた話だぞ。

>>73
68の文章は真実だよ。訂正するつもりなんてないよ。

>>74
>汎用機でやっている大規模かつクリティカルなシステムをUNIXで実現
>しようとするならばマルチベンダにならざるを得ない。
決め付けるな。
>当然、ディスク、テープ、プリンタ、ネットワーク制御等の周辺装置
>を含めた話だぞ。
69でそこまで言及してるか？
金融機関でも、そこまで含めたらマルチベンダーだよ。
Ｉ○Ｍの提案書そのままだね。

シングルベンダーでできなくもないかもしれないけど・・
メーカ純正と称しててもどっかからのＯＥＭで・・障害があったとき
原因究明を依頼しても開発部門が「わかりません！」とかるくいって
くるんだよね。
まあ、メーカの保守部隊が修理できるので修理時間を短縮できるけどね。

＞７６
お前経験ないんだな。
知らないなら知らないって言えよ。

>>75 >>76
私は、汎用機もUNIXもPCも扱っていて、それぞれの利点はまあ理解して
いるつもりで、その理解から>>73 >>74に賛同する。
厳しい信頼性が求められる部分は、現在でも汎用機以外考えにくい。

ちなみに私があげた項目は、某大手都銀の内部資料に手を加えた
ものだ。それぞれについて現在での解決方法と将来的なレベルアップ方針、
運用に伴うコストと将来的なコスト増加要因の分析を、幹部稟議がとおる
次元で説明してほしいものだ。

もちろん、現在は汎用機で動いてるわけだから、両者での耐障害性比較、
UNIX化にかかる総コストについても経営陣がメリットを見いだせる必要がある。

私は厳しい信頼性が求められる部分にはこれからもS/390などを買って、
いままでどおり運用するのがよいと思う。お金が命の次に大切ってひとが
世の中には多く、そのひとたちのためのシステムでもあるのだよ。

７７の言うとおり「できなくもない」が、それが汎用機と比較して
まともなシステムになる可能性は低い。

タンデムやNUMAみたいなアプローチもあるじゃないか

ちょっと聞いてもいい？
知ってる銀行系のプログラマが、汎用機でアセンブラによる高速化一筋やってん
だけど、なぜにアセンブラ？
Ｃとか使わないすか？
アセンブラなんかで組んで安定性とか稼働率とか問題にならないの？

>>82
＞Ｃとか使わないすか？
基本的にCよりアセンブラの方が処理速度は上だよ。

＞アセンブラなんかで組んで安定性とか稼働率とか問題にならないの？
言語の違いが安定性と稼働率に影響を及ぼすことはないよ。

>82
今までの実績
すでに作ってしまった資産があるからね。
実務をやっていると痛いほど分かるけど。

>>83
いまどきの RISC だと内部の実行過程が複雑になりすぎて、コンパイラのコードに
ハンドアセンブルの効果が追いつかなくなっているという話を聞くけど、
メインフレームはどうなの？

いちいち投機的実行時の成功可能性とか計算してやってるの？
それとも割と単純なつくりになっているの？

そもそもCISCなんじゃない？

>>79
なんじゃコイツ偉そうに。扱ってると言っても売ってるだけだろ？
ＵＮＩＸやＰＣなんか知らないこと文章読めば分かるよ。
69のような問題のあるシステムなら、オフコンでパッケージ・ソフトでも
入れてカスタマイズすりゃいいんだよ。
ＵＮＩＸやＰＣとは関係無いハナシだね、ば〜か。

>>79
69は、
AS/400とSAPあたりを売りつける為の提案書みたいだね。

ひどい言われようだ…。

>>87
おそらくあなたが想定している小規模の案件ではUNIXやPCでの
パッケージ利用、AS/400などで乗り切ることはできる。しかし、想定の
対象は、大手都銀の基幹システムであり、数千人月、数百人が携わる
大規模プロジェクトなのだよ？

このような大規模プロジェクトに携わった経験があり、それでもオフコンに
パッケージいれてカスタマイズすればいいと思ってるのだろうか。

＞ＵＮＩＸやＰＣなんか知らないこと文章読めば分かるよ。

某超大手食品や、某超大手海運の金融サイト構築をiDC導入を含め
携わっている。NTのクラスタはもちろん、SANの構築なんてのもやって
るな。SUN Enterprise２台で、Firewall-1を使ってVPNを構築したいなら
なんでもきいてほしいくらいだ。CAのARCserveやHPのOpenViewの、
統合運用への壁が宣伝文句とはかけ離れて高いことも身をもって知って
いる。

つぅか、開発はずっとAIX+DB2とかNT+Oracleでやってるさ。

つまりあなたの「分かる」はあてにならないってことだよ。

パッケージというのは、適用できるユーザがそれなりにいないと作る意味が無い。
汎用機を適用できる分野なんてユーザ数はたかが知れている。

>>79
はーい、おれもどうしても >>69 の書いてある内容に納得できない人。

汎用機ではユーザIDとパスワード管理してないの？
汎用機だとなぜ設置スペースを逼迫しないの？
汎用機はどのメーカでも同じ運用？そんなことないよね？
UNIXだと本番と開発が同じ？なんで？
開発・テスト・本番・バックアップ・分散で４〜５台あったなあ。
このコスト度外視の数は汎用機ユーザーには驚きだろう、と言ってみたり。
それぞれスペックは違うし徐々に減らしたみたいだけど。

真面目な疑問。あおりじゃないよ。

＞９１
あなたは汎用機のクリティカルなシステムの経験ある？
ないんだったら多分分からないんだろうな。

＞汎用機ではユーザIDとパスワード管理してないの？
これは、どの発言に対する質問かは分からないが、当然必要だよ。
ただし、UNIXでシステムを組んだ場合、マルチベンダ、複数サーバになるのが普通だから
利便性を考えると1回で必要な全てのサーバにアクセスできるような仕組みが必要だな。

＞汎用機だとなぜ設置スペースを逼迫しないの？
これについては、かつての汎用機ならばかなりのスペースを必要としていたのは事実だ。
しかし現在では汎用機と言えどもその大きさは以前とは比べられないほど小さくなり、
同じ稼働率を確保するような構成にすると、UNIXよりもスペースを必要としないことが多い。

＞汎用機はどのメーカでも同じ運用？そんなことないよね？
これは、汎用機であればほとんど単一ベンダで済むということを考慮しなければならない。
つまりベンダ側で運用しやすいようなツールを用意していると言う事だ。
UNIXであれば、運用ツールを使って合理化を図ったとしても、マルチベンダであるがゆえに
汎用機並に使いやすくはならない。

皆さんの会話を聞いてるとコストと人材のこと考えてないように感じました。
まず、品質や性能及びセキュリティ等はコストをかければ大差ありません。
次に、信頼の置けるパッケージはUnixの方が少ないのは当然です。
次に、人材の多さから汎用機が勝っているのは事実です。
兎に角、人を大量に集めて開発するやり方はUnix機には向いておりません。

唯、残念なのは銀行系の過去の開発で技術者の数は増えたけど．．．
技術力の平均値はかなり下がってしまいましたね。
まあ、資本にものをいわせるやり方が何時もでも通用しないのはＩＢＭをみれば
明かでしょうね。

>>91

＞汎用機ではユーザIDとパスワード管理してないの？
管理しているが従来から一元管理できる仕組みがあり、その運用にも実績がある。
対してLDAP等の管理方法にどれだけの「実績」を見いだせるかが問題。また、ネ
ットワーク上をパスワードが流れる際の暗号化やハッシュ化をすべてのシステム
に徹底できるか疑問が残るし、監査証跡を取得する仕組みを各アプリケーション
で構築し、随時内容の正当性を確認する必要がある。負荷高いでしょ。

＞汎用機だとなぜ設置スペースを逼迫しないの？
汎用機の導入は設置床の設計も含めて計画的で「いつのまにか増える」ことはな
い。対してPCサーバ等は19インチラックの42Uすべてを埋めてしまうことは将来
の拡張を鑑みほとんどありえず、汎用機より効率は悪い。ラックマウント型の1U
液晶ディスプレイの装着率などもごくわずかではないか？　また、統合監視に実
績がない、またはアプリが対応できないため、無人エリアだけの設置が望ましい
のに有人エリアに専用の監視コンソールを設置せざるをえない場合も多い。

＞汎用機はどのメーカでも同じ運用？そんなことないよね？
>>92と同じ考え。保守以外でも、たとえばプリンタ出力ひとつを考えても、機種
毎に給紙やジャムったときの対応とかは違うわけだから、オペレータに新機種が
入るたびに教育を施すコストがバカにならないし運用負荷が増大するだけ。

＞UNIXだと本番と開発が同じ？なんで？
＞開発・テスト・本番・バックアップ・分散で４〜５台あったなあ。
汎用機で開発から運用までを経験したことありますか？　ライブラリ修正作業で
「開発と本番が分離」してると認められる要件は説明しにくいのだが、カタログ
管理等の徹底にも違いを見いだせると思う。指摘は残念だが的はずれ。

>>93
＞唯、残念なのは銀行系の過去の開発で技術者の数は増えたけど．．．
＞技術力の平均値はかなり下がってしまいましたね。

どっかで書き込みましたが10年前の２分の１から３分の１らしいですね。
私はまだこの業界５年程度なので、ひとの技術力を云々できませんが。

91ね。
>>92 >>94 詳細なご回答ありがとう。
汎用機の開発経験はないのでよい勉強になったよ。
まだ納得できんところもあるけどね。
おれがプログラマだからか？

＞汎用機並に使いやすくはならない
逆に、圧倒的に使いやすくなるかもよ？
だってそれはソフトの能力だから。
いくらだって革新があるさって思えるけど。

＞新機種が 入るたびに教育を施すコストが
うーん、つまり新機種を入れなければ教育コストかからないってことでしょ。
それは、どんなコンピュータ使おうが当然だよね？
「一蓮托生および過去の実績の意義」と「汎用機であることの意義」は
論理的に切り離してくれないものか？
「一蓮托生」も「過去の実績」もどんなコンピュータにだって存在しうると
思うが。なんか間違ってる？

ま、納得いかないのはお互い様だろうってことでこれぐらいで
やめとくよ。汎用機の経験無いしね。
どうもありがとね。

>>92,>>94 見て感じたこと
・ユーザー一元管理、ネットワークセキュリティ、監査証跡等は、アプリケーションの
　設計の問題で、汎用機を使っても問題のある設計は可能なのではないか？
　汎用機（および専用 OS）を使うことによって、その部分の設計および実装・運用が
　Unix ないし PC に比べて容易かつ確実に実現できるということなのか？

・設置等が計画的なのは、導入する側が計画的に導入しているからであって、
　　汎用機 = どうやっても計画的にならざるを得ない
　　Unix/PC = どうやっても計画的にできない
　ということにはならないのではないか？

・ツールを用いた管理運用についてはそのとおりだと思う。本番と開発体制の
　分離についても、上と同じようなことが言えないか。つまり汎用機かそうでないか
　の違いが品質を決めるのではなく、それに携わる人の質の違いが品質を決めるという
　こと。

最終的には、携わる人が、計画的に、隅々まで目を配って、信頼性とセキュリティを
高めるために、たゆまぬ努力をしているからこその汎用機の信頼性であって、もし
同じメンバーで UNIX/PC 上のシステムを開発したら、汎用機レベルのセキュリティと
信頼性を実現できるのではないかという疑問が残る。

その辺、どうお考えなのでしょうか。

>最終的には、携わる人が、計画的に、隅々まで目を配って、信頼性とセキュリティを
高めるために、たゆまぬ努力をしているからこその汎用機の信頼性であって、もし
同じメンバーで UNIX/PC 上のシステムを開発したら、汎用機レベルのセキュリティと
信頼性を実現できるのではないかという疑問が残る。

実は、ユーザやＳＥ部隊が同じだけお金をかけても無理なんですよ。
なぜ無理かというとメーカ側の体制がそーなってないから・・
１．ＯＳやメーカＰＰの保守体制
　　汎用機のＯＳやメーカＰＰの開発部隊は、重大障害が発生すると深夜だろうと
　でてきて原因究明・修正にあたる。しかし、ＵＮＩＸの開発部隊はそこまでやらない。
　通常のペース。

２．ＨＷの保守体制
　　ＵＮＩＸサーバ機の場合、Ｉ／Ｏコントローラなど主要部分は、他社の汎用品が
　つかわれることがおおい。他社製のため内部はブラックボックスとなり、障害発生時
　の原因究明がおくれる。

>>98
一見すると正しい見方なんだけど...
良く考えると矛盾するよ。
保守体制等は全てコストに跳ね返るからね。
ハードを売ってるように見えるのは虚像ですよ。
実際には人を売ってることになります。

それにマルチベンダー問題をネガティブに捕らえてる人が多いけど
実は殆ど関係ないです。
マルチベンダーであっても多大なコストをかければ問題なしですよ。
逆に、マルチベンダーであるが故に隠匿し辛くなるから良い面の方が多いです。

但し、全てはコストをかけた時と人材育成が為された場合のお話です。
現状だと、大きなコストをかける場合系列がものを言うし、
人材育成より簡便な手法を取るのが企業ですらかね。
その意味で企業エゴが多少介入するのは仕方ないですね。

＞９７
UNIXでもやってやれないことは無いと思う。
しかしまだUNIXに置換するのは現実的でない分野もある、と思う。
経済コスト（人件費）を度外視すれば私はUNIXでも可能との立場。
また、永続的なサポートをひとまず置いておくとして、
構築と２〜３年の保守サービスくらいを想定すれば、
例え金融機関のコア部であったとしてもUNIXでの置き換えは可能。
やはり人の問題と過去の実績が大きいよ。
安定性を高めようという課題の前で博打はできんでしょ。

追加：
ま、経済性を度外視すれば・・て時点であんまり意味のない話に
なっちゃうけどね。でもいろいろな経験を書き込んでくれた方々には
感謝です。

>>99
現状「メーカの保守体制がそうなっていない」ということです。
同様の保守体制をもつには、新たに作る必要があるのです。
金出して解決しようとすると、保守体制維持だけでなく保守体制
構築の費用もかかります。おそらく一社負担するのは現実には
不可能でしょう。また、汎用機と同様の保守体制をメーカが構築し
ＵＮＩＸシステムのコストに反映させたとすると、競争力のない価格
になるでしょう。

>>102
それは余りにも保守的な見方だと思いますよ。
現在のメインフレーム市場が発展しておればその見方で正しいのだけど
現実としては頭打ち状況であり、その原因が優秀な技術者不足であることは否めないです。
そして、優秀な技術者が育たない環境を作り出しているのがメインフレーム市場
であり、保守体制を含めたコストパフォーマンスに陰りが出てきているのは現実です。
この業界構造を根本から見直すには痛みが伴うのは必定だと思いますよ。
日本で出来なくても必ず外国の何処かで構造変化は起きるし、そのうち嫌でも構造改革する
時期が来ると思います。

何か「汎用機ラブラブ♪」って人はUNIXは寄せ集め部品で作られてマトモな保守体制も無いって言いたいみたいだけど本当？
IBMのRS6000なんかは全部IBM製だし保守もちゃんと保守料払えばS/390と同じように24時間365日保守してくれるよ。
もちろんPCレベルでもxSeriesなんかは同じ。
まぁUPSなんかはAPC製だったりするけどね

そういう所を無視して端っから「Unixダメダメ」って言ってたんじゃあ誰も説得できないよ。
まぁ、言いたい事言ってるだけで説得する気なんて更々無いってんだったらそれでもいいけど（ﾜﾗ

１０３の言ってる事は正しいな。
しかし、今もしくは近い未来という範囲内では、ユーザがクリティカルな
システムを構築するには汎用機を使うしかないんだよ。
メーカが全てのマンパワーをUNIX等の開発に振り向けてくれれば、状況は一気に
変わるかもしれないが、そんなことは望めないし、ユーザも望んではいない。

＞１０４
いくらIBMのRS6000でも汎用機と同じ保守は期待できない。
汎用機を使いかつRS6000も使っているなら十分な保守を期待できるかもしれないが。
これは銀行・証券のシステムをやっているヤツなら痛いほど分かるはず。

>>104
ＩＢＭのお偉いさんもメインフレームとの稼働率の差については
みとめてるんだけど・・日経コンピュータのインタビュー記事
だったかな・・

ちなみにオレは「汎用機派」ではない。
「どんなシステムもUNIXとPCサーバで作ってやりたい、できないことはない」
と考えているが、実際に顧客の要望、コスト、信頼性、稼働率、実績を踏まえると
まだまだ汎用機にはかなわないんだよ。

ここで「UNIXでできないことはない」と言っているオレの同士よ。
キミ達がもしメーカに勤務しているなら汎用機に負けないUNIXマシンと
保守体制を作ってくれよ！

>>106
>汎用機を使いかつRS6000も使っているなら十分な保守を期待できるかもしれないが。
って事は、保守体制は「ある」って事でしょ？
ただ、その保守体制を享受するためには＋α（別に汎用機の保守も契約してるとか）が必要というだけで。
だったら「Unixなら保守体制を一から構築する必要がある」ってのはウソなのでは？
ただ金追加して払えば済む事でしょ？
（まぁ、ベンダが受けてくれるかどうかは別だけど）

>>107
>ＩＢＭのお偉いさんもメインフレームとの稼働率の差については
> みとめてるんだけど・・
オレも認めてるよ。
だから、稼働率やその他、「本当に汎用機が優れている所」をアピールするんならわかるけど、
そうでない所で「汎用機はスゴいんだ〜」って言っても「コイツ知らないだけじゃん」って思われてオシマイになっちゃうよ。って言ってるの。

＞１１０
違うんだよ。
汎用機を使ってくれている大事なユーザだから、UNIXも”特別に”
見てあげるっていうこと。
UNIXだけ使ってる場合の保守レベルはガクンと落ちる。

キミが言うとおり、
＞ただ金追加して払えば済む事でしょ？
＞（まぁ、ベンダが受けてくれるかどうかは別だけど）
受けてくれないんだよ。
つまりUNIXだけの保守(汎用機と同等の)をやる体制がメーカに
ないってこと。

>>111
いや、それは「現時点でクリチカルな業務は汎用機で」という方針でベンダが売ってるからであって、
Unixの保守はベンダの提示する保守料の範囲ではレベルの落ちたサービスしかできないというだけ。
この辺（保守料金とか）の設定というのはベンダの経営方針が変われば明日からでも変わる話。

攻め方（笑）として
「保守体制が無いからUnixはダメ」
って言うんじゃなくて、
「クリチカルな業務に耐えるだけの稼働率が確保できないからUnixはダメ（な分野もまだある）」
って言わなきゃ
Unixの保守体制がイマイチなのは「クリチカルな業務に使われていない」という現状の結果でしか無いんだから。

＞１１２
そりゃごもっともだと思うよ。
でもね、「保守体制がイマイチ」の状況で「クリチカルな業務」に使うわけにいかないんだよ。
キミが金出して大事なお客様のお金を預かるシステムを作る場合、そんな保守体制がイマイチの
マシン採用する？

メーカが「これだけの保守をします」「稼働率も汎用機と遜色ありません」とか、さんざん使う側の
不安を打ち消してくれなければダメなんだよ。

オレなら銀行の勘定系とかをUnixではやらないね。
それは保守の問題じゃなくて「稼働率も汎用機と遜色ありません」という状態に無いから。
それは>>110でも書いた通り。

誤解があるといけないので一応書いとくけど、オレは汎用機を否定してる訳じゃない。
現状の稼働率から見て、汎用機にしかできない分野が厳然としてあるとも思ってる。
ただ、「Unixは寄せ集めマシン」というステレオタイプや、結果論でしかない現状の保守状況を理由に
「汎用機じゃなきゃダメだ」って言っても同意を得るのは難しいよって指摘してるだけ。

汎用機ってつまるとこ専用機？

出番がない・・・

保守云々の話だが、私の勤める会社のセンターはIBMなどのサポートが
24時間365日常駐してることもあり、それが売りになりUNIXやPCも集めら
れているのが実状。「NTというかPCは不安」という顧客に「IBMが常駐！」
は効くようだ。

S/390がどかどか置いてなくてもこれだけの保守体制をとってくれるので
あれば、PCやUNIXももっと基幹用途に使われ、それに連れ現在では
懸案となっている諸問題への解決策も続々と現れるのかもしれない、
基幹用途に向けた積極的なソリューションが提供されるのではと思う
私は少し酔っぱらってます。

>>114
「現状」を甘く捉えすぎだと思うよ。結果論でしかないって？
顧客に対して十分説得力のある一つ（それもかなり大きい）になると思うが。

>>116
そうなりつつあるよ。ＰＣというとユニシスさんかな？

スパークサーバーは
メモリにパリティビットすらないのを3年も隠せるんだよ
シングルベンダって怖いね

どっちもがんばれ！

パリティビットがあったとして、問題発生後
何か出来るのか？
そんなに必要か？

>>120
まあ問題発生後はなにもできなくても「正しくない」内容が伝わる可能性を
低くすることはできるんじゃないかな。

>>97
＞汎用機（および専用 OS）を使うことによって、その部分の設計および実装・運用が
＞Unix ないし PC に比べて容易かつ確実に実現できるということなのか？

RACFのリソース管理が有名かと。許可されていないリソースに触ると、すぐにフ
リーズ（？）し、警告リストが出力され、始末書を書かされ晒されるというもの。

＞汎用機 = どうやっても計画的にならざるを得ない
＞Unix/PC = どうやっても計画的にできない

その通りでありコメントのつけようがないのだが私の読み方がマズいのだろうか。
ただ、開発の単位が汎用機は年、C/Sは月、Webは週だと言われているように、
開発サイクルによる差異も影響する。

＞最終的には、携わる人が、計画的に、隅々まで目を配って、信頼性とセキュリティを
＞高めるために、たゆまぬ努力をしているからこその汎用機の信頼性であって、もし
＞同じメンバーで UNIX/PC 上のシステムを開発したら、汎用機レベルのセキュリティと
＞信頼性を実現できるのではないかという疑問が残る。

汎用機レベルのセキュリティと信頼性を実現するにはUNIXやPCの利点のいくつか
を失うような気がする。これは直感だけなのでいずれ改めて書ければと思う。

>>117
いくらサポートが厚くても、今の稼働率で銀行の勘定系をUnixに持って行くのは無理ってもんだろ？
顧客に「保守」という面で説得する以前に「稼働率」をもっと上げない事にはUnixで勘定系なんて怖くてできない。

現状のUnixマシンは、汎用機のような稼働率は達成できないし、そういう稼働率を要求されるようなクリチカルな業務も無い。
その「結果」として（というか「そういう方針で」かな？）、メーカもそういう保守体制を取ってない。
そういう事だと思うけど。オレは。

高信頼性の分野で必要な事が10あるとすれば、稼働率は1番目とか2番目に来る事。
保守体制なんてのは7番目とか8番目だな。

1番2番を達成できないうちから7番とか8番の話をしてもしょうがないって事。
逆にUnixベンダなんかも、1番とか2番が達成できるようになれば、そこへ売り込むためにも7番8番の環境も作ってくるだろ。

皆さんのお話を聞いてると悲しくなってきました。
大企業の前では、技術者も所詮は部品であり大量に安くて且つ品質の悪い人材を
掻き集め、その人の成長等は無視され、ひたすら社会貢献の御旗のもとでこき使われる
様子が浮かんでなりません。
そんな市場などに優秀な人材が集まるべくもなく、唯ひたすらに時代遅れの声を待ち続ける
旅人のようですね。
衰退産業のエゴが働かないことだけを願っております。(可能性低いけど..)

>>122
>＞汎用機 = どうやっても計画的にならざるを得ない
>＞Unix/PC = どうやっても計画的にできない
>その通りでありコメントのつけようがないのだが私の読み方がマズいのだろうか。

汎用機は計画的にってのはそうだと思うが（というか、そういう場合が多いようだが）、
Unix/PCでも計画的にやってる所は計画的だよ。
ただ、Unix/PCの場合、汎用機と違って、最初から全部入れるんじゃなくて順次増設になるから、
最初はワンフロアにラック1本とかで寂しいけど（ﾜﾗ

>＞同じメンバーで UNIX/PC 上のシステムを開発したら、汎用機レベルのセキュリティと
>＞信頼性を実現できるのではないかという疑問が残る。

ソフト的な面では可能かもしれないが、ハード的な面はどうしようもないんじゃないかなぁ？
たとえば、Windows2000なんかで、稼働率保証99.9%なんてのがあるけど、これって要するに月に一度は止まりますって事でしょ？（ﾜﾗ
元々ハード自体がこの程度の稼働率をターゲットに作られてるんだから、その上で動くソフトをどうやっても99.99%とかの稼働率は達成できないと思うな。

ちょっと前から読み直してて思ったので補足しとくと、「稼働率」として汎用機とUnix/PCで一番違うのは

「止まらない事」

保守云々ってのは

「止まったものをどれだけ早く復旧できるか」

って事。MTBFとMTTRだな。
MTTRを同等にするという方は、ハードベンダが「必要」という経営判断を下せばすぐにも実現できる事。
MTBFの方はハードウェアのアーキテクチャからOSから多くの部分で現状のUnix/PCは汎用機に遅れを取ってる。
まぁ、OSに関して言えばWindows系が悪すぎるだけで、Unix系はそこそこいいけどね。（ﾜﾗ
この辺がクリアされない限りは、全ての汎用機をUnixで置き換えるってのは無理だと思うし、汎用機もまだまだ活躍の場はあると思う。

実際、ASPなんかで1UのUnix/PCを何百台も置く位なら、S/390一台入れてVM上でLinuxたくさん動かした方が色々な面で良いんじゃないかな？とか思ったり..

>Unix系はそこそこいいけどね
へえー今初めて知りました。

66さんが言う所の
>いくらIBMのRS6000でも汎用機と同じ保守は期待できない。
>汎用機を使いかつRS6000も使っているなら十分な保守を期待できるかもしれないが。

というのは事実でしょうね。　保守の要員は汎用機グループとunixやAS/400
などのグループとに別れていて、双方で体制や要員のスキルがちょっと違う。

要員のスキルというよりは、考え方の部分もある。

汎用機が入っている様な顧客では極端な例を上げると、そのシステムが1時間
止まったら不渡りが出て会社が倒産とかして誰かが首をくくったりする様な
シチュエーションもあり得て、結果凄くシビアな稼働率を求められるから
間違っても止められないし、止まったら保守員は休みや自分の都合を放り出
して速攻で直しに来るから。

汎用機とその他ではシステムに関わる人間全てに128で触れた様な考え方や姿勢の
違いがあって、設計・開発・運用・保守とあるからその差が余計開いてしまう。

汎用系とunix系を両方使う所なんかに行ってミーティングすると、unix系の人は
「厳しすぎる、面倒くさい」と言い、汎用系の人は「いい加減すぎる」と相手の
考え方を表現するシーンに立ち会った人はきっと少なくないはず。

「そういう状況にunixやPCが使われてないから育たない、ゆえに誰かが先頭を
切って使い出せば状況は改善されるのでは？」　という意見が多く見られるけど
選ぶ側にしてみればそういう体制が整ってからでないと使えないのは当たり前だし、
そういう体制は関わる全ての人の考え方と行動が変わらないと無理なんですね。

人の問題だけでも難しいのに、セキュリティの事、設置スペースとスケーラビリティ
と計画の事、運用ツールの事、実績の事…　考えたらまだまだクリティカルな分野
では汎用機しか要求を満たせない要件って多いんじゃないかと思います。

MP3000を使っている人いますか

IBM9021でMVS/ESA
DASDはESCONで光接続の日立のやつ

なんか寝て＆仕事してる間にずいぶん進んだな。
オレの言いたいこともほとんど書かれてしまったし・・・

ところで、みんな仕事は大丈夫なの？それとも学生？

UnixもＰＣも汎用機なんですけど．．．（汗"
それと、UnixとWindowsを同列に扱うのは止めたほうが良いですよ。
あまりにもものをしらな過ぎる。

私もほんとに出番がなくなってしまった・・・

>>124
汎用機がいい！っていうひとはまだまだたくさんいる。その声がもっと
伝わる方法はないものかなあ。書店に並んでるコンピュータ雑誌の中の
世界だけがこの業界ではないはずなんだけど。

２年くらい前か、当時のアスキーNTにS/390の記事が組まれたことが
あったが、なかなか新鮮だったように思う。昨年あたりの日経ソフトウェア
の特集がCOBOLだったような記憶もある。

汎用機→レガシー→なくしたい、って風潮は、情報が不足しているが故の
必ずしも正しい認識とは言えないと思う。情報を積極的に提示できなかった
側の責任もあるのだろうけど。

>>133
＞UnixもＰＣも汎用機なんですけど．．．（汗"
「いわゆる」汎用機もUnix機なんですけど・・・って話になりますよ。

＞それと、UnixとWindowsを同列に扱うのは止めたほうが良いですよ。
＞あまりにもものをしらな過ぎる。
UnixはハードとOSのどちらを指しているの？両方？
PCとWindowsを明確にわけてるのはなぜ？？

昨日は汎用機寄りの立場で書いたので今日はアンチ汎用機（笑）
上でも書いたように、確かに汎用機でなくてはできない事は今後も残ると思ってるけど、
汎用機ユーザとか汎用機売ってるメーカとかって何でも「汎用機でやりましょう」って言うよね
確かに信頼性(稼働率とか)で言えば汎用機の方が上だし、大は小を兼ねるという事でいいのかもしれないけど、
オーバースペックの米潰し（笑）になってしまう危険性もある。
たとえば中堅程度の企業で、会計処理なんか汎用機にやらせてて、夜間に走ってるジョブと言えば1時間ぐらいバックアップだけとかさ。
こういうのって汎用機いらないよね。Unixにどうしてもアレルギー（笑）があれば、オフコンって手もある。
メーカはもちろんオイシイお客さん逃がしたくないから「おたくぐらいの規模なら汎用機が要りますよ。これまでの資産もあるし」とか言うだろうけどね。
こういうのは今後リプレースに合わせてどんどん無くなって行くだろうね。

>>135
> PCとWindowsを明確にわけてるのはなぜ？？
PCと言う場合、LinuxとかFreeBSDが動いてる場合もある。
PCというハードウェアで動かしていても、LinuxとWindowsじゃあ稼働率が全然違う。
Windowsだったら、日に100万件ぐらいのデータ処理するようなDB載せてたら、まぁ週に一度はリブートしないとダメだろうね。
前にWindows NT+SQL Serverで150万件/日のデータ処理させるシステム組んだけど、3日ぐらいでマトモに動かなくなった。
別にLinux+DB2の試験環境作って、同じデータ突っ込んでみたけど、1ヶ月動きつづけたよ。試験終わったから止めたけど、そのままやってればもっと動いただろうね。

あと、ハードの話をすれば、Sunなんかの中位〜下位機種って、中身はPCなんかと変わらない。
PCでも上位のサーバ用のハードなんかで、電源の冗長化とかRAIDとかちゃんとすれば、ハードに限ればUnixの上位機種と遜色ないね。
だから、Unix/PCというのはひとくくりにできるかもしれないけど、Windowsは別物（笑）
アレはクライアント用のOS。サーバで使っちゃダメ。
どうしてもサーバもWindowsにしたいんなら、毎日リブートだね。

>>132
> ところで、みんな仕事は大丈夫なの？それとも学生？

今仕事中（笑）
今やってるのが、米国のエンジニアと話しながらじゃないと進まない仕事なので、あっちに合わせてやってるの。
もう少ししたら出社してくるかなぁ。オレは眠い（ﾜﾗ

（昨日初めて読み出したので、古い話を掘り返してしまうがスマソ）
>>37
> 超大量のデータ印刷したりフロア全体をテープライブラリにして
> やんなきゃいけない超大規模とかは汎用機でしょ。

最近はそうでもないよ。
10TBクラスのRAIDファームでもSAN使ってUnixで扱ったり、SONYのPetaSiteなんかのペタクラスのテープライブラリもUnixで動く。
プリントアウトなんかも、信頼性はそれ程求められない分野だから、Unixでもできる。

>>133
>UnixもＰＣも汎用機なんですけど．．．（汗"

サーチエンジンで「汎用機」って引いてみな。
この業界で言う所の汎用機って物がどういう物か解るから。

>あまりにもものをしらな過ぎる。

オマエモナ（藁)

>それと、UnixとWindowsを同列に扱うのは止めたほうが良いですよ。

ここの話のテーマ（メインフレームってこの先どうなるの？）で扱う
様な案件（＝汎用機で続けるか、それ以外に持っていくか）という視
点で物を話す場合は、同列扱いでも構わないのでは？

>>140

> サーチエンジンで「汎用機」って引いてみな。
> この業界で言う所の汎用機って物がどういう物か解るから。

サーチエンジンが間違ってるだけだよ。
汎用機の解釈を特化し過ぎているね。
それとハードとＯＳは区分けして語るべきだね。

基本的にハード機器を議論の対象にしてはいけませんよ。

汎用機の利点：万が一の事態に陥った時の責任の所在が明確。

>>141

ハードもソフトもすべて含めて「システム」なんだから、ハードも
対象に含めないと意味ないんじゃない？

ちなみに・・商用ＵＮＩＸ開発部門からは、「ＵＮＩＸ（と、当社ＵＮＩＸ用
サーバ機の組み合わせ）では２４時間稼動（１年間稼動させつづけるの意味）は保証できません」
と正式回答を得てます。
同社営業やＳＥからは当然客に「ダメです」なんていいませんけどね

サーチエンジンが間違ってると来たよ。　すげぇな(ﾜﾗ

>>143
そりゃ、「当社」が悪いね。

>>140
>>UnixもＰＣも汎用機なんですけど．．．（汗"
>サーチエンジンで「汎用機」って引いてみな。
>この業界で言う所の汎用機って物がどういう物か解るから。

いわゆる「ホッチキス」と「ステープル」の問題の逆だな（ﾜﾗ
元来の「汎用機」という日本語の言葉の意味としては汎用に使える（何でもできる）機械（コンピュータ）という意味だろうが、
この業界で「汎用機」と言えば、いわゆる「メインフレーム」だけを指す。
っていう前提で、オレは「汎用機」と書いてる。
おそらく多くの人もそう読んでるんじゃないかな？>>133
少なくとも、UnixやPCを「汎用機」って呼んでるような場面にはお目にかかった事は無いな。

まぁ、この業界の事を知らない厨房か、辞書に書いてある意味しか認めないという辞書オタか、立場が悪くなったので、関係無い所を突付こうと思ったUnix至上主義者(笑)か、どれかなのでステとけ
相手しても場が荒れるだけだ

# ってオレモナー

Unix至上主義者がいるときには誤解を受けないように
メインフレームと呼ぶようにしている。
もちろん普段は汎用機。

>>142
> 汎用機の利点：万が一の事態に陥った時の責任の所在が明確。

いゃ、ソレはマルチベンダーの問題だ。
Unix使ってもシングルベンダーでまとめれば、責任の所在は明らか。
Unix＝マルチベンダーという考えを否定する事は既に書いた。
反論があれば詳しく書いてくれ。再反論するか、同意するから（ﾜﾗ

UnixよりもNTのほうがいいとこもあるぞ

段々、ガキンチョレベルの会話になってきたね♪
特に、146,147さん当たりは最悪ッぽいね。
もう少しＯＳの成り立ちや仕組みを勉強して下さい。

ケケッ
OSの成り立ちだって。
バカ丸出し。
汎用機が「汎用」って言われる理由はOSなんか無かった頃にあるんだよ
突っ込み入れるんだったらもっと勉強してからにしようねぇ〜

相性による不具合なんて言う言葉が無い以上、
品質は高いと見ていいんじゃないかな？

デジタルの世界と言うよりシステム関係で、「相性の問題」なんて
逃げ口上だろう。絶対確固たる原因があるんだよなあー。
ブラックBOXになっていて分からないだけで

汎用機でもUNIX動くですけど。TCP/IPだってね

>>152
製造現場の事は良く知らないから思い付きだが(笑)、汎用機でも実は相性の問題ってあるんじゃないかな？
汎用機と言えども、工業製品である以上、それぞれのハードウェアでのバラ付きもあるだろうし。
ただ、ユーザの所に出て行く前に十分なテストをやって、ユーザサイトで問題を起こさないようにしてるだけで。
まぁ、それだけ十分なテストをするだけのコストがかけられる値段になってる訳だが（ﾜﾗ

> 汎用機でもUNIX動くですけど。TCP/IPだってね
TCP/IPでなければUnix動かす意味無いじゃん（ﾜﾗ

>>151
「汎用」じゃなくて「汎用機」。
ここ大事だからね。

ところで、ＵＮＩＸに「プロセスごとにＣＰＵ使用率を制限する」機能が
ないってホント？
ＵＮＩＸサーバを再起動したとき、１個の大きなプロセスがＣＰＵ占有してしまって
小さいけど、早急に動かして一部だけでも再開したい業務が、何十分もうこがない
のみたからさ・・

実際の事例です・・（もうこの商談はないので詳しく調べる気はありません）
小型メインフレームでバッチ処理のみ下記のような業務をしています
ＵＮＩＸ機にダウンサイジングのと後継機へのリプレースを比較し
ユーザに報告します。
１．２０００人分の給与計算
２．固定資産管理（金額単位は「兆」の単位が必要）
３．年１回　登録業者証（賞状みたいなやつ）数千業者分印刷

ＣＯＢＯＬ７４（準拠）で３０万ステップ程度
業務用スクリプト５万ステップ
フォームオーバレイ用フォーム　百数十個
ファイルはすべてシーケンシャルファイルを利用。ＤＢはなし。
数百メガバイトのＤＩＳＫを使用している。
ラインプリンタは　５１０行／分（くらい）の性能
ページプリンタは　１２５０行／分（くらい）の性能
を使用している
プログラム・データは、必要になるつどテープ（オープンリールのやつね）
をとりつけて運用している
ちなみに・・後継機るのメインフレームの値段は定価６５０万円＋その他機器２００万くらい
現行機を利用可能。
私はねＵＮＩＸ機へのリプレースを提案できませんでした。
プログラム等ソフトの移向費用があまりにも高くて・・（＾＾；）
あなたはＵＮＩＸ機へのリプレースをていあんできますか？

>>156
適材適所。
ネットワーク経由でそれができる条件とか、なら
UNIX化もありかも。

>>155
> 「プロセスごとにＣＰＵ使用率を制限する」機能

Unix（および互換OS）系とWindows系の場合は各プロセスの
優先順位を設定する方式が標準なのでは。

"早急に動かして一部だけでも再開したい業務" の優先順位を
上げて、残りを下げればOK。

>>156
上と同じ業務ではないけど、Unix方向にもWindows NTクラスタリング方向にも
提案して実運用まで持っていったことがあります。

> プログラム等ソフトの移向費用があまりにも高くて

基本的にはここが大きいですね。UnixやWindows系でないとしても
プログラムは実質的に書き直しせざるを得なくなるでしょうし。

あとは利用者と現場の管理者に対して運用手順が大幅に変わる
（Unix系やWindows系に沿うような形に）ので、その説明と
教育をどうするか、というのもコストとして考えておく必要が
ありますね。

ただ思ったのは、

> １．２０００人分の給与計算
> ２．固定資産管理（金額単位は「兆」の単位が必要）
> ３．年１回　登録業者証（賞状みたいなやつ）数千業者分印刷
を見る限りでは大して大規模にはならないのではないかと。

コンビニのように売り上げデータが秒単位で上がってくるような
厳しいシステムではないですから、**信頼性は別とすると**
極端に言えばMicrosoft Accessでも十分対応できます。

>>157
端末は4台で・・電算室の中だけに閉じてました。

>>156
頭がメインフレームの人は無理でしょうね。

ＣＰＵ能力は現行ＰＣサーバ・ＵＮＩＸでもまったく問題ないです。
プログラムの移行費用（独特の給与形態と大きすぎる資産管理のため適用できるパッケージ
がなかった）推定　1億ちかく
また、
給与明細等印刷の際にジャムったときなどの再印刷の問題の他ＨＷ費用が
おもったほど下がらなかった。
メインフレームでは、本体のみの取り替えですんだが、ＵＮＩＸ・ＰＣサーバでは
プリンタも取り替えなければならなかった。
同等のラインプリンタは定価350万くらい・・
同等のページプリンタは定価900万くらいした。

業務の流れを変え
印刷方式の変更も考えたが・・
プログラム移行費用がさらに増えるのであきらめた。

>>162
やっぱり、頭がメインフレームしてる...

一般のグループウエアとか、別の業務システムは別途オープンシステム
で構築中・・
このシステムだけとりのこされたのだ・・

>>156
汎用機->Unixへ移行するのに、現状の汎用機上で動いてるものをそのまま移植しようとしてもコストで合わないでしょうね。
汎用機->汎用機であれば、単純にハード価格だけで済むけど、Unixへ移行するなら必ずソフトの部分が入ってくるので。
あと、やっぱりUnixとかPCへ移行するのであれば、会社に合わせてソフトを作るという考え方を捨てて、ソフトに合わせて業務の流れを変える。
ど〜しても譲れない所だけ開発。
というように考え方を変えなきゃダメでしょうね。

たとえば、
> １．２０００人分の給与計算
弥生給与
> ２．固定資産管理（金額単位は「兆」の単位が必要）
弥生会計の固定資産管理エクステンション
> ３．年１回　登録業者証（賞状みたいなやつ）数千業者分印刷
Wordの差込印刷

で、Windows1台でもできる程度の規模ですね（ﾜﾗ
もちろん、他とのリンクとか、その会社固有のナニかがあったりするので、「これで十分」とは言わないけど、規模的にはこんなもん。

ところで、ちょっと疑問なんだが
> 後継機るのメインフレームの値段は定価６５０万円＋その他機器２００万くらい
って本当にメインフレーム？オフコンの中位機種程度の価格のようだが...

それと、
> 同等のページプリンタは定価900万くらいした。
って桁間違えてないか？
>ページプリンタは　１２５０行／分（くらい）の性能
ページプリンタのスペックを行単位で書かれても困るんだが(笑)、まぁ50行/Pageとして換算すると25Page/分でしょ？
これぐらいだったら900万もしないでしょ。
たとえば、キヤノンだったら、精一杯奢って(笑)60Page/分でも298万
http://www.canon-sales.co.jp/Product/LBP/LBP-1060.html
32Page/分で\348,000- 24Page/分なら\298,000-
エプソンだと40Page/分で\498,000-
http://www.i-love-epson.co.jp/products/printer/laser/lp9600s/b_9600s_ex.htm
リコーは38Page/分で\998,000-
http://www.ricoh.co.jp/IPSiO/nx1100/index.html
ってあたりかな？

もう一つおまけに
> 給与明細等印刷の際にジャムったときなどの再印刷の問題
って、一枚単位で再印刷できるようにするのアタリ前じゃないか？
そういう機能の無い（そういう機能を後で付加しなきゃいけないような）ソフトって欠陥品だと思うぞ。オレは（ﾜﾗ

# ジャムったら2000枚印刷しなおすんだろうか？

ちなみに、上で書いた弥生やWordはボケてみただけだ。
本気にするな。オレも本気で書いてる訳じゃないから（ﾜﾗ

# って一人突っ込みを入れようとしたらクライアントのPCが落ちちまった。
# 鬱だ氏脳

>>165
>> １．２０００人分の給与計算
>弥生給与
→給与体系が独特で一般のそふとがあわないのですよ

>> ２．固定資産管理（金額単位は「兆」の単位が必要）
弥生会計の固定資産管理エクステンション
→「兆」まであつかえますか？
>> ３．年１回　登録業者証（賞状みたいなやつ）数千業者分印刷
>Wordの差込印刷
→印刷時間が限られていて「連続用紙」で朝から晩まで印刷します
　プリンタがあるかどうかですね

>> 後継機るのメインフレームの値段は定価６５０万円＋その他機器２００万くらい
>って本当にメインフレーム？オフコンの中位機種程度の価格のようだが...

ＥＰＵをＣＭＯＳチップ化したとき大幅に価格が下がりました。
「小型」メインフレームです。

>> 同等のページプリンタは定価900万くらいした。
>って桁間違えてないか？
連続用紙を使うページプリンタです

>>ページプリンタは　１２５０行／分（くらい）の性能
>ページプリンタのスペックを行単位で書かれても困るんだが(笑)、まぁ50行/Pageとして換算すると25Page/分でしょ

連続用紙を使うページプリンタは行／分で性能を表します。
朝から晩まで印刷するような場合、カット紙だと紙の重なり方（高く積み重なると排出された紙の順番がむちゃくちゃになつたりする）
のであまり向きません。
フォームオーバレイでフォームを登録できる数も問題になります。

>って、一枚単位で再印刷できるようにするのアタリ前じゃないか？
そういう機能の無い（そういう機能を後で付加しなきゃいけないような）ソフトって欠陥品だと思うぞ。オレは（ﾜﾗ
># ジャムったら2000枚印刷しなおすんだろうか？

UNIXとかＮＴとかの標準機能にはないですね

>>168
すまん。この前つくったのがそうだった。
すぐ客に、途中から印刷し直せるようにしてくれといわれた。
でもまだやってない。
ソフトで組み込まんでも、スプーラにそんな機能がほしいなーー

＞ソフトで組み込まんでも、スプーラにそんな機能がほしいなーー
UNIX用でそういったミドルウェアがでてますね
ＰＣ用は最近のプリンタ添付のユーティリティでかのうなのがありました
（かんたんなものだけど）

>>167
オレの単なる冗談にまで親切に答えてくれてありがとう。
ま、それは置いといて、連続紙って最終的にはカットしなきゃいけない訳で、カット（バースト）する手間、カット時に破損してしまった時に再印刷しなきゃいけない手間なんかを考えれば、スタッカーにある程度溜まったら取り除く程度の手間は手間のうちにも入らないと思うがな。オレは。
それに、カット紙使うプリンタでも、早いヤツならそれなりにスタッカーに溜められるようになってるし。たとえば上で書いたキヤノンのヤツなら3000枚ぐらい

>　UNIXとかＮＴとかの標準機能にはないですね
ジャム対応に限れば、大抵の場合プリンタ側で1ページ分バッファして、ジャムったら再出力ぐらいはしてくれるからな。

>>169-170
Unix/Windowsとかの場合、OSが管理するのはページ単位じゃなくてジョブ単位だから、OSとして汎用的にサポートするのは難しいだろうな。
特定のプリンタとか、PostscriptとかLIPSとか制限が付けられれば、ページ単位での対応もできるとは思うが、途中にプリンタバッファが入ってたり、ネットワーク経由だったりすると、ウマく行かないような予感がする（ﾜﾗ

＞カット紙使うプリンタでも、早いヤツならそれなりにスタッカーに溜められるようになってるし。たとえば上で書いたキヤノンのヤツなら3000枚ぐらい

今なら十分選択肢ですね。
ただ、印刷物をファイリングするとか、そういったところで客からつっこまれました

>>　UNIXとかＮＴとかの標準機能にはないですね
>ジャム対応に限れば、大抵の場合プリンタ側で1ページ分バッファして、ジャムったら再出力ぐらいはしてくれるからな

失礼・・ジャムが問題になるのは
ページプリンタよりむしろラインプリンタのほうが問題ですね。

複写紙タイプ給与明細書印刷なんかに使います。

一人一台パソコンがついたんで・・半分冗談で
「給与明細は各自が自分の分を自分で印刷しましょう。（笑）
そうすれば、ラインプリンタなんかいりませんよ」といったら・・
「信用できない奥さんからの問い合わせが増えるからダメ！（笑）」
といわれた

うちの給与明細は各自印刷。
社員は約１５００人。

> ただ、印刷物をファイリングするとか、そういったところで客からつっこまれました
上のキヤノンのはパンチもしてくれるぞ
ついでに製本とか中折りとかまで...

そういえば、他社品だが封筒に詰めてくれるってのもあったな。NECだっけ？

>「信用できない奥さんからの問い合わせが増えるからダメ！（笑）」
>といわれた
PGPで暗号化＆署名してメールで送るとか（ﾜﾗ

フォーム（フォームオーバレイ用データ）の移行もあり・・
移植費用がハードウエア価格を大幅に越えたんですな・・
結局本体のみ取替えで済ませました。
アプリはいじらなくてよかったし。周辺機器は今までどおりつかえるし・・
ちょっぴりオープン化したのは、通信プロトコルがＴＣＰ／ＩＰになったのと
端末エミュレータがＷｉｎ対応になったくらいでした

プリンタの問題なら、印刷する部分だけ印刷業者に渡すという手はないのですか？
高いのかな？ よく知らないけど。
給与明細は各自が自分のＰＣで見る（ペーパレス）というのが最近の流行だと思う・・・
けどやっぱり>>174の問題が大きいみたいだね（わら

自社の社員の給与を他社に印刷させるというのは抵抗を感じる人が
多いのでは？　　帳票を完全持ち込み制にして、印刷ミス分を含めて
持ち込んだ分の枚数が必ず戻ってきたかどうかを確認するとかしても
自社社員の給与明細を他社に見られてしまう可能性はなくせませんし。

ラインプリンタは昭和６０年代のはじめ買ったものを今も使いつづけています。
保守サービスがまだ続いているのでまだ現役です。メーカの保守サービスが
続く限りまだ使いつづけるでしょう。メインフレーム本体を取り替えたのは、
買い換えるだけで月額支払いが減るからです（それだけ昔は高かった）。

返事をくれたみなさん、どうもありがとう。

どうやら人だけの問題じゃないってことだね。
現在入手可能なベンダーの保守体制、サポート体制、技術情報等を前提にする限り、まだ 24x7 の
信頼性を実現するにはメインフレームしか現実的な解がないって解釈した。

これを見て結構イメージがつかめた。
http://mentai.2ch.net/test/read.cgi?bbs=infosys&key=982762367&st=74&to=75&nofirst=true
確かに完全にバグを追いきるにはシングルベンダーかつ手厚いベンダーサポートが必須だね。

Open Source でも実現できるって人がいるかもしれないけど、巨大な業務システムを構成する
すべてのコンポーネントについて、ソースコードおよび実装に通じた人を集めるのは、理論的には
無理じゃなくても実際にはとてつもなく困難だろうね。

やっとわかったよ。

>>182
「電動ナナシ」って誰？
誰も返事なんかしてないよ。
アホにはアホの結論しか出せないね。

あはは、もっと煽れ！

メインフレームのいいとこ・・
すんげ〜長いこと保守してくれる。保守打ち切りも事前に教えてくれる。

>>167
メインフレーム用のカット紙ページプリンタあるよ。
たしかXeroxが出してたはずだ。
印刷後製本も出来るので連続紙よりも便利だ。
値段はご多分に漏れず強烈に高かったと思うが。

>>155
> ところで、ＵＮＩＸに「プロセスごとにＣＰＵ使用率を制限する」機能が
> ないってホント？
ないUNIXもあるし、あるUNIXもある
PC以外でうごく商用UNIXでは大抵あります
標準状態では使えなくて、メーカーから別途ライセンスをかわないと
いけなかったりする場合もあります
また、スーパーコンピューター用のUNIXはあるんじゃない？
UNICOSとかSuper/UXとか

UNIXがはやったのは、そーゆーのを細かく指定しなくてもとりあえず
動くとかゆーのもあるのかな?
freeunixとかはそーゆーのは細かな制御が難しいね

NTやSolarisがダウンしても、MSやSunのひとが謝りにきたりはしないけれど、
メインフレームがダウンしたら部長とかが頭下げにやってくるからいいね

>>188
そういう契約すれば来るでしょう。

>>178
メーカの思うツボだね。

こないだ某社の社長が某銀行に謝罪に行ったらしいぞ。

>>186
>メインフレーム用のカット紙ページプリンタあるよ。
>たしかXeroxが出してたはずだ。

プロプラシステムの象徴であるメインフレームで、他社製品を使うのは、
かなりの勇気が必要ですね。
たいていメインフレームメーカ自身が、ＯＥＭ供給を受けるなりして同類のものを
製品化しているかもしれません。

メインフレームっていくらぐらいかかるの？
ＰＣの値段しか知らないので教えて…
それとおすすめのメーカーや機種ってあります？

＞１９３
「メインフレーム」といえばＩＢＭ、富士通、日立かな。
あと値段はピンキリです。

>>193

小型メインフレーム　６００万〜ん千万以上
中型メインフレーム　ん千万（後ろのほう）〜ん十億（青天井と思っていいです）
大型メインフレーム　ん十臆〜（青天井と思っていいです）

>>193
「おすすめのメーカーや機種」というのが、なんか、
ＰＣ感覚でメインフレーム買うみたいで斬新です。

住友系ならNECとかいったようなしがらみが非常に強い。

http://www.fujixerox.co.jp/product/4669_lps/
これ、使ってる。

>>196,197
そう、大抵が政治問題でメーカーが決まって、懐具合で機種が決まる。
カットオーバーまでは低いスペックでコストを抑えて、開発が終わって
カットオーバー前にMESしてスペック上げるとか色々手法はあるね。

ttp://www.○ujixerox.co.jp/product/index.htm
DocuCentre DocuPrint DocuPrint フェイザーカラープリンター
．．．
ドキュンドキュン言ってるし掲示板嵐も支援してるのか（藁

>>193
このあいだ大型メインフレーム３台をシステム１式で１００億で
売りました。利益は３０億。いい客だ。

>201
何に使うのかな？
もうちょっと詳しく書かないと、面白くないよ

>>201
いまどき珍しい。顧客はどこ？きっと民間じゃないな。

>>202
金融機関。

都銀クラスの金融なら３台では少ないと思うぞ。
最低４台からだろう。

>>205
情報系だったり仕手

うちのＮＥＣ製メインフレームはこれからどうしたらよいのでしょうか？

>>207

なんかこまってんの？
こまってることなければそのままにしとけばいいじゃん

毎年○億円かかります。

>>205
金融機関は都銀ばかりではないよ。
都銀クラスは十数台とかです。都銀で４台は少ないのでは。

>>209

ダウンサイジングを検討し、費用とリスクと手間をはかりにかけましょう。

＞211
それがむずかしいのよ・・・

>>212
>それがむずかしいのよ・・・

だからメインフレームはなくならないで使われ続ける（＾０＾）

メインフレームからサーバーに乗り換える際の注意点は？

見積もりを間違わずに比較検討をする事。>>214

安くなるとは思わないこと。それ以外のメリット（使い勝手の向上、
業務のリエンジニアリング等）を理由にしておかないと、開発
コストをjustifyできない。

>>214
運用についてメーカだけ頼りにしないこと。
自分で情報を集めること。
ＯＳやＰＰについて障害調査を依頼しても回答まで時間がかかることを
覚悟すること。

今時、ハードだけでぼろもうけしようというのが、詐欺同然だとおもうのだが。
まだまだ、だまされる金持ちが多いのだな。
金融機関なら、ありうるな。公的資金投入して無駄なことやってんじゃないぞ！

＞216
＞安くなると思わないこと。
これって本当ですか？

>>219
サービスレベルが下がって良いなら、値段はさがる（かもしれない）
運用はたぶん汎用機より金掛かる様になると思って間違いない。

そうそう、金をかけるべき部分が変わるだけ。
運用にドジればトータルではアップしちゃうよ。

＞220、221
聞けば聞くほどよく分からなくなってしまう。

>>222
運用にかかわる
自分の作業時間、エンドユーザの作業時間が増える可能性がある。
　作業時間＝金
ですから・・

極端な例
メインフレームをＮＴ＋Ｗｉｎ９５（問題点を際立たせるためＵＮＩＸではない）
のクライアントサーバにしたとき・・
ＨＷ導入費は大幅に下がる。
運用について考えると・・
ＨＷ運用固定費　（土地代（設置スペース代）、電気代、空調代、保守契約費）はおそらく下がる

運用管理費（ＳＷ費・手間賃）　上昇する
　上昇原因
　　１．クライアントへのソフトウエア配布等（パッチ含む）
　　　　（クライアントにインストールしなければならない・・全国に散ってたら
　　　　大変）→工夫すれば減らせる
　　２．クライアントの状況がわかりにくい
　　　　電源のＯＮ／ＯＦＦ等の状況把握・制御もむずかしい
　　　　→工夫すれば改善できる
　
　

>>222 今までメーカーが保守でしていてくれたことを、今度は自分でやる覚悟を
すること。気をつけないとシステム部門の人は仕事が増えます。

>137
どうせ、お前自身がどきゅんだろ
SAS受けるくらいなんだから。

今日の格言
「世の中グタグタ実力主義が技術がどうこう言うやつに限って馬鹿なんだ」

＞223、224
なるほど

＞225
おれはバカじゃない

>225
アホ上司相手に本心かくしてヘイコラするのも
ある意味技術だよね。
それができない餓鬼の遠吠えの可能性あるよね。
まあ、そういうのが大人なら、大人になんかなり
たくないけど。

>228
アホ上司、ヘイコラ中間管理職、ドキュン下っ端の
三拍子揃った大人の職場は嫌過ぎ。

>>217
>ＯＳやＰＰについて障害調査を依頼しても回答まで時間がかかることを
PPって、Ｎ用語?

N用語だとするとプログラムプロダクトだな。

sage

だれかこいつをサブミットして(ﾊｱﾄ
//JOB
//OWARI EXEC OPCMD,CMD='Z EOD'
//

//JOB JOB
では？

>>233
OPCMD なんてカタプロ入ってたか？

運用を考えると汎用機はいろんな管理情報を一元管理できるから
すごく楽です。トラブルが発生した時も汎用機なら詳細な情報が
ソフト、ハード関係無く採取できてそれを解析してくれる専門家も
いてすごく信頼できます。UNIX機に同じことが出来れば乗り換えても
よいと思ってますが・・・

>>233
そのまんまコマンド書けよ。
もしくはコンソールで打てよ。

>>メインフレームをＮＴ＋Ｗｉｎ９５（問題点を際立たせるためＵＮＩＸではない）
>>のクライアントサーバにしたとき・・

コストで比較したら、メインフレームとＰＣじゃ比べ物にならんだろ。
かたや数十億、かたや数十万だぞ。
いくら運用費がかさもうが、コストで考えたらUNIX+Winの圧勝だよ。
そんな金があるなら俺にくれよ。

>>238
初期コストは安いですね。
導入後にプログラムをバージョンアップするとしよう・・
端末　２０００台が全国５００箇所の支店・出張所に散っている。
サーバとクライアントのバージョンアップにかかる費用はいくらかかるかな？

>>239
ＷＥＢアプリケーションにすれば、クライアントのバージョンアップ
は必要無いでしょ？

>>239

>ＷＥＢアプリケーションにすれば、クライアントのバージョンアップ
は必要無いでしょ？

>>メインフレームをＮＴ＋Ｗｉｎ９５（問題点を際立たせるためＵＮＩＸではない）
>>のクライアントサーバにしたとき・・

クライアントサーバと書いてありますよね。
また、Ｗｅｂアプリケーションでなんでもできるとはかぎりません。
反応の遅さ、Ｗｉｎ９ｘでは画面上に配置可能なオブジェクトも多くできません。
データエントリ作業には向きませんね
>>222に
>>工夫すれば減らせる
とかいてあります

ＵＮＩＸをつかうとホスト集中型も可能ですが、ＮＴです。
「問題点を際立たせる」ということでＮＴにしています。
（ターミナルサーバを使う手もありますが・・）
どっちにせよ工夫が必要ですね。

＞ＷＥＢアプリケーションにすれば、クライアントのバージョンアップ
＞は必要無いでしょ？

トレーディングシステムをＷＥＢでやってるところがあったら知りたい

最近は汎用機に繋がるクライアントもwebブラウザになってる所あるから
わけわからん。　若い人間連れてきてやらせてるがそのうち…。

ま、超保守的ユーザもいるんよ。

汎用機を知らない人のために一応かいときます。ちなみにＩＢＭ系。他メーカーは経験無し。
汎用機の操作は昔はダム端（専用端末）で操作していましたが、今ではＰＣ上でエミュレーターソフトを使って操作しています。
もちろん開発、保守、ＯＰ、ほとんどの事はエミュレーターでやります。
それと、最近では汎用機でもＵＮＩＸが動きます。あとＬｉｎｕｘも動きます。
Ｗｅｂサーバーにもなります。当然ＴＣＰ／ＩＰも動きます。
参考程度ですが私が使っている汎用機では、ここ１０年間でストップした時間は０分です。
故障は数回ありますがシステムがダウンするような故障は起きていません。
ＤＩＳＫの故障もありましたがＲＡＩＤ５、ＲＡＩＤ６のＤＩＳＫなのでまったく問題なくオンライン中に修復しました。
ただし、１０年間おなじマシンではありません。３回ほど変わっています。
今ではテープ装置もライブラリーなので人手がかからず昼間はオペレーターと言われる人もいません。
ほとんどのことを自動化しています。

Webでどんなことやるの？
エントリーには向かないんでしょ。
照会とかグラフとかメニューとか？

＞エントリーには向かないんでしょ。
なんで？
水冷式だから？

>>246
Webでできることといえば代表的なのは基幹業務をWebブラウザー上で行うとかです。
グラフもソフトがあります。文字情報だけの画面もＷｅｂ画面のようにするソフトもあります。

>>247
たしかに１０年位前まで使っていたＩＢＭの３０９０といマシンは水冷でした。
しかもでかい、ＤＩＳＫを除く本体だけでも、最低でも学校の教室一つ占拠する大きさでした。
その次のマシンからは空冷式です。大きさも格段と小さくなり幅１２０センチ
くらいのロッカーくらいの大きさです。
空冷になったとは言えＵＮＩＸに比べると初期投資は汎用機の方が格段にかかります。
０からスタートすることを考えるとエントリーは不向きです。
今の汎用機は、あくまで今までの培った技術、経験、資源があっての汎用機です。

エントリーとはインプットのことを言ったんですが・・
伝票入力をＷｅｂでやってしまうのですか？
不安定でレスポンス悪いとかないですか？

>水冷式だから？
すまん、少しチャカシタだけだったんだけど。
エントリーに向かない理由なんてないと思うけど、どう？
トランザクション処理なんて汎用機の得意分野でしょ。
あるとすれば、TCPが負荷に耐える実装になっているかぐらい？

>大きさも格段と小さくなり幅１２０センチ
最近汎用機みてなかったけど、そうなんですか。
サンのSTARFIRE（汎用機みたいなもんだけど）と大差
ないね。

>>249
実際には使ったことはないけどＩＢＭのセミナーで見たときには
まったく問題ないように思われました。
ただＰＣ自身が不安定だとどーしよーもないですけど、
それはエミュレーターでエントリーするのも同じです。

>>250
確かにトランザクション処理は得意ですけどねぇ。
実際にＵＮＩＸつかっていろいろやってないので比較できないです。

>>251
セミナーはデモにすぎないすからねえ。
事例が知りたいす。
どこでも普通にやってることなのかなあ。

だけど、外資系金融はオープン系使ってるでしょ？

だからよ！結局汎用は残るんだよ。残るところでは！！
欧米でもある一定のレベル以上の汎用は売れつづけるって言うデータ
だってあるんだから。ある一定のレベルって言うのは結構高いレベル
だけどね。
あと中央に汎用・その周りにクラ鯖なんて構成も良くあるなあ。

>>253
どこ？

>>140
>UnixもＰＣも汎用機なんですけど．．．（汗"
>サーチエンジンが間違ってるだけだよ。
>汎用機の解釈を特化し過ぎているね。

　オマエ、頭だいじょうぶか!?
　『汎用機の解釈』ってのが特に笑ったよ。

　年中理論武装してるんだけど、人の目を見て話せない
　女にはまっったく相手にされない童貞オタくんの姿が
　浮かびました。

ってことで、勇気を出して”やっぱ根本的に汎用機を使ってるのが駄目なんだから
上に言って下さいよ〜”って言ってみよう。

>>250
最近の汎用のTCP/IPはそりゃもうパワフルで頑丈に出来てますよ。
蟲も昔ほどじゃないし今なら充分枯れていると思います。
TCP/IP接続で高負荷TPサーバーにするってのは最近良く聞きます。

汎用機のエンジニアって、同じ様なシステムに
長いこといるから、仕事のやり方が私らには
納得できない部分が多々あるわな・・・
今も非常に毎日腹が立ってしょうがない生活
おくってます。分業化が進んでるのに、何でも
かんでも知ってなきゃいけない！なんてアホな
現場が多すぎるんで、それなりに出来る輩を
送り込んでもマニアックな要求ばっかされる
んで、まるで対応できない。腐ってるとしか
思えない。

>>258
マニアックな要求されて対応できないなら、覚えろよ。
それで人を腐ってるなんて言って責任転嫁してるだけだろ。
よーするに、てめーはアマちゃんなんだよ。
だいたい、何を基準にマニアックだ？ただ、自分がなじみがないだけじゃねーのか？
自分がわからないからって、知っている人間のことを腐っているだの
腹が立つだの、俺はこーいうやつが一番ムカツク。

部外者だが俺には２５９のほうが技術無さそうに見えるな。
初めからなんでもない仕様をどんどんマニアック藁にする
無恥ユーザと自称ＳＥなら俺も知っている。

> 254
ＵＢＳは、メインフレームの撤廃にチャレンジしてるという話は
聞いたことがある。外資系金融はメインフレーム系への
投資は削減の方向にあるのは確かだ、だがUNIXでは
パフォーマンス的に要求を満たせなくて、3090に戻したという
最近の話もある。

エンドユーザからすればメインフレームでもUNIXでもWNTでも
何でもいいんだよ、要求が満たせるんなら。

＞２６１
さらに、すぐに・安くできてマニュアル読まずに使えりゃ文句無し！
EXCELで充分なお仕事システム化しようとりきまないでー。

>>260
技術のある無しを言っているのではない。
２５８のあの文章ではたぶん、元々汎用系の人ではないのに汎用機の仕事をしているって感じを受ける。
ならば、仕事として関わっているのに、解らないこと、なじみの無いことを覚えるのが嫌って
言う感じがしてたまらない。それをマニアックだのなんだの言って、そのことを分かっている人間を
バカにするなんて、最低なやつだと思わないか？
最近、こういう奴と仕事をしました。はっきり言って全然仕事にならない。
だれだって最初はわからない、でもわからないなら仕事上必要なことだから
覚える努力をしてほしい。それも出来ない奴にとやかく言う資格はない。

>>261
３０９０なんて巨大なシステム使ってるとこなんて、まだあるのか？

３０９０か、懐かしいなぁ。
うちは今９６７２だよ。

>263

そのわからない… っていうのが半端じゃないんですよ…
オープン系なら書籍もたくさんあるし､利用者本位に作られているけど
汎用機の場合って担当者がわかればOKって感じで
ドキュメントもろくにないし… 新人で配属されたら発狂するよ

それとあなたのような汎用機の文化を絶対に崩さないっていう人が多いのも
話にならない…
新しく入った人をまず徹底的に洗脳しますから
全力で潰しにかかるっていうか…

自分の技術が風化しきっていても絶対に新しいものを取り込まないんだよね〜

>>265
坊や、現用機で安定稼動してればその技術は風化なんてしとらんのよ。
わかってないな〜。
充分に枯れた技術なんだよ。
てーか、君は物事の上っ面しかみとらんな〜。

若いな＞２６５
多分２０代前半だろ。あと７〜８年すればキミにも分かるよ。
っていうより７〜８年で分からなければ業界を去った方がいいね

>>266-267
うわ、こういう人達本当にいるんだ…

> っていうより７〜８年で分からなければ業界を去った方がいいね
ウチの会社では、去るのはアナタの方です。
勝手に業界とやらを定義しないで下さい。

＞オープン系なら書籍もたくさんあるし､利用者本位に作られているけど
＞汎用機の場合って担当者がわかればOKって感じで
当たり前だろ。
「よくわかる汎用機」なんて本でも求めてるのか?

7,8年たちゃ汎用機は消えてるかもしれんが。
現在の状況ではまだまだ現役。
（というか、昔入ったやつが現役稼動中)
「枯れた技術」の本当の意味知らないだろ.

>>268
汎用機とかオープンとかに種類にかかわらず
あるシステムに携わってればそこから学べる事ってのは
結構存在してるのよ。君は自分から知識吸収の機会を閉ざしてるんだぜ。

ほんとに表面でしか見とらんのね。

268は自分でもいってる通りその程度会社にしか就職できず、その程度の職場にしか配属されない。
使えない駄目野郎だね。

＞オープン系なら書籍もたくさんあるし､利用者本位に作られているけど
＞汎用機の場合って担当者がわかればOKって感じで

だからオープンシステムなのですよ。
ただ、情報がオープンなだけに中途半端に知って余計なことをしてしまうこと
もなきにしもあらず・・
余計なことをさせないためにわかるようにしないという考え方もある。
特に汎用機は、ユーザごとにＨＷだけでなくＯＳにまで手を入れることがある。
（出荷台数が少ないためユーザごとに管理できるのだ）
あと、わかりやすい書籍を作りにくいことはたしか。守秘義務もあるしね。

>>270
あの、私は265とは別人ですよ。

>>265
確かに「１周間でマスターするＭＶＳ」みたいな書籍は本屋にも無いけど。
講習会テキストとかマニュアルとかも無いの？
自ら、知らない事を学ぼうとする姿勢をみせたら、まわりも教えてあげよう
って気になるんじゃないのかな？

＞２６８
あんたも何も分かってないな。
しょぼいシステムしか作ってないからそういう意見しか言えないんだよ
少なくともキミよりはオレの方が仕事ができるという自身はあるよ。
汎用機だけでなくオープン系もな。
もっと自分を磨きな。

汎用機、分散機両方とも使っていますが、本当に止めてはいけない業務は、
どうしても汎用機になってしまいますね。
一度、汎用機を分散機に置き換えなどが検討され、一部のシステムから、
移行していったんですが、「コストが安い、時代は分散」という触れ込み
のわりに、保守コストは莫大、機械はどんどん増えていく、運用部門から、
大変だ！という怒りの連絡と、いいこと無しでした・・。ベンダーの体質
も、合わず、あまりいい思いしなかった。無駄金使い・・。と思います。
まあ、これは、うちのやり方も悪かったと思いますが。

>>275
何だか…こういう煽りでしか反論できないんですかね。

「268はどうせ使えない駄目野郎だね」「キミよりオレの方が仕事ができる」

私はほんの数行しか書いてませんし、大した事も書いた覚えはない
ですが、それでココまで言いますか。
私には低脳バカの過剰反応にしか読めないんですが。

だいたい、私はシステム屋じゃないですよ(藁 勝手に人の職業や能力
を(年齢も？)決めてかかってる所が、逆に想像力の貧困さを物語って
ますね。

システム屋じゃないくせに
＞ウチの会社では、去るのはアナタの方です。
＞勝手に業界とやらを定義しないで下さい。
なんてよく書けるな。
お前は何もんなんだよ。システムを語れる人間なのか？
さらに「低脳バカ」とくるか？
お前の方が「創造力が貧困」だよ。

初心者です
メインフレームと　オラクル+unix
の違いは？

ところで最近のメインフレームの処理速度ってどの程度なんだろう？
俺は１０年ほど前までメインフレームでソフト開発してたけど
そのころでさえ、ＵＮＩＸマシンに負けそうだったな。
（日立のＭ６８０ってやつね）
メインフレームはたくさんの処理を一台でこなすから、どうしても
応答が遅くて、いらいらしたものだ。
開発する側から言えば、メインフレームは最低だった。
今はだいぶ変わったのかな？

>>280
搭載している演算能力だけならＵＮＩＸの方が上でしょう。
ＣＰＵ（メインフレームではＥＰＵといっていいかな？）以外の
Ｉ／Ｏ性能（おそらくです）と拡張性（メインフレームは無限といっていい？）
ではインフレームかな・・
使い分けすればいいわけですね。

>>279

メインフレーム vs オラクル+UNIX というのは
構図としておかしいよん。
メインフレーム用のOracleもあるしね。
DBということならS/390に限ってもDB2とかIMSとか色々…

今は、汎用機もほとんど分散機に似通ってきてますよ。
ディスクも最近はＰＣと変わらんし・・。
まあ、専用部品と違うから、結構壊れるんだけど、
その分、何重にもミラーリングしてたりして・・。
速度というと、比べるのは難しいけど、
汎用機の方が複雑なことをできるような気がします。
気がするだけですが（笑）。

メインフレーマーってのは一種独特の雰囲気があるね

>>283

ですねえ…＜ディスクはPCとかわらん
IBMが出してるESSは別に汎用機専用ではないですが，ありゃ
中身的には専用RS/6000x2+7133SSAドロアx8+でかいキャッシュメモリ
であって，中身的にはあんまり…

>>284
確かに，ある意味徒弟制度のある風土で職人的な人が多いかも。
あとUNIX，PC系に対して「分散」「小型」「下のほう」という表現
をする人が多いような。

>>285
RVAも使ってるディスクはESSと一緒でしょ。
でもインターフェイスが増えてるとかそんぐらいしか
変わってないのになんでRVAからESSになってあんなに
使いにくく信頼性が落ちるのかが解らないけれど。

汎用機導入の際、汎用機の開発者達と会ったこと
ありますか？
IBMとか

不毛な議論だな。
いまや、IBM S390でLinuxは動くし、PCアーキテクチャのマシンで汎用機OSは動くぜ。
でかい小さいとか処理の規模とかMTBFとか表面的なことばっか見てるから、正しい選択ができないんだ。
結局は、OSのアーキテクチャの優劣と適材適所があって、そのOSをどんなマシンで走らせるかを考えよ

>>288
>PCアーキテクチャのマシンで汎用機OSは動くぜ
ACOSのはNT上でエミュレーションだろ。
他のまともな汎用機のOSが動く訳じゃない。

ちょっと前は、こんなのあったけどね。
今はどうなってるんだろ。
http://nc.nikkeibp.co.jp/jp/2000/articles/960401.html

>>290
開発マシンに、それ使ってました。
全然問題はなかったよ。
OS2上でのエミュレートだけど。
どっちかっていうとOS2の不安定さが目立ったって感じかな。

289 名前： 名無しさん＠１周年 投稿日： 2001/04/17(火) 03:40
>>288
>PCアーキテクチャのマシンで汎用機OSは動くぜ
ACOSのはNT上でエミュレーションだろ。
他のまともな汎用機のOSが動く訳じゃない。


Free なのありますか？

>>290
「自宅で汎用機OSを動かしたい」なんて衝動にかられる
汎用機ヲタには、最高の製品かも知れない。
専用の370カードが必要で、そのカード一枚がめちゃ高い
のが難点だが...

いつの間にやら、このスレッド延びましたねー。
>>1さんのスレが、いつのまにかメインフレームvsUNIX&PCになったり。。。
確かに汎用機の希望小売価格は高い。でも時には1掛け(1割）で売る事も有る。
それでも高い値段ですな。
>>276さん。
私、一昔前（おそらく貴方が遭遇した時期だと思う）、個人でワークステーション
買ってみました。当時の価格で400万。使いこなせませんでした（藁）

汎用機の世界を渡り歩いて来て、この職場が職人気質なのは確かに認めます。
でも、（知識に裏づけされた）経験が尊重されるのはどこの業界でも同じじゃないですか。
知らないよりは知っておいた方が、何かの時に応用が利きますよ。

適材適所っちゅう言葉がある通り、どっちが優れているとか、取って代われるとかを論じるのは
不毛な論議ですね。

　>>276さん。
　当社でもまったく同じことをやってしまいました。
　バブル直後の「ダウンサイジング」大合唱に載ってしまった幹部は導入後には既にいなくなっている。
　泣くのはシステム管理部門だけ。

　汎用機の稼働率ってまだ頭抜けて高いんですよね。

PCサーバで分散処理でコストダウン!自体は不可能ではないと思うよ。
ただ、現状できもしないのにそれをうたい文句にして仕事受注する
詐欺師もどきばかりなので、導入失敗するのは当たりまえ。

あの糞馬鹿どものせいで、分散コンピューティングそのものを否定
されるのは悲しいなあ。水平分散処理環境構築って楽しい仕事なんだ
よねん。

276です。

>>295さん
どこでも同じような話ってありますね。

>>296さん
否定はしてないですよ。
でも、末端は結局導入する／しないの判断はしないから。
するって決まっているところからくるからベンダーを
選ぶなんて・・できないよ。
見えない力（笑）も働いてるし。
そういった中で、やっぱ分散より汎用機の方が楽だった
って思う人は多いんじゃないかなあ。
分散環境の仕事はやってみたいけど、
手間はかかりそうだよねぇ。

>>296さん。
確かに、水平分散処理環境構築ってイメージとしては面白そうですね。
ネックは分散ＤＢの同期かなー。
完全な水平分散処理は、やはり難しいのでは？
ダウンサイジングでこの辺り苦労された方、居ましたらレス希望します。

＞２８０
全くおなじ６０万件のデータを、Ｄ／Ｂにロードする処理時間を測定
したことがあります。
汎用機　Ｎ○Ｃ製　ＰＸ７５００（２ＥＰＵ）無負荷状態で約２時間
NTサーバ　ＰＥＮ２　６００ＭＨＺ＊２　で約３０分
汎用機はＣＰＵの開発スパンが長いんでつらいですねー。

＞２８３
たしかにディスクのドライブ自体はかわらんかもしれんが、
コントローラ部とばかでかいキャッシュがつけられるとか
他の部分がちゃいます。
同じＲＡＩＤ１でも読み込み処理同士なら、片方づつのドライブ
に同時アクセスできるなんつー荒技もできます。
でも価格はバカたかい。

>299
どこからどこへの・・・
周辺機器の差も考えれるしなんともいえん

大量生産されるパソコンにはH/Wは値段でかなわない
TANDEMみたいな思想のOSで
パソコンを組み合わせて動いて、どっかが壊れてもちゃんと
動くみたいなのがでてくると、汎用機は終わるでしょう

Javaがそうなのかな??

>>302
CORBAまたはRMI/Jiniがわかれば、分散サーバは誰でも作れるぞ。
たいして難しくないよ。必要なネットワーク知識はTCPだけ。

>>302
そういうのが枯れて、業務のパッケージが乗っかるまで
一体どのぐらい掛かることやら…

>> 302

クラスタって知ってますか？ VMSレベルのクラスタがPCで構成できる
ようになれば、かなりの可用性を確保できるでしょう。
＃ いつの話かわからんけど

いまでもPC Unixのクラスタならそれなりのものがあるはずです。

また、アプリケーションサーバでもロードバランシングやフェイル
オーバの機能を持っているものがでていますよね。ま、現時点で
それらがどれだけ枯れたものかどうかが問題ですが。

＞＞３０１
汎用機は、物理ディスク１にある順編成ファイルを物理ディスク２
のＤ／ＢへＲｌｏａｄ
ＮＴサーバは、論理ディスク１（ＲＡＩＤ５）にあるフラットファイル
を同じ論理ディスクにあるＤ／ＢへＢＣＯＰＹ

５年前の汎用機は、そのとき最新のインテルサーバーに比較して
単一jobの処理では、まず勝てません。
（ただマルチjob動作では別ですよ）

クラスタが切り替わる時間が数秒いないになればいいけどね

>>
306
??

>>305
単なるクラスタ接続じゃダメなんですよね。
それだと繋いだ台数分だけ分母が増えて稼動率が下がっていくから。

IBMの汎用機のSYSPLEXみたいな考え方は汎用機以外の世界では
まだまだ思いつかない発想だろうし、そもそも汎用以外のプラット
フォームにはそこまでの事は要求されていないんだろうな。

age

>単なるクラスタ接続じゃダメなんですよね。
>それだと繋いだ台数分だけ分母が増えて稼動率が下がっていくから。

えーと、つないだ分だけ稼働率が下がっていくクラスタってどんな
やつでしょうか。それって何の意味があるんでしょうか。

>IBMの汎用機のSYSPLEXみたいな考え方は汎用機以外の世界では
>まだまだ思いつかない発想だろうし、そもそも汎用以外のプラット
>フォームにはそこまでの事は要求されていないんだろうな。

VMSクラスタはご存知ないですか？
クラスタはそもそも分散処理の発想から来ているので、汎用機の世界
にはなかった概念だと思いますが。

もっとも私がSYSPLEXをよく知らないので勘違いしているのかも
しれませんが。

RISCならイイんじゃないの。

>311
クラスタ接続で分散処理というのは汎用ではあまりやらない（出来ない）です
CPU１個の価格が高いのと現状１個のCPUで充分のキャパシティを持っているから.

超巨大企業が膨大な顧客データなどを持つ様な所だと汎用の高い稼動率を前提と
しながら巨大なデータ量を処理出来るシステムが必要となって将来的に拡張の
余地を考えた投資が必要となります.　そういう場面でのスケーラビリティを考
えると費用対効果がハッキリしている必要が有るんです.

309さんが言う並列SYSPLEXってのは、従来のクラスタリングでは結合スケールが
大きくなればなるほどデータやロックの共有などで結合要素同士を結ぶ部分での
オーバーヘッドが大きくなって行き、増やしたCPUの台数分だけリニアなパフォー
マンスの向上に繋がらない事と、障害発生時のデータの保全性などを高めるために
考えられた一連の仕組みの事です.

訂正、
パフォーマンス向上に繋がらない事への対策と、障害発生時…
と読んで下さい.

汎用機でマルチベンダーってやったことある？

某金融機関だけどやったことあるよ

汎用機の利点、万が一の事態に陥った時の責任の所在が明確
マルチの時はどうするの？

>>317
責任のなすりつけあいです。
イヤ、マジで。

ただ汎用の場合は問題判別と対処の手法がきっちり確立されてるから、
問題があっても対策までの担当者の時間と労力は少なくて済むんですよね。
支援する部隊の数と質からしてもしっかりしてるし。

最近、汎用機向けのソフトウェア販売会社で技術の仕事をしています。
（Ｆｉｌｅ−ＡＩＤとか・・・知ってる方も多いのでは？）
その関係で、現在猛烈に汎用機の勉強中です。
このスレの内容は大変ためになります。生き続けさせたい！！！

日本コンピュウェアさんですね＞３２０
もう少し製品価格を下げてください。

大規模な基幹システムでメインフレームが指示されるのは
ソフトウェアの実績､品質からですか？
または､ハードウェアの信頼性からですか？
それとも､サポート､メンテナンスといった保守の問題からですか？

また､これらをUnix系サーバのシステムと比較した場合の
現状はどうなのでしょう？

ハードウェアの信頼性とソフトウェアの実績でしょうね。
安定性を重視する銀行ではメインフレームですね。
勘定系などのメインシステムがUNIX系というのは日本には
まだないです。(開発中ではあるけど)
UNIX系だと都銀の勘定系のような超大型のシステムも
組めないしね。

ハードウェアの信頼性とソフトウェアの実績でしょうね。
安定性を重視する銀行ではメインフレームですね。
勘定系などのメインシステムがUNIX系というのは日本には
まだないです。(開発中ではあるけど)
UNIX系だと都銀の勘定系のような超大型のシステムも
組めないしね。

外銀はSybase on StarFireだったりするけどね

ＦＩＬＥ−ＡＩＤさんいつもありがとう。ＦＩＬＥ−ＡＩＤ　FOR　ＤＢ２さんも
ありがとう。
なによりＴＳＯさんありがとう。どんなエディタより愛してます。
ＥＡＳＹＰＬＵＳを知った時、パソコンをあまり愛せなくなりました。
汎用機よ永遠に．．．というわけではないですが、安定して便利な
アプリケーションズだけは失いたくないですね。
あ。エクセールさんも愛してます。

現在DB2 for OS/390を使っているんですが、先日、オープン系の顧客との間で
ＤＢ２よりオラクルの方がよりダイナミックに操作が出来、優れているとの話を
私が直接ではないんですが聞きました。
私自身オープン系の経験がなくホスト系のＤＢ２しか使ったことがありません。
だれかＤＢ２、オラクル、サイベース等の違い、各製品の特徴など詳しい方が
いらっしゃったら教えてください。

DB2についてだけ。バインドってなんだー。面倒だぞ。AIXにしかない
操作なのか？

> バインドってなんだー
静的SQLね。
あらかじめ使うSQLをデータベースに登録してアクセスパスを
かためちゃうの。実行ごとにチェックやパスの計画を立てない。
静的SQLのないDBは普通、１回実行するとキャッシュして使いまわす。

むう、「１回実行するとキャッシュして使いまわす」でいいじゃんか。時間が
かかるのは１回目だけだろ。ここがUNIX屋とメインフレーム屋の感覚の違
いなのか。マシン変える度にバインドしなおすの忘れられちゃうの。

別の話だがDB2はオンライン中の再編成ができないな。オラクルは出来る気がする。

> 327

Oracleはダイナミックに操作できるが完了するには相応の
というか当たり前の時間がかかるので、カタログでうたってる
機能は現実的には全く使えないのが多い。
耳障りのいいこと謳ってるだけで、使えた機能ではない。

>>330
キャッシュから落ちたら、性能落ちるだろう。
安定性能がメインフレームの信条。

>キャッシュから落ちたら、性能落ちるだろう。
でも、統計値変えると（DB２だとランスタッツっていったけ）
、オートで再バインドするんじゃなかったけ？
まあ、オンライン中にそんなことする奴いないか。

>>333
設計の段階でINDEX-SCANかTABLESPACE-SCANか解ってるハズだから
そんなのが普段から頻繁に変わっちゃう様なマズイ設計はしないでしょう。
一般的にはRUNSTATSしてもAUTO-REBINDしない様に設定しておいて、
RUNSTATS〜REBINDはオンライン止めて手でやるもんだと思っていますが。

>>289

>>PCアーキテクチャのマシンで汎用機OSは動くぜ
>ACOSのはNT上でエミュレーションだろ。
>他のまともな汎用機のOSが動く訳じゃない。

古い話のぶり返しですが・・・・
PC上で動くS/390エミュレータがあります。（Freeだったと思います。）

エミュレータなので”Nativeでは動かん”ということになりますが、
OS/390(MVS)というメジャーな汎用機OSはPC上で動作可能です。

まぁ、実際のOS/390でもデバイスをエミュレーションしたり、F/Wで
エミュレートしたりして使ってます。
(EMIOやDASD・・・)

Nativeだエミュレーションだという論議も不毛かな・・と思います。
エミュレーションでも必要な分の性能が出れば良い。

ちなみに、S/390エミュの日本語解説ページ
http://homepage2.nifty.com/ohrat/

ＤＢ２バッチで開発を行います。生産性のよいプログラム言語を
教えて下さい

>336
バッチだったらC,C++,COBOLあたりは？
俺はそれ以外で開発しようと思ったこと無いんだけど

>337さん
ありがとう。
汎用機でもＣ，Ｃ＋＋使えるんですか？

あるよ。

そういえばオブジェクトＣＯＢＯＬなんてのもあったな。
どこかで厚生年金のシステムを作ったらしい。

DB2はテーブルごとにキャッシュをきめれるので、
そのチューニングが大事だね。

金融系メインフレーマー客よ、
どーでもいいから障害出たときくらいトレースかけさせてくれぇ・・・
トレースの中のデータ内容なんぞ読む気もせんわ　確かに暗証番号とか入ってるけど
電文を既存のメインフレーム内の処理で暗号化しておかないオマエラがおかしいんだつーの
UNIX系はメインフレームみたいに詳細で単一体系で水ももらさないロギングしないんだからさぁ・・・

こんなことだったら、CPUとアレイ装置追加してでも、
gprofとtcptraceとktraceかけながら
オンライン運用できるようにやっとくんだったなぁ・・・
あはは・・・そこまでやってる基盤UNIXある？？

COBOLのメインフレームは、もう終わらせたい。
すくなくとも２０００年問題で、全て消すべきだった。
３０年まえのアセンブラ崩れのソースにはうんざり。

>>342さん。
>３０年まえのアセンブラ崩れのソースにはうんざり。
ご同情致します。
私、もはやその類のソース見ると拒絶反応起こして神経に支障を来します。
なるべく近寄らない様、注意しております。

age

メインフレームってみんな嫌うけどなんでそんなに嫌うの？UNIXしか
知らない私にはとっても不思議。

メインフレームマンセー！

COBOLが嫌われてるんだと思う。
つーか誰が作ったかも分からんような古いソース一日中修正するのは苦痛だしな。

私はそれで転職しました（藁

レスポンスが遅いからだよ。
スクロールするのに何秒かかるんだ。

すいません。
私はメインフレームとCOBOLマンセーな厨房です。
誰か、逝ってよし！
って叱ってください。

COBOL知りません。よく規模を表すのに何本ていう言い方をするのを不思議
に思ってました。これは1プロセス＝1関数だからですか？

>>348
エディットってパソコンでやんないんですか。

教えて君ですいません。

　　　　　　ζ
　　　 ／￣￣￣￣＼
　　 /　　　　 　　　＼ 　 ／￣￣￣￣￣￣￣￣￣
　　/＼ 　＼　 　／ ｜ ＜
　　|||||||　 (・) (・) | ばっかもーんっ！期限切れの学生おいてくな〜〜　
　　(6-------◯⌒つ｜　 | 　　　　　
　　｜　　　　＿||||||||| ||| ＼＿＿＿＿＿＿＿＿＿＿＿＿
　　　＼　／　＼＿/ ／
　　　　 ＼＿＿＿_／ (っ)

一-、
　　　　 /￣　l |　　　／￣￣￣￣￣￣￣￣￣￣
　　　　■■-っ　＜　 いったんＣＭでーす。
　　　　´∀｀/ 　　　＼＿＿＿＿＿＿＿＿＿＿
　　 ＿_／|Ｙ/＼
　Ё|＿_　| /　　|
　 　　　| У　　|

　　　　　　　　　　γlヾ
　　　　　　　　　　（人）
　　　　　　　∧ ∧ |　|　 ／￣￣￣￣￣￣￣￣￣￣
　シコ　　　(　ﾟДﾟ).|　|＜　やれやれ・・・。
　　　　　　/　　　　|　|ヽ ＼＿＿＿＿＿＿＿＿＿＿
　シコ　　（　）　ﾟ　ﾟ| ⊂川
　　　　　　＼ ヽ川つ⊂川
　　　　　　　 ＼川つ.|
　　　　　　　 （　 　|　|＼
　　　　　　　　|　 |○○ ＼
　　　　　　　　|　 |　　　＼ ＼
　　　　　　　　|　 ）　　　　|　 ）
　　　　　　　 /　/　　 　 /　/
　　　　　　 /　/　　　　 （＿）
　　　　　　（＿）

○＿＿＿＿
｜　 ∧∧　 |
｜　(;ﾟДﾟ)　|
｜占 領 軍|
｜￣￣￣￣
｜
｜

アハハ
ユダ、最高〜♪
　　　　　 ∧∧
(ﾟДﾟ )
　　　　　 ⊂　 ヽ　　　／￣￣￣￣￣￣￣
　　　 　　 　〉 ﾉﾉ~　＜ ラオウもオナラ、プッ！
　　　 　　　∪∪　　　＼＿＿＿＿＿＿＿

　　明　　　日　　　を　　　創　　　る　　　手　　　術　　　の

┏━━┓┏━━━┓┏━━━┓┏┓　 ┏┓┏┓┏━━┓　 ┏━━━┓
┗┓┏┛┃┏━┓┃┃┏━━┛┃┃　 ┃┃┃┃┃┏┓┃　 ┃┏━┓┃
　 ┃┃　 ┃┃　 ┃┃┃┗━━┓┃┗━┛┃┃┃┃┗┛┗┓┃┗━┛┃
　 ┃┃　 ┃┃　 ┃┃┗━━┓┃┃┏━┓┃┃┃┃┏━┓┃┃┏━┓┃
　 ┃┃　 ┃┗━┛┃┏━━┛┃┃┃　 ┃┃┃┃┃┗━┛┃┃┃　 ┃┃
　 ┗┛　 ┗━━━┛┗━━━┛┗┛　 ┗┛┗┛┗━━━┛┗┛　 ┗┛


　　　　　　　　　　　 　　 (⌒Y⌒Y⌒)
　　　　　　　　　　　　　／＼＿＿／
　　　　　　　　　　　　/　 ／　　　　＼
　　　　　　　　　　　 / ／ ⌒　　　⌒ ＼
　　　　　　　　　（⌒ /　　　(･)　　(･)　 |　　　 ∧
　　　　　　　　（　　(6　　　　　　つ　　｜　　　|　￣ヨ
　　　　　　　　　（　｜　　　　＿＿＿ 　| 　 ／　　 ヨ
　　　　　　　　　　　 ＼　　　＼＿/　／　／　／￣
　　　　　　　　　　　　　＼＿＿＿_／　／　／

　 　明　　　日　　　を　　　創　　　る　　　手　　　術　　　の

┏━━┓┏━━━┓┏━━━┓┏┓　 ┏┓┏┓┏━━┓　 ┏━━━┓
┗┓┏┛┃┏━┓┃┃┏━━┛┃┃　 ┃┃┃┃┃┏┓┃　 ┃┏━┓┃
　 ┃┃　 ┃┃　 ┃┃┃┗━━┓┃┗━┛┃┃┃┃┗┛┗┓┃┗━┛┃
　 ┃┃　 ┃┃　 ┃┃┗━━┓┃┃┏━┓┃┃┃┃┏━┓┃┃┏━┓┃
　 ┃┃　 ┃┗━┛┃┏━━┛┃┃┃　 ┃┃┃┃┃┗━┛┃┃┃　 ┃┃
　 ┗┛　 ┗━━━┛┗━━━┛┗┛　 ┗┛┗┛┗━━━┛┗┛　 ┗┛

　 　　　　　　　　　　 　　 (⌒Y⌒Y⌒)
　　　　　　　　　　　　　／＼＿＿／
　　 　　　　　　　　　　/　 ／　　　　＼
　　　 　　　　　　　　 / ／ ⌒　　　⌒ ＼
　　　　 　　　　　（⌒ /　　　(･)　　(･)　 |　　　 ∧
　　　　　 　　　（　　(6　　　　　　つ　　｜　　　|　￣ヨ
　　　　　　 　　　（　｜　　　　＿＿＿ 　| 　 ／　　 ヨ
　　　　　　　 　　　　 ＼　　　＼＿/　／　／　／￣
　　　　　　　　 　　　　　＼＿＿＿_／　／　／

　　　 Λ＿Λ
　　　（ ´∀｀ ） ｿﾚﾊ
　　 　し　し　）
　　　く　く　く
　　　（＿（＿）


　　　 Λ＿Λ
　　　（ ´∀｀ ） ﾅｲﾈ
　　　（　　つつ
　　　/ ／＼＼
　　（＿） 　（＿）

チロリーン♪


　　　Ｐ　Ｏ　Ｎ　が
　　　　　鳥　の　死　体　を
*　　　　　　　食　っ　て　い　た　　　　*
　+:.　　　　　　　　　　　　　　　, 　　+　,.
　　　';' +' "・.,*'. .+　　+ :　　*

　　　　　　　　　 ∧∧
　　　、。., .__　_ （ﾟдﾟ）￣￣｀〜
　　ﾐ=+,,.∠・｀ﾐ　UU￣￣UU
　　　⌒・*’

>>350
一応、ＷｉｎやＭａｃのエミュレータで開発してますけど、そんなにはやくないですよ。
それにしても、アセンブラ崩れのＣＯＢＯＬは凄いですよ。スパゲティ・プログラムとはこのことと納得できます。
まず、３０年前の人たちの思想から理解しなければならないってのが、メインフレームのつらいところです。
信頼性は認めても、新規開発へのレスポンスの遅さ（過去の資産との絡みも含め）は、致命的な欠点と思います。

>>348
TSOにちゃんとプライオリティ与えてるか？

>>348
うちでは１スクロールというかエンターキー押してのレスポンスは０．１秒以下。
ほとんどストレスを感じたことないっす。その昔、９６００の回線経由でしてたときは遅かった。

私はPL/Iで開発やってるんですが、こんなマイナー言語使ってるとこってあります？
いろいろ言語はかじったけどPL/Iって非常に使いやすいとおもうんですが・・・・。

>>362
PL/Iは東京では結構仕事あるみたい。
他の地区はダメ。
スクロールの遅さはＦ通でも5秒ぐらいかかる。
なぜだろう？最近入ったんでわからん。

ローカルにホストがあるならLANとかで接続するからTSOの設定だけ見てれば
いいけど、リモートなら回線を設計する担当者がドキュソな可能性もあるな。

TSOは所詮端末だからとか思ってる奴が多いんだけどSNAって結構データ大きい
からDLCをそのまま流す様な事してたらたちまちネットワーク黒くなるし。

来年からC/Sへ移行するぞ。

この間、某社の汎用機で、

01 A PIC 9(10) OCCURS 10.

のところを、

MOVE ZERO TO A(11).

とやったら、システム領域破壊されて、OS落ちたそうです。
早くなくなれ、くずOS。

ソノ前にコンパイル通らねえよ。スゲーつまらん>366

>>366
それは違うだろ。フォートランやＣじゃないんだから。

>>367
>>368
ちゃんとコンパイルとおって、本番稼働してたそうですよ。
コンパイラで、こういうエラーを検出するオプションを指定すれば、
エラーになります。けど、このオプションを指定するとロードモジュー
ルのサイズが大きくなってしまうので、これまではオプションはずして
使ってたそうです。それがこの事件を機につけるようになりました。
このオプションをつけないと、

01 B PIC X(4) VALUE 1234.
01 C PIC X(2).

で、

MOVE B TO C.

とすると、コンパイルできて、Cには｢34｣が入ります。
（オプションをつけるとエラーになる。）

ちなみに、このコンパイラだけかもしれないけど、

01 D PIC 9(01) VALUE 1.
01 E PIC 9(01) OCCURS 10.

として、E(0)と指定するとDに入った値が読めました。

はあ？
E(0)で、OUT OF ARRAY で異常終了だろ普通。
汎用機はどこのメーカーだ？PPも同じだろうから。

>>369
送り側がX(4)なら入るのは[12]じゃなくて？
もし送り側が9(4)だったら[34]になったと思うけど。

配列範囲外の参照って普通できないんですか？
危険極まりないのは分かってるけど。
いまいｂｍでやってるけど>>369さんのとおり、SSRANGEの
オプションを付けなければ A(0)とかも A(-1)とかもｏｋだぁよ。
ＬＯＡＤでかいけどね。３割増しくらいになるかな？

つーか10バイトずれただけでシステム領域になるなんて話がおかしいよ。

>>372
確かに。何壊したんだろうね。

>>372
同意。なにかＳＥが隠ぺい工作してるんじゃ？
>>396
普通は、デバッグ時のオプションと本番時のオプションは
切り替えるはずです。

>>366
そんなの単なるバグだろ。
メインフレームとかそんな話じゃないだろう。
でも配列の範囲外をアクセスしたんだろうが、
それで落ちるOSってちょっとださい。
つーか、チェックオプション付けろよ。
付けないで落ちたと文句を言うのは筋違い。

メーカーはヒターチだな。

ヒターチは、使いづらい。
ＪＯＢがいつ流れているのか解らなかった。

結局>>369はガセだったのか？
話の辻褄があわないもんな。

　＊＊＊　業務連絡　＊＊＊

情報システム板のローカルルール制定について下記スレにて討論中です。
この板の利用者の皆さんはできる限りご参加ください。
http://mentai.2ch.net/test/read.cgi?bbs=infosys&key=991019015&ls=5
以上、業務連絡でした。

汎用機あげ

JCL 萌え あげ

最近思うのですが、アプリケーションの高度化に開発環境が追いつけていないよう
な気がします。
自分のやっている環境がガチョンなんでしょうかねぇ？
最先端の汎用機業務アプリの開発環境ってどうなってます？

>>382
10年前から変わってないよ。まあ、どうせテキストだからどうでも
いいんだが、grepやfind系の検索、あるいは
エディタのカラーシンタックスなんかは欲しいよね。

>>382
こないだ素人にISPFでREXX書かせたんだけど、わりとなんとかなるもんだよ。
新しい人間もこういうインターフェースに慣れると、PCでメモ帳とか使うより
効率いいみたい。

ＮＥＣをひきあいにだしてる人がいるけど
ＮＥＣって大型汎用機出してるの？

>>385
http://mentai.2ch.net/test/read.cgi?bbs=infosys&key=957734655&ls=50

ＩＢＭのＭＶＳ（ＯＳ／３９０今はＺＯＳ？）しか知らないんですけど
他メーカーさんのＪＣＬとかって、ＩＢＭのとよく似ているんですか？
あとＴＳＯとかも・・・・・。

Ｆ、Ｈなんかはよく似ています。Ｎは全然ちゃいます。

FとHはIに国のいいつけで習いに行った経緯があるからね

今日区役所に住民票をとりにいったが
まだメインフレームのシステムでやってたね。

やはりまだ現役らしい。

>>383
昔ＰＬ／Ｉでgrepもどきを作って使ってたけど、ＷＳに
編集環境を全部持ってきたほうがずっと楽だった。でも、ＭＦから
ダウンロードすると全行８０桁に合わせてスペースが入ってきた。
今はＭＦ使わないからどうでもいいんだけど。

>>388,389
そうなんですか・・・。一度他メーカーのマシンもさわって見たいんですが
なんせ社内システム専門で、外部との接触がなく他の企業やマシンでどのようなことを
しているのかって言う情報が入ってこない・・・。
やっぱだめですね社内ＳＥってのは・・・・。

>>390
外字とか考えるとメインフレーム離れは難しいかも。

大昔、DIPSちゅうのが有ったな〜。
BCLだったっけ。

age

あげ

>>384
>新しい人間もこういうインターフェースに慣れると、

って、ユダヤ人がアウシュビッツに慣れるようなものでしょうか。

>>390
外字を考えたらまずサーバには移行できない。
外字って多いとこでは5000字ぐらいあるからねえ。移行が大変
なので大規模な市役所メインフレームが手放せません。
I/Oたくさんあって早いしねえ。重い処理はほとんどお任せです。
何より安定してることが大切。

大田区では外字を捨てたみたいだね。
「あんたの名前は条例でこう変わります」といって似た違う字にさせられたよ。

>>399
ひでぇな。　固有性という物をなんと考えているんだ？

age

DIPSなんてNTT（っていうか公社）以外どっか使ってたの？

最近外字を正字化とかいって
強制的に置き換えているところが多い
JIS第3というのはどうなったの？

　

AS400あげ

ACOS-6あげ

ＭＰ５８００上げ

ＧＳ８３００揚げ

富士通のシステムでＳＤＳＦに相当するのある？

ＧＳ８３００揚げ

はっきり言って、
メインフレーム系の開発要員に将来はない。
あと、5年後には各社とも
「メインフレーム事業開発縮小。社員1000人解雇」
ってことになるだろうな。
メインフレーム業界の人間よ。
今のうちに違うスキル身につけとけよ！！
自分は切られないって安心してると
取り返しのつかない地獄見るぞ。

＞＞４４１
そんなことはないなー。オープンシステムって意外と欠点多いから。
知ってるお客さんもＤＩＳＫとサーバーばっかり増えちゃって、
汎用機に移行するって。

確かに、メインフレームがなくなるってことは無いと思う。
俺が言ってんのは｢縮小｣てことね。
そして、収入が減るってことは、もちろん
ほかの、例えば今盛り上がってるモバイルなんかの
仕事やってる社員に比べて、
明らかに少ないボーナスで、
年収でがんばらなくっちゃいけないってこと。
社会全体としてメインフレーム導入の企業は年々減少
傾向だってことご存知?
収入は少なくなって人が減るから、そのぶん
生き残った社員一人あたりの仕事は増えるんだよ。
万一解雇を免れたとしても、
社内での肩身は狭いんだよ。
＞４１２

メインフレーム系の開発者は逝ってよし！

>>414
つーかメインフレーム自体逝ってよし。なあ、稲野ちゃん。

あほー。
メインフレーム復権の時代だっちゅーに。

サーバの集中化としてのメインフレームの復権は、理解できるのですが、
Ｃ／ＳシステムにおけるＣＯＢＯＬの復権（？）は、
どうとらえたらいいんでしょうか。

勤め先の別部署で手掛けている、ある金融機関のシステム再構築案件で、
誤差のゆるされない数値計算とかとは何ら関係ない部分で、
また、既存のＣＯＢＯＬプログラムの再利用をするわけではないにもかかわらず
オブジェクトＣＯＢＯＬを利用していて、
それを採用する理由が私には、「既存ＣＯＢＯＬ要員の雇用対策」
としか思えないんです。
もちろん、客先への提案書には、もっともらしい事が書いてあるようです。

とにかく、メインフレーム事業はもうやばいってことね。
各社のメインフレーム担当の方々、せいぜいがんばってください。
年齢いってる人はもう行き場が無いとか？？

メインフレームの仕事が無くなったなら、他の仕事探すだけさ。
マシンに命預けてる訳じゃない。
メインフレームが無くなれば、ほかの何かが同じ役割を果たすだけの事。
ただね、メインフレームにのっかってるPPは基盤からアプリ開発までメーカー純正の
ものが多くて、その分の信頼性はメーカーも保証している。（これは助かります）
これを流行りのマシンでやるとアッチャコッチャのサードベンダーソフトをつなぐだろうから、
構成管理（バージョン管理）が一番シンドイ事になるんじゃない？
どっかのV-Upしたベンダソフトを入れて動作不安定になっても、
他のベンダは
「うちの知ったこっちゃない。」
ユーザーは
「ともかく動かせ。」
そっちのマシン管理者の苦労が想像できるし、そんな能力もないしで、
メインフレームの仕事無くなったら俺は畑換えする。

うちの会社はメインフレームからC/Sに完全移行したが、
システム管理という面からみると、４１９の言う通りすごく面倒だ。
バージョン管理もそうだけど、セキュリティとかもな。

411>
銀行、証券等の基幹システムでも
将来的にはＣ／Ｓへ移行しますか？

420>
移行した理由、きっかけはなんでしょうか？

今、メインフレーム系の開発部署にいます。
実際にどんどん人が減らされて
この人数で保守していくのはどうなんだろう…
と思ってます。

>あと、5年後には各社とも
>「メインフレーム事業開発縮小。社員1000人解雇」

まだ20歳代なので転属になるとは思うけど… リストラかな〜 (T_T)
早めに脱出した方が良いかも

各社って？ Ｉ、Ｆ、Ｈあたりですか？

>>421
きっかけなんて簡単。
メンテナンス要員の募集が難しい
ハード・ソフトの購入費用が高い

・・・管理の手間と障害によって失った信頼回復のコストの方が高いっちゅーに

Σプロジェクト時代の人々って・・・

メインフレーム要員に将来はないのか、、、、
ボーナスもたぶんないだろうなーー。
5年後ろとうに迷わないようにみなさんがんばってね。

＞４２１
各社って、I,F,H,Nあたりじゃないでしょうか。
会社に将来託すより今自分で切り開こうよ。
とにかく転職！！！！！

将来性はまず無いでしょうね > メインフレーム
まあ、転職出来る人はあんまし気にしないと思うけど...

転職出来ない人の割合凄く高いから...(笑

# まあ、自業自得ってことで諦めて下され！

COBOLでプログラム設計するにはOS知識が必須だった。
で、プログラム設計するSEでも理解できるくらいOSがすっきりしていた。
＠しかし、すなわち単純って訳でもない。

　なんかさー、「便利だけどわけのわからんもやもや」がない分だけでも
汎用機やオフコンのプログラムって信頼性高そうだったよなぁ。

>>425

なんていうかさ、NT/2000 しか知らないで十分だって
思っている、最近の一部の若者の将来みたいだよね。

歴史は繰り返す、か。

>>427
残念だかマイコンからメインフレームまで全てを経験しているんでね。

まあ、ＮＴしか知らん若者もそれなりに不幸さ。

ＶＯＳ３マンセー！

メインフレームは、エンタープライズサーバへ

メインフレームのＣＰＵクロックで何ＭＨｚなんですか？
最新のＮＴは１０００ＭＨｚ位ですが。

メインフレームの経験があり、
PCの経験もあるとかだったらSEとして使えると思うが、
いまさら新人にメインフレーム教えるのはかわいそうな気がする。
爆弾をしょわせるようなものだから、
むしろ、そういう部署に行かされた新人って
最初からリストラ要員の予定なのかな。

>メインフレームのＣＰＵクロックで何ＭＨｚなんですか？

メインフレームはCPUよりI/Oの性能の方が重要です。

メインフレームは性能より信頼性の方が重要です。

>431
メインフレームがＣＭＯＳを使ったとき・・同じくらいだった。
ＰＣ用ＣＰＵ（遅いＣＭＯＳ）ではなくバイポーラ使った高速なやつも
残ったので・・
モデルチェンジのサイクルが長いので、少し劣るんじゃないのかな・・
ただ、Ｉ／ＯはＣＰＵを使わずそれぞれ専用のプロセッサが行うので
Ｉ／Ｏ性能限界は高いはず・・

この先5年ぐらいでメインフレーム要員は半分リストラされます。
覚悟しておいてください。

メインフレームとＰＣを比較しようなんて間違い。

>ＣＰＵクロックは何ＭＨｚなんですか？
お願いだから、教えてください。

>>438
600mhz位が標準。でもcpuだけじゃないのさ。

メインフレームのクロック・・・
ＰＣより、相当低いんでしょうね。
でも処理速度は別ですが。
メインフレームの入出力、おそろしく強力だよね。

頼むからUNIXにメインフレーム系OSと同じ機能が見当たらないときに
文句言うのやめて・・・
あと、UNIXにはRACFないからTACFいれたらいーじゃんとかいうのもやめて・・・

ＩＢＭのメインフレームは２８００ＭＩＰＳってあるけど。

http://www.zdnet.co.jp/news/0012/15/b_1214_04.html

１ＧＨｚのペンティアムで何ＭＩＰＳぐらい？

>>442
2800MIPSは複数CPUを加算してるだけです。

ＮＴだって、特別なバージョン入れれば倍々ゲーム状態になるぞ！！！

# ＣＰＵ一杯付けよう ^^/
# 誰がチューニングするのかは秘密！

>>441
お金の計算とかで、RACFとかで保護された世界でやらないと監査を通らない
ような業種も存在するので…。

で、結局今後のメインフレームはどうなるわけ？
どうせだめなんだろ。

既出で言い尽くされた議論ではありますが、初めてこの板に来ましたので

メインフレームへの回帰現象
・ＣＳしたけど下がったのはＨＷ価格だけ
・開発コストが上がってしまった
・システムが不安定
・バージョン管理やシステム維持管理が大変
・システム寿命が短命
・上記を反省してＷｅｂ化したけど、使い勝手が悪くなった
・ウィルスとハッカーに常に怯える運用をしている

と言う事で、メインフレーム本体に億単位の金が掛かっても
総コストは安いと考えるようになった。
特に国内の通信事情が良くなって、分散しなくても一局集中で
運用出来るなどなど・・
異論は多々あるとは思いますが
大規模システムの需要は無くならず棲み分けしていくと思います。

＞メインフレーム本体に億単位の金が掛かっても総コストは安いと考えるようになった。
そんなこたーない。雑誌の読み過ぎ。

ＨＬＬ／ｗｂ使ってるひと〜？

萌え萌え〜♪

>>442

60MHzのPentiumが100MIPSだった。
1GHzなら1667MIPSかな・・

俺、汎用機に詳しいやつで、しかも本当にUNIXに詳しいやつってほとんど見たことないよ

>>452
そりゃ当たり前じゃないの？
メインフレーマーにしろＵＮＩＸオタクにしろ閉鎖的であることに違いは無かろう！

>俺、汎用機に詳しいやつで、しかも本当にUNIXに詳しいやつってほとんど見たことないよ
っていうか、汎用機を熟知している人が少ないの。
メインフレームは完全分業性になってるから、ＯＳやハードについて
しらなくても食っていけた。
汎用のOSに詳しければ、Unixは直ぐ理解できるはず。
ただ、Unixに詳しいっていうのは、コマンドよく知っててシェルすぐ
書けるみたいな意味が入ってるとつらいけど。

>>454
メインフレームはそれだけＯＳが肥大化＆広範囲化しちゃって、一人の
カバーできる範囲を超えてしまっているということでしょうね。
宿命かな。
やはり、ＵＮＩＸも同じ道をたどって行くんだろうな〜。

>>445
突合とか精査なんかはその部類ですよね。

いい情報をリークいたしましょう。
もし、UNIX系で同じ事（RACFによる監査が必要）をやりたいのでIBMにまかせる、
てなことがある場合、
TivoliかCAという会社のTACFていうのを薦められると思うんですが、、、

・あと3年しかサポートしてくれません。
・IBMしかサポートしてくれません
　HP-UXに乗せた場合、最悪動いてる製品全てのサポートを断られることがあります。
　（よくて、有償サポート）
・TACFの監査機構の仕組み上、ブート時パッケージ商品の起動がうまくできないことがあります。
・カーネル、ユーザーアプリ含めて、1本あたり最大20倍ほど処理遅延が出ます
・SMP構成では、CPU枚数が多ければ多いほど、
　CPU間排他待ちが大量に発生してCPUのアイドル時間が0になります。
　CPUを追加しても良くなることはありません。
　（つまり、キャパシティプラニングができなくなります）

以上の理由により、RACFの代わりにTACFを使うくらいであれば、
そのUNIXの開発元が持っているセキュリティツールを導入するようにしてください。

Solarisだと、Trusted Solaris、PAMなんかがあります。

>>454
入ってるにきまってんじゃん。
もちろん、歴史的文化的背景に関する知識も入ってるよ。

汎用機できるやつの中には、それより小さいやつはなんでもできるようなつもりでいる
やつが多いけど、勘違いも甚だしい。

汎用機：うまく行ってたころのローマ帝国
UNIX：ヒッピー全盛期のアメリカのコミュニティー
Windows：今のアメリカのハイスクール

はたして、ローマ帝国の役人がコミュニティーのリーダーになれるか？

>>447
>システム維持管理が大変

ＵＮＩＸのサーバーをポンポン立てるより。
一極に集中させて、、、、ってのは自分も聞いた。

電源管理も大変だし、サーバーが沢山あるとしょっちゅう壊れるし。

>>459
当たり前のこと言っても仕方ないのでは？
分散型の利点欠点、集中型の利点欠点それぞれに特徴あるでしょうに．．．

適材適所の観点を捨てて議論するのはどうだろうね？

汎用とUnixとか言ってるけど、サンのでかい奴とかは
実質汎用機だよ。インターフェースがUnixなだけ。

まともなコンソールがあれば認めてもいいけどね>>461

>460
>分散型の利点欠点、集中型の利点欠点それぞれに特徴あるでしょうに．．．
>適材適所の観点を捨てて議論するのはどうだろうね？
私は汎用機からNTに行って、今LINUXで苦戦中（笑）
どちらも利点があり欠点もあるって実感している、
今しばらくは共存していくでしょう
NTやLINUXが64BIT化とタスク管理の高度化がしっかり出来れば
汎用機は過去のものとなると思います。
UNIXはメーカーの抱え込みで好きになれない、HWも高価だし・・・

TPFはまだまだなくなりそうもないです

>>463
６４ｂｉｔ化とタスク管理の高度化．．．ってソフトウェアだけ高度化してもねぇ．．．
汎用機とＮＴ／ＬＩＮＵＸ機はハードウェアの設計がぜんぜん違うって事を理解してますか？
ハードウェアの違いも含めて汎用機がなぜ「汎用機」と呼ばれのかもっと考えましょう。

>>465
同意。
MTBF 30年はすごいと思う。

>>465,466
その汎用機がシェアで考えると縮小し続けているんですよ。（現実
何時までも安泰だと考える根拠の何と脆弱なことか．．．（笑

メインフレームの堅牢なアーキティクチャを背景に下らぬ反論しててもつまらんよ。
もっと大きな視野で眺める時期じゃないのか？
何処でも通じる技術を身に付けなよ。

>>467
汎用機を擁護しているつもりはないよ。
最新の動向をチェックしてるだけ。
ちなみに汎用機のCOBOL＆昔ながらのオンラインパッケージで
HTTPサーバー＆CGIを実現できるようにもなってるみたいだね。
この構成だとセキュリティーやキャパシティーポリシーを今まで通り
堅牢にしたままWEBサービスが実現できるから結構すごいと思う。
でもこれSSLは使えるのか疑問。。。

どこがサービスやってんの？ 実績は？

>>468
そうそう、なってるなってる。
やっぱし、膨大なCOBOL技術者の再利用は時代の要請でもあるようです。
オープン系でもCOBOL系で何とかしたいツールが出揃い出しましたね。

でも、やっぱ邪道かもよ。

汎用系のアーキティクチャは堅牢で優秀だよね。
そのことはこれからも長所として生き続けると思うんですよ。
唯、これまでと違って人を付けて売る方向は衰退して行くと思うんです。
汎用機と言えども、オープン化して行くんじゃないの？

でも、オープン系の開発スピードについていけないのも事実＜汎用系
オフコンの世界じゃ、オープン系連携製品がぼろぼろ蟲出してるし。

>>471
オフコンはもうダメでしょう。
一時期、ＯＳにＵＮＩＸを使い５年程は生き延びて来たけれど．．．
もう限界でしょうね。

「汎用機」って呼ぶこと自体がもうふるいんじゃないか。
俺としてはあの精緻でこなれた運用環境は依然魅力。
クラスタ構成っていったって、「おちない」ことだけじゃ
ないからな。高いだけのきめのこまかさ、安定感やっぱりある。
装甲車が必要なところもあるわけよ。業務によってはね。

>>473
確かに汎用機って定義、ＯＳなのかハードなのかシステムなのか、わからなくなって
きた。ＩＢＭのＺシリーズなんかみると、「・・・・・・」なんて呼んでいいか。

>>474
汎用機の定義ってチャネルプログラムとかの通信用の
マイクロコードを含めた箱を指すんじゃないかな〜。
つまりハードだけ。
OSはなんでもいいと思う。

オフコンにも需要はあると思うよ。
最近はパッケージで固めて使うのが主流になっているから、
システム自体のメンテナンススキルの無いユーザーとか
人を割けないユーザーとかは選択すれば良いと思う。
とにかく現場での開発っていうのが全くに近いほど無いから、
不具合がでたら、メーカーにパッケージ単位もしくはOSごと
総入れ替えしてもらうパターン。

汎用機のシェアが縮小しているのは事実、
しかし無くなる事はないと自分は考える、

しかし、製造メーカーが無くなる（倒産等）事により、消滅ってパターンが・・・

汎用機は「事務処理」も「科学技術処理」もこなせるから「汎用」と呼ばれたんだよ。
今は科学技術計算に汎用機使う理由はほとんどないけどな。
当時、やっとまともなOSができていろんなCPU中心のバッチやI/O中心のバッチを
組み合わせて流せるようになった。
「汎用」という呼び方はそのころの名残りにすぎない。
汎用性から言えば今のPCのが話にならないぐらいはるかに汎用的だし、
「汎用機」はむしろ時代の中で専用機化していった。

常時２００以上のタスクを平行処理し、
かつ超高速プリンタ６台に吐き出しをしながら、
４デッキのＭＴ装置に読み書きし、
１０００台以上の端末とオンライントランザクションを処理している
我が社の汎用コンピュータに取って変わる
クラサバＯＳとＨＷはいつになったら世の中に出現するんでしょう？

科学演算はＰＣの方が遙かに勝っていますが、平行処理能力と安定性は
汎用機の足下にも及びません。

アインシュタインと聖徳太子を比較するような議論はあまり意味が無い
と思いますが・・・・

>>479
たいした性能じゃないね。

汎用機のオープンＯＳ化もいいけどウイルスに弱くなるのは考え物・・

>>481
便利と危険は比例する。(何時の時代でもね)
だけど、行き着く先は何時の世も発展でしょう？
公開なくして発展なし！

# プライベート情報も同じだよ。(一見すると逆に感じるけどね)

>>481
汎用機ＯＳだからウイルスに強いというより、
汎用機のセキュリティーの多くは、専用線に守られているというのが現実。

汎用機ワームか、面白いかもね。

汎用機ワームはオープンリールから感染します。

汎用機ワームはカードリーダーから感染します。

ワームは自己増殖するだろうが。
それとも、感染した汎用機は次のターゲットのカードリーダに
勝手にカードつっこむのか?

ワームの正体が実は掃除のおばちゃんがオープンリールの上に
置き忘れたピップエレキバンであることは秘密です♪

メインフレーム系の連中ってワームも知らんのか??

>>489
しってるYO、ブラックバス釣るときにつかうやつだろ？

汎用機のワームってどうやって他のホストに感染するんだろう？
全銀手順？（ｗ

CordRedに感染する（実際感染した事実があるかどうかは不明）能力もある
汎用機もあるなりよ

>>492
CordRedは無理じゃん。ラーメンワームならちょっと分かる。
でも、アドレスの取り方とかインテルＣＰＵと一緒なの？
教えて汎用機の偉い人。

>>493
>CordRedは無理じゃん
↓のページの図をみてみそ
ttp://www.sw.nec.co.jp/products/acos/acos-2/sales/index.html

↑うえのＵＲＬは謝り　スマヌ
↓こっちだ
ttp://www.sw.nec.co.jp/products/acos/acos-2/sales/ipack02.html

>>494-495
もしかして、馬鹿ですか？

結局なによ？＞492

>>497
メインフレームでＩＩＳがうごかしてるやろ。
CordRedにもやられちゃうよ。

>>496は厨房だな

>>492 >>498
笑った。IISをどこで動かしているか分かってないでしょ？

結論：メインフレームにCordRedは感染しない

>>499
Ipackegeサーバ機構だろ？
別筐体かも知れんけどメインフレームの一部だろ・・
このメインフレームはＸｅｏｎで動いてるし・・

>>500
＞Ipackegeサーバ機構だろ？
＞別筐体かも知れんけどメインフレームの一部だろ・・

「iPackageサーバ＝WindowsNTを積んだIAサーバ」
なんだから、単なるNTサーバとしてとらえてるよ。

NECのウリ通りにとればメインフレームの一部といえなくもないか。

agw

わがメインフレームは永久に不滅です。byガースーナー

質問です。
わが社では大して大規模じゃないシステムにメインフレームを使いつづけています。
別の環境に移行しない理由は「ライブラリのコンバートに金がかかるから」らしいです。
この会社に未来はありません。私は専門学校出なので大手銀行なんかには転職できそうもありません。
この状況で私はどうやってメインフレームの技術を学ぶ事に対するモチベーションを保てばいいですか？

あともうひとつ、ウチの会社の人に聞いても質問の意味を理解してもらえそうもないので(ドキュメントもなさそう)。
データセット内のメンバーっていう単位はOSが管理しているファイルシステムの単位なんでしょうか？
PC系の知識しかないのでファイルよりも細かい単位っていうのがいまいち理解できないのです。
コンデンスなんて必要だし。

なんかその気持ちよくわかる。
院出て大手メーカーへ入ったはいいが配属がメインフレーム系だった…

オープン系と違って資料が全然ない。
自社ローカルルール、顧客単位の独自システムのオンパレードで
もうウンザリだよ

80年代に作った奴らでこの先もず〜とメンテしてくれよ
ITバブルにまぎれて新卒入れるなって〜 (;_;)
相変わらずどんどん人員削減してるし…
おれにはこんなのメンテできないぞ、する気もないぞ

この先ほんとどうなるの？
都銀だっていつまで使ってくれるかわからないし

いっそのこと都銀が使わないって言ってくれれば
部署移動できるのに

都銀のSEの人っていますか？
もうメインフレームはやめましょう！
こんな状況じゃ この先いつ事故ってもおかしくないです。

メインフレームであるとか別にして中途半端な
大きさのユーザー系技術者は大変不幸なんだと思う。

まあ、待遇が良くてそれで良いって考えならば良いんだけどね。
技術者ならば己を磨ける環境で在りたいよね。

技術者としてはそうありたいですね。
でも技術者じゃなくサラリーマンの方が多いですよね。

>>504
>データセット内のメンバーっていう単位はOSが管理している
>ファイルシステムの単位なんでしょうか？
その通り。ボリューム>データセット>メンバとなる。
データセットは順編成と区分編成があり、区分編成なら
ファイル＝メンバとなります。
こんでんす。パソコンにもデフラグがありますよ。

>>508
待機結合編成もあるぞ！

>>504
通常はファイル内での分類としてメンバーが存在しており、
世代管理や排他制御に良く使われますね。
だから、複数のメンバーを1つして認識したりする命令セットが制御言語に存在するはずですよ。

しかし、古いなぁ

社内システム担当してますが、仕事はユーザ部門の仕様をとりまとめるだけ。
大学も文系だし、システムの知識なんてまるでなし。
なのに、上司からベンダ毎のメインフレームの違いを説明しろと言われてます。
システム担当とは名ばかりなのに。
ベンダに聞いても、企業秘密で教えてくれないだろうし。
日経コンピュータの別冊しか資料がないです。
どうしたらいいのだろう。

良いスレですね。
勉強になりました。

>>510
ユーザー系に居る宿命みたいなもんですね。
コンピュータ関連知識に付いて言えば、オープン系ならば独学も可能なんだけどね。
メインフレーム系となると現行機種以外の情報は無理っぽいしね。

更には、業務系情報となると皆無だしね。

# 独学にしたって使う機会が無ければ習得も怪しいよね。
# ごめん、勇気付けること書けなかった．．．（泣

メインフレームは、永久に不滅です

まぁ、UNIXをいじること=ハカー気取りの厨房には勘定系システム構築の実績を
作ってから言ってみて欲しいものだ。しょぼい参照が中心の情報系を手がけた
だけで思い上がるなといいたいね。

>>514
ダイサンセーでage

age

>上司からベンダ毎のメインフレームの違いを説明しろと言われてます。
聞いたところでどうなるんだ　あほ

>>510
ESCONとACONARCとかその辺の

IBM vs 日立 vs 富士通

の「用語の違い」を一覧にしてみたら？（笑

日立製作所、64ビットのメインフレーム機を発売
ttp://biztech.nikkeibp.co.jp/wcs/show/leaf?CID=onair/biztech/comp/145970

>519

VOS3もこれにあわせて64bit化するよん
Linux系のOSを共同開発(I､F､N)するって話はどうなったんだろう？

７月には三和で昨日は東京三菱でオンラインダウンした
もうシステム(ソフト)の限界だよ 保守しきれない
当時作った人は現場に残ってないし
引継ぎも上手くいってない。
開発現場の人材の質と量と経験が完全に不足してる
この先もう続かないと思う…

情報処理部門を子会社化したり、オペレーターを外注に頼んだり
してる会社は大抵ドキュソな道を歩んでるよね。
で、汎用機の事なんて当然しらないから、使えないだの古いだの
文句ばかりたれて逃げてる。
バブル崩壊後にオペレーター上がりの外注のシステム運用を
切ったところは更に悲惨。
もっとメーカーのSEがちゃんとフォローしてくれればいいんだけど、
基本的なことも知らない自分らでは、向こうが逝ってくる単語の
意味もわかんないから意思の疎通ができない。
もっと研修とか行かせてくれないと本当にやばいよ＞うちの部長！
分かってんのかな〜〜〜(;´д｀)

>>521
ダウンしないシステムなんてあったら驚きだよ。
ダウンしやすいシステムは散見される。
それは殆どの場合がデザインに問題があるんだけど、
敢えてそれを口にするひとは少ない。

例えばMQをオンラインシステムに使うとかね。
あれは非同期でも使えるって事が売りなので、完全に
リアルタイムな処理を要求されるシステムで使おう
とか考える時点でまちがってるって事に気づいてない。

http://www5.justnet.ne.jp/~ttp/

>>523
>例えばMQをオンラインシステムに使うとかね。

激しく同意。
まともな人は、普通は気付くけどね(w

私はas/400系のＳＥなのです。ＳＱＬはわかりますので
オラクルやＳＱＬサーバーなども扱ったことがあります。
昔はＣＯＢＯＬで汎用系のお仕事も致しました。
２年ほど前に某携帯電話のシステムのお手伝いをしました。
マシンはＲＳ−６０００でDB2でした。ＵＮＩＸは初体験でした。、
バックアップツールやパフォーマンス監視とかやたらＩＢＭ以外の
ベンダのソフトを使ってました。当然バグがあるので情報収集とか
が大変でした。ＡＳや汎用だとＩＢＭに頼めばよいので楽。
自分でしたとしても、累積ＰＴＦとかを当てれば解決します。
エラー追及もメッセージが詳しいので厨房な私でもわかりやすい。
ＵＮＩＸ、ＰＣはなんでもかんでも１つのメッセージなのだ。わけわからん。
ある意味汎用機よりもたくさんの要員がいる？気がするのは気のせいかな？

>521
へ〜
６４ビットになっちゃうと、もうVOS3とは呼ばなくなるんだろうね。
きっと３１ビットモードとか作って、２０年くらいはそれが動いてる
ってのが目に見えてくるな〜。
いまのオンライン系ソフトなんか、絶対移植できないもんね。
UNIXは６４にしましょうねって感じかな。

MARK�C愛用者いますう？

>>527
OS/390R.10もそんな感じだよね。
中身は64bitのz/OSとほとんど同一だけど、31bitモードで動かす限り
従来のMVSやOS/390と互換があるという感じの実装だから。

age

>>529
9672で動かしてる限り64bitは無いよ。
64bitを使いたいときは2064を使わないといけない。

汎用系からオープン系の転職はどうすれば出来る？
資格持ってるだけで出来るかな（２５歳）

>>532
できる。勉強すれば。
汎用系の考え方（知識じゃないぜ）は、まだ
十分使えるぜ。
頑張りなよ。

>532
いいかげんな会社にはいると何でも出来るよ。
営業がうそついて仕事とってくるから。

>>534
ｺﾞﾙｱ、夢のない話をするな！！

夢はないが、リアリティはあるな

>>536
まあ、胴衣

>>533
ていうか、UNIX厨やPC厨が「こんなことできるようになったんだぜ〜」と
自慢げに言っていることはメインフレームでは100年前から当たり前の
事だったりすることが多いから笑える。

http://www.speednet.co.jp/

今日も元気だ車をもらおう！

>>538
禿げ四苦童ィ
厨房のUNIX野郎やWIN野郎は、永久に逝ってよし！

先日、IBMがUNIXサーバにメインフレーム技術のLPARを載っけるって宣伝して
いたけど、このLPARって、S/390で使えるものと同等？
マーケティング的におなじものの様にみせかけているだけかな。

同じものでしょう。ゲストOSより上位層ですから。

age

>>538
そうだよね。
Webサーバーはもともとメインフレームで開発されたんだよね。
最近やっとUNIXでも動くようになったみたいだけど。

とあるメーカー系の子会社で新人としてホストコンピュータの仕事を
やらされてるんですが、未来はあるのでしょうか？

>>545
会社の規模によるよ。
IBMなら安泰じゃないの？

あ！子会社でしたか、ご愁傷様です。徹夜の練習が良いでしょう。

都銀のシステム統合が終わったらその後は
ず〜と保守ですか？

入社２年目､まじで配置転換したいぞ…

>>545

とにかく極めてみれば。まだ始まったばかりなんだから。
オープン系だろうと汎用系だろうと、何もやらんで口先ばかり
の奴は何やってもダメなんだから、自分である程度先のプランが
見えてくるまではガムシャラにやってみるこった。
でも、新人なんていうのは、対人関係なんかのコミュニケーション
能力を身に付けることがまず一歩だよ。

>>549
扱く同意。そそ、まだ始まったばかりなんですよ。
新人のガムシャラは、見ていても聞かれても、心地良いもんです。

突如話題がそれますが勘弁してね。
メインフレーム関係でちょっと思うところがあるので。

その昔、某都銀系システム子会社で偽SEやってました。
その時PL/Iって言語をやったんだけど使ったことある人や
おれにPL/I語らせたらちょっとうるさいよ、って人います？

ちなみにその後、COBOLやVB、JAVAなんかもやったんだけど
事務処理系としてはCOBOLよりもPL/Iのほうが優れているなぁと感じました、
個人的にはね。
COBOLのように構造体(Cの構造体とは異なる)がありつつも、ポインタや
ポインタ付き変数が使えたり、プリプロセッサがあってどことなくC言語
のようだし。コメント文の文法もCやJAVAみたい。
結構いいのに世の中ではやらなかった不遇の言語、って印象もって
ます。もちろん今さら新人に教えるものではないけどね。
誰か話にのってこない？

>Webサーバーはもともとメインフレームで開発されたんだよね。

これは本当か？絶対有り得ないと思う。
世の中にWebというものが先にあって、メインフレームがWeb対応したって騒いでるんだが。

本当にごめんなさい。
メインフレームの事がよく解りません。
Yahooで検索してもいまいちわかりません。
なんとなくサーバの中のメインサーバ？という感じを受けたのですが・・・・
それともＵＮＩＸ、ＬＩＮＸＵ、ＷＩＮのようなＯＳの事ですか？

メインフレームって何ですか？

age

>>553
　「汎用機」という文字列を検索しる。

>>552
擬似会話で処理を進めていくっていう方法は似てるけど
CERNではNEXTSTEPで作られたって言われてるね

だれもPL/Iにのってこない・・・
やっぱり超マイナー言語だったんだ
打駄市農

PL/Iは最高です。
自由に記述できていろんなデータを扱えて。
でも、マイナーなんだよね。
なぜなんでしょう？？？
自分にも分かりません。

PL/Iあげ

そもそも、「ぴーえるわん」っていう読み方も知らなかった。
初めて見たときは、「ぴーえるあい」ってよんでました。
ところで、PL/II, PL/III, PL/IV って存在するの？

DL/Iの開発はPL/Iの方がええな。

>>560

もちIBMはそのつもりだったんだろうけど、
DL/IがDB2になったところで（社内でコッド博士がリレーショナル
理論をぶち上げたところで）、その使命は終わったのでしょう。
ただ、その道のりは長い長いものでありました。

因みに、PL/I = Programing Language I

技術者の時間あたりの単価

PL/SQL >>> PL/I

>>552
ネタに決まってんだろ・・・

ヴァカにされる前に訂正しとこう

技術者の時間あたりの「収入」

PL/SQL >>> PL/I

DL/Iか〜
初期のマニュアル
IBMはハイアラキー
日立のADMにはヒラキ（チ？）カル
ってかいてあったな〜

なんか戦前の文学書にはそんな言葉もあったようだけど

>>561,>>562,>>566
DL/Iってなに？
おしえてくんでｽﾏｿ

>>567
NDBだよ

NDB?

>>568
ネットワーク型データベース、と理解すればよろしい？

AGE

ネットワーク型データベースって、項目がビーツリーになるのかい？
で、RDBより便利？

>>572
B-Treeのようなのものは階層型では？
ネットワーク型は、ちょっと違う(と思う＃自信なし)

B-TreeはOracleのインデックスの種類の1つだと覚えといてまちがいナシ！！

ねっとわーく型(NDB)はCA-IDMSや不実のAIM/DBで階層型(DL/1)を少し便利（面倒）にしたようーなもんでしょ。保守はめんどくさそー。B-tree indexのRDBと違ってPOINTERだしね・・まだ使ってるよねM田製作所とか・・

>>573
Ｂ木と階層型は別物ではないかと思われ。
階層型ＤＢはＢ木と違って１ノードに対して枝が
（理屈上は）無制限つくけど、Ｂ木は必ず１ノードに
対して枝は２つまでだよね。

ちなみに銀行の勘定系システムなんかはおそらくどこも
階層型だと思われ。ＲＤＢの便利さよりスピードが命だから

SAILで使ってるｼﾞｪ

>>568
おいおい
DL/Iは階層型DBの典型だよ

IBMのコッド博士がリレーショナル理論を発表する前までは、
データベース・システムは階層型かネットワーク型かという
論争がありました。勿論、両者一長一短あります。
IBMは階層型を採用し開発したデータベースがDL/Iです。
しかし、当時IBM社内でネットワーク型を主張していたメンバー
がスピンアウトし開発したネットワーク型データベースが、
TOTALというデータベースです。（富士通のNDBもネットワーク型）
その後、リレーショナル理論が広まり、IBMがDB2（前身はSQL/DS）
を開発している間に、他のサードベンダはいち早くリレーショナル型
（SQLは実装していない）データベースを世に出しました。
ADABAS、IDMS、MODEL204などが一世を風靡しました。
その後、SQLを実装したリレーショナル・データベースとして、IBMの
DB2、ORACLEが世に出ましたが、実際に基幹業務（あるいは情報系
でも）で使用するには問題が多すぎました（特にパフォーマンス）。
ORACLEはいち早く稼働プラットフォームをメインフレームからUNIX
へと転換し、その後の繁栄は言うに及びません。
ADABASなどもその後SQLエンジンの搭載（エンジンはシーメンス・ニックスドルフ
から買っている）、オープン系へと転換しているが、如何せん
ORACLEの勢いには勝てませんでした。
現在では、IBMのDB2、富士通のRDBIIなどは十分信頼性のある
DBシステムですが、DL/IやNDBの過去の資産が多すぎます。

>>579
現在、富士通はホスト上でもSymfoWareを推進しているようですが、
RDBIIと差はあるの？

>>580
IBMの DB2 ==> ユニバーサルデータベース みたいに
富士通も RDBII ==> SymfoWARE ということで全ての
プラットフォームに対するソリューションとしているみたいです。
でも、どうも富士通はマーケティングがパッとしないように
思います。
製品やマニュアルは良い意味でコツコツ造りましたみたいな
感じがあって、嫌いではないのですが、コマーシャルなんかは
いつも、どこかの二番煎じみたいな感じは拭えません。
組織的な問題なんですかね？

このスレッド、地道ながらも良いスレに育ってるな〜。これからも期待してROMします。

>>582

>このスレッド、地道ながらも良いスレに育ってるな〜。
>これからも期待してROMします。

期待するんならsage進行にするべきではないと思われ。
別に煽りじゃないっすよ。自分も結構楽しみに見てるクチなので
そう思っただけ

>>583
うん、ageるのに異論はないんですが、sage進行で粛々と育つ良スレも良いかと思ってデス。
一頃、ここでもメインフレームかUNIXサーバかでつまらん議論になりかけたしね〜。

>>584

なるほど。確かに以前
「メインフレームCOBOLerオヤジ　vs UNIXマンセー厨房」
って図式になりつつあったからね。
本来、どちらかがどちらかを駆逐しなくてはいけない、とか
そういうものではないからね。使い古された言葉だけど
自分は適材適所とかそういう観点から
「メインフレームってこの先どうなの？」って発言していきたい
と思います。

そうだよあ〜
箸とフォークどっちがいい？
箸はこの先どうなの？って議論して得るのと一緒になっちゃうよな。

age

このままだと倉庫行きになっちゃいそうなので。
倉庫行きにするにはあまりにももったいない名スレだと
個人的に思ってます

１です。
このスレを立てた本人です。

このスレも１年近く経つんですね。
これまで色々と貴重なご意見をありがとうございます。

大学院をでて大手電機メーカーへ就職し
配属されたのがホスト系基幹システムの開発保守を行う設計部でした。

配属後数ヶ月… 今まで勉強してきたことは何だったのか…
これからどうなるのか､正直､かなり悩みました。

当時､新人だった私が絶対に職場では口に出来なかったひと言
｢メインフレームってこの先どうなの？｣

これがこのスレの始まりです。

色々ありましたが…
それでも何とかがんばってやっています。

>587さん

そしてみなさん。 ありがとう。

1さん。
ここで一発、ご自身の１年間くらいの
感想と、このすれの層活してくれたら
ありがたい。
そして１０００レスまで突っ走りましょ。

最近、リプレースじゃない新規の導入の場合、
メインフレームが高級UNIXマシンみたいになっている感があります。
ブラウザのバックエンドになっちゃったり、データウェアハウスになっちゃったり。
純新規のメインフレーム導入で、昔ながらの階層DB(or NDB)にプロプラエタリーな専用端末なんか使わせちゃったりする案件って、あるんでしょうかね？
そんな案件が、よく儲かるんだけど・・・。もう、利益なんか抜き放題。

絶対無くならないでしょ。
安定性とマルチベンダーシステムでのトラブル対処にかかわる時間と
手間を考えたらメインフレームに落ち着くよ。
企業の基幹系のシステムならやっぱりメインフレームだな。
DWHとかSCMぐらいならどうでもいいけどね。

>>591
DWHはともかくとして、SCM止まっちゃったらシャレにならんでしょ。
限界まで在庫圧縮しちゃったら、SCMもすでに基幹であると思うが、これいかに？

>589

１です。

銀行､証券などのオンラインですが､もうしばらくは残りそうです。

下手なミドルやアプリよりの安定して収益が出ているし
黒のうちは会社も続けるみたいです。
でも､この先､誰がどれだけ保守をしていけるのか
みんな不安なのが本音かも？

あれだけのものを新しく作って置き換えるにしても
それだけの人員も予算もなさそう
それに第一､正直なところ誰もやりたがらないといった雰囲気です。

誰がどういう形で幕を引くのか､新しい形に変えてゆくのか
それともこのまま何とか残していくのか

そういう意味で｢メインフレームってこの先どうなの？｣
という疑問は未だにあります。

>1
大手電機メーカに就職してなんで金融システムやってんの？

>>594

え？それってマジでいってんの？（煽りじゃないよ、念の為）
大手電気メーカーと金融システムってめちゃくちゃ密接な関係だよ。
たとえば某都銀の勘定系や営業店システムなんてヒターチだし、
ＩＢＭなんて至るところでシステム構築してるよ。
大手電気メーカーの情報システム関係の事業部は大抵は
金融、流通、公共、産業・・・（あとなんだろ？）って感じに
グループ分けされてそれぞれの業界で飯食ってるって具合だから。

大手銀行で、自社で金融システム開発なんてしてるところ
今時ないですよ。・・・・問題ではあるけどね

>>596
意味がわかりません。

大手銀行で？それとも大手電気メーカーで、の書き間違い？

>>596
意味わかるよ。
自社開発は一部あるよ。

時代の流れはシステム部署をｉｔ子会社化か
あうとそーすだけど。

オンライン自己の際、緊急対応できるのは
やはりそれなりのリソースを自行でかかえて
いるところ。
距離があればあるほど緊張感や使命感、
モラルが低下しがち。
一般論ですまそ。

>594

ＮＲＩとかＮＴＴデータとかイメージしてた？

奴らの方が給料高いのだろうか…
納得がいかん！

新生のcioがこのすれ見てたら
花で笑うんだろうな。
unix、パッケージ・・・
費用1/10。

あれもひとつの道。

無くなる無くなるって言われてるんだけど、
９６７２やＭＰ３０００って結構売れてるんだよね。

>>600
元・都銀関係者です（行員ではありませんが）
新生は旧・長銀なのでいわゆる都銀や地銀といった一般の
商業銀行とは違い、単純な比較はできないとおもいます。

もともと法人メインの業態だし、やっぱり都銀なんかとはデータ量、
トランザクション量もけっこう違うんでしょうかねぇ？
実はあんまり自身ないですが（ｗ

>>602
確かに単純比較はできないけど、
従来の行員ではとてもできない決断
でもある。またベンダーもそんな提案
する勇気がないはず。
他の金融機関でもIndian CIOやお雇い
外人CIOブームになったら勢力図は
いっきにかわる。smbcあたりに一発
起用をやってほしい。

イヤーン、またsagaってる

age

ホント、みんなもっと書け。こっちは情報なし。

最近、SUNやIBMが発表している最新型のハイエンドUNIX機は
彼ら曰く「メインフレーム並み」（何がメインフレーム並みか
は不明だが）とのこと。個人的な解釈としてはメインフレーム
並みの高可用性、高信頼性を誇ること、と認識してます。

んで、じゃあ従来のメインフレームのリプレイス時なんかの
タイミングで実際にメインフレームに取って代わるかって
言ったらそれについてはちょっと”？”って感じだなぁ。

例えば、現行稼動中のバッチシステムがあるとします。
ハードの性能はともかくとして、いったい誰が
COBOL&JCLで運用されている膨大なソースをUNIX用のソース
（たとえばCとか？まあ、COBOLでも一向に構わないけど)
の移植&ジョブネット構築（UNIXについてはド素人なんですが
JCLの代わりにシェルスクリプトで記述するんですかねぇ？）
&並行テストを行うっていうんでしょ？
少なくともおれ（企業の情報システム部門所属）のところには
そんな体力ないなぁ。っていうかそんなことに時間と金を割くなら
利益をあげる為の新システムをレガシーといかにうまく連携させる
かってところに注力すると思うけど。
だいたいこの不況の中、そんな単純リプレイスは経営陣が納得しない
はず。

情報システム部長「社長、従来のメインフレームをUNIXにリプレイス
　　　　　　　　　しましょう」
社長　　　　　　「それによってどんな効果があるのかね？」
情報システム部長「単なる我々の自己満足です。特に利益にはなりませ
　　　　　　　　　ん。まあ、ふるーいスパゲッティコードのプログラ
　　　　　　　　　ムが保守しやすくなることくらいです」
・・・ってなことになっちゃうんじゃ？
ちょっと偏った意見かもしれないけど、誰かマジレスキボンヌ。

一応誤解のないように言いますが、おれは決してメインフレーム
マンセー、COBOL万歳派ではありません。むしろUNIXにリプレイス
してほしいくらいです。でも、実際はどうかね？って思ったんで
こんなカキコしました。
以上、超長文ｽﾏｿ

regattaはHMCがついてるのでメインフレーム並（ｗ

>>607
も、ちょっと私の文脈に沿ったレスつけてください

age

>>606
ってか、私の認識だとメインフレーム＝人(技術者)と共にハードと
ソフトを販売する形態の装置だって意識があります。

# 単にそれだけの違いじゃないの？

>>610
ﾊｧ？606のカキコに対して全くの見当違いの答え。
606も言ってるけど、もっと文脈に沿った答え方
をする勉強したほうがいいね、知ったかさん

>>610は保守／運用がドラスティックに変われるよって言いたいんじゃない？
だったらそれなりに文脈にも沿ってるとは思う。それが効果的か否かってとこ
まで踏み込めればもっとわかり安かったんだろうけどね。
俺は運用形態を変える時に発生するコスト考えると買い手は及び腰になっちゃ
うと思うけど。

全面的にメインフレームからハイエンドUNIXに変更っていうのは時間、
体力的に難しいんじゃないなか？メリットが思い浮かばない。
長いスパンで考えて移行していくってのもあるかもしれないけど…
そんな事やっても開発終った頃には新しい機械は出てくるし意味無しか？
全面的に新しいシステムつくりたいんじゃーってだけではお金と人が
いくらあっても厳しいね

ふと思ったんだけどデカイメインフレーム使ってると、プリントが大量に
あると思うんだけどUNIXで大量に印刷しているなんて事例あるのかな？
200page/min upで5台とかつなげてフル稼働＆インパクトプリンターで
帳票とか。そこらへんの仕組み作るだけでも大変かもね、というより
出来るの？

>613
IBMのZシリーズとかは、その辺狙っているのかも
しれないね。

>>614
ｚはでっかいのは何だかいくらでもでかくできるけどMPとｚだと何だか
中間が無いような気がするのは気のせい？

数年前の日経コンピューターにAS400ﾏﾝｾｰな記事にオオクラ？だかで
system36ぐらいで作ったアプリが2000年問題で見直した時に動いてて
ビックリしましたという様な記事が載ってたのを思い出したが、現行から
アップグレードするのがメンテナンス的にも楽ではないのかな？
新しいシステム作ると落ち着くまで夜もたたき起こされてやなんだよね
徹夜も多くなるし＜ネガティブだらけやね（藁）
まぁ開発は新しい事やって仕事を増やしていきたいかもしれないんだけど
運用から見れば今＆アップグレードで行きたいよ
１からシステム作って行くって言うんだったらUNIXでもオッケー。

>>613
大量打ちでも、メインフレーム用規模のプリンタさえ繋げて、
帳票の種類さえ少なければ大丈夫ですよ。
種類がたくさんあれば、オーバーレイの問題やら、現行の帳票の移行やらでちょっとしんどい。
でも、大量打ちするようなところは、顧客向けの請求書や明細などがほとんどでしょうから、種類も少ないでしょう。
昔は大量印刷していたような大きな会社は、現在は社内向けに大量印刷というのはあまりしてませんよね。

　私がOP時代（といってもつい最近までだけど(^_^; )
運用していたシステムでは電子帳票への移行が進められていました。
OPにとって帳票打ち出しってのは、結構大仕事でして、私がOPやって
いた三年間で実際に打ち出す帳票が30%くらいは減りました。
　電子帳票化した帳票は、バッチが終わると電子帳票用にデータ加工
してホストのデータセットに落ちてくる。
　そのタイミングをみはからってOPが手動でテープ媒体に吸い上げ、
C/S系のサーバに転送してました。移行の最初の方はテープの本数も
一日３〜４本だったけど、日に日に電子帳票化が進み私が異動する
直前には多いときで30本以上のテープが必要でしたね。
　いずれはホストからFTPで伝送する方式にするといっていました。

WinやUNIXでは対応出来ないほどのトランザクション量だと、
メインフレームにしなきゃならないと思います。
その場合、開発環境をWinやUNIXイメージに出来るのでしょうか？
例えば、汎用機-LINUX-Kylixとか。
まさか、汎用機-AS???-COBOL/FORTRAN/PLI-ネットワークDB or ファイル
しかダメってことは無いよね。

age

長年にわたって機能追加と仕様変更を繰り返した
膨大なスパゲッティープログラムを誰が保守していくのか
それが問題かも、誰もやりたくないし、実際にできない。

バブル期の工業高卒プログラマーの賞味期間が終われば
自然消滅するんじゃない？ あと５年先くらいかな？

>>620
フッフッフ、甘いな。
人間、その道に通じればそれなりの玄人職人になれますよ。
かつては頭の中でレジスタ動かしてた人も居った訳でして。
スパゲッティーが無くなるか否かは別として、それを専門にする企業も現れるでしょう。

ユーザはシステムの比重をメインフレームからUNIX系サーバサイドJavaに
移していきたいみたいだ。現在は９対１の比重。

しかし、開発・運用を担当している当社はメインフレーム系技術者がたくさん
いるので、その進行を遅らせたい模様。

>621

ホスト系の人？
最近の新卒はＣ＋＋やＪａｖａでオブジェクトの教育受けてるから
あんなスパゲッティは見たくもないらしい

今後、無くなって行くのがわかっていてどうして
また、一からあんなものを勉強しなおさなきゃならないわけ？

OS/390　AS/400上のWebSphereってなんで流行らないんだろ。
まともに動かないのか？

>624
zSeries でWebSphere動かしたって高いだけじゃん。
メインフレームは、レガシーなものだけ動かしてりゃいいんじゃない？

メインフレーム系の部署なんて保守･運用業務ばっかやん。
配属された奴見るとホント可愛そうだよ。

うちでは、メインフレーム系の部署はとても楽で、仕事中はジャンプ読んでタバコ吸ってられてあとは雑談ですが何か？

フリーソフトで最も使いやすいCのコンパイラはなにですか？

>>627
うるさい。DQNオペレーターはすっこんでろ。

　メインフレームのオペレータって楽そうだったなあ〜〜。
空調完備の部屋でぼさーーーーーーっとしてて、たまに
ジャーナルとかディスクとか運んで仕分けして。
　故障なんかの緊急時でもカスタマエンジニアかシステム
責任者に連絡して終わり。復旧するまで、またぼさーーー
っと見てるだけ。８時間だかの間只コンピュータルームに居
るだけ。１０年前の話だけど、当時結構らやましかった。
どうやったら就職できるんだろ。

>>630
35歳から年金生活が始まるのなら、折れもうらやましい。
みんな後はどうするんだろうね？

>628
それって、当然メインフレーム上の話ですよね。
富士通MSP上で動くものあれば、教えてYO。

　それがＳＥなんだよね。エラーが起きたときに緊急でソース見てるとき意外は楽そう。
俺じゃないよ。俺はそこに手伝いに行っただけ。オペより楽だと思う。だって何十年と動いてるシステムだし。年数回のためにいる人達。30後半ぐらいが一番若くてほとんどが40代。そこにパソコンの設定しに行った。

>627
その無駄な人員配置は、大企業？　公務員？
中小企業や外資系じゃ、その使い方は無いよね。

MSPでフリーのソフト・・・

F社の沼津工場の知り合いに聞いてみるなんてのもいいのかも。

大企業です。しかし公共機関で「SEさん」と呼ばれている。ほんとに、年金生活者が門番や高速の料金所でバイトしてるようです。

MSPでフリーのソフト・・・
MTEDITていうフリーソフトどちらかご存知ですか？
すいません。いま使い方が解からなくて困っています。どちらか
パラメータの説明書お持ちの方教えてもらえませんか？
パラメータの説明書PDF形式とかになっているとありがたいです。

あげちまえ。

メインフレームでCOBOL、
PCだと思えば PowerBuilder

事務処理関係のジジイってどうして使いづらいものが好きかね？
なんで一時間くらいでマジックナンバーバリバリのプログラム書いて
毎月毎月メンテするかね？
最初に丸一日かければ２〜３年はメンテの必要のないプログラムが書けるのに。

本当にお前らには鬱だ。

>>639
そうやってメシのタネを確保しているのさ
わかってやれよ

>>640
メシのタネならいいのだが
奴らは本気だ・・・。

客は後から後から仕様追加を言ってくる。

>>639
PCやUNIXで、C++じゃなきゃと言っている人もおなじ、
いつまでたっても、新しいものと作ろうとも、使おうともしない。
それが若い人だったりしたら将来が怖い。

>551
ちょっとレス古くてごめん。
ＰＬ／Ｉはやっぱ最高です。今まで結構いろんな言語やったけど
事務系ではやっぱり一番だと思います。ＣＯＢＯＬよりかなり生産性は高いです。
ＰＬ／Ｉやっとけば、他の言語を覚えるのも早いです。
関数なんかよく似てるし言語はいっぱいあるし、Ｅｘｃｅｌなんかにも応用きくし・・・。
でも情報処理試験からも消えたし、やっぱマイナーなのは事実、でもＣＯＢＯＬはやだなぁ。

新規物件でＯＳはUNIXなのに開発言語はCOBOL〜
マジ？

>>645
もしかしてＳｕｎＣＯＢＯＬか？
サブルーチンＣＡＬＬのプログラム書いたら
コンパイルオプションの指定がわからず大変だった。
静的ＬＩＮｋだったからサブルーチンをいちいち指定
しなければならなかった。
動的ＬＩＮＫがあれば楽だったのに。（そもそも
ｓｕｎＣＯＢＯＬに動的ＬＩＮＫがあるかわからん）。

その他age

ﾎﾌﾟｰｽﾏﾝｾｰ!!!

HOPPS & JP1/AJS　マンセー！！

これでメインフレームもオープン系サーバも
ジョブ管理バチーリだＹＯ！！

あげ

巨額詐欺の疑いのある、グローバリーについて

掲示板を拝見されてるの皆様、新年あけましておめでとうございます。
掲示板の趣旨とは直接関係ない話で申し訳ないのですが、この世の中では許せない事があります。

http://www.max.hi-ho.ne.jp/sakimono/index.htm

この会社はありもしない儲け話をでっち上げ、巧みに客の財産を聞き出し、全財産を巻き上げます。

２００２年になりましたが、一向に改善する気配すらなく、悪質化は進む一方です。
この会社の営業は世間の皆様の迷惑になっています。

それだけではなく、人を騙して破産に追い込み、騙された人が仕方なくグローバリー社員を
殺人する事件も実際に発生し、新聞ザタになっています。

http://www.mainichi.co.jp/news/selection/archive/200001/24/0124e038-400.html

みなさんもこちらの掲示板に投稿し、悪徳会社に騙される不幸な人が増えないようご協力お願いしま
す。


http://messages.yahoo.co.jp/bbs?action=q&board=8745

また、この書き込みを見て賛同頂ける方はこの内容をコピーしていろんな掲示板に書き込みをお願いします。

新生銀行って基幹系もWindowsなんだってな。

日経Windowsプロ1月号に記事があるそうだ。あるいはここにも載ってるよ。
http://itpro.nikkeibp.co.jp/members/NT/JIREI/20020122/1/

ちょっと引用すると、
Franken氏（注：システム企画部長）は大まかな数字だと前置きをしながら，
「メインフレームで開発していたら3年と300億円がかかっただろう。
だが今回のシステムは，1年と30億円で開発できた」と語る。

だってさ。

ATM手数料無料とか、年利2%の定期預金の原資はこんなとっから
出てきてんのかナ？ただし日系の銀行がこれに追随できるほどの
ノウハウや度胸があるかどうかは？？？だけどね。

どするよ、同士？

年利２％も出すのは、それだけ資金が必要だから。
支店は少ない上に、結構資金量ある。
ついでに、高い金利の金融債がたくさん償還したもんだから、２％出しても以前よりは負担が軽い。
たくさん償還するから、資金が不足気味。
でも、２％も出さなければ金が集まらないというのが問題。
はっきりいって、営業努力足りなさすぎ。
長銀時代の殿様気分が抜けていない。殿様気分だから、だまされてNTなんぞを使うんだろう。
あの規模でメインフレームをさけるのなら、UNIX系が妥当でしょう。
まさに馬鹿殿様。

トヨタコミュニケーションシステムの新人研修は、
2ヶ月間すっとPL1（COBOLを少し）でしたよ....。

>>653

でもさ、なんだかんだ言ったって定期で2%つきゃ、
一般人にとっちゃうれしいじゃん。ATM無料ももちろん。

なんで他の邦銀は真似できない訳？営業努力イコール低金利
でカネを預かるってこと？？営業努力って、コスト改善して
高い価値のサービスを安く提供することじゃないの？

ひょっとして銀行業界って、世の中の常識と反対なんだろうか？
素朴なギモーン。

ちょっとスレからずれちゃったけど、Windowsでも別に障害
出さなきゃいいんじゃないの？現に出てないじゃん。

>>655
その2%の金利は、あぼーんした時に国民に降りかかってくるのだ。
655は郵便局が金利高いといって喜んでいる馬鹿国民と同列。それと、新生銀行は瑕疵担保特約もってるから強いね。これも国民の税金ね。

>>656

じゃあこれからの預金先は、あぼーんすることを前提に選ぶべきなのね？
あぼーんする可能性が一番低い銀行をおしえてケロ。

瑕疵担保特約にしても、そこに使われた税金って、他の邦銀に注ぎ込まれた
税金とどっちが多いの？数字で教えてケロ。

それとさ、UNIX系が開発・保守・運用コストにおいて、Windowsより
優れている点ってどんなとかおしえてケロ。

仰る通りの馬鹿国民ですが、素朴なギモーンナリ。

>なんだかんだ言ったって定期で2%つきゃ、
>一般人にとっちゃうれしいじゃん。ATM無料ももちろん

損が一枚かんで、いる時点で危険なにおいがするけど・・
ヤブーみたいに・・

情報板では金融専門の人は少ないでしょうから、いちおう書いておきます。
2%出せるのも理由があるわけで、
金利の高い金融債が償還して身軽になって、高い利率を提示できるようになって、
いまの金融債に頼ったビジネスモデルが維持できそうにないので、
一般預金を集めるために戦略的に高い金利を提示してるとも受け取れます。
普通の銀行はこれ以上の預金をあまり必要としていませんが、
利付金融債や割引債にかたよっている新生銀行は一般預金を必要としています。
だから２％を出してしているからあぼーんするかといえば、そういうわけでもありません。
金融分野を専門としていない人に、新生銀があぼーんと受け取れるようなことを書いたのは不適切でした。

要は、どこがあぼーんするかなんてわかりません。
はっきりしていることは毎週金曜日の午後は、どこかがあぼーんすることだけです。

>>659

アリガトサン。正直なところ、普通の銀行がこれ以上預金を
必要としてないっていうところには驚いたなぁ。でもなんで
みんな金利が低いと文句を言いながら、利率の高い外銀に
預けないんだろ？あぼーんの確率以前の国民感情のような気も
するが。「赤信号みんなで渡れば・・・」の世界ね。

ちょっと強引だけど、邦銀がメインフレームから大胆に切り替え
できないのも、20年前のアタマしたSIerとかIS部門が、「イヤー
信頼性っつたらメインフレームでっせ。現にどこもそうでしょ」
って思い込んでる部分が大きいと思う。だって現にWindowsの
成功事例があるんだよ。ここ5年くらいのMSの技術の進化をちゃん
と評価する気があるんだろうか？もちろん問題も多々あるけど、
回避しながら低コスト開発・運用できるっていう事実をさ。

マジレススマソ。

他の銀行は現在運用できてるシステムを捨てることはないでしょ。新生銀行は
経営方針が変わったから新システムが必要になっただけだし。それにシステム
の費用は開発だけじゃなくて運用と教育の費用もトータルで考えないと。

>>660
異常がでないときはどのプラットホームもさほどかわんないよ

問題はその後だと思うけど、どうかな？
メインフレームだとその後も何事なく終わるようだけど。

運用が非常にガンだな・・・替えるとすれば。

＞だって現にWindowsの成功事例があるんだよ。

安田火災海上保険株式会社だな。季刊システムをＮＴに痴漢成功。

現在計画中の金融機関の基幹システムは、オープン系がトレンドです。
すでに開発に突入しているところも多いと聞きます。
ただ、メーカーやコンサルは及び腰。
コンサルは責任取るのが怖いし、メーカーは長期的な売り上げ落ちるのが怖い。
でもメインフレームに執着すると、コンサルやメーカーは切られることがあるので、その兼ね合いの狭間でいろいろな話があるわけ。
退役役員が出てきたり、政治家が出てきたり。とにかく役者がそろいます。

ＡＳＰＥＮまんせ〜ＪＳＫＳＯＲＴもまんせ〜
ＳＹＳＴＥＭ−Ｑって言語知ってる人、一歩前へ！

@ASPEN ********** 機能選択メニュー ************************************ ----- *


１ @EDIT 編集
２ @VIEW 表示・検索
３ @TSS ＴＳＳコマンド実行

//STP0D0 EXEC PGM=JSKSORT 00005500
//SYSOUT DD SYSOUT=* 00005600
//SORTIN DD DSN=USRXXX.XXXXXXXX.YYYYYYYY.ZZZZZZ,DISP=SHR 00005700
//SORTOUT DD DSN=&�D0-OUT, 00005800
// UNIT=SYSSQ, 00005900
// SPACE=(TRK,(00010,00000),RLSE), 00006000
// DCB=(RECFM=FBA,LRECL=00121,BLKSIZE=27951), 00006100
// DISP=(NEW,PASS) 00006200
//SYSIN DD * 00006300
SORT FIELDS=(011,004,CH,A,040,017,CH,D) 00006400
INCLUDE COND=(030,008,EQ,C'DDSEXFOG'),FORMAT=CH 00006500
END 00006600
/* 00006700
//SELECT EXEC PGM=Q101, 00006800
// PARM='EXEC(0)' 00006900
//STEPLIB DD DSN=USR1.QLIB,DISP=SHR 00007000
//SYSPRINT DD SYSOUT=* 00007100
//SYSUT1 DD UNIT=SYSSQ, 00007200
// SPACE=(TRK,(00001,00001),RLSE) 00007300
//SYSUT3 DD UNIT=SYSSQ, 00007400
// SPACE=(TRK,(00001,00001),RLSE) 00007500
//SYS100 DD DSN=&�D0-OUT,DISP=(OLD,DELETE) 00007600
//SYS030 DD SYSOUT=* 00007700
//SYSIN DD * 00007800
START 00007900
SYS100 INPUT R121 00008000
SYS030 PRINT 00008100
EQU TBLWRK = 00008200
EQU1 TBLREC = (10)(Z121) 00008300
EQU B = (1)(P4) 00008400
BREAK B1=M11Z04 00008500
SAMPLE SECTION 00008600
SUM B(1)=(1) 00008700

なつかしや、JCL
最後の一人になれば、おいしかも。
世界で一番、利益率の高い
半導体メーカーが、何つくってるか
しってるか？
米軍向けの昔の装備に使われている
ゲルマニュームダイオードとか
ゲルマニュームトランジスタとか、
だとさ。
保守部品として、細々やってる。
他がつくってないので、一人がち。
市場は細るばかりだが、利益率はよい。

NTでもわしらの使うのと、基幹業務につかうAdvancedなんちゃら、とぢゃあ
同じNT？って位、安定度が違います。
そのかわーりUNIX系OS使うのと変わらんコストを覚悟されよ。
ちなみにGCCってあるのかなあ＞メインフレーム

>>668
「あるのかなぁ」じゃなくて
自分でコンパイルしろ(ﾟДﾟ)ｺﾞﾙｧ

なんかＳＰＡＣＥずれちゃったね。スマソ。
ＡＳＰＥＮ、導入当初は遅かったけど、ＴＳＳ見直したら速くなったよ。
どこ直したか忘れたけど。

>>669
おっしゃるとおーり。
ぼくがコンパイルしてもいいんだ（・∀・）

>>668 Linux の使い易さが評価されてるのです．NTでは色々大変．

汎用機はダウンしないんじゃなくて、ダウンさせないでしょ。
UNIXはダウンするんじゃなくて、ダウンしてから復帰させる。
今のとこ。
とりあえず汎用機は残るよね。
でもUNIXでもいい基幹業務も増える。
ウチはUNIXだけど、サーバー・メンテでしょっちゅう止めてる。
でも特に業務には支障なし。
あ！　あたしゃ単なるユーザーですが。

SI系のCSKとか新日鉄、教育機関系では北海道大学とかがメインフレーム版
Linux入れてるけど、一般企業でLinuxを本番でつかってるところあるのかな？
どのぐらいのスペックが出てるとかTCOがどうなだとか知りたいな

unixだとカーネルコンパイル時に決める共有領域サイズとかセマフォーの数ですが
汎用機では意識したことがなかった。
このへんの制限とかはどうなんでしょう。

とりあえず汎用機は数は少なくなっても無くなりはせんだろ。
１日数百万単位の処理をＵＮＩＸにやらせたいとは思わない。
つーか、汎用機自体どんどん安くなっているしね。もっとも
ＯＳの高さには参る。

皆さぁ〜
どっちかつーとメインフレームは
無くなってほしいんじゃないの？
俺はどっちでもいいけど・・

正直な処、安定性だとか信頼性だとかと
のたまうてるけど、無くなってほしんだろ？

違うの？

ミニコンが消えたように　30年ほどで消えるでしょう

これからは、二重化されたサーバと大型のディスクアレイで
システムが構築されるでしょう
サーバも一つの業務を一つのサーバで処理する位の
使いかたになるでしょう。業務が増えれば、サーバを
するのです。

はやい話しが　Tandemとかいうコンピュータの思想や
アーキテクチャを、安く効率よく、簡単につくれるようになるのでしょう。

でもアーキテクチャて死語だね

３０年かかんないでしょ。悪いけど。

いまや落ちずに動くだけがとりえなんだから。
あと、落ちずに動かす体制ね。運用ノウハウとか。いわゆる人間系。これは大事。歴史がある。
でもぼったくりだよね。

１CPUで比べたら低電圧ノートPC程度の処理能力だし、メモリなんて汎用機はちょっとしか要らないし、
ハードディスクはパソコン用のと共通だし（コントローラ部分は違うけどね）、ネットワークに至っては、
UNIX由来のTCP/IPにプロトコルごともってかれて通信制御装置なんて見る影もない（こともないのかなププ）。
プリンタぐらいかね。汎用機圧勝は。でも、汎用機が偉いんじゃなくて汎用機用のプリンタが偉いんだけどね。

汎用機が１台数百万円で買える時代が来た時、自分の価値、発揮できる？


＃ラックマウント３Uの汎用機とか。USB接続のコンソールとか。出来たらちょっと萌える。

厨。

>>679
現状でも「安価かつ無停止のシステム」という要求は高く、それの一つの
回答がフォールト・トレラント・サーバーなんですかね。↓
http://www.ftsconsortium.org/press/010910/010910.html

10年くらいしたら 金融系もすべて オープン化しているだろうね！

しかし、現在新しいビジネスモデルなどといわれている分野が
以外とメインフレームのお世話になる気がしてしょうがない

2010年に楽天が生き残ってたりしたら、メインフレーム上に
構築されているかもよ
(言語は COBOLじゃないとおもうけど)

2chも もしかしたら… あっはは

>>661
　激しく同意。
　銀行も「次はオープンで行こう」くらい考えてるとは思うけど
　体力もないし、あえて今動いてるのを捨てて全面更改する
　メリットを見出せていないんでしょう。
　新生銀行は新たに作らざるを得なかったから、ああなったんだろうね。
　でもまともに動いてるみたいだし、いいんじゃないの。
　他の都銀なんて、ネットバンキングやるにもいちいち紙出さなきゃ
　ならんけど、ここはオンラインサインアップでできるし。
　手数料も大抵はタダだし。
　正直、メインフレームベースで作られた他の都銀のシステムよりも
　はるかに進んでると思うよ。一顧客として見たところでは。
　うっとうしい通帳もないしね。

>>668

　NTの安定性は、バージョンとかよりむしろ使う側の問題が大きいと思う。
　不要なものは入れるな、がサーバの原則なのになぜかNTというだけで
　それが守られないことが多すぎるから。
　基幹サーバにわけのわからんフリーソフトとかベータ版ドライバ
　入れられて、それで不安定になったとか言われてもなー、と
　MSも思ってるだろうね。
　ま、MSのサポートが不十分かつ態度高飛車でムカつくのも確かだけど。

＞＃ラックマウント３Uの汎用機とか。USB接続のコンソールとか。
それはなかなか良いアイデア、ビジネスチャンスでは。
もっとも電算機メーカの汎用機開発部隊はＰＣ部門に吸収され、消滅となり。
そしてもちらん、ＪＣＬなんてものも消滅。

己の技量も知らずオープンだ！オープンだ！と騒ぐのは滑稽に感じるわ。
肝心の優秀な技術者が一体全体どれだけいると思ってるのかね？
右を見れば経験３年、左を見れば経験５年生
実際の業務分析経験に至っては単純なシステムを数例．．．．
で、開発効率は激悪で品質に至っては評価に値しないと来ては最早語るものもなし

そりゃ時間が経てばそんな状況の中でも優秀な技術者も育ってくるだろうが．．
まだまだ先のお話だな。

あんたの言う「先の」時代にあんたが幸せな年金生活者であることを影ながら祈ってやるよ。

こんばんわ。１です。
このスレがここまで続くとは正直思っていませんでした。

相変わらずメインフレームの仕事を続けています。
でも同期がオープン系で華やか〜な仕事をしているのを見ると…
いずれはなくなっていくわけですし
仕事の幅も限定されて正直、会社も仕事もつまらないです。

安定して採算とれてる部署なので
管理職になるならいいのかなって思いますが
でもそれまであるのかな？という気もします。

来月入社の新人がITバブル大量採用の最後だろうと思います。
何人かは配属になるでしょうが…
この先､社内では日陰の道ですね。きっと…
出世はないだろうけど都銀が潰れなければリストラもないって感じでしょうか？

>654
ｵｰ、ｳﾁの会社だ。
てか、俺、来年の新人相手にＰＬ／ＩとＣＯＢＯＬ
教育の講師しなアカンからなあ･･･。

オールドエコノミーな会社は昔から汎用機なところが多いし変えようという
会社も少ないように思うなあ。変える方がメインフレーム上のシステム維持
する方がコスト高くない？SAP？SAP入れてメインフレーム全廃した会社って
どれぐらいあんの？

景気が良くなって金融系のシステムが、メーカー（汎用機）の
呪縛から解かれることを切に希望します。

まだまだ

>>690

禿同!!!

　運用部門からいきなり開発部門へ異動し、今遅ばせながら、ＰＬ／�Tの
勉強しているけど、今後役に立つのかが非常に疑問に感じております。
運用側に立っていた面からしても楽な運用であって欲しいし、トラブル対
応のしやすいのが理想なんだけど、今のシステムを一気に換えるというの
は大変に体力を消耗することもわかっているので・・・。

↑
役に立ちません

ベンダーは協力して、S/390かzSeriesのLinuxにサーバー統合し、不況に苦しむ
金融機関をしょぼい国産メインフレームから救い出し、日本の金融危機を救って
ほしい
IBMが駄目ならSun(というかCTC)のやってるメインフレーム・リホスティングでも
いいぞ〜

>>694

　あんたはIBM広報か。

　国産のメインフレームはそんなにしょぼくないぞ。しょぼい部分は
あくまでもプログラムミスやジョブリリースミスなどの人為的なとこ
ろでの部分が非常に多い。Linuxがメインフレームに浸透することなん
ておそらく１０年は先の話、もしくはもっと先の話だぜ。決して今の
メインフレームのＯＳが使い勝手がいいとはいえないものの、そう簡
単にはOSが落ちないことやシステムの移行にどれだけの体力・費用が
いるのか十分に理解してから論ずるべきではないかと思われ。

　ワークステーションの感覚ではメインフレームは維持できませんか
らね。

>>695
> Linuxがメインフレームに浸透することなん
> ておそらく１０年は先の話、もしくはもっと先の話だぜ。

禿洞。
今この時点で、システムを Linux に全てリプレースするという銀行が
現れたら、漏れはその銀行から全部預金を引き上げるよ。

>禿洞。
>今この時点で、システムを Linux に全てリプレースするという銀行が
>現れたら、漏れはその銀行から全部預金を引き上げるよ。

総額15円くらいなのにエラそうに良く言うＹＯ！

数十年という年数を掛けて開発してきた
COBOLプログラム数百万行、
年間数十万枚を印刷する帳票及びそれに耐えうるプリンタ、
膨大な量になっているデータベース

これらをメインフレームからLinuxへ移すだけの、時間・金・人は想像もつきません。
そもそも、Linuxで動かせる高速なプリンタが無い（高速って1秒間に何枚かわかる？）

なんかサンのサーバーって高くない？

700GET

>>698
例えばXEROX9700なんて、めちゃくちゃ早いからねー。

そもそも、そんな高速なプリンタで大量打ちしようという考えが古い。
郵送物以外は印刷する価値無し。

古い＝ダメ　かよ・・・技術者が聞いてあきれるな

耐えれる＝スピードだけでればいい？・・・そんなんじゃだめなの

銀行とかじゃなくても、
ちょっと大手の企業の物流センターですら午前中に一日1000枚は伝票印刷やるんだぞ
たった一枚の紙が詰まるだけでも作業は止まる　−　印刷とは、工場のラインのようなものなんだ。

詰まったときはその原因の迅速なリカバリー、
原因がとりのぞけたあとの、続きからの印刷の整合性。
「プリンタの電源入り切りしないとリセットできないかもしれませんね・・・
　１，２枚飛ぶかも」
なんてのは論外です。
事務センターや物流センターの帳票は、ラインを動かす制御信号に等しいんです。

古いから不用　高速なデバイスが最近あるからいい　そんな次元じゃないんだ

東京に住んでるとわからんかもしれんが
世の中紙でないとうまく伝達できない地域がまだある。

S/390にLinuxを載せる最大の利点は、MVSのリプレースなんかじゃない
そう思っているヤツは頭を豆腐にぶつけて暫く考えた方がいい。

「Linuxが動作するプラットホームでハード信頼性の一番高いもので
　クラスタリング裁量幅の大きいものはなんだ！！！！」

という問いに対する答えとしてのLinux on S/390 だ。
Linuxの普段得意としているWeb系基盤としてのS/390だ。
（要はWebなんぞホスト集中とかわらんから
　先々負荷分散しなきゃエンタープライズ業務のフロントエンドできないでしょ？
　でもLinuxベースだから開発の立ち上げの早さはいつも通りでいいんですよ？
　ってこった）

それ以外のソリューションに「近」未来を描く力などあるものか！！喝！！

>>703
>銀行とかじゃなくても、
>ちょっと大手の企業の物流センターですら午前中に一日1000枚は伝票印刷やるんだぞ
>たった一枚の紙が詰まるだけでも作業は止まる　−　印刷とは、工場のラインのようなものなんだ。

おいおい、都銀とかの帳票印刷量は1000とかそういうオーダーじゃないぞ。
文字通りけた違いだ。ただ、なんでも紙に出せばいいというものではないから
印刷量が多ければ偉いってわけではないけどね。
しかしながら、切り替えの体力も相当必要だろうし、なにより
金融機関なんかだと、法的に紙媒体でないと認められない法定帳票なんかも
結構あって、なかなか融通がきかないのです。

見たことある人ならわかるだろうけど、銀行の電算センターなんかの
基幹業務用プリンタってのはそれこそ輪転機みたいなもんだYO。

まあ、基幹業務用プリンタも高性能な部類になるとオープン系では結構しんどいね。
だけど現場では日進月歩で開発が進みつつあるのも事実なんだわ。

>>705

>見たことある人ならわかるだろうけど、銀行の電算センターなんかの
>基幹業務用プリンタってのはそれこそ輪転機みたいなもんだYO。

　補足として（どこの金融機関でもほぼ一緒だとは思うけど）

金融機関での帳票は数年前に比べればかなり電子化もされており、
ジョブさえ走らせれば、営業店・事務センタに伝送で送られ、そ
ちらのほうでレーザプリンタなんかで帳票出力が可能となりつつあ
り、電算センタでの帳票出力量の削減にはつながっています。

　このシステムのデメリットは

　・あくまでもA4・B4サイズの共通用紙（つまり白紙のみの奴）
　　のみで、制定帳票まではコスト上厳しい

　・回線も高速なわけではないので、条件すべを満たすての帳
　　票がこの手段ではできないこと（緊急を要する帳票のみが
　　セオリーかと思われ）

　結局、制定用紙や数万・数十万ページの大量帳票については電
算センタで出すパターンが当たり前だと思います。

　しかもデータ量は日によって違うのは当たり前だけど、帳票
発送に関しては時間が固定なのでどれだけ大量であっても、そ
の時間帯までには必ず出力しておかなければいけない条件下を
加味すると、いかに高速かつトラブルの少なく、リカバリーの
効きやすいシステムが必要か一目瞭然のはず。

　このようなシステムだと、Unixマシンなどではi/oが追いつい
ていかない・ＯＳのフリーズの可能性もあるので、基幹業務規模
はやはりメインフレームでないと無理ではないと思うのだけどど
うでしょうか？

　媒体からデータをもらって手直接プリントするような中小規
模の帳票出力だとUnixなどを使っても問題ないかと思うけどね。
（昭和機械がそういったようなシステム出していたような気が）

仕事としてメインフレームに携わっている方からの書き込みが多いので驚きました。

プリンタとは少し異なるのですが、みなさんの所はどうしているのか教えてください。
みさなんのシステム内には膨大な量の外字が組み込まれていると思うのですが、
最近の電子政府構想にともない、漢字を簡略化する動きがありますよね、
JIS規格を見直しし、新たに第四水準まで作成するとかどうとか。

現在、帳票の電子化を進めて行くうえで、上記の理由によりJISコードが変更なるのでは？
との懸念があり、思い切った帳票の電子化を行えないでいます。メインフレームだけでなく、
UNIXやWindows等の電子機器全般にわたる問題だと思うのですが、みなさんの所はどの様に
しようと考えていますか？
法律も絡んできそうだから難しいと思うのですが、ソースは総務省かどこかにあったはずです。

メインフレームのセールス
一昨年：同じ事がPCでできるのにまだ気が付いていないのか？
　　　　かまわん、メインフレーム売っちまえ！
昨年：　「UNIXやWindowsでもシステムは構築できます。実際に
　　　　　弊社でもそのような構成で提案する場合もございます。
　　　　　ただし、今回の案件では総合的に見てメインフレームを
　　　　　お勧めいたします．．．」
今年：　ヤベー、去年メインフレーム売った客、システム更新提案依頼
　　　　だって。いまさらうちの会社がUnixやWindows売れないし、
　　　　メインフレームじゃ乗せるパッケージないし．．．
とまあ、メインフレーム売るのはベンダー側の都合ですね。だって単価が
１桁、２桁違いますし、これで最後売れたらラッキーて感じ。

勘定系など大規模オンラインはやや事情が異なりますが、やはりベンダー側
の都合と思います。「汎用機で行けるところまで行く！」

http://headlines.yahoo.co.jp/hl?a=20020321-00000201-yom-bus_all
相変わらず良くわからん内容の記事なんだけど、IBMと不治鬱の間でメイン
フレーム開発を統合するってことか？

ﾒｲﾝﾌﾚｰﾑは今後も廃れない。

ただ、未来ある若者が汎用機系ｼｽﾃﾑの配属になったら・・・
ただ憂鬱感のみが漂うことであろう。

結局、人件費じゃないかと思います。
現在メインフレームを使っているところが、UNIX系サーバー、
ワークステーションに移行できたとしても、それまで運用、
保守に携わっていた人がそのまま続けられるわけではないし、
ましてCOBOLからJAVAへ言語も移行なんてことになったら、
一人あたりの人件費が５万ぐらいアップするから、余計金が
かさんで仕方がない。
C/Sが出て来てからいつ汎用機がなくなるかと楽しみにしてたけど
いまだに、エミュレーターどころかDAM端末が残ってるのを見ると、
ほんとに憂鬱になります。

SIerに勤めてますが、ﾒｲﾝﾌﾚｰﾑ部署に配属になった新人は
大抵ヘコむね。

いっぺんどこものとよすにいっておしごとしてみてくだはい。
すなおにはんようきいれれば？っておもうから。

汎用機が主流の時代からの汎用機SEです。
友人にはコンピュータのプロと思われていましたが、あるとき仕事の内容を
話したら、
「ヘー、ずいぶん特殊なコンピュータやっているんですね。」
と言われました。率直な感想です。
汎用＝特殊！です。あとPCのCPUが２GHz、ディスクが１２０GBの時代に
今さら「（超）大型機」とも威張れないしね。

レイゾウコみたいなキョウタイに(I/O以外は)パソコン程度の処理能力だからね。
あとは問題判別がやりやすいとかあるけど。
判別しやすくて嬉しいのってメーカーだよな。

最近、使わなくても良い立場になったので性能のことは良くわからんが、汎用機
はなぜあんなに高いのだろう。毎月のリース料金見るたび
これ1桁間違えてんじゃねのか？と思う。

ハードの保守屋から言わせてもらうと、メインフレームの安定性は半端じゃ無い。
っていうか、オープン系壊れすぎ。もしユーザだったら２重化３重化しようとも
使おうって思わない。
後、オープン系は障害部位の指摘分解能低すぎ。

信頼性重視の金融、リース、保険、官庁なんかはまだまだ
メインフレームだね。
中小企業だと、お金ないから買えないけど。

>>718
ソフトウェアの種類自身少ないから比較できないはず。

過去を知ることは、未来を知ること。是非みんなで感動しようYO!
http://www.nhk.or.jp/projectx/yokoku/yokoku.html

みづほのＤＱＮなＲＣって、メインフレームなの？

んなところにそんなに高いコンピュータは使わんだろう
プライムパワーかRS/6000(最近はpシリーズというのか)じゃないの？
しかもドキュソなのはハードじゃなくてプログラムだ。
なんでも店番号の変換がバグってたらしい。

>>723
即レス感謝。
でも、ＲＣって、イターチじゃないん？（↓さんしょう）

http://mentai.2ch.net/test/read.cgi/infosys/1017649519/l50

111 ：非決定性名無しさん ：02/04/06 22:51
>>109
　新聞の内容。変だと思わないか？
　興銀が受け持つコーポレート系のシステムで一本化するってのは、銀行の
商売上、どうも変だと思うが・・・・・。
　だから、銀行を繋ぐシステム。所謂、外部接続系のシステムの問題だと思
うが・・・・・。それだと、日立のはずなんだけどなあ〜。。。
　ご存知の方、いるかな？？？

>>724
うん。目立って聞いたYO!

>>724
勧銀を富士の間のRCはイターチじゃないYO!

>>726
そうなんや。詳細きぼんぬ。

ニュース・サイトをあちこち検索すると
　当初、勧銀&無事通に統合が決まっていたのを、面子第一とする残り2行の
　システム部門が抵抗し、それに癒着して莫大な保守料の甘い汁を吸わん
　とするメインフレーマ営業部隊が暗躍、果ては中傷合戦まで繰り広げ、
　その辺は独禁法と競合メーカーつぶしで鳴らした愛撫エム&富士銀の
　強引な抵抗で
　・リテール分野（個人・中小企業向け取引）　勧銀　　無事通
　・ホールセール分野（大企業向け取引）　　　興銀　　イターチ
　・投資信託システム　　　　　　　　　　　　富士銀　愛撫エム
　のお粗末なマルチベンダー・システムに。
　そのイザコザのせいで無事通と愛撫エムの接続部分の開発が
　遅れに遅れて見切り発車であぼーん
ということらしいねえ。
トラブッたリレー・コンピュータのH/Wはわからんけど、アプリは
愛無エムお得意のEAIツールMQじゃないの？

3銀行のシステム部門とその癒着ベンダーが、責任の押し付け合いと
次の商売獲得のため、互いの中傷とマスコミへのリークやりまり。
サイトによっては「主導的立場にあった無事通のチョンボ」
「ＳＩの統括やってたイターチが無能」だの、メーカーと
お付き合いのあるサイトや記者によって犯人バラバラ。
愛撫エムが悪いって記事が見当たらないところからして、
リーク元は愛撫エム？いやいやメインフレームのリプレイスを
狙うSunやMSが記事をかかせているのか？
業界関係者としては、犯人探しの行方が楽しみ

「みずほ」に興味があるのはわかるけど、その犯人探しは少なくとも
このスレとは別だろ。

>>728
MQじゃ、同期がとれないーよー
完全なリアルタイムじゃないと勘定系同士の連携はムリでは？

勘定系→情報系（DWH等）ならMQでつなぐ実績をこの目で見たこと
あるのでありえる

ＡＴＭ障害の原因は明確。旧第一勧業銀行と旧富士銀行をつなぐリレーコンピュー
ターと呼ぶ中継器のプログラムに生じた不具合だ。旧1勧の基幹システムは富士通
製で、このリレーコンピューターのハードも富士通が開発・製造した。
http://it.nikkei.co.jp/it/foc/index.cfm?i=20020409t1000t1

ＩＢＭメインフレームのシステムで財務システムを構築・運用しています。
言語はＣＯＢＯＬ、ＤＢはＲＤＢ。
今度、関連会社へ財務システムを導入するのだけど、費用が高いメインフレーム
を導入できません。
上からの指示は、安いはずのｕｎｉｘをいれて、ＣＯＢＯＬを移植せよ！！

こんなｕｎｉｘにＣＯＢＯＬで財務などの基幹系システムを導入している
ところってありますか？？

めちゃめちゃ不安なんですけど・・・・

>>733
規模にもよるけどAS/400の方が安全確実なんじゃない？

↓これ出張32が自分の非を認めて謝るまで毎回書くことにした。
あと、信者絵＞出張３２

＞＞734 朝から不毛な書き込みご苦労さま。今日も粘ついてるねー

>>735
なぁーんだ。出納32さんか、出張32なら無視するとこでした。
ねばっこさな誰にも負けん。
かな？（藁。忍耐力養う為に頑張ってみる事にした。

↓これ出張32が自分の非を認めて謝るまで毎回書くことにした。
あと、信者絵＞出張３２

まぁ遅かれ早かれ汎用機は無くなるよ。（俺は困るけど）
しかし俺の様なヤツが世の中にはごまんと居る事を考えると、そら恐ろしい・・
何故ならそいつら（俺も含む）が職にあぶれると今の世の中もっと深刻な不況が
始まるだろ？そうなると情報処理産業は安泰とか思っていた俺の様なヤツは
この業界しか知らないから何も出来ないだろ？、結果ホームレスって事もあり得る。
何故か業界は景気が良いのに汎用出身の人は職が無い。
そして世の中の人は「やる気が無いんじゃないの？」とか景気が良い業界にも
関わらず仕事が無いとは「能力がよっぽど無いんじゃないの」などと言われ
余計にやる気が失せる。
う〜ん考えたくねぇー恐ろしすぎる。
今からやっても遅いかもしれんが何もせんよりマシか、、勉強しなければ・・・・

ちなみに俺は現在３６歳・・・勉強して間に合うか否か・・

> ちなみに俺は現在３６歳・・・勉強して間に合うか否か・・

これまでの貴方の技術者としての生き様によると思われます。

＞７３７
がんばれ！その心意気が貴方を変える。

４０歳で勉強して現場で頑張ってる人もいるよ。
ただ、汎用が一番と言う気質は捨てた方が賢明だと思うよ。
優れている面は確かにあるのだけれど現場としては汎用の人達が
この業界を悪くしたと思いこんでいる人達が多いから。
とにかく明るく行こうよ。（暗いと嫌われるよ）

昭和の哀歌でこんなのあったな、そういえば・・
あかるくぅ〜あかるくぅ〜

>>737
それでは今後、誰がこの巨大（汎用機）なシステムを保守していくのかな？
これらを保守出来る人間はそうそう居ないと思うぞ。
なにしろ一筋縄では行かないから。

無くなると思う人はそう思えば良いし、存続していくと思う人はそれで良いと思う。
勿論どちらに転んだとしても誰の責任でも無いし信じた自分でそれらを
感じれば良い事だろ？
世の中の可能性がどこまで現実になろうがＳＥ（システムエンジニア）は必要なのだ
※ここで言うＳＥとは業務に精通しそれらをシステムに応用可能な人を指す

いわゆるテクニカルエンジニアでは無くＳＥが欲される時代は不変だろう。
そしてそこに到達しないＳＥもどき（プログラマーの延長）の様な人達は
汎用、その他に関わりなく間違いなく淘汰される。

安い汎用機もあれば、高いUNIXワークステーションもあるんだし、
ディスクにCPUが付いてるのは汎用機だけだし、
ナンデ無くなると言うのか分からない。
少なくなる、とかなら分かるけど。

あの複雑な業務要件をシステム化するには汎用機は必要不可欠と思われ
複雑なモノを複雑に作ったのではシステムと言わず
複雑なモノをかみ砕いて一般的な水準まで落とす場合、機械資源と人の能力が
とても必要になる
それを実現するには汎用機が必要なのだ
お客の立場にたてば一目瞭然だろう
>>737
俺は逆にＰＣでの作業しかした事がなかったので汎用機を使用した
業務知識が非常に複雑で難解な事に改めて驚かされる

>>743
ディスクサーバーはＣＰＵ付きですが何か？

>>743
いまどきオープン系、汎用機関係なく同じSANにつないでいる時代に、まだこんな
こと言ってる頭の古い人がいる・・・。
こういう人が使っているから汎用機って時代遅れの恐竜なんだと思う。

そうなんだよなぁ
２年前に外資系メインフレーマにオープン・システム作るのを手伝ってもらったけど
高可用性を実現するためにすごくお金がかかったので、
「オープン系ってやっぱり駄目ですね。メインフレームのほうが安いな」と、
そのメインフレーマSEに言ったら
「メインフレームは保守料だのなんだの名目をつけて費用を回収するシステムが
確立しているから安くみえるだけですよ。逆に『オープン系は安い』という先入観が
あるから高可用性システムにするとトンデモナク高価に見えてしまう。メインフレーム
維持なんかにかかっている人件費なども合わせて計算してみてください」
とボソっと言われた。
２年たった今、再計算してみると総コストはメインフレームのほうが恐ろしく高い・・・。
メインフレームには先はないのか？鬱だ・・・・。

>>746

うむ、その通りだと思うんだな。

取りあえず、メインフレームに依存しすぎると
ミズホみたくなるし
でも、信頼性考えるとメインフレームが必要な部分もある。

メインフレームも含めて
きちんとネットワークでつないで行く
両方の良いところ会わせて行かないといけないから
こんなこと議論しなくても良いのでは？

メインでも

今年の２月以降に製造された RX-2001 が、
たったの 9700 円！？↓
http://www.bidders.co.jp/user/1023585

買おうかな。

世の中のシステムと呼ばれる仕組みは技術者の為にあるわけでは無く、
顧客の要求する機能が反映された仕組みであれば顧客はそれで良いのだ。
故にコンサルティングでも無い人間が企業の何たるかを論じるのは
甚（はなは）だおかしい。
今、何故メインフレームなのではなくお客様がそれを望んでいるのであれば
それで良い。
また実現可能か否か判断がつかない場合、大抵はその筋のコンサルティング会社に
依頼するだろう。残念ながらここで書き込みをされている人には間違っても問い合わせを
するとは到底思えない。ましてや汎用が云々・・オープン系がうんぬん・・
顧客が望むのはコスト・信頼・スピード・パフォーマンス少なくとも
最低これだけは満足させなければ、何が汎用、何がオープン系だ
馬鹿馬鹿しい。また書き込みしている方々も本当に図々しい。

>>750
＞今、何故メインフレームなのではなくお客様がそれを望んでいるのであれば
＞それで良い。

むせきにーん、だよなぁ。。。
不可視な問題を自覚してる人間が声を上げることなく、ややすればそれを黙殺するのって
まさしくミズホなんだけど。

って７５０は厨か、これは。

あと、上流工程に食い込んでいるＳＥもここにはいるだろ（推測）

>>750

つまるところ
100万円で作れるシステムがあってそのこと知ってても
客が無知で、一億まで出すといえば
そっちを売っちゃえって事だよね？

技術屋がそんな思想だから
CSとかそう言うのが声高に叫ばれるんじゃないの？
きちんと技術屋もサービスという意思持とうよ。

お客様によっては政治的な意向または自分達の本音を我々に話す事が出来ない
事情がある場合がままあります。故にお客様の意向を無視して自分の欲求を押し通す
のはに問題があります。（これが図々しいと言ってるのです）
少なくとも自分達の知識は絶対では無いし、ましてやお客様の所でのお客様が把握しない
タイミングで試そうなど、もっての他です。（仮に予算があっても）

>>750
技術屋の意見を無視して自分達の要求を押し通す顧客の方が圧倒的に
多いと思うが。。。っつーかナニが言いたい？

>>753
申し訳ない。書いてる内容がワカンナイ。
（故にはどこに掛かる？下２行の主語は何？）

>>755
激しく同意
>>753
結局、なにが言いたいの？
>>750
顧客の事を考えるのも良いが、自社の利益のことも考えてよ。
もし、自社が抱えているシステム要員がメインフレームのほうが多ければ
メインフレームでの提案になるし、オープン系の要員であれば、そちらに
行くのではないの？問題の切り分けは、要員の教育がシステムのカットオーバー
に間に合わなければ、意味が無いのでは？一番良いのは経費をかけず
コスト・信頼・スピード・パフォーマンスを実現することじゃ！！

＞７５６
＞一番良いのは経費をかけず
＞コスト・信頼・スピード・パフォーマンスを実現することじゃ！！

言いたい事は上記の事です。しかし、自社の抱えている要員が云々・・は
ちょっと違う気がします。（申し訳ない、意味が読みとれなかった）

>>757
＞一番良いのは経費をかけず
＞コスト・信頼・スピード・パフォーマンスを実現することじゃ！！

メインフレームじゃなきゃそれは実現できないんですか？
単に要員がいないだけでは…

>>758
要員がいなきゃ開発できないじゃん。
開発要員いないけどオープン系で！！って事？
悲惨だな・・・

>>759
＞開発要員いないけどオープン系で！！って事？

いや、それはいくらなんでも無理っしょ、ってんなこと言ってるつもりはないけど。

ただ、メインフレームの選択が要員云々だけだとしたら、じゃあ人が揃えば必要ないのね、
って思ったので。

７５３の言いたい事はシステム要件を満足に把握出来もしない似非ＳＥが
さも自分の意見は正しいと主張する事に意義を申し立てているのでは？
確かに口先だけ素晴らしい人は沢山みかけます。（営業及び技術者もどきで）
ここに書き込んでいる人の中にも一部、自分のエゴ丸だしで意見を出している
人をみかけます。その人達に対して意見しているのでは？
それとスレの主旨に戻れば現在のシステム要件の主流は汎用機を使用したそれでは
無くＷｅｂ系では無いのでしょうか？その辺の事から考えてみてもゼロとは言わない
までも無くなったに近いのでは？
しかし、それと業務を精通した汎用機出身のＳＥが不必要なのとは別だと思います。
むしろ逆なのでは？

個々での議論が無意味かどうかという意味だけで言えば
これからキャリアを確立して行こうと言う人にとって
メインフレームという
近い将来構造不況になりそうな道選ぶのかどうかと言うのは
とても重要なことだと思うよ。

汎用機がなくなりはしないと思うが、現在よりも数は減るだろう。
でも、よく考えると税金の納付書とか、一時に多量に処理しなきゃいけないものや
顧客がデータの入力自体を拒否したら、パンチャにデータパンチさせて、オペレータ
が操作するしかないとしたら、汎用機もオープン系も関係ないのでは？
エンドユーザーは、出来上がったものだけ受け取ればよいので、その経過がどうでも
良いのでないか？後は、費用対効果とか信頼性とか機密性とかの問題で決定される
ような気がするが。

これからメインフレームのキャリア選ぶのか
それともオープン系のキャリア選ぶのかは
NTTに入社するのか、NTT‐DOCOMOに入社するのか
というのと同じくらいの違いがあるだろうね。

「思う」「だろう」「気がする」ばかり。
バックデータに基づいてスレの趣旨に合った説得力のある意見が欲しいね。

これからまた汎用機が息を吹き返す兆しが見えてきた模様
もし汎用機（ハードウェア自体）が安くなり人材の確保がしやすければ
顧客はどちらを選ぶだろうか？

>>766
価格が安くなれば、安定性に優れる汎用機を選ぶんじゃないかな？
漏れはオープン系の経験しかないけど、汎用機の人から見ると
UNIXでも不安定なんですよね？

実際にメインフレームの事を詳しい人など居ないだろう？
（ＩＢＭ、日立、富士通、ＮＥＣを例にすれば）
例えばＪＣＬの事を詳しいだとかその程度でメインフレームを解った気に
なってるだけじゃないの？
そうでは無くどうせ勉強するならハードウェアの事も勉強しておけば
この業界のどのジャンルに行っても役にたつしメインフレームが
無くなろうと問題は無いと思いますが。
それと現在の状況は７６１が上で書いている通り「無くなった」のと
同様だろう。１０年以上前であれば「やれＣＩＣＳの詳しい方」だとか
「やれＡＩＭを使用して設計をしたことがある人」とか
「ＤＣＣＭでプログラムを組んだ事のある人」なんて言うのが常だった。
しかし現状でこんなオーダーが来ることは希だ。現実ベースで
オーダーが来るのは「ＵＮＩＸのシェルがくめる人」だとか
「ＪＡＶが組める人」や「ＴＣ／ＰＩＰが詳しい人」その他も
沢山あるけど汎用機を使用した開発のオーダーは殆ど無い。
これを以て無くなったと考えるのはどうだろうか？

漏れはＲＤＢに対するバッチ処理って経験ないので
ＤＱＮな質問で申し訳ないのですが、誰か教えてください。

ＲＤＢに対するバッチ処理で業務上許容できないエラーが
発生した場合、ＪＯＢを停止するとかエラーリスト（もしくはログ等）
を吐き出して、正常終了するのが普通ですよね。
で、その後のリカバリってどうするのでしょう？

入出力がファイルの場合は、更新前の入力ファイルがあるから
いくらでもリランが可能だけど、ＲＤＢの場合は既に途中まで
更新しちゃってるはずだから、リランというわけにはいかない
ですよね？まさか１ＪＯＢごとにバックアップをとってるとも
思えないし。
それともバッチが正常終了するまでＣＯＭＭＩＴをかけず、
エラーが発生したらＲＯＬＬＢＡＣＫして、ＪＯＢ停止なんでしょうか？
最近ＯＰＥＮ系に移ってきて、メインフレームでの経験しかないもんで。
誰か教えてください。以上、長文スマソ

汎用機ってユーザーインターフェースもUNIX系とは全く違うのですか？
コマンド的には似ているのでしょうか？
汎用機について全く知らない私に教えてください。

>769
そう言う場合は何件単位でコミットかけるって環境変数とか引数で
指定するのが普通でしょ。リスタートする時は最終コミット時点まで
戻ればいいわけだから。これは汎用機だろうがオープン系だろうが
一緒でしょ。

>>770
基本的に一緒。ただし２０年位前から各社ともにメニュー形式にして
コマンドを発行しなくとも良い？様に仕様を変えたので現在では
コマンドを発行する必要性が殆どない。
汎用機の発想そのものはむしろＵＮＩＸと同様と考えてよい
ＭＳの様にそれらが古いと感じる企業もあるようだが

>>771
ありがとうございます。もう少し詳しく教えてください。

コミットポイントをいくつか区切るのは理解しました。
（メインフレームのオンライン処理で１トランザクションが
リソースを掴みっぱなしになるのを防止するのに、同期点を
切って、別トランザクションに引き継ぐのと同様の発想かと）

ですが、RDB以外の外部データをトランザクションファイルと
して使用する場合、どのレコードがリスタートの対象だと
把握するのでしょう？
まさか、処理済フラグのようなものを各レコードが必ず保有する
ファイル設計にするとか？そんなわけないですよね？

ホント教えてくんでスマソですが、どなたかよろしくお願いします。

ごめんなさい。自分でカキコしといて何ですが、今自分の
中で解決しました。

現在、処理対象のレコードのキー（もしくは何件目のレコードかという数値）
をRDB上に保有して正常に処理できたら処理対象キーをＮＥＸＴレコード
にして・・・ってのを繰り返せばいいんですよね？
そうすれば、ROLLBACKした時には処理対象キーの方もROLLBACKするし
問題なしと。そういうことで自分の中では解決したんですが・・・

考えてみれば、これってメインフレームのオンライン上で
スケジュール実行されるEBMP（UNIXのデーモンとかWINのサービスみたいな
ものに相当かと）がDB全体をなめて処理していくのと考え方として
何も変わらないや。
お騒がせしました。すみませんでした

>>772
レスありがとうございます。

ではユーザーインターフェースはUNIX(Xなり)よりも簡単という事でしょうか？
では人手不足なのはどうしてなのでしょうか？
メインフレームの技術者というのはカーネル（UNIX用語ですが..）やハードまで知り尽くしていると言うことですか？
いちオペレーターとしてはそんなに難しくなさそうに感じるのですが間違いでしょうか？

質問ばかりですいません。

その通り、ネットワークの知識もね

各プログラムがどの様にメモリを使用するか、どの位置にあるのか等も
わかってるよ。（ＤＩＳＫもね）
というか、そこまで設計しているよ、

UNIXじゃ考えられないようなところまでちゃんと設計しないと
動かないor障害が起きたときにRECOVERYできないのがメインフレーム。

なんちゅうか、そういったメインフレームのだささが、
アプリケーションレベルの品質の高さにもつながると思うが、どうよ？

アプリの品質の高さは、新規開発がないので枯れてきたからである。
枯れたと思っているうちの80%はすでに腐っている。

＞ではユーザーインターフェースはUNIX(Xなり)よりも簡単という事でしょうか？
その通りだと思いますよ。
但しWindowsシステムの様な仕組みが汎用機には無いので、あくまで一昔前の
ＰＣの画面のイメージですが・・（言い過ぎかな？

＞では人手不足なのはどうしてなのでしょうか？
それはＵｎｉｘを使用した環境の事を指してますよね？
それとも汎用機を使用した環境を指していますか？

＞メインフレームの技術者というのはカーネル（UNIX用語ですが..）や
＞ハードまで知り尽くしていると言うことですか？
いいえ、ごく一部の者しか知らないでしょう。
特にメーカーがその中心を支えていると思います。

>>778
完全な新規開発も少しはあるけどな。

前に読んだ某コンピュータによると障害や外的要因によるシステムダウン後の
システムリカバリの速度はメインフレームは数分で、ＵＮＩＸ系は数時間で、
ＲＡＳに重点を置いた設計に関していうとメインフレームが圧倒的に優位。
しかし、ここ数年ＵＮＩＸ系はＲＡＳ機能の向上を図りメインフレームの高信頼性を目指している事から・・・。

確かにメインフレームじゃＥＣＣとかは３０年位前からあるし命令の再試行なんてそれより前からあるし
それに比べＳＵＮは数年前にＥＣＣ搭載を画期的なこと見たいに大々的に発表してたっけな。

扱いやすくて（開発＆運用が容易で）壊れなきゃどっちでもいいや。

みなさまは優秀な方々ですから、安い事務所を借りて
独立すべきです。
http://www.kitayama.co.jp/soho/

メインフレームはあと１年以内の命です。

＞７８３
一年でリプレースできれや苦労しないよ。

分かった！！！メインフレームの強みは、歴史だ！！！

サッカーブラジルに勝てないようなもんだ！！！

歴史の重みだ！！！

ということは『ＩＢＭ』には勝てない！？

歴史ならブラジルより
イギリスとかウルグアイでは？

ｲﾀｰﾁの古いCFぢゃないけど、

　「みんなが集まって、みんなが持ち寄って、
　　システムを開発・運用しています」

ってな感じでしょうか＞メインフレーム
そうでないと回らないしね。UNIXはいつまでたってもコンソール
代わりにしかならないかもね。メインに君臨するなんて無理でし
ょうね、汎用機OSに勝るようなUNIX系OSが出れば別かもしれない
けど。これは、ちなみにマシン抜きでの話しね。

情報システムで重要なこと＝歴史
→IBM最強・マンセー！！！

しかし、実際業務レベルで使われるソフトって
同じ情報を入力する人と利用する人の分担だから
ｗｅｂ系のシステムとかＡＳＰとかだったりで
メインフレーム使わないといけないようなシステムなんて
銀行とか公共機関とかしかないのでは？
どうなんでしょう？

メインフレームでもＵＮＩＸ動くけど基幹系では聞かないなぁ
昔、大学に入っていたメインフレームでＵＮＩＸを動かしていた
よそは知らないが結局ＵＮＩＸじゃ研究用とかには良かったけどＭｘｘとかいうＯＳに比べると
逆に使いにくい点も多かった
（今いる会社の基幹システムはＵＮＩＸだけどね）

メインフレームはなくなりはしないけど、市場としては小さくなるのは間違いなし。
特に日立、富士通というIBMコンパチ・メインフレーマが海外撤退、国内の既存ユーザーの
リプレイスや拡張のみに商売を限定し、IBM独占市場になっている現状を考えれば、先が
「無い」わけではないけど「非常に狭い」のは確実。
米国ではメインフレームの管理者が高齢化して少なくなっているので、IBMが資金を出して
いくつかの大学でメインフレーム管理者講座を開いているけど、講義内容は全てLinux（とVM)を
扱うためのものでレガシーOSについては教えていないことは、IBMがメインフレームの将来を
どう考えているか暗示していると思う。
しかもLinuxメインフレームの「売り」は、複数のLinuxが統合的に運用管理できることだったけど
その分野は新しく登場したブレードサーバーに侵食されつつある。
IBM自身の動きが「脱メインフレーム」に向かっている今（顧客がいるのでメインフレームはもう
先はありませんとは口が裂けても言わないけど）、メインフレームを神聖視するのは自分の将来の
キャリアを考えると危険だと思う（かく言う私も最近Linux始めました）。
まあ、希少化するであろうメインフレーム管理者を狙って、むしろメインフレームを集中的に勉強する
っていうのもアリかもしれませんが。

>>792

正直僕もメインフレームの将来には疑問があり
メインフレームで食って行くキャリアは避けたいと考えてるけど
しかし、ここ日本ではメインフレームが売れつづけてるのも事実。
ここ日本においては、もしかしてメインフレームエンジニアの需要が
今後もあるのかも知れない。

どっかのアメリカの会社は
基幹システムはずーっとメインフレームをつかう！
と宣言したっての聞いたな。どこか忘れたけど。

>>793
メインフレームが売れ続けてる？
それ本当？

メインフレームにおいて、中小のシステムはＣＳに、巨大システムはより巨大に
って感じかな

>>792
>...希少化するであろうメインフレーム...集中的に勉強するっていうのも...

なんかつまんなそう。得意になってＳＬ走らせてるやつみたい。

>得意になってＳＬ走らせてるやつみたい

違うだろ、少なくとも過去の遺産ではない。
適材適所ってえ事。

>>451
亀レスだけど、メインフレームMIPSとドライストーンMIPSは別物のベンチマーク
だから、比較対照にならないよ

昨今、頻発する大規模障害の真の原因を御存じかな？
何の事は無い、リストラですね。リストラに飛びついて、ササッと逃げ出した
人たちが今までシステムを支えて来たんだよ。
なんやかんや言っても３０年前に、入社早々システムを作っちゃた人たち。
その後も、修羅場をくぐりぬけてきたんだよ。
まあ、偉そうな事いっても４５才以下の汎用機担当なんてアフォだものね。問題が出ても、報告書（いいわけ）第一で行動してんじゃないの？
障害がをなんとかしようと、必要で有ればアセンブラ、COBOL、アプリ、
OSのソースまで自分たちで確認するくらいの本気さないの？
まあ、若手中堅でできるやつはすでに汎用やってないけどね。

断言する。
汎用機を使用する時代は終わった。

故に今、作業が出ている営業上案件は殆どが保守の様な作業だ。
（また書き込んでいる人達も薄々感づいているのだろう終わった事を。）

勉強するのは個々の自由だし、それが何の勉強であっても別に他人にとやかく
言われる筋合いのモノでは無い。
しかしこの先食べて行く為の糧にしたいのなら汎用機の勉強はその歴史を学べば
十分だろう。その後の勉強は金融に進むのか製造業なのかはたまた流通業なのか・・
それによりどのアーキテクチャが必要かおのずと解ろうと云うモノだ。
単にプログラマーに成りたいのであれば、現在主流の言語を勉強すれば良いのだし・・

>>799
CPU性能であれば、「PC>>汎用」です。IOも「汎用>=PCサーバ」ですね。
でもなおOSのCPUリソース管理では「汎用>>>PC」ですね。これは機能、
デザインよりはチューニングの世界。PC以外に選択肢がなくなれば早々に
実現されるでしょう。
でも、例えばゼロから勘定系システムを考えると現状からかなり違った形態
にすべきではないかな？　現行システムではコンピュータ・ハードウェアと
ネットワークは極めて高価であることが大前提になっていると思う。

>>802
すでに、かなりの数の銀行で開発を計画中です。
信金レベルですら開発中だから、銀行から汎用機が無くなるのも時間の問題。
早いところでは５年後くらいから本番稼働が始まり、
１０年後くらいには、かなりが移行するものと思われ。
１５年後でも汎用機を使っているところは、開発するだけの体力のないところ。

ここに書き込んでいる方達の中で汎用機が無くなると解っていても
まだ汎用機系の仕事に着いている人って何人位いるの？

なくなるのは時間の問題。１５年後・・・

未だにＣＳ、あるいはＷＥＢに全面移行できない企業がほとんど。
というのは、メインフレームにアドオンの形でＷＥＢシステムやＣＳが開発されている。
ＩＢＭから、メインフレームの資産を活かせて、ＷＥＢやらＥＤＩまで全部ひっくるめて出来る
エンタープライズが出ているが、実際に買い換えたなんて話は少数。
企業にそんな金もない。

確かに、大型汎用機の新規需要、新規大型案件（億単位のＰＪ）の開発受注は今後はまず見込めないでしょうが、１５年という根拠はどこにもない。
１０年以内に汎用機は数％になるかもしれないし、２０年後、まだ２桁残っているかもしれない。
どっちにしても近い将来は携帯ツール＆ネットワークのシステムが大多数になるでしょうね。

>>802
整数演算は今でも圧倒的に汎用機のほうが速いぽ。
整数演算だけ考えればCPUの速さは
汎用機＞＞＞＞WS（パワーPCとかSUNとか）＞＞＞＞AMD＞いんてる

>>803
信金レベルの取引量だから汎用機が必要ないと思われ。
金融系で処理用が多いのは株屋だべさ。
株屋はフロントエンドはPCとかWSでやっててもバックエンドは汎用機だべさ。
松井もバックエンドは汎用機だがや。
今までは汎用機でなくても出来るようなところにまで汎用機を使ってたと思われ。
それがまともな姿（適材適所）になってきてるだけだべさ。

>>802
キミの言うCPU性能って何よ？
PCが上って判断する根拠を提示してから言いましょうね

>>803
松井はDIRのSONARはもう使ってないです。
取引系システムは2年前から完全にUNIX系に移行しています

野村も何年か前に、15台あった日立のメインフレームを数台残してオープン
系に移行してたような

系統ごとに分けてたのをＶＭ運用にして数台に集約かもな
後は、たいしたことの無い（少々止まってもいいような）業務をＣＳに移行したんじゃない？

>>808
これは秘密ですけど次世代汎用機のCPUはxxxxxです。知らなかったですか？
ですからPCより速くはならいですよね。
最近MIPSとかあまり言わないのは、２GHzとの比較を問いつめられると
困るからです。
次世代汎用機の性能表示も1900+みたく、これはx.xGHz相当ですとかすれば
分かりやすいのにね。
でも改めて言っておきますが、コンピュータの性能はCPUだけでは
ありません。OSなども重要です。

可用性、信頼性ってレベルからみてどうなの？
私はメインフレームやってないけど、やっぱり
２４時間フル稼動のシステムの部分ではまだ、使われる
のかなって気もするんですが。
高いだけあって、こわれないらしいし。
こわれないというか、ちゃんとハードメーカの
保守がきっちり行われてるのかな。ＵＮＩＸ系は
ウインドウズ系と比べれば、信頼性は高いけど、
確立低いけど、ハード障害とかでとまるしね。
実際、基幹系はホストが残ってるしな。

命令実行に失敗してもリトライ
演算結果をハードが自動的にチェック
各ユニットに自己診断が働いている
メモリも自己診断機能でリードライト時以外にもデータ化けがないか監視・修復
修復不能な場合、交替メモリの割り当てや切り離しにより動作に影響がないようにする
ラッチ毎にデータ化けの監視
複数のＣＰＵを積んでクラスタを構成し、複数クラスタでシステムを構成している場合
クラスタ内のＣＰＵが使用不能になっても切り離して残りのＣＰＵで運用
クラスタが動作不能になったらシステムから切り離し運用
システムによっては動作不能のクラスタを自動ＩＭＰＬ実施後クラスタ運用が可能な場合ＩＰＬ後復帰
ＯＳの動作もハードが監視、その逆も
とにかく多少速度は犠牲になるけどプログラムミス、バグがない限り誤動作やシステムダウンの無い様に設計されている
メンテも共有部分や１重化のみのところ以外は必要最小限だけシステム構成から切り離してメンテしてシステムの動作としては止めない様な工夫

ただし、ＵＮＩＸ系もＲＡＳに関しては発展途上なので今後さらにＲＡＳ機能がメインフレームに近づくと思われることからメインフレームが絶対というわけではない。

Ｗｉｎｔｅｌのつくりからするとこれからもそれなりでしょう。（分かれると発展が面白そ）

>>807
信金がやっているのは、業界まとめて１つのシステムにするというやつだ。
資金量的には１００兆円を越えるはずなので、都銀より大きい。
信金は小さい金ばかりあつかっているし、各信金で重複が多いはずだから、
顧客数や口座数では、都銀を遙かに超えるものになるはず。