【システム障害】 みずほ銀行　高い信頼性を求められる銀行システムに何が起きたのか？　大規模障害を招いた「夜間バッチ処理」★２

★みずほ銀行、大規模障害を招いた「夜間バッチ処理」

　19〜21日の３連休にすべてのＡＴＭが停止する事態に至ったみずほ銀行のシステム障害。
発端は15日未明に起きた「バッチ処理」のトラブルだった。
一瞬も止まることを許されない高い信頼性を求められる銀行システムに何が起きたのか。

　銀行は窓口業務やＡＴＭ、インターネットバンキングなどで発生する金銭取引を
「勘定系システム」と呼ばれる巨大システムで処理している。
みずほ銀行は口座利用客だけで約2500万人を抱え、日々の入出金や送金、振り込み、
記帳といった顧客の依頼のほとんどをオンラインで処理している。

■給与振り込みは夜間処理

　こうした取引は日中のコンピューター処理で完了するが、
それ以外にも給与振り込みや企業間取引といった件数の多い業務が存在する。
これらは日中のシステム運用が終了した夜間にまとめて勘定系システムで処理している。それがバッチ処理だ。

　バッチ処理とは、大量のデータを一定期間ためておき、まとめてコンピューターで処理する操作を意味する。
日本の金融機関は、日中は勘定系システムをオンライン処理に使い、
夜間は給与振り込みや企業間取引などのバッチ処理に振り分けている。
これは限られたシステムを有効活用するために、時間を区切って使い分ける考え方に基づいている。

　夜間のバッチ処理では、その日に扱うべき取引データをチェックし、所定のフォーマットに整えたうえで、
自行や他行の口座宛てに送金処理して取引を完了させる。バッチ処理に使える時間は深夜から翌早朝までに限られる。
日中用のオンラインシステムを立ち上げるには２〜３時間を要し、遅れは許されない。
「給与振り込みなどのデータは一定期間に集中するため、日程に合わせてシステムの処理能力を確保し、
予定時間までにバッチ処理が終了するよう準備する」（システム技術者）という。（続く）

日経新聞　http://www.nikkei.com/tech/business/article/g=96958A88889DE0E7E1E2E1E5E0E2E3EBE2E1E0E2E3E3E2E2E2E2E2E2;dg=1;q=F2F2F2F2F2F2F2F2F2F2F2F2F2F2;p=9694E3EAE3E0E0E2E2EBE0E4E2E2
前スレ　http://ninja.2ch.net/test/read.cgi/newsplus/1300525602/

続きは>>2-4

>>1の続き

■人為ミスの可能性も

　しかし、みずほ銀行は15日未明、バッチ処理が予定時間までに終了しなかった。
原因について同行は「東京都内の特定支店の特定口座への振り込みが想定以上の件数に上った」と説明しており、
その段階でシステムが動かなくなった可能性がある。18日夜の会見で西堀利頭取は
「一部の口座では、データ容量の上限設定が適切な数値になっていなかった」と人為ミスの可能性に言及している。

　いずれにせよ、14日から15日にかけて終了させるべきバッチ処理は朝５時になっても終わらず、
約38万件の処理が翌日に積み残された。バッチ処理が長引いたせいでオンラインシステムの起動が遅れ、
15日と16日にＡＴＭが一部利用できなくなり、さらに両日の夜間バッチ処理も計12万件を積み残すという悪循環に陥った。

　この間、みずほ銀行はシステム上のつじつまを合わせながらオンライン処理を運用したが、
通常にはない処理負荷に加えＡＴＭなどの利用集中もあり、17日にはシステムがダウンした。

　このトラブルを解消するには、15日から積み残されたバッチ処理をいち早く片付け、
一度崩れたバッチ処理とオンライン処理のバランスを取り戻すしかない。
３連休の19〜21日にＡＴＭとインターネットバンキングを休止するのは、
勘定系システムの能力をすべてバッチ処理に振り向けるためだ。
みずほ銀行はシステムのソフト、ハードを増強し、処理能力を高めたとしている。

　ただ、西堀頭取は残るバッチ処理について、
「本来、処理するはずの日付とは違う日にやる分、（システム処理が）煩雑になる」との懸念も明らかにしている。
３日間で予定通りバッチ処理が完了するかは予断を許さない。
みずほ銀行は19日から21日まで毎日経過を説明し、21日夕方には頭取が３連休の進捗を説明する予定としている。

日経新聞　http://www.nikkei.com/tech/business/article/g=96958A88889DE0E7E1E2E1E5E0E2E3EBE2E1E0E2E3E3E2E2E2E2E2E2;dg=1;df=2;p=9694E3EAE3E0E0E2E2EBE0E4E2E2

計画停電も中止したんだからなんとかしてくれ

わざと混乱させているんじゃないかと疑いたくなる。

ミズホ銀行、終わるかもしれないね。口座を移動し始めてる。
この非常時に、こんな大迷惑じゃ、そりゃ相手にしないよ。

システム設計がアホなのか
非常事態で処理が遅れた場合の事を考慮してないとかあり得ない

私のメインバンクである「りそな銀行」には隙は無かったな。

＞「東京都内の特定支店の特定口座への振り込みが想定以上の件数に上った」

これが募金口座？

>>8
CXの募金だろ？
しかし、そんな負荷ごときで落ちるような銀行システムってどんだけー。

外国人派遣銀行員の不正隠しとか、疑っちゃうな

現金を放出したくないんでしょ。

夜間バッチなんぞ前世紀の遺物だろがバカどもめ!

そんなやり方が通用するのはオレの会社みたいなド中小だけだろ！

天罰

いや、一度の大量のバッチ処理が発生すれば処理不能になるのは、理解でき
るよ。そんなごく希な処理のために莫大な処理能力を用意する余裕もないよ。

むしろ、今回の事を機会に、大規模災害時の募金のＴＶ局への振り込み依頼
は控えた方がいい。
ＴＶは、地元の市町村の窓口に募金を持参するようにＰＲすればいい。
市町村なら不正の懸念はないので、有効に使われるだろう。

一番信用あるのは三菱なのかな

今度の金曜日
祭

>>8
日本赤十字の口座振替業務は
第一勧銀ファクター（みずほ系）に委託されている
専用の募金口座があったのかもしれない

義捐金口座＆その他もろもろががみずほ→三井になって、三井も落ちたりしないか？

みずほの利用者はただの情弱だろ。
統合時のごたごた見てたらまず利用しようとは思わん。

ゆうちょ銀行しかないな

こんな銀行に口座作るほうが悪い。

>>12
中小ならバッチどころかオンラインであっという間だろｗ

合併時の綱引きの後遺症が尾を引いているわけだね

これはやはり「フジネットワーク募金」のせいとしか思えない。

>>20
ゆうちょ銀行は堅牢らしいね。

夜間バッチ。懐かしい響きだ。コボルなのか？

むかしなら取り付け騒ぎだな

おわってるーーーーみずほ

簡単に言えば、フジテレビが悪いの？

マイレージ会員なので振込み手数料タダなのに・・・
しかたなくゆうちょ使ったわ。
手数料420円かえせｗｗ

みずほに出入りしてるベンダってI○Mだっけ？

みずほは駄目だな

>>12
大きい会社だからこそ必要

これも今一生懸命作業してるのは中小のデジドカ。
おかしな世の中だよ。

夜間バッチ突き抜けた要因は単に件数じゃないだろｗｗｗｗ

>>8
中国か朝鮮の地下銀行じゃないの？

特定支店の特定口座への振り込み

これって寄付金の口座でなかったとしたら、
外国人の使う地下銀行だよな、明らかに。

ヤカン熱っちっち

>夜間バッチ。懐かしい響きだ。コボルなのか？
PL-1だと思う、富士銀は第３次オンラインをPL-1で開発していた。その前の生き残りだったらCOBOLだが。

CXドメインはもともとクリスマス諸島に割り当てられたものらしいが？
「JOCX-TV/DTV」フジテレビは単なるコールサインのごろ合わせでこれを使ってるのか？
いろんな意味で有害無益な局だな。

>14
あるひ　山のようなアタッシュケースが被災地に・・・

皆さんの税金注入で倒れる事はない。

>>16
給料か＞＜

オンラインゲームの会社がサービス停止が相次いでるのって、
電力と関係無しに、緊急にサーバーをみずほに貸してたりして

うちの会社のシステムも年に1〜2回、夜間バッチトラブルで通常業務の処理が遅れることがある
大手銀行の万全なシステムでも起きることなんだから
うち程度のシステム、年に1〜2回で済んでると思えば納得だｗ

通常の何倍の処理件数が有ったんだろう？２倍や３倍だったら、銀行が糞杉。
（バッチ処理だって、エラーでやり直す事があるはず。だから能力的には可也余裕がなければ変だ）
５倍くらいか？

昔からのシステムを拡張しながら、継ぎ接ぎだらけ
になっているシステムに高い信頼性なんてあるはず
無いじゃない。

UFJ銀行が新規に構築したけど、三菱に吸収される
とき捨てちゃったので、メガバンンクで昔のシステムを
引きづった継ぎ接ぎになっていないシステムは無い。

メガバンクはどこも綱渡りの運用だと思うけどね。

中小しか使ってないけど、日本ユニシスの勘定系が
一番しっかりしたシステムになってるよ。

一時期、携わったオレは断言できる。

メインくら替えしよっと

記帳ありの一般口座で募金受け付けしたのが原因だろ

ほかの募金口座は　記帳無し　だよ

不法入国者の反乱

docomoの義援金が多すぎて、みずほのシステムの限界を超えたのでしょう。

ドコモケータイ送金のフローチャート
ttp://www.mizuhobank.co.jp/useful/keitai_sokin/images/keitai_sokin02.gif
ttp://www.mizuhobank.co.jp/useful/keitai_sokin/index.html

docomoのケータイ送金経由の義援金依頼をフジテレビや日赤程度の件数だと
思い込んで安易に受けたみずほの担当者が悪いのか、それとも
docomoはみずほに通告しなかったのか？

>>14
>市町村なら不正の懸念はないので、有効に使われるだろう。
職員がパチンコ代に有効利用ですね。

>>45
UFJが捨てた新品を拾ったテラバンクゆうちょ銀行が勝ち組。

銀行システムの設計自体に問題がある気がする。

特定支店の特定口座に振り込みが集中しただけで銀行システム全体が
ダウンとか・・・。

負荷が集中した場合は処理を分散させたり最悪でも負荷のかかった
支店だけに被害を留めるシステムを構築するべきだろう。

>>49
フジテレビにdocomoも乗っかっていたのか……。
そりゃパンクの可能性も上がるわけだ。

バッチ処理を営業時間終了後の夜間限定でやろうって考えが間違いだろ

２４時間連続でバッチ処理やるシステムと
日中のATMや窓口処理のシステム、
それの２つを統合して相互連結するシステム

３つが必要じゃね？

バッチこーい

>>27
簡単に言うとみずほが悪い。

システム管理会社のレベルの低鱈苦。

知らないうちに
預金額が増えてたり
しないかぁ…

>統合時のごたごた

今回のミンス東電の失態や
去年のゆうパック大混乱と同じ臭いがするね

地方都市の山奥にデータセンターがあるのよね。

銀行系システム運用ってシステム運用のなかでも特にキツイ部類
だから私は今回のトラブルには同情的ですわ。

運用やってる派遣社員達よ。
過労で死ぬなよ！！

>>14
×　>市町村なら不正の懸念はないので、有効に使われるだろう。
○　 市町村なら不正の懸念は少ないので、有効に使われることも期待できるだろう。

【緊急・拡散】
原発から鉾田市徳宿6時前まで放射性物質の毒雲きた！今、東京へ向かっている。
数字がコワイ。
昨日、100強ぐらいだったのに、2000nGy/h(ナノグレイ/時間)を超えている。
原発で何かあった。関東は午前中、外出しないほうがいい。
翌日に花粉のようなガス状粒子の放射性物質は地面に沈降する。
汚染されたヨウ素、セシウム、ストロンチウムを
呼吸器に吸い込み体内にしみこむと30年以上ガンで苦しむ。
http://ninja.2ch.net/test/read.cgi/newsplus/1300656463/285

排他制御の問題？だとしたら、設計上のチョンボだな。

オンラインを手抜きして作ったぶんの皺寄せがバッチにいったんだな

今回の件で給料日に給料が振込まれない可能性が高いと会社から通達があった。２５日は金曜だから振込まれるのは２８日以降とか…

>>45

あの勘定奉行ってソフト、出来がいいのか・・・。

>バッチ処理とは、大量のデータを一定期間ためておき、
>まとめてコンピューターで処理する操作を意味する。

そこからして間違ってるしなあ

みずほか…
うん…まぁ…何というか言葉に詰まる…

給料振り込まれないとローン返済が即時破綻する奴も居るだろ。
そんな銀行、すぐ切って他の銀行を使えよ。
やばいでそれ。
せめて支店に通帳とハンコ持って行って何とかならんのか。

ロクでもないシステムだな。
おそらく一口座ごとのループ変数の上限を超えたとか、
そんなしょうもない原因だろうな。
銀行なんて半官半民みたいなもんで規制で守られてるから、
ロクなシステムが出来ない。
銀行系のシステム屋はレベルが低い。

銀行が悪いのではなく、システムを構築した富士通が悪い

給料振込がローンの引き落としに間に合わなかったらみずほのせいでプラックリストだな。

もう決めた。
給与振り込みが遅延するとかありえないわ。
家賃とか公共料金引き落としはどうなるんだよ。
システムが復旧次第全額おろして三菱に口座変えるわ。
給与振り込みも変えてもらう。

これひょっとしてオーダーの記録消えたんじゃまいか？
システムだけならこんな時間かかるはずがない。
データ消えたんでその復活に必死こいてる、と。

>>71
発注したのは銀行。
発注元が時間と金をけちったから、このレベルシステムになったのかと。

要求されると予想されるレベルを提示しても、ふっかけられていると思うのか、
大抵は少し劣るシステムで発注するみたいだしな。
沢山の大規模システムの現場を知っているわけじゃないけど、何処も似たようなもんだろ？
導入してみたら性能不足で慌てて追加発注、二度手間っていう。

今頃、協力会社のエンジニアが徹夜で必死に対応してるんだろうな
システム開発費用をケチるからこんなことになるのに、
尻拭いは下請けのエンジニア達か

>>75
発注先のレベルが低いと金と時間をどんだけつぎ込んでも
ｋｓシステムしか組んでくれないんだぜ。

ぽぽぽぽーん

ついでに抜本的な改装をやってるんでしょ。

>>78
じゃあ、レベル高いとこ選べばいいだけかと。

>>80
知っていたけど言えなかったバグをついでに直しちゃうチャンスってことだねｗ

突貫で性能改善とか危険すぎて泣けてくる
死人とかでませんように

これも日本ユニセフ協会のようなエセ募金団体が存在する事にあるだろ。

ほんと有害だわ

原発事故と原因は同じだよ。
想定内のことについては重箱の隅をつついたような仕事をやるが、
想定外のことにはからきし弱い。
型にはまった人材しかとらないから、
自分の守備範囲だけやって終わりという人間が多い。
お決まりのテストパターンしか思いつかないからこういうことになる。

原発だと、津波の最大値は過去のデータだと7mだから、それ以上の値については考えなくてよい、
となる。
もしそれ以上の津波が来てもそれは責任外ということにしてしまう。
無責任の体系だよ。

みずほ銀行も、おそらく一口座あたりの最大取引数を100万程度に見積もって居たんだろう。

>>7
やーいやーい、ださいたま〜

>>82
見る人が見たら、一緒に直したのなんてバレバレだよ。

明日は金おろしにいく。これでトラブったらマジ口座変えるわ。

>>74
データがそんなに簡単に消えてたまるかｗｗｗ
バッチ処理の件数が当初の予定超えただけってことは、みずほが前止まったのとほぼ同じだろ
負荷テストやってないんだろ

明日はもう俺の口座に、無反応だった金、返ってきてる？

今の銀行で動いてるシステムなんて
元は福島原発より古いんじゃないの？

水も食料も電気も暖房もある分、
被災地よりはましか...

過負荷でとまるのはオラクルのせいだろｗ

>>88
当然やってるけど、想定以上だったっていうことだろ。

ベンダーにすれば「システムは御行の仕様通り作っただけだ」という
言いわけが立つでしょ。

ここは統合直後も大トラブル起こしていたけど
３行統合時に仕様の詰めも甘かったし、テストの工数もケチった気がするね。
今回の件も潜在バグだったと思うし。

>>71
何事にも想定外ってのは付き物だしね。
俺も引き継ぎの時によくあるシステムエラー色々と発生させて新人に教えてたら、
システムのエラーログの保存容量を超えて、それが原因で会社の会計システムが
全社ダウンしたことあったなｗ
システム会社の担当者が夜中に呼び出されて原因を見つけて、こんな状況想定
してないですよって泣いてたの思い出したｗ

メインフレームのことはよくわからんのだが、
MSSQLでも任意レコードダイレクトアクセス
できるようになったのは確か2005ぐらいから。
それまでは内部シーケンシャルアクセス。
フィールドでのバイト数制限があったり、おまけにテーブルwww
多対多のリレーションはテーブルこさえて工夫しろと。
容量こそ小さいが、テーブルレスとかこんなん手作りのDBでも80年にやってたのに。
DBって進歩が遅いように感じる・・・

自分のせいじゃないだろうに怒鳴られまくれ、
正確な調査ができないまま捏造報告書作成を求められ、
上司という名の馬鹿に何度も説明を求められ、
連日徹夜で作業させられる。
現場のＳＥかわいそうにｗｗｗ

まあ本当に遅くなってるだけなら、全金融機関で含みおけば済むことやけどな。
もしかしたら取引記録、ことによっちゃ口座残高記録も消えたんちゃうの？
そうでなくとも、オーバーフローして止まったシステム、そのオーバーフローしたデータ生かしたまま復旧できるもんかね。
復旧する際には消えてしまうのでは。

>>93
こういう大規模システムで負荷テストは重要だ
充分な試験をしているはず

予算の範囲内で

>>96
それ、MS製品ですから。
最初にツールやプラットフォーム疑ってかかるなんて、
汎用機やってた頃は、想像したこともなかったし。

>>86
一般人が騒がなければいいんじゃない。
今なら休日出勤もしてくれるし。
本当にそうなら考えた人は頭良いね。

>>49
ドコモがやらかしたってこと？

どうせまた日経コンピュータで｢動かないコンピューター｣
って叩くんだろうなぁ…

間違いなく死者が出るな。

下請けをこき使って成り立っているシステム、ってところでも、
原発と共通するものがあるね。

そしていざトラブルが起こると下請けが駆り出されて不眠不休でリカバリー作業。
下請けが過労死しても知らんぷり。

ベンダーどこ？
ＩＢＭ？

ここにも海水注入

>>102
いやいや、みずほがやらかした。

>>67
あってんじゃん。

こんなダメ銀行べつに消滅しても実は誰も困らない

もう、アウト

>>106
IBMは三菱UFJだよ
みずほは富士通と日立
ちなみに三井住友は日立と日本HP

日本のマスコミは巨大な相手は叩かない

>>82
こういうときに既知のバグを直すのは
基本中の基本ですw
正常に稼働してるときに下手にいじって
ダウンさせちゃうのが怖いから。

うちもみずほユーザなんだけど
ATM使えなくて財布の残金がだいぶ
心細くなってきた。。。
明日にはちゃんと動くかな〜

どうせ多重派遣なんでしょ。
何も変わらないな。担当者、何日寝てないんだ？

>>55はもっと評価されていい。

とりあえず、今回の件で契約者が減れば、
現システムでも問題ない。

ユーザーが元請けを怒鳴りつけて
元請けが下請けを怒鳴りつけて
下請けの役員がSヨを怒鳴りつけて
Sヨが派遣PGを怒鳴りつける

みずほってベンダどこだっけ？
勧銀はIBMだった覚えがあるが

俺のコードも混ざってるんだから動いてるのが不思議なレベルという認識で間違いない

>>80
負荷の高い処理をみつけだしてチューニングしてるんだろうさ。
銀行系じゃないけど俺もよくやらされた。
馬鹿が作ったプログラムの改善だから設計書が残ってなくて苦労したよ。

俺情報系しか知らないんだけど、勘定系もRDBMS使ってるの？

>>119
富士通じゃね
下請けにIBMがいたりするが

今回の件を簡単に説明しよう
　　　 　 　　 ＿＿＿_
　 　　 　　／ _ノ 　ヽ_ ＼　　　　　　あー楽勝、こんなの簡単だおｗ
　　　 　／｡（⌒）　（⌒）o＼　　　　
　 　 ／　:::⌒（__人__） ⌒::: ＼　 ＿＿＿＿＿＿＿＿
　 　 |　　　　 ヽr┬-ﾉ 　 　 　| . | | 　 　 　 　 　 　 　 |　　←　平常時
.　 　 ＼　　　　`ー'′ 　 　／ 　| | 　 100件/日　 　 |
　　　　／　　　　`　　 　 　＼ 　.| | 　 　 　 　 　 　 　 |
　　　　|　　r　　　　　 　　.| 　＼.| | 　 　 　 　 　 　 　 |
　　　　|　 ┴rｪｪｧ_　　　　|＼ 　 |_|＿＿＿＿_＿＿＿|
──‐‐｀ー-ｲ＿＿）ｌ二二ｌ￣￣　 　 　 | |　　|

　　　　　　　　　　　　　　　　　　＿＿＿　
　　　　　　　　　　　　　　　　／　　　　　＼　　な、なんだおコレ！！　　こ、こんなの処理出来るわけないお！！！
　　　　　　　　　　　　　　 ／　　 ＼ ,　, ／＼　　　
　　　　　　　　　　　　　／　 　 （●）　 （●） ＼　 　
　　　　　　　　　　　 　 |　　 u. 　 （__人__）　　　| 　　 　　._＿＿＿＿＿＿＿＿＿_
　　　　　　　　　　 　 　 ＼　 　 　 ` ⌒ ´　　,／ｶﾞﾁｬ　　| |　　　　　　　　　　　　　|
　　　　　　　　　　　　 　 /⌒ヽ　 　ー‐ 　　 ｨヽ　ｶﾞﾁｬ　.| |　　１００００件/日　　|　　←　今回
　　　　　　　　　　　　 　 |　　|　　　　 　 　 　|　＼ ｶﾞﾁｬ.| |　　　　　　　　　　　　　|
　　　　　　　　　　ﾀﾝ.　　|　　|　　 　 　 i i| 　i＼,,c｀ヽ彡.| |　　　　　　　　　　　　　|
　　　　　　　　　.　　ﾀﾝ　|　⌒￣￣r〜ﾉｿｨ" | 　inﾙｿノﾉ|_|_＿＿＿＿_＿＿＿＿_|
　　　　　　　　　　|＼￣￣　ー─‐─ｏｰ"o￣￣~´￣￣　　　　 ＿|_|＿_|＿

　 　 　 　 　 　 ＿＿＿_
　　　 　 ；　 ／　　　ノ（.＼　；
　　　　　 ／∪　_ノ 三ヽ､_＼
　　 　 ／　　　（ ＞）三（　｡）ヽ　；　　←　今
　　　；l　ノ（　 ⌒（__人__）⌒　|
　　 　 ＼⌒ 　u 　l++++l 　ノ~-'､　；

よその話だけど
使ってない変数をコードから削除しただけで
メモリ領域破壊するようになる高度なプログラムとかあるからな

/* この行消さないで */

謎コメントおそろしいｗ

ゆうちょ銀行は堅牢みたいだが、他に優秀なところは無いの？
例えば設備新しそうなネット銀行系とか。
イオン銀行も設立して新しいし。

>>125
高度なんじゃなくて作ったやつがメンテナンス考えてなかっただけだろｗ

http://itpro.nikkeibp.co.jp/article/COLUMN/20080318/296461/

痛すぎる記事

>>9 たかだか2万件/日でこの有様になるわけがない。
でも、本当は別の理由があるはずだが隠してるな。

はっきりいって勘定系みたいな「でかくて」「古い」システムは誰もが改変したいと
思うのだが、稟議が普通なら通らない。
費用対効果が出ないので・・・、社長のトップダウンとかでないと絶対に改善されないシロモノ

というか企業が特定の銀行と取引するのって
やっぱりバックマージンとかそういうのがあるってことなのかな。

>>125
コンパイルオプション等で、下手に削ってはいけないのは良くある話
char unko[12];
char manko[20]; /*why 12??? this is not used and reserved for unko compile option */

みずほのバカ社長はちゃんと謝罪会見したのか？
どうせ下請けに責任丸投げなんだろ

>126

セブン銀行は、日本ユニシスなので堅牢。

ここは銀行本体に開発部隊が無くて、あくまでマネジメントだけの
丸投げ組織だよ。解決能力無い。

預金者引きとめの算段はついたのか

>>112
日立は統合の時にメインの勘定系から弾かれたんじゃ無かったっけ？まだ居たのか（笑）

開発を請け負ってたのはどこだ？
ＮＴＴデータか？

預金がダブついてるから少々預金者が離れても問題ないんじゃないの

わざと混乱させたんだろ。


あるいは、シナ人を全面的に使ってコストダウンしたんだろｗ

昔ATM開発で、NECが中国語の分かるSE募集してたｗ

>>112
IBMは三井住友にも噛んでるはず
たぶん瑞穂にもまぎれこんでるんじゃないかな

OSでもバージョンアップしたんじゃねえの。

>>134
＞日本ユニシスなので堅牢。
ﾜﾛﾀ

初日の遅れは百歩譲ってしょうがないとして、
普通予備のサーバーとかあるはずだからそれを立ち上げて、
「特定の口座」だけデータすっぱ抜いて、予備のサーバーで流すだけじゃねーの？

福島みずぽ銀行

トンキンの買い占めテロ
抑止に貢献ですかw

俺の口座へ3億程誤入金あれば
今回の事を許す準備がある (ｷﾘｯ

>>132
Cとかで、ハード依存のプログラム作ったりする場合は
アライメントの都合やアクセスするハードの仕様にあわせて謎の未使用領域定義して使うのは当たり前だけどｗ

勘定系ならレコードの都合以外は、地雷を仕込んだんじゃないのｗ

バッチで処理ってどういうこと？
誰かエヴァンゲリオンに例えてくれ。

>>148
エヴァンゲリオンってどういう事？
だれかガンダムに例えてくれ。

こんな事で障害起きるような鯖とメンテじゃ
データ丸ごと飛ばして、バックアップもなしとか平気でやりそうだな、ここはｗ

よくわからん。。。
ttp://ja.wikipedia.org/wiki/みずほ銀行#.E3.82.AA.E3.83.B3.E3.83.A9.E3.82.A4.E3.83.B3.E3.82.B7.E3.82.B9.E3.83.86.E3.83.A0
勘定系 脚注 ttp://www.computerworld.jp/topics/osst/110209.html
オンライン系 脚注 ttp://ja.wikipedia.org/wiki/みずほ銀行の合併処理

>>149
まだだ！ たかがメインバンクがやられただけだ！

>>148
目標をセンターに入れてスイッチ
目標をセンターに入れてスイッチ
目標をセンターに入れてスイッチ
　　・
　　・
　　・
以後繰り返し、これはあくまで単純なケースな

なんだB37か

>>150
それでローンの残高も吹っ飛んでくれるといいな〜w

これって地震全然関係ないんだな・・・

今更だが

>>134
ほぉ。
調べてみたらOSはWindows Serverなんだな。
ハードは何使っているのかちょっと調べただけでは分からなかった。
http://www.microsoft.com/japan/showcase/sevenbank.mspx

イオン銀行の方はHPのサーバ使ってるらしい。
http://h50146.www5.hp.com/enterprise/casestudy/aeon/

OSは良く解らんが…

みずほみたいな旧型のシステム使っているとこは、
一回システムを白紙にして
最新のシステムを構築したほうがいいんじゃないの

旧型のものをつぎはぎして運用するから時間がかかっているわけで

急激な円高にパニック。

>>148
アスカは生意気なやつ
アスカとうまくいかない
アスカが全部悪い
アスカにとって僕は
アスカは何故エヴァに乗るの？
アスカに認められたい
アスカとセックスしたい

以上を積み上げ処理（バッチ）
↓
シンジの中二病的自我が暴走
↓
アスカの首を締める

　＿＿＿
/　||￣￣||　∧＿∧
|.....||＿＿|| （ 　　　 ）　　どうしてこうなった・・・
|￣￣＼三⊂/￣￣￣/
|　　　　|　( ./　　　　 /
　＿＿＿
/　||￣￣||　∧＿∧
|.....||＿＿|| （ ＾ω＾ ）　　どうしてこうなった！？
|￣￣＼三⊂/￣￣￣/
|　　　　|　( ./　　　　 /

　＿＿＿ ♪　∧__,∧.∩
/　||￣￣||　ｒ（ ＾ω＾ ）ﾉ　　どうしてこうなった！
|.....||＿＿|| └‐、　　　ﾚ´｀ヽ　　　どうしてこうなった！
|￣￣＼三　 /￣￣￣/ノ´｀　♪
|　　　　|　( ./　　　　 /

　＿＿＿ 　　　　　　　♪　　∩∧__,∧
/　||￣￣||　　　　　　　　　_ ヽ（ ＾ω＾ ）7　　どうしてこうなった！
|.....||＿＿|| 　　　　　　　　/｀ヽJ　　　,‐┘　　　どうしてこうなった！　
|￣￣＼三　 /￣￣￣/ 　´｀ヽ､_　 ノ　　　　
|　　　　|　( ./　　　　 / 　　　　　｀) ）　♪

例えば、ハードはちょい前のHPお買い得サーバを使って、後は数に任せて分散
極論だが、これはこれで別方面で危険だな

実はデータ全て飛んでましたってことないのか

>>28
それでも他行より
お安いですW

大福帳に戻れ

サラッと見る限りこのスレはPC、ワークステーション関連業務の人が多いね。

システム障害の話だからな

SEやってるやつからすれば業務上で問題に思ってることは多いからね

>>166

今時汎用機とか使ってるところあるのかな？　　大手は全部分散鯖つかってると思ってた・・・・・・・・・・

日立、IBM、富士通系？

システム担当者は、どこのシステムもあんまり変わらないんだな
と、思ったに違いない

これも何か隠蔽してるでしょ
バッチの遅延ごときでここまでなるか？
大方新規リリース物件の手順ミスとの合併症とかだろ？
被災地対応で忙しいなか余計な手間増やしやがって
金融庁も財務局もしかっり事案調査して罰則適用してくれ！

>>169
そんな感じで

それ系の仕事の人たちは

書いちゃいけないこと
うっかり漏らさないように気を付けるんだよｗ

大手の勘定系は、ＣＯＢＯＬとＰＬ−１だろ

わけもわからん大金が振り込まれてきて銀行もそれに全く気づかない
状況希望

嘘も困るが本当に特定できないようでは怖くて使えない

終わんなかったんなら、その時点で諦めて停止させときゃよかったものを。
それより、

> 東京都内の特定支店の特定口座への振り込みが想定以上の件数に上った

これの方が気になる。募金かなんか？

みずほの勘定系システムの保守はチャイナクオリティー
取り返しがつかない状態なのか？
http://itpro.nikkeibp.co.jp/article/COLUMN/20080318/296461/

特定の口座って
募金口座かなんかじゃねーの？ｗ

システムがショボいんだ。

>>168
金融系の基幹システムは大手であればある程、今でも汎用機だよ。

>>163
データセンターが爆撃でもされない限りそれはないよ。
データ処理の入口や過程で何重にもバックアップとってある。
全電源が吹っ飛んでサーバーが熱暴走しても2週間ぐらいは耐えるでしょ。

これだけかけても復旧のメドが立たないって
どんだけデータぐちゃぐちゃにしちまったんだよ。

銀行は三菱だけでいいよ

関連ニュース

【システム障害】 みずほ銀行、給与振込を他行に委託へ　預金者の混乱回避
http://ninja.2ch.net/test/read.cgi/newsplus/1300666468/

週明けに向けてて言ってたのに
今日新聞広告で周知
謝罪会見はなるだけしたくないって事だけは分かった

本来なら　TopNewsだろ　よかったﾈ　みずぽん銀行

なんかMMORPGより貧弱そうなシステムだな
兆単位で儲け出てるんだし、さっさと刷新すりゃいいのに

学校ではＣＯＢＯＬ習って実務ではフォートラン使ってたバブル世代の私です

>>173
Cを使ってる部分もあるな。
つか、今後COBOLなんて技術者自体がいねーのにどうする気だろ。

>>189
COBOLのほうが馬鹿には使いやすいんだよ
ホスト使ってる限り永遠になくなんないって

>>188
コボラーは他言語プログラマに馬鹿にされるが、
金融系システムで使われてるから仕事に困らないんだよね。

IDENTIFICATION DIVISION

>>132
どこかのバグでスタック破壊してるだけだろ〜

これで不渡り出したところもあるんだろうな。合掌。

ブラックリスト
多数発生(笑)

給料から住宅ローン15万払い込まないといけないんだが…
連休明けに本当に復旧してくれるのか・・・

>>158
頭の悪そうな奴だな。
そんなこととっくの昔に考えてる。

>>196
引き落としならみずほが引き落とし完了通知を出さなきゃ行けないので
残高さえあれば何の問題もない。振り込みなら遅れるかも知れんが控えで証明できるだろ。

>>196

延期ってニュースみなかったのか？28日だって

だから勘定奉行にまかせとけって言ったんだ

>>196
明日朝一で電話してみずほのせいにしときゃどうにかなんじゃねーの？

勘定系オフラインいじったら不適切なセンター記帳データができて、それでセンター記帳したら最後のトータルチェクでABEND したんですね。

みずほの顧客が移動するのは確実だが
移動先の銀行がパンクするなんて事態にならないだろうか？

サラ金のデータベースも消してください！

>>204
ローンの一本化はなんたら法律におまかせ！
手数料は分割払いもできます！

普通のカードくらいならいいが、不渡りとかどうなるの？

移るとしたら三井住友？三菱東京ＵＦＪ？それともりそな？

みずほ・・・・名前が悪すぎる。

>>206
振り込み遅延
保証しませんって書いてあるけど…
裁判になるだろうなW

ゆうちょ銀行
預金枠増額が
すんなり通りそうだなW

みずほは全都道府県にあるけど
三井住友や三菱UFJは県によってないところがあるから
自分の住んでいる県や関わりのある県に支店があるかどうかということではないかと思う
都市圏ならどっちでもいい
りそなは埼玉人以外は不便だろ

>>207
ぶっちゃけ財閥系だから良い意味でどちらも変わらないとおもふ。
近所や会社近辺にATMがあるかなど利便性で選ぶべし。

富士銀行復活を！

北海道拓殖銀行の祟りじゃー！

プログラム組んだこと無い奴が上流行程やると酷いよな。
工数とかは会社で難易度でランク付けされた必要工数の一覧があるけど
PG経験無い奴はランク付けすら見謝るからな。。。

>>214
程度問題だけど、中途半端な奴が出しゃばると、部類の○○好きみたいなのが出て初期処理アウト
現場レベルなら、百人力なマッチョ将軍が奮戦するも討死連続
白兵戦もやべえ

んなとこだろね

バッチ処理する前にその日に受け取ったデータ件数をあらかじめしらべて
作業用ファイルを確保するサイズを若干大きめにしとかないと
翌日出勤したとき「ファイルサイズが足りなかったのでアボーンしました」
と夜間オペレータからメモを渡される。

でその後作業用ファイルを確保しなおして再処理するのが普通で、
コンピュータの処理能力やデータ件数にもよるけど
昼頃から日の入り前には終わるはずだ。

あ、今回マッチョ将軍を向けられたかは知らない
将軍赴くに及ばず、が妥当な判断かな

>>188
大まかな計算でいいなら有効数字８桁、１６桁なんていう不動小数点のＦＯＲＴＲＡＮでいいけど
１円からン兆円まで四捨五入しないで正確に計算しないと許されない金額計算はＣＯＢＯＬの独擅場だな。

違法なノミ屋と同じだよ
人から預かった金で投機
元手をすって返せないので
当座の金ができるまでシステムトラブルのふりｗ

>>219
マジだとしたらすごいな
ソース的なものはあるかい？

>１円からン兆円まで四捨五入しないで正確に計算しないと許されない金額計算はＣＯＢＯＬの独擅場だな。
其れ＋汎用機の強力な１０進演算回路ね

百万歩譲って、ディレイ処理できているのかな？
負荷結構だよ♪

ENVIRONMENT DIVISION

今回のシステムトラブルって、これも何か関係してる？

みずほグループ：勘定系システムの保守を大連で
http://itpro.nikkeibp.co.jp/article/COLUMN/20080318/296461/

DATA DIVISION
01 COBOLER GANGALE

>>214
しかし元請けのSEはプログラムできないどころか、文系の奴だらけという現実。
文章が書けて工数管理ができりゃ良いらしい。現場をかき回すSE(笑)はいらん。

追証があああああああああああああああああああああ

>>97

で、三連休内に復旧させても、さも当たり前のように感謝もされず、
火曜日以降の業務に支障をだしたら、査定ダウンですね。

給与振込がみずほでオワタ・・・
貯蓄・財布系は別個に設けてたんで二月くらいは生活平気だけど・・・

どうでもいいけど福島みずほって最悪な名前だな

これは、預金封鎖演習である
本番は近いぞ

東電と一緒だよ。
丸投げの丸投げでいまみずほの正社員がみてるんだろうｗ

氷河期世代の派遣ＰＧとかかかわってるから、だれかうらみで
爆弾でもおきるようにしたんだろうｗｗｗ
おれも、たまにそんな風にするしな。
ざまあｗ勝ち組ってところだな。

>>103
ウチの会社も出たwww

>>131
> というか企業が特定の銀行と取引するのって
> やっぱりバックマージンとかそういうのがあるってことなのかな。

中坊？

>>230
それ俺も思った。

>>227
悲痛な叫びだな

昔　バッチ処理が終わらなくて、翌朝　オンラインが開放ができなくて、各利用部署へ
電話しまくってたのを思い出す

あの頃は、ホストの上位機種へのリプレースやＯＳバージョンアップで解決していったが・・・・・

プログラム自体は、数十年前に素人が作ったＣＯＢＯＬを継ぎはぎされたもので
仕様書も青焼きをセロテープで補修　とても　簡単に修正できるものではなかった

業種が違うんで、そんなに問題にはならなかったが

最寄りの支店までだったら往復の電車賃 を後日振り込むと言われた

電車賃とバス代を堂々と請求した方がいいぞ

>>158
　みずほが金ないとシステム統合見送った。
今年は６Ｚもあるしな…

東電と同じ


考え方が甘い

■みずほ銀行システム障害の分かりやすい原因解説の説明と画像
http://ebrain-news.com/news.php?bc=0&c_number=1300405111

不渡り 続出

もし、コーポレート銀行が みずほのサーバー使ってる処理があったら
影響あるのかな？

こりゃ不渡りでアボする零細が沢山出るな。

原発にしろ、大手金融にしろ
中枢にはレガシーシステムが現役稼動

それが、次々と破綻か！？

>>45
１バイトが９ビットのマシン？

>>221
そいや、どうして他の言語は精度をＣＯＢＯＬ並にしなかったんだろう。
用途が違うし、そこまですると処理が遅くなるからやめたのかな。

>>247
金計算と科学技術計算との精度の捉え方の違い
金計算は一円単位まで厳密、小数点以下切捨て
科学技術計算は桁数3桁までとか5桁までとか7桁までとか
有効桁数で考える

>>247
１０進演算回路が無いコンピュータで、１０進演算をさせるのが大変なのよ。
２進で演算させて１０進に戻すと丸めが生じて計算が狂う。だから、丸めの補正が必要になる。

233 名前:名無しさん＠十一周年 投稿日:2011/03/20(日) 12:04:33.77 ID:g/4ylUdr0
>http://itpro.nikkeibp.co.jp/article/COLUMN/20080318/296461/
>
>この記事、・・・

これどさくさ紛れに情報抽出されてんじゃね？
チャイナに

愚か・・おろかナリ。


【山形】ガソリン気化か？パチンコ店駐車場で3台の車が全半焼　携行缶、注意を喚起　新庄市
http://ninja.2ch.net/test/read.cgi/newsplus/1300685706/l50

車内に置いていた携行缶のガソリンが気化したのが原因とみられる。

新庄署などによると、土田さんは車両後部にガソリンが少量入った
携行缶を載せたまま　約　4　時　間　、車を離れた。

車に戻り、エンジンをかけたところ燃え上がったという。
天童市のケースは、給油待ちの軽乗用車から出火。バイクから取り外したタンクを車内に置き、
たばこを吸おうとライターに火を付けたところ炎上した。
タンクに残っていたガソリンが気化していたとみられる。

揮発性が高いガソリンは、車内温度が上昇すると引火の危険性が増し、静電気でも引火することがあるという。
消防法は専用の金属製携行缶に保管することを定めており、消防関係者は「換気が重要。火気はもちろん、
長時間の放置も厳禁」としている。

ID:ChBITceD0
コピペ野郎うざい

>>247
javaはそれ用の演算クラスがあったような…。
それ使わなかったから怒られた若かりし日の苦い記憶が。
あってもホスト環境下じゃ使わないだろうけど。

プログラマ軽視のつけだ
しかしどうすんだよこれ？

>>254
ｊａｖａ動くホスト（ＯＳ）あったと思う。ＩＢＭに。

上流工程の専業なら専業で、
変更や、見積もりに誤りがあれば
即時に納期延ばしたりするのが本当の所なんだけど、
結局無理させる方に行っちゃうし、

そもそも、建築みたいにウォーターフォールで物事進まないのに、
納期だけはキッチリしてるとか

根本がおかしいんだよ。

手抜き建築で良いのか、時間かけても耐久性の高い物を作って欲しいのか。

何時までこんなバカな方式で仕事したら気が済むんだ？
短期間で良い物作る、無理じゃないけど優秀なメンバーに高給与えてからの話だろ。

民主党の詐欺師みたいな、口だけ上手な奴が優秀だと思い込んでる営業上がりの屑に
システム触らせるんじゃねーよバカｗ

こんな銀行潰れてしまえ、関東と一緒に滅べ。

なんだ、未だに９４５０Σでリカバリしてるのか？

時間がなくて間に合いません><→間に合わない理由を納得のできる様に報告して、回復策を明確にせよ→資料作成→報告→ますます遅れる→最初に戻る

こんなことをやっていたら品質も落ちるわw

みずほ情報総研　マンセー！　

>>259
＞間に合わない理由を納得のできる様に報告して、回復策を明確にせよ

これを専業でやる人間がバブルの昔は居たｗ今は多分居ないｗ

現場で働く人間が派遣等の、自給換算で考える人間ならば
ばっくれた方が楽だし、給料上がるワケでも無いしで
真面目に物を作っても作らなくても評価変わらんのなら、
体壊さないように、適当にやるのがビジネスってモンだろう。

銀行の重役が頭下げれば何でも許されるんだからさｗｗｗ

>>96
とりあえず階層型DBのさわりくらいは理解してから出直して来いｗ

>>45
孫請けを一回しただけで、
「一時期関わった俺は断言できる！(ｷﾘｯ)」
とか言うアホも多いからなあ。

>東京都内の特定支店の特定口座への振り込みが
>想定以上の件数に上った」と説明しており、
>その段階でシステムが動かなくなった可能性がある

ロックの粒度が表か表領域とかのクソ仕様ってことなのかと
通信機器へっぽこソフト屋が言ってみる

>246
9ビット？8ビットじゃなくて？
どういうこと？

そんな汎用機があるの？

現在の二大ニュース
『福島、みずほ』

悪いのは社民党だな

>>264
フジTVの義捐金口座の開設を窓口でミスったため
数万件単位の記帳処理をするCPUバカ食い、メモリ領域バカ食いの超高負荷ジョブ誕生

気づかずそのまま投入して、当然ながらシステムが超負荷状態になってトランザクションログの退避ジョブが起動不能
んでトランザクションログがパンクしてオンラインがダウン
大規模ユーザはオンラインが死ぬとシステムも巻き込んで殺す設定が一般的なので
そのままシステムあぼん

事の発端はこうらしい
その後のｇｄｇｄまでは知らん

Ｃのポインタで挫折した俺には、何言ってるのかさっぱりわからんｗ

IFRSなんてとても無理だな。

地震でハードが壊れたならともかく、ソフト的な問題なら全部人災だろ。バグだったとしても

ITのシステムなんてプログラマからみりゃほんとにこんなの本番運用して
いいのかってのばっか。原発の現場でも同じことやってたんだろな。

まだ夜中にフロッピー使ってデータ書き換えてるの？

>>264
解説ありがと
フジTVの義捐金口座の開設を窓口でミスからなのか
大規模障害の起因はいつも人為エラーだな。。。

やっぱこれからは安心の地方銀行だな

もう一つ解せない点として、>>2にある
>バッチ処理は朝５時になっても終わらず約38万件の処理が翌日に積み残された

これって朝３−４時には警告もなしで、または警告上がっていても対処してない・できなかった
ということだろう？勘定系夜間処理では普通なのか

さっき近所のみずほ行ってきた。けっこう偉いと思われる人が
土下座せんばかりの態度で対応してた（こっちは文句言ったり
してないのに）。サービスのつもりなのか、窓口で対応してた人が
普段みたこともないとびきりの美人だった。

処理件数だけの問題ならこの三連休にマシンパワーを全部溜まった処理に
振り向ければ終わるだろ。それができないって事は何か他にやらかしてるんだろ。

富士通のSEが何人か廃人になっているんじゃないか。

>>278
もとから壊れているようなもんだけどね。

特定口座に大量の預金データが来たためと言っているから人災になる。

>>259
仕事オナニーだよなこれ

ABENDED

みずほ銀行、22日(火)午前もATM停止・・・
コイツら何か隠してるな・・・
3連休に全停止してこれだと、マジでとんでもない事やったな・・・
何か少しでも知ってる人は金融庁へTEL
匿名で話聞いてくれるよ

>>282
やめてアベンドやめて！

元請けはHだろ
つか孫請けひ孫請けくらいの偽装請負で入ったことあるけど
コーディングやテストをするのは俺みたいな
どっからきたかわからないような奴だからなｗ

銀行のシステムは軽く十年前の物を使っているからなあ。

募金口座に100円、200円といった小口の振込みが殺到したんちゃうの

まさか・・・
排他処理のタイミング障害に起因したデッドロック？
まぁ、ありがちっちゃーありがちだが、金融のしかも本番稼動中にやるのはマズイ

夢の中の話です。
資金がショート、資金調達ができなくなった事態に陥ったとき、
銀行側はすぐに公表することは、ありません。
通常は「コンピューターが故障しました」等のような言い訳をするはずです。
デリバティブが決算操作に利用されていたツケか？
株価暴落でノックイン条項。Ｇ７も大慌て。

こういうのって、人手が増えれば何とかなるの？
元システムに不具合が有ったら、全取替えとかできるんだろうか？

メインがみずほだったらきっついな

既存顧客を全部解約できるなら新システムへの切り替えもできるんだろうけど。
移行って面倒なんだよね。

給与計算のシステム作ってるヤシだけど、振込データ伝送したら、後は俺シーラネ！！

こちとら締め日と振込み日までに死に物狂いでやっているのに、何をやってんだ。
まぁ、今更COBOLって時点でありえんだろ。ＪＫ。

金融系はいまだCOBOLで汎用機ばっかなのかね
銀行、カード････
カードももうすぐ破綻するよ

あしたもATM使えないみたいだが直るのかこれ

0C7

ナンバーズがあたらないからだよ

　やはり、だめほ銀行。

データ例外かｗ

キーワード：みずほ　福島

ん？

システムのことを真面目に研究してこなかった付けだな。
トラブルが起きたっていきなりコボラーをかき集めるなんて出来ないぞ。
人員に限りがあるんだ。

>>301
今時、コボラーなんて稀少人種だからな。

俺もＳＥだけど、出来ない仕事は出来ないって現場の人はちゃんと言った方が良い。
後は責任のなすりつけ合いだ。

勘定系の基幹はまだCOBOL多いの？
農林中央金庫で勘定系やってた時、一時期Cとかに移行していこうって話があったが
結局COBOLが再評価されて元に戻ったっけな

これを気に、メインフレームなんてやめて、全部オープン系にしろよ
何がCOBOLだよ
こういう所に金けちってるから、こういうことになる
多分、みずほ銀行解約するやつ続出だろこりゃ
目先の金ケチったせいでトータルでは圧倒的に損害になったな

COBOL馬鹿にしちゃいかんぞ
馬鹿にでも使えるCOBOLなんだから
だから無くせないんだから

>>210
都銀がほとんどない茨城最強
いろいろ見放されるんだよねぇ

>>302
どっかの銀行が合併した時にPGと銀行がマジでつかみ合い寸前になったとは聞いた。
銀行はシステム統合のスケジュールなんて頭に無くて決済期だけでスケジュール決めるらしい。

昔のように通帳に直接手書きで数字書きこんでやれや

>>276
普段は大口のお得意様にサービスしてるんだな

ひょっとして、オリジナルデーターを消滅したのか？

>>305
お前はCOBOL以外のプログラム言語を利用してそうだが、
なぜCOBOL以外のプログラム言語で作成したシステム構築提案が出来ないんだ？
答えてみな。

全システムを把握している人間は一人もいないんだろうなあｗ

元帳が心配ｗｗ

こぼるちゃんいやなんでもない

>>308
通帳はどうでもいいけど、元帳手書きは無理だわｗｗｗ
ATMとか使えないよ

みずほ銀、店舗外のＡＴＭは２２日も終日休止

http://headlines.yahoo.co.jp/hl?a=20110321-00000476-yom-bus_all

もうソースオープンして、
『誰か教えてちょ☆』
ぐらい言ってもいいと思ふ。

みずほ明日ストップ安かな

COBOLなんてまだマシ、PL/1が現役なとこもあるぜ。

混乱に乗じて海外ハッカーにやられたとか？


もうごっそり資金取られたとかだったりして…

欧米列強の金融システムは何で組んでるのかな？やはりＣＯＢＯＬ/ＰＬ−１か、
それともＣ＋＋かな。。
そもそも汎用機使ってるのかな？？

>>316
うわっ。　本当にやりやがった。　これって現実？


233 名前:名無しさん＠十一周年 投稿日:2011/03/20(日) 12:04:33.77 ID:g/4ylUdr0
>http://itpro.nikkeibp.co.jp/article/COLUMN/20080318/296461/
>
>この記事、・・・

964 名前:名無しさん＠十一周年 投稿日:2011/03/21(月) 15:47:06.16 ID:xR/2pk5I0
>http://www.atmarkit.co.jp/fbiz/cstaff/serial/offshore/02/03.html
>中国オフショア開発の成功と失敗の実態


責任感もなく、ヤバい時にすぐ逃げる連中と関わりあうと、こうなる。

>>318
織り込み済みでしょ
権利落ちまでは下がることはないかと

たしか、いぜんもミズホはおなじようなシステム障害を起こして
その時は復旧までに１ヶ月必要だっただろ

年度末に決済振込みができなければ、倒産する企業もあるだろな

実際すでにFX主婦が入金できなくて自動ロスカットされて
数百万溶かしたとかいうどうでもいい話もあるけどｗ

株の暴落で追証が発生しているんじゃないのか

念のため明日全額下ろすかな

銀行間のコール市場で相手にされなくなったので拓銀は破たんを決めた。

結局、みずほのシステムは富士通ということでFA？

>>311
おれが過去にCOBOLで作られたシステムをJavaに置き換えようと思って、断念したケースと言わせてもらうと、
（多分ダメこぼらーが作ったんだとおもうが、）グローバル変数の使い方が酷くて
どこでどのフラグが立っているのかサッパリわからない。そして当然設計書も間違っている。
こりゃだめだと思ったよ。

ちなみにそれ以前までにCOBOLはトータル1年くらいやっていたから、「まぁ読めるよ。」程度のスキルだった。

>>322
思わず納得。

バッチの積み残しなんて
なんで21世紀の銀行システムで…

>>316
まじか……。

原発といいみずほといい、少し前まで起るとは思えなかったことが次々に起るなぁ。

>>322
あちゃー

給料が振り込まれなかったらどうするの？みずほから手渡しで貰えるのかな〜!?

みすほはF社で汎用機でPL/Iだと思ふ。
（だからabendでなくabortだったよな？）
おまいら汎用機ばかにするけど、汎用機はやっぱり強力で、
世界中の金融機関はまだまだ汎用機使ってるよ。
クラサバで勘定系作るとまだまだニュースになる世界。

東電とみずほが隣同士だなんて・・・

http://p.tl/Ymtn

統合の時もそうだったけど、結局システムの1本化もできてないんじゃないの？

二重振込みとかありそうだなｗｗ

口座作ってから2年間、記帳してない。
残高証明するもの持ってないよ・・・

ネット振込できんと困る

PL/IはABEND。

給料振り込まれないんだからもらえるわけない
２５日パニック

>>339
そんなもん(ﾟ�听)ｲﾗﾈ

Ｆ社ならCOBOL
PL/IはＩＢＭ

>>60
>地方都市の山奥にデータセンターがあるのよね。
足柄か。
今は渋谷に移ったはずだけど…？

単に、桁溢れじゃねーの
重要部分が止まれば全体にも影響出るよ

金融系だとシステム切り替え後の溢れとかはたまにあるよな

しかしどう見ても、ﾁｮﾝかｼﾅの地下銀行系が原因だろ

http://itpro.nikkeibp.co.jp/article/COLUMN/20080318/296461/

これって今分割で買ったもの毎月引き落とされてるんだけど２０日支払い分って
ちゃんと支払われてるんだろうか？
ちょっと心配だよ。

この事故のせいで引き落とされなかった場合、残高が足りないとか誤解されないんだろうか？

A PIC 9(10)

MOVE 10000000000 TO A

COMPUTE ANS = A / 365 * X

0C7

>>303
保険や金融系ではまだまだCOBOL中心だろ
うちでもサーバー系の一部や一部の入り口処理をjavaとかに切り替えてるが、
中身は普通にCOBOLだな

次期システムでどうなるかは知らんが、相当金かかるから簡単には切り替えられないんだよな

みずほのせいで不安視されるCOBOLが可哀想

でも呆れるぐらいやらかすねえ

>>319
みずほってPLじゃなかったっけ

５年ぐらい前にみずほ関連やってた奴がPLって言ってたような気がする　

今週末、給料が振り込まれなかったら。カード会社の引き落としが
できなくなる。カード会社はこっちの事情なんて斟酌してくれんからなあ。
ふざけんなよ、糞みずほ。

>>323
まったく織り込んで無いよ
皆、ATMとかの軽い障害だと甘く見てたから。
最初から、ここまで酷い障害だと気がついてた人は少ないよ

>>348
支払われてるんだろうか？

引き落としが無い場合、信用保証協会のＤＢにフラグが立つｗｗ

結局地震以来ずーっとダメだな

>>308
そういやそれもそんな昔の話じゃないんだよな…
今じゃ信じられんが

カードの支払どうしてくれんだよ？責任とれよ

>>357
通帳手書記帳はそんな昔の話じゃないよ。今は不正防止の為に禁止が大半じゃね？
預金元帳のオンライン化はかなり前だろうよ

先週も毎日、昼に復旧させて失敗してたよな
今週も同じ事を毎日繰り返すのかね？

>>338
既に報道されてたな
たまには俺の給料も二重振込なりして欲しいもんだが

>>210
みずほしか都銀がないような県の場合
役所や地場企業は地銀を使っていると思われ

請求を本社に一旦持って行って集中処理するぐらいのレベルだと
口座はみずほじゃなくてみずほコーポレートだろうし

>>353
カード会社（のシステム担当）とはさすがに連携とるんじゃねーの
カード会社のシステム処理対象顧客から、みずほ分の客を抜いた状態で処理してもらうんだと思うが…
このトラブルのせいで、顧客の信用情報に瑕をつけたら、みずほオワタ状態になるだろ

>>75
システム屋はそれを理由にしてはいけない

料理人が客に塩加減を聞いて、お客さまのご要望通りの調味料で作りましたって
まずい料理出しちゃダメだろ

>>362
そういう田舎の地場企業や役所は地銀だろうよ

>>337
システムは旧式のゴミシステムに統合した
ただし銀行自体が、みずほとみずほコーポレートに別れて同じシステムを二重用意するとかバカな事してる

そういえば謎の大金が送金されたからシステム障害って言ってたよな。
何で騒がれてないの？

今回に限ってはみずほコーポレート銀行が分離してて良かったんじゃないのか？

その考え方がクオリティの低下と品質の低下に繋がった
膨大なサービス残業を強要することになり
技術力のあるプログラマから順に退場して
カスしか残らなくなった

ただでさえ　今回の震災で会社が軽いパニック状態なのに
メインバンクがみずほ・・・

>>364
そういえばお客様がすごく辛いカレーをご所望で
出てきたカレーを食えなかったからクレームって事件なかったっけ？

どーーーうせ、大連の中国企業に保守を任せてたんだろ

そりゃあ、こういうことは当然おきるわな

これからも起きるだろうぜ
何百万ある口座から毎月１円ずつ抜かれてなければ幸いなレベルじゃね？

>>368
だね
おかげで大企業はほぼ無傷のはず

ん？　FホストでもPL/I動きますよ？
abendは、言語環境から直で出るものではないよ・・。
ま、いいけどね。

公明党
草加学会
個人情報保護法

ああっ、俺の口座に１０兆円ほど入金処理してくれないかなあ。

>>81
単純にそうは言えない
もっと低い水準のところに発注してもうまくいってるシステムはあるんだから

>>49
どう見てもdocomo関係なさげｗ

まさかdocomoが逐一送金してるとか？
携帯会社なんて一括だからまずそんなことは有り得ん

みずほ一行では危険だな
もうひとつ口座を持とう

このトラブルでオレの預金が増えているばいいのに・・・

オザーさんが慌ててなんかし・・・ん？こんな時間にチャイム鳴らすとは非常識な。ちょっと怒鳴ってくるか。

>>329
COBOLからJAVAへ移行って何のシステム？
JAVAはDB処理には向かないと思うが。

何だか嫌な予感がしたから、14日にみずほから全額下ろして関西に逃げた俺は勝ち組。

>>190
馬鹿っていうな
自然言語に近いということは業務系の人間にも理解できるということだ

一般人に理解しづらいプログラミング言語のほうが高等だと思っているほうが馬鹿

「課長っ、もの凄い勢いで預金の払い戻しが増えてますッ」
「ナニっ！？このままじゃ資金が底を着くぞっ」
・・・

メガ地銀哀れ〜♪

>>385
つ日銀特融

処理件数が多い分、
CASE文の聞く順序ひとつでけっこう処理時間かわるからな……。
意外とそういうとこだったりして……。

COBOLやPLIがフルパワーで処理してるもんが
分散＋Javaでこなせるとは思わんが・・・。

>>84
>原発事故と原因は同じだよ。
>想定内のことについては重箱の隅をつついたような仕事をやるが、
>想定外のことにはからきし弱い。

まさにこれだと思う。
日本人は想定内のテストはアホみたいにしつこいくらいするけど、
想定外の事象を発想出来る奴はホントに少ない。

>>323
だめぽは、また120切ると思う。

>>243
みずほって社名についてるけど、コーポレート銀行は全く別のシステムです

　　　　　　　 ＿＿＿_
　 　 　 　 ／ _ノ 　ヽ_ ＼
　　　　 ／｡（⌒）　（⌒）o＼　　　
　　　／　:::⌒（__人__） ⌒::: ＼　　
　 　 |　　　　 ヽr┬-ﾉ 　 　 　|　　　 __＿＿＿＿＿＿＿＿＿_　　　　　
　　　＼　　　　`ー'′ 　 　,／ ._i~~| | |　　　　　　　　　　　　　| またプログラムエラーだぉ
＿＿／　　　　　　　　　　＼　 |_＿| | |　　　　　　　　　　　　　|　　　
| |　/　　 ,　 　 　 　 　 　 　 ＼ｎ||　 | |　　　　　　　　　　　　　|
| | /　　 /　　　　　　　　　r.　 （ こ） | |　　　　　　　　　　　　　|　
| | |　⌒ ーnｎｎ 　 　 　 　|＼ (⊆ｿ .|_|_＿＿＿＿_＿＿＿＿_|
￣ ＼＿_､("二）￣￣￣￣￣ｌ二二ｌ二二　 ＿|_|＿_|＿


まぁ実際現場のプログラマーなんてこんな感じでヘラヘラしてます

>>378
振込処理の反映が遅れるとまずいからまとめてドコモが振込データをまとめて送信なんて考えるづらい。

>>190
極端にいえば高級言語はマシン語に変わればどの言語も同じ。
覚えるのが難しいから高速で多彩な処理が出来るなんて幻想に過ぎないし、
馬鹿にしてる奴ほど生産性お応用力が無い。

【呪い】　東電とみずほ本店 隣り同士
http://hatsukari.2ch.net/test/read.cgi/news/1300705661/

1 名前：名無しさん＠涙目です。(東京都)[] 投稿日：2011/03/21(月) 20:07:41.93 ID:3Sq8U40q0 ?PLT(12666) ポイント特典
http://img.2ch.net/ico/anime_iyou01.gif
東京電力株式会社
本店所在地
東京都千代田区内幸町1丁目1番3号
http://www.tepco.co.jp/corporateinfo/company/annai/gaiyou/index-j.html

株式会社みずほ銀行
本店所在地
東京都千代田区内幸町一丁目1番5号
http://www.mizuhobank.co.jp/company/info/profile/index.html

google
http://maps.google.co.jp/maps?f=q&source=s_q&hl=ja&geocode=&q=%E6%9D%B1%E4%BA%AC%E9%83%BD%E5%8D%83%E4%BB%A3%E7%94%B0%E5%8C%BA%E5%86%85%E5%B9%B8%E7%94%BA%E4%B8%80%E4%B8%81%E7%9B%AE1%E7%95%AA5%E5%8F%B7

6 名前：名無しさん＠涙目です。(東京都)[] 投稿日：2011/03/21(月) 20:10:31.14 ID:giV0eEE00
福島の事故、
みずほの事故、

この符号が意味するものはひとつ・・・・！

>>393
まあコンパイル段階じゃ間違ってねーがw

でも今って単体以降の試験段階であんまり故障出すと、
リリース時の品質評価でやり玉にあげられるぞw

みずほ銀行がほとんど情報を流さないから預金者はパニックで
明日は震災後のガソリンスタンドよろしくで長蛇の列が出来るぞ。

>>248
年金のシステム一から構築した時、泣いたよ
年金数理ってもう微分積分の世界なのな

月割りにした小数点以下１０桁の料率を何十年分もべき乗計算する部分があって
当時、事務系のコンピュータではどうやっても検証できなかった

端数をどう扱うかは案外重要だからね。

これ、基本のしシステムがもう駄目ダメじゃん…

>>399
あー有効桁数の問題が出てくるのか、なるほど

>>384
>>395

別に言語のことを馬鹿と言ってるわけではない
馬鹿でも理解しやすいと言ってるだけだ

1990年代中盤からSUNを筆頭にダウンサイジング（笑）分散化（笑）なんて煽るから
大規模の基幹システム技術者が減ってしまった。

>>268
これが全部終わって原因が整理されたら、簡単に理解できる内容になってるよ
ポインタなんて難しいｗ単語もいらない

夜間バッチを流す、見守るのはシフト勤務の運用担当。
バッチ処理プログラムを組んだPG、SEは家で安眠中。
バッチがコケると運用担当がSEに電話して叩き起こす。
中には起きない奴もいるし寝ぼけててまともに返答出来ない奴もいる。
「マニュアルに書いていない作業以外はやるな」と厳命されている運用担当は
ひたすらエラー画面が表示されてパトライトが鳴り響くオペレーションルームで
夜が明けるのを待つのみ。


どうせみずほもこんな感じなんだろ。

>>398
スーパーとかで買い溜めしてた主婦達が長蛇の列作るかもね
食品
トイレットペーパー＆ティッシュ
ガソリン
そして次はみずほからの預金引き出し
25日の給料日には入金もされず、更に引き出せないかもとか報道されたら凄い事になるだろうね

製造した下請けの会社は、いまごろ大慌てだろうな。
ここまで損害出したら、さすがに取引停止だろうなぁ・・。

>>403
それって技術者の裾野が広がるから良い事なんだが。
一つの言語を覚えてアルゴリズムさえしっかり自分で考えられれば、
他言語を覚えるのも比較的容易だし。
貴方は変にエリート意識持ってるようだけどなんか使えなさそう。

>>20
ゆうちょの、あの独特なインターフェースも
気味が悪い。

原発問題はハイパーレスキューがヒーローになったが
みずほの障害は誰がヒーローになるの？

>>406
金融系のメインフレームで構築してるところは
ベンダーやシステムを作っている所は違っても
営業時間中のオンライン処理と業務処理後のバッチ処理の流れは殆ど同じだね。

>>278
実際には富士通なんとかサービスとか富士通なんとかシステムとかいう
名称の会社の社員（もしくはそこの協力会社）だろうけどね

特定口座の振込は同じキーでのインサートが連続で発生するから並列処理がやりにくいんだろう
直列で番号フって挿入だと、一件辺りの時間がわずかでも数か多いと莫大な時間になりがち
最初に夜間バッチが遅れたのはそのせいじゃないかな
まあ設計ミスではあるけどテスト段階で気付きにくい事象かも

たまった処理のせいで数日後に止まるのは解せないが

>>413
協力会社だろうね……。
実際作ってるのは協力会社だ。

>>411
すっ飛んだデータを手入力する為に駆り出された人たち。
人数が沢山いても気の遠くなる作業だと思うよう。
何人かは確実に精神が病む。

他はどうか知らんが富士通は協力会社多すぎて
かつお互いが意思疎通や連絡手段構築してないこと多くて
何かトラブった時に担当者行方不明ということが多々あるから困る。

結局、ちょっとわかる他社の人が「クセのある書き方してるなぁ…」とかぶつぶつ言いながら
推測で手直しして修正プログラム走らせるハメになる。

やっぱフリーＳＥは、仕事場どんどん変えるのが正しいよな。
できたら辞め、できたら辞め。
おかげでシステムトラブルなんぞ会ったことない。

>417
さらにその上の銀行員か銀行システム子会社がブツブツ言いながら確認作業をします。

>>406
わかるわかる
金融機関じゃないけど自分も運用やっていたから
PGも少しやっていたから処理がコケた場合でも
マニュアルとかない対応とかも多少はしたけど
それでも手をつけられないともうお手上げ
翌日の業務の立ち上げとかも遅れたりするから
スケジュール変更とか各部署との調整とか大変だった
上司はあちこちに部署に謝りにいったりとか
支店とかには電話で謝ったりとか
でも上司はなんとなくそんなトラブル対応を楽しんでいた感じだった

明日はハイエナ投機家と放出組出動で証券市場も荒れるぞ。

>>409
なんか勘違いしてないか
俺はCOBOLの悪口なんか一言も言ってない
馬鹿でも使える良い言語だと思ってる
だから無くならない
これからもずっと続く

とっかえひっかえが効くからなPGの
ただ想像もしない低レベルのソース書く馬鹿がいるのも事実

>>418
君はSEとは言わない。

色々なソフト（技術計算系）作ってきたから思うが、
言語はマニュアル片手で十分。
確りしたアルゴリズムと、論理的な可能性を
どれだけ考慮できるかが大事だよ。

>>408
製造した会社に罪はなくて　（仕様通りであれば）、青くなるのは設計したところ

なのだが

その設計を承認した部署やら人間がいっぱいいて、誰が責任を持つのかてんで
わからないようになっているというオチ

>>422
君の業種を教えてくれる？

>>423
議論する気はないが、作ってきたシステムにはそこそこ自信もってるよ。
実際、大きくトラぶったって話も聞かない。

>>426
やだ

て言っても同業者ってばれてんだろうけど

バッチ来------------------------------------------------------------------------------い




ヘイヘイ社長ビビッてる-----------------------------------------------------------------------------ゥ

夜間ﾊﾞｯﾁﾘ処理かと今まで思ってた…

>>427
作るだけ作って放置するSEってｗｗｗ
お前の知らないところで障害が起きてるよｗ

>>406
でも、運用の人やよくわかってない管理系の人がやると、
間違ったジョブとか流しちゃって、DB誤りとかになった日には
更に復旧に１週間とかかかるからね…

いろんな人が承認しているけど最終的に精神を病むのは無茶を押し付けられた開発者

>>431
まぁ作るの好きなやつから、要件をまとめるのを好きなやつから、
顧客が言ったことを社内の誰かに伝えるのが好きなやつから、
火消しになるとやけに張り切るやつから、いろいろいるから、作るだけでも優秀なやつがいてもおかしくないと思う。

おれは火消しになると燃えるタイプ。パズルみたいで好き。

>>425
客「ちゃんと動かすって言ったじゃないか」
親「ちゃんと動かせって言ったじゃないか」
子「ちゃんと動くように作れって言ったじゃないか」
孫「ちゃんと動かすには金と期間が足りないって言ったじゃないか」
子「それ途中で言い出しただろお前」
孫「途中でシステム変更言い出したのお前だろ」
親「責任の擦り付け合いはみっともないから止めろ」
子「お前が言うな」
孫「お前が言うな」
客「とりあえず取引停止なお前ら」

>>428
じゃあ君の使える言語を教えてくれる？
かじった程度でもいいから。

>>420
運用系の会社のマネージャーやってる人ってなんか体育会系というか、
豪放磊落な人をよく見るな

>406
あんたプロだな。

>>368
分離なんて事をしてなければ、システム投資予算半減なんて事になって
保守運用を中国企業に丸投げなんてアホな事にはならなかった

>>382
いまみたｗ
JavaがDBに向かない？？そんなことないと思うけど。
Javaアプレットしか思い浮かばない人ならそう思うかもね。

>>417
ＳＥが各々勝手に作って干渉しあって動かなかった、はやぶさの成分採取システムの不調に似てる

上層部は責任の擦り付け合いに必死
現場は対応でいっぱいいっぱい
こんなところの協力会社は大変だわwww

>>436
やだ
経歴ばれるから

ちなみに情報処理はCOBOLで通った
基本的にループで回す言語は嫌い
SQLオンリーかな

あとはワンライナーが好き

COBOL技術者ってもう10年以上前から少ない少ない言われてるんだが
このまま来世紀にも普通にCOBOL使っていそうだよなｗ

COBOLの2進数を意識させないでプログラム書ける仕様は金融系でトラブルなくシステム構築させるためには
これを超える言語って無いんじゃないか？

少なくとも、俺が10年くらいIT業界の末端でさまざまな会社を彷徨ってプログラム書いて、
プロパー、派遣、営業いろいろ見てきたきた経験から、
2進数ベースの一般的な言語で数兆まで対応するようなプログラムを信用して書かせられるような人間は凄く少ないな。
正直、日本の開発現場の問題は、現場に中堅が少なすぎるんだよな。
やっぱり細かなミスを経験してきて始めて分かることがあるのに、実装をくだらない仕事とみなして
経験２，３年みたいなのに任せっきりにすればいずれ大変なことになるに決まってるよ

明日のサザエさんは
・各銀行のATMにドラクエ発売日よろしく長蛇の列
・投機家、株主が放出、空売り祭り

の二本でお送りいたしま〜す。んがっくっく。

>>440
JAVAのみでDB処理するの？処理速度考えてる？

>>443
やだ
やだ
やだが好きなのねぇ

>>443
ワークステーションレベルのシステム技術者ね。

残高数百円だからどうでもいいや

>>444
金融、保険に集中してるから、前に会った人と違う現場で再会するってのはよくある話だな

>>449
？

ホストもいじるよ、さわるよレベルかな

というかそんなに探り入れたいのwww
なんかムカついた？

>>411
（デジドカ）または（ＩＴ土方）　に１票

>>451
使う側、使われる側がひっくり返ってるという話もあったりねｗ

>>447
それなりには考えているけど、
数億レコード程度のテーブルなら問題なく処理できているよ。

アナタいってるJavaだけってのはよくわからないけど。

>>14
年金保険料がどれだけ消えたと思ってるんだ


※昔は市町村が担当だった

>>148
ぶざまね
ここはじっと我慢よ
動け動け動け！動いてよ！
また恥をかかせおって

がループしてる

金融はコンピューター無しで業務を遂行するなんて無理。だから金出ししぶんな

>>452
ホストってメインフレーム？

にちゃんねるってなんちゃってSE多すぎだな。

メインフレームのオープン系に対する優位が何か理解してないだろ。
Cとコボルっていう話じゃねえよ。

>>455
まさかJAVAだけで完結するDBシステムでは無く、
SQLとかにアクセスしてるなんて言わないよな？

>>413
みずほのシステム開発担当SEは富士通本体の社員だよ。
富士通は勘定系システム部署にみずほ専用の部署作ったからね。
富士通なんたらってとこに投げてんのは地銀のシステムで、
三菱とかりそなとかのメガは、富士通本体がやってる。

まぁPGやってんのは全部協力会社だけどね。

とにかく今はみずほを徹底的に叩くことだ。
それがシステム投資につながるからな。現場には頑張れ、としかいいようがない。

日銀が何十兆円も突っ込んだのはこれのせい？
逆に日銀砲に撃たれちゃった？

TWS?

>>460が解説をしてくれると期待できるスレか

ID:WlcZGe8w0　はなんちゃってSEのIT底辺君だな。
どうせただの運用だろ。

バッチファイル内のコマンドで、別のバッチファイルを呼び出したら戻れなく
なることがあった。　PC-98時代の懐かしい思い出。ｗ

給料がもらえないので、ごはんがたべられません・・・

た〜のし〜い　な〜かま〜が

.　　　　　　　　ポ　　　 ポ　　　ポ　　　ポーン♪
.　　　　　　　　∵∴　∵∴　　∵∴　　∵∴
.　　　　　　　　∴∵　∴∵　　∴∵　　∴∵
.　　　　　　 .┷┷┷ ┷┷┷ ┷┷┷　┷┷┷
.　　　　　　　１号機　２号機　３号機　みずほ

株価100円切れよ。10万株かってやるから。
富士銀行系（IBM）のシステムにしないからこうなる。

>>460
おお！みずほ銀行の救世主ｋｔｋｒ

>>416
派遣を大量投入でしょ

>>461
SQLにアクセスするってなんだ？？SQLは言語だろ？
DBMSに問い合わせすること？
ごめん、アナタの言っていることがおれには理解できない。

>>473
＞SQLは言語だろ？

はい名言が産まれました！

バロスｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

情報化社会といわれているが、現代は江戸時代より退化しているのでは？
電気も電話も無い時代の大災害なのに現代より復旧が早いってどうなっているの？

安政大地震。1855年11月11日（安政2年10月2日）発生。

安政の大地震における江戸中の寺の記録を集計すると、死者数は２２万人にも上る。

昨夜まで外交折衝に追われていた老中（内閣）は、そのまま対策本部と化した。

南北の町奉行所はほとんど無傷であったため、早朝から機能的にスタートし、
ただちにお救い米の炊き出し、仮設小屋の建設に着手できた。

それは一年前にこの世を去った、桜吹雪の刺青で有名な遠山金四郎が、
本郷大火災に対処した時のすばやい処置が、南北の奉行に影響をあたえたからであった。

地震から三日後には仮設住宅に罹災者が入居しはじめていた。

>>128
えええええええ！　仕込みか！？　

不良債権処理で補てんされた国民からの税金国に返せよ馬鹿クソみずほ

処理件数が多くなって……ってのは嘘だな。

計画停電の準備関係でおきたハードウェアのトラブルだろ？


処理件数の遅さ、重複済扱いの数の多さ。
どうみても人力。

>>474
言語以外のなにものでもないだろｗｗｗ
DBMSに問い合わせするための言語でしょうも。アナタが何をいってるのか本当にわからん。

>>469
通帳見せて毎月の給与入金実績があれば
10万を限度に払ってくれたらしいぞ。
俺が行った時はなぜか勤務先の会社名と連絡先書かされたけど
そこで「富士通」って書いたらどんな顔されてたかな(´・ω・｀)

だいたい想定外の処理件数で止まっちゃうんだよな

東証、新幹線、みずほ銀行

>>478
なんで富士通サーバって納入2週間でハードディスクぶっ壊れるの？(´・ω・｀)

そういえばワニさんが８７歳半ボケ婆と暮らす沖縄の
敗戦後FRBユダヤ様が資本なって創った銀行に税金払いにいった時
店員が必死に貯金を定期”にしたら１００万に付き３千円あげます！！
といってたワニがね、これは将来みこした預金封鎖の実験でないワニか
ベンジャミンフルフォ〜ド氏
http://www.youtube.com/watch?v=-PwmAT7Bdf0&feature=mfu_in_order&list=UL
http://www.youtube.com/watch?v=Er80i-Lf8vY
１９７１年１１月６日アムチトカ島スパルタンミサイルW７１
核出力５Mtでの地下核実験（戦時中から日本で起こす計画あった）
http://www.youtube.com/watch?v=qp6aZIhHiRE

夜間バッチってなにやってんの、リアルタイムで処理できないもん？

>>484
他システムから日次で送られてくるデータとかあるじゃない。それを勘定系に乗っけたり、
逆に他システムに送るための当日分や当月分のデータを集計したり。

>>484
リアルタイムで処理やるにはそれなりの処理能力必要だし
処理がコケたら即システム停止しかねないよ。

>>254
BigDecimalだ
他の型では0.1を１０回足して1にならない
こんなのは勘定系やってれば常識

>>460
優位性のあると思われるメインフレームを使ってこのザマをなんと説明するwww

その優位性のためにお金をつぎ込んでるんだけど、それが意味をなさなかったって話だと思うんだが

>>479
わかった。もういいよｗ

>>482
WindowsやLinuxを動かすサーバなんかだと大したディスク使ってないからじゃね？

>>489
ところでSQLにアクセスするって何？ｗｗｗｗｗｗ

給与とか手形とか大丈夫になったんでしょ？
良かったじゃん

>>491
ググレカスｗ

うちの会社も富士通製のシステムが一部入ったけどなぜかよく止まる。
自社の要件定義が糞かソフトが糞かは不明だが。
まあ福島みずほに名前を変えてくれ。

ここまで勘定系が糞だとどうしょもねぇ。
結局閾値をあげようが、増設しようが根本的な解決をしない限りおかわり確定。

今回はFSAへどういい分けるのかｗちゃんと事前に報告の相談しておけよ。
根回ししないと形式だけの注意じゃなくて、リアルに怒るぞあいつら。

なにかくさい。

意図的な預金封鎖のような希ガス。


だいたい１０万円が限度というのは・・・おかしいやん。


準備高不足なんじゃない？　復旧すると同時に他の銀行に預金を移さないと


デフォルトになるとあぶないよ＞１０００万以上の預金者の皆様

明日の営業時間って１７００まで？
それとも通常通り１５００終了？

>>493
SQLってクエリ言語で、アクセスする対象じゃねーだろってことを言いたいんだよｗｗ
まったくｗｗ

>>488

アホは論理的に考えられないといういい症例だな。オープン系だったら対処できるトラブルだったのか？
どういうトラブルなのかわからないのに今回の話に結びつける理由がわからん。

別に、メインフレームマンセーっていう話なんて一言もしてないんだが。
メインフレームにはメインフレームの利点があり、オープン系にはオープン系の利点がある
それは、Cがーコボルが-って話じゃない。
それなのにお前らなんちゃって底辺ITが、知ったか飛ばしてるから批判してるだけだ

>>485 >>486
早速のレスサンクス。
他システムと連携しない場合は、究極の姿として夜間バッチは不要ということで
いいのかな。
>>486の言うように安全性を考慮してあえて分けてあると考えるのが
自然なのかな。

何年かに一回システムトラブル起こすね。この銀行

勘定系はやっぱ怖いなぁ。しみじみ
金融庁から業務改善の注意うけるだろうし、現場は今頃ピリピリしてるだろう

>>488
金融はバッチ多いから、オープン系で組んだら結構目も当てられない状況になるかもね。

>>496
みずほ銀行のサイトにPDFで載ってるよ
ttp://www.mizuhobank.co.jp/company/release/2011/pdf/news110321.pdf
（注：PDF）

>>495
無駄な改行ｳｻﾞｲ

493や474みて
ID:oXP+Npiq0
こいつが徹底的な馬鹿だってわかりました
なんちゃってSE確定です

>>497
SQLデータベースにアクセスしないの？

PCみたく、ホストもなにか障害おきたら、ブチっと電源を切ればよろしい。

>>488
勘定系のシステムは今でもホスト系多いだろ
保守料はクソ高いし、対して早くねーし、それでも使ってるとこが多いのが現実

今回の事故はアホとしか言いようがないが、それでもオープン系に変わることは難しいだろうな

この手のニュースを聞くといつも「もしかしてH社？」と思ってしまう

これ思い出したｗ

178 ： WBC監督(東京都)：2008/09/14(日) 22:30:48.60 ID:mNrtA2B90
深夜のメンテナンス作業で眠くて眠くて、ユーザーの伝票明細テーブルを間違ってTRUNCATEした。
ROLLBACKも効かない。
あせってArcserve開いてテーブルを戻そうとする・・・ログウィンドウを見ると、
バックアップバッチは数ヶ月前から停止したままだった。

頭が真っ白になった。

IDCを出て深夜の自席に戻って、机の中の大事なものをかきあつめてかばんに詰めた。
社員証を課長の机の上に置き、会社を出て、アパートに戻る。
保険証、パスポート、前の年に死んだ愛犬の写真を持ち、始発にあわせて家を出る。
携帯が鳴り始める。何度も何度も何度も。空港につくころには着信が１００回を超えた。
電池を抜き、俺は北海道行きの飛行機に乗った。
逃げるなら、なんとなく北、というイメージがあった。

それから３年無為な生活をし、ほとぼりが冷めたころ、北海道の小さな
ソフトウェア開発会社に就職した。
経験を買われて、すぐにプロマネになる。
そして、孫請けながら大きなプロジェクトに参加することになり、
キックオフミーティングのために東京へ。
発注元とともに汐留で会議に参加する。

・・・会議室には、俺が逃げ出した会社の部長と、課長がいた・・・
ふたりとも、会議のあいだずっと、顔を真っ赤にして俺を睨んでいた・・・
こみあげてくる胃痛と嘔吐感に耐え、会議が終わると同時に俺は会議室から逃げ出した・・・

それが、先週の金曜日のこと・・・死にたい・・・

>>505
具体的にどう馬鹿なのか教えてくれる？
勉強になるから。

>>493
お前、真性だなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>494
まあ富士通が糞ということだ
保身主義者の巣窟

>>475
当時は多発する火災天災に対応するため、
庶民の家なんて建てちゃぁ壊し、ってのが簡単にできるようになってたからねぇ。

あと、今のﾐﾝｽ政権と違って、お上が絶対で統制が取れてたってのが大きいかもｗ

>>508
別にメインフレームを馬鹿にしてるわけでなく
その優位性をないがしろにしたソフトの組み方がチャンチャラおかしいってだけだよ

おれもメインフレームがなくなるとは思ってない

>>507
メインフレームは電源上げてから使い物になるまで1時間以上かかりますが(´・ω・｀)

>>510
これは犯罪だよｗｗｗ
いや笑い事じゃないよな

>>497
SQL SERVERのこと言ってるんじゃないの？
普通それを「SQL」とは略さんけど

なに震災二次被害くらってんの

真面目に仕事してよ

>>499
例をだすとさ、金融の場合、額をさ、按分したり合算したりするじゃない？
そうするとどうしても、オンライン処理がなくなった後、バッチで処理したくなる。

>>510
これ気になるなｗ
続き無いの？

なんか単発IDが増えたな。

>>517
素人にも分かるように解説してくれないか
この人、そんなにやばいことやらかしたの？

>>523
分からない

>>506
SQLデータベースwwwwwwwwww
なにこのなんちゃってSE

富士通系のメインフレームだとGSシリーズが動いてるのか？
DBは何つかってるんだろ？

>>518
あの〜ＡＣＣＥＳＳとかＯＲＡＣＬＥでもＳＱＬ書けるんですが・・・

>>520
具体例がありがたいですｗ
長年のもやもやがとけました。
いちおうSAPに関わったことがあって
なんで夜間バッチなんているんだと
ぶつぶつ言ってました・・・
ごめんなさい・・・

>>518
SQL SERVERってややこしい名付けだよね
実態と聞いてすぐ浮かぶイメージが違い過ぎる

こういう突貫作業で臨時に作成したリカバリ用のPEDやサブスキーマ、ＰＧがいつの間にか本番用になっちゃうんだよな。
数年後、何かあった時、もう違う会社の社員なのに後輩から電話が掛かって来たりする。まぁ俺が悪いんだけどね。

地震のおかげで大して騒がれてないけどこれ大問題だよなぁ
２５日の給料の振込みとかちゃんと間に合うのか？

なぜかCOBOL叩きスレになってて笑ったw

でもCOBOLとその文化がシステム開発に与える
悪影響は計り知れないからな。

この世からコボラーとその薫陶を受けたSEを
絶滅させない限り、悲劇は永遠に繰り返される。

>>499
いわゆる情報系のシステムというか、ちょっとしたDBだったら、
バッチ処理なんて全くもって不要。全てオンライン処理可能。

俺もいくつかシステムを作ったけど、バッチが必要になるようなものはほとんどない。

「参加した」システムは全てバッチありで、開発工数も難易度も高いものばっかり。

メインフレームの優位性て何だろうね？

・DASDいっぱい繋がる
・意味不明のスローダウンとかがほとんど無い
・システムログの管理が楽

他にある？

>>518
俺も、ID:oXP+Npiq0 が言う「SQL」は、恐らく、
「SQL Server」 であるような気がする。

DBというのが、どんな物か理解が出来て
勉強になったんじゃないでしょうか？

>>527
単に「ＳＱＬ」だとＳＱＬ文のこと指すのが普通だけど
「ＳＱＬ SERVER」を「ＳＱＬ」と略す人がたまにいて（文意で分かる場合もあるけど）
どっちさしてるのか分からなくなるという意味だったんだけど

>>525
あのう〜誤解されているようですが俺はSEじゃないよ。
関連スレ含めID抽出すればわかるでしょ。

まあいいけど。

＞SQLデータベースwwwwwwwwww
SQLはデータベースだろ

郵便局窓口から、日赤に振り込んだ俺は、どうやら正解だったようだ。

>>518
RDBMSをSQLっていうことは現場ではよくあるよ。
とりあえず
ID:oXP+Npiq0　ID:WlcZGe8w0 のどっちも開発者でないのは明白だか。
とりあえず、本物じゃないやつに限ってどうでもいい用語のやり取りで
言い争いするんだよな。
むかし、シェルスクリプトのことをシェルって言ったら、さんざんにかみつかれたのを思い出したよ。
確かにシェルとシェルスクリプトは別物だが現場では９割が、シェルスクリプトのことをシェルって言ってるのにね。

>>534
今まで使ってた資産がそのまま使える。
これだけじゃないか？

>>532
もともと従事させちゃいけないレベルの人間を取り込める言語だったってのが不幸の始まり

今となってはいいか悪いかって話じゃなくて
置き換えるためには多大な労力がかかるって事実が横たわるだけ

>>523
大変大事なデータを復元できないやり方で消した
バックアップも取られてないことに気づいて、報告もせず夜逃げした

>>532
COBOL無くならないと思う。
大昔にCOBOLで組まれたアプリが今でも動いていて、
無意味にオープン化もできず、かといって保守のためにCOBOLを忘れるわけにもいかない。

>>538
データベースはSQLじゃないよ

>>538
>SQLはデータベースだろ

SQLはデータベースじゃ有りません。
主にデータベースに使われてる問い合わせ言語です。

>>517
これはどうみても犯罪です。しかも運用オペ全無視ｗ
その前にルールすらなさそうな気配だけどね。

>>521
これしか残っていなかった。すまん。

>>523
顧客の売上データ全削除しバックアップは半年前。
どうみても復元不能です。それは逃げるか中央線ダイブ
しかない。

俺も以前40万件ほどのデータ飛ばした事あるけど、バックアップで命拾い。

>>523
伝票明細をtruncate＝伝票明細を削除した
rollbackも効かない＝「今の処理なしね」ができなかった（→回復できない）
Arcserveのデータが数ヶ月前＝バックアップソフトで取ってるデータが数ヶ月前（→最新にならない）

で、バックれたと。
ネタか現実かどっちもありそうな話だけど

>>533　　　バッチ処理なんて全くもって不要。全てオンライン処理可能。
優秀だな。DOAの設計思想でDATAの正規化がよくできている設計だな。

NDBとＲＤＢが混在してる

>>534
思いついたのは
金融の場合、24時間常時システムが動かなきゃいけないから、毎月osにパッチ充てなくて良いよね。
リスクがでかすぎる。windowsなんて糞だろなと

2度あることは3度あるというが・・・
そのうち残高が無くなるとか、自分の口座だと思ったら他人の口座だったとか、やりかねない。

>>533
なるほど、業務によるわけですな。
このスレは保存しときますｗ

>>540
その現場がどういう現場か何となく想像がついてしまう所が怖い。
シェルスクリプトをシェルと言ってる時点でな。

Arcserveが動いてねえというのはよくある話

>>540
底辺ではシェルスクリプトをシェルって略すのか。

>>540
ああ、あるね
知識だけの人には現場での常識が通用しない事って

前に給与の二重振込みとかあったよね
ああいうのは大歓迎なんだけど

>>289
メガバンクの資金繰りですかｗ

散々貸し剥ししてきたツケを払う銀行も多いでしょうねえｗｗｗ

>>557
何でデジタル土方と呼ばれるか良くわかる例だよ。

>>556
シェルどころかコマンドってよんでる我が職場

>>538
Structured Query Language 紛れもなく言語
SQL Server は単なるマイクロソフトの商標だろ

>>558
調子にのって使って、後でダブり分戻されて泣きをみるがな

お前ら、IT土方で詳しいんだろ？直しに行ってこいよ

いろんな環境の人が集まってる。
底辺の俺にとってはこのスレは勉強になるぜ。
くだらない事で小競り合いしてスマン >>ALL

>>561
コマンド・・・DOSとかCP/Mとか・・・

>>559
ﾒｶﾞでも地銀でも毎日市場から調達して資金繰り付けてるの間違いないけどな

ホストのバッチってＪＣＬの世界じゃないの？

DBだってSAMファイルだろ？

容量不足とか単純にそういったエラーな気がするなぁ

銀行勘定系ならセンターカットっていうオンバッチなんじゃない？
バッチから取引トランザクション起動してして小分けのオンライン処理として全体を処理するやつ
FやAIMはよく分からんからどんなDB構造なのかしらないけど。

>>563
そうだったんだ
知らなかったわー

うちのところはAIXとDB2でした
本番運用開始後、なんかバージョンアップで大揉めしてましたわ。
Tivoliかなんかでほぼ毎日バックアップを取ってた気がします。
データを消して復元できないとか脂汗ものですよね。

>>543>>547>>548
解説ありがとうございました。

つうかさ、ハード増強してこんなに処理能力って低いものなの?
スパコンにやらせるような高度な分析処理をやらせてるわけじゃないのに。

>>552
今からみずほに口座作って1000円くらいいれとくのも悪くないなw

>>554
その他、ストアドプロシージャをストアドと略す奴な。

あと関係ないけど、「SQL」のネイティブでの発音は「シークェル」。これ豆な。

>>561
「コマンド」はある意味正しい。

>>534

まあ、べたな話をすると、障害の切り分けがしやすいから、トラブル起きた時に
上司に報告入れられるんだよね。つまり仕事やってるふりがしやすい
即時に障害場所がわかって、一週間かけて手作業で直しながら進捗状況を逐一報告できるのがメインフレーム
とりあえず完全に止まったら、切り分けに時間がかかるのがオープン系
その代りわかってしまえば、オープン系のほうがトラブル解決が圧倒的に早い。
後者のほうがトータルでの解決時間が短かったとしても、日本では特に前者が選ばれてしまう

日本の場合、上司は発狂してわめき散らすだけだから、トラブル起きた時に、目に見えた成果が少しずつ出ないシステムは
つらいよ。これは、上に行くほど馬鹿になるという日本特有の企業事情によるものだから何ともならない。

>>568
これならエラーコードで簡単に判ると思うけど

>>573
システム設計の根幹が腐ってればハードを幾ら増強しても無駄。
リソースを無駄遣いするだけでどんどん腐敗が広がる。

>>564
自分の分だけじゃなく他の人担当分までこなしてたのに
（エラーも一番少ない）
意味不明な理由で突然切ってくる所なんて行かない。

>>575
くそどうでもいいw

>>564
ひたすらCMTかけてハンコ押すだけの仕事ならエキスパートなんだが(｀・ω・´)

違うラベルのCMT突っ込んだだけでABENDするとか死ねばいいと思います。

>>573
だから、他に何かやらかしいてるんじゃないか？
と、みんな疑っている訳でw

ぶっちゃけCOBOLってどんな言語なの？

クラスベースとかプロトタイプベースな言語しかやったことない俺に解説してくれ

>>540
え？

ま、みずほ銀行はいいかげんてことや

そもそもみずほグループっていまだにトップが3人もいるよね
だからシステムも統合できなくて
内部でケンカして止まってしまうｗ

>>568
今のところ出てる話でありそうだなと思ったのが
口座振替が多い口座を通帳有りの口座で誤って作成し
上限を超過した分が支店取扱い分手作業として戻されたという話
（通帳繰越の処理が重い上、未記帳も上限があってそこをオーバーしたという）

>>564
おれジャーナル運びなら自信があるから
ジャーナル運びの雑用バイトでもすっかなｗ

>>584
MOVE
PERFORM
IF
GO TO
この4つだけ憶えればいい言語

たしかここのＤＢ設計を担当したのはアイネスさんだと思った。
まあ１０数年前の話だけどね。

>>588
それも眉唾だけどなぁ
NBの件数に上限があるってことかな

>>590
完璧ｗ

どうせまたデータオリエンテドなシステムじゃなく、データの正規化のできていない
サブシステムやＤＢがいぱーいあちこちにあるつぎはぎだらけのシステムだろ。
つまり各サブシステムやＤＢ間をバッチでファイル渡ししているような構造になっている。
だからバッチ処理に時間がかかるのだよ。

>>591
ＩだったらDEDB(階層型)がメジャーだと思うんだけど
ここはどういう構造か知ってる？

>>96
ん？君なんか違うような気がする

>>587
やっぱ合併時の負の遺産かなぁ？

夜間バッチ未処理で翌日オンライン立ち上げて
って後処理考えると怖すぎて

今日中は無理だったか・・・
あす間に合わせるといっているけど大丈夫かな。

>>577
>後者のほうがトータルでの解決時間が短かったとしても、日本では特に前者が選ばれてしまう
さすがこれは言いすぎ、システム的にはオープン系が大部分を占めてるよ

>>592
通帳が２４×１１
未記帳（ＮＢ）が９９９
残りが支店扱いになったという話で聞いた

>>593
COMPUTE大切ｗ

なんか、いろんなレベルの人がいてこのスレ楽しいw

>>594
ただ単に統合がきちんと終わってないだけじゃないの

>>601
よく知りもしないのに無理くり参加しようとしてるひとが多い気がする。

>>590
COBOLは事務スキームを以下にプログラムに落とし込むかが肝だしな・・

こんかい暫定的に対応したとしても、また同じ程度の要求があればまたパンクしそうだな。
どうするつもりだろ。

>>322
あはあははあああｗｗｗ

外注は、自社で1から作る能力が無いと、
まず成功しないｗ

作れない奴が出来るのは、バグ数のチェックしか無いもんなｗ
あとは、中国で小姐と遊んでくるぐらいだろ。

なんか、ゴッソリ資産持って行かれたりしたんじゃないのｗシナなんか信用するからこうなるｗ



>>335
昔某社の汎用機のOS作る人と仕事したけど、
その人のサポートは派遣の人でしたｗ
優秀なのかどうかはよく分からなかった、バグの隠蔽もみ消しが上手だなｗ
という印象しかなかったｗｗｗ汎用機だから安心ってのは
トラブル対応がマトモという事が大きいと思う、バグはしょっちゅうあったしｗ

何のかんの言ってもコボルはずっと残るよね？
「言語のリプレースするだけで金は出せん」って理由で

>>603
俺も含めて「富士通」って言葉が出るとスレがよく伸びると思う。
これがIBMだったらそんなにレス付かないんじゃね。

地震と原発と停電に隠れてるけど、本来なら、連日トップニュースクラスの深刻なトラブルだぞ。
年度末になに馬鹿やってんだよ…

中国は…ダメだろう。

>>608
いや実際差があるし

>>593
宣言無いとコンパイル通らないから
enviroment割と大事ｗ

>>601
たぶん富士通、日立、IBM、ユニシス各ベンダーのメインフレーム使用SE、プログラマ、運用がいて、
さらにオープン系のSE、プログラマ、運用がいる。

スレ内容もニュー速+スレとは到底思えない内容。

みずぽ　給与受け取り専用口座でほとんど使って無くてよかった。
ＭＵＦＪに１２００万入れてあるけどペイオフとか怖いから
１０００万以下にしておくか。

>>602
リレーコンピュータでつないだだけ、統合の「と」の字もないシステムなはず

>>595
もう忘れたなあ。今はアパレル店経営者だからｗ
トランザクションが特殊だった希ガス。リカバリもＦSEでも事情を知らないと失敗する。

ほんとの原因は闇に葬られるだろうけど解決だけはしろよな

233 名前:名無しさん＠十一周年 投稿日:2011/03/20(日) 12:04:33.77 ID:g/4ylUdr0
http://itpro.nikkeibp.co.jp/article/COLUMN/20080318/296461/
みずほグループ：勘定系システムの保守を大連で
プロセス構築にインド人を活用


964 名前:名無しさん＠十一周年 投稿日:2011/03/21(月) 15:47:06.16 ID:xR/2pk5I0
http://www.atmarkit.co.jp/fbiz/cstaff/serial/offshore/02/03.html
中国オフショア開発の成功と失敗の実態


責任感もなく、ヤバい時にすぐ逃げる連中と関わりあうと、こうなる。

>>602
合併から何年経ってんだよ('A`)

>>590
GO TO はもう１０年以上昔から使ってはいけない命令になってるけど

下請けのCOBOLマスターがろくな引継ぎもせずもう退職しちゃってんだろうなぁ

ENVIROMENT DIVISIONか、懐かしい
COBOLもPL/Iもさわったことあるけど
めんどくせぇ言語だったな

>>590　>>612
最後にピリオドを付け忘れないように！ w
ケアレスミスを撲滅しよう！ w

なんか懐かしいなあ。

>>615

それは以前のシステムだよ。それが一回こけたから
勘定系だけは統一したはず、ただしそれにぶら下がってるものが多すぎるから
どうしようもないんだけどね

>>620
使い方間違えなきゃ問題ないんだけどね
COBOLではあんまり使っちゃいけないような気がするよ

>>620
GO TOはうちも禁止されてる
構造化言語なはずのCOBOLで「なんでもいいからここに飛んで」って命令は確かに
違和感有りまくりだからなぁｗ

>>616
そうか、そいつは残念
出てる情報を見てるとハードの性能不足じゃなくて
アプリ的な欠陥に運用ミスが重なって整合性ロスト + 人力リカバリーに見えるな
統合のときもやらかしてたけど口振ホント弱いなココ

COBOLのいい点
　・10進演算を使っているので、小数点以下の計算で誤差が出ない。
　　(浮動小数点演算では二進数⇒十進数での変換で誤差が発生する)

　・覚える必要のある命令が少ないw
　　とりあえず、MOVE、COMPUTE(もしくはADDやSUB)、GO TO程度覚えておけばok。

　・(メインフレームに限るけど)JCLに任せれば、物理的にファイルがどこにあるか気にしなくてもいい。

COBOLの悪い点
　・グローバル変数しかない。

　・命令が少ない分、コーディング量が多くなる。
　　下手すると、一つのサブルーチンで数千行というコードも存在する。

　・大文字しか使えないため、ソースの可読性が…。

　・プログラムを移行するプログラムを作ろうとしても、「文化」が違いすぎて作成できない。
　　(人間がソースを見ながら、もしくは一から作り直す必要がある)

　・一番大きい問題として、過去の資産が多すぎて移行できない。
　　経営者から見た場合、コストメリットがないため移行したがらない。
　　技術者から見た場合、安定して動いているシステムを変にいじってバグを混入させたくない。

もう口振やめてﾊﾟｰｿﾅﾙﾁｪｯｸ郵送しようぜ('A`)

中国が悪いんだろ？

>>621
懐かしいｗ
PL/Iでバイナリデータの処理書かされた時は
何故Cやアセンブラでは駄目なのか上司を問い詰めたかった

銀行の勘定系ってどの辺がＣＯＢＯＬじゃないとだめなの？
利子計算？　open系のＣやってる人にわかるように具体例よろしこ。

日本いろいろ大ピンチだなおいｗ

>>620
「例外処理で抜ける時だけ使え」で統一してたとこはあったかな

おまいら蒲田か八王子の出身だろｗ

しかし”店舗外のＡＴＭは２２日も終日休止”って…
このタイミングで三連休（＝72時間）の猶予があったのはまさに天の助けだったのに
それでも完全復旧できなかったっていうのは致命的なんじゃないの
じゃあこれから月末にかけてどこでパフォーマンス稼いで復旧するんだって事になる

>>631
固定小数ライブラリか十進演算ライブラリを使う必要がある。

>>620
多重ループ抜けたりするのに便利だけど、とにかく禁止にするところが多いね。

中国のテロだろ

たとえばオラクルを使っていて、原因不明のDBのパフォーマンスの低下があったとしよう。
ログや資料をオラクルに提出して、一週間待ってれば回答が返ってきます。その間はバックアップで運用しましょう
SEは楽ですね、っていう理由でオープン系を採用するのが外資。

一週間待ってる間に、糞上司から朝から晩まで怒鳴られっぱなし。
それだったらメインフレームでコボル使って
トラブルが起きたら、ソースプログラムの読み直しをして仕事やってるふりできるほうがいいというのが日本のシステム。

>>533
>いわゆる情報系のシステムというか、ちょっとしたDBだったら、
>バッチ処理なんて全くもって不要。全てオンライン処理可能。

バッチ処理等の処理形態はDBには依存しないが。

>>635
致命的でしょ

うちの親族にはミズホは使うなと通知しました
ちなみに口座は今は動かすなと言ってある
振込みが正常に動いたとニュースがあってから資金移動しろと伝えてる

>>635
しかも３月末な
洒落じゃなく預金流出するだろね
少なくとも分散しようとする人が多いでしょ

>>336
NTTに波及したりしないだろうなｗ
本社がここか知らないから、本社じゃなかったら関係ないかｗ

>>631
じゃないと駄目じゃなくて
ＣＯＢＯＬ全盛期がバブル期で
予算かけまくって３次オンラインシステム込みで
各金融機関がシステム導入したからじゃないかと思った。
以降アレ以上予算かけて大規模開発やる余裕がないんじゃないかと

何か今、色々、面倒だから現金降ろさないで、完全にクレカ使ってるけど、
俺のクレカの引き落としや電気代の引き落としとかは見逃さないで処理されるんでしょ？

>>635
店舗外は計画停電の影響という名の電力節減対策で他行も止めだしてるね
三井住友がそうだった

>>637
”スパゲッティになるから”っていうんだけど
でもそれを避けるためにGO TO回避して結局無理のあるコードになったりするんだよな

SKE48の松井玲奈はCOBOL１級持ってる

COBOL→.NET化の見積もり出したらあまりの工数にあきれられた

>>639
昔MSに問い合わせしたら


そんな過去事例ないからお前のシステムの環境依存だから
公開情報見ながら自分でなんとかしろよ。
一応公開情報のリンク貼っといてやるからありがたく思え。機械翻訳だけどな！


という親切な回答が返ってきたこともありました。

>>363
でも、給与振込元がみずほで自分の口座は他行だった場合は、さすがに
そこまで連携出来ないよな
どうすればいいんだろう

>>649
メインフレームからwindowsへ移行？？？

これだけ問題起こしてるんだから、
もうみずほだけ最新のシステム構築したらいいじゃない。
不安定で頻繁に落ちようが、今とそんなに変わらないじゃん。

>>637
それそれ
返ってややこしくなるから例外処理で抜けて後処理に行く時だけ使え
ってとこがあった

預金封鎖か、民主党の活動資金が大量に動いたからじゃないのかね？

公共料金等口振のﾊﾞｯﾁ処理は先週は正常だったんかな？
これから月末にかけて集中してくるのに大丈夫かな(；・∀・)…?

該当ソースを修正する人が永遠に同じヤツならいいけど
担当は変わるから、GOTOで飛ばれるとソースの可読性が
著しく落ちて後任の負荷があがる

GOTO使って神掛かった（なんで動くかわからない）PGM作るやつに
限ってコメント残さなかったりするからな

>>630
自分は日立のオフコンでシリアルポートの制御をさせられたな。
一応、ライブラリは日立から提供されていたけど。

ただ、シリアルポートのバッファが少なくて、すぐにバッファオーバーフローした。
受信時に割り込みかかる仕掛けだったのかな？
結局、ポーリング方式で対応したような記憶があるけど。

>>645
銀行統合時のトラブルでは引き落とし遅延とか普通にあったよ。

さすがに事故扱いにはならないけどクレジット枠の清算もされないから
天井張り付いてる人は死ぬんじゃね。

どこの銀行だって同じ事。なんでみずほだけがこんな時に間抜けな事になってるの?って事。

怠慢愚弄精神で経営してるからだろ

特定の２国に対する多数のトランザクションだろ。
生活保護費とか盗んだ金とかじゃねーの？
口座名義見て、特ア向けの処理を棚上げにしとけばいいのに。

>>627
>COBOLの悪い点
>　・グローバル変数しかない。

これは違う。 手続きを外PERFORMで呼び出すのではなく、
プログラムを入れ子で記述してCALLで呼び出せば、
外側と内側のプログラムで変数のスコープが異なる。
パラメータの引き渡しは、ふつうのライブラリと同様、
USING句を使えば良い。

このトラブルってファクタリング処理なのか？

SECTIONが長いやつは確かにGO TOあると読みづらい。
SECTIONが短ければGO TOあってもいいとおもうけどな。

>>635
通常夜間の半日で終わらせなければならない処理が
3連休というリカバリーするには気分的に余裕のある休日中なのに
未だ終わっていない所がもう致命的。

ハードを増強すればいいレベルでは無い。

>>635
同感。

まさに天の助けで3連休を得たのに、その時間を何に使っていたんだろう？
現場は当然、最大級の努力をしたと思うから、結局は上がよく分かっていないんだろうな。

システムは目に見えないせいか、経験したことのある人とない人で全然違う。
勘所があるかどうか、陥りやすい落とし穴や効率的な方法を知ってるかどうか、で
リカバリのスピードと精度が全然違う。
上層部にそういう人がいないと、不思議（≒理解不能）な指示が次から次へと届く。

原発以上に人災なんじゃないか、という気がする。

>>646
他行は停電対策とかあるかもだけどみずほについては
”店舗内のＡＴＭについては午前８時〜正午まで振り込みができない状態が続く。
現金の引き出し、預け入れはできる。正午〜午後３時までは振り込みもできるようになる。”
とか言ってるし…要するに綱渡りだもんな。
こんな銀行怖くて使えるかと普通なら思うはず。

個人的には[SQL]は[言語]か[データベース]か等という話題は好き。

この世界、働く先で方言見たいなものは、よく有ることだけど、
その中システムの中で、きちんと統一されていれば無問題だと
割り切っていた。（私はこの世界から足洗ったから）

ただ、その場合、他から人連れて来れないし（言葉が通じない）、
そこから旅立った人は行った先で苦労するけどね。

これ、フジネットワークの募金振込みでダウンしたって噂あるけど本当?

>>637
ループをＧＯＴＯで抜けるのは判断がそもそも間違ってるんだと思う
上にあったように例外へ抜ける場合は仕方ないけど

アセンブラを忘れないで

ＣＯＢＯＬのほうがいいコンパイラがあったりすんのかなぁって
おもったけど、時代遅れじゃね？

>>650
Technetのインシデント使って何回かMSに質問したことがあるけど、まともな回答がきたけどなぁ。

>>533
無理だよ、無理。絶対にバッチ処理が必要な処理ってあるよ。
「締め」って概念がある処理は基本的に処理時間の長短にかかわらずバッチ処理がいるよ。

>>657
昔、システム更新するついでにコボルから多言語にリプレースする仕事があったんだけど
ひたすら「元ソースにコメント入れてくれ」って仕事があった

プロのPGでも他人のソースを追っかけるの苦手な人は多いんだよね

無理してGOTOを使わないようにするとフラグやリターンコードで
汚いIF文だらけになった記憶があるｗ
組み方が悪かったんかなｗ

>60
山奥としか書いて無いところがが正解か？
データが飛んだかどうかは今後の問題だが、データセンターに甚大な被害。極めてまずい状況かな？
でもって、そんなことは（特にデータセンターの所在地）は絶対に公表できないので、まあ適当なこ
とを言ってごまかしてる。取り敢えず稼動している方のデータセンターも大丈夫なのかと・・・・
なぜ同じ地域に・・・・小一時間・・・・
データというよりみずほ飛んだっぽい。

>>675
俺結構好きだぜ、人のソースみんの
えらい疲れるけどな

>>538
なんだろこの基地外、と思ったけど、自身満々に間違った
ことを言って、突っ込みで教えてもらうっていう狙いなのか？

>>659
何だ、遅延だけかよ。
今月の利用は無かったことにして欲しいぜｗ

クレジット枠の天上って何？
クレカで借金してなきゃ関係ないよね？

おい、明日の朝にはどうにかなるんだろうな？

>>662
そうか、USINGなんてあったっけ。
確かにそれを使えばライブラリ化できて、ローカル変数も使えるようになるね。

ただ問題は、(自分がかかわったプロジェクト限定だけど)誰もUSINGなんて使っていなかったという…

>>675
追っかけるのが苦手というより人によって癖がありすぎるんだよ
バグやら改善修正やらで他人が触りまくってると何がなんだかわからんよ

データ使っておってみないとソース見るだけで追えることなんてほとんどない

>>681
ならない事が発表されてるよ

「72時間もあったのになぜリカバリーできてないんだ！」って

たぶんコンビニに食べ物売ってないから労力落ちてるんじゃね？

>>672
枯れた言語だけど分かりやすくて安定しているって感じかな。
新聞、ラジオ、テレビ、インターネットの中で立ち位置を無理やり当てはめるとラジオ位の立ち位置。

これって、特定の口座に集中って
今回の震災の募金？

>>654
自分が経験した中で、自分が一番妥当だと思ったのは

・プログラムカウンタを進ませる向きでのgotoは許可、
　プログラムカウンタを戻させるgotoは禁止
・goto経路が交差するのは禁止

っていうルールだな。
前者は割りと分かると思うが、後者がどういうことかというと

(処理1)
goto tag2;
(処理2)
goto tag1;
　：
tag1:
　(処理3)
tag2:
　(処理4)

みたいな飛ばし方は許可しない、っていうルール。

>>681
明日の昼にはなんとかなるってレベル。

俺の職場でも1980年代にコーディングされたCOBOLプログラムが
まだ稼働しているんだよな。
当時の仕様書なんていい加減なものだし
もう下手に触れない状態。
みずほもそうだったのかな。

>>675
というより、そのソース書いた奴が二度と捕まらないなんて業界じゃ普通だし
人を買い叩いてるから常にソースを追っかけて直せる奴がいるとも限らないしね

会社の経理してるけど、数年に一度くらいは間違いで数千万の入金あったりするよ。
すぐに修正の引き落としあるけど。ｗ

>>689
それもあくまで「予定」だからねえ
この調子でいくとどうだか・・

>>640
>バッチ処理等の処理形態はDBには依存しないが。
？

小さいシステムだったら全てオンライン処理で問題ないけど？
外部ファイルの取り込みを夜間にしたい、とかならバッチ作っても良いけど。

その場合も、即時性を求めないなら朝一にオンライン処理で取り込む方が作り手は楽。

実質一人で作るようなシステムだから、トランザクションは100件/日程度。
四半期末や、年度末は異例処理が必要なシステムもあったけど、それは専用機能を作って処理することにした。

>>119
IBMは富士銀と興銀だった

>>688
＞　プログラムカウンタを戻させるgotoは禁止
これ＋「グローバルな変数」で死ねるなｗ
もうおれじゃ、プログラム追えなくなるｗ

コンパイルオプションにTESTを付けると鬼DISPLAYの嵐がコンソール上に表示され
何がなんだか分からなくなる。しかもＰＧの３／４は注釈でＰＧの解説とかザラだった。

>>620
COBOLでもGO TO は禁止なのか。
今はC,C++,Objective-Cで仕事をしてるけど、新人の頃にCでgo toでreturnに飛ばすように指示して来た上司を馬鹿にした事を思い出した。

自分はこの業界にいるけど、この業界嫌いです。

>>695
I捨ててFにしたんだwww

最悪の選択

>>678
ひたすら忍耐だよね

>>683
一人ならまだ良いけど、長年の内に何人もの手が入ったソースは確かに酷いよねｗ

もうまずCOBOL要員を探すのが至難の技だから
人海戦術って訳にもいかんだろうしなあ

ここは
コボラー臭いインターネットでつね

>>635
「店舗害外ATMだけ休止とか」正直なんでこんなへんな対応するんだろう。
素直に、ごめんなさいして、22日は全面的にオンライン止めて、
振込のバッチの障害を徹底的にやっつけろ言いたい。
でないと、悪化する可能性の方が大だと思う。

これ、給料もらえない人かわいそうだよ・・・
弁償してもらいなよ

>>700
Iは人月高いからなｗ

>>704
店舗外ATM動いてると回金したり締上したりで人員取られるからじゃね

>>697
年次バッチ流しながらコンソール見てたら

「コトシモ　アトスコシダ　ガンバレ　！」

とか流れた時は妙にイラッとした。

たまたま動いてる時間に３万円下ろせて良かった

>>701
癖あるからね

修正あると毛色が違うから注意が桁違いに高くなるけど

>>677
データセンターってこれから東北、北海道に移すべしという機運だったのにな
気温が低いので冷房にかけるエネルギーが減るから地球温暖化対策とかで

メインフレームから離れて随分経つけど、2002年の統合時トラブルの時は十分なテストなしで結局
一勧の富士通機(OS:MSP)、富士のIBM機(OS:VSE)、日本興業の日立機(OS:VOS)をリレーコンピュータで繋いで
ぐちゃぐちゃになったと記憶してるけど、今回はどうなのかね？

>>691
> 人を買い叩いてるから常にソースを追っかけて直せる奴がいるとも限らないしね

結局コレが根本的な原因だよな。

>>696
グローバル変数使うと、変数スコープ関係なく「常に」変数が見えるから
それを好む人もいたりするんだよなｗ
まあ、共感はしないが理屈は分かるってところだが。

それと同じ理由で、

・可能な限りdefineは使ってはならない。
　配列の要素数定義以外では、必ず const変数を使うこと

ってのはかなり妥当性があるルールだと思った。

個人的には、「構造体以外にtypedefや型名置換目的のdefineを使うのは禁止」
も付け加えたいところだが。

　

維持管理で最低限の体制（分かる人だけ残す）はあるだろうから
その体制でもわからないのなら　多分　オワタ　なんじゃないの？

いくらCOBOL分かる人連れてきても維持管理してるひとより
出来るのかなぁ？

>>674
俺が作ったシステムの中には締め処理のないものもあった。だからバッチは必ずしも必要なかった。

今回のような勘定系だったら、そりゃ無理だ。絶対にバッチ処理が必要になる。

だけど、世の中には金融機関でもバッチ処理不要のシステムがある。
規模は確かに小さいけど、結構重要だったりする。

単に、お金（予算）がないだけとも言えるかもしれないが。

>>705
給与振込の延滞利息ってあるのかねぇ
対応してほしいもんだ

>>695
大和銀もIBM

一週間早くてよかったな
これが年度末だったらどうなっていたことかｗ

>>675
新卒で入った会社が計算センターみたいな業務をやってたので
退職したおっちゃんの書いたCOBOLやアセンブラコード読んで年末調整計算や給与計算の修正とか
おっかないことやってた
おかげでしばらく古いプログラムを解析できるというだけでご飯が食べられたよ

何ヶ月後かに日経コンピュータで特集されるのか

>>700
国内シェアNo1、技術と信頼の富士通です（ｷﾘｯ


事務所の隅っこで富士通とエフサスが喧嘩するの何とかならんか…

こんな糞銀行はつぶせばいいんだよ。

>>718
例え明日処理が掃けたとして
年度末クリアできるかどうかは判らんぞ

安くしたかったんだろうが、この業界安かろう悪かろうだからな。

バッチ？
パッチだろ

>>711
群馬県館林にデータセンター置いてる会社とかバカの極みだな。

>>675
VB.NETだけど、それに似たようなことをやっている。

VB.NETでも今はXMLコメントでドキュメント化できるんだから、それを活用すればいいのに、
コメントは入れない、いわゆる関数と関数の間も行を詰めるから、関数がとこで終わっているのか
わかりにくいとか。

あとは訳の分からないフラグを使いまくったり、コードに直接数値を記述したりとか。

でも、それを注意すると作った本人は切れるんだよな。
一応、オブラートに包んで言っているんだけど。

コーディング規約？　そんなの作る暇があったらプログラム作れと言われるw

俺の家は貧乏だったから夜になると母親は俺のスボンにひざあてを縫い付けてくれたなあ

残り3万件だってさ@NHK
給振は全部処理したらしい

「福島」「みずほ」の2つは日本破壊のキーワードなんじゃないか？

30000JOBですね。わかります

夜間バッチは何ステップあるのかなあ。

パッチワークはあまり得意じゃない。てか好きじゃない。
身を削って本格対応するのも馬鹿らしいとは思うが。

バッチイ話だ。

一体どれくらいの会社がこのせいで不渡り出す事になるんだろう。
みずほのせいで倒産だなんて嫌だよね。

>>721
Fもゴリゴリやる仕事は向いてんだけどね

今頃下請けが泣きながら渋谷の不夜城に監禁されてると思うと泣けてくる

すごいねあと3万ってｗｗｗｗ
朝までに　３件／秒　でおわるね。

>>726
館林のDCってFだよね。
今回のも館林にあるの？

これは…”営業してる”というサービスレベルには程遠いな…
http://www.mizuhobank.co.jp/company/release/2011/pdf/news110321.pdf
ローンとか相談とか普通に終日受けてるのにちょっと笑った。
システムリソース食わないのはわかるけどそんな事やってる場合か！ｗ

>>728
夜間パッチだなｗ

>>635
これは本当に根が深い問題ぽいね。原因解ってないでしょ。
そこは触れずに、明日の午前ってｗ

72時間は何をしていたんだ？となる。かなり深刻な問題だね。
もうIBCSとか関連のない所から今猿連れこんで、富士銀系に戻せよ。
みずほ総研は止めろよ。名前が悪い

>>730
今浜岡止めろと騒いでるおばさんですね

>>719
たまに自治体の税金の計算で後から計算ミス見つかって
何年も遡って還付とか大騒ぎになることあるよねｗ

>>735
手形交換の特別措置がでるかもな
どうせ地震で出てるんだしついでだよ

あ〜まじでメインバンク東京三菱にしようかな・・・

>>739
メガバンクのDCは自前だと思う。
一ベンダーのDCなんかにまかせないだろ。

メインフレームでCOBOLって旧態依然とした
システムの良いところはね、ハードもソフトもとにかく
堅牢なのよね。金融系に最適ね。

まずハードは滅多に壊れない。
オープン系だとあちこちよく壊れるでしょ。
壊れてもベンダーの常駐担当者がすぐに手配して直してくれる。
（ベンダーが常駐しているのはメガバンくらいかも知れんが）

ソフトもね、COBOLはトリッキーなコードが書けないし
変数宣言場所が一つにまとまってるし、変数スコープがないから
ソースを見た時にロジックを掴みやすいね。
10進高精度演算も大きいね。これないと口座残高狂いまくりね。

んで実行ファイルがWindowsのようにOSとデータもろとも巻き込んで
青画面で落ちるとか、ダンマリになるとか、そういうのないからね。
システムがOSとそれを支える各サブシステムに分割されていて、
アプリが万一落ちても、サブシステムの詳細なエラーコードが出て
原因の当たりが付けやすいのね。

あとデータベースがRDBじゃないから、人間が手でデータベース構造に
アクセスするのが難しいのね。
RDBは扱いが楽だけど、その代償として気軽に手でSQL発行して
内容更新したり、データ盗んだりできちゃうっしょ。これとても危険ね。

とにかくおまいら、もっとメインフレーム＋COBOLの堅牢さを
知るべきだと思います。

>>739
そこまでは知らんし知ってても書いちゃダメじゃなかろうかｗ

>>738
「まともなコンピュータ」で「まともなプログラム」だったら、3件/秒なんて余裕だろw

>>700

IとHならどうだろう？
個人的にはHの方が好きなんだが。

サービスの悪さ態度のデカさでは日本一だね

この時期はわらわらと異動がある
メガバンの異動は２週間内完了だっけな

時期的にも最悪だったな

>>737
どうだろうな、俺は銀行のシステムは知らんが
毎日不夜城じゃねーの？毎日のバッチ処理を見届ける奴がいると思うんだが･･･
それともエラーでたら歩いて5分のとこから集合ってパターンかな？

>>747
やっぱりそうなのか
フロア丸々借りたりとかでベンダー系のDCに入ってるのかと思った。
確かに自社の建物も一杯あるだろうし、土地としては何とかなるのかな。

>>727
コーディング規約にうるさいとこはギスギスするんだよね
でも緩過ぎても問題だし

何重にも下請け構造で、現場のPGにはまともな給料が出ないだろ。
能力があるやつが集まるわけないじゃん

>>749
そりゃそうだなｗ

まだ年度末まで猶予あってよかったな

企業の決済口座切り替える余裕があって

ハード増強をケチってキャパが全然足りないんじゃないの？
みずほ自体もケチな上に間に入る総研がやたら穀潰しだし。
証券も酷いケチだしあのグループは本当に内部が酷い。

>>737
被曝の危険の中、任務を遂行している人には到底およばないものの、
それでも今頃精神をすり減らしている現場下請け会社の人には心の底から同情する・・・

いろいろ言い分もあるだろう
恨み節もあるだろう
しかし、その声が上に届くことはないんだ・・

>>714
保守要員なんか残してないだろ〜
仕様変更で食いつないでない限り
作った人間は大体どっか行ってるよ

システム障害って、地震は関係なくね？

ホストがあるだろう東京は、別にこわれてないだろ。
それに、銀行のシステムとか重要なのは、
自然災害で壊滅しても大丈夫なように、
関東と関西で二重化してたりしなくね？

金を下ろすヤツが集中したから、何か
システムがおかしくなったってこと？

みずほ以外の銀行は、なんで障害が
発生しないの？

>>759
今更無理だろｗｗ

>>754
それは毎日見守るだけのお仕事の人がいるんじゃ？
エラー出たら勝手に担当者の携帯にメール入るはずだし

あとCOBOLのいい点でもあり、悪い点でもあるんだけど、データ列をプログラム中に記述するんだよな。

仕様変更で項目追加があった場合は、FILLERで余っている部分を使えばいいけど、
文字列の桁数が増えた場合は…

>>752
２０年くらい前だが、大企業病をぶっとばせ！というビジネス書がヒットした

著者は富士通だった

50過ぎのオッサンらが呼び集められて
ソースから設計書もどき起こしてるんだろうな・・・

>>747
確かに限りなく自前に近いね
IIMSのSAILやらCAPやらACPやら日本IBMしかデリバリしてないし・・・

>>703
だが、それがいい。

>>751
頼む側に技術があるならHのほうがいいんじゃないかな
ただ仕事は時間かかると思うよ

技術ないならI一択だと思う

コボラーって今50手前位か？
先輩がそうだったが

>>771
そういえば、電話屋Nってこの手のシステムつくりとしてはどうなんだろう。

>>768
いやー、既に退役した60代のｵｯｻﾝ連中だろうよ

現場は生き地獄だなｗ

>>755
大手保険会社もDCは自前です。
なので金融系は基本自前じゃないでしょうか。。
事務はBPOだけど

>>768
むしろ、中国人と不毛な言い争いしてるんじゃね？
システムの保守は中国に移管したそうだし。

>>754
バッチのログ監視はまた別にいる

システムの人たちって人と人との連携がめちゃくちゃなんだよ。
性質上仕方ない部分もあるんだが、大規模トラブルの場合
連携ミスで長引いてるのもあるんだと思う。

＞739
いや、もっと震源地に近いってば・・

全銀とかはNだけど、勘定系は聞かないね。

>>730
おもろい！
そのとおり

>>738
3万人用意すれば一人1件じゃんｗ

しかし、お昼の段階ではまだ、60万件位残ってなかったっけ
それが、いきなり後3万って、とりあえず解決方法見つけたって事か？
でも、あと3万って、そんなに時間かからず終わると思うんだが、手動での対応が必要な部分で
時間がかかるって事か？

>>760
>ハード増強をケチってキャパが全然足りないんじゃないの？
これはどの業界にも言えることだが、システム関連部署のお偉いさんはあんまり出世しない（できない）
つまりそういうリスクを認識できる人間が上に少ないってことなんだよ

>>770
コボルに始まってPHPとかのWEB系もやったけど
もう離れて数年
今の現場じゃトレンドもガラッと変わってるんだろな

>>773
どうなんだろね
あそこはどこも取り入れてるから

いい話も悪い話も両方聞くからね

長いJCLを編集するのに画面スクロールもできないダム端末の馬鹿！

>>777
いや、喧嘩が発生するような仕事ｊは大陸には出していない（出せない）と思われ

>>756
同意。
コーディング規約を作ったら作ったで、それに縛られるのは目に見えているし。

ただ、中国人を雇ったときに「コーディング規約はないんですか？」と言われた時は問題になったな。
その中国人を相手に、社内のSEが複数人張り付いたり、エロサイトからエロ動画をダウンロードしやがって
ルーターのNATテーブル使い果たして社内ネットワークをダウンさせやがったり、
検索サイトとして百度使うから、スパイウェアまみれだったし。

で、出来上がったソフトを見てみてるとセキュリティは何も考えていない、同じ処理をまとめていないで
酷い出来で、自分はそれで(本当の)鬱になった。

結論：できるだけ中国には関わるな。

>>784
そりゃあ、問題の根源としては「仕事が多すぎて追いつけなくてどんどん溜まってしまいました」なんだから、
三連休フルに使えば、そのぐらい進んでもおかしくは無いよ。

>>780
別の場所なのか
でも、ある程度解法見つかったら遠隔で対応すれば良いんじゃね？

>>694
それはシステムの規模云々でバッチ処理が不要になった訳ではなく
そういう業務だったということ。

規模は関係ない。

Hadoopとかで夜間バッチなら出来るよね。

>>784
ノーマル処理で対応できる57万件が処理終わって、残った3万件が今回の元凶とかなｗ

>>748

ただし、それを動かすCPUがないんだよな。
IA-64上で動いてるシステムはあるようだがな。
確か日立のVOS3は９５年に開発したCPUいまだに使ってたはず。

IA-64も開発止まってるしねえ。まあ、金融系って、それほど処理能力必要ないんだけど。
それにしても、二十年前のCPUじゃ限界あるだろう

振込みが終わらなかったら、中小企業は、何社か
倒産するの？

こう言う銀行の不手際の場合、法的になんか助け
てもらえるの？

>>794
あれはまだ技術者が少ないからなぁ

ある意味、福島原発の消防よりも勇者じゃないのか？

>>744
住宅控除忘れて契約会社から還付の遅延利息請求されそうになって
泣きそうになった事ならある

>>738
この3万件ってバッチ処理前はデータ手入力の人海戦術だよね？

生き地獄だ・・・・

>>790
情報収集で中国や韓国の政府系や銀行系サイト閲覧してる部署から
ウイルスやスパイウェア検出されまくってウイルスバスターさんがブチ切れまくってるんだけど
あそこら辺の国って一体なんなんだろうね…

バッジかパッチかしらんけど、ちゃんとしとかんと致命傷被る人が出てくるやろーが
給料日で月末で期末やろ

>>772
45〜50歳くらいかね
自分は20年目だが、新入社員時にはもうC全盛だったし

Hadoopはログ解析とかなら最強だけど銀行とかのデータ同期が
重要な更新処理には向かない

>>802
2chでそんな疑問投げかけるなよ
特亜だからに決まってんだろ

ANALYZEし忘れてトランザクションが固まったんじゃねーの？

hadoopなんて怪しいもん、銀行で使えるかよｗｗｗ

>>790
多人数でやる場合は、コーディングルールは必須じゃね？

必ず守る事と、出来れば守る事、って決めていけば良い。

>>798
Map-ReduceのMap部分だけでもやらせたら、トランザクションの要らない処理を分散させられて、
結構速くなると思うんだが。
まぁ、二日で作れって言われてもできんだろうけど。

>>785
みずほ合併時にシステム部門がかなりの人数を総研に転籍させられちゃったしねｗ

明日のAMは振込受付しませんって、実質明日着金は難しいですって言ってるようなもんだな

>>795
ああ、そういうケースもあるかもしれないなあ。
その3万件、ひょっとしたらさらにその中の1000件が、糞詰まりを起こさせてた可能性とか。

>>790
個人的には、コーディング規約は本当に現場引退するぐらいの経験者の人が作るべきであって、
頭でっかちの理想論で固まって現場を知らない若造に作らせるべきではないと思うんだよなぁ。

DB吹っ飛んだとかないの？
つまんねーなぁ

よく解らないけど津波で陸前高田辺りに置いてたサーバーが水没してデータ消失になったの？

>>786
私も金融系の運用から足を洗って10年立ちます。
今現場をみたら私は完全に浦島太郎状態です。
このスレは興味深く有益な情報があるのと、ノスタルジーを感じてつい見入ってしまいます。

原発も銀行もダメになる構造が同じなんだよなぁ。
どんどん下請けに放り投げて行って末端の労働環境がひどい。

>>812
明日そんなことしようと思う奴は勇者だぞwww

>>814
クレジット会社のDB飛んだら喜ぶ人も多いだろうが
銀行のDB吹っ飛んで誰が喜ぶんだよｗ

みずほ
りそな
新生

俺にとってきな臭い3銀行

>>794
分割耐性採って一貫性捨てちゃまずいだろ、ここじゃ。

日本以外の銀行はどんなシステム使ってるの？

>>816
でも、変わるのはトレンドだけで、
やってる事は大差無いと思うんだ。



そういえば、パトライトって何所についてる？
プリンターに付くパトライトなら作ったことあるｗ

>>510

自分の身に起こったらと想像したら恐怖で吐き気がしてきたｗ

井上真央のおっぱい画像をうｐしてお詫びすべき。

>>804
なるほど
ちゃらんぽらんでリストラされたけど
何故か今は県庁に契約だけど入って更新しまくって５年もいる
コボラーって使えるのかなと思ってw

>>802
平和ボケしているけど、実際は「情報戦争」状態なんだよな。
ルーターのログをみると、ウィルスやワームからのアクセスがあったりするけど、
時々、(中国や韓国の)閲覧したサイトからポートスキャンがあったりとか。

だから、中国がOSとしてソースコードが公開されていないWindowsではなく
自前でLinuxディストリ作ったりするのも理解できるし。
(それ以前に、割れが横行しているけどw)

>>822
あんまり聞くな
参考にならん

日本の銀行って決済一番進んでんだから

>>821
結局、一貫性ってアプリで担保するしかなくね？
単純に技術者が少ない。まだ実績ないし、時期尚早ってだけな気がする。

>>822
大福帳とそろばん

>>773
昔N系の仕事したこと有るけど、Nの子会社の社員がテストして無いjob流して帰りやがった。で、下請けの下請けの自分がデバグした。
先輩に拠ると、Fは仕様書などの書類には厳しいが、Nは紙が沢山有れば内容は何でもいいらしい。

>>816
でも、WEB系やってた時に感じたのは「後から入ってくる人ほど大変だなぁ」という事
過去の技術の上に乗っかる形で新しいものがどんどん出てくる
自分は基礎部分から知ってるけど、まっさらな人がイキナリこの環境じゃ
可哀相だなと

>>510
ちょ、ひでーｗ
しかし巡り合わせだな
ネタなのかマジなのか分からないけどｗ

>>821
作り方次第だと思うんだが。
トランザクションが必要な部分のみの抽出だけでも使えると思うんだ。
いまはメインフレームとかでやってるんだろうけど、
その部分をEC2にやらせるとか。

自分で書いててEC2はあり得んっておもったけど。

通常半日で終わる夜間バッチ処理が3連休使っても終わらないとは
処理量的には考えにくい。

取引がグチャグチャになっていて、多重引き落としとか
出金と入金の一方しか処理していない状態が発生しているのか？

>>809
プログラマーのレベルが同じなら問題なく作れるんだろうけどね。

コーディング規約を上に合わせると下がついていけないし、
下に合わせると、とんでもない規約が出来上がっちゃうし。
(下のレベルを上げる必要があるのは当然なんだけど、その「当然」ができないんだよな)

あと、インターネットで公開されている出来合いのコーディング規約を参考に、と提案したけど蹴られたw

>>832
N系も沢山あるけど、勘定系をやってる所ってDが付く所かな
他のN系は結局他のベンダーと組んでやってるだけな気がする

福島原発とみずほ銀行をつなぐのは

福島みずほ

黙示録に記載された使徒の1人はまちがいなくこの女。

>>835
作りが悪くて追いかけっこの多重処理とか地獄が発生していると想像しているｗ

>>748
>変数宣言場所が一つにまとまってるし、変数スコープがないから
>ソースを見た時にロジックを掴みやすいね。

「変数スコープがない」というのは違う。 >>662 にちょっと書いてある。
ただ、多くのCOBOLプログラマが、敢えて「変数スコープがない」
即ち全部グローバル変数という書き方をしているのは確かだね。

だいぶ前だが、昔俺がCOBOLで書かれたシステムの保守をしていた頃
(金融系ではないが)、プリンタ室にジャーナルを取りにいったら、
誰かがプログラムリストを出力していた。
A4用紙の両面刷りで、厚さが1cmぐらいあったと思う。
「巨大なプログラムだなぁ」
と思ってパラパラめくって見て驚愕した。
そのプログラムの厚さ1cmのうち、約7mm ぐらいは、DATA DIVISION
すなわち変数の定義で占められていたからだ。

確かにこのプログラムは
>変数宣言場所が一つにまとまってるし、変数スコープがない

といえる。そして
>ソースを見た時にロジックを掴みやすいね。

といえるかどうか、>>748 さんに聞いてみたい。

>>834
通信、銀行などミッションクリティカルなところは外部の
サーバなぞ使わないぞ。すべて自前システム。
場所によってはハードウェアから自前設計。

>>776
なるほど、そうなのか
やっぱりお金の関係するところは自前が多いって事なのかな

この業界のことは知りませんが、ソースレビュー的なことはせんの？

>>838

0C7

>>840
それコツがあるのよ

LOAD CLEAR ですべて解決

>>831
そうなのかぁ。
俺が一度だけ電話屋Nの人と仕事したことあるけど、
とんでもなく頭が切れる人たちだなぁって印象しかなかった。

>>836
コーディング規約制定に必要なのは、「高い技術力」の人ではなくて、
「幅広い分野の経験者」であることだと思うなぁ。

>>840
PROCEDURE DIVISION内のプロシージャの行数というか、
一つのプロシージャで最大何行あるかも知りたいw

>>836
なるほど、俺の時はそれほど下って人は居なかったから
何も問題が出なかったｗ

C++じゃ無くて、Cの時代だったから、今より緩い規則だろうけどｗ

コボラーの俺が遊びに来ましたよ＾＾
おまえら、ホスト舐めすぎ、だったらオープン系で今の処理やってみろよ
中身は単純でも、アホみたいにいろんな要素（ＮＥＴとか）の処理するには
汎用機しかいまだに処理できる機械は能力無いんだよ、擬似リアルみたいな処理までは大丈夫だけどな

それにしてもかわいそうだ、みずほの仕事していた家族がｗ>>845吐いた反故冷害・・・ｗ

>>828

というか異常に進んでるんだよね。海外には銀行間決済が即時できるシステムなんてそもそもないし。
それどころかごく一部の大手銀行以外は、同じ銀行の口座間でも即時決済できないところが多い。

>>841
自前設計はしらんけど、サーバは自社管理なのは知ってる。
ま、クラウド系の好きなときにインスタンス増やせるタイプの奴でやれば
一番良いんだろうけどと思っただけ。

現実的ではないってのは、>>834にも書いたけど、わかってるｗ

>>823

＞そういえば、パトライトって何所についてる？

パトライトという用語が分からなかったのでググってみましたが、
マシン障害を知らせるランプはメインコンソール卓付近にあった記憶がします。
アラームも鳴って心臓にとても悪いです。

CODE=000C

リアルタイムシステムというのは、組むのがめんどいんだよな・・・・・・。

>>843
下請けの中だけでやる。
下請け同士が行ったレビュー記録表とかも納品物になるかなぁ。
設計、製造、試験も下請けに○投げ。

っていうのがおおいんじゃないかな

>>829
アプリで保証するったって無理でしょ？処理対象のデータが同時刻のものである
保証がないんだから。

>>854
今、散髪屋さんに待ち時間表示用にパトライト使ってるよね
あればびっくりしたｗ

>>835
夜間バッチはとっくに終わってるだろ。
そこで作ったトランザクションが全く履けなくて、お手上げなんだろ。

多分だけど、ミドルレベルの流量制御が出来てないせいで、本来の処理能力が出てないのが原因かと。

>>848
中小というか零細企業には、その「幅広い分野の経験者」がいないんだわ。

今は勉強会ブームで、各地で勉強会やっていて自分も参加しているけど、
(その後の懇親会目当てもある)で、会社の人を誘ってみても、
「何で休みに勉強しないといけないの？」と言われたり。

どうせ多重派遣やってんだろ

都市銀行の勘定系なんて設計書とかまだ手書き時代のが残ってるよｗ
OCRじゃ読み取れないのばっかだし、PDF化をしてもスキャナの解像度が荒くて読めなくなってるｗ

日本の銀行って与信能力ないでしょ、んでバブル崩壊の時に貸し渋りやったから
優良企業ほど銀行から金を借りない。そこで何で儲けてるかというと
円キャリーと、決済手数料なんだよ。今はメガバンの稼ぎ頭は決済手数料

システム開発者のことを底辺のゴミ扱いしてるくせに、実際は、システム開発が作ったプログラムを動かして
儲けてるだけなんだよ。

>>823
とりあえず、秋葉原で売ってる。

>>864
知ったか乙

>>863
金融系じゃないけど、青焼きの設計書を見たことがあるな。
(青焼きって言葉って通じるんだろうか？)

メガバンクの勘定系システムは全部自前設計だよ。専用のデータセンターもある。
一回入ったことあるけど２重３重の入室チェックしていたり
監視カメラだらけだったりで結構緊張した思い出がある。

バッチ処理は関係ない気がするよ。
バッチ処理はやり直しが効くからな

>>867
青焼きみたことあるよ。古くからコンピュータ化されたところはたぶんあるんじゃないかな
ＣＡＤ化される前の設計事務所にもよくあったけど

>>848
コーディング規約以前に、COBOLならCOBOLの構造化プログラミングが出来ないと
多分話にならないと思う。

そうじゃないレベルの人は、実行出来ないからルールに口を出すしかないんだｗ

廃棄のＭＴをばらして寄った勢いで女子社員をグルグル巻きにした事がある。

>>868
だよなぁ。
銀行だもん、そのぐらいのセキュリティと自前センターが無いとこなんて信用できんわ。
少なくとも都市銀行とかなら。

うちんとこの社はバッチ処理５人がやるとPCが激重になる。
一応注意表示されるが、時間内にやっておきたいもんな。

waiting for execution

>>867
建築だとまだ現役だから　>青焼き

多摩センターの警備システムは知っている限り最高

>>869
そうそう夜間バッチならオンライン止めた後
各バックアップとってからやるはず。

夜のうちにどうしようもなかったら
翌日そのままオンライン上げられるようになってる。

今回はデータを中途半端に壊したままあげちゃったんじゃないの？

>>858
ミドルウェアだけでは一貫性を担保できなくて、
結局アプリケーションの方で一貫性を意識することことが多いんじゃないかと。
・・というか全く意識せずにやった事が無い。

>>681
明日の朝、金融システム全体がどうにかなるかもしれない

その後、時代劇にあるような帯を引っ張るような事もやったよなw

そのＭＴがまさか赤い糸だとは、その時気付きもしなかったけどな。

>>867
青焼き懐かしいな
トナーのコピーをゼロックスするって言う人もいたな

>>863
某金融機関のコボルSEだけど、70年代の手書きの仕様書沢山あるよｗ

>>867
最近の現場は知らないけど建築図面じゃ普通に使ってるんじゃない？
じさまとかにはパンチテープでデバッグだとか自慢されるよ。
>>868
金属探知機とかあってよく引っかかってた。

>>866

事実を言ってるだけだよ、ググれば事実とわかることなのに
それをすることすらできない知的弱者の低学歴クズニート

>>883
いや、キャノビックスだろｗ

三井住友銀行を使っています。
ココは大丈夫？コードがスパゲッティ化してないですか？

まあ、しかし、福島みずほの事件は、どっちも使ってるだけの奴
上で偉そうにしていて、いざとらぶると何もできなくて即逃亡という
事件だな。

MTってエムテーってやぱり言う？

>>887
それ初めて聞いたｗ

>>878
途中で中途半端に復活したのも大きいと思う
影響範囲を確認せずに動かしたことで傷を広げた感じがある

>>890
えむてぃ　だな

>>890
エムテー
シーテー
コンピュータ
プリンタ

バグは休み明けに仕様に変わるだろう

CMT

>>878
＞翌日そのままオンライン上げられるようになってる。

なってねーよ、バカ。

規定時間以内にバッチ処理が終わらないと大騒ぎだよな
オペレータからプロパーSEに緊急連絡が入るｗ

>>872
MT・・・ﾃﾗﾅﾂｶｼｽ
エムテーって呼んでたなぁ。

銀行は現役かもシレンけど、
30台半ばの俺が触ったことある最後の世代かもしれん。

>>890
フランス語読みだとエムテー

>>876
「ゼロックスコピーは原理的にコピーではなくて模写みたいなもんだから、信用ならん」
だっけかｗ

>>879
なんか誤解してるような気がするが、アプリケーションで一貫性を意識するのは「当たり前」で、
さらにミドルウェアやファームウェアのレベルでも一貫性や順序関係を意識する必要がある、
って言う話だと思うんだけど。

>>888
コードがスパゲッティだろうが素麺だろうがラーメンんだろうが、
利用者にとっては何の関係もデメリットもメリットも無いんだから、そんなことを気にする必要は無いよ。

むしろ「スパゲッティを直せ」とか言い出すと、余計にトラブルを抱え込むんだから。

ＭＴってオープンリールの？　うちではえむてーって言ってるけど
他に呼び方あんの？

今ニュースでやってたよ。
みずほ頭取「特定口座（たぶん赤十字？）へ集中することが分かっていながら
充分な要領を確保していなかった事によるヒューマンエラーでした。」
だとさｗ

>>890

言う。

社名をだめぽ銀行に汁

>>884
入社当初、ワープロが普及していたにも関わらず、英数字とフローチャート記号入りの
テンプレート(定規の方ね)が備品として渡された事を思い出した。

当初は設計書を清書する為ものだったんだろうけど。

>>900
誤解してた。

どうもくさいな
宝くじとかで余った使途不明金を
ロンダリングしてたんじゃね？

そのためにはシステム落としちゃうのが手っ取り早いとかさ


こいつら汚いことしておっぞ、たぶん

やっぱり「エムティ」より「エムテー」って言う人の方が多いねｗ

>>901
オープンリール懐かしいな。
多分どこも使ってない

>>890
エムテー

機嫌が悪いときは、アルコールで拭いてやったり、
掃除したりｗ

>>901

オープンリールなんて今時ないでしょ。ＣＭＴでさえ使うとこ減ってるのに。
今は、メインフレームもＬＴＯを使うんでないかい。

>>905
IBMロゴが入った緑色のあれっしょw？

俺の周りには20代のコボラー沢山いるぞｗ
以外にもかわいい女の子多い

結局ここは富士通メインフレーム(MSP)で勘定系やってるの？

>>909
多分倉庫で眠ってるものは多いだろうね

>>864
素人の想像だが、ローンの利息と株式投資などの利益で収益を上げてると思うよ。

>>896
なってるよ。

ATMとか窓口端末優先で、どこでも結構思い切った運用やってる。

オープンリールって、テープの最初の部分を固定するんじゃなくて摩擦で噛ますだけなんだっけ？
しかし1600フィートのMT。なつかしす。(部署が違ったんで、実際には使ったことないけど)

>>908
やっぱ「てー」って読むよなぁ、この業界だと普通はｗ

誰かが大事なデータテープをイレーサーにかけたとか

無いな。

やっぱVOS3が最強だな。

>>912
おれのはFACOMロゴだｗ

>>916
銀行系は無理でしょ

>>918
この業界ではデズニーランドがデフォです

>>918

DBはデービーだよな

ＪＣＬ

>>916
振込積み残してオンライン上げられるとこって何処。ｗｗ

みずほダイレクトも明日の12時まで使えないようになっとる
このままズルズル延びないといいけどねー

このスレ、昭和から平成初期の匂いがします。

>>911
普段は使っていないけど、データ移行や過去のMTを読むために残っているところもあるかと。
特に、メインフレームの現役として運用するサイクルの長さから言うと。

Ｄに横線入れたりとか

>>748
COBOL/Sの方がCOBOLより長かったんだけど、VSASにプログラム外からアクセスしていたと記憶している。

マスタデータに反映させるのに時間が掛かったってことか
情報処理に出てきそうな問題ですね

>>917
確かキューイングして巻き付けるんだよね
先端がボロボロになって巻き込めなくなると先端カットして
BOTシール張りなおしてイニシャライズとかやってた

>>930
それある。
その癖のせいで、Nintendo DSで"D"が文字認識されなかったりw

IT業界もバブルくらいまでは結構楽しい業界だったのに。

>>926
バッチ
トランザクション
オンライン

この辺の違いが説明出来る？

>>929
そもそもオープンリールをリードする装置自体どこも作ってないだろ。
多分壊れても修理なんか出来ないだろうし

DPIの違うMTを先輩に渡して、しこたま怒られたことを思い出した。

このスレ運用の人多そうだな

>>936
金融の場合トランザクションって別の意味に捉えられちゃうこともあるから注意が必要だよね。

ハッピータワーみたいだな

>>936
いや、何処だって聞いてるんだけど。
知ったか君にさ。
答えられるんでしょ。ｗｗ

>>66
突っ込みが難しいボケだわｗ

>>939
最初はオペから始めましたｗ

トランザクションは処理とデータで意味違うから会話してても話が通じない時ある。

>>869
時間内にやらんと他に障害がでる。

富士通のオンラインってAIMでしょ？IBMのIMSもどきみたいなやつ
あれってWEBｱﾌﾟﾘからのミドルってなに使ってるの？IBMでいうMQみたいなのあるの？

>>937
検索したらあった。(WindowsやLinuxにも対応)
多分、昔のMTを移行するたに需要があるんだろうな。

>>946
でもバッチ処理が最優先だろ。
他に支障が出ても仕方ない

>>939
全部やってたよ。特にリカバリ時は
PG作ってJOB流してMTマウントさせて、マシン室に走って、MTセットして、コンソールにＯＫと入力してた。

>>936
OS屋の俺がDB屋になったつもりで答えてみる。

バッチ ... バッチ処理とほぼ同義。昼間溜めておいたマスタデータテーブルの更新処理を夜間に一括して処理する。
トランザクション ... 複数の更新・参照処理を機能的にまとめた単位。
オンライン ... バッチの対義語。逐次的にデータテーブルを更新する。

どや

>>942
どこかって言うのには答えられんけど、、
お前はバッチで、付け替えしてると思ってるだろ。

そんな金融システムは今時ねーぞ。

>>790
＞　結論：できるだけ中国には関わるな。

激しく同意ｗ
しかし上の人間は阿呆のようにオフショアだなんだと中国人を使いたがる。

俺オンラインとトランザクションの違い明確にわかんないけど

オンライントランザクションとしか言わないし

>>951
バッチ、夜間って・・・
トランザクション、エンター（リターン）オスだけでもトランザクション
オンライン、おｋ

CICS

みずほデフォルト銀行

どうせ明日もまた止まるよｗ

>>951
現場の人間から言わせるとバッチだけ正しい。

ＵＦＪのシステムは進んでたのに

DBならオンラインバッチ処理も可能だよ。VSAMは更新出来ないけどね。

>>952
オマエ、オン時間外の更新もリアルでやってると思ってんのか・・。
今回の件は、業前バッチのトラブルだってこと理解してる？

>>955
夜間のバッチが有名だからじゃね
でも、バッチ処理であってないの？

>>845
０Ｃ７ってデータ例外だったっけ？

ありえんでしょｗ

ヒューマンエラーが発生する余地があるシステムは糞、とか言っちゃったり。

オープンリールってメインフレーム用は空気で
ｼｭﾊﾟｰって自動的に先端を巻き込んで、スゲーとか思ったけど
UNIX用は手で巻きつけたりしてたな。

>>949
バッチが最優先なんんておかしいだろ。
エンドユーザーがトラブルと認識するATMとか窓口が最優先なのは、業界の常識だろ。

>>951
バッチ → マスターデータとは限らないと思う

>>966　壊れやすいから手巻きの方が安全

明日は営業時間内のオンライン業務は本番系でやって
障害のリカバリー処理は待機系で続けるのかな？
その場合本番系がダウンしたらもう終わりだ。

長引くと日本経済への影響がシャレにならんぞ…

マスタデータ、トランザクションデータって古い人間じゃないとわかんないよねｗ

>>950
JCLやOCL駆使して如何に動かずに処理するかとか工夫してたなぁ
管理者の特権で自分のジョブだけ優先度上げたりして

>>968
ふむふむ

>>959
実際は、夜間バッチはマスタ処理だけじゃなくて、オンＤＢも連携させてる。
２４時間は見掛けだけなんだよ。
だから、現在の金融システムでそれぞれを切り分けるのは大変難しい。

なんか大体このトラブルの原因はわかったって人ここにはいないのかね？

日付変わったからATM見てきたら？

>>963
見た瞬間書き込んだからだけど、まぁ夜間バッチってイメージあるからなんとも言えないけど
今は２４時間リアルタイム処理が動いてるから２４時間バッチ処理動いてるけどね
特に月次や、今、今このときだと年次処理が随時、企業から送られてくるとｗ

絶対に無理だけど２日ほど営業停止にして障害対応に集中させれば復旧は早いと思う

>>973
後輩がAIMと同レベルのJOBプライオリティーに設定した時は流石に焦った。

チラチの裏で申し訳ないけど…

自分は製造系なんだけど、コンピュータの性能が向上した分、
今まで夜間バッチで処理していたのを、日中に何回か処理したいという要望が出ている。

クライアントサーバー型システムだけど、「クライアントからの更新がない」という前提で
プログラムが作られているから、本来は保証できないんだけど、やらざるを得ない状況になってきた。

しかも、バッチ処理中もクライアント側の処理に関しては最小限にって…
排他ロックで止まるか、データの整合性が取れなくなるかのどっちかなのに。

>>976
>>1嫁。
多分、想定以上の件数になったのは被災地への募金か何か。

>>951
あってると思う。
けどリソースの専有という観点で解説出来る人が素敵ですｗ

@ASG,A DAME*PO.

>>965
どこかのスレに、多くの処理が発生した支店が旧第一勧銀系なら
気を利かせた行員さんが、リカバリーしてたんだろうけど、今回は
旧富士銀行系だったからダメだったとか
第一勧銀系は今までも同じシステムだったから、何となく動きが
わかってたって事かな

>>976
多分、オンラインシステムのバグ。
仮にそのシステムが富士通製なら確定

>>979
二次障害を招く可能性を考慮して、障害リカバリーが完全に終わるまで
営業を停止した方が安全だと思う。
振込処理を停止してもATMを稼働させたら当日のバッチしょりが発生するし。

>>772
>>804
おれは20年以上コボラー一本だ、十分食える、うちの会社はcob系しか
仕事とってこない、コボルで十分で、Ｆ系は設計能力が低い印象、
仕様書は作った人の頭の中、コーディングルールーもなし、メンテすると
情けない作りが多い。バッチ処理はな再実行できる用に設計すべきだがな
バックアップから手作業で戻して再実行と情けないね。

バッチから先に片付けないと業務上の整合性がとれなくなったりするからなぁ。
まあ、この辺りはシステムの作りにもよるんだが。

過去のDBをDATに吸い上げてあるんだけど
この前、暇だったので試しにリストアしてみようと思ったら読み取りエラー。
過去数年分のDAT全部バックアップ失敗してました。気付いているの俺だけ。


逃げたい

生産性の高いオープン系に移行すればいいのに

OSの責任じゃないだろ

>>962
お前の言うリアルってなんだよ。
バッチでは更新してないって言ってるんだよ。

汎用系といえば・・・
例のADABAS系DBの保守料値上げで
DB切り替えたとか絡みじゃないよね

新ＤＢ導入したけど、メインフレームはそのまんま
で処理速度が極端に悪くなるとか結構あるんだけど

新生銀行は、Cでプログラムして、RDBをサーバー保管した
システムにしたそうだけど、利点はなんなの？

>>985
勧銀のシステムは障害時に人海戦術のソロバンで対応することが前提だから。
>>989
業務締めが存在する以上はバッチが基点にならざる得ないよね。

>>989
途中で生成したデータが既にサブとかに渡ってるとね

被災地への募金って確かみずほ指定の大きいところはFNSじゃなかったか？
他にも沢山あるのかな？

みずほ破綻

>>990
今すぐ最新のバックを取ればある程度は免責されるだろ。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。