業務システムをオープン系にするメリットって

なんですか？
汎用機でいいじゃん。
処理スピードは断然速い。
インターネット系のシステムはともかく、会計（決算）、受注出荷、生産、債権債務管理、請求入金、原価計算等々、
いわゆる基幹系システムにおいては、オープン系で作るメリットが分からない。

操作性？
日常的に利用する基幹システムでは、『慣れ』の方が大事。
今時？古い？COBOLer？ドーテー？夢？幻？

誰か俺を論破してください、お願いします（´・ω・｀)

んなもん、ねーよ。

俺が稼げるからオープン系にしろって客にいってるだけ。

あ？そりゃ逆だろ。
汎用機の方が稼げる。だが、それだと高くて売れない。そんだけ。

>>3
汎用機だと今時のポッと出のSIerには無理じゃん

マジレスすると

バカにも扱えるようにするため

マジレスすると持ち帰って開発できる

メンテナンスや、不具合のときの対応がある程度のレベルの人間で可能

１台いくらよ？保守料ひと月いくらよ？

>>8
うちの例で言うと・・・、
汎用機は、コミコミで6,000万/月くらい。
オープン系は、ミッションクリティカル少ないのに、1,800万/月くらい。

動いているシステムの重要度で言ったら、比較にならんくらい汎用機のが上。
これらをオープン化すると、6,000万/月で済むとは思えない。

うちの例でいうと
10万/月くらい。

メンテナンスや不具合は、ベンダと連絡すれば短時間で解決する。
しかし、オープン系はサポートにたらい回しにされ、非常に時間がかかる。

何より、汎用機はノウハウが溜まっているのに対し、オープン系は枯れる前に
新しいのが流行るから、大抵の人間は狭い範囲のスキルしか持っていない。

汎用機のノウハウ・スキルってなにさ？

>>9
6,000万／月・台？オープンだとその１％程度。
サポートの質の差が6,000万/月以上の利益をほんとに生んでるの？定量的に説明できる？
とくに、ノウハウが溜まってるなら、サポートはそんなに重要じゃないんじゃないの？

>>12
・プログラムが異常終了したことを迅速に検知
・障害箇所を迅速に特定、対策
・１つの箱（同じ汎用機）でいくつものシステムを作る為、できる事／できない事が
　周知であり、要求定義の段階で見積り精度が高い＆計画的な工程管理が「出来ている」
・ログを出力する勘所が明白
　（オープン系はやや角度を変えただけログが一杯だったり、本当に欲しいログが
　　抜けてたりする）

>>14
上二つはまあいいとして、下は設計がうんこなだけじゃねえか

「できない事」＝「やらなくていい事」ではない件

>>13
6,000万の価値というのは、動かしているシステムの基盤としての価値です。
オープン系だと1%どころではなく、6,000万を超えると試算しています。
（導入支援SE費の償却費も含め）

ハードも高いし、ソフトもべらぼうに高い。
UNIX、Oracle EE RAC、運用監視、印刷処理、ストレージ、負荷分散機、太い回線。。
作ったJavaプログラムを動かすのにも、TOMCATじゃサポートないからWebLogic。

>>15
そりゃごめんな。
けどな、オープン系ではオンスケで開発進むのが普通だと思ってるのかい？

>>16
投資対効果という言葉があるように、例えば100万ならやって欲しいけど、500万
ならいらない、という機能もあるのです。

>>17
価値ってどういう計算で出てきたのよ。それがなきゃ曖昧すぎるよ。
だからまず、汎用機の購入価格と、支払ってるサポート料はいくらなのって聞いてるの。

> ・１つの箱（同じ汎用機）でいくつものシステムを作る為
そのせいで１システムのトラブルが他所に波及するんだがな。
１つ糞重いジョブが動いたら全システムがレスポンス低下したり。
汎用機とオープン系の連携なんざやってる場合オープン系の多種のシステムにも影響がいく。

よくわからんけど、開発工数はオープン系の方が圧倒的に少ないんじゃない？
うちは同じフロアで汎用機とオープン系と両方やってるけど、汎用機やってる連中は
ちょっとしたことやるのにどんだけ稼動かけてんだって感じ。

>>14は単に経験とスキルの問題にみえるけど、
オープン・汎用機関係あるの？

>>19
汎用機はハウジングなので、利用料金。
サポートは6,000万に込み。

で、価値について。
稼動している個々のシステムには、それぞれ開発当初に見積りを行います。
その見積りには、開発費用、システムの規模に応じたインフラ利用料、運用費用等が
含まれます。
システム費用は、利用部門（全社で利用するシステムは本部）が費用を負担します。
当然ながら、金額に納得がいかないなら、開発は中止。

多数のシステム費用の合計は、6,000万よりもっと上。
その差額が、情報システム部門の給料やら飲み代やらになります。

利用部門は当然ながら、システムにかかるコストと、恩恵たるメリットを
上申書に纏め、役員のハンコを貰ってはじめて「金を負担する」と言える
わけです。

つまり汎用機は、利用部門が認めた価値を生み出している、と言える訳です。

ブランコの風刺画
ttp://www.cagylogic.com/archives/images/20040303-2.html

＞当然ながら、金額に納得がいかないなら、開発は中止。
汎用機なんかで見積もり出してたら、全部中止になっちまわね？

>>20
そのためにオペレータがいる。
又、周りの人間が「おかしいことやってる」とつっこめる。
しかしオープン系では、自由度が高すぎていまいち外から見えにくい。

>>21
例えばSAPで基幹システムをリニューアルしようとすると、100億はかかる
と試算されました。たっけーよ。

>>22
汎用機は、１０年前の経験、スキルが武器となる。
オープン系は、１０年前の経験の半分が思い出だけになる。

>>25
汎用機１台で、多数のシステムを稼動させています。
つか、基幹系全部と＋＠

>>23
なるほどやはり、月6000万か。
それが月6000万以上の利益を生んでいるのはそうなんだろう。
しかし、オープンで月1000万に抑えたら、毎月の利益が5000万増えるんだが。
年間で６億をどぶに捨てるってのは、いくら儲けてる会社でも無視すべきではないと思うが。

＞オープン系は、１０年前の経験の半分が思い出だけになる。
この辺、単なる願望くさい。

>>28
俺も、半分は言い過ぎと思うな。表面は変わっても経験は生きる。
逆に、汎用機は10年前と(ハード性能以外)変わっていないのか？

>>27
全くもって無視してません。
そして、月1,000万に抑えるのは非常に難しい。
いろんな会社さん、その思惑でもってSAPを導入したものの、なかなかうまく
いってない。
オールJavaやオール.NETで基幹システム成功した事例があったらご教授下さい。

>>28
乱筆で失礼しました。
１０年もあれば、技術的な部分は大きく変わる。
そうすると、「判断」する為の材料としては弱い。
当然ながら、プロジェクト管理経験、業務知識等は有益なノウハウ。

>>29
言い過ぎました。３割に訂正。
しかし、肝心な判断材料のネタにパラダイムシフトは痛い。

汎用機も変化する。
しかし、その変化を少数の専門家でもって吸収することが出来る。

オープン系では、そもそも動かない事が多い。
Oracleのバージョンが変わって仕様が、JDBCが、Windowsが、APIのインターフェイスが、
DOSの○○命令が無くなった、、。
基幹システムなんて、サブシステムでも億単位なので、数年サイクルで再構築なんて
やってられません。


又、汎用機には少なくとも、
・再起動したら直った
・もう一度動かしたら正常終了した
なんてのはない。

>31
俺オペレータだが、残念ながら
> ・もう一度動かしたら正常終了した
は汎用機でも存在するぞ。

> ・再起動したら直った
はあまり聞かないがな。

つか、基礎的な技術の理解無しに「最新の技術だけ」習得することなんて出来んぞ。
JDBCやWindowsのAPIなんて枝葉もいいとこ。

>>30
オープンで、数台でサポート料＋ハード＆ソフトの償却で月1000万超すなんてのは普通ない。
システム開発が汎用機よりブレやすいってのはあっても、
ここで問題なのは基盤としてのコストなんだから、それは直接関係ない。
まず固定の費用で数倍から数十倍の差がある。それをごまかしてはいけない。

その差を埋める汎用機のメリットを、定量的に示さないとダメ。

>>31
＞しかし、その変化を少数の専門家でもって吸収することが出来る
ノウハウが溜まってるってのと矛盾するな。

>>32
>> ・もう一度動かしたら正常終了した
>は汎用機でも存在するぞ

そこは、マスタの状態とか、参照整合性的なものとか、処理日が
違うことに起因する問題ではないでしょうか？
Windowsでは、それら全く関係無しに起こりえます。

もしそれらが同じ状態で起こるなら・・・、勉強不足でした。
しかし、銀行振込みデータや請求書、決算書作る処理でそんなこと
起きたら、恐ろしいですね。


>>33

そこは汎用機と同様、本人の勉強でカバーするところだと思います。
しかし、その枝葉が変わる影響が理不尽にでかすぎる。

オブジェクト指向の「設計」なんて、もてはやされた割には廃れてしまった。
（もちろん、オブジェクト指向型言語は申し分なし）
Java Appletも昔は・・・。
ＳＯＡなんてのも、どうなることやら。

技量で生産性が変わるのが良くないって理屈？

最低レベルの生産性に強制的に合わされる＝見積もりし易い環境よりも、
技量によってはより高い生産性を獲得できる可能性がある環境のほうが
よいのじゃありません？

>>34

>>1にも書いたとおり、業務系基幹システムを想定しています。

会計（決算）、受注出荷、生産、債権債務管理、請求入金、原価計算等々
を動かすのに、そんなに安く出来るでしょうか？

Oracle EE 500万（Intel系２コアあたり）←デュアルコア４つのせて、2000万
Oracle RAC 250万（同上）
ストレージ 数千万（バックアップ装置だけでも数百万）

それぞれ、保守費は年額で購入費の20%が相場。即ち５年で倍。

RACやBlade、障害設計の設計・設定SE費で計1000万〜3000万。

汎用機と違って壊れやすいので、冗長化が必要。

汎用機は１０年償却。
サーバは３〜４年償却。

具体的な数字を書くのは簡便して貰いたいが、売上げ数千億、社員数千人の会社
の基幹システムと思って欲しい。
数台のサーバで賄えるとは思えない。

>＞しかし、その変化を少数の専門家でもって吸収することが出来る
>ノウハウが溜まってるってのと矛盾するな。

？

Oracle+WebLogicなんて、はっきりいって何もいいことないからなー。

誤字脱字が多いのはごめんなさい。
殴り書きで読みづらいのもごめんなさい。

汎用機に対して優位性が本当にあるのか、真剣に疑問なんです。

周辺系システムについてはどう考える？

>>37
月額と購入費をごちゃになってるので整理すると、

月額１０００万となるには…

償却を４０ヶ月として、月額は、初期購入費÷４０
サポート料は、月額（初期購入費÷５）÷１２。

初期購入費÷４０＋（初期購入費÷５）÷１２＝１０００万

初期購入費×３＋（初期購入費÷５）×１０＝１２００００万

初期購入費×５＝１２００００万

初期購入費＝２億４千万

初期購入費だけ（当然開発費やそのほかの費用は含まず）で、２億４千万のシステム。
売上げ数千億、社員数千人の会社なら、こんなもんじゃないの？

>>38
それだけは激しく同意

>>38
の理由はわからないが
汎用機と連携する時に俺の相手が痛い連中ばっかだったのでしんどい目を見て以来
汎用機が嫌いになった

たまたまかもしれんが･･･

何がダメかって語りは基本的につまらない
批評っつーのは才能であり芸だからな

1はもっと積極的に汎用機の利点をアピールすべき
汎用機バッシングにもおなじことが言えるんだけど

>>1
SAPがオープン系だったら絶対使うが・・・。

オープン系でも汎用機でもどっちでも良いよな
業務に影響が出なければ
あともっと安くなるといいよね

>>40
帳票処理などの専用サーバのことですか？
それとも、データウェアハウスなどの戦略型システムのとですか？

>>41
業種にもよるが、製造業、流通業などでは、売上げの１％を情報システム投資に
まわすのが一般的。（とSIerさんが言ってた）
不思議とうちもそれに当てはまり、年額で数十億が掛かっている。
そのうち、インフラに関しては汎用機、サーバそれぞれ前述の通り。

あなたの口調からすると、お金周りのことは想像で話していると見受けます。
社内構成の話はさすがに出来ないので、インフラのアドバンテージは少ない、
としか言えません。

逆に言えば、オープン系のメリットはそれだけでしょうか？

あんた言葉遣いは丁寧だけど、全く論理的じゃないし話があちこち飛ぶな。
あきらかに汎用機が不利なポイントだからわざと話を拡散してごまかしてる？

事実：ハード＋ソフト購入＋サポート費をひと月１千万に抑えたら、毎年５億浮く。２千万なら４億浮く。
事実：毎年５億浮くのは、ハード＋ソフトの初期購入費だけで２億４千万規模の場合。５億規模なら浮くのは４億。

汎用機なら別だが、オープンなら２億４千万でそれなりに揃う。５億掛けても毎年４億浮く。

オープン化を否定するには、
その毎月６千万のシステムをリプレースするのに、初期購入費がこの額に納まらない事か、
リプレースによる損失リスクの期待値が年額５億か４億を上回ることを示す必要がある。

いっとくけど、オープンに切り替えるってのは頭も切り換えるって事。
念のため念のためで取捨選択せずにストレージにドバドバ金注ぎ込むとかは無し。

>>48
というか、論点がかみ合ってないのは間違いなさそうです。

>オープンなら２億４千万でそれなりに揃う。

１日１０万件のトランザクションと、同数程度の印刷、数１０万の検索が
行われる基幹システムです。
定時間内のサービスダウンは許されません。
インフラ面は大手ベンダ数社とも打合せをしており、それなりのレスポンスを確保し、障害対策を
汎用機並みに行うと、価格面でのアドバンテージが無いことは結論として出ております。
従ってインフラ価格の面は不毛だと思ったので、こういう事は開示していませんでしたし、
「インフラ以外で」と何度も主張しました。
#加えて、インフラのお話は板違いなので、話にも出ないと思ってました

うちの環境をコンサルして欲しい訳ではなくて、プログラム技術板らしい観点で、
「業務システムをオープン系にするメリット」
を教えて頂けると嬉しい。

>>49
ム板向きの言い方をするなら、
HaskellとかPrologの切り口を付けたいと言うときに
・ プログラマが得られない。
・ コンパイラが得られない場合が多い。
このような場合、他システムとの連携を設計思想とする
オープン系だとうまくいく可能性がある。

汎用機は後継者が育ちにくいだろうな
オープン系のプログラミングは自宅でも学べるし
多くの学校でも教えている

だが汎用機なんて個人じゃ持てないし
学校で置いてあったとしても古かったり
JCLが異なったり思うようにいかない
おまけに変なジジイばっかの環境でメイン言語はCOBOL…

確かに長いこと同じような環境でやってるジジイどもは
そこの環境や動いてるジョブの保守はよく出来るだろうが
それ以外の人間には理解不能な環境になってることも多い
ジジイどもがくたばったら後が続かないんだよ

典型的な後だしじゃんけんだな
どんどん条件が増えていく>>1にご期待ください

以下の話は規模によって事情が違うと思います。それを断った上で。
事務計算は記号処理部分をPrologで記述し、十進演算をCOBOLで
処理するという切り分けがシステムのSDLCの観点から本来は望ま
しかったと思う。しかし、アトムが増え続けるPrologのような系を
汎用機に本格的に導入することは危険であり、それがこのような
方向のシステムが開発されなかった理由です。
オープン系の開発だと、HaskellやPrologといった高級言語系を
別のサブシステムに分離する設計が可能で、業務システムを
抜本的に洗練された記述で知識化する道筋が漸く開かれるのでは
ないでしょうか。

>>49
一日たった１０万トランなのに２億４千万円じゃ不足って、ベンダにとって最上級の鴨だな。
（その半分が定時前１０分に集中する、とかならともかく）
そもそも、ベンダにとっては汎用機の方が利益率が圧倒的に高いんだから、
それを基準にしてる客に、安上がりの提案なんかするわけがない。

＞障害対策を汎用機並みに行うと、価格面でのアドバンテージが無い

>>48の最後の２行読んだ？
それは、汎用機並みに行うじゃなくて、汎用機のやり方で行う、の間違いだろう。
しかし、そういう思考の人間しかいないなら、確かにオープンにするのはリスクばかりでコストも下がらんかもな。
>>36も言ってるが、プログラミングセンス最低のＰＧに合わせるのがCOBOLだが、
ほんとに最低ばかりなら、しかも組織風土がＰＧをコーダー（パンチャー）みたいに考えてるなら、
オープンの生産性メリットも得られないだろう。
それで下手にオープンの底辺ＰＧを外注したらもう破綻しかない。

＞プログラム技術板らしい観点で、
これってどういうのを言ってるの？ どっちもコンピュータなんだから、
汎用機でだって方法が変わってもやれば出来るに決まってんじゃん。
だからどうしたってコストの比較は捨て置けない。

>>55
４ベンダが談合し、うちを鴨っているということでOKです。
できれば、240百万でどんな構成のサーバを作るのか、簡単に教えてくれると幸いです。

ほかの方たちの意見は、技術者育成問題ですか。
たしかに今、ITSSなんていう体系もあります。
しかし、勉強には本人の自覚と意識による部分が非常に大きく、優秀な技術者とそうでない技術者の
二極化が問題となっています。
技術に興味を示さない人は、生産性があがらないばかりでなく、問題の種になったりする。
かといって組合がある以上、個人の生産性云々で解雇は不可能。

汎用機は、各社標準化がきっちり成されており、優秀でなくてもコーダーにはなれた。
そして、有識者によるコードレビューもやりやすい。

又、オープン系は、言語やフレームワーク毎にコーディング基準が必要で、学ぶべき範囲が
非常に広くなる。

常に up to date にしてようと思ったら、結局学ぶべき範囲は非常に広いから問題無す。
学ぶべき範囲みたいなのが明確に定まっていて、しかもそれが十分に狭いなら、それは
儲からない仕事だろうね。

ITSSの体系が整備されていくと社内SEって人達は言語とは完全に切り離されるよ

>>56
断っておくけど、俺自身は関連する職だがSEじゃない。
しかし、SE達が基幹と呼ぶシステムの情報からは、
１０万トラン/日の規模で浮かぶのはこんな感じ。OracleをSEにしたい気すらする。

RAC４台（サーバ込み１０００万×４）　４０００万
APサーバ４〜８台（同５００万×８）　　４０００万
運用管理　　　　　　　　　　　　　　　　　１０００万
ストレージ　　　　　　　　　　　　　　　　　３０００万
バックアップ　　　　　　　　　　　　 　　　３０００万
ネットワーク（分散込み）　　　　　　　 　２０００万
テスト系・ほか　　　　　　　　　　　　　　　のこり


＞しかし、勉強には本人の自覚と意識による部分が非常に大きく、
＞優秀な技術者とそうでない技術者の二極化が問題となっています。
＞かといって組合がある以上、個人の生産性云々で解雇は不可能。

分かってるじゃん。で、その切れない不勉強技術者の割合は？
それが高ければ上に書いたとおり、オープンじゃ破綻のリスクありだ。

しかし、汎用機の思考でよく分からないのが、>>31の
＞又、汎用機には少なくとも、
＞・再起動したら直った
＞・もう一度動かしたら正常終了した
＞なんてのはない。
だ。直って欲しくないの？調査はコアなりログなり取っといて後でじっくり調べりゃ良いじゃん。

で、既存のオープン系システム

１．DB許容量について

価格からみて、１ＣＰＵのサーバ４台と判断します。
Xeon5160を積んだと想定しても、無理です。
（クアッドコアだと、その予算に収まりません）
キャッシュフュージョンって知ってますか？
４台積めば、４倍の処理能力になるわけではありませんよ？
１０万トランザクション／日を賄えるとも思えないし、更に
数１０万の検索がある。>>49参照。

トランザクションというのは、イメージ沸きますか？
１つのトランザクションには、例えば受注でも複数品目が登録
される。
生産処理において、１つの物を作るには、多数の原料が使われる。

即ち、１つのトランザクションにおいて多数の在庫更新、原価計算等
が行われます。
更にビジネスロジック以外の処理として、入力内容のチェック、ログ、
エラー処理等も必要。

ちなみに検索対象というのは、小規模データの検索もあれば、上記
のように膨らんだデータを検索することもあります。
経験上、１ＣＰＵ４台じゃまず無理です。

２．導入作業費

あなたの仰る構成だけでも、導入ＳＥ費に1〜2000万はします。
キャッシュフュージョン対策を行うなら、その倍では済みません。

>>60へのコピペミスです。。。
先頭に、以下があると思ってください。

>>59
割とまともな価格感がでてきたので多少驚いてます。

俺は職種でいうとSEです。

３．残りといっている7000万では賄えないサーバ、パッケージ

負荷分散装置
開発用ＤＢ
開発用ＡＰ
印刷処理
認証関連
モジュールの配布
パッチ適用関連
企業内FW関連
障害検知
ネットワーク上のデータが膨らむことによる回線の増強

その他、ストレージは3000万で収まらないだろうし、開発（又はテスト）ＤＢ
にもストレージが必要になる。

不勉強者の割合は、意味が無いので割愛します。

>だ。直って欲しくないの？調査はコアなりログなり取っといて後でじっくり調べりゃ良いじゃん。

直って欲しいです。
しかし、後でじっくり調べても分からないことがあります。
再現性がなければ、コアダンプが無かったり、ログが不足したりします。
ログがあっても、ＭＳ有償サポートでも分からない（自分んトコは悪くないと
言い張る）、ベンダさんでも分からない（同）こともあります。

株式会社 基幹　サーバ台数　例
で、ぐぐってみました。
http://www.google.co.jp/search?num=100&hl=ja&q=%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE+%E5%9F%BA%E5%B9%B9%E3%80%80%E3%82%B5%E3%83%BC%E3%83%90%E5%8F%B0%E6%95%B0%E3%80%80%E4%BE%8B&lr=lang_ja%7Clang_en

サイジングのイメージが掴めると思います。

横槍ｽﾏﾝが、1 トランザクションの重さなんてシステムによって全然違うでしょ。
あと、Xeon で Windows なのは決まりなの? 汎用機から Windows とは
急転直下だねw

日本のソフトウエア産業、衰退の真因
http://itpro.nikkeibp.co.jp/article/COLUMN/20070306/264055/

以上のような様々な問題点に加え、日本のソフトウエア開発の産業構造には、決定的な欠陥がある。
ソフトウエア技術者の派遣ビジネスである。

　大規模な開発プロジェクトの場合、ソフトウエア開発の仕事は、ほぼ例外なく複数の会社に分割発注される。
ところがソフトウエアシステムをサブシステムに分割して請け負わせるケースは少なく、
多くの場合、「一カ月いくら」で契約する派遣プログラマーを雇い、プロジェクトチームに組み込む。
派遣会社の間で技術者を貸し借りするので、技術者が多層化する。いわゆる多重下請け構造である。
発注者でさえ、実際の階層数や末端の会社名を知らない。ある政府のプロジェクトで、
危険視された宗教の信者が最下層に参画しており、それに管理者は気付かなかったという話さえある。
当然、開発責任は曖昧になる。厄介なことに、派遣契約の多くは請負契約を装っているので、
書類だけでは実態はわからない。

　派遣がすべて問題なのではない。現に欧米でも派遣に相当する契約はある。
それは、開発規模を決めるビジネスモデルをコンサルタントが作る場合や、
不確定要素の大きい革新的なプロジェクトでリスクを避けるために使われる。
また、成果物の品質責任を問われない事務的な仕事では、派遣は便利な形態である。
しかし、品質に関して重大責任を負うに至ったソフトウエア開発ビジネスで、
成果責任を負わない派遣形態がかくも横行しているのは日本だけである。

そのレベルでその値段とは時代にそぐわないすげぇボッタクリシステムだな〜

>>63
住友電気工業っていうのは何をやってる会社だろう。

DB設計が糞ってことはない？まともなDB技術者がやってる？性能考えて取捨選択してないでしょう。
テーブル内容も、なんでもただナイーブに突っ込んでみましたみたいな。
IsolationもSerializableとかしてそう。

>>54
業務ルールを他と分離しましょうってお話は、3月中にあっちのスレ
　　http://pc11.2ch.net/test/read.cgi/prog/1174837272/373 (方針と実装の分離原則)
でさんざやったよな〜

今更恥ずかしげもなく何を言い出してるの？

>>62
言いたい事はいろいろあるけど、特に３の半分は贅沢。定時外なら計画停止ありなんだろ？
汎用機系は、オープンからみて、コスト意識が欠如してるように見える。
役人体質というか。100%でなく97%にすればコストは半減。
あとは選択・技術・運用ルールでカバーする。

それはともかく、1000歩譲って２億４千万で足りないとして、
倍にしても、毎月４千万浮く。年間で毎年５億のコスト減。

業務屋って陳腐なシステムしか作れない癖に
話を大袈裟にして大金ふんだくろうとするから
業界で嫌われてるんだと思う。

お前らには文系出身の似非コボラーがお似合いだ。

>>62
＞又、汎用機には少なくとも、
＞・再起動したら直った
＞・もう一度動かしたら正常終了した
＞なんてのはない。
＞再現性がなければ、コアダンプが無かったり、ログが不足したりします。
直るのが最善は当然として、わからなかったら仕方ない。
業務データを間違うって障害ならそうも言えないが、
情報部門の趣味のために業務を止めるなんて、発想が根本からおかしい。

要するに
・実績が少ないと不安だからヤだ
ってことじゃないのか？
その一言で片づければ、ベンダもユーザの気持ちも少しはわかるが。

>>67
弱電系で商売になる物は何でもじゃないの？
そう言う事じゃなくて？

私も昔はU-Stationのユーザだった。電線だけ売ってるのでない
ことはわかる。でもシステムが障害を起こすと人命にかかわる
業務はそれほど多くはないだろう。これほどITを厚くする理由
が正直わからない。何をしているか、とはそんな意味。

>>72

あなたひょっとして、エンドユーザか学生さん？
雑誌や情報処理の教科書をそのまま信じているだけに見えてきた。

現場を（ＰＭ・ＰＬとしてでも、ＳＥ・ＰＧとしてでも）見れば
当たり前のことを、さも自慢げに語る。
言葉に重みを感じない。

あなたの理屈でいえば、投資対効果でいえば比べるまでもなく汎
用機に利点はないことになる。
では何故、何年もの間、「基幹システムのオープン化」という
キーワードが無くならないのか？
情報システム業界の２００７年問題なんてものが取り沙汰される
のか？

（ＳＡＰ導入企業が増えたことで減りはしたが、ＳＡＰを強行導
　入した各企業の憂鬱は業界では有名）

>言いたい事はいろいろあるけど、特に３の半分は贅沢。定時外なら計画停止ありなんだろ？

勿論です。
例えば、一部を除いて２０時でサービス終了でも構わない。

>役人体質というか。100%でなく97%にすればコストは半減。

１年の営業日を240日と過程します。
240　×　0.03　＝　7.2

１年のうち、7.2日分のシステム停止は考えられない。
企業である以上、何かしら物・サービスを売っている。
受注、出荷、購買、生産、会計で、システムに頼った業務を行って
いる人が1000人と仮定する。
又、１日８時間労働。福利厚生等々込みで平均時給を3,000円とする。

57.6時間（7.2日）　×　3,000円　×　1,000人分　＝　１億7280万

止まっている時間だけでこれだけ掛かる。
その間、ユーザ部門は代替手段の模索、実施に追われる。
復旧後、それまでの代替手段とシステムの辻褄あわせに手をとられる。

協力会社への影響を考えるともっと膨らむ。
更に出荷が遅れることによる信用失墜の損害は計り知れない。

あなたはこれだけ非現時的な話を、鬼の首を取った様に述べている。
以上により、あなたは基幹システムに関わったことが無いと確信した

このスレ、あちこちの計算がデタラメで笑えた

誰かの脳内対話ではきっと動かしがたい真実なのだろう

>>78
具体的にどうぞ

>>1 は以前 UNIX スレで暴れてた人と文面が似てるんだけど、
世代的な特徴なのかな。部下に仕事を任せて、自分は暇だから
2ch をやってるとか言ってたけど。

例のキチガイコンサルが
2007年問題絡みのマイグレーション仕事にありつこうと
必死にもがいてるだけだろ

>>78
＞１年の営業日を240日と過程します。
＞240　×　0.03　＝　7.2
稼働率が97%なんて言ってないよ。言うはずがないでしょ。

トランザクションがたまに失敗したって、リトライして貰えばいいじゃない。
それがヤバイ時があるなら、ヤバイ時専用にロジックを用意すればいいじゃない。
どこかがコケけたら、その間だけは方肺でレスポンス時間が3倍になったっていいじゃない。
本当の本当にリアルタイムなビジネス遂行にクリティカルじゃない奴は、別の安上がりシステムでいいじゃない。

そういうことを言ってるんだよ。要求に対する考え方をいってるんだよ。
ずっとやってきた思考をいきなり切り替えるってのは難しいだろうけどね。
それまでのやり方に、あんたなりの誇りみたいな物があるんだろうし、それはそれで意味はある。
だが、供給側のこだわりが本当の需要を正しく射ているとは限らない。
利用者に対しても経営者に対しても。

>>76
あんた、全然>>72に反論出来てないよ？解ってる？
それを理由とするのが自分の主張を否定すらしうるって解る？

ｼﾞｻｸｼｴｰﾝ

空理空論と空理空論のガチンコでアミダのトグロｗ超絶無意味

>>83-84に関しては、

>当たり前のことを、さも自慢げに語る。
>言葉に重みを感じない。

で、答えになってると思っている。

あなたのほうこそ、

>では何故、何年もの間、「基幹システムのオープン化」という
>キーワードが無くならないのか？
>情報システム業界の２００７年問題なんてものが取り沙汰される
>のか？

に、答えてみて下さい。

深夜の自問自答

それは自殺の兆候

>>86
ここでアルマゲドンしている内は、他に被害が行かないから良いんじゃない。

kwsk

まさか、ここまで版画の魔手が及んでいるのか？くわばらくわばら

汎用機の良さをきちんとアピールできない>>1は
ウンコみたいなマイグレーションにたかる銀バエが作り上げた仮想人格。

>>44
こいつは汎用機の知識はもちろんのこと、
オープン系の知識もテキトーなゴミだから
それは能力的にムリ

>>1

あんたさぁ、自分が信じることをやればいいじゃないよ。

俺はクリティカルなことはやっぱ汎用機に分があると思ってる。
だいだいハードもソフトも極度に限定されるんだから、その分安定して動いてもらわなきゃ困るさ。
安定して動かすために金をかけるわけですから。

ただ今のご時世、70がいうところの100%を望まなくてもいいんじゃない？って会社もでてきてる。
そういうところがオープン化して安くすませるわけでしょ？

オープン系と汎用機を同列に見てるのがそもそも間違いなのよ。分かった？

適材適所ですよ。保険とおんなじだって。
高額でも手厚い保障を望む人もいるし、保障は最低限でいいから安いのを選ぶ人だっている。

選ぶのは買う人(会社)なんだから、売り手の押し付け論理は通じませんよ。

市場で勝負していけばいいじゃん。
どっちかか負けてなくなるかもしれないし、比率は変わっても両者生き残っていくかもしれない。
自然と答えは出るでしょ。

なんと空虚な文章・・・メーカの人間が見たら泣くだろうな

営業出身だからこんなもんだろ

科学技術分野だと、専用機の地位はここまで低くないんだけどな。
特に国内の地球環境とか素粒子物理分野。
アメリカさんがとっくにあきらめた、専用計算機やベクトル計算機の技術が
未だに重宝されてて、超並列機と住み分けているような状態。

あの分野は伝統保存芸能扱いだからなｗ

やけに伸びてるなｗ

>>87
それはつまり、>>84の答えを教えれってことだね。
簡単だよ。
>>76はあんたは単に俺に悪態を付いてるだけで、なんら反論してない。
代わりに「基幹オープン化」「2007年問題」のキーワードを持ってきただけ。
>>77は反論の形にはなってるが、趣旨を外してるので無意味。

なんで「基幹のオープン化」って言葉がなくならないかって？
そりゃあんたみたいのがウジウジと二の足を踏んでる、あるいは踏ませてるからだよ。
物事にはただでも慣性があるんだから、抵抗勢力が居たらますます変化は遅れる。
あんたはいわゆるLaggard。それはそれでいいけど、みんながそうだと思うのは間違い。
「2007年問題」が騒がれる？そりゃあんた達がそういう事態を作ってるからじゃないか。

というわけで、あんたが引っ張ってきたネタも、なんら>>72の反論になってないんだよ。

ダメコンサルの化けの皮がとうとう剥がれたなｗ
恫喝営業は受け付けないよ。さっさと巣に帰れ

> あんたはいわゆるLaggard

俺はモルツ頼むわ

脳内議論にしても、あまりに乱暴だと思った

この先、その調子でうまく営業していく自信ある？

>>99
不思議と、全く同じ感想をあなたに持っている。
「悪態をついているだけ」「反論していない」「論旨がずれている」

まず、言葉に具体性が無い。
又、根拠なしの結論が多い。
出来れば、事例とか調査結果とか示してくれないだろうか？

インフラ費用の話は平行線が続いてるけど、それ以外にオープン系
のメリットはないのかね？

相手から望んだ答えを得られないのは、相手の話をちゃんと聞いていないからだよ。
これ昔からの真理ね。

また ゲイ の細かい自作自演だこと

>>76のどこら辺が反論になっているのか、小一時間…。
まあそれはともかくだ。現場のSE経験はあんたが圧倒してることは確かだ。
言葉に具体性がない？それは手痛い指摘だ。正しい。
で、そういう現場に精通したあんたにこそ、具体的な根拠をご教授願いたい。
とりあえず、>>62だ。
残り7000万では賄えないと列挙した物が、
本当に必要不可欠な範囲で7000万で賄えない、具体的な根拠。
ストレージは3000万で収まらない、具体的な根拠。
ガツンと示してくれないだろうか。

前提条件も定かじゃないのに、何億円で収まる収まらないの話しても
意味が無いと思うので、もっと話を続けて下さい。

まー、正直マイグレだけで数十億ポーンと飛ぶようなプロジェクトを見てると、
オープン化へ進んでるのはただ、今後の保守が技術者減って大変ですおと言ってるだけに感じる。

こんな議論しかできない奴とだけは
一緒の仕事したくないな。
無意味な主張に必死になっちゃって
火病かよ

俺はオープン系だけど、UIだけWindowsに外出しする仕事が
多いです。

中出しの方が好きです。

これだから業務系とは会話にならないな、と思った漏れは制御・情報系。

汎用機はそんなに売れないからもっと値段上げても良いですか？ってメーカの質問にNoと答えたのがユーザー
なにか勘違いをしているが作り置きで余っているならともかく、受注生産品で売れない物は値段を下げて作っても仕方が無い
だからオープン系に移行してるだけなのだが
そもそも安くしろってのはユーザー側の要件なんだよ
性能の劣化とコストダウンを計りに掛けて考えるのが良いSE

インターネット技術のいい加減さでも業務で支障無いから、汎用機なんてゴミ。
原子炉制御とか、エラーで大規模事故にでも成る用途でもない限り不要だ。

つーか、汎用機の信頼性以前に、汎用機のプログラムミスでエラーが多い件に付いて。
定時のバッチ処理すらまともに処理できないなんて異常。オープン系のようにリアルタイム処理なんて絶望的だわ(w

銀行とかで汎用機使ってるのは行員には嬉しいだろう。
でも預金者には、インターネットで口座チェックや振込出来たり、一円でも安い手数料のほうが嬉しいのであって、高コストの汎用機を求めている訳ではない。
業務ユーザもオープン系にしてコストダウンできる分だけ、給料や賞与で還元受けるなら汎用機なんて捨てたいよ。目的は業務を管理したいだけで、汎用機を使いたい訳じゃないし。
汎用機を売りたがる／導入したがるのは、汎用機技術者の利己主義に過ぎない。

版画は下らない茶々ばかり入れてないで、なんか主張して見ろよ。

業務システムは奴隷にやらせとけばいい。
終了

そして奴隷のプログラムミスで大事故発生。
りそなのATMシステム障害も検証不十分の奴隷の仕業ですね。

http://www.sankei.co.jp/ad/nttdata/

ほんとあいつらばかじゃないのかと思うんだが・・・・

検証不十分を彼らのせいにするのは同業者として間違ってるだろ

むしろそもそも短い開発期間しかないにも関わらず
運用開始日を頑なに守って強引に稼動させた経営側に問題がある

自作自演ばかりするお前の存在が間違っている

>>119
だからといってバグや不具合を起こしていいわけがない
ミスしたPGの責任は免れない
例えお前の言うような状況だったとしてもな

おまえ仕事したことないだろ？もしくは生ぬるい場所なだけか

銀行系で１日遅れたらいったいどれだけ損害賠償請求されるか判らんぞ

>>122
一時間でもすごいことになったからな

業務システムのトラブルは奴隷が発生原因なのだから
奴隷に尻拭いをさせておけば良い。
抜本的解決策は奴隷の全廃。

かくして奴隷PGは低給で短納期でこき使われると。
奴隷PGのわがままにつきあってたら運用開始日は１年後とかだしねえ。
バグが無いプログラムぐらい一発で出してこいよと思う。
つーかちょっと使ってみれば不具合見つかるのにあきらかに確認すらしてないだろうってのが、奴隷PGの仕事。

金払いの悪い相手にはそれ相応の対応をされるのが世の常
ああ無情

>>125
まあ、奴隷にすら見はなされて数億の損害出してるプロジェクトを見ると
そんなセリフも外には出せない世の中・・・

抜本的解決策は奴隷の全廃。

そもそもIT化って業務の効率を良くする目的で始めたはずなのに
逆の結果を産んでないか？

国内の場合、ＩＴのアウトソーシングが進みすぎていて
企業側情報システム部門が弱すぎるのだろう。
現場に突っ込んでいって業務改善する力もなく
ただメーカやSIの言いなりになってシステム構築するだけ。

それが国内でマイクロソフトやＪａｖａみたいなのの
企業システムがうまく展開できない理由だ
って誰かがblogに書いてたｗ

奴隷ちゃんガンバ

だってホントは誰もシステム化なんて望んでないんだもん。
たとえ非効率の極みであろうと誰しも自分の居場所を失いたくは無い。

>>131
それが一番デカいよね
結局経営者の都合だからうまくいくほうがおかしい

Win上で動かせる
汎用機とターミナルのエミュってある？

ある

なんだ相変わらず他人とろくすっぽ会話できねぇのか
だらしない奴だな

奴隷PGは隣の席同士でもメールでしか会話しない。
生産性悪すぎ。

理解できねーな

偉大なるSE様は階違うのに口頭でしか指示しない。
記録性悪すぎ。

>>138
俺のことですか　ごめんなさい
http://up.kabubu.net/cgi/img2/26280.jpg

>>139
明日からウチに来ないか?

>>1は逃亡したようだが、せっかく立ったんだし、　ここを
http://pc8.2ch.net/test/read.cgi/tech/1128039768/
の次スレって事にしてはどうか。

>>141
おまえ>>1だろ

コストが安いから

信頼性？いっぱいハード買っとけばいいよ

ハードが安くても、Oracleの値段でそんなん吹っ飛びます＞＜

オープン系なんだからORACLE使うのは間違いだろ
MySQLで何が不満？

何かとんでもない勘違いをしているな

>>145
「オープン」を理解してない小僧っ子か。
昔は（そして今も中堅以上の企業の基幹システムの相当部分）、UnixでもWindowsでもない、
メーカ独自規格のハードとOSで他社の製品と組み合わせられない完全ロックイン状態だったんだよ。

おいおいオープン系ってのはLAMPみたいにオープンソースで構成する事じゃないぞ

>>148
「オープンソース系」かｗｗｗｗ
最初なんで引き合いにMySQL出てくるかわからなかったｗｗｗｗ

>>145
オープンソースとオープン系を間違えてるのか？

下らない釣りに食い付き過ぎ

じゃあ、プロプラ系でオープンソースがあるわけ？
ないんだったらオープン系の特徴のオープンソースを使う意味はデカいだろ。
だいたい、ただで手に入るのがあるのに、何百万も金払うって馬鹿だろ。

またメンヘル出現か

根拠が判らず闇雲に有難がってORACLE使う馬鹿が多いのは事実

このスレの新しいﾃﾝﾌﾟﾚ：　　『根拠が判らず闇雲に有難がって○○使う馬鹿が多いのは事実』

○○には好きな言葉を入れてね。

http://pc11.2ch.net/test/read.cgi/tech/1177786441/

まあ実際、Oracleの方が、対応SQLも全然多いし、関数も多いし、
ストアドもあるし、ロックしにくいし、いざというとき（内容はともあれ）サポートもあるし、
当然のようにデフォルトでトランザクションできるし。

というか藻まいら、板違いなんじゃ…

じゃあ、WebLogicはどうだ？Tomcatで何か不満？

関連スレ
http://pc11.2ch.net/test/read.cgi/prog/1154874670/
http://pc11.2ch.net/test/read.cgi/prog/1171181035/l50

>>159
WebLogicとかTomcatとか、
アプリケーションサーバーであって、

業務システムでは無い！

>>161
Oracleじゃなくてもいーじゃん的な話が出たから、その対比だろう。
WebLogicじゃなくてもいーじゃん的に

昔は小規模な案件なのに無意味にOracle導入する奴いたけど

十年ひとむかし? 十六年はひとむかし、ゆめだぁ?

汎用機の10年は全然ひと昔じゃないな
普通に10年前のコードが現役で動いてる世界だ

>>1
仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

業務に使うからオラクル入れとくのが安心なのは確か。

趣味なら無料ソフトでも良いが、業務でソフトが無料だからデータ消えましたなんて言い訳通用しないし。
下らん会計処理程度でDB2動いてるのと同じ感覚。

まぁオラクルのせいにする為に金払ってる様なもんだし

2〜3鯖のライセンスなんてカスみたいな値段だしな

じつは・・・・オラクル使ったことねぇ････
SQL鯖とかDB2だけだ・・・・
俺ありえねぇ・・・・

>>170
そんなことないよ
そう思わされている時点で君もORACLE病
早く洗脳から抜け出せ

ＰｏｓｔｇｒｅＳＱＬ使ってるところ無いの？

>>172
うち業務でも使ってるよ
PHPと組み合わせてる

それってもし業務データに問題が有ったときに誰が首になるの？
良ーく考えよう。業務は大事だよ。

下っ端には関係ないね

ﾏｼﾞﾚｽすると、客に断りなく勝手にオープンソースを重要な箇所に使ったりしない。
コストとリスクを説明して客に選んでもらう。

>>169
カスみたいかも知れないが、その金を工数に使ってたら何人月の補充になるだろう。

>>171
Oracle病は多いかも知れないが、アンチOracleは意思決定者を説得する
だけの話術を持っていない。

つまり、結果(Oracle以外を採用させる）を出せない。
小さな会社は別として。

>>178
構築ノウハウ含めて考えると、別に移行するほどのメリットないよね、ってことになるからね。
特にＳＩ案件では。
パッケージ販売とかの数売ってナンボな商売だとまた話は変わるんだろうけど…

上司説得するより客説得した方がいいよ

客は判断できないから頼んで仕事になってると思うけどな。
客が分かってるなら、自前でエンジニア雇ってシステム構築してしまうよ。
客の代わりにおまいが責任もってオラクル以外での不具合の責任を持てばいいだけ。

MySQLを使って発生した１０００万円とかの損失は生涯掛けて補填しますとかさ。
顧客情報流出程度でも５０００円（最高裁判決）×１万人で５０００万円とかさ。

>>178
話術じゃなくて理論的な説得材料な。

from 客

>>181
話の流れとしてはわかるが、情報流出はDB選定とは関係ないだろう

DBに格納する案件として顧客情報って割と多いよ。

>>184
そういう問題じゃなくて、DBMS製品とセキュリティ設計は
考える階層が違うだろう。

セキュリティ設計で、個別のDBMS製品に依存する部分は非常に少ない。

データ流出をORACLEのせいに出来るってすごいな

大体情報流出は，部長のデスクトップに張ってある付箋とか，
ダメ社内SEの持ち込んだUSBメモリとかからだろ．
そこで発生する危機はどんなDBや機器を使ったって軽減できない．
まぁトラブった時にサポートに聞ける，とか，
パフォーマンス関連でモラクルに一日の長がある部分も多いけどな．

>>187
「持ち出して盗難」「こっそり売り」を忘れてる

>>181
ありえない。
SEが年間どれだけのシステム作るか知らないでしょ？
永久補償（わざとこの字）とかありえない。
それに客に求めているのは技術力じゃないよ。
リスクとコストどちらを採るか判断して貰い、責任を取って貰うことだ。
責任というものがどういうものか実感してから出直してこい。
客が望んでいるのは無茶とか無謀なサポートするベンダーじゃないよ。
自分達がどこまでできるか理解していて、一緒に悩みながらシステムを安定運用に持って行くことだ。

オラクルなら不正アクセスも考慮された設計だし。MySQLとは違うよ。

悩む様な屑PGにお金なんて払いたくないよ。
優秀なPGが作った一つの瑕疵も無く動くシステムを納入してほしいだけ。

>>190
> オラクルなら不正アクセスも考慮された設計だし。MySQLとは違うよ。
もしかして本気で言っている？
ミドルウェアは道具にすぎないんだよ？
理想郷は君の頭の中にしかないよ？
> 悩む様な屑PGにお金なんて払いたくないよ。
> 優秀なPGが作った一つの瑕疵も無く動くシステムを納入してほしいだけ。
じゃあこの世に現存するすべてのものは使えないね。
OSでもどれだけのパッチが出てるか知らないでしょ？

現実を知らない営業とか客とかって、傍から見てると無様だねぇ…。

学生だろ

雑魚ＳＥが粋がるな

図星かい？

>>189
は小規模開発した事しかないチンカス学生
１年〜かけてやるプロジェクトも平気であるんだよ

おちんちんにかすなんてたまってません！！

>>195
と学生が叫んでいます

×　学生
○　グロマン学生

>>197
と知ったかぶりのNEETが申しております

>>195
そういう問題じゃないだろ。

一年も時間かけてバグつぶせないなんて、糞PGですか？
給料泥棒！　ちゃんとバグの無いプログラム書けよ。

>>201 は未経験だということを自ら露呈しました

>>201
仕事ちゃんと経験してから煽ろうな？

>>1
こんな記事もある。
しかし、ム板で聞くこと自体が間違ってるんじゃないか？

ttp://www.itarchitect.jp/enterprise/-/26401.html

>従来、この種のシステムの稼働環境としては、メインフレームが用いられてきた。
>しかし、レガシー※1・トランスフォーメーション、すなわち、Java EEなどの
>オープン分散プラットフォームを用いて、既存のミッション・クリティカル・システム
>を再構築しようという機運が高まってきている。メインフレームは高い信頼性を
>備えるため、新規システムの開発をメインフレーム上で行うケースもいまだ多いの
>は事実だが、メインフレームを扱える技術者の高齢化が問題となり、また若手技術者
>の教育コストを削減することを目的とし、基幹業務の稼働環境をメインフレームから
>オープン分散プラットフォームに切り替える例が増えてきているのである。

>※1　IT業界では、「レガシー」という単語が用いられる場合、それは主にメインフ
>レーム資産のことを指していると考えられる。筆者は、現在も技術革新を続け、
>オープン分散プラットフォームとは比較にならないほどの高機能を提供するメインフ
>レームをこのように呼ぶことには抵抗を感じる。しかし、一般的に通用する用語で
>あることは事実なので、本連載ではそれを踏襲することにする。

凡庸系なんかみたことないけど。

つ AS400コボラー

オープン系技術者の中では、ｺﾎﾞﾗｰは蔑称だなぁ…。
COBOLしかできないコピペPGなんてｲﾗﾈ。
もちろんCOBOL以外も書けて広い視野を持っている方に対しては、ｺﾎﾞﾗｰなんて言わない。

ぼんよう 0 【凡庸】


（名・形動）[文]ナリ
すぐれた点もなく平凡なこと。また、その人やさま。並み。平凡。凡人。
「―な作品」
［派生］ ――さ(名)

RPGでもいいじゃんAS頑丈だし完全上位互換するし
ちょっと7色しかないからってなんでもパソコンてのもどうよ？

うちのASは緑しか表示できないよ。
７色も出るなら買い替える(w

ASシリーズのシステム・アーキテクチャはオブジェクト指向だ(ただしアプリ記述言語はCOBOLだけど)
とかいう煽り文句を思い出した・・・出所は父の伝言あたりか？

商用マシンでオブジェクトって言い出したのはシステム38が最初かな。
オブジェクト指向的な要素は陽には見えなかったが・・。

>>204

>若手技術者の教育コストを削減することを目的

ここでせっかくのノウハウの蓄積がなくなってしまう。
若い連中はインストラクターや本で覚えた知識をかざして
汎用機のプログラムを見てはダサイといい、
ｵｻｰﾝの言うことをきかなくなり、○○を使えば今までの１／３の工程とか言い始めて
その結果、同じ失敗を繰り返す。
しかもフレームワークがころころ変わる昨今、若い世代でも同じようなことが・・・。

ベテランがあたらしめのアーキテクチャをマスターして
若い世代に教育できればいいんだけど、そんな人はほとんどいないからな。
オレはオープン系だけど、たいしてコストも変わらないのに
２０代のボンクラプログラマばかり集めて基幹システムをオープン系でやる意味が分からない。

細かい話でいえば、データベースとオープン系言語との間に
そもそもデータ型の互換がなくプログラムのほとんどが型変換やチェックばかりで
しかもそれがバグの温床にもなってて非常にバカバカしく思う。

汎用機にゃ汎用機の、オープンにゃオープンの利点があって使い分けるべきなのに
ソレをオープン系や若手のせいにしてるようじゃ
若手もついてこないだろ

汎用機の「変化が少なく安定」てのは利点だからそこは否定せんけど
それに甘えて、変化の早いオープン系を解らんポイと捨てる奴や
個人じゃ学びにくい汎用機についての教育をろくにしなかったり
汎用機そのものについていい加減にしか理解してないベテラン
どう考えても言語としての機能が見劣りするCOBOLそれ一つしか解せないPGがベテランの椅子に「でん」と構えてたり

…そんなんじゃ若手もそっぽ向いて「汎用機は時代遅れ」ってイメージ持つだろうよ

>汎用機にゃ汎用機の、オープンにゃオープンの利点があって使い分けるべき

システム構成としてはもちろんそれが理想だが、
どちらにも柔軟に対応できる人材はあまりいない。
結局はベンダやソフト屋の都合次第なんだと思う。

>どう考えても言語としての機能が見劣りするCOBOLそれ一つしか解せないPGがベテランの椅子に「でん」と構えてたり
おれはオープン系だがこれは別に悪いことではないと思う。
また開発手法や標準化が徹底しておりビジネスロジックのみに専念して記述してある
COBOLのソースを見ると芸術的とさえ思う。
設計や行程についてこういう人に質問することは多々ある。
むしろ悪いのは言語により優劣をつけてベテランを論破しようとする若手。
それで結局だれが得をするのかと・・・。

>>215
ビジネスロジックの部分だけCOBOLで実装するとかそう言う選択が出てきてもいいのにな．

Web〜Service層までJava/.NET
Serviceの内部でビジネスロジックをCOBOL実装
DAO以降のレイヤーをまたJavaとか．
ってここまで書いて思ったけど，COBOLとそれ以降では，
データ構造とか取り扱いが根本的に異なるから無理かな？

コボルが芸術的とは到底思えない。
オブジェクト指向ですら無いじゃん。

昨今のインターネット対応なんてコボルでは絶望的。

>>216
ハブの所に使うCORBAの実装費用だけでもう一システム余計に作れるな

>>217
オブジェクトCOBOLの名前すら知らないお前にCOBOLを語る資格はない。

Excelでゲームは造れるけどCOBOLでは造れないだろ

Obj-cobolって実際使われてるの？　どんな汎用機？

百五銀行のWindows勘定系が稼働、フルバンキングで世界初
http://itpro.nikkeibp.co.jp/article/NEWS/20070507/270070/

　三重県の地方銀行である百五銀行は
Windowsで構築した新基幹系システムの
稼働を開始した。マイクロソフトによれば、
勘定系を含むフルバンキングをWindowsで
構築した銀行は、世界で初めてだという。
ゴールデンウイーク最終日の5月6日（日）
に稼働を開始し、7日（月）から平日稼働を
開始した。現在のところ、トラブルはなく
順調に稼働している。

　新システムの構築は2003年から始めた。
OSに「Windows Server 2003 DatacenterEdition」、
サーバー機に日本ユニシスのIAサーバー「ES7000」、
パッケージには日本ユニシスの「BankVision」
を使っている。

　旧基幹系システムは日本ユニシスのメイン
フレームで稼働していたが、新商品開発のス
ピード向上や運用コストの削減、周辺システ
ムとの連携などを図るため、Windowsで再構
築することを決めた。新システムでは休日の
窓口での入出金、コンビニに設置したATM
（現金自動預け払い機）の24時間取引などを
可能にした。

>>222
これ、何時間で止まるかな？

ASでも安定運用には毎日再起動してたし、ウィンドウズも毎日再起動すれば良い。

>>220
何が目的でプログラムしてるかは知らないが、
こういう考えを本気で持ってる人間が業務システムにも多いのは事実。
もうカルト宗教の世界だよ。
金の勘定にそんなのいらない。

こんな輩が再利用や部品化といいOOPを導入しては、
数年後、やっぱりDIでないととか言って作り変えるのだろう。

オープン系の人もバッチはPL/SQLとかで書くのに、
これはOOPじゃなくてもいいんだよね・・・。結局権威主義なんだと思う。

最終的に目指すところが安定したフレームワークや再利用可能なクラスを用いて、
ビジネスロジックのカスタマイズに専念って、
結局は汎用機がやってることじゃん。あほらしい。

俺は汎用期こそがベンダ主導だと思ってきたが、１０年オープン系をやってきて、
こっちも結局はベンダに振り回されてただけなんだとつくづく思うよ。
であればきめられた枠の中で技を磨き続けるほうがいいな。

何が目的ってお金が目的でしょう
同じ事続けていても儲からないからね

ここまで読んで、結局は人の品質なんだな、と思った。

しっかりとしたコスト意識を持ち、手段と目的の違いを考えきれる技術者が
多い企業には、オープン系が良い。
それは、汎用機と同等のことをオープン系で実現した上で、更なる可能性を
追求できるからだ。

しかし、現実にオープン系の基幹システム成功例が少ない以上、今のオープン系
技術者は汎用機の水準まで達していない人が大半と言える。
＋αを夢見るも、足元を固めきれていない。

従って、技術者の品質が高まるまでは業務システムをオープン系にするメリット
は無い。

何か凄い論理だな…

>>223
毎晩再起動するんだと思うよ

>>227
禿

>>223
49.HOGEHOE

なんかTimeGetTimeかなんかの限界値があって到達したら戻るとかってのあるじゃない？
あれでなんか起きると期待したい
というかネタ的に早く止まってすげーこｔになってほしいわけだがｗｗｗ

>>231
いつの時代の人ですか？

>>231
49.7日のことか

>>232
なつかしいけど、今でもまだ残ってたりするよなぁ･･・そういうPG
運用でどうにでもなる問題だが

ﾏｼﾞﾚｽするとオープン系での高可用性はクラスタが基本。
だからFailOverして何ごとも無く動くだけだよ。
汎用機は集中型だけど、オープン系は分散型。
元々、多ノード構成は得意。

別にオープン系とクラスタ構成は関係ないと思うが。
たまたま、汎用機とはちがって、クラスタ構成化できるハードソフトをそろえやすいだけ。

関係在るよ。
汎用機の文化は一点豪華主義というか、高い部品を使ってMTTRを良くする、集中投資型。
オープン系の文化はRAIDと一緒で、高可用性が必要ならサーバを束ねて使う、クラスタ型。
高可用性においてオープン系サーバとクラスタは常にペアなんだよ。

>汎用機の文化は一点豪華主義というか、高い部品を使ってMTTRを良くする
そ・・・そうか？？？

汎用機＝鎖国
オープン系＝黒船

双方とも、メリット・デメリットが入り乱れて訳ﾜｶﾒ

いくら可用性を上げても事故が起きるのは人為的なミスが大多数だよ。

>>238
×黒船
○海賊船

>>239
新人にデータの容量調べさせてたら、客のＤＢまるごと飛ばしたり、
エクスプローラでプログラムのフォルダをどっかにやっちゃったり。
ま、これはどっちでも起こりうるか・・・

>>239
それを言っちゃあ、おしめぇよ

ってゆーかそれは、内部統制の範疇な

でも、人為的ミスを警告やビジュアル化して表示する事ですこしは減らすことは可能だろ

まぁ・・・・その減らそうとしてやったことも　スルーされて　
「でてたけどそのまんま処理しました」
といわれ人為的ミスが起きるわけだが

もういやだがや・・・・・

>「でてたけどそのまんま処理しました」

多いんだよなそれ

矮小化した例でｽﾏﾝが、checkstyleの警告なんて見てもくれないのな。
（そもそも規約でチェック有効にしとけっつってるのに無効にしてるっぽい。アフォか。）

自分も中〜下の間くらいだと自覚してるが、
下の集団を相手にするのは疲れるよ。

>「でてたけどそのまんま処理しました」

つ フールプルーフ

みなさんコンパイルしたときのワーニングは放っておきますか？

自分が書いた部分なら全て直すよ。

>>247
ワーニング出ないように修正してる
なんか気持ち悪いしｗ

わーにんぐレベルをさげる・・・。ｗ

>>250
ちょっｗｗｗｗｗｗ


そして>>250のその行為が引き金となり後に伝説の事件を生むこととなるのである

641億円を投じた技術試験衛星「きく8号」、故障の原因は回路のショート
ttp://www.technobahn.com/cgi-bin/news/read2?f=200705101553&page=2

>>251
いや、ワーニングは所詮警告だよ。
本来そんなグレーゾーンはなくすべきだから、レベルMAXで通らないと駄目ってのが正しい。
それを規定してない開発チームだったら、下げても問題ない。

>>253
日本語で

>>254
漏れは >>253 じゃないけど
日本人としてちゃんと意味分かったよ

昔、汎用機用の周辺機器開発やってたが、
汎用機にはトラブル対応の為ぶら下がってる人がたくさん居て
常に解析できる人をフルタイムとはいかないまでも待機させておいたり、
保守チームを残しておく必要があった。

それにトラブル修正の為の予算、要求はほとんど通り、
再現性が低いけどバグ以外考えられないといったトラブルに関しては、
半年掛けても直せとか命令されたこともあった。
その仕事に関しては、考えうる限り妥協が許されなかったよ。

トラブルが直ったら、ある程度の責任者が報告書を持ってお得意様まで説明しに行ってた。
いまでもそうなのかは知らない。

今は辞めちゃったので良く知らないけど、
現在は昔ほど厳密じゃないと言う噂を聞いた。

実際その通りです

波があるからまた変わるだろうけど

だから汎用機には高いコストを払うってだけだと思うんだが
今の時代はミスはミスとして認めれば許されるケースも多いので
リスクから考えて安いオープン系で開発するのも有り

>今の時代はミスはミスとして認めれば許されるケースも多いので
>今の時代はミスはミスとして認めれば許されるケースも多いので
>今の時代はミスはミスとして認めれば許されるケースも多いので

人為ミスは無くならないが、あなたはシステム屋としての姿勢がおかしい

一時栄華を誇ろうとも時代を経るごとに駄目になっていくのは歴史の定めなのだろうか。

>>260
だが時代は繰り返す
きっと「これじゃダメだ！」て風潮になる････って信じたい

つうか、仕様書や説明書ひとつとっても相手から金取ってるんだからもっと真剣にやれと････
若い連中のスタンスに問題があるような気がする
とかいう俺も20後半だけどさ･･･

>>259
これを前提にしているようではダメだと思う
1ミスが命取りくらいに思わないと信用失っちゃいそうで･･･

>>258
エラーが本当に致命的な所以外は皆そうなってると思う。
運用でカバーしろって奴か。

止まっても、再立ち上げで動けば無問題、そういう開発者も多いと感じるよ。

>>261
しかしミスがありえないと考えてしまうのも考えものだぞ

>>262
前に下請けの会社が作ってきたものに不具合があって
結局漏れがソース中に原因を発見したんだけど
途中のやりとりではそいつは


サーバー再起動してください。そうしたら治りますから。
あと、おたくは毎日一回再起動しないんですか？


って平然と言いやがった
実際再起動すると一時的に症状が出なくなるパターンだったんだけど

>>264
> サーバー再起動
まさか reboot じゃないよな?

>>263
いや、それぐらいのつもりで書かないと
謝れば許してくれるからまぁいいか
じゃぁダメってことです(；´Д｀)

>>264
恥さらしだな･･
まったく持って恥ずかしい・・・・

サバ管「サーバの不具合の今後の対策として毎週１回OPによるリブートをしてもらうということになりました」
俺(OP)（…ハァ！？）

…ソレ対策って言わないよな？
先週は「一時的な対策として今週だけリブート」って言ってたよな？
つーかリーダーの承諾取れてますってぉ〜ぃ何で通したんだよ…

数週間後、リブートの翌日にフリーズって事態が起こったんだけどな。

抜本的解決を要求するニダ！！

恥さらし　というより　面汚し

ニューヨーク証券取引所(NYSE)のシステムがIBMメインフレームから
AIXが動くIBM System pとLinuxが動くHP IAサーバーへ移行開始されているそうだ。
NYSEでは、この移行によってトランザクションあたりのコストが半分になると見ているとのこと。

これでロンドン証券取引所はWindows、東京証券取引所は富士通のPRIMEQUESTでLinuxとなったわけだが、
三者三様というのはちょっと興味深い。

不治痛ってあれだろ
いろいろ問題起こしてるところだろ

それぞれのシステムに精通した奴をシステムの寿命が終わるまで確保できていれば
何でもいい気はする。

使えない奴をコロコロ替える体制なら何使っても駄目。

取引所の件もそうだけど、オープン系の良いところは選択肢が沢山在ること。
競争原理が働き、良いものが安く手に入る。
だからこそしっかりとした技術のあるSIerを選ぶのがとても重要。

>しっかりとした技術のあるSIerを選ぶ
結局、それで高くつくんですが。なんとかなりませんか？

良い物を手に入れるにはそれなりにお金が掛かるんです。

以下ループ

人沢山抱えないといけない汎用機に比べたら、かなり安いだろう。
仮にも業務の中核となるサーバをそこらに転がっている
Windows端末に毛が生えたものなんて認識していると痛い目に遭うよ。

>>277
オープン系の方が人たくさん必要なんじゃないか？
システムのリリース時期、規模、個人の嗜好によってプラットフォームが
違う以上、運用に求められるスキルも多様化する。結果、人がたくさん必要。

汎用機の方が教育コストというかノウハウの蓄積が大変なんじゃないか？

>>279
おっさんたちが新しいことをおぼえないのはそういう習慣がないから。
一度教育を受ければあらたしく覚えることはそんなにないし、
メーカーには腐るほど資料がある。
ネットには資料が落ちてないけどこれで十分。
そもそもこいつらが作ってるんで問い合わせたらまちがいなく解決する。

バージョンごとにプラットフォームに振り回されて、
挙句の果て新たなフレームワークが登場したら
若手に邪魔者扱いされるオープン系とは雲泥の差。

今回のシステムはどうやって紙を印刷するかを
基盤系の連中が集まって丸一日会議してるのなんてあほらし・・・。

どのスキルがあるかを証明するためにころころ変わるベンダ試験を受けて、
せっかく試験に受かっても有効期限付き。

そして若手はしょーもないトラブルに振り回されて徹夜・・・以下ループ

お疲れ様です

汎用系だろうとオープン系だろうと、メーカーやSIerの取り分は変わらないよ。
オープン系に切り替えてコストダウンしようなんて絶対無理。
いＢＭなんて、金取れそうに無い客は露骨に無視するしね。

システム開発部門は企業の寄生虫だな

>>283
その寄生虫がいなけりゃ、何もできないくせにｗ

>>278
それはない。
たしかにオープン系は多種多様なスキルが必要だが、方針が決まったら詳しい人間を連れてくるだけ。
ちなみに１芸しかできない奴は使いものにならないよ。
少数精鋭がオープン系のやり方。
だから、下手なSIerにやらせると大変なことになる。
自由度が高い分、スキルもピンキリなんだよ。

>>285
なにお前の狭い物差しできめてんだ？カス

>>280
何点かつっこみ。

・オープン系だろうが汎用機だろうが、勉強をやめたら技術者じゃない。
　それはオペレータと言うんだよ。
・客が求めているものに汎用機の印刷システムが応えられない現実を忘れるな。
　選択肢の多さとレイアウトの自由さは汎用機の比ではない。
・それと、オープン系技術者もピンキリだ。
　君の周りにいるのが全てではない。

根拠の無いレスは負け惜しみと一緒だよ？

一行しかレス付けられない香具師ってなんなの？






























あ、俺もかｗｗｗ

>>285

>たしかにオープン系は多種多様なスキルが必要だが、方針が決まったら詳しい人間を連れてくるだけ。
>ちなみに１芸しかできない奴は使いものにならないよ。

馬鹿か?
1芸の人間を種類別に集めりゃいいんだよ

>>290
１芸しかできない人間って他の分野の人間を理解する能力に
欠けてることが非常に多いから使い物にならんよ、マジで。

>>287
上から目線乙

>　それはオペレータと言うんだよ。
そいつらに言ってくれ。
あくまで新しいことを覚える必要がないと言っている。
パラダイムシフトにはついていかなければならんが新しいだけが技術ではない。
誰も過去の知識にしがみついてやっていけるなんて思ってないよ。

> レイアウトの自由さは汎用機の比ではない。
どの程度システムを経験してるのか知らんが
見掛け倒しの帳票なんて客は求めてない。っつーか役に立たない。
そんな枝葉のシステムはそれこそパソコンでやってればいいけどね。
印刷速度を求めるとオープン系もオーバーレイ使うようなでっかい印刷機が必要じゃね？

> ピンキリ
あたりまえ。だがプロジェクトは腕のない奴に足を引っ張られる。
だから長年かけてプロを育てる必要がある。

オープン系の連中にはちゃんと足元固めてるやつもいるが（こいつらと仕事するとマジ楽しい！）、
ベンダの広告に振り回される浮足立ったやつも多い。
できて当たり前のことを一から説明しなきゃならんので
オープン系の会議ほどあほくさいものはない。
せっかく会議で合意が取れて規約を作っても出来上がってくるものは各社バラバラ。

オレはキャリアの後半をオープン系のＰＭとしてやってきたが、
品質も集まる人材も汎用機の方が上だった。主観ばかりですまんね。

>オレはキャリアの後半をオープン系のＰＭとしてやってきたが、
>品質も集まる人材も汎用機の方が上だった。主観ばかりですまんね。

禿堂

>>292
> オープン系の連中にはちゃんと足元固めてるやつもいるが（こいつらと仕事するとマジ楽しい！）、
少ないんだよ, こうゆう連中。
つか、アホが束になってかかっても(ry

ここでおまいらと話してるとマジ楽しい！

>>258のような人が沢山集まるから大変なんだろうね。

チームの性能は一番能力の低い人と同じぐらいになる、とどこかで聞いたことがある。

>>296
秀同

こんな許されると思って作ってるカスはいらない
時間なくってもそんな考えは持たないだろ
その油断こそバグの元

>チームの性能は一番能力の低い人と同じぐらいになる、とどこかで聞いたことがある。

率速段階がどこにあるかっつー琴屋根
サブプロジェクトが直列に結合された状態走っているときに
遅い部分に引っ張られて全体が遅くなるということはあるが
並列に走っている場合はそうでもない
つまり能力低い香具師にはそいつをカバーする香具師をつける必要がある

>>298
そうなんだろうど、カバーする余裕（能力）のある奴を足かせ（能力低い奴）無し全速で動かしたほうが
効率が良いと思う。

やる気のある新人を教育する目的以外では非効率的。
使えない、やる気も見れない奴はサッと切る能力こそ重要。

やる気の無い奴を切ることは出来ても。
やる気のある無能者を切ることは出来ない。

オープン系は人口が多い分、裾野もまた広い。
裾野の人間しか集められないのはPMの力不足だよ。
それにオープン系を汎用機の文化で管理しようとすると悲惨なことになる。
早めにプロジェクトのオープン系部分全体を技術的に広く浅く知っているリーダーを探した方がいい。

プロジェクトのまとまりは人数に反比例する。
一芸ばかり集めるからそうなる。
しかも、一芸技術者は協調性がないからさらに迷走する。

あとPM側の問題のパターンも在る。
使える奴を使えるのは誰でも出来る。
使えない奴を使えて始めて上に立てる。
自分の管理能力、客観的に見たこと在る？

>>302
そうなんよねー。
スーパースターがときどきいるけど、そんな奴がいればラッキー！というくらいの価値。
別にいなくてもいい。
オープン系なんかでは若手から神扱いされてむしろ邪魔な存在になることも。
あたらしい開発手法のレクチャーなんて教祖様なみの憧憬のまなざしだもの。自分で勉強しろっての。
そこで「スゴイ！スゴイ！」としか言えない若者をいかにきちんとまっすぐ歩かせてあげるかなんだよね。
すぐに客寄せパンダを見に道草食っちゃうんだけどさ。

ある意味、客寄せパンダで回ってる業界だからね

>>303
オープン系の基盤プロダクト作ってる連中にはザラにいるんだけどな,
とんでもなく頭きれるやつ...
でも, 出来上がったもの使って物を作ってる連中は何も考えてない.

逆引き辞典かコピペしている漏れの様なＰＧも居れば、
便利なＡＰＩ作る奴も居るってことでつか？

オープン系って呼び名から胡散臭いんだよね。
会話にカタカナが多いほど信頼できないって意見には同意出来る。

対応する日本語を作るほど誰もヒマじゃないのだろう。
日本語版がないのに中国語版があると知ったときこりゃ駄目だと思ったよ。
英語の名詞を日本語の文法で繋いでる状態じゃ英文のままのほうがマシと思われても仕方が無い。

オレら千年近く漢語の名詞を日本語の文法で繋いで来てる訳ですが…
技術情報は英語で得るのが普通だと思うけど。

現在使われている熟語の大半は
明治時代に西洋の言葉に対応づけるために日本で作られた造語

中国の義務教育の教科書に出てくる単語の三分の一は近代日本で作られた熟語らしいね。
実は「人民」も「共和国」も元は日本語だってテレビで言っとった。それと、英単語から翻訳された
中国語は音を当てた字が多いから、日本人がカタカナで書くのとほぼ一緒らしい。実際には
英語に対応する中国語熟語を作ってるわけではないのよね。

まぁ、勝手に負けた気になってる人間はそのまま負けといてくれれば良いと思うけど。

>>306
> オープン系って呼び名から胡散臭いんだよね。
たとえば IP の上に乗っかるプロトコル層ってほとんどオープンなんだよね...

# つか, プロトコルをクローズにするってのは自殺行為だと思う

> 会話にカタカナが多いほど信頼できないって意見には同意出来る。
上記の様なところに行くと, 日本語定義してる暇がないのも確なんだわ

IETF が sample/prototype 実装主義だから, あれだけ rfc でてるのに
std はほとんどない.
でもって, 数少ない std すら理解していないアホたれが大口叩いているのが
今の日本のオープン系って称されてる連中だと思う.

あくまで, たとえばの話なんだが...

>>308
あほか >>309-310 に書いてある通りだ

>>309-310
おまえら油断しすぎ
今は 英->日 の造語生成数よりも
英->中 の造語生成数の方が圧倒的にペースが上

そういう漏れは
>>307 に胴衣
>日本語版がないのに中国語版があると知ったときこりゃ駄目だと思ったよ。

フランス人を見習え

>>310
どこでそんなデマを仕込まれたんだｗ

「人民」 と 「共和国」 が日本語なのは常識だろ

実際日本も社会主義国化に足半分突っ込んでた訳出汁

>>312
駄目なのはあんさんだけですがな。オレはコミュニケーションが英語オンリーになっても
困らんし、英語の読めない日本人技術者が路頭に迷っても知ったこっちゃない。
むしろおかしな日本語をバシバシ作られる方がむかつく。

>>316
でも喋れないんだろ？
無理するなよｗ

自分基準で物事を考えるなよ…

>>316
お前みたいな　ｵﾅﾆｰSEとかPGが居るから周りが迷惑なんだYO!

中国にはカタカナがないだけの話だろう、常識的に考えて…

結論、業務系は所詮烏合の衆。

>>319
その気で頑張れ。英語の壁なんて大した事が無いって分かるから。

まぁ・・読みではなんとなく意味がわかるが
ヒアリング・スピーチ全くできない俺が来ましたよ〜

無理やり変な日本語の造語ができるくらいなら
そのまま英語の方がいいよ

平日の真昼間に2ch書き込んでる連中なんて、業務システムの世界では
末端ワーカーでしかないと考えるのは偏見だろうか

無類のサッカー好きなだけかもしれんよ。

俺はケータイ手放すと死んじゃう人。
もう充電とか禁断症状でまくりで必死ですよ。

オープン系って幅が広いんじゃ？
エクセルＶＢＡでウインドウズアプリ作っているのも立派なオープン系開発者だし
Ｗｅｂから組み込み端末まで何でもござれと言う奴でもオープン系。

DB2の接続プロトコルなんてクローズだが囲い込みに成功して、他に移れないけどな。
オペレータが懸命にエクセルに抜いて加工している。

帳票は馬鹿みたいに開発費かけても良ければ汎用機のほうが完璧なものが作られた実績はある。
今のコストダウン至上主義の時代には合わないが。
公共料金の請求書なんて全部独自フォーマットだし。

接続プロトコル？Excel？
よく知らない事無理して書かなくても良いんだよ？
ODBC以外は殆ど非公開だよ。
DB2だってクライアント入れてAPI越しだ。

印刷についても、ちょとフォントサイズ変えた文字出そうとしただけで
OSの印刷機能がまったく使い物にならなくて、プリンタの独自コマンド山盛りなのに？
つか直接コマンド送るなら汎用機関係ないよね。

それともオーバーレイ？
オープン系で作ったレイアウト使ってオーバーレイして威張られてもなぁ…。

>>329の
背伸び具合はどっかのスレで見た気がするなぁ…・

どこのスレにでも一人は居るもんだ

リナ廚ってにちゃんならどこにでも居るからね。
現実だとマカ以下の絶滅危惧種だが。

Linux?何の関係が？

はい、お一人様ご案内〜

【航空/IT】全日空システムの障害原因は、事前のシステム入れ替え [05/27]
http://news21.2ch.net/test/read.cgi/bizplus/1180265753/l50

まあ、この場合でもごめんなさいすれば済むらしいねｗ

納期短縮？予算節減したんだろうか？
オープン系にすればもっと予算を減らすことが出来た。
どうせ失敗するなら、予算が低いほうが良かったね。

減らした予算と今回の問題解決に費やした費用、どちらが多いのか？
信用はプライスレスだけど。
もう信用なんて無いも等しいし。

　全日本空輸（ANA）が国内線の予約・発券システムを全面刷新する。
30年近くメインフレームで動かしてきたシステムを、
オープン・システム上に再構築する。
新システムへの移行により約70億円を抑制できる見込みだ。
それに向け、日本ユニシスと10年間の包括契約を結んだ。

誤ったなｗ

ttp://itpro.nikkeibp.co.jp/a/biz/jirei/jir0707/jir_o13.shtml

まだメインフレームだよ。
スケジュールよく読め。

>>338
ホスト接続システムがメインフレームだとは書いてないyo

１万台の操作端末--ホスト接続システム（３系統、オープン系？）--チェックインシステム（メインフレームの新機種）

詳しいなら詳細よろ。

>>338
俺も少し詳細に解説してみてほしい

>新システムで利用する米ユニシス製パッケージ「AirCore」の開発言語はJava。
>「全世界でみれば技術者数は多いし、特定プラットフォームに依存しない点も評価できる

なんかJAVAだからプラットフォームに依存しませんって100%思ってそうだけど、やっぱみんなそう思ってるんだろうか・・・・

>>341
>なんかJAVAだからプラットフォームに依存しませんって100%思ってそうだけど

100% 思ってると思ってるのは君しか知らないけど。
単なる OLTP だったら互換性は高いんじゃないかね。

>>341
しっかりした開発方法論とルールの徹底で、プラットフォーム依存部分を
限定的（外だし等）にすることが出来る。
ITインフラの変化には、その辺の調整とテストで対応、と。

.NETは無理だろう。常識的に言って。

>>339
それは問題のすり替えだ。
>>337の書き込みが的外れだと書いているだけだろ。
現行のメインフレームを中心としたシステムの構成なんて知らん。

ＡＮＡでは７０億円もの経費節減ができたんだけど、既に総投資額を使い切っちゃったのかもしれないね。

未確認情報だけど・・・
ネットワーク機器の設定しくじった模様。

ttp://news21.2ch.net/test/read.cgi/bizplus/1180265753/225
>今回のANAシステム障害の根本原因はANAの100%子会社のACC（ANAコミュニケーション）って会社のバカが
>コアスイッチの設定しくじって、天文学的な量のデータを湧き出させたおかげです。

PGなのにNWになんて手を出しちゃったとか？
NWが本業の香具師のミスなら、プロ失格だが。

>>342
別にOLTPでなくとも、COBOLよりはプラットフォーム依存は低いんじゃない？
というか、プラットフォームで困ることなんか文字コード以外ない気が。
単純すぎ？指摘があればどしどしプリーズ。

>>343
なんで？？WindowsがインストールできるPCという限定つきながら、
プラットフォームに依存しないという言い方はできなくもないきがするが。

>>348
ベンダーに依存するなんて、普通は一番避けたいシナリオだろ。
そんなことを言ってる奴が、何かを指摘されて理解出来るレベルにいるとは
とても思えないな。

>>349
ベンダー依存といっても、マイクロソフトですよ？
メーカー汎用機に依存するより安くあがると思うしなぁ。

というより、今はそこの議論じゃないんだけど。。。

ハードウェアがこれだけ安く調達できる世の中になってきているから、
ハードウェアベンダーに依存するのが一番損をすると思ってる。
メーカー独自のメインフレームは特にだめだと思うんだよね。

で、僕がWindowsも選択肢として有効だと思ってるのは、
Windowsの導入によるハードウェア変更のしやすさを考えると
（つまり、ハードウェアベンダーへの依存率を下げられる）
大きな値段だと思わないんだ。今はWindowsも安定してるしね。
つーか、MS-Office使いまくってて今更依存もくそもないと思うけど・・・

>>350
あんた学生だろ。学生が想像の範囲で書いたらそんなもんだろうな。
君のファンタジーワールドに出て来ないプレイヤーが世の中には沢山いるんだよ。
UK 抜きで洋楽の歴史を語ったり、フランス抜きで映画史を語ってる様なもんだ。

> フランス抜きで映画史を語ってる

kwsk

納得いく結論であればそれでもよいと思われ。

とりあえず、PC端末とサーバの区別くらいしろ。

>>353
勝手に一人で納得する分には良いが、他人に意見を述べるならある程度の
見識は持ち合わせているべきだと思うよ。

>>350
このスレでまともなことを言っても、
そもそも汎用機にこだわってる「フリをしている」人間が聞く耳持ってないので、無意味だよ

まともって、何の冗談だよw
>>350 がまともに見えるなら勉強が足りていないと思うよ。

この世には Windows と汎用機しか存在しないという発想が凄いね。
MS-Office しか使っていないのに Windows が安くて安定していると
言い切ってしまうのも驚き。

さぞかしシンプルな世界に住んでるんだろうなあ。ある意味羨ましい。　

調べもせずにWindowsは糞とかいっちゃう奴もいるけどな

あと業務システムにOfficeはあんま関係なくね

自分が楽できるなら何でもいいよ

>>359
>あと業務システムにOfficeはあんま関係なくね

だからそう書いてるわけだけど?

糞っつーか、サーバに使う気がしれないけどね。

>>359
誰も君のWindowsを貶しているわけじゃないよ
Windowsしか知らなければ、他に選択肢は無いもんな

なんか俺がWindows擁護みたいになってるし
まぁいいや

>>351
う〜ん。
反論はいくらでもおっけーで別にいいんだが、そのための根拠はほしい。
僕が想像しているというファンタジーワールドを351はどういう世界と思って
いて、また、そこでプレイヤーという言葉が351の中ではどういう役割を
持っていて、ここで持ち出したのか、全然わからないよ。ヒントすらない。
相手に理解されない文章ほど無意味なものってないと思いますが、いかが？
（歴史の話もどことどうつながってるのかもわからないしねぇ。）

>>354
PC端末とサーバの違いはわかってるけど、348での書き方が悪かったね。
「Windowsがインストールできるコンピュータ」に訂正しておいて。

Linux がまともだったら多くの問題が解決するのになあと思い続けて早５年…

追加
誰もWindowsしか選択肢がないなんていってない気がする・・・
選択肢として有効といっただけなんだけど。

>>365
ｽﾏｿ。でも君が理解出来る様になるまで説明するのは大変そうだ。
反論とか根拠とか、そういうのが出て来るレベルには達していないように見えるけど。
他人に騙されない様に気をつけてね。

端末のWindowsとサーバのWindowsはまったくの別物。
違いが判らない人は物知り顔で騙らないように。
端末の延長で「Windowsサーバ簡単」って言っている奴は、
ヒヨッコもいいとこだ。
片手間でセットアップした簡易サーバとエンタープライズを
一緒にするな。

>>369
別に簡単ともいってないじゃないの・・・
一度構築したシステムを停止してハードウェアを新規導入しても、
そこから同じように再構成する大変さも理解してるよ。

でも、メインフレームより移し変えは楽になる。
それが僕の論点であって、それに対して反論するならきちんとして欲しい。
根拠を示してくれないと、どうにもこうにも話にならないんだけど。

>>366
Linuxはなんであんなにだめなんだろうね。
ディストリビューション違うとインストールすらできないハード多数だし、
それならまだしも、同じディストリビューションであっても
1つでもバージョンが違うだけでインストールできないとかもあって、
ちょっとひどすぎるよね。GUI環境は便利になってきたけど・・・

何処まで行ってもデスクトップ視点なんだなw

それはデスクトップ視点ではLinuxは負け確実だから、
話題変えてくれよといういみか？

>>371
君、批判がお粗末だね。
相手を叩きのめすには、それ相応の論拠が必要なんだよ？
デスクトップ視点がどっから出てきたのかもわからないし、
そもそも、デスクトップ視点がどうしていけないのかもわからん。
システムを重々しいサーバが管理しなくてはいけない理由は何？
（たとえ話ね。僕もサーバが管理すべきだと思ってるけどね。）
そういう点に言及してくれれば、もう少し僕も大人しくできるんだけど。
批判がお粗末だから、あんまり面白くない。せっかく
メインフレーム＋COBOLの有用性を聞きに来たのに、期待はずれ。

割り込みスマソ
基幹のバッチ処理なら今でもメインフレーム＋COBOLは有効と思います。
データを扱うための機械にデータを扱うための言語。
開発基盤について考慮する必要がないため、
純粋に業務ロジック、I/Oについて記述した仕様書が書ける。
ハードの処理性能ではコストパフォーマンスの良いIAサーバーも多いと思いますが、
大人数で開発した時の開発期間、精度はこれにかなわないと思ってます。

オープン系は業務システムでの実績はまだまだ浅いのに、
メーカー系のSEたちは無理してOOPで設計し珍妙な仕様書が回ってくる。
UMLだけ出されても困るし、独自のユニークな仕様書はもっと困る。
せめてサーバー側処理だけでもRDB＋ストアドにしてくれればいいのに。

業務システムの仕様書（詳細）で一番大事なのはI/Oだと思ってます。
「伝票ヘッダは伝票明細と関連があり、伝票入力画面でDBにI/Oをかける」
とかいう説明に何ページかけてるのやら・・・。
オープン系に慣れたベテラン業務SEが充実してくるのはまだまだ先の話と思われ。
COBOLの設計ノウハウには全然かなわないと思います。

>>370 >>372 >>373> >371とは別人です。
LinuxデスクトップはUbuntuに統一されそうだから、
それはそれでいいのでは。インストールはWindowsより楽だし。
ここは業務システムをオープンシステムに置き換える意味があるか
というスレです。UNIX系だと数十台、場合によると数百台の
クラスターといった構成になる。ここで#1-#8はRHEL、#9-24はSuse
#25-64はDebian なんてことはあり得ない。
だからディストリビューションが云々なんて言うと、
あっ、デスクトップ視点ね、と思われても仕方がない。

>>375

>>統一されそうだから
はぁ？
DELLが採用したからってんなわきゃねぇだろ

>>373
自分に叩きのめされる価値があると思ってるのが哀れだな。
君の書き込んでる内容はどこからどうみても素人の書き込みなんだよ。
素人に許されるのは「おかしな事を書いているかもしれませんが、どうか
教えてください」だけだぜ。下らん御託を並べても君の為にならないよ。

理解出来ないのであれば、それは君の所為であって、他の誰かに食って
掛かるのはお門違いだ。悔しいのかもしれんが、態度だけでかくても
成長はしないぜ。

>>376
たしかに。統一は適切な表現ではなかったね。
せいぜい、一人勝ちくらいかな。

>>376
デスクトップ部分しか突っ込めないのは、このスレ全体の傾向なのかw

>>378
確かにLINUX標準搭載のPCでは暫くの間1人勝ちしそうな気がする

1から読み返したんだが、
どう考えても>>1の会社はボられてるよなぁ……

MSに依存するのもIBMに依存するのもコスト高。
でもベンダー一社の方が、バグ解決も速かったり、力技で対応してくれたりするのも事実。

>>381

感覚だけで言わないで、成功事例をお願いします。

>>1
これといったメリットなんてない。
所詮は商売。新しい物を売ってなんぼ。

フランス抜きで映画史を語っても問題あるまい。
フランスの映画なんか名作なんてないし。
売れねーし。
唯一の例外は
エマニエル夫人くらいなもんだろ。

ハリウッド映画よりはましでしょ。

LinuxってのはHPのハードを安く使うためにあるんだろ

>>385
スクリーンに映す映画を発明したのはフランス人だし、最初に映画を公開したのもフランス人だよ。
つまりフランスは映画の祖国なわけね。ヌーベルバーグとかも知ってるでしょ。ゴダール、トリュフォー、
メルヴィル、ルノワール、ルイ・マル、リベット、タチ、ドゥミ、アノー、ルコント、ベッソン、ジュネなど
有名監督も沢山いる。名作かどうか分からんけど「冒険者たち」は一般にも面白いと思うよ。

ハリウッド中心の世界の映画産業の中でフランス映画は主要なオルタナティブの一つだね。

セブン銀行 銀行勘定系システムに Windows Server を導入
http://www.microsoft.com/japan/showcase/sevenbank.mspx

汎用機遅いよね

中小経営者が無駄に汎用機買わされてるのを見ると腹立たしくなる事もある

汎用なんだからいいじゃん。

昔の意味で「汎用」だからな。
オープンの方がよっぽど汎用的。

>>391
騙される程度の才覚しか無いのが経営者を騙るなかれ。

汎用機とかは保守とセットじゃないとあまり意味無いんじゃね？

ＰＣヲタ一人雇うお金以下で汎用機のレンタル、保守料金がまかなえれば
それで問題ないと考える経営者も居るんじゃね？

>>395
夢見すぎ。
冷房費だけでどれだけかかると…w

>>373
＞メインフレーム＋COBOLの有用性を聞きに来たのに、期待はずれ
結局は根本は人なんだよ
開発者や関係者の質が違う

オープン系のアバウトさを考えればわかるだろ
無責任・個人主義のゆとり世代が開発・運用する基幹系
オープンシステムなんてナンセンス

オープン系マンセーで目立つのは
開発や運用コストの比較といった狭い視点だけっていうのがいやになるね

コストと投資の違いがわかっていない

情報システムは設備投資であって、設備投資コストがかかっても
それなりのリターンが得られればいい

結局、長い目で見て企業活動の基盤を絶対的信頼性と実績を持って
支えられるメインフレームはあと半世紀は消えることはない

費用対効果の問題を費用だけで語るナンセンスさが
オープン系の連中の浅はかさとアバウトさがでててるよね

はっきりいおうか
汎用機を使える余裕のないへぼ会社はオープン系へ

そういう２極化がおきるだろうね

ある意味汎用機を運用しているかいないかってのはその企業の
現状の実態を表している

>>398
とりあえず、コストでは太刀打ちできないとやっとこさ理解して、
ひねり出した屁理屈が、「コスト」から「投資」への言葉のすり替えか。

プロプラが、オープンより投資のリターンが大きいという根拠はなにかあるのかい？

つーか、レス自体が、費用対効果について、前半で肯定して、後半で否定してる電波レスで、コボラー脳の限界を感じるが。

>>400
まず、はじめに私の立場を言っておこう
現在はＪＡＶＡなどのＷＥＢ開発をしていもと汎用機のＣＯＢＯＬ
経験者だということだ

＞プロプラが、オープンより投資のリターンが大きいという根拠はなにかあるのかい？
絶対とめることのできない金融系のＷＥＢ開発でなぜ
フロントエンドはＷＥＢ、バックエンドはレガシーシステムといった
開発がなされるかわかるかい？

根拠はそこにある。現時点でオープン系のシステムはまだ歴史が浅すぎるんだよ

>>400
＞とりあえず、コストでは太刀打ちできないとやっとこさ理解して、

いやだから、企業活動をコストの視点だけで論じてる
視野の狭さを指摘してるわけで

企業の１サイクルというのは30年と一般には言われている
そのサイクルをミッションクリティカルに支えるづける
長期的基盤を安定的に提供するための
実績はオープン系にはないし、最低この問題を語るには
目先の損得だけでなく30年サイクルで見るような視点が大事だって

あたりまえだろ？

しかし、>>400はオープン系のアバウトさがでてるレスだね

ミッションクリティカルな基幹系システムでは
損得よりも安定性が優先されるのは当たり前なんだがな

オープン系の連中は汎用機も運用できないような貧相な顧客の相手か
チンケな情報系のシステムしかやらないから

大手のユーザー企業さんが顧客への信頼性、社会的責任をどれだけ
背負ってるか理解できないんだろうね

ラーメン屋の顧客管理システムが障害で停止しても
社会全体の影響は知れてるが

ＪＲの基幹システムが停止すればそれは
国家経済の損失になる。

まあ、オープン系の連中はこの辺を語りだすと頭から煙が出てくるからなｗ
この辺でやめとこう

どうでも良いから sage てくれよな。書き込みする際にメール欄に
sage って入れるだけで良いんだ。君でも出来るよね?

sageもできないCOBOLerが、頭から煙を出してスレを荒らしてるみたいだけど。

リターンが「安定性」だけで決まるとは、ずいぶん牧歌的な世界に生きているみたいだな。

その安定性だって、まともに作ったオープン系システムと汎用機ベースとの差は微々たるもの。
そんな差は、運用要員のくだらないミスやその他のリスクで、誤差に収まってしまう。
その誤差に年間数億の出費の価値があれば汎用機にしがみつくのもいいかも知れない。

だが、現実世界では、それは算盤に合わないと判断する会社が多いから、汎用機の売り上げが落ちてるわけだ。

それでも汎用機が残ってるのは、安定性というより、お抱えCOBOLerの仕事を作るためとか、
カオスで動いてる現在の汎用機システムに手を付けられないとか、の理由を無視できない。

>>406
＞リターンが「安定性」だけで決まるとは、ずいぶん牧歌的な世界に
これはひどい

その言葉そのまま返すよ。驚くほど発想が貧困だな
１度の障害が企業活動と企業生命を脅かしかねない
それがミッションクリティカルな業務なんだからさ

たとえば銀行が定期預金の利息計算や満期の払い戻しの計算ミスを
大量にしてみろ。社会的信用は地に落ち銀行免許取り消しになりかねない

君はシステムアナリストには向いてないね。それだけはいえる。

>>406
＞sageもできないCOBOLerが
日本語読めないほうが恥ずかしいな

sageるさげないは別に強制でもなんでもないしｗ
会話する以上、日本語読めないのは痛いな


401 ：デフォルトの名無しさん：2007/09/27(木) 00:41:40
>>400
まず、はじめに私の立場を言っておこう
現在はＪＡＶＡなどのＷＥＢ開発をしているもと汎用機のＣＯＢＯＬ
経験者だということだ

>>406
＞その安定性だって、まともに作ったオープン系システムと汎用機ベースとの差は微々たるもの。
いちいちひどすぎる

汎用機は高度成長期の初めからもう４０年、企業の基幹業務を
支えてきたわけでそれだけの信頼性と実績がせいぜい
古くても１０年のオープン系にあるとは
これは凄い理解度だなｗ

オープン系への以降が進んでるのは
決してオープン系が汎用機に匹敵するほどの信頼があるから
じゃないからね

グローバル化による激烈な国際競争が企業にコストダウンを迫ってるわけで

ある意味、余裕のない企業は信頼性を犠牲にしてまで
オープン系に移行、コスト削減をしいられてるってことだからねえ

まあ目先の金浮かしたところでどうなんだか
追い詰められた企業の消極的選択だな

ひどい釣りだなぁ。
頭からもうもうと立ち上る煙で脳が逝っちゃってるんじゃないか？

＞＞リターンが「安定性」だけで決まるとは、ずいぶん牧歌的な世界に
っていう簡単な日本語もまったく理解できてない。

この文は、「システムのリターンは極めて多面的あり、
それを安定性の一点に限るのは愚か」と指摘したものだ。
システムのアップタイムが100%になったところで、客がいなきゃガラクタに過ぎない。リターンは０だ。


＞汎用機は高度成長期の初めからもう４０年、
＞古くても１０年のオープン系に

ほう、安定性とは古さの事ですか。ずいぶんパラダイスな脳をお持ちですな。

Googleが同社の収益の源であるLinuxベースのそのシステムを止めたのは見たこと無いけど、
ここ数年だけでも、メインフレームベースの東証も止まったし、マルスも止まったねぇ。


＞現在はＪＡＶＡなどのＷＥＢ開発をしているもと汎用機のＣＯＢＯＬ経験者

以前、COBOLerの書いた拷問のようなJavaソースを見たことあるが、
あれで本人はCOBOLer卒業と思ってたんだろうなぁ。


＞グローバル化による激烈な国際競争が企業にコストダウンを迫ってるわけで

なるほど。お前が言いたいのは、「みんな、共産主義国家に行って汎用機やろうぜ！」って事か。

通りすがりだけど、Googleのシステムを汎用機に置き換えることは
現実的じゃないだろうなー。それに、あんなに頭がいい連中が多いんだから、
もしも汎用機に置き換えることがベターなら、奴らはそれをやっているだろうし。

>>408
>sageるさげないは別に強制でもなんでもないしｗ

空気が読めませんて事か?
であれば仕方がない。

たまにこういう奴が湧くよなあ。
いい大人なんだろうに…

>>411
おいおい、ほんとうにどうしようもないなあ
ひとつづ回答していくよ

＞この文は、「システムのリターンは極めて多面的あり、
多面的であっても優先順位はあるでしょうにｗ
ミッションクリティカルな基幹業務ではまずなによりも絶対的な安定が要求される
なぜ之だけオープンシステムが活性化しているのにいまだに汎用機とそのレガシー資産が
が現役なのかまったく見えていない意見だな。

あんたはビジネスでは顧客満足が一番とわかっていながら
それを基盤から支える基幹システムの重要性がわかってないのではないかな？

基幹システムが障害で停止してまともに振込みができない銀行でなんで
顧客が満足するの？ｗ安定性は当たり前だが一番重要なはずせない
要素だって馬鹿でもわかるだろｗ顧客の満足度を考えるならね

オープンカーと同じ。
イザというとき、(サポートが受けられなかったり素人が作ってたりして)脆い。

なんとなくいい気分になれるってだけで、車としては欠陥であるように
クリティカルな場ではオープン関係は使えない。

>>414
私は振込手数料が安い方がいいな。本気で。

>>414
＞ほう、安定性とは古さの事ですか。ずいぶんパラダイスな脳をお持ちですな。
実績だといってるでしょうに・・・勝手に古さとかに摩り替えないように

＞Googleが同社の収益の源であるLinuxベースのそのシステムを止めたのは見たこと無いけど、
グーグルっていつできた企業だよｗしかしこれで根本的に理解不足が露呈したね。＾＾
まず情報系と基幹系の区別すらついていない
あとはなからオープンシステムでやってる新しい会社の話を出すこと
自体わけわからないね。どう考えてもこのスレの前提は今基幹システムを
動かしているそれなりの歴史ある企業さんのシステムなんだろ？

そんなに必死にならずもっと落ち着いてレスしてほしいな＾＾

＞ここ数年だけでも、メインフレームベースの東証も止まったし、マルスも止まったねぇ。
あっそそれって別にメインフレームだからそれが原因で停止したとかいうわけでもない
信頼性や実績に絶対はない相対的な比較なんだからオープンシステムとの
比較になるわけｗあんた何と比較してるのｗ

比較対照にグーグルのシステム持ち出してるわけだから
わかっていなんのはしょうがないんだろうけどねえ＾＾

まあ君もそういうグーグルみたいなとまっても国家的影響が出ない
会社のシステムの話を持ち出してちょっと勘弁してほしいなあ

グーグルのシステムが停止したところで東証システム停止のような
社会的問題にはならんだろうに・・・。
ミッションクリティカルとか基幹系という意味がわかってない

まさにアバウトオープン系のおおらかな発想だね

>>411
＞以前、COBOLerの書いた拷問のようなJavaソースを見たことあるが、
＞あれで本人はCOBOLer卒業と思ってたんだろうなぁ。
おいおい短納期のＷＥＢ開発できれいなソースなんて見たことないよ＾＾
だいたい基幹系であってもきれいなソースなんてめったにお目にかかれない

少なくとも君は開発関係者じゃない冷やかしか？
経験３年以下のプログラムを芸術と勘違いしている程度の初心者だと
わかる意見だな　こりゃｗ　ひどい

オープン系の開発現場では開発途中のソースコードの
管理ができてない何って事も普通にあるｗ

メンテンナンスではどれが最新のソースコードかわからない
なんてこともあったなあ

汎用系では絶対ありえない話

まずソースコードは最低限エンドユーザーの資産だということを認識してくれればね
実務経験者としてはソースコードがきれいか汚いかなんてどうでもいいよｗ
ただソースの管理だけはしてくれよｗ

>>411
＞なるほど。お前が言いたいのは、「みんな、共産主義国家に行って汎用機やろうぜ！」って事か。
なんだこの一文は・・・。

結局、目先の損得しか見えない、語れない脳が丸出しだな
まったく話についてきてない

君みたいなやつは安く毒いりの中国うなぎや
格安で落ちる飛行機や、営利重視で脱線転覆事故起こす電鉄会社の
電車乗ればいいだろ

少なくとも君の人生がどうなろうが社会的影響はないだろうが
今話しているのはミッションクリティカルな基幹業務システムの話なんだぜ？

ミッションクリティカルがどうとかうざいことこの上ないが
止まって困るようなところはたとえ止まっても潰れない

だから十分な技術の蓄積があれば何だっていいんだよ
オープン系やってるようなところで
オープン系の根幹から理解してるようなところは少ないだろうけど

＞止まって困るようなところはたとえ止まっても潰れない
そんなところが止まれは国家や日本経済が死ぬな
自分はつぶれないから社会的影響がどうなろうとしったこっちゃないよ〜

なんて発想はもうシステムどうのこうのいうよりも
モラルハザードもいいとこ、さすがオープン系カルチャー＾＾

自分はつぶれないからいいよ〜で
東証が１週間でも停止したら世界的金融パニックの引き金になりかねない

やはりオープン系の発想はアバウトすぎる＾＾

ほんとのほんとにぶっちゃけたこというと、
金融系の基幹システムも、ぽこぽこ落ちてるよ数年に1回ペースで
汎用機だなんだいっても、想定外のシステム負荷には脆いもんだよ
とはいえ数年に1度を想定しちゃうとお金がいくらあっても足りない・・難しいね
オープン系と比べて汎用機が安定つってるのは、あくまでハードウェアの世界の話ね

俺別にオープン系擁護じゃないからお間違え無く
オープン系の場合、毎月のようにハード障害・交換。これはガチ

>>424
一分一秒を争う基幹システムの復旧で
システムダウンのとき最初にハードの問題じゃないと切り分けやすいのは
それだけで利点だよね

オープン系だとそうはいかない
いろんな要素でシステムが構成されていてある特定の場所なのか
あるいは複合的な要素でそうなってるのか？
いろいろと切り分けが大変だ

明確に違うと書いておこう。
オープン系もピンキリだ。
ちゃんと高いUNIXサーバ使え。

>>426
後、オープン系誤解してる。
汎用機は一品主義で１台の中で可用性を高めているが、
オープン系はHAクラスターで可用性を高める。
だから、サーバダウン＝サービスダウンではない。
ちゃんと設計されたシステムでは、使用者に障害を気付かせないよ。
それと一次復旧と二次復旧を分けて考えなさい。

>>428
誤解してる以前に話の内容を勘違いしている

あきらかに障害防止の仕組みの話なんかしてないでしょう

ああそうか
＞金融系の基幹システムも、ぽこぽこ落ちてるよ数年に1回ペースで
これはサービスダウンを言ってるわけじゃないのか？
でも落ちるなんて表現は誤解を招くぞ

落ちるといえば大抵システムダウンを連想するよ

コボラーがどうして駄目かよくわかるスレだな。
古ければ正しい、若いのは駄目、ソースは汚いのが正しい。
なにより、ビジネスの広い視点がまったくなく、盲目的に安定性しか言わない。
いくらハードやＯＳが安定して立って、システムなんて人間のミスで簡単にトラブルのに。

>>429
安定性の話の流れで可用性の話が否定されるとは・・・ちょっと絶句。
解説してあげると・・・
>>426が「一分一秒を争う基幹システムの復旧で」と書いているが、そもそも
オープン系は多数のサーバで可用性を確保しているので、サーバ停止が
即サービス停止にはならない。
つまりシステムは問題なく稼働し続ける。
だから、「一分一秒」だとか「基幹システム」だとか、そんなのは否定要素に
なりえない。
そして、切り分けの話については>>427でﾚｽ付けているが、ちゃんとした機械なら
OSがきちんとログ吐くのでハードかどうか切り分けができる。
もし万一、デバイスドライバーとかの低位レイヤーの問題で切り分けが付かない時でも、
デバッグ用の情報はログに吐かれているので、とりあえず部品を交換したあとに
ベンダーに解析させればいい。
部品交換中だろうが何だろうがサービスは続けられるんだから。

WindowsやLinux等のIntelArchitectureだけがオープン系ではないぞ。
まぁ、少し前からメインフレームみたいに全部品をサーバH/W側で二重化した
ftサーバなんてものも出てきたから、IAサーバでもかなり詳細なログとれるように
なったけどね。

ちなみに>>424は私ではないよ。

もう絶対的信頼性と実績の維持のためだけに、高いコストを負担してまでメインフレームを使う時代は終わった。
価格には適度という物が有る。いつまでも高価格じゃ企業は存続しない。
メインフレームしか使えないコボラーなんて寄生虫なんだよ。

Javaや.NETでも安定性は確保できる。つフォールトレラント
JRの基幹システムも未だにメインフレームじゃないでしょ。
メインフレームの高額費用の維持のためにリストラしまくらないと潰れるじゃん(w

銀行こそコストに敏感だからメインフレームからの脱却が進んでいるけどな。
化石のメインフレーム使っていて、最新のネットバンキングとか携帯に対応できる訳ないし。
メインフレームでIEが動くのかい？　自社のネットバンキングすらログインできない(w

銀行や保険の計算ミスって割と良く有るけど、メインフレームだと、 １度の障害が企業活動と企業生命を脅かしかねないミッションクリティカルな業務で、社会的信用は地に落ち免許取り消しになりかねないのではなかったの？

コボラーは単にスキルが低いからハードの切り分けが出来ないってだけか？
小学生からやり直せばおk。おまいこの業界向いてないよ。

メインフレームの高額費用は賠償金を払うときのための保険

>>433
オープン系の一員として書くが、こういう頭の悪い発言はやめてくれ。
> メインフレームでIEが動くのかい？
業務サーバ上でクライアント機能が動く必要はない。
というか、むしろ重要なサーバ上で一般業務をするな。

メインフレームの主張でよくコスト効率の話が出るけど、
最近はだいぶ限定的になっているよね。
メインフレームは、後からの拡張性に乏しいので最初に
キャパシティを決めて購入・構築になる。
で、足りなくなったら数億以上の金と長期間かけて増強・・・。
もちろん、余裕をもってキャパシティプランニングするんだろうけど、
当然余裕分は余剰投資になるわけで・・・。

安定成長分野でないと使いにくいよね。
金融系の従来業務とか・・・ね。

金融でも新しい決済関連（電子マネー等）とかの急成長分野は、
メインフレームでは辛いでしょうね。
大きいの入れても売れなかったら、どれだけの損失になることか・・・。

柔軟な拡張性と短期間での増強・展開はオープンならではと思う。

でも伝票打ちのおばちゃんにはWin等のPCでは無く端末機が良いなと最近思う。

よくわかっている人はメインフレーマーという
何も知らないお馬鹿なやつほどコボラーという

ソースコード管理やシステム設計など開発のノウハウは
メインフレームの資産から学べることは山ほどある

所詮コボルプログラムなんて
サーバーサイドＪ２ＥＥ（ＪＡＶＡ）で言えばＭＶＣモデルのＭの部分に過ぎない

ＪＡＶＡでバッチフレームワークを組むときメインフレームのＪＣＬ起動の仕組みを
参考にさせてもらったがあれはすさまじく理にかなってる

コボルだけ見てああだこうだ言いってるのは
フレームワーク上でビジネスロジックしか書かない
最近のなんちゃってＪＡＶＡプログラマーとしか思えないな＾＾

ああ、僕の中では
コボラー＝ビジネスロジックしかできないＪＡＶＡプログラマーだからね＾＾
目くそ鼻くそを笑うとはよく言ったもんだ

フレームワークでＤＢ接続部分の共通部品を作ってくれと仕事任せたら
上司連れてきてそんなことできるかと開き直って
自分ができないのを俺の責任にしようとしたいつかの自称ＪＡＶＡ
プログラマーを思い出すよ

まったく
ＳＱＬパッケージやリフレックスパッケージも知らないで
なにがＪＡＶＡプログラマー何だよって頭痛くなるね

>>433
どこからのこぴぺだｗ１０年前からそういう意見は耐えないな
でも汎用機は健在しているのが現実ｗ

>>432
＞オープン系は多数のサーバで可用性を確保しているので、サーバ停止が
＞即サービス停止にはならない。
なにを必死になってるのかしらないけど
ダウンしないシステムなんかない

ハードウェアの構成だけでああだこうだ言ってるみたいだが
ソフトウェアとかいろいろこける要素は多分にあるんだがな

>>431
＞古ければ正しい、若いのは駄目、ソースは汚いのが正しい。
へ〜だれがどこでそんな主張をしたの？
具体的に指摘してくれないかな＾＾

オープン系の連中はソース管理どころか自分が口に出す言葉も
まともに管理できない＾＾事がよくわかるレスだね

>>432
＞安定性の話の流れで可用性の話が否定されるとは・・・ちょっと絶句。

障害の復旧時の原因追求の話を安定性の話の流れで可用性？？？

オタが自分の知ってる知識ひろうしたいのはわかるけどね＾＾
無理やりすぎますよそれは

>>そして、切り分けの話については>>427でﾚｽ付けているが、ちゃんとした機械なら
>>OSがきちんとログ吐くのでハードかどうか切り分けができる。

できるできないの話はしてない
そういう障害復旧時の原因追求のきりわけのやりやすさの話をしているだけ
＾＾どうしてこうオープン系は日本語で会話不能な人が多いんだろうか

>>431
＞古ければ正しい
ＪＡＶＡやオープンやＷＥＢ系が昨日今日にでてきた技術だと思ってるのかねえ

ＪＡＶＡにしても最初のＪＤＫがリリースされたのがもう１０数年前
本格的に使用されはじめたのが１０年前ぐらいから＾＾

いまつかわれてるのはその実績を評価されてるからなのにねえ

汎用機に手が出せなかった中小零細企業が、オープン系の登場によって、
なんとなくそれらしいシステムを利用することができるようになった。
ってことでいいじゃん。
汎用機使ってる企業がオープン系に移行する必要はないと思うよ。逆に、
オープン系から汎用機へのステップアップはあると思う。

>>445
>オープン系から汎用機へのステップアップはあると思う。
これを退化だと捉える一派の声がでかすぎてウザいって事かと。

>>442
> ＞安定性の話の流れで可用性の話が否定されるとは・・・ちょっと絶句。
> 障害の復旧時の原因追求の話を安定性の話の流れで可用性？？？
一分一秒の状況下での復旧の話だろう？>>426に書いてあるよね。
あのさぁ・・・君もプロならさぁ・・・。
起きる前に対処するって鉄則ぐらい知っているよね？

それと、そもそも>>242を含めて、それ以前の流れは安定性の話の流れだったよ。
唯一、>>426が一分一秒の状況下での切り分けの話をしていて、
ちゃんと冗長化しろよってレス付けられたんだろうが。

ふと気づいたんだけどさ・・・。
メインフレームの連中は、監視システムについて何も知らないのか？
ハード・ソフトの切り分けどころか、オープン系は機能分散と個別サービス監視して
いるから、アラート上がった段階でだいたいの障害内容が把握できるんだが。

もちろんちゃんとしたエンタープライズでの話だがな。
小さなシステムしか見たこと無いの？

どうもオープン系に対する前提知識がなさ過ぎると思ったんだ。
メインフレームと小さなシステムのオープン系比べて、比較するのはみっともないと思うよ。

>>445
昔の金融業の基幹系におけるメインフレームの使用率は、ほぼ100%だった。
で、今は、何割なんだろうね。

ム板でこういう事書くのもどうかと思うけど･･･
アプリ部分で比べるのはどうなんだろう？
メインフレーム互換のトランザクションシステムとかCOBOLとか、
オープンでも動くよ。誰も使わないけど
逆に最近は、メインフレームでLinuxとかWEBシステムだとか流行っているよね？
で、どこらへんがメインフレームなの？
そもそもハードウェアにしても、メインフレームだって分散系だしねぇ
非力なCPUの代わりに、ストレージやらI/O制御装置やらで処理させているだけでしょ
H/Wレベルで分散しているか、機能単位で分散しているかの違いでしかない

>>447
＞起きる前に対処するって鉄則ぐらい知っているよね？
知っているが、起きた後の復旧の話をしている

話題とかけ離れた話をしたければ
別すれでやるか、一人でつぶやいてろ

いいかげんうっとおしいですよ＾＾

ageんなボケ

無駄だって。周りを見て sage られる様な人間ならとっくにやってるよ。

>>450
おまえがｶｴﾚ!

セブン銀行 銀行勘定系システムに Windows Server を導入
http://www.microsoft.com/japan/showcase/sevenbank.mspx

UNIXは昔から使われているんだけどね。
Windowsでやるからニュースになるんだろうなぁ・・・。

【新聞/IT】神戸新聞のシステム障害はオラクルDBの問題、修正プログラム配布へ　〜システムは神戸新聞がNECと共同開発　[10/01]
http://news21.2ch.net/test/read.cgi/bizplus/1191209754/-100

こんな胡散臭いものが基幹システムを担うんだって？

ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

上記すれより抜粋

53 ：名刺は切らしておりまして：2007/10/01(月) 15:06:17 ID:MrYTE1Tg
なんかOracle擁護が多いが、
そもそもDBがabortだろうが強制リセットだろうが電線切ろうが壊れる方がおかしい。
考えてもみろ。
銀行やいろんな窓口業務のDBが何かの理由で壊れたら数千億レベルの損失くらい簡単に出る。
だから普通は、ジャーナルログを取ってて異常時に旨く反映されてないものは反映する仕組がある。
それを検索中に強制終了でDBが壊れるなんて絶対にあってはならないこと。
運用以前に、どう考えてもOracleが戦犯だろ。

ジャーナルログがディスクに吐き出される前に死ぬことは無いの？

・ストレージそのものは多重化
・ジャーナル出力もトランザクションの一部

OracleつってもJDBCのドライバ周りは良くバグってるよな
Oracle擁護ってわけじゃないけど、インストールにしたってパッチの数が
ハンパじゃないし、よくよく動作確認したうえでサービス開始しないと
単にOracleがバグってましたつってもSIerの責任は重いと思うが

汎用系・・・信頼性高い、コスト高い
オープン系・・・信頼性低い、コスト低い
を踏まえて、好きなの選べばいいんじゃね？
市場規模的には、信頼性低くていいから安くしろってのが大勢。

Win+Oraの単独サーバなんていう最弱を基準にされても困るな。
第一、汎用機も不具合多いぞ。
ちなみに金融機関での話。

>>461
基幹業務は汎用機で
あったら便利システムはオープン系で

ってことか？

>>462
汎用機の不具合って、まさかプログラムミスのことか？

PGMの不具合なんてもっと沢山あるだろ。
ミドルウェア（DBﾄｶ）の話だよ。

>>462
＞第一、汎用機も不具合多いぞ。
オープン系信者が涙声で問題を単なる不具合に抽象化してごまかし始めましたｗ

>>464

基盤部隊に訊いてごらん。

オープン系だとゲームが出来るから最強

業務時間中に緊急停止スイッチでピンポンダッシュ。
そしてそのまま鬼ごっこ。
これ最強！

ついでに携帯電話の電源も落としとこうぜ
対応するのめんどくせ

ピザのデリバリー受付システム → オープン
地銀のATM → オープン（止まっても社会に大きな影響はないし）
都市銀行のATM → 汎用（止まると経済にちょっと痛みが出るよね）
山手線の管理システム → 汎用（止まったらヤバイ）
釧路電鉄の管理システム → オープン（迷惑かけた人に煎餅配れば大丈夫）

みんなソフトウェアに頼るのを辞めて紙媒体に戻せば止まるとか気にしないでいいと思うんだぜ

どこぞの年金記録の二の舞になりそうだなw

ミスをしなければ大丈夫

>>473 天才だな

バグが出た時にSEが取った対策
「みなさん、細かいミスをなくしましょう」

と言っただけだった

オープン系、まともなとこはもう見切り付けてる。

どうせ根拠を示せないんだから、適当な事は言わなければ良いのに。

２０００年問題にしても
年金漢字カナ読み変換プログラムにしても
根っこは同じ
その当時に考えられるベストな(少なくとも誰もがそう思っていた)選択結果が
将来ベストじゃなくなるどころか
責任を追及されるような事態になる
こんなことで設計やってられんよ

コボラ以外はだれもベストと思ってなかったわけだが

コボル以外で1億人のデータ管理出来るDBがあったか

コボルはDBだったか

要はなんでもいいからちゃんと作りこめればいいわけだろ
その意味でCOBOLが今までのノウハウがあってバグを出しにくい、
コスト的にも保守性でもそういう蓄積があるから総合的に優位って事？
（幅が広すぎるオープン系に比べて人材の質に左右されにくいというのもあると思うけど）
んで今は将来的にどこまでその費用対効果が有効かって事を議論してるって事でいいのかな。

まあなんていうかどんなハードだろうが言語だろうが作る人次第だと思うんだけどな。

人材の質に左右されにくい

これも良く聞くけどインチキくさい言葉だよな
もれなく最低の生産性ってことじゃん

ｺﾋﾟﾍﾟｺﾎﾞﾗｰほど使えないPGはいない

オートクチュールかプレタポルテかの違いかな

ロジックの中身を考えずにｺﾋﾟﾍﾟしてくる神経がわからん。

昔コボルを使用していたマシンの更新時期が来たから、
またコボラーの需要が増しているだけ。
ちょっと前はコボルの仕事なんて全然なかったよ。
旧新更新がひと段落つけば、コボラーはまた失業だな。

http://news21.2ch.net/test/read.cgi/bizplus/1192331270/

１）COBOLER（コボラ、コボラー）

　業務知識が豊富である反面、言語知識は最低限である場合が多い。
　上流工程向け。今となっては希少な存在。
　年収は３００万〜１２００万程度である。

２）オープン系技術者（ソルジャー）

　仕事と趣味を混在させることが多く、更には自覚がない。
　変わりはいくらでもいると思いきや、想像以上にハズレが多い。
　仕様書に書いてあるより「上（設計）の事」には想像をめぐらすことが出来ないが、
　仕様書より「下（手段）の事」にはこだわりがある。
　年収は２５０万〜４５０万（４０歳）程度である。

>>487
ちょっと前はオープン系に夢を見ていたからオープン系の案件ばかりであった。
今は、心臓部分はコボルが安心かも知れない、という風潮の兆しがある。

>>490
>心臓部分はコボルが安心かも知れない

ﾜﾗﾀ

COBOL（笑）

ぶっちゃけ業務知識なんざそこの職場で一ヶ月も働けばどんな馬鹿でも身に付く

>>493
お前の言う業務知識ってなんだ？

>>489
それって、ただ単に、
COBOLやっている人＝ほとんどが年寄り。
業務知識が多いとか単に年の功ってだけの話だよね。

>>1
この広い世の中、
操作性が大事な人もいる。
RomPa！

処理速度は圧倒的にオープン系の方が速いよ。

>497
だね。速度ならエンタープライズUNIXのが速いよね。
ただ、処理結果の信頼性ではメインフレームのが高いけどね。

個人的にはどこともつなげたくないクローズドシステムならメインフレームのままでいいんでない
シームレスなシステム関連携とか考えるとオープン系のが色々と便利だけど。
まぁメインフレーム上でもJavaとかMQとかのMOM製品使えるからJMS連携でもかなりいけるけどね。

が、やはりシステム間連携を考えるとオープン系になっちゃうかな。
単純な連携じゃなく、BPMとか考えると、現状ESBもEAIもメインフレームとの連携ではパフォーマンスイマイチだし。

処理結果の信頼性？
それはユーザアプリがエラーハンドリングしていないからだろ。
まともなPG雇え。

>499
ん？単純にCPUの話だけど。
IBM系のメインフレーム用CPUは、１つの計算を2回やってそれぞれの結果を、
別のキャッシュに格納し、結果を照合して合っていればOK間違っていれば、
再計算して結果が正しくなるようにしているらしい。
なんで、CPUはエンタープライズUNIXと比較すると遅くはなるけど結果に対する
信頼性はメインフレームのが高いんだそうな。

まっ少し前の話だから今はどうだか知らんがね

それは冗長化の話の一部だね。
zは検算でエラーがあると壊れたCPUを切り離して、あらかじめ用意してある予備CPUで再実行する。

オープン系で言うところのftサーバ

冗長化の話ではなく、単純にCPUの演算処理の話
１つの演算に対して必ず2度演算するって事らしい。
IBMのサイトに解説があったんだがURLを失念してしまった・・・・

冗長化そのものじゃん。

冗長化というかソフトエラー対策だね。
（バグや故障のことじゃないよ）

そういえば原発の臨界事故のときに数km離れたとこにあったサーバで
まさにその時間にメモリのECCエラー出まくった事があったね。

２つとも同じ間違いをしたときはどうするんだろうと

>>507
それほどの劣悪環境を仮定するなら、3系にすればいいだけ。

2 機のプロセサが異なる回答を弾き出した時、世界が分岐する

汎用機の経験はほとんどないけど、AS/400（今はSyetem i、IBMのオフコン）
は結構長くやってた。
たぶん、AS/400と汎用機って似たような状況だと思うんで、その時の不満
、不安だった点は、
１．ダブルバイト文字の前後にx0E,x0Fが必要。オープンとのデータ連携の場合、必ず問題に
面倒。
２．英小文字が扱えない。（厳密には扱えるが、既存資産の問題で、何かと
不都合があるケースあり。）
３．技術者がAS自体に関して、不勉強。ASも進化はしているので、知識さ
えあればできるのに、技術的に不可能なんていったりする。業務知識なんて
いうけど、たいていの場合は、その会社でしか通用しないレベルの場合が多
いような。（まあ不勉強な香具師が多いのは、オープンも同様ですが。）
４．SE、PGの確保が難しくなりつつある。

CUIに関しては、あんまり問題だとは思わなかった。VB,Excel,Access等
との連携もわりに簡単にできたし。

けちはつけましたが、長所もあり、AS自体はいい機械だったと思う。
（汎用機も似たような感じだと想像してます。）

一番問題なのは、４じゃないかな。

本当に必要なら育てる。でも、育ててないということ。

>511
ベンダーからすりゃあんまり金にならないからね（保守需要はあるだ
ろうけど）。

若い人は「汎用？何それ(笑)」って感じだしな

レガシーだからな

>>508
劣悪環境なら2つ答えが同じになるより違う答えになる確率の方が高いと思う

もし同じ間違いになるならある一定の傾向を持った劣悪な環境を想定すべきで
さらにそうであれば3つめのCPUを持ってきても同じ間違いを起こす可能性大

CPU１個あたりの正答率が50%以上あるなら意味がある。

>>515
エラーが検出できれば再計算なりなんなりの処理ができる。
（そもそも2つだとエラー検出までで訂正はできないし）。

そうして、
どんな環境を仮定しても、2つが同時に同じ間違いをする確率より
3つが同時に同じ間違いをする確率の方が常に（一般的にはかなり）低い。

>>507 は同じ場所を同じ値に間違ったらエラー検出も出来ないと言っていたの？

ほら指名されたぞ、答えろよ>>507
>>518がどう解釈したのかも気になるけどｗ

>>507

各命令毎に調べているのではなくて・・・と言うか
今時の豪勢なプロセッサーは賢くてプログラムに影響ない範囲で
同時に何命令も処理しますから
一つの命令で>>107氏の心配するエラーが出ても
同時に実行される他の命令でエラーが検出できる仕掛けかなとか思いましたが

ググッて見たらRAS design for the IBM eServer z900　
http://www.research.ibm.com/journal/rd/464/alves.html
なんてのがあってその中に

The two engines execute each instruction in lockstep.
The output of the engines is compared at checkpoints,
and any mismatch causes the PU to retry from the previous checkpoint.

check-pointとcheck-pointの間の計算結果は全部プロセッサーの中に一時的に記憶していて
その間の処理結果の照合がＯＫなら外に出すみたいな感じですね

>>515
「あたらしい算数」を読み直してきなよ

NEC なんかは Xeon に外付け LSI でやってるね (Gemini Engine)。

>>508
「科学者としての自分」、「母としての自分」、「女としての自分」
の三者による多数決で決定するわけだな

>>1
安い

以上。

>>1
低品質

以上。

仕様が適当でも許される場合がある

使えればそれで良いというシステムは多いからね

コストの大半は人件費だから
誰でも簡単に作れて直せるほうがいいんだ

レガシー系は人口が少なくクローズドだから初心者が少ないだけだろ。
オープン系は人口が多いから裾野が広い＝初心者が多い。
オープン系は個人を指名するくらいで考えておかないと、失敗する。
しかもムチャ振りするユーザには、技術者側のモチベーションが著しく落ちる。
威張り散すユーザがいるプロジェクトは間違なくない失敗する。

人生で学べる事は限られているから、クローズドな技術にはあまり時間を割きたくないなあ
ロストテクノロジーの最後の伝承者にはなりたくない

オープン系は代えが効くから首を切られやすい罠

逆に言えば入りやすい

俺は人材を調達し易い方が良いな。

つか、オープン系の技術って、
オープン系一本でやってきた人が思っている程、
習得困難な技術じゃないしな。
ネットも書籍も有り余ってる上、
下手すれば個人レベルでほぼ似た環境が持てる。

>>534
そんな前世紀から当たり前の事に今更気づくなんて、ベンダに
囲い込まれて来た技術者にはまだまだリハビリが必要みたいだね。

技術習得が困難wって、他所から見たらそう見えてるんだ?

どっかのコピペじゃないの？

切られやすくてもすぐに再就職先が見つかるならいい

オープン系一本って感覚がわからね

ASはIBMにぼったくられるのを覚悟しないとな。
オープン系ならベンダーに依存しないし、安く済ませられる。

オープン系のハイエンドは、個人じゃ買えないし。
まさかPCを１台買ってくればオープン系のすべてとか思ってたりするのか？
AS一台でコボラーの全てというのとは異なるよ。
オープン系は他のシステムとの連携があるからいくらでも拡張されるし現在も日々進化し続けている。
グーグルとの連携とかASで実現してみろよ(w

ベンダ囲い込みってORACLEのこと？

技術が標準化されて公開されていれば囲い込みとは呼ばんだろ

>グーグルとの連携とかASで実現してみろよ(w
たぶんできるよ。AS上でJava、Tomcat、Axis等々も動くから。
要はHTTPとXML、WEBサービスが動かせるマシンであれば、理屈的には可能
だろう。
＊まぁ、ここらへんのASの情報ってほとんどないから、苦労するかも
だけど。おれ自身はASでの必要性も感じないし、やる気もないが。

>>539

>ASはIBMにぼったくられるのを覚悟しないとな。
>オープン系ならベンダーに依存しないし、安く済ませられる。
確かに初期コストは、Intel系と比較すると割高なイメージ。
（でも商用Unixなら大差ない。）

あと、ベンダーに依存しないというのはよいことばかりじゃない。
たらいまわしにあったりだとか、バージョンアップに一苦労するなんてこと
は珍しくない。

また様々なシステムが乱立していて、ブラックボックス化しているシステム
に苦労している客の姿なんてのは、珍しくない。

本当のところ、囲い込みとオープンとはどっちが客のために良いのか？
なんていう疑問をもったことねぇーか？

商用 UNIX と大差無い?

>>544
>商用 UNIX と大差無い?
価格でおどろいてのか、性能面でおどろいてんのわからんが。
性能面で言えば、筐体はpSeriesと共用してから、大差。
価格面では、３年ぐらい前に、HPとIBMが出した額の比較。
まぁ、IBM結構値引いていたが。やつらも必死なんだろう。

>性能面で言えば、筐体はpSeriesと共用してから、大差。
性能面で言えば、筐体はpSeriesと共用してから、大差ない。

でした。

念のため、HPとASのその当時の見積もり確認してみた。確認したら、
HPのほうが３倍高かった。
これは、IBMの値引き攻勢と、信頼性の対処の違いの差だろう。
HPはクラスタ（DB2台、AP3台）構成だったが、ASは1台ってのが大きい。

ASの場合、確かに落ちないから、こういう見積もりは珍しくはない。

その見積もりの精度ってどんなもんなの。

少なくとも、HPのほうはかなり細かく出してきた。使うパーツをすべて
洗い出して、それそれの金額を積み上げてた。
IBMのほうがざっくり。

ちゃんと眺めたらHPは定価ベース、IBMは値引きありなんで、３倍ってのは
うそだな。
IBMの値引率で概算すると、HPのほうが2.2倍高いね。

パーツの話じゃなくて、要求性能（処理速度だけじゃなくて可用性も）に
どれだけ沿ってるのかなって事。それと DB ならストレージ込みの値段
なんじゃないの?

>>550
ストレージに関しては、ASも見積もりに乗ってるので、同条件だろう。

可用性に関しては、文化の違い（オープンの人間には信じられないかも
しれないが、単体の信頼性が高いので、クラスタとるほうが珍しい。）
もあるが、HPのほうがオーバスペックだろう。
＊クラスタはともかく、サポートでクリティカルサービスなんてのが
のっかてる。

なもんで（HPのほうが信頼性の面でオーバスペックだから。）、大差ない
と記憶していたんだと思う。

オーバースペックなら高くて当たり前なんじゃないの。

>>552
？
>なもんで（HPのほうが信頼性の面でオーバスペックだから。）、大差ない
>と記憶していたんだと思う。
こう書いてるんだがな。金額だせないからあれだが、オーバスペック分を
抜くと大差ないという意味。

良く分からんが、それ以外に相見積もり取った事はないの?

>>554
俺がはっきり覚えているのは、この事例ぐらい。

ところで、あなたの事例を聞きたいね。具体的に。

何だ1案件だけなのか。サンクス。
一般的にはどうなんだろうねえ。

>一般的にはどうなんだろうねえ。
素人だったのか。ばかばかしい、寝る。

それはお互い様。俺は裏方の技術屋だから基本的に算盤は弾かないよ。

>俺は裏方の技術屋だから基本的に算盤は弾かないよ

素人まるだし恥の上塗り

知りもしないのを得意げにベラベラ喋るからそうなる

ただ自尊心を満たしたいだけ。くだらねー

まあ、そんなもんだろう。突つけばボロが出るんだから、黙っておけば良いのにね。

そうやって情報出しにくい雰囲気にするのはイクナイ

自分で1から10まで作れるならオープン系
そうでないならつぶれなさそうなメーカー選んで
汎用機使う方がいい気がす

>>564
> 自分で1から10まで
の定義がない
ハードも自分で作るのか?

>>565
KY

何でも空気嫁が解決してくれるという
幻想を捨てる事が大人への第一歩だよ

銀行で汎用機が使われてるとは逝っても、インターネットに汎用機を直接つなげてるところは皆無。
汎用機は時代の流れに付いていけないのだよ。携帯にも対応してないし。
大企業で、朝から夕方まで窓の外眺めていて、何のためにこの人会社に居るのだろうってよぼよぼのおじいちゃんがコボラーの典型。リストラされたら再就職できずに段ボールハウスまっしぐら。
生保も汎用機使ってるのに、不正給付で信用なし。ハードがいいと自慢しても結局は、古い思考で既得権益を守ろうとしてる老人は社会の癌なんだよ。
戦後の好景気を支えてきたとか自慢してるけど、結局は無理を通したツケがたまって、バブル崩壊で日本を駄目にしたのもこの世代だし、責任とって自決すべき。

> 銀行で汎用機が使われてるとは逝っても、インターネットに汎用機を直接つなげてるところは皆無。

そりゃそうだろｗ
理由は時代の流れとかではなくセキュリティのためな。

>>568
> 携帯にも対応してないし。
携帯に対応したマシンってなによ？？？

全銀手順とか知らないんだろうなぁ…

>>568 はWebブラウザ周辺のことしか物事を考えられないんだよｗ

全銀に請求情報送信してるんだけど
締め切りギリギリまで放っておくと
携帯にメール来るぜｗ

【金融】スルガ銀行：日本IBMを提訴、基幹システム開発中止で・総額111億700万円の損害賠償請求 [08/03/06]
http://news24.2ch.net/test/read.cgi/bizplus/1204812710/

>>1
ロン波−−−！！！

オープン系もう駄目だね。
メインフレームとコボラーの世界へ逆戻り。

インターネット時代から、店舗のATM端末時代へ逆戻り。

ほう

IBMは汎用機の事業継続をアピールしているな。
でも、OSはLinux？それって意味あんの？

上位レイヤにオープン系技術者
基盤は自社のベテラン
で構成できるじゃん

汎用機のベテランがLinuxに長けてる理由はない気がするが

でも(AIXならともかく)Linuxが基幹業務として汎用機OSほど
信頼性/安定性があるとは、とうてい思えないんだが。
よほどLinuxに自信があるのか、あるいは、もう大量の汎用機プログラマなんて
抱えられない(抱えたくない)と判断したのか？

単に今までの汎用機の人材も、即席栽培したリナックスの開発部隊も活用したいってだけだろ。
顧客には両方の開発費を合算して請求してがっぽり儲けたいだけ。

基板とアプリケーションでバグのなすり付け合いでろくに動かない糞システムが出来上がりそう。

> 基板とアプリケーションでバグのなすり付け合いでろくに動かない糞システムが出来上がりそう。
組込み制御の話かと思ったw

ハードが汎用機でもOSがLinuxだったら、汎用機PGの出番なんてあるのかよ。

だから基盤構築をやらせるんじゃねぇの

リナックスのapi叩いてファイル読んだはずだけど読めてないときは、基盤の汎用PGの出番だろ。

言い換えると、業務の汎用PG(要はCOBOLer)はイラネってこと。
基盤を扱えるPGなんて少数だから、大半は配置転換や異動させられるんだろね。
FやHはどうなんだろ？

COBOLはCOBOLで一定の需要がまだあるのよ
もう10年以上も前から
「COBOL終了wwww」
とか言われてるんだけど

日本の通信網はまだCOBOLだったよな確か…
次はさすがに違うと思うけど

> 日本の通信網はまだCOBOLだったよな確か…
何の話をしているんだ？
NTT の DIPS の話だったら全然ちゃうぞ
# 今時 DIPS が動いてるとも思えないが

Nの納品した全国の基地局繋げるシステムがCOBOLだったような気がするけど、
違ったっけ？
DIPSよりもずっと新しいはず

>>591
料金関係のシステムじゃないのか?
COBOLで網の制御ができるわけないじゃん
リアルタイム要求めちゃくちゃ厳しいのに

>>592
いや、料金じゃないはず。
聞いて私も驚いたが、電話通信網の冗長系の制御をCOBOLでやってるらしい

F/H/NのCOBOLerはまだまだ現役なれど、
IのCOBOLerに死亡フラグが立ったってことかな？
あるいはIに限っては、既にCOBOLerは死滅していたとか。

コボルの冗長系って役に立たなさそうだなw
バッチ処理来るまで冗長系使えなさそうw
D70とコボルってどうなのって機が。

Iならまだiシリーズでアフォな中小企業相手にコボルで稼いでいそうだが。

俺の周りでは大半がCOBOLの既存資産を生かして
Java経由でシステムに糊付け
っていう使い方になってるな