☆★☆ みづほシステム あぼーん ☆★☆

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
今回の原因はプログラムのバグと十分なテストが行われていなかったのが原因
障害の元になった個所は富士ソフトＡＢＣがコーディングとテストを実施。
特にテスト現場はいい加減だった、分厚いテスト結果報告書はいちいち
銀行員は見ないって感じでいい加減なテストを実行していた
テスターもサビ残で働かせていた上、逃げる担当社員多かったので
引継ぎが上手くいっていなかった。

以上、メーカー下請けとして扱き使われた富士ソフト担当社員の密告。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

おぉ新事実。
富士ソフトＡＢＣは、これまで一回も名前出てこなかった。
ホント？デマなら大変だよ。もうちょっと詳しくお願い。
例えば言語は何？ベンダーは？

それから、今はどんな状況？
明日間に合うの？

俺も某メーカに派遣されてサビ残でこき使われたのでとっくに逃げた
今も現場なら２ちゃんにカキコしている暇なんかない。

あすこたんも、今頃仮眠室で、明日の立ちあがりに怯えながら、
切なくオナーニしてるのかなぁ。

萌え〜。
http://www.fuji-ric.co.jp/saiyo/gyomu/eno.html

言語はＣＯＢＯＬかな？

↑エロサイト顔負けだね、
なんで、社員のＭＧＥＧ晒すのかね？
ＦＲＩＣはブス多い、
ＦＲＩＳとか子会社の方がまとも、
やっぱ行員が一番（制服で騙されてるかもしれないが）

>>157
情報システム第1開発部 江野明日子の一週間
サーバー起動・停止など日常オペレーションを行なう運用メニューのテストに終始
した一週間でした。 4月1日のみずほ統合に間に合うように急ピッチで開発を進めて
きましたので、このテストでバグを一掃すべく、入念な準備のもとで実施しました。
その結果、テストは無事終了。みずほ統合が落ち着いたら、長い休暇を取る予定で
す♪

【本件についてのお問い合わせ先】統合照会センター
旧第一勧業銀行・旧日本興業銀行と取引のお客さま フリーダイヤル　0120-324-789
旧富士銀行と取引のお客さま フリーダイヤル　0120-324-389
受付時間　いずれも午前9時〜午後9時 （土日・祝日も受付いたします）

>>157
消えてるぞ・・・

>>162 あーあー。2chらーがセクハラするからだよ…

>>163
奈歩たんと薫たんが新登場だよ！

みずほで新たに３万件の二重引き落とし、ＡＴＭ障害も
http://www.yomiuri.co.jp/00/20020408i212.htm
・プログラマ板
【もう】みずほ障害スレ＠マ板　その7【だめぽ】
http://pc.2ch.net/test/read.cgi/prog/1018267304/l50
・株板
【綱渡り】☆みずほHD(8305)26☆Part2【必死】
http://money.2ch.net/test/read.cgi/stock/1018231560/l50
・速報＋板
【経済】■みずほ銀行障害関連総合スレッド パート3
http://news.2ch.net/test/read.cgi/newsplus/1018267225/l50

お前らなにやってんだか。by糖蜜荒淫とIt代表(Ｄ○Ｓは除く)

こうなることは本番稼動以前にわかっていたんだろうに。
第２地銀クラスなら珍しくも無いトラブルだけど、都銀がねぇ…。

今日のＡＴＭ障害は時間帯からいってセンターカットがからんでるのかな？なんて妄想しちゃう。

＞１６７
そんなことないよう（｀ε´）

UFJは何回もテストで連休とか
止めてテストしてたけど
みずほは一切しなかったの？
UFJは完全に三和を基本に統合したから良かったのか。
三井住友も統合する際は恐いねえ。

>>163
あーあ、あすこたんのあすこ・・・

ﾊｧﾊｧ

経団連の今井敬会長は８日の記者会見で、みずほグループが大規模なシステムトラ
ブルを起こしたことについて「金融業は国民生活に密着している。トラブルは起こ
して欲しくなかった」と述べた上で「利用者が受けた損害は補償すべきだ」と、み
ずほに対し、損害賠償などの事後処理に誠実に対応するよう求めた。ただ、みずほ
経営陣の責任については「システムは発注者（銀行）と受注者（電機メーカー）の
共同作業だ。経営責任はないと思う」と述べた。

昔、俺のチョンボで起きたトラブルの悪夢を思い出すなぁ。
あのときは怒られた。ユーザーに。

http://www.fuji-ric.co.jp/saiyo/video/eno.wmv

みずほちゃんのいくじなし！
できないときは正直に「できない！」って言えばいいのよ。
ごめんなさいってあやまればみんなわかってくれる。
先月も朝礼で「引き返す勇気も必要」って校長先生が言っていたわ。

でも、もう引き返せないところまで来ちゃったんだね。
がんばってね、みずほちゃん。

>>173
速攻でデリられたと思うが･･･

内部SEからのチクリ希望。
見切り発車しました、ってチクッちゃえ。
週刊誌にもってきゃ結構このネタ高く売れるぞ。

二重引き落としってどうして起きたの？

ああいうのって、夜間バッチとかじゃないの？

>>177

一回だけだと心配だったからだろ

>>178
ﾜﾗﾀ

しかし、同じ情報系の企業に勤める営業としては
今回のトラブルのたいへんさ・・
想像できるようなできないような・・

そこらへんの小さなシステムでもトラブル起こると
対応にたいへんだもんねえ・・
ＳＥも徹夜続きで・・

>>180
氏ね。腐れ営業。SEもじゃねーだろ。もじゃ。
ばーか。

>>181

はあ？おまえらＳＥのしりぬぐいをする
営業のみにもなれや、
おまえが氏ね、ボケ。

>>182
営業の尻拭いは毎回なんだよ。うんこ。
口惜しかったら営業板へでも逝け、板の名称もよめねーのか？
この文盲

>>183
キミ、ＳＥ？？
だとしたら担当する営業もたいへんだろうねえ・・
おまえの造るいいかげんなものの尻拭いで。

まさかＳＥじゃないと思うけど・・
まあ、うんこって今時、幼稚園生でも恥かしくて
言えない幼稚語を平気で書く奴がつくる
システムがどんなか、はたからみればおもしろいだろうね（笑

>>184
うるせー
このちんこ、まんこ、うんこ、しっこ。
ばーか、ばーか、ばーか、ばーか、

>>185
荒らし相手にしない方がいいと思う。

どちらが荒し？

>>187
胸に手を当てて考えれば分かるよ。
＞：　非決定性名無しさん 　　

技術者と営業の間に信頼関係のないＦみたいなとこは×ってことだろ

二重引き落としはソフトのバグなの？
業務課の指示チョンかオペチョンでしょ。

無能なシステム部門のPGMバグとオペチョンと
派遣費用だけは超一流でスキルはユーザー側SEにも劣るベンダーのＳＥと
金儲けで品質そっちのけのベンダー営業が三位一体となった
トラブルなんでしょうね、きっと

システム部門は別として、SEと営業は一体にならんでしょ(藁
>>180-185がいい例じゃん

犯人は誰かな
メインフレーマ同士のぱわふりゃ〜な泥仕合が楽しみ

↓山椒
http://mentai.2ch.net/test/read.cgi/infosys/977231011/l50

主導権争いの第一フェーズ。
俺んとこ優秀。俺んとこなんでも出来る。俺んとこ納期短い。
これはこっちの担当だ。

主導権争いの第２フェーズ。
そちらさんで出来るだろ、フォーマットこれにしてくれ、
そっちが出来ないとこっちが出来ない。それはこっちの担当じゃない。

主導権争いの第３フェーズ。
そもそも、そっちの担当だ。

>>192
ばらばらにやってるから不実みたいになるんだろ
一体になって考えなきゃいいものはできん

大規模なシステム統合をうまくやれないってんじゃあ、
日本の企業再編もうだめぽ

>>196
実質２ヶ月そこそこの割には、
良くやったと思うよ。
まったく、ここの経営陣は何も決断できない。
企業結合の問題でなく、重役が耄碌しているだけ。

新たに処理もれ判明　引き落とし遅れは約４０万件に （04/11）
http://www.asahi.com/business/mizuho/K2002041102696.html

うはー。いよいよ泥沼だな

>>189
信頼関係が有ると思っている馬鹿はっけん。
信頼できるわけねーだろ。

>>200
まあ、おまえみたいなのだらけだと
進展もしないわなあ・・
いろんな意味で（ｗ

>>201
馬鹿発見ーん。その言葉そのまんま返すよ。
バーか｡

>>200 >>202 は不実関係者と見た。

連休前にみんな一斉に金を下ろすんだろうけど、そん時に祭りにならんかなあ。
そう言えば15日って公務員の給料日じゃないか？

今日課長が○○銀行情報システムって所からの電話に
「そんな無理いって、みずほさんのようになりたいんですか？」
などと話してたのにはわらった。
＃思いっきり実話

何人氏にましたか？
何人頃されましたか？
これから何人逝くんですか？

日立らしいね。
やっちゃったね。

>>207
不具合が起こったのは銀行側の金融ＳＥが中心に開発したアプリケーション（業務用）ソフト。メーカーの手を借りなくても復旧は可能と考えたのだろうか。


http://it.nikkei.co.jp/it/foc/index.cfm?i=20020409t1000t1

>>208
リレーコンピュータもＦだったんだね。
しかしなぜＨしかよばれてないんだろう？　ＵＦＪの経験を買われてるのか？

情報システムが統合されれば、不要になった機器は当然のこと
人間も解雇しなくてはいけない。銀行は社内の情報システム要員を
残すために、システム統合に積極的に関与させたが、最新技術にうとく
また恐ろしく無能だった。（ATMが停止したら、または口座振替ができなく
なったらどうなるか理解できないほどだ。）

今後、富士通には怖ろしくて案件お願いできないって企業が
続々出てくるだろうな。
ノンストップサービスとか金融業務とかそうゆうところあたり
から特に。大変だな…。

>>209
Ｆはかき回すだけで問題を解決できる能力が無いから
業界の常識

結局悪いのはDKBの子会社ですか？

>>213
悪いのはみずほ。
あほは使ってナンボの世界。

なんかＭＴのハンドリングミスが大きな要因のひとつらしいな。

雪印食品よりヒドイと思うのだが、銀行はつぶれんのか？？？？

>>216
逝き印は買わなければいいだけだけど、都銀はな…

口振データ来んぞーーーーーーー！
スケジュール表ーーーーーー！

資金とか為替とか貸付とか先物とかは、障害出てないの？

不治通の方は、何してるんでしょうか？

>>220
問題が起ってから緊急に100名程度の技術者を待機させているとのこと。 > 立派
だけど、みずほから依頼が来ないので動けません。

そろそろ、大臣命令が出る頃か？
って言うか、みずほの責任者は全て首が飛ぶな。（もうアホかと）

>>221
不治通の方ですか？
彼は技術者ではないのに
営業というだけで、音信普通なんですけど
どういう事なんでしょうか？

>>222
音信普通　→　ｼｮｰｸ?
ﾏｼﾞなら、いつから音信不通なんですか？

>>222
君が何を言ってるのか理解出来ないが、Ｆの技術者の中でのトップクラスは日本を代表する
技術者であることは業界の常識です。

最近一番面白いのがこのみずほの事件です。
もっと泥沼になってもっと楽しませて欲しい。

>>224
３月中旬からです。

>>226
訂正
>>223
３月中旬からです。

>>224
彼は技術屋ではなく、ただの営業なのに
今回の事に巻き込まれているようなのです。

>>224はもう少し業界のことを理解したほうがいい。

>>228
ごめん、>>224じゃなくて>>227だ。ｽﾏｿ

>>229
私は全く違う業界なんだけど。
だから教えてくれって言ってるのにさぁ。
一般人が、金融新聞なんか取らないでしょう？

＝＝＝＝＝嵐警報発令中＝＝＝＝＝　　　　

>>231
え？私のことかしら？

単純なミスのはずなのに発表がないねえ。

難しいトラブルのほうが報告書作るのが楽だけどね。
ただ、分かり易くしないといけないのが少し時間がかかるかな。

簡単なトラブルほど報告書の内容に悩む。

ニュース板でやれ

下記板との間をＲＣで繋ぎましょ。

http://news.2ch.net/test/read.cgi/newsplus/1018751384/l50

みずほで引き落としやってなくてよかった。

>>221
＞問題が起ってから緊急に100名程度の技術者を待機させているとのこと。
＞だけど、みずほから依頼が来ないので動けません。

そーなの？っていうかＦもＩも、
「ほれ見たことか！ウチんとこの勘定系は大丈夫なんだから知らんＹＯ！」
ってところがホンネなのかと思ってた。
みずほも「いまさらアタマ下げられん。。」ってことなのかと。

3行それぞれ出身の役員だか顧問だかが辞任とかって
今朝のニュースでやってたけど、ネットでソースが
見つかんね。

なんでも「3行の主導権争いが原因だったと認めている」
ってことだったが・・・。

>>238
実態は、みずほのシステム子会社が自力でやろうと無理に無理を重ねていたらしい。
ソース：
http://www.weeklypost.com/jp/020426jp/news/news_3.html
「そればかりではない。大銀行のオンラインシステムは各行とも数百億円という
費用をかけて開発しており、膨大な取引情報を扱うため機密性も極めて高い。
いざシステム統合作業に入ると、取引先の大手コンピュータ会社は応援のための
ＳＥ部隊を編成して待機させたものの、みずほ各行の技術部門は機密保持を理由
にギリギリまで頼もうとはせず、作業はさらに遅れていった。」

システムの戻しが発生する模様。

>>240
振込の遅れは企業から渡されたデータに問題があったという報道。
（それだけが原因かどうかは分からないですけれど）
結局生データを触らせなかったのだと思うが、それは機密保持の原則を貫いただけだろう。
（その処置全てが妥当かどうかはさておきね）
数百億とか取扱量が多いとかは無関係。データとシステムの違いがわかって欲しいね＜この記事
とは言うものの、この記事のポイントである現場の意見を無視してＧＯを出した銀行首脳部に問題ありとする意見は概ね賛成。

本当に、雪印Ｇｒ潰れても、
銀行は残りますね。

過労死はいませんか？

今、みづほのPGを募集してますが、
いったら死んじゃうでしょう。

2年半で2000億つぎ込んでこのざまｶﾖ。
あと「興銀ｼｽﾃむさえなけりゃ」とか言ってたよ。

週間ポストによると一巻と不痔痛がわがまま言い出したことが事の発端らしいよ。
不痔痛がすべて不痔痛にしようと画策したから訳のわからん複雑怪奇システムに
なって手におえなくなったらしいね。

不治痛、必死だな。

もう辞めようかな。疲労が限界だよ。

>247
第一勧銀のシステム開発部門じゃないの？

不治痛は他メーカと歩み寄ろうとしない
いつもそうです。

ＦＦＣの人どう？

東京三菱 IBM
三井住友 NEC
UFJ 日立
なので富士通はかなり必至だったと新聞に書いてあった。
あとみずほのシステム子会社が機密保護を優先したためにぎりぎりまで
メーカーにヘルプを求めなかったらしい。

ガイシュツだった鬱打

>>253
それじゃ、政治的な都合で富士通ってことかな
でも、システムの開発会社が泥沼にはまったような状態でも助けを呼ばないで
事態が深刻化したなら富士通って悪くないのかあ。日立がどうのっていってた
記事もあったけどほんとのとこどうなんだろう

それにしても今までのマスコミ報道とかいろいろ見聞きしていると、トラブルがあると
コンピュータ本体を納めたところが原因って言っている様に聞こえてくるけど、
企業の基幹システムとかよばれるシステムを持っているとこってよっぽど自分たちの
手におえないとき以外は自分のとこで開発ってのが普通じゃないのかなあ。
うちの会社の基幹システムもシステム部の連中が作ってた。業務開始時は
トラブリまくって結局メーカーに協力してもらって何とかうごいたけど。

パソコンとかは買ってきたのをそのまま使うのが多いからなにかあると
作ったとこが悪いって言うのは分かるけど、マスコミとかヤフーに書きまくっている
人たちってパソコンと同じに考えてるんじゃないのかなあ

本当にこの期に及んでもベンダーSEはお呼びがかかってないらしいよ。
大抵は、社長命令で赤紙が回ってくるはずなのだが。

>255
禿胴

銀行システムは特殊な世界。やっぱ行員あぼーんでしょ。

【選挙活動】
２ちゃんねる全板人気トーナメント。。。
今日の投票は、（株式板）を応援よろしくお願いします（↓投票所）
http://live.2ch.net/test/read.cgi/vote/1019147047/l50

フラッシュ板に作ってもらった選挙応援フラッシュです。ぜひご覧ください
http://www.monakura.com/mizuho.html （みずふぉ統合変）
http://members.tripod.co.jp/UTPFlashRIQ/kabu.html

>>255
マスコミには基幹システムは存在しないんだろうね。

あったとしても開発は役所と同じでベンダーに丸投げじゃない

みずほを立ち入り検査　金融庁が５月上旬に実施
http://www.asahi.com/business/update/0419/011.html

って、立ち入って何するんだろう？
金融町がシステム見てわかるの？

http://kabu.zakzak.co.jp/kinyu/kiji/kinyu0419.html
日立製の『ＳＴＥＰＳ』に殆どの責任？？

>>262
記事が間違ってるヨ
STEPSは一勧の勘定系のことだヨ

>>262
日立『ＳＴＥＰＳ』の製という名目にして
STEPSの設定・プログラムによる不具合ではなくて
”商品の潜在的バグ”として無難に過ごそうとしている

一巻のシステム部長（今は、役員か？）は、ホントのDQNヤロウ
派手なシャツ着て、システム何も和姦ね奴。
でも、強引に不治痛を主張し、エラくなった。不治痛から金でももらって
あのシャツ、買ってたんだろよ。

遠因としては、年配の職人ＳＥをリストラしていって、
頭はいいけどシステム全体や修羅場をくぐってない
若いのですすめてたんじゃないのかな？
４０〜５０代の銀行のシステム部ＳＥって、そりゃ
職人そのもので、あんなずさんな移行をやらないんじゃ
ないのかな？

そいや、既出かもしれないけど、うちでの被害。

引き去り不能はさることながら、
旧第一間吟で廃止された統一店番コードが復活していた。
しかも、まったく別の旧不治の支店のコードとして。

おかげで、銀行コードの履歴照会画面など、余計なアプリの改修の手間が
発生(;_;)　まだ一部テスト中だけど。

いつか殺す。＞＞みずほ

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　ゴールデンウィーク休みないらしいよ。
＼
　 ￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　 ∧＿∧　　　　　 ∧ ∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　´∀｀）∬　∬ (ﾟДﾟ,,)　　＜　さすが糞不治痛！
　（__　　 ⊃目　目⊂　　|　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　 し＿＿）┳━┳ (＿_ っ

>>262
株屋の記事に信憑性はないと思われ。
「STEPS」は一巻の勘定系（富士通製）システムの名前。
日立製ホスト（ソフトは一巻）を使っているのは振替データを
「STEPS」用のフォーマットに起こす部分だけだったと思う。

システム屋云々の前にきちんとした合意を成し遂げられなかった３行に
責任あり、に見えるね。
もちろん、そうだが、３行が合併するというリスクフルな状況を監督し
きれなかった金融監督庁の責任は少なくないんじゃなかろか。
少なくとも、これから合併するってときには、誰も責任を負わない空白
の時間ができるわけだし、それを看過したってのはどういうこと？

みずほ、システム試験を拒否
ttp://headlines.yahoo.co.jp/hl?a=20020420-00000001-yom-bus_all

>みずほ側は「内部で試験を繰り返しており、必要はない」と説明したという。


内部の試験って一体何をやっていたんだろう？

http://muvc.net/deedrich/erocite/erocite_japan.html

どうぞ！！！

今回の件は、関係無いシステム屋さんにとってはうれしいのでは？
システムテストの難しさを顧客に説明しやすくなるし。

いつかきっと、プロジェクトＸで紹介されるでしょう・・・

>>273
それはあるね。
頭の固い顧客達を説得しやすくなったよ。
というか、向こうから「改善しよう」って話が出てくるようになったよ。
よかったよかった。

要するに国の政策みたいに行き当たりばったりじゃダメってことで

>>275
よかねーよ。
ＳＴをやたら長くするためだけに、
はじめっからＵＩとかＰＧが削られそうな雰囲気。鬱だ。

>>267　の話は既出だったかな。
関連スレ。経済板の↓から一部分コピペ。
http://money.2ch.net/test/read.cgi/eco/1018045525/200
>200 ：金持ち名無しさん、貧乏名無しさん ：02/04/14 09:56
>ただ今、マー版にて一部「みずほ」混乱理由が解明中。くわしくはマー版みずほ統一スレで。
>835 名前：829 ：02/04/14 09:34
>貼ったよー。
>
http://www.geocities.co.jp/Technopolis-Mars/9857/index.html
>
>こいつは旧支店番号が同じで旧銀行番号がちがうもの、
>っていう条件で出したもので、特別問題とかトラブルの原因にはならない。
>旧銀行番号+旧支店番号と新銀行番号+新支店番号のマッピングがちゃんとうごいてる
>ことが前提だが。

みずほでトラブってる口座の支店一覧って公開してないのか。
意外と、上に有る支店に集中してたりして。
>>267にも、できたら被害詳細希望。

>>278
あまり詳しく書くとばれるんで、概要だけ。

うちの会社には「金融機関照会」って銀行コードと金融機関名の相互検索
画面があるんだけど（ってどこもあるとおもうけど）
そいつのマスターロードでJOBがずっこけたのが発端。
調べてみると「廃止店鋪に新規データがあります」てなエラー。

旧第一勧銀の廃止店鋪が復活している・・・・って大騒ぎになった。

調べてみると結構な数のの旧不治銀行の支店が旧題意血勧銀のコードで
追加になっていた。

例をあげると（あくまでも例だよ）

2001/07　に銀行コードで　0001-001 ２ちゃんねる支店が廃止
このとき不治の銀行コードで 0003-001で１TV支店が存在したとする。
2002/04の統合で、0001-001で１TV支店が追加される

てな案配。

とりあえず、だぶっている支店コードをオンコーディングで指定し日付指定
を強制させる機能を急きょ追加。ちょっと使い勝手は悪いが、しょうがない。

まぁ、統一店番号は銀行任意なので、なにやられても文句は言えないのだが
それにしても１年以内に廃止になったコードをつかわなくても
いいと思うんだけど。

あと、今想定しているのが、口座振替依頼書に金融機関コードしか
書かなかったばあい、こちらで銀行名と支店名を補記しているんだけど、
ダブり銀行コードを使ってきた場合、はたしてどっちなんだか全くわか
んなくなる。

旧銀行コードに不治のコードを書いてくればまだいいけど、知ったかぶりした
客が銀行コードを題意血勧銀にしてきた場合と、支店の統廃合をしらないで
旧い銀行コードを書いてきた場合、まったくみわけがつかない。
そーゆー奴に限って銀行からのおしらせはまったくみていないので
廃止の事実は知らなかったりする。

銀行名と支店名ぐらい書くでしょうと思われるかも知れないが、キャッシュカード
だけ見て書くやつもいるので油断はできない。

そのばあい、銀行側で顧客無しで引っ掛かるんだけどそのたびに営業に、客に
でんわさせるのもなぁ。

そんなこんなで鬱な日々を過ごし中。

あまりたいした被害報告でなくてスマソ。でも精神的ダメージは
大きかったの。

>>278

やっとこさ
ttp://www.geocities.co.jp/Technopolis-Mars/9857/index.html
みました。
これも、場合によっては対応が必要かも。（気がついていたんだが
こんなにあるとはおもわなんだ）

あした上司に報告しヨット

>>277
もう少し社会勉強と修行が必要。
君が使用してる言葉は会社固有の言葉だ。

277の言いまわしは不治痛系だっけか？

http://www.asahi.com/column/funabashi/ja/
＊系列取引先のコンピューター機種を導入するという決定が先行し、この
システムはそもそも何のために、誰のためにあるのか、統合メリットをど
う生かすのか、という目標と設計思想を明確にしないまま、走り出してし
まった。（戦略の不在）

統合システムとして不痔痛を選択するってのは誰が見ても異常ってことだね。

敢えて みずほ銀SEを弁護する(1)

今回の事件でみずほ銀行の拙さを指摘する声ばかり聞こえてくる。
準備期間を主導権争いに空費した点は拙いという他はない。
ただ、現場のSEに罪はない。彼らは徹夜の連続で合併準備を続け
て来た筈だ。同業者だから、そのシンドサは良く理解出来る。

洩れの場合は、ニ行だったから、その度合いは相対的には軽かっ
たが、それでも神経がささくれ立ったような毎日だった。
あれが三行でそれをリテールとコーポーレートのニ分割すると言
うのは恐らく飛行中のジャンボジェット三機から乗客を別の二機
に乗り移させる様なものだと思う。それをタルンドルとは塩爺も
耄碌してるし、マスコミもやり過ぎだ。

米銀はあの程度のトラブルは日常茶飯事で大して報道する事はな
い。95年だったかケミカル銀のオンラインストップが一週間近く
続いて漸く記事になった位だ。
911でBONYのバックアップセンターが二週間近く稼動しなかった
時の扱いも小さかった。日本のマスコミは銀行をスケープゴーツ
に選んでいるのだから、必要以上に大きく叩かれたというのが真
相だし、それもまた日本のマスゴミの拙い処と思う。

失敗したから叩かれるが、合併を四月一日にするのは、決算日を
考えればある意味当然の事だと思う。嘘だと思うのだったら、過
去の合併例を調べて見れば良い。四月一日が圧倒的に多い。
対外的に公表した合併日をずらすのは銀行関係者なら、そうそう
出来なかった事も容易に想像できる。
ただ、敢えて言わせて貰えれば、現場はストップをトップに出す
べきだったし、トップは謙虚に現場の声を聞くべきだったと思う。
そうは言っても、洩れの銀行でも出来なかったろうというのが本
音だが....。

システム的に考えてもニ行合併だとオンライン接続はRCは一台で
済む処が三台になってしまっている。複雑さはニ行合併に比べて
三倍の負荷になる。というか三乗倍で八倍難しいと言っても良い
かも知れない。ロードバランシングだって結構難しい。また、テ
スト環境を作成する負荷だって馬鹿にならない。その割には実質
一年の準備でシステム部員やメーカーSE達は良くやったと言える。

それでもオンライン関係はまだマシだ。キャパシティーを増やせ
ばカタが付く部分も大きい。四月一日のデータがあるから、どの
CPUがネックになったか、もう完全に判明している筈だし、ロジ
ックの修正も中味が分かっているだけに比較的容易だ。もう修正
してるだろうし、CPUグレードアップ済ませているかも知れない。
まだだとしても遅くとも月末のGWにはやると想像する。

敢えて みずほ銀SEを弁護する(2)

それに比べて口座振替関係の処理は根が深い。報道を見てると興
銀が開発に音を上げてDKB側で振り分け部分を開発開始してから
半年の様だが、それでは事実上、テストも碌に出来なかったろう
と思う。

どの銀行でも口座振替のフロント部分は三次オンの積み残しにな
っていたから古いシステムが今でも稼動している処は多い。第一
と勧銀の合併ロジックが残ってたという事からそれが分かる。
システム部門でも花形ではないから人は抜かれる一方で、安定稼
動してるから要員も減少していたのではないかな。UFJが、同じ
部分でトラブッた理由も似たようなものだろう。
洩れの場合は幸いに97年に三次オン水準に書きなおしていたから
合併時も問題が無く助かった。

また、全銀フォーマットを使っているとは言っても営業のゴリ押
しで顧客別にシステム対応している部分も多いし、三行によって
その対応をしていたりしていなかったりするから一番トラブル原
因に成り易い部分とは容易に想像できる。お客を巻き込んだテス
トをしたかったというのが現場のSEの本音だろう。
一番時間が掛かる部分に時間が割けなかった処が今回の一番の敗
因。修正するにも時間が掛かると想像する。

多分、もうやってるだろうけど、退職した口座振替システムの経
験者に頭下げて来て貰って助言を仰ぐ、または修正を手伝って貰
うのが一番の早道だろう。

まだまだ、合併対応の泥濘は続くだろうが、同業者としてせめて
エールを送らせて貰う。頑張ってくれ。

マ板が活気づいているのは、やはりＳＥはただの下僕だったてこと？

第一勧銀のシステムが古い、富士銀の方が新しいとよく出てくるが未だに疑問。
具体的にどこが古くてどこが新しいんだろう。新聞にはこっちは古いあっちは新しい
等出てくるが具体的に書いているのをまだ見たことが無い。
何が違うんだ〜〜〜〜〜〜

>>287
三次オンを同じ時期にやったという事では、DKBも富士も同じようなもの。
富士の方がやや時期は早いが、TOPSは銀行としてはかなり先進的な思想を
盛り込んだユニークさがあった。DKBのものは比較的標準的と言える。
新しさは無いが当時日本最大の銀行用だから処理速度に留意した設計と言
えるのではないかな。

283-4で書いたけど、口座振替用のシステムのフロントエンドはどの銀行
も勘定系とは切り離した設計。バックエンドの口座引き落としの部分は勘
定系に組み込んでいるけど、データの受けの、引き落とし明細データの渡
しの部分は古いままになっていた。
この部分を富士は三次オンの時に書きなおしていた可能性はある。
ただ、そうであっても、現状の処理は、DKBで受けたデータを三行に分割
して各々のシステムに引き渡して、処理結果をまたマージして顧客に返す
という設計だから、顧客とのテスト充分にやっていないとエラーが発見し
にくいと言えるでしょう。

訂正
×データの受けの
○データの受けと

>>287
不冶銀のシステムは一つの口座でいろんな金融商品が扱えるようになってるんだよ。
一巻銀のシステムは昔ながらの金融商品しか扱えない。拡張性もない。

>>290
富士はIBMの階層構造DBであるIMSを使っている。
でもDKBも富士通の階層構造DBを使っているので
(名前は忘れたけど)、そういう意味でのテクノロ
ジーレベルは同じ。何階層持てるかセグメント単
位のオカーレンスの数の制限はどの程度あるかで
違いはあるけど、業務システムに影響するレベル
の違いは少ない。

また、一つの口座で複数商品が持てるというの
も、普通預金口座番号をCIFのルートに使って、
商品種類を枝番で使うか別番号を使うか程度の
違いでしかない。

だから、その違いで拡張性はないというのは当
たらないと思うよ。
実際、拡張性云々よりも実務的には、業務シス
テムを作る上でのドキュメンテーションとか、
DBの正規化やフィールドのネーミングルールと
かの開発ルールがどの程度キチンと管理されて
いるかで、システムライフや新規商品開発負荷
が変わってくる。
両行でそれがどのレベルにあるかは、残念なが
ら内部の人間でないので判らないが表面的な機
能の違いでシステムが良い悪いと判断できない
部分であると思う。

何行かＡＴＭを使っていて思ったこと。
ＤＫＢはある時期から突然ＡＴＭを使っての処理が早くなった。

>>292
それはATM側の問題。
例えば出金ならそれまではホストの処理結果が返ってきてから
出金するお金を用意して出してた。
それを出金するお金の準備に入ってからホストに問い合わせるようにした。
正常ならそのまますぐ出てくる。エラーの時はお金を戻す。
不冶痛が自慢しとった。

>>292
一時期(４〜５年前)当時の三和銀行が仕掛けたATMのスピー
ドアップ競争の結果、銀行のシステムではなくATM単体の性
能がアップした結果だと思います。

結局、あまりに速度を早くしすぎた結果、老人だと手を挟んだ
りする位に、各パーツのスピードがアップした、つまりこれ以
上早くすると逆に事故に繋がるという限界に達した為、今の新
型ATMのスピードに落ち着きました。

ただ、銀行のATM三千台を一気に変更する訳ではないので、支店
のATMの中でも早いものと遅いものが混在している事があります。
更改の場合は基本的には、支店にあるもの全てを入れ替えますが、
業量が増えて追加ATMが必要な時に、支店内で混在する様なケース
ですね。

>>291
IMSとAIMじゃ同じ階層構造DBでも能力が比較にならんがや。
ハードの能力だってＩとＦじゃかなり違ってるやろ。
それ以前にＤＫＢのシステムがだめっていってるのはアプリケーションの構造が
古臭くって今の金融商品に対応するのに時間と手間がかかるってことらしいよ。

>>295
実際問題として何をどう比較して階層構造DBの能力を比べて
いるのか良く分からないし、業務アプリで階層構造DBの能力
限界まで使った例は聞いた事がない。IMSのFast Access path
の事言っているのなら3.0以前のIMSの当初のパフォーマンス
は酷かったよ。

また、ハードの能力でIBMと富士通に極端な能力の相違が当時
あったとは思えない(一方は当時日本最大の銀行だよ)し、
パフォーマンスに大きな違いがあったとは思えないし聞いた
事もない。そういう点で貴見には同意できない。

アプリの構造という言葉も上手く定義して貰えないと比較で
きないよ。富士銀のどういう処がアプリケーション構造的に
新しくて、DKBのどういう処が古臭いのか具体的に指摘して
貰えないと洩れには理解できない。

両方共、階層構造DB使ってるし、DBの２フェーズコミットを
確保するミドルウェア使ってるだろうから、基本構造に違い
はない。洩れの知ってる範囲では富士の営業店システムは良
く出来てたと思うけどね。実際的な違いには至らなかったと
理解している。

ワシの知ってる範囲では、簡単に言うと・・・
一巻のセンターカット系は、元帳更新系でありながら、
まさにバッチ処理。従って、構造上、24/365に適応できない。
というか、STEPSの根本思想として、24/365対応の
アプリケーション構造という概念がなかった（DB/DCのトラン制御を含めて）

不治は、よく判らんが、大惨事オンの構想時に、既に
根本思想として24/365を志向するアプリケーション構造の構築を目指していた
（らしい）

そういう点から見ても、一巻のシステム（ここでのシステムは
ハード面というより、むしろアプリね）には、行く先の
限界があるんじゃないか？

>>295
漏れは三次オン(DKB)参加者だが、確かに設計は恐ろしくレトロだったぞ。
各タスクのメイン（０レベル）と業務メイン（１，２レベル）をアセンブラで、業務ロジック
（３〜７レベル）、業務共通ルーチン（８，９レベル）、システム共通ルーチン（９９レベル）を
COBOLとアセンブラで書くのだが、呼び出し構造が固定でそれだけしかない。だから
設計を失敗すると恐ろしく長いモジュールができる。漏れが書いた中では１モジュールの
くせに１２KステップもあるのがあったYO！さらにメモリ節約のために〇レベルで取った
各レベル専用のグローバル領域を使いまわすんだ！COBOLでもLINKAGE内で（たとえ
ループカウンタであってもｗ）間に合わせるんだよ！ローカル変数がないからデバッグの
ほとんどは「この値はどこではいったんだろ．．．」という低レベルさだったYO!

>>298
で、上位レベルのモジュールしか呼び出せない規則のため
（まあ、これはこれは仕方ないけど）、訳の分からないところで
苦労する訳さ

>297
ということはＩが進んでいるＦが古臭いというより
アプリを開発したＤＫＳＤがわるいんじゃん

どちらにしても一昨日だか何だかの新聞に全面的に作り直すとか何とか
書いてあったな。その時はどんな感じになるのかね？
少なくとも汎用機でやる事は無いんだろうなぁ
やっぱ、時代遅れだもんねー？

AIM電文共通領域のどっか（だったかな）の名前がXXXXXXXXだったのには
笑った。（伏せ字じゃなくて大真面目でこの名前だぜえ？）

>>301
もちUnixだろう！

＞ローカル変数がないからデバッグの
＞ほとんどは「この値はどこではいったんだろ．．．」という低レベルさだったYO!
昔のFORTRAN(再帰呼び出し不可能)みたいなマシン・コードっすね。
やっぱ速度＆シンプル至上主義のたまものですか？

>>304
その通り。っつーかS/360の昔からスタックの考え方が無かったから当然だな。
Push-popの仕掛けじゃなかった（リンケージ規約がね）レジスタ１つ（R10か？適役は)
スタックポインタにすればよかったんだろうけど。３次オンのときはまだ31ビットアドレス
への移行途中だったんでそーもいかなかったんだろ。（昔は汎用機もメモリ空間16MB
だったんだぜぇ）

あ、ついでに言えば各レベルの使えるエリアは１ページ(4096Byte)だったかな。
ベースレジスタの届く範囲だったとうろ覚え。レベルによって違ったかもしれない。

ヤフーは、どこをどうとっても最悪。

ビッダーズが一番！！！↓
http://www.bidders.co.jp/bpu/1072049

皆、左上の会員登録をクリックして、
入会しよう。

よぉやく盛り上がってきたな。
しかし、内容がマ板的？

>>305
＞３次オンのときはまだ31ビットアドレスへの移行途中だった
って、DKBって３次オンいつ作ったの？
ＩとＨは31ビットアドレスって１９８４年か５年には出来てたと思ったけど。
不冶痛ＯＳだけ遅かったのかな？

>>302
これ見て思い出したが、昔不治痛にＡＩＤＳ−Ｘていうシステムソフトがあった。
どんな機能のやつかは忘れた。
ちょうど病気が流行り出した頃だったんで、マニュアル一覧で見つけたときは
大いにわらった。もしかしてこれ？
ＯＳはＯＳＩＶ/M４-MSPていうんだな。

>>310
あっ　ほんとにＸＸＸＸＸＸＸだったのね・・・読み間違えでした。

IBMの人ってどうして会社から書き込んでも平気なの？
なんで仕事しながら２ちゃん見られるんだYO！

>>309
Fだってそのころにはできてた。けど顧客のアプリがそれを使うかは別の話。
いまでもVC5やらひどいとこではWin3.1のシステムを改造、って案件あったり。

>>310
AIDS/XはVTAM用の制御補助システムだったような....そいやデバッガ（っつても
ワトソン君ほどのもんだが）にはAbendAID(S?)があったなぁ。

>>308
やっぱこーゆーのはマ板いかんとだめかねぇ。むこういま厨房多いからなぁ。

ＡＩＭってのは名前からしてＩＭＳより進んでいるという
（実態は変わらないんだろうけど）随分、挑戦的なＤＢ／ＤＣ
だったな。
ＩとＦじゃＳＰＡの使い方が違ってたみたい。Ｆはトランコード
で起動ってのがなかったような。

>>298
DKBじゃなかったけど、最下位の業務ロジックまでアセンブラだったよ。
エリアは上から渡すのが普通じゃないの。下でGETMAINされるというのは
ちょっと不安。レトロな場合、ソースから仕様書を起こして組み直すのじゃ
ないの。動いているのがソースと違うと大変だよね。

>ＡＩＭってのは名前からしてＩＭＳより進んでいるという
>（実態は変わらないんだろうけど）随分、挑戦的なＤＢ／ＤＣ
>だったな。
>ＩとＦじゃＳＰＡの使い方が違ってたみたい。Ｆはトランコード
>で起動ってのがなかったような。

横レス、しかも厨房レスでスマソだけど、ＤＢ／ＤＣのＤＣって何？
データベース／データコミュニケーションの略ってことは分かるけど
結局何をするものなのか、イマイチ分からなくて。
これでも一応、汎用機の業務ＯＬＴＰ系システムを３年ほど経験した
者なんですが・・・あまり何も考えずに今まで来てしまった。
・・・打つ市

301,303のﾕﾆｸｰｽ房が静かになったYO!

>>317
DB/DCのDCはアプル間通信の事ではないかな。
SNAの世界では確か端末アプリもホストアプリも対等の立場だった
様な気がする。

>>298
アセンブラを使ったからレトロという事はないんでないの。
パフォーマンスの条件があるから、良く使われる部分は、
アセンブラにして速度を上げたという事だと思うよ。
三次オン時のIBMのお勧めは共通マクロは全てアセンブラで
書いてくれという事だった。だから、富士はPL/1を使ったと
思うけど、簡単な命令語も全てアセンブラで書いて、それを
参照する形でPL/1で書いていたと思うよ。
でないとパフォーマンスが保証されなかった。
全部上級言語を使って三次オン開発した銀行は、上位都銀の
中には無かった。マシンのパワーが充分じゃ無い時にパフォ
ーマンスに気を使うとそういう事になる。

>>297
銀行の処理の中にはバッチ系の処理が沢山あるの、全てを
オンライン処理するには時間が掛かりすぎる。だからバッチ
で階層DBをハンドリング出来るように、わざわざDBMSをそう
いう風に作って貰っている。勿論オンライン中にも、そうい
うバッチ形式の処理は流せる様になっているから、24時間対
応は出きる筈だし、やってるでしょ。

もう一つ言うと、ATMの24時間対応をすれば良いのであって
ホストオンラインを24時間開けておく必要はない。顧客から
見ればATMがホストに繋がっているかどうかは関係ないから
ね。実際に12時以降６時位までの時間当たりのATMの取り扱
い件数は非常に少ない。日中の100分の1以下の事も良くある。

追加

今回の口座振替の処理というのは、バッチ系の処理の典型的な
ものやね。

訂正
上級言語　×
高級言語　○

>>319
いや、アセンブラだからっつう訳じゃなくて...漏れはその０、１やら９９やらのアセンブラんとこを
書いてたんでわかるんだけどね。

上位モジュールしか呼べないとかいうのが、無駄だなぁと当時ですら思ったよ。だいたいモジュール
階層を１１なんていう半端な数字で制限するのになんか技術的根拠があんの？

>>316
ＧＥＴＭＡＩＮｺﾜｰってのはたしかに流布してたなぁ。でもPSECT（COPY句）のかぶせ違いで混乱してた
ことを考えると実行時のデバッグの大変さはどっちが上かなぁ？それにあの当時にしたってFの
COBOLはかなりいいコード吐いてたよ。まあS/360系自体がCOBOLを素直にマシン語表現できたのも
あるが。実際、９９なんか書いてた中には規約びちびちで書いてコンパイラのほうが高速なコードだぜ、
ってのも多かったYO!確かに人間が見やすい形で書くと負ける部分があんだよなぁ。

あとせっかく完備されてるのにマクロをほとんど活用してなかったなぁ。レジスタ待避やら復帰まで
コピペだったし。おまけにコメントが　ﾚｼﾞｽﾀﾀｲﾋ　とかねw) STM使うななんてのもあったし。
まあ規模でかいから自習書（なっつかしー）に書いてある以上のことは使わん。ってことだろな。
ステップ稼ぎができて助かった。非常に。予測バグ数に達するのにナンギしたけど。

>>312
えっちなページ見ててもう会社に来なくていいって言われた人がいるらしいぽ
2chでも仕事に関連のある内容ならOKなんでしょ

>>319
＞ホストオンラインを24時間開けておく必要はない。

ってATMだけで処理するっての？
是非ともその方法を詳しくご教授して頂きたく

この板は穴場だね>>314 ＜３０８
（ﾟ∀ﾟ）ｲｲ!

DTSの社員が書き込んでるのかな？なんかそんな感じ。

「株式」富士通(6702)-個別銘柄ショート・コメント
メリルリンチ証券は、みずほＨＤのシステムトラブルでの懸念材料として、システ
ム修復に向けた賠償金を含む追加コストの発生、同社への発注量の削減等を挙げて
いる模様。なお、現時点でのレーティングは、Ｂ-2-2-8を維持しているそうだ。
本日の株価は軟調。
http://headlines.yahoo.co.jp/hl?a=20020409-00000016-fis-biz

-------風俗の総合商社・ＭＴＴどこでも-------

〇デリバリーヘルス〇デートクラブ〇女性専用ホストクラブ〇
〇ハードＳＭ奴隷クラブ〇レズビアン倶楽部〇ホモ・オカマ倶楽部
〇変態痴女と遊ぶ会〇痴漢・覗き趣味の会〇変態同好会・各種！
●楽しく遊べます！　090-8002-8356番
-----------美男・美女会員など多数在籍中-----------
　 http://www.mttdocomo.jp/
-----女性アルバイト随時募集・高収入（日払い）月100万円可能-----
-----レズビアン・スタッフ●ホモスタッフ●女性専用ホストスタッフ同募-----
http://www.mttdocomo.jp/
------------------------------------------------

４月の〆もあるからな。
来月なかばまでは、何あるかわからんね。

>>323
ホストを使わずにATM24時間をやる方法はミニ元帳を持っ
た小型ホストを使えば良いんですよ。

ある時間、例えば午前一時に、通常のホスト機からミニ元
帳を持ったミニオンラインにスイッチする。このマシンは
残高情報だけを持っていれば良い訳。明細情報を持たない
し、ATMサポートだけ、取り扱い量も少ないので、小さな
マシンで良い。本来のホストはバッチ処理を開始する。こ
こで、口座振替処理なんかをやる。バッチ処理が終った後、
ATMサポートをホストにスイッチする。ミニオンホストから
取引明細データを作ってオンラインバッチでホストにその
内容を反映する。ホストのスイッチには、精々１分程度しか
かからないから、表面上は24時間ATMサポートが出来ている
様に見える。

sage

>>319
オマエ、元帳更新のタイミングとか、順序のこと、
全然判ってねえ議論だな。
だいたい、ATMの夜間は元帳と繋がないなんて、
じゃ、バッチ引落後にATMディレード更新して引き落とせなかったら
どうすんだYO、教えてくれよ、天災君

>>331
いじめちゃだめぽ。>>319はど素人さんなんだから。
DCについてもとんちんかんなこと書いてるぽ。

>>331
そういう問題はある。
単純化して書いている事は自覚してる。(藁
解決方法としてはATMの一日の引き出し限度
以下の口座分の口座振替処理後の残高ファイ
ルをホストと共有のディスク上に置いておい
て、引き落とす時にそのファイルの残高を参
照しても良い。

また、夜間ATMでの引き落とし日付も口座振
替処理も同じ日付だから、ミニオン終了後の
オンラインバッチで資金不足になった口座は
口座振替側を未処理状態に戻しても良い。
(ここでの引き落としの順序を維持する必要は
必ずしもないと思う。銀行側が口座振替を引き
落とし日のいつやるかは企業側には保証してい
ない。当日入金もあるしね。)

口座振替は未処理になっても当日入金があれば
処理する様になっているから、当日の締切段階
で処理明細ファイルを修正すれば済むと思うよ。


>>332
じゃあ、正解をお願いします。
調べる時間があったんだから素晴らしい説明を
期待してるよ。(藁

>>331,332
上では書かなかったけど、喧嘩腰やオチョラケで
来るならもう返事しないよ。君の質問に答える義
務は洩れにはないからね。精々論破したと思って
いれば良いのではないかな。(藁

>>332
わざとド素人さんのふりをしているだけじゃないの?
こっちはズブの素人だから教えてね。
富士の勘定系オンラインは「IBM IMS DB/DCシステム」に乗っていて、
DKBの勘定系オンラインは「富士通 AIM DB/DCシステム」に乗っているよう
だけど、注目の勘定系巨大バッチも同じなの?

>>333
331,332ではないがレスするぞ。

>(ここでの引き落としの順序を維持する必要は
>必ずしもないと思う。銀行側が口座振替を引き
>落とし日のいつやるかは企業側には保証してい
>ない。当日入金もあるしね。)
これは正解。銀行側は口振依頼元企業にはこの旨を事前に
伝えてあります。（っていうかそういう契約になってる）
以下は漏れの知ってる銀行のケース。（２４／３６５オンラインなので
レスの主旨が違ってきちゃうけど）

スケジュール上、そういった口振処理の前に
�@自分のとこの貸付金→�A代理貸付（住宅金融公庫等、銀行が代理店
になって行う貸付。直接には銀行の資金ではない）→�B口振等、
の順に引き落としを行います。しかもその辺の順序の逆転が起こらない
ようにする準備は入念で、当日付けの貸付金返済処理を全口座分なめて
そこの処理が終了しないと、口振スケジュールには移行しないように
オンライン全体がスケジューリングされています。
ようは、自分とこの資金は確実に回収したいけど、電力会社とかのなんて
優先度低いよ、ってこと。まあ、当然といえば当然。

>>335
前にも書いたけど、バッチ処理でオンラインでも使う階層DBを
処理できる様になっている。だから同じようなものと言って良
いと思うよ。処理スケジュール見れば判るけど、どの銀行も凄
いバッチ処理をしてる。銀行の電子計算センターの人達は知っ
てるから知り合いがいれば聞いて見れば。

>>336
レスサンクス。当たりです。
ついでに書くけど、同じ様に、いくつもの未処理がある時に
オンライン中に入金があった場合の処理順序も明確に優先順
位が決まっています。これはバッチで管理するのではなく、
オンラインに組み込んであります。だから入金するとATMで引
き落とす閑なくバタバタっと未処理だったものが引き落とさ
れて行きます。(藁

>>333
了解。アンタがはじめに、ATMの件数が少ないから何とかなるって
言う風に書いてるように見えたから、ついイジワル質問をした次第。
誠にスマソ。

>>337
336です。ええとですね、漏れの知ってるところでは処理形態ってのが
大きく3つに分かれてます。
(1)MPP（メッセージなんたらプロセス）いわゆるOLTP
(2)BMP（バッチメッセージングプロセス）多分、今話題にあがってるのはこれ
(3)BPP（バッチなんたらプロセス)純粋なバッチ処理。主にSAMファイルが対象

で、ポイントは(2)でして、あるスケジュールに基づいてBMPタスクが起動し、
そいつが通常のOLTP処理で使用されているプログラムを呼び出し、オンライン
DBにアクセスする処理を行う。ってな感じです。だから(2)の処理は
形としては一括処理しててバッチと言えばバッチだが、実際はオンライン
のシステム空間の中でマルチタスクで次々とOLTP処理を1トランザクション
ずつ実行してます。
口振で言ったら、ものすごく操作が素早い人たちが数名でATMから出金してる
と思って下さい。

で、そのBMPの元データ（どの口座に対していくら出金するか）の部分は
というと、各企業から持ち込まれる口振依頼データから(3)のバッチで
作成されてるわけです。

未処理管理については長くなるので割愛。どこかから要望があれば
また書きます。では

>>333
>(ここでの引き落としの順序を維持する必要は
>必ずしもないと思う。銀行側が口座振替を引き
>落とし日のいつやるかは企業側には保証してい
>ない。当日入金もあるしね。)

口振依頼元企業から同一口座に対して複数の振替が
依頼された場合は、古口順とかで処理されると
思っていたが、いつも逆になってしまう都銀があって、
使いにくいので解約したことがあるけど。
これはバグじゃなくて、そういう仕様だったの?

これでも見れ

24時間連続運転
http://www.hitachi.co.jp/Prod/comp/soft1/4vsp/24h/24h.htm

>>337

つまらねぇ文章ダラダラ並べたうえに（藁なんて言っている
君の品性も知れるよ、

面白くないから逝っていいよ、、

ふっ、コードも書けねぇでなにが安全性なんだか。汎用機の安定運用ってなぁ、人の生き血で
できてるんだぜぇ。

>>332=342
結局DCの正しい説明が出来ないので、悪口叩いて
逃げたっていう事ね。良く分かったよ。(藁

>>331=338
了解。

>>343
禿しく同意。

>>344

君の態度が醜いので書きこんだだけなんだが？

誇大妄想癖だったとはね、
しかし恥ずかしい奴だな、

ATM機の中に入って手入力してろ。

>>347
どこがどう醜い態度だったか教えて呉れる。
まともに書いたコメントを最初に揶揄したのは
どっちなのかな。それとも(藁って書いたら態度
が醜い事になるのかな。
それだったら２ちゃんのどの板も皆醜い事になる。

ホントにトラブルﾊｾｰｲしたのか？

株式ニュース - 4月25日(木)19時33分

みずほＨＤ、後場に入ってから給与振込トラブルで株価急落

「午前の段階では給与振込に問題は発生していない
との発表を行っていたみずほ銀行となるが
午後に入ってから一部で実際の振込額の倍の金額が振り込まれるなどの
給与振込のトラブルが発生たと報じられた・・・」
ttp://headlines.yahoo.co.jp/hl?a=20020425-00000012-tcb-biz

ニュー速＋
http://news.2ch.net/test/read.cgi/newsplus/1019726540/-100

バグなのかオペミスなのか、全部読んでないんで分からんが

大本営発表が「トラブル無し」らしいから、
２倍振り込まれた奴ぁ黙っとけば自分の物だな
ｳﾗﾔﾏﾋｨ

>>351
現在は全て人海戦術でやってるからオペミスしかありえない。

>>352
＊＊みずぽ攻略法＊＊
http://news.2ch.net/test/read.cgi/newsplus/1019726540/n3

電算室の変な上着を（青色、自分が知っているのは）
着ている兄ちゃんの臭いがする。このスレ。

または自動機つくってる会社のやつ。過去形か？
Ｏから始まる会社だったりして。

役立つサイトを満載したサイトです。
是非見にきてください。
http://home9.highway.ne.jp/cym10262/

「みずほ銀行のトラブルはビジネス・チャンス」，富士通副社長が語る
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20020425/4/

不二痛って、みずほトラブルの当事者一味じゃないの？

おＫＩ？

今，GMからのインフォメーションが入りました．
MIZUHOは，ホスト再初期化で今までの事は無かったことになります．
全員スキル０，持ち金０から再スタートです．
すでに城や中型の家も建っていますが，ご愁傷様です．

MIZUHOといえば、銀行もDQNだが、東山詐欺死もDQN

一部の企業のデータ消失　口座振り替え数千件未処理
http://www.mainichi.co.jp/news/flash/keizai/20020428k0000m020100000c.html

ｷﾀ━━━(ﾟ∀ﾟ)━( ﾟ∀)━( 　ﾟ)━(　　)━(ﾟ 　)━(∀ﾟ )━(ﾟ∀ﾟ)━━━!!!!!

>>315
>ＩとＦじゃＳＰＡの使い方が違ってたみたい。
亀レススマソ
最近のオンラインでもSPAエリアを活用しているの？
IMSでもCICS風にトランザクションにすべての情報を
設定しているシステムが多いのかな？と思っていたんだけど？

２ｃｈでは随分前からカキコされていたが・・・
何を今更sage

>>320-341
　漏れはドしろーとだけど、この辺りの議論、すっごくタメになった。
　銀行内部の業務処理の中身なんて、そうそう外部にはわからないもんね。

　最後が煽り合いになったのが誠に残念。ブチ壊しの張本人な

>>342
　・・・氏ねよｺﾞﾙｧ！

>>361
そんなことで、３０日は乗り切れるのかなぁ・・・

明日の開局に備えて早く寝よ〜

でも寝られない〜。開局エラー出たらどうしよう〜。

やっぱ、江野明日香たんとＨしてから寝ようっと。

ついに元帳破損の件が白日の元にさらされたようだな。
http://www.mainichi.co.jp/news/flash/keizai/20020428k0000m020100000c.html

朝イチが楽しみ。

ぐふふ。

>>369
特に何も無かった様だが？

３０日の不具合は翌日以降に報告される。これ常識！
３０日がしのげたのは、前に３日も営業日が無かったから前倒し振替が
可能だったため。これも常識。

東京三菱。システムの処理能力を超えたらしい

地殻変動age

そういえば、郵貯に伝染したらしい
提携取引ができないっす

金融・経済
最新更新時刻： 2002/05/07 19:20
　郵政事業庁は７日、郵便貯金のオンラインシステムに同日午後３時８分、
障害が発生し、全国の郵貯のＡＴＭ（現金自動預払機）で提携先金融機関の
カードが使用できなくなるなどの不具合が出ていると発表した。
同庁で原因を調べており、「大半のＡＴＭが始動する８日午前７時までに
復旧させたい」としている。
　同庁によると、障害発生場所はオンラインシステムのうち、約2000社の
提携先金融機関やインターネットからの注文処理を受け付ける
「対外系」システムの制御部分とみられる。
ttp://markets.nikkei.co.jp/news/economy/index.cfm?ref=1

日本は、みずぽ＋３大ギガバンクになったそうです

ホットニュース
最新更新時刻： 2002/05/07 22:16
　みずほフィナンシャルグループは７日、大規模なシステム障害について
金融庁に報告した。発生原因はシステムのプログラムミスや事務作業の
混乱が重なったためと改めて説明。金融庁は８日から立ち入り検査を始め、
早ければ月内にも業務改善命令を出す方針だ。

>>376
寺バンクとききましたが。。。
当然、だめぽ＝�`バンク

ttp://itpro.nikkeibp.co.jp/NC/members/NC/REPO/20020511/1/
対外接続系の修整をミス，振替処理の開発も失敗

（１）ATM（現金自動預け払い機）が正常に稼働しなくなった原因は，
旧第一勧業銀行の対外接続系システム（富士通のメインフレームを利用）の
修整ミス。
これまで報道されてきた，「リレー・コンピュータ（RC）」
（富士通のUNIXサーバーを利用）の不具合ではなかった。

　口座振替のトラブルの原因は，口座振替処理（センターカット）のために
新規導入したプログラム（日立製作所のメインフレーム上で稼働）の
開発に失敗したことだ。
対外接続系とセンターカット用プログラムの修整・開発作業は，
第一勧銀情報システム（DKIS）が中心になり，ソフト会社の協力を得て
進めたものである。

なんか飽きてきた
次どっかない〜〜〜？

休日にやるかい、ﾌﾂｰ？
ｹｺｰｳな額の休日出勤手当。
相変わらず無駄が多いなぁ。

ttp://www.nikkei.co.jp/news/main/20020519CIII084919.html
　口座振り替えのトラブルなどシステム障害が起きたみずほ銀行は19日、
４月の発足後初めて、東京・千代田区の本店で部店長会議を開催した。
工藤正頭取は全国から集まった支店長ら約700人に、今後の課題として
「人事の完全な統一に向け積極的に取り組む」との方針を説明し、
顧客の信頼回復を図るよう訴えた。

　工藤頭取は「出身行のバランスにこだわることなく、適材適所の人事運用を
徹底していく」と強調。旧行別意識の弊害が指摘されていることから、
旧第一勧業、富士銀行の支店長間や、システム部門などの交流人事を前倒しで
進める方針を示唆した。

また、やってしまいました。

２営業店で振込障害＝グループの信頼回復に打撃−みずほコーポレート銀
ttp://headlines.yahoo.co.jp/hl?a=20020520-00000379-jij-bus_all
　みずほコーポレート銀行の２営業店で２０日午前、
振り込みを受け付けられなくなる障害が発生、
証券会社が行っているインターネット取引の
一部に遅れが生じた。
障害は同日午後に復旧した。
関係者によると、週末に同行がシステムを
微調整した際に何らかの不具合が生じたのが
原因とみられる。
　新たなシステム障害の発生は、
口座振替遅延などで失墜したみずほグループの
信頼回復にも影響するだけでなく、
月末の大量決済処理にも不安を残した。　（時事通信）
[5月20日21時3分更新]

http://www.nikkei.co.jp/sp2/nt26/20020521dl1i155021.html
　午前9時過ぎに都出納長室の職員11人が
東京都千代田区内幸町の同行本店に入った。
都が検査の趣旨などを説明し、みずほ銀から
障害の状況や原因などの説明を受けたもようだ。
1カ月程度で検査結果をまとめ、
今後のみずほ銀行への対応を決める。

検査って具体的には何するんだろう？

あぽーんって何?

>>386
あぽーんではなく、あぼーん。
骸、削除、消えろ、残骸の意。
２ＣＨで遊ぶなら、下記用語は必修だ。
http://www.myu-k.co.jp/2ch_fq.html

みづほシステムあべんど