【社会】三菱東京UFJ銀行でシステムトラブル、約30億円が定期振込できず 想定外の処理が発生 [5/1]

三菱東京UFJ銀行でシステムトラブル、約30億円が定期振込できず
2014/05/01

三菱東京UFJ銀行は2014年4月30日、定期自動送金サービスを担うシステムにトラブルが生じ、
当日中に振り込みができない事象が発生したと発表した。約2万3000件の契約について、
合計約30億円が振込先に入金できなかったという。

トラブルが起きたのは、決まった振込先に対して定期的に定額を振り込む「定期自動送金サービス」。
4月30日付けの振り込みの一部が送金できなかった。システムに「想定外の処理が発生した」（広報）ためだ。

定期自動送金サービスのシステムは、振込日の前日に、1000件単位で契約内容をチェックし、
送金処理を実施している。前月分の振り込みで同サービスを解約した契約については、
当月分からは送金の必要はないものして扱われる。

具体的には、契約内容のチェックにおいて、契約の継続が確認できたものは、翌日朝に送金処理が
実行されるが、確認できないものについては、解約したものとして「データなし」として処理する。
このチェック処理は、1000件連続で「データなし」と確認すると、終了する仕様となっている。

2014年4月30日付けの送金に関して、チェックの対象となったのは6万4162件。本来ならば、
チェック処理を65回繰り返して正常終了する予定だった。ところが処理の途中、1000件連続で
「データなし」と判定する事象が発生した。この時点で処理が仕様通り終了してしまい、
未処理だった約2万3000件について、送金ができなかった。「1000件を超える解約があった可能性がある」
（広報）という。

三菱東京UFJ銀によると、5月1日以降の処理について、同様の事象が発生することはないという。

三菱東京UFJ銀行のお知らせ http://www.bk.mufg.jp/info/pdf/info20140430.pdf

ソース： 日経コンピュータ http://itpro.nikkeibp.co.jp/article/NEWS/20140501/554082/
関連スレッド：
【事故】三菱東京UFJ銀で一部の振込が未処理、規模など調査中 [4/30]
http://ai.2ch.net/test/read.cgi/newsplus/1398856328/

だいたい社会インフラシステム更新はＧＷと相場が決まってるからなー
あぁ顧客の信用情報にキズがつく・・・

Xデーか？

ＳＥ地獄やな

大事な処理なんだから全件チェックするようにしとけよ

そういや日曜日テレビ放映された劇場版相棒でやってたな

意味もなく処理に上限付けて、それで不具合起こすシステムってなんなの？

ちょっと前に容量超過って銀行全体のシステムの問題点のニュースなかったっけ

しょうもないチェックロジック使っとるな

>>1
＞このチェック処理は、1000件連続で「データなし」と確認すると、終了する仕様となっている。

この仕様書作った奴、バカそのものだろ（´・ω・｀）

おい、振り込み出来てないと人生終了する案件あるんだが・・・
私は殺されるんですか？

ここのＡＴＭ有料化にぶち切れて解約の嵐なんだろうよ

>>7
コンピュータのパワー、リソースが有限だから。

この処理、どこの誰がOK出したんだろ
みずほはこのシステムの何十倍ひどいんだろうな

なんとなく分かった
終了したらまずいな

>>13
なるほど、じゃあしょうがない。

>>10
また自殺者が出るな

同じSEとしてはビビるような、んな馬鹿な仕様書かねぇわって笑うわ


・・・仕方なく書かされる時があるんだよなぁｶﾞｸﾌﾞﾙ

チェックを打ち切る条件がおかしいだろｗ

オワタ

>>13
それにしてもたかだか6万件程度の処理だろ？
UFJのシステムの規模からすると微々たるものだろうに。

なんで1000件連続で削除が来るとゲームオーバーにしちゃったんだ？

人間の判断を介さずにABENDしてしまうのを許容するからおかしい
つか韓国のフェリー事故もこういうノリを延長したものだったんだろうな

1000件を超える解約？
末日締めってことは家賃の自動引落しとか、そういう類のものかな

１０００件も連続することはありえず、
むしろ何かトラブルが発生している可能性があるから、
処理を終了する。

って発想は悪くないが、
使っているうちに、そういう仕様であることは
忘れられてしまうから、パニくるよな…

5月の連休前後は派遣SEにとって地獄だな
みんな遊んでるのに会社でデバック、テストばっか
しかも薄給でこき使われてる
やってられんわ！

1000件連続で「データなし」と確認すると、終了する仕様となっている
1000件連続で 「データなし」と判定する事象が発生した

仕様どおりの動作したってことなんでしょ、あーよかった

>>2
馬鹿過ぎるｗ

>>18
処理が累積すると急ぎ実行しなければならない優先処理まで滞るから
このトラブルの根幹はシステムの負荷分散がなっていない証拠

昨日の晩、カード会社から「今日入金が確認出来なかったので振り込んでね」
って電話があった
銀行違うはずなのに連絡が早かったのはこれのせいか

処理終了の条件がコレだったら、実行完了後にチェックする手順が必要だろうな。
目視でもいいが、自動化もできるだろう。理想は両方。
何かのタイミングでその手順が失われたんだろうな。

>>28
打ち切らなければチェック処理続けるんだから関係なくね？

普通トレーラーに総件数チェックしてエンド読んで終わりだろ
どこの外注が作ったんだよ

>>25
今時、銀行系でそんな仕事してんのはみ○ほくらいだよ

>>28
お前、IMSの仕組み知らんだろ

>>14
みずほは合併する末端のＡＴＭの処理手順の違いを見落とした、と聞く

あれっ

このせいで俺のクレジットカードまでトバッチリ食らったのではないか
少しの間使えなかったぞ

今日ある店舗ではATM１台とまってたぞ
くそ長い行列できてんのに

で、いつなんだ？
Xデーは

よく分からんが、COBOLで桁あふれを起こしてるんじゃないか？

>>25
派遣なんだし辞めちゃえば逃げられる

>1000件連続で「データなし」と判定する事象が発生した。
こっちのほうがおかしくね？

GW用のセンターカットの設定ミスったんだろ。あほだ

>>37
なにそれ？
ＮＥＳＡＲＡの事？

相棒とのコラボか

半沢か花咲舞はやくきてー

>>38
エクセルでソートすると最後に空白行がダーと集まるけど、
そんなデータの流し方したら内部ロジックが表面化したとか。。。？
仕様書は良く読め、みたいな

バッチ処理のterminate条件が適当すぎるw

処理が空振りしたら即終了ルールなのか。
大口の大量削除とか想定しないんだろうか。
あるいは異常終了の場合でも気が付かなそうだ。
前日との差分チェックか、登録件数と処理件数の突合せが必要だな。

仕様が基本情報に出てきそうな文体。

http://www.youtube.com/watch?v=EpwW1KdKlOs

>>10
仕様書なんてモノはな、一番最後に作るんだよ

これは隠しコマンドであると思ふ

まあ、４／２０過ぎにアチコチの会社で初任給の支払いが開始されるし、
一方で３月で辞めた人の給与振込の停止もあれば、
家賃の引き落としも３月に引っ越しが集中するから４月は停止が激増するし。
更に連休前に資金決済が集中するし、何年か前にみずほがやらかしたようなこともあるわな。
連休前は手持ちの現金は余裕を持って事前に準備しとかないと、
下手したら自分の預金も引き出せない恐れもあるよなあ。

ルーズベルトゲームだな。

これは下請けに死人がでるな

思ったより騒ぎになってないのかな
定期的に定額ってどんな取り引きが多いんだろう
給料も毎回違うだろうし

何で1000件データが無かったら処理終了にしたのだろう。
対象が無限にあるわけじゃなく、連続1000件6万4162件が続かなかったら
6万4162件チェックし処理するんでしょ？極端な話、6万4161件データが無くても
最後の１件に処理しなければいけない案件があるかもしれないのに。

もしデータが無ければ「データなしの処理」をし、次のフィールド？をチェックせよ、
データがあれば振り込み処理をし次のチェックをしろだけじゃないのかな。
「データ無しの処理」がi++で、iが1000以上ならプログラム終了は余計なことに思える。
自分、素人だから的外れとは思うけど。

>>50
勘定系でそりゃないやろ

windowsＸＰ？

>>55
家賃。

↑↑↓↓←→←→AB

このせいで嫁にちゃんと振り込んだの？ってめっちゃ怒られたンゴ…

想定外→ABEND

おれはＳＥだが、別にこんなことどうでもいいじゃねえか
死ぬわけでもなく、金がどっか逝ったわけでもない
勤め人はみんな早く家に帰りたいし、休日は普通の勤め人みたく
休みたいんだよ

>>1
これ個人でも、
保証人代行業者を利用して家を借りてるよう人だと不味いんじゃないのかね？

あーあ、他人の預金がエラーで全部俺の口座に振り込まれないかな

>>60
ＢＡじゃなかった？ｗ

なるほど、月末だと家賃が多そう

COBOLにしとけばよかったのに

MDIS...

、


　みんな夜空を見上げるんだ。

　また一人、名もなきＳＥが死んでいく

1000件空振りってループしてね？？
終わらせるようにしとくか。

こんなところじゃね？

三井住友ATM高すぎない？
この前利用したらびびったんだけど

毎度のシステムトラブルで思うのは、新銀行を設立して、新システム立ち上げて、口座を徐々に移管して行く方が安全じゃないのか？
もしこれでうまくいったら、功労者として何かくれ！

船頭多くして頭取謝罪

顧客が本当に必要だった物
ttp://blog-imgs-12.fc2.com/n/w/2/nw2/project.jpg

日本人の言い訳は
世界一ヘタクソ
近隣を見習えや

>>73
何と何を比べて何がどう安全なんだかさっぱりわからんｗ

>>70
この場合、氏ぬのは担当役席だな
外注は結構しぶといよ

>>76
世界一発達してるのは日本のATMな

>>79
そうかな？？
海外のクレカ使えないとかあるよね。

>>79
小切手じゃなくてatmで全国百行やりとりして
トランザクションが合うのは、なんだかんだ
言って凄いぞ。

どう見ても想定外の処理じゃなくて想定通りの処理じゃん
1000件連続データなしで終了する仕様通り正常に終了したんだろ？
そもそもが何かトラブル発生の可能性があるから処理打ち切って調査するためとかの仕様なんじゃ無いの？
何故かそこで放置して未処理案件を無視している馬鹿な運用者がいただけじゃん
何故システムトラブルって人のせいにしてるんだ？
トラブルなのはお前らの脳みそだって言う

>>65
タイムマシンとかいうＳＦ映画で
ＩＴ技術者が利息の小数点以下の端数を自分の口座へ
って処理いれて派手な生活送る話、あったな
最上階の役員会議室の窓から投げ出されてたような記憶があるけど

ATM有料化で糞になった
金預けるのに手数料取るとかおかしい

大口が連番で1000個の振り込み予約→実行があって
次の月までにその大口が解約したってことかな

1000人の従業員を抱える会社の社員への臨時給付とかに一回だけ使われたとかかしら

１０００件単位でチェックする仕様らしいから、
絵に描いたような仕様バグだな。

>>83
ウェルズの？

>このチェック処理は、1000件連続で「データなし」と確認すると、終了する仕様となっている。

ざっくりすぎるだろｗ

1000件単位で仕訳伝票を処理して元帳を生成するアプリなら作ったことがあるが、
空白地帯が続いたら終わりはねえだろw

1000件ってどこから出てきたの？勝手に制限つけるなよ

>>73
それは既に「みずほ銀行」という実例がある
One Mizuhoとかほざいてシステム統合中だ
延々な
統合中に更改案件が山積み、更改をやって、また統合するとまた問題を抱えた統合前の各銀行のシステムが保守期限を迎え、



どんどんバラバラなもんが歪に繋がって、
また問題が発生している

まあお前も手伝え

こういう話は楽しいなあ

他人事に限るけど

1件あたり65回も伝票チェックするなんて65人の行員が徹夜でやってるのか？

上海F？頑張れよ。
冥途員シナのシステムってマジかよｗ

>>83
どこぞのメガバンクの内部犯行で
休眠口座に多額の銭入れての利息GETやってた奴なら居たとオモタ。

>>83
実は米で全く同じ手口の犯行があった。
それをアシが付かないように架空口座に振り込むように
プログラムを組んでウホウホしていたら、
架空口座を存在しない口座名（例えるならＸＹＺとか）にしていたところ、
本当にＸＹＺ氏が口座を開設したからさあ大変、
そのＸＹＺ氏の口座が身に覚えがない額がドンドン殖えていったので、
ＸＹＺ氏が驚いて銀行に問い合わせて発覚した。

頭の悪い設計だなｗｗｗ
どこが作ったんだ？？

怪しいな
テスト用の無限ループ回避条件が残ってたんじゃないか？

> このチェック処理は、1000件連続で「データなし」と確認すると、終了する仕様となっている。
何でそんな仕様になってるかちゃんと説明しろよ

業務系って一回仕様が確定するともう変更できないうえに
仕様決定する段階で関わる人間がシステム素人ばっかり

異常なデータ検出のひとつでないの？

むしろそれが起きた時に即対応できない体制がおかしいんじゃないの

仕様通りで、お客様が悪いんだろこれ。
銀行は胸を張れよ、弊行の規約にも明記されている仕様でございますってな。

規約に無いなら法務部の責任、仕事しろよｶｽ

sortパラメータいじったんだろ
と適当に言ってみる

振り込みできなくて利息が発生してしまったら勿論UFJ持ちだよね。

月またぎ　ってのはマズイな

IT土方、連休の後半が消えるの巻

ＳＥになんかなってはいけない

そういえば素人で良いからてseをかき集めている銀行があるとどこかで見たな。恐ろしいね。

＞定期自動送金サービスを担うシステムにトラブルが生じ、

まぁどうでいいだけど、「定期」じゃなくて「定額」な
どうでもいいんだけど

少し余裕持って　２８日くらいに設定しておいたほうがいいな

想定外の操作が出来ることの方がビックリだな。

当行他店あて振込が有料に変更されていたわ

ブーメラン・・・といいたいとこだが、このシステム異常の陰で
かの国へのロンダリング作業の臭いがするなあ

こんな事が起きていたのか
今日、普通に振込をお願いしたけど、無事に送金できてよかった(^^)

優しいSEさんがちょっと弄って、LOTOやBIGの1等を当ててくれますように

韓国とその企業ポスコ他に大口支援してるんだよな。ここと三井住友。みずほも。
韓国がつぶれないようにせっせと反日資金を供給してるわけだ。
共倒れしちゃうもんねー。
日本の中小には貸し渋るくせに。

借金はこれで誤魔化せそうだな
しらんがな確かに入金したで

データチェックせず処理しないようにする仕様ってすげぇな
1001件目以降にデータあったら処理されないってｗ

>>1
＞このチェック処理は、1000件連続で「データなし」と確認すると、終了する仕様となっている。
＞ところが処理の途中、1000件連続で「データなし」と判定する事象が発生した。この時点で処理が仕様通り終了

想定通りの処理じゃねえかｗｗｗ

本当にそういう仕様だったならな・・・

正直に言えよ
undefで終了しなきゃいけないところをfalseで終了しちゃってたんだろ？
null終了しなきゃけいないのをゼロ終了しちゃったんだろ？

>>114
システム不全でもうじき目が目が〜って言ってる所
セウォルしそう。

三菱UFJのシステムってどこで請け負ってんの？
自前か？

家賃の支払にうちの口座使う奴は大馬鹿 ということなのか？
俺のメインバンク。

ちなみにチリは超親日国な
昔日本の近くで沈没した船を日本人が体を張って助けた

合併するのにあっちはA社システムでこっちはB社システムってなってたらそりゃトラブルにもなるんじゃない？
システム内部のことはまったく知らないけど。

今まで何十年も遅れたことが無かった家賃の振り込みが無かった、これだったのか

このシステムかはしらないけど日本IBMがufjのシステム改定に
か関わっていたはず。
2年位まえのIBMカンファレンスで説明してた。

仕様通り！
プログラマー大勝利！

XDAYの録画昨日見た麦価なのにｗ

想定外にどう備えるかが危機管理じゃないのか

仕様だから無問題。

嫌なら他の銀行へ池って事じゃないの？

わーいわーい

自分の口座に3000万ぐらい振り込まれてないかな(´・ω・`)

その仕様が出来上がった背景は何だ？
意味わかんねー。

なんか知らんが、総件数をゲットできないので、こういうことをしたわけか。

>>7
別に上限を付けたわけじゃなくて、終了判定しようとしただけだと思う

たぶん>>117

つまり、「処理すべきレコードが存在しない」判定をしなければいけないところで
「処理したレコードが０件」で終了してしまっていたのではないかと・・・

>>131
多分、銀行側の怠惰。
システム屋に仕様策定丸投げしたから無責任で良いとか思っていそうな気がする。

こんなミスするか銀行が
信じられんわ

フロッピー全盛期のプログラムそのままか？

>>130の口座全財産が俺の口座に振り込まれますように

>>136
オープンリール時代じゃないか・・・

>>25
仕様追加いいすか？
あ、連休明けまででいいですよwww

矢沢永吉の負債より安いな

何十年前に作ったロジックなんだろうな。
プログラム修正するのは1行だけだな。

ＦＯＲ文で６５回、インデックスカウンタを回す処理で
処理終了条件が甘かったのかね
NEXTまで回して、カウンタチェックの方が安全じゃないの
予想だけど。

あー、先月来た三菱東京UFJ会社からのお知らせを無視しなければよかった

>>141
UFJの仕様だと言うなら
このプログラムだけとは限らないよなー
パフォーマンス上げる為の処理だったりしたら

三菱東京UFJなんてこんなもんだろ。

銀行＝コンピュータシステム

だから、コンピュータシステムの仕様が銀行のルールなんだよね。
今更間違ってましたサーセン、

本当は〜が正しいんです（ｷﾘｯ

とかは頭取の辞任が必要なレベルだと思うんだ。
責任とはそういう事だろ。

バンカー様は偉いから全て許されるとかネーよ。
システム＞＞＞＞＞＞＞＞＞＞＞＞＞＞バンカー様の力量　だろ。

おまいらのおかげで、やっと意味が分かった。
こんな処理イメージだろうか。

１．1000件単位にデータを読み込んで1000件分のワークエリアにセットする。
２．1000件分のワークエリアが全て空白行の場合、EOFと判定する。
３．解約データがあったら、ワークエリアに空白行をセットする。

今回は解約データが１０００件以上連続であって、1000件分のワークエリアが空白になったから
終了と判定されたと。

あまりの糞仕様ぶりに、記事を読んだだけでは理解不能だったわ。

>>144
合併でデータが増えて、バッチ処理が夜中に終わらないから、
パフォーマンス上げる処理を突っ込んだ可能性はあるね。

なんでこれが「システムトラブル」なの？

UFJ使って月末に給料か決済金か何かまとめて振込みしてた会社が解約したんだろうな

>>149
プログラムの設計ミスだから

銀行の責任じゃなくて
下請けが責任とらされるよな。

銀行関係の孫の孫下請けで仕事した事あったが
上の人ってあんま理解してないよな・・・

>>151
設計ミスかどうかは記事からでは判断できないけど。

ベンダは日立？

こういう間抜けな仕様でも、担当者レベルが「この仕様はまずいんじゃないですか？」と申し出ても、
往々にして上層部で握りつぶされるのがオチ。それでもしつこく食い下がると逆に干される。

どやす銀行員、どやされるSE。SEが可哀想だな

1ファイル(中身最大1000件)、nファイルをhalftで受信
受信側はnファイルを読み込みながら処理
戻りの件数がゼロ(読めない場合、全ファイル読み込み終了、ゼロ件return)でexit

大量解約で処理件数ゼロで仕事終わり〜
だろ

コンピュータのシステムとすれば、
30億円の振込みが出来ないとか考える処理無いもんな。
そういうのを重大事項として要件に出来なかった時点で
銀行側のミスだろ？

>>158
内情は知らないけど、多分、リスクに気付いてた人はいたと思うんだ。
初めてそのプログラムをみたら、なんで1000件で切ってるんだろうって思うでしょうし。
今まで大丈夫だったから平気だろう、って感じじゃないかな。

また落穂拾いとかいう担当者だけに責任押し付ける吊るし上げ大会が開催されるのかい？

>>153
故意に1000件連続すると終わらしてるってのは文面からでも解かることでは？

X-DAY の正確な日付を教えてくれ！

>>161
故意なのはわかってもそれがミスなのか本当にそうしたかったのかは
わからないじゃない。

>>159
現場の人は気づいてる。
だが下請けの下請けの立場でそんな事言えるはずがないし

ちなみに有名なのが
過去に大規模システムトラブル2回…….

みずほFGの次期システム発注の裏側…富士通の独占が崩壊！
http://biz-journal.jp/2012/12/post_1105.html

東北大震災の後のトラブルはまた別件だからな。
俺らの募金活動が想定外の振込みだったから。

>>40
自分もそう思った

なぜ６５５３５件にしなかった

こういうトラブル情報が出るとどこが担当してる部分がトラブる起こしたんだ？って各所で緊張が走る

定期自動送金って地代家賃の振込くらいしか思いつかん

1000件も連続で「データなし」が起こるようなときは
その元データになにかおかしいことがあったから異常終了する

ならわかるけど、その場合は異常終了して元データがおかしくないか
チェックして問題なければ朝がくるまでに今度は終了させないようにして再実行
という対処をすればいいだけなんだけど
夜間のSEが対処方法を誤ったんじゃないの？

プログラム上は逆に想定内のことが起こったからそのまま終了しただけだし、
想定外って言っておけば許されるって風潮が嫌だね

この判定処理の妥当性レビューした奴、死んだ方がいいよ。
多分レビューしてないんだろうけど。

想定外の処理発生してないじゃん。プログラム通りなんだから、既定の処理で想定内しょ。

この程度で処理しきれないって糞遅いJavaでも使って開発したのか？

>>21
もともと１処理の件数が1000件だから。
対象全件がデータなしだったってだけじゃないのかと。


>1000件単位で契約内容をチェックし送金処理を実施

間違って俺の口座に振り込まれた後に振り込みデータがクラッシュしますように

>>159
何年もコケずに動いてるプログラムは、なるべく触りたくない
なんでそんな仕様になってるか分からない場合は、とりあえずそのままにしとこうって思う

ファイル丸ごと読み込むと重たくなるから1000件ごとに小分けにしてたのかな？

>>91
残念ながら、俺は使う側で、そんな作る能力ないな
すまんな、シヌまで働いてくれ

>>171
仕様ミスなのかロジックミスなのか分からんくないか
と思ったけど、想定外の処理って言ってるから仕様ミスなのか

> このチェック処理は、1000件連続で「データなし」と確認すると、終了する仕様となっている。

まあ前例がないからこういう条件にしたんだろうけど
ちょっとアホっぽい仕様だな。

つうかたかだか6万数千件なんて全件ブン回してチェックしろよｗ

これは処理前に総件数が把握できないから
1000個単位で処理してって空データが1000個連続したら終了って仕様なんだろ
途中で空データが来ることはないのが前提なんだろうから
送られてきたデータの方に問題があったんだな

何処が作ったの？

>>1
相棒
Ｘ-DAYかよ？

>>181
解約と空データを同列に扱わざるを得ない状態にしていることが
そもそも間違いだよな。
そこは前工程で区別つけろと。

>>184
じゃあ、そう修正してくれと説得してみろよ。無理の一言しか返ってこねーよ。
そうやっていろいろ問題を回避するたびにトンデモ仕様が蓄積されていくんだ。
既にどれが何の問題回避のための仕様かすら誰も把握していない。
もう何も変更できねーんだよ。

そういう状態。

>>185
ソースが唯一残ったドキュメントなんだろうな。

月末だったみたいだけど、不渡りが起きたりしてないよね？これ。

　　ｎ
　　l.l＿. 　　　　　　　　　　　　　　　　
　r|　　 j　　　　　　　　　　　　　　　　
　 ゝ　.f　　　　　　　　ジタミ　そうか　　　　　　
　　|　　|　　　　　　 /　 　　ｎ　　ヽ.　
　 ,｣　　L_　　　..　,'　　..▲　▲、 .',
　ヾー‐'　|　　　　|　 く 〈 ◎ 〉 ゝ |　　
　 |　　　じ､　　　| 　＼|´▲｀|／..│
　 ＼　　　 ＼. 　ヽ 　　 　　　　　/
　　　＼　　　ﾉﾘ^ー-＞==__,..-‐ﾍ＿＿＿
　　　　 ＼　 ノ ﾊヽ　 |_/oヽ__／　　　　
　　　　　　＼　 /　　　 /　　　　　　　

>>184
て言うかこれは連続データなんだろ
本来空データってのは無いのが前提だと思うぞ
このケースだと1000件詰まったのが64本来て142件で残り空ってのが一本来て
最後に空1000件が1本来たら終了っていうのが本来の手続きだったんだと思う
それが途中で受信空振りしたかなんかして空1000件扱いのが一本来ちゃったんで仕様通り終了したってことなんじゃないかな

在日だらけの日本チョンビーエムがまたやらかしたのかwwwwwwww

>>189
その通りだとしたら、両方アホ仕様としか言いようがネェな。

>>191
まぁ俺が前にいた別の銀行でもこれと全く同じ手続きしてるシステムあったからなぁ
古いシステムだと結構これに近いことやってるの多いと思うよ

相棒でやってたなコレ

はぁ？頭悪すぎな仕様だろ
入社一年目がつくって、ノーチェックで出したのか？

俺が1円ずつ1000件振り込む契約してすぐ解約したらまた発生するの？

大手でも予算と期限絞って作ったシステムなら
重大事故につながるバグとか仕様不良なんていくらでも眠ってるよ
ときどきそういうのが顕在化して重大事故になってる

>>189
あ〜、システム連携部分か何かで全件数を事前に貰えない（相手側が
吐き出す努力ををしない）から0データ1000件を番兵にして、、、、、
とかか。

この手のケースって突き詰めると銀行が金けちってる事が原因なのが
大半なんだよな。それでいてトラブルを口実に因縁つけて次の契約を
割り引かせたりするからどんどんシステムの品質が低下していく。
銀行の自業自得だよ。

金融庁も真面目に指導しろや、と思う。

　　　　　　　　　∠:::::::::::::::::::y（::（　　））ﾍ :::|
　　　　　　　　　 〈:::::::::::::ノ|/ ,...,,,,特　区.,, {:ﾉ
　　　　　　　　　　∨::::::::{ 〃 _＠, ::..　'＠ }
　　　　　　　　　 　 Vミ:::�Y| ｰ〜 .:　∨¨ |
　　　　　　　　　　　｛　ヽ:トヽ::..　（_;;__;;)∨
　　　　　　　　　　　 ＼__;:..　｀ 〃ﾄｪｪｪｲ}
　　　　　　　　　　　　　V|:ヾ、 {{　`==-'/
　　　　　　　　　　　　　 _| 　 ヾゞ:..____ノ
　　　　　　　　　 　 　_/i:i|　　ｰ=;..__-=|＼＿＿＿
　　　　　　　　-=ﾆ三{i:i:∧ 　 -=し-=ﾘ:i:i:}そうか　=-
　　　　　∠　　　　　ｉ:i:∧ 　 　 　 /i:i:i:i　ジタミ　三ﾆ=-

　　(⌒Y⌒)|＿__）　　(⌒Y⌒)u　(⌒Y⌒)　　　　|＿__）　　
　(⌒*☆*⌒) (⌒Y⌒)*☆*⌒)(⌒*☆*⌒)*☆*⌒)~)　　
　 ~（__人__)~(⌒*☆*⌒)ゝ__)~　~（__人_(⌒Y⌒)*☆*⌒)(

カウンターが３桁に決まってるだろ、Ｓ９（３）ＣＯＭＰ−３
そのくらい記憶域は貴重だった

日立か

命令通りに作った下っ端が責任を取らされる会社に勤めてる男の人って…

ロシアへの送金がウクライナ絡みでなくなったからとかだったりして

　ジタミ物語　　　　ダム物語　.アベノミクス物語　原子力物語
|＿30＿0021__.,|＿09＿0301＿_,|＿04＿716＿_.,|＿00＿_1852_.,|
|　.／:::+:+::::＼ . |　.／:::+:+::::＼ . |　.／:::+:+::::＼ . |　.／:::+:+::::＼ . |
|√:*::::###::::* :: |√:*::::###::::* :: |√:*::::###::::* :: |√:*::::###::::* :: |
| | ::U::777::U::: | | | ::U::717::U::: | | | ::U::174::U::: | | | ::U::478::U::: | |
||| .::*::::u::::*::: ..| ||| .::*::::u::::*::: ..| ||| .::*::::u::::*::: ..| ||| .::*::::u::::*::: ..| |
||＼_∧＿∧_／ ||＼_∧＿∧_／ ||＼_∧＿∧_／ ||＼_∧＿∧_／ |
||＿<=( ´∀｀)___ ||<=( ´∀｀)___ ||＿<=( ´∀｀)___ ||＿<=( ´∀｀)___
| ==（　　 　）◎─=（　　　　）◎─ =（　　　　）◎─= （　　　　）◎　
|〓〓　　　 ）〓〓. （○　　　）　.　　 （○　　　）　　　　（○　　 ） 　　
|〓〓┳━) )〓〓　━┳━)〓 　　　━┳━) )　　　 ━┳━) )

定期送金サービスなんてあんのか？
いつも家賃手動で払ってた

>>201
責任なんて取らないよ。
仕様通りの正しい動作です。
要件もそうなってます。

と、答えて終り。

>>205
ITは取らされるんだよね。
自称SEはいくらでも嘘ついてPGに責任を押し付けてくる。日常風景。

>>204
１回につき108円とられるんじゃなかったかな

この手のスレは、何も知らない馬鹿ばかり湧いて出てきてスゲー面白い
唯のバカ自慢だらけだし

ようは解約が1,000件超えることはないと
想定していたわけか

直に読むとSafe側に倒れたので、システムとしてはOKなんじゃない？

そういう仕様なら仕様バグだな（棒

仕様が甘かったんだな
1000件連続で解約が続くことはないと決めつけていた

責任取るのはレビューした上長だろ

大手銀行向けならどんな糞仕様でもレビューぐらい通すだろうからな
そこでチェック機能が働かなかったという話

＞ 1000件連続で「データなし」と確認すると、終了する仕様となっている。

仮にもSEならせめて1024件にしてほしかった(´・ω・`)

>>212
逆だろうな。
どうにもこうにも誰に聞いて誰も仕様を知らないので決めざるを得なかった。

>>214 そのキリの良さゆえに、ＳＥが処理を早くするために設計したものではなく、
銀行がオーダーした仕様であることが丸わかりだね。

件数は普通はキリが良い数字だよ
2進数が絡んでるわけでもないDB処理でわざわざ1024件なんて数字は使わない

銀行に金がないんだよ
言わすなよ

送金すべきデータ無しと、送金の契約なしってのがごっちゃになってねぇか？

見るDBのデータ項目か、データのレコードの項目間違ってるorデータの種別コードみたいなのが荒い、とかじゃねぇか？

ガイジンさんに作らせたか、アホに作らせたか、アホが短時間で作ったんちゃう？

あるいは、送り主の人が大量に死んでるとか。

普通に、1000件超えたら止まって、アラームでいいだろ
できてるような気がする
アラーム無視したんじゃないの、アホな行員

責任を取るとしたら
何をすればいいの？

なんで1000件連続してたら、処理を打ち切るなんてプログラムにしたんだろう。
そんな面倒なことをしないで、単にend of file まで実行させる方が楽だろ

>>1
＞当日中に振り込みができない事象が発生したと発表した。約2万3000件の契約について、
＞合計約30億円が振込先に入金できなかったという。
＞トラブルが起きたのは、決まった振込先に対して定期的に定額を振り込む「定期自動送金サービス」。

毎月か４月末に定額を送金するのがダメになったんだな？
ローンの返済とか定額の貯金とか投資か？？

>>222
当該回の終了か全回分の終了かを手っ取り早く稚拙に判断するっていう・・・

なるほどね
連続１０００件初期値ならデータの最後だよってことにしてたのか
データの塊が１０００件単位とかで逐次処理してたんだろうね
それで本来ならデータを受け取れずにNullとかで処理すべきなのを
初期値で終了にしたからデータなしと初期値の区別がつかなかったと

1000件連続削除でエラーを出して停止するってのは、誤操作保護の観点ではいいかもしれないけど、復帰速度までは考慮出来ていなかったみたいね。

もうすこし言えば
連番のファイルに１０００件ずつデータが入ってて
逐次処理してたんだろう
だからファイルの終了やDBでの件数でなく内容で終了判断したとか
なんでもDB使うわけじゃないしね

>>225
一回ごとの処理の高速化か、分散・分担で処理するのを優先してる気ガス。

>>227
あるいはソートとかで抽出せず、他の取引？のレコードも混じっていたか・・・

>>227
振り込んだ件数が０なら終了としたんだろ。
言い張れば仕様かも知れないが、実装のバグだろう。

仕様通りと聞いて一安心だよ
銀行の人もそれでOKしてくれたんでしょ

>>229
それもありえるね
不要のデータが続くから読み飛ばしの為に入れた処理が・・・とかね
全件処理できてない時点で実装バグだよね

どうみても仕様バグ
0、切り替わり、MAXの仕様が適当すぎ

振り込み手数料？が
無料から有料になって
ここ使うのやめたは

固定資産税支払いのついでに記帳しようと思ったのに、こりゃ今日はムリか

あんな規模がでかい銀行で１０００件程度の解約で止まるんかｗ
１０００件も定期振込解約なんてでねーよってあぐらかいてたつけだわ戯けが

結構昔に作り込んでて、当時はあんまり件数がなかったからこんな仕様になったのかな

ついに、表に出てきたね。ＩＴに弱い企業は現代ビジネスには対応できない。

このまま行ったら、順調に日本の全産業は衰退するよ。

>>216
いや、業務アプリなら普通にありえるから、SEが作った仕様かもしれない
レビューで確認してなかったらアホだけど

Excelマクロの終了判定にデータなしの行数とかなら解るんだが
DBの読み込みをEOFまでやらんとかありえないだろｗ

これって普通に仕様バグじゃん

数分で終わる処理だろうから、その瞬間は気づけないだろうなぁ。

>1000件連続で「データなし」と確認すると、終了する仕様

こんなのダメじゃん
誰が承認したんだよ

1000件単位でサブルーチンに入って、そこの処理に
「処理件数が０件の場合、該当データなしで処理を終了する」
とあると、客は全件数０と読み、設計担当はサブルーチン終了のつもりで
PG（＝テスタ）はプログラムの終了と解釈した場合があるな、うん、あるわ

昔から使いまわしてる仕様書、こういうのあるある

給料遅れた人もいただろうな。

>>195
今回の件で対応入るから、流石にそれは無いかな。
でも 1001件でしたら、また発生するかも(笑)

>1000件連続で「データなし」と確認すると、終了する仕様
1000件に何か意味あるのか？ないだろ。
どんでもない仕様にしたもんだ。

面白いじゃん
システムエラーとかじゃなく定義したとおりに動いた結果だろ？ｗｗｗ
笑えるｗｗ

貴様

今回のと違うけど、昔使ってたシステムは商品マスタとか顧客マスタとか削除するとそれぞれの削除情報マスタに
商品コードや顧客コードが記録されるんだけど、それの上限が千件（その日の夜のバッチ処理が終わったらクリアされる）で、
ある日商品マスタの整理で昔に廃番になった商品のコードをバンバン消してたら削除情報マスタオーバーフローしたので、
応急処置として登録し直すというウンコみないな処理をさせられた。

これはシステム設計者側のミスだろう。
システム要件として千件連続で「データなし」なら残りのデータを処理しないとかありえない。
サブルーチンが千件単位に処理してるからサブルーチンの処理を終えるだけのはず。

実装途中で設計書に処理終了のメッセージがないことに気付いて
あわてて定義しました、的なクソ設計だな。
メッセージとデータを同じラインで処理するなよ。

1000件取ってきて
1000件チェックしてからデータ無しと判断する必要性がわからないな

>>12
JAバンクのATMからなら引き落とし無料だよ。

まだ、120バイトの全銀データ使ってるのかなあ

>>251
サブルーチンの終了とメインルーチンの終了を混同したっぽいね。
読み違えた仕様でコードも試験仕様書も作ってしまったのかな。

横文字の会社はコレだから困る
責任感の欠如
お偉いさんが適当につけた会社名だから
業務も適当

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　1000件単位でデータ送りますね。あと全部空データだったらついでに終了フラグも立てといて下さい。
＼
　 ￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　 （　・∀・）　 ∧ ∧ ＜　お前の人生も終了だｺﾞﾙｧ!!
　（　　⊃ ）　 (ﾟДﾟ；)　　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣ （つ＿つ＿＿
￣￣￣日∇￣＼| BIBLO |＼
　　　　　　￣　　　=======　　＼
.＿＿＿＿＿＿＿＿＿

またか。

すごい昔のエクセルのマクロだとそういう処理してたこともあった
1000件空行が続いたら処理終わりみたいな

ここって合併した時に政治的都合でポンコツシステムのほうを
使うことにしたんだっけ？

ちょっと前に三井住友のＡＴＭが半日くらい止まったし
日本の技術ってすごいね。

昔のATMってめいんめもりー8kだったんでしょ

昔の処理の遅いコンピュータなんかだと、こういった処理してる場合あったな。
空データを最後まで読み込んでると時間がかかるとかでさ。
ファイルやレコード長が固定長だった時代。

ここ最近
土日でＵＦＪの店舗でなんかやってるけどあれは関係ないのか？

こういうの使う人は家賃振込以外に
サラ金への定期返済とか
財形感覚で別の口座に貯金とか。

そりゃ、毎月末の振込金額は3月31日のと4月1日のは消費税5%と8%で金額違うから
修正入るのが多数で前月まで通りが少ないのは当たり前。

システム担当者はちゃんと見直さないと2015年10月末に消費税が10%になった場合
同じ事が起きる可能性が高い

>>155
だいたいアヤしい処理の場所が見つかったら、
人身供養にスキルなさそうな派遣を投入する
半年ほど稼がせてあげて、ウラでは「あの派遣が触ったから」
でその派遣会社を出入り禁止にして終了。

派遣じゃなくても人事に影響しない外注に仕事を持たせればＯＫ

eofまで全部やるだろ普通は

>>268
なるほど、そうやって責任転嫁して30億円分の客の信用を失う事を
屁とも思わない体質が上海Ｆにあるのかよｗ

金融庁の事績管理簿の保管機関は３年。

>>223
家賃支払いや養育費、仕送りなどの定期的な振り込みだろ
３月が移動時期だから家賃の振り込みの解約が多い
あと、店舗、駐車場などは消費税値上げで一度解約して値上がり賃料で再度契約するから解約が多くなったと推測

>>1
千件連続で空とか解約は前のシステムデータが異常の可能性あるから止めて点検するという運用はあるかも。
合併とかで運用ノウハウが消えてたかねぇ

10000件にすればさすがに大丈夫だろう。0一個追加しとけ。

夜間バッチなのか？

オンラインバッチにすればいいのに、

また富士通か

前に勤めてた会社のメインバンクが三菱だった
末日に振り込み出来ないなんて地獄だｗ
せめて年度末じゃなかったのがまだ救いか

1000人の人が解約したってことか、来月は残りの2万3千件も解約してるだろうから、システム自体必要ないな、もう。

ぬるぽ

これが原因で不渡りとなった場合、
金融機関の責任はどうなる？

　
想定外？
素直にバグって言えばいいのに。
保身は醜いね。

仕様通りに停止したんだから仕様書作ったやつがアホ。
つまり、頼んだ側がアホ。

でも実際ケツ拭くのは作る方。

処理は何のエラーも出さずに正常に終了してたから、現場から指摘されるまで全く気づかなかったのが実態。

わろた
仕様作ったやつがあほだな

仕様をつくったのが銀行であれシステム会社であれ
ここまで障害が多発すると、
銀行側の管理がザルであることは疑いの余地がないな

こんなの普通はプログラミング前に仕様をチェックする時に気づくと思うんだが

なぜ普通に全件処理して終わらなかったの

実作業は上海ってマジなの？

＞１０００件データなし、で終了

無限ループ対策かな、次は処理が終了しないトラブル発生だな・・・・

エラー件数カウント変数三桁にしただけじゃないの？
1000件ずつなんだから

で次の1000件処理にいかずこけた

MUFJのスローガンは「Quality for you」
これで「Quality for you」かwww

MUFJとか訳の分からん会社名にしたりともうね・・・
誰が責任取るんでしょうね
システム屋？派遣社員？
お客に対してはうやむやにして終了？

>>270
たぶん、それやってるのは銀行じゃなくシステム担当の会社

>>291
MUFGなｗ

Jってなんだよｗ

さすがに1000件連続該当せずはねーだろ、こんなんあったらデータがおかしいかバグだからシステム止めるわ。

と思ってたら普通に1000件連続しちゃったわけか。

仕様が酷いｗ
大昔の遺産か何かか

これって、どっちのシステムを引継いだんだ。
日立だったらやりかねないな。

此奴等、ジョブの実行中エラーになるとアベンドさせたがるから。

アベンドどころかエラーすら吐いてないよ。全くのノーマルエンド。

本題とは関係ないのだが、
数年前、サマータイム導入が騒がれたとき、やらなくともいいシステム変更で
金融とか化学プラント、原子力プラント等々で問題が発生する危険性が指摘された。

推進派の自称システムの専門家の書いたものを見てのけぞってしまった。
「確かにシステム変更には危険性があります。例えば交通信号の切替えタイミングです。
でも、面倒だと言っていたら何もｊ始まりません。」
金融システムとかに全く触れていなかった。

>>214
COBOLだと、1024件はめんどくさいと思う

三和のシステムでよかったのに…

>>8
みずほ
手作業(?)で対応しようとして、更に泥沼。

>>274
嫌がらせで1万件振込解約すればいいんですね。

みずほグループ：勘定系システムの保守を大連で

エイチテーテーピーコロンスラスラitpro.nikkeibp.co.jp/article/COLUMN/20080318/296461/

三菱のシステムも中国で保守してんのかな

システムを中韓に外注するって世間知らずにも程があるｗ
責任者は首になりたいのか？

こんなとこかな？

public class MTU20140430 {
　　public static final int SUB_RECORD_MAX = 1000;
　　
　　public static void main(String[] args) {
　　　　boolean[] aryRecord = new boolean[64162];
　　　　for (int i = 0; i < aryRecord.length; i++) {
　　　　　　aryRecord[i] = true;
　　　　}
　　　　for (int i = 42000; i < 43000; i++) {
　　　　　　aryRecord[i] = false;
　　　　}
　　　　
　　　　int nRecordIndex = 0;
　　　　int nSubRecordIndex = 0;
　　　　int nSubRecordCount = 0;
　　　　int nProcessCount = 0;
　　　　while (true) {
　　　　　　if (nRecordIndex < aryRecord.length) {
　　　　　　　　if (aryRecord[nRecordIndex]) {
　　　　　　　　　　nSubRecordCount++;

　　　　　　　　}
　　　　　　　　
　　　　　　　　nRecordIndex++;
　　　　　　　　nSubRecordIndex++;
　　　　　　　　if (nSubRecordIndex < SUB_RECORD_MAX) {
　　　　　　　　　　continue;
　　　　　　　　}
　　　　　　};
　　　　　　
　　　　　　if (nSubRecordCount == 0) {
　　　　　　　　System.out.println("bye");
　　　　　　　　break;
　　　　　　}
　　　　　　
　　　　　　nProcessCount++;
　　　　　　System.out.println("process subrecords " + nProcessCount);
　　　　　　
　　　　　　nSubRecordIndex = 0;
　　　　　　nSubRecordCount = 0;
　　　　}
　　}
}

途中で切れてるし馬鹿っぽいしｗ

>>17
仕様書ってプログラミング中や終わったあとに作るアレのことか？

同行でも振り込み手数料かかるように改悪されたから
解約者続出したんだろ

そもそも仕様がおかしいんだが

>>307
関係者の方()ですか？

>>309
>そもそも仕様がおかしいんだが
書いてて思ったが、仕様ミスってよりも、
コーディングミスだろうね

振込み手数料よりも自分の口座に入金するのに手数料掛かることになったから大量解約したんじゃねｗ

血税で倒産回避して

儲けまくって

還元せず

このザマか

いいかげんにしろよ

サラ金の親玉

無限ループ防止しようとしたら失敗したの？

月末定額送金なら家賃、駐車場代、月謝、仕送りとかかな

>>313
無限ループ防止の失敗でも、間違いではないが、
終了条件の誤りと言うのが適切

>>310
1000件も連続して失敗するのは
どっかおかしいかもしれないから確認しろよ

って意味で止まるのかと思った
止まった時に内容確認して、問題がなければそのまま手動で継続判断下すとか
という事で、オペレーションミスかと思った

送金元口座の残高不足、停止手続き無しの送金先口座の解約等が4月という事で多発したっぽいね

>>305-306
かなり低級なコードだなｗ
1000件連続で「データなし」と確認すると、終了する仕様だったらPGの実装はこんな感じだろ。
そんな無意味にカウンタやらwhileやら使ってたらコードレビューでボツるわ。

for(Data data : datalist){
　if(data.isEmpty()){
　　emptyCnt++;
　　　if(emptyCnt >= EMPTY_SEQ_LIMIT_1000){
　　　　terminateFlg = true;
　　　}
　}else{
　　emptyCnt = 0;
　}
}

698 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:14:03.90 ID:YhFxGRGq0
アメリカ人の言う自己責任と
中世バカジャップの言う自己責任は根本的に異なる
儒教と権威主義の思想に基づいて、国民を黙らす魔法の言葉として
「自己責任」という言葉を意味も知らず使ってるだけ
アメリカ人がなぜ銃で武装できるか知ってるか？自己責任だから
自己責任ならばアメリカのように国民個人が武装する権利を認めよ
それができないならばバカジャップ政治家の言う自己責任は上記の意味だということ
701 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:20:19.32 ID:HjN7vZiI0
限界超えるの忍耐←ん？くやしかったの？←なんかこれはいまないらしいとこがむそ

ちょんころ時事でそうざらえでセンテンスざらっと変わる、なんかそんな電動掲示あんなん。
702 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:21:22.00 ID:HjN7vZiI0
じわじわ理解されたﾈ
703 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:22:22.49 ID:HjN7vZiI0
しかも三角じゃねあれ。
705 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:23:23.32 ID:HjN7vZiI0
とら
うま
うし

どれかﾁｪｷんのはゲイン。
706 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:24:53.72 ID:HjN7vZiI0

な、１０月なんにあたる？
707 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:25:07.71 ID:YkJhrObm0
そうですね東電の人にそう言ってください
よしこちゃん
708 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:26:14.22 ID:HjN7vZiI0
たつ
しか
おおかみ

こう？
709 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:27:19.68 ID:HjN7vZiI0
ししか。ししつてもいにしえのししは。
710 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:28:54.80 ID:HjN7vZiI0
あとまあ　あまりこのお　もぉ〜
711 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:29:57.17 ID:HjN7vZiI0
日本会議思考な。かもりやすくはなるはず。
新着レス 2014/05/04(日) 01:30
712 名前： 番組の途中ですがアフィサイトへの転載は禁止です 投稿日： 2014/05/04(日) 01:30:58.17 ID:HjN7vZiI0
ばりばり転載してきますは。

>>316
そういう意図があったかもしれないよな。安全志向で良いともいえるよね。
直しちゃって大丈夫かね。

仕様通り動いただけなのに怒られてる末端派遣バイト君かわいそす

汎用機のシステムって独特の運用してるから関わりたくないわ
エラーが起こったらそこで全部処理止まるとか聞いて恐ろしい
だいたい今のオペレータがコマンドなんか打てるんかね？
写真つきの手順書見ながらでも失敗して電話してくるアホだらけだぞウチの現場

Ｃでいうところのループをcontinueするべきとこにbreak書いて脱出しちゃったとか？
じゃなきゃわざとへんなループ制御フラグの使い方でもしないとおきなさそうなのに

PGバグだったら「プログラムの不具合」と書く
仕様と書いてるからには仕様バグだよ

んな複雑でもない仕様どこの低級PGが実装間違えるんだよ

年度末な３月末までって振り込みが結構多くても不思議はないもんな。

>>236
総件数じゃない。
連続だよ。

>>325
ってことは、仕様として要求したチェックロジックか
じゃあチェックロジックで正常にとまったのにオペミスってことなの？

>>291
見られるもんなら当該PGソース見せてみろとかいいたいがw(COBOLでもバッチ位なら読めると思うw)

>>323
詳細な手順書使ってミスするのは、手順書書いたやつのセンスがない（無意味に詳細）か、
わざとそういう風に書いたに決まってる。

1000件で打ちきりってテスト用の仕様くさいな。
テスト終了しても忘れて本番コードに直さなかったらこうなるだろう。
バスの手配忘れと同じだな。

>>330
確認しろって書いてあるのに、確認しないで確認済みボタンを押した糞オペレーターが居たw
システム障害起こして首になったけど

>>328
＞この時点で処理が仕様通り終了してしまい、
って書いてあるしね。

「1000件連続で空だったから途中で処理終了した。これは仕様通りだからテストOK！
「OKじゃなかった…
　1000件連続で解約の場合を考慮してなかった…（所謂、考慮漏れ）

という話だから、プログラマにもテスターにもオペレータにも罪はない（と読める）

>>328
すごーーーい昔に、例外処理みたいな感じで書かれていた仕様で、調べたらわかった。って、感じなんじゃなかろうかね。
そんな仕様だとは今回の件で調べる迄、誰も知らなかったみたいな。

>>333
考慮もれってか、なんでそんなロジックが要るのか理解できない
>>334
ステルスロジックかよ

三菱東京UFJ銀行に定期自動振込機能なんてあったの！？
一般人も使えるなら、やり方教えてー

>>332
まあそのオペレータに問題はあるにせよ、
そういうのも手順書の言葉の表現一つで大分違うと思うんだよね。

なんで1000件連続が「解約」だと処理終わっていい
っていう仕様なの？

>>331
あるある

>>330
相手に説明するのに不必要なレベルの所まで書いたり言ったりして
無駄に相手混乱させる奴いるな

明らかに焦ってるっぽい相手に郵便局の場所聞かれて
場所だけ手っ取り早く説明してあげればいいのに
最近駅前に大々的な工事が入って、それでコンビニが今仮移転してて、であっちがあーで
で郵便局は元々はあそこにあったんだけど今は〜的な
駄目な意味で几帳面な知人がいる

1000件連続で「データなし」か。
で「データなし」＝「解約」か。

1000件連続にしてるのはつまり末端がないってこと？
末端があればExcelみたいに上からと下からみていくもんね。

>>338
関係者じゃないから知らないけど空データが解約以外の意味も持ってたんじゃないの？
バリデートして不正データだったら空っぽにして送ってたとか。
不正データが1000件も続いたら異常だから止めとくか、みたいなノリでロジック入れたけど
解約の時も空っぽで、解約が1000件続くというのは頭になかった、的な

なんだよ事象って
普通に事故、トラブル、ミス、失敗だろ
なんかうちらは関係ありませんよーシステムがこうなったんでねー
みたいに言いやがって

>>341
なるほど、それが正解っぽい。
1000件連続解約が想定外って、設計した奴最悪のアホだな。

終端の判定が1000連続データなしってしなきゃいけない事情と
解約を解約じゃなくデータなしって扱いにした事情がわからん

素人考えでは
総件数をもらう
データ終端の目印をもらう
解約はデータ無し扱いしない、データ無しが来たら即終了
のどれかが妥当な気がするんだけど

データはもともとあったが消されてデータなしのレコードになった、と考えるのが自然。
データがもともとないなら１件としてカウントする必要すらないわけで。

なんでデータなしが１件でカウントされるのかがポイントだと思う。

なんでデータなしが１件でカウントされるのか？

ひとつは「解約データ」の場合データが空っぽになるから（なんでそんな仕様にしたのかは知らんｗというかこれが仕様バグだろ）

で、実はもうひとつデータが空っぽになる条件があって、
それが続くとシステム的にまずいと判断できるから

まずいと判断したら処理を中断するという仕様にしたはいいが
「解約」と区別がつかなくなった、と。こんなところか。

契約情報と解約情報でソートされてる前提だったのか？

ああ、>>24こういうことか。あるな

>>318
多分、君みたいなおっちょこちょいがPGだったんだろうね
三菱も災難だな
ツッコミどころ満載過ぎて、疲れるわ

>かなり低級なコードだなｗ
話を元に、悪いコーディング例を想像で再現してみたのですが？

>1000件連続で「データなし」と確認すると、終了する仕様
既に書いたが、仕様ではなく、コーディングミス

広報が素人に分かり易く伝えるため、
または単純なコーディングミスをもっともらしく釈明するため、
「仕様」と言ってるだけだろ

君もそれを真に受けて、バグありきのコード書いてどーすんの
普段、他の人の話、ちゃんと聞けてる？

>そんな無意味にカウンタやらwhile
どこが無意味だかイミフ

実際のコードも、書いた本人にしか分からない、
君が書いたような、独りよがりのコードだったんだろうね

PGが「これで大丈夫なんです！」とか「動けばいいんでしょ？」とか言い張って、
レビュー担当者も、読むの嫌になって、スルーしたんだろ

>>349
多分違うだろうね

>1000件単位で契約内容をチェック
>1000件連続で「データなし」と確認すると、
から察しろと

1000件エラーで打ち切るとか、
仕様書のどこにも書かれていなかっただろうし、
PGも、そんなコードを書いたつもりは無かったのだろう

>>350
売り言葉に買い言葉にしかなってないし
何も説明できていない

使い物にならんな

>>351
1000×65←例えばこの65が1つのファイル単位とかだと、1つでも空ができると都合悪いって事に思うけど
まあ、偉そうに講釈垂れたって所詮妄想にすぎんよ

>>352
「何も説明できていない」ってのは、
君の>>346や>>347の事ですか？

>>354
いいからお前は現場でクビ切られとけ

>>353
おいおい、65は、64162÷1000の結果だろ・・・

>>355
こーいう、技術を感情で語ろうとする奴が
メンバーに混ざってるのが、一番困るんだよな

>>356
そうだよ。その上での話してんのに、どう読んだわけ？

>>357
？
正直イミフ

プログラミング言語の前に、
日本語勉強してくれって感じ

普段、他の人が読んで分かるように、設計書書けてる？

どう見てもめんどくさいのはID:uoHBw4kg0
こんな技術も人格もレベル低い奴絶対いらない

ん？？　ほんとうにそうなんか？？

6万4162件のうち、（1000 x n）+1 件目から連続して「1000件を超える解約があった可能性」
なんてことは考えられないんだけどなー。
別のバグじゃないのかぁ？

>>356
クソコード撒き散らしてロクな解説もなしじゃあクビ切られて欲しいなあ

実際、現場では>>359みたいな、具体的な説明はせずに、
感情論だけで押し通そうとする奴が、なぜかはびこっているから、
ホント困るんだよね

現場は苦労するよ

>>362　日本は９割文系だから、情緒的に判断する。

メルトダウンも２ヶ月も認めなかったし。

>>361
だったら君が分かり易く説明、またはコードを書いてみたら？
いるんだよね、口だけで、自分では何もしない奴w

>>83
TVアニメの攻殻機動隊であったなその設定。
個別の十一人だったかな。

ネタでコード書いても素人は隠せないもんだよ

>>364
ケチなこと言わないで自分であえてクソに書いたコードに仕込まれたコーディング不良ぐらい教えてくれないかな
ここニュー速＋だよ

>>358
1の説明を前提に、例えば
65千件を1000件ごとにチェックし、それぞれを1ファイルに出力する。
出力したファイルが1つでも空だったら困るから落としたっつー話
あくまで例えば。
わざわざ1000件単位にする理由なんぞ知らんから

つーか、相手が何いってるかもわからないのにいきなり>>356ていったの？
思い込みで話を進めるわ、相手をバカにする発言を会話の合間にいちいち挟むわ
そんな野郎にどうこういわれたくないね

どうせ、この1の説明だって本当かどうか疑わしいし
単純バクだったとしても、企業としてはそれらしく説明するしかないっつーのに
あほらし

ID:uoHBw4kg0
思い込みが激しい
攻撃的
ネタでコード書いても低スキルバレバレ
説明できない
アホなくせに高圧的


話になりません
単価０円

>>367
1行、終了条件を修正。

if (nSubRecordCount == 0) {
　↓
if (nSubRecordIndex == 0) {

>>369
技術が無いから、感情論だけで相手を責めるしか無い
うん、正直、有能なリーダーになれると思うよ。イヤミ抜きで
実際、こーいうのがはびこってるし

ニュース系のスレでいきなりコード書き始めるような
空気の読めない人間には何言っても通じないから無視しれ

ろくに金を貸さない、決済もミスって銀行としての存在価値があるの？
被害にあった人への謝罪と説明くらいはちゃんとやれるの？

>>371
技術がないのはバレバレだから無理すんな

Java覚えたてか？J2EEわかる？Strutsは？
リモートシェル書ける？PL/SQLぐらいは書けるんだろうな？

三菱東京UFJ銀行騙ったフィッシングメールの量がすごいんだがｗ

>未処理だった約2万3000件について、送金ができなかった。

未処理となった件数は、正確には2万3162件か？
もしそうだとすると、6万4162件のうち、 4万1001件目から4万2000件目まで連続して
1000件の解約があった、ことになる。

データを見れば判明するはずだが、こんなことは普通は考えられないな。

マスコミが全く報道しない事実

・去年パスワードを要求する偽メールが来たので
　三菱銀行に連絡したが、無視された
　今年になって被害が拡大してから大騒ぎしている

・俺の定期預金が消失したｗ
　調べ直させたらコンピューターのミスだとわかった
　三和の定期預金は調べ直させたほうがいい

>>347
解約と解除の区別も付かない奴が銀行系のシステム語っちゃアカン

>>376
普通はそうだけど今回のは税率が変わって初回の月末だから
確率はアップしてる
現実的に起こりうる確率までアップしたかはわからない

>>376(訂正と追記)

>未処理だった約2万3000件について、送金ができなかった。

未処理となった件数は、正確には2万3162件か？
もしそうだとすると、6万4162件のうち、 4万0001件目から4万1000件目まで連続して1000件の解約があった、ことになる。

データを見れば判明するはずだが、こんなことは普通は考えられないな。
別の原因とみる。

1000件と聞くと、どうしてもコミット件数を連想してしまう

三菱がＩＢＭでＵＦＪが日立だったかな？
やっぱＩＢＭ互換機でも上手くいかんわ

>>83
>>365
そうか。
攻殻の2ndGigでクゼヒデオがこれで核爆弾買う資金作った。
よくできたネタだなーと思ったけど、やっぱり元ネタあったか。ありがとん。

>>367
教えを請いておいて、スルーかい？
程度が知れるわ

>>372
いきなり？
2、3日経って、だいぶ落ち着いてきたとこだと思うけど？
あと、君も無視できてませんよw

>>374
君、大丈夫？
話が拡散してるぞ
餅つけ

>>1
> このチェック処理は、1000件連続で「データなし」と確認すると、終了する仕様となっている。

？？？？


誰だよ　こんな　馬鹿な仕様　決めた香具師はｗｗｗ

まあ1000件連続で解約が入るとは思わんな
ただ、解約とデータ無しを同一に処理するようなプログラム使ってんなら他も怪しすぎる

花咲舞が黙ってない
杏と上川に臨店させよう

>>370
なるほど
1000件のうちデータ有りかどうか判定した件数が0になったら終了ってすべきを
データ有り件数が0になったら終了ってやっちゃったんじゃないかって予想か

であれば普通はあらかじめ総件数がわかってるなら>>305-306みたいにはしないけど
こういうところで作られるプログラムだと無くはないねえ、困ったことに
これやられると単体テスト以降の工程で弾くの難しいね

銀行は１円合わなくても行員は帰れない、なんて都市伝説が木端微塵だなｗ
30億円が闇に消えるようなズサンな会社は聞いたこともないｗ

>>385
1000件連続でデータ無しだったら処理停止ってのは安全対策としちゃ理解できるぞ
別のバグでデータ無しを入れるような自体が起きても、それが1000件続けば自動的に処理が止まってチェックが入るから早期発見につながる
解約とデータ無しを一緒くたにしたのが間違い

>>388
そういうこと
まぁ、実際のコードを見てないわけだし、
あくまでも俺の予想というか、妄想に近いけどね

ずいぶん幼稚な仕様で組んでるんだな
関係者は全員知的障害としか思えん

３月までの契約が多かったってこと? 年度の切り替え月だから。

> このチェック処理は、1000件連続で「データなし」と確認すると、終了する仕様となっている。

素人の設計だな。
クビでいいよw

>>385
データの終端判定方法がそれしか無かったのか
データ異常検知のためのものなのか
プログラムのバグを仕様ってことにしたのか
今出てる情報だけでは判断できない

>>391
> >>388
> そういうこと
> まぁ、実際のコードを見てないわけだし、
> あくまでも俺の予想というか、妄想に近いけどね

勘定系のbatchだろ

ｃ系なわけねーよ

>>396
だろうね
あくまでも、説明用の妄想コードと捉えてくれ

妄想コードはなんとなくわかったから
俺の29億円を現金で今すぐ返してくれ

円預金はせっせと下ろしとけ。
ドル・ユーロの現金がオススメ。

バッチの処理対象を絞り込む段階で解約を除外しておけばこんなことにはならなかった
sql一行で済む話

何かのトラブルが発生している可能性があるからチェックしてくださいって意味で1000件連続データなしだと終了するんだろ？
なのに終了した物を正常終了だと勘違いした馬鹿がいたって事じゃ無いの

>>52
時々共産主義国家の銀行網体制かとゾッとするような笑いネタがあるよなｗ

だんだん思い出してきたぞ、チェックポイント・リスタートとかあったな、ＪＣＳとかいうのもあった
まあ単純に言えば今回のはただのバグ、何十年も一度も通らない分岐だっただけ

これ、場合によっては不渡り出して潰れるところもあるんじゃねえの？

>>332
日時点検でPowerLEDが点灯してることを指さし確認って手順があって
電源ボタンにLEDが付いてるタイプのサーバーの電源ボタンを勢い余って押したオペがいたのを思い出したｗ

解約されたデータではなく解約された可能性のある異常データが連続1000件続いたとある
アプリのバグ、顧客への継続確認が出来なかった運用不具合等あると見なして中断したんだろうね

つまりEOFの判定が1000件ゼロデータって事か。せめてゼロ、イチ交互1000件にすれば。

>>405
wwwww
おバカだと思うが、わからなくもないなw

SE由来の仕様バグかPG由来のPGバグが仕様になったか
どっちかしかないからオペレータに罪はない

>>406
>>347で合ってたってことか

＞解約された可能性のある異常データ
解約の正常データじゃなくて”可能性のある”異常データってことは
バグのニオイがしてきたね
処理中断ロジックとは別のところで

みずほに続くのか
UFJはHPが爆発しそうだしな

http://www.bk.mufg.jp/index.html

ダッサイプログラムだな
来年のなんかの試験の論述試験に出るんじゃないかってなぐらい頭痛が痛い案件

恐らくは送金先の口座が解約されたのに送金元の顧客が停止又は変更手続きを三菱東京UFJに依頼しなかったか送金元の残高不足に加えて利用履歴がない等あり(これまた顧客が停止手続きをしなかった)のではないかと思われる
それが連続1000件続くという事はある意味異常な状態ということで抽出アプリのバグか判断がつかない為終了させたのではないかと

郵貯が一番。

>>412
＞送金先の口座が解約されたのに送金元の顧客が停止又は変更手続きを三菱東京UFJに依頼しなかったか

そういうケースって普通は「エラーコードxxx送金先の口座がみつかりません」とか
「エラーコードxxx送金元の残高が不足しています」とかなんとかエラーメッセージをセットして
どういう種類の異常データかわかるようにしておくよね。

異常データというのはわかるが「解約かどうか確証持てない」なんて仕様はお粗末すぎる。

＞まずいと判断したら処理を中断するという仕様にしたはいいが
＞「解約」と区別がつかなくなった、と。こんなところか。

多分だけど、
・その辺考えてた人が仕様完成させる前に居なくなって仕事中断誰も覚えていない。
・追い込みで忙しいからそんな優先順位低い処理は放置しろ命令が出た
・今回間に合わないから次の機会でちゃんとやりましょうという話だけで終わり
・そういう仕様を愚直に実装。

顧客が本当に必要だったもの
ttp://maniyax.net/project_cartoon/project_cartoon.gif

解約フラグをたてるんじゃないのか

安全対策で入れてたんじゃないの。運用の仕方のほうが引き継ぎされなかったん
だろうな。

そういう事。顧客が正式に手続きを踏んでエントリー部門で停止したのは元々対象外で回って来ない。
じゃなくて判断出来ないデータつまりは、エラーになった分はエラーリストとして出力はされるが顧客から正式に解約依頼がないデータばかり大量に連続して発生したものだから不正或いは誤ったデータの可能性もありとして中断したんだと思う。

なんで客が悪いっていう発想になるんだ？その矛先は絶対向けてはいけない方向だと思うんだが？
そんな（正式な手続きを踏まない客もいるという）客の動向も加味した上でシステム構築するのがSEだろ。

どっちにしても解約祭りってことか

連続、大量という事で送金元も送金先も三菱東京UFJ内の同一支店だった可能性が非常に高い
それも1000件連続という事でインターネット支店だったのではないか？何らかの理由により送金先口座が凍結されたがエラーになるだけと思い送金元顧客への通知が遅れた或いは支店側が情報部門に変更、停止依頼を提出忘れた可能性もある。
まあ末日に凍結された日にはどうする事も出来ないのだが、現場での運用上1000件も連続してエラーという状況あり得ない、有るとすればアプリのミス、情報部でのオペレーター操作ミスの方が非常に高いと判断してシステムを構築したんだろうね

>>415
久しぶりに見たら進化してるｗ

Ａ口座からＢ口座への振り込みが何らかの原因で失敗すると、
Ｂ口座からＣ口座への振り込みが（Ｂ口座の残高が上の原因で足らずに）失敗し、
Ｃ口座からＤ口座への振り込みも（Ｃ口座の残高が上の原因で足らずに）失敗し、
と次々と引き落としに失敗する連鎖が起きる。
単にそれだけならまだ良いが、不渡りが起きれば連鎖倒産になる。

>>418
依頼がなければ、解除されずに対象先のままだろうに
頭悪過ぎて、嗤うしかないわ

>>1
統合前のＵＦＪのシステムに戻せばー？（棒

システム作った奴がクソだな
きちんと最後まで読み込めよ
たいして時間かわらんだろうが

>>424
三菱東京UFJの自動送金は無料じゃないのでエラーでも送金主の手数料は引かれし無料を謳っている所でも銀行内部では手数料が発生している
>>1で継続確認が取れなかった云々とあるので何らかのタイミングで銀行から継続確認の通知があっても返答がなかった場合は解約したものして扱う。
例えば送金主が死亡等で解約したくても出来ない状態でも送金が続けられてしまう事とかあり得るよね

MUFGのページ初めて見たが、びっくり三角にでっかい×印、
元々コーポレートカラーが赤だし、ウイルス対策ソフトのページみてーだなｗ
画像含めて文字でびっしりすぎるし、FG本体のホムペでもこれはありえん…。

>>427
アンタ銀行間決済の仕組みも知らないの？

＞例えば送金主が死亡等で解約したくても出来ない状態でも送金が続けられてしまう事とかあり得るよね
顧客から報告のないモノをどうやって検知しろとｗｗ

UFJトラブル多すぎなイメージ

>>240
もしかしたら、昔なにか不具合があって、永久に無効データーを処理し続ける問題が起こったのかもな。
対策として、1000件無効データーが続けば処理を停止するようにした、と。

問題は、俺が仕様だ！
みたいなジョブズ並みの奴が銀行に居ない事だろ。

金や人の命に関わるシステムなんか絶対イヤだお

メインフレームだったら異常を検知したら終了するんじゃなくて、該当ステップでホールドするんじゃね。
それとも本当に終了するのか、それとも記者が勘違いして記事かいてるのかわからんわ。

自動処理なのに手数料盗ってこれですよ。
まぁ、金払って送金依頼してんだから損害請求しないとな。

>>1
これは三菱由来だろ？

>>75
このバージョンは知らんかった

何らかのトラブルと捉えて止めるのはいいが、即座に人為介入して異常の有無を確かめて
処理の継続可否を決めるようにして置けよ。

>>336
信用金庫でもそのサービスあるよ

怖っ((( ；ﾟДﾟ)))

これが仮に例えば株価操作を狙いとした一種の破壊工作
だとしたらどういうことになるのだろうか。

内部犯行

損失補てんのために手数料値上げですか？

三菱東京ＵＦＪ-VISAのサイト見るだけでも技術力低い奴が作ったのよく分かるわ
何か見ようと思ったら通信中ですってなって数秒待たされる
三井住友カードのサイトはもっと早かったぞ

注　こういう事例でもローンの支払いが出来なければブラック逝き

>>117

＞ndefで終了しなきゃいけないところをfalseで終了しちゃってたんだろ？
＞null終了しなきゃけいないのをゼロ終了しちゃったんだろ？

それは絶対ありえない。

あーなんとなく分かった。
最初はこの解約フラグをソートの最優先にしていたんじゃないか。
そうすれば１０００件連続でエラーだったらそこで終了の処理の意味も分かる。
こういう発想はだいぶ昔のものだな。

で、どこかのタイミングで気付かずにソートをいじった。
それが原因か。

>>426
だいぶ違うぞ。
転送もするんだろ。

中国人に作らせた結果がこれだよｗ

4月30日に発覚して5月1日以降は同様の事象は発生しないって
金融のプログラムを1日で直して移行する訳ないし
この処理が動いてる間ずっと見守ってるだろｗ

>>450

１日で直すってそれほど珍しくないぞ。
他に影響が無ければすぐ直す。

>>451
>他に影響が無ければ
これが何よりも難しいのは、ご存知のとおり

>>450の見守る説は有力だな
30億規模のトラブル対応として、そのぐらい普通にするだろ

当分の間は人力で終了確認するんだろうな

金融系のシステムなら24時間つきっきりで、バッチ毎の時間も記録してるもんだろ

鯖落ちとかなきゃ座ってお茶飲んでるだけの楽な仕事。

世のなかの金の大半が銀行にデータとしてしか存在していないという話を聞いたことがあるようなないような

これ金融庁に報告案件だろ
対応策提示して色々と書類作ってそれからプログラムの修正じゃないか？

こういうことが起きるってことは、一日にして預金者の預金が全部
消えてしまうってこともありそうな話だよな・・・

システムトラブルの起きた銀行は避けたほうが良さそうだ

地銀では同一支店内のカード振込で手数料とる銀行があるぞ

トラブルで休眠口座の情報が消えていたり残高が無くなっていても、
直ちには誰も気が付かないね。

>1000件連続で「データなし」と確認すると、終了する仕様となっている

なんという糞システム

>>461
単なるコーディング担当者のやらかしだろ
過去レスぐらい嫁

仕様どおりってあるじゃん
コーディングは仕様どおりで間違ってないんじゃないのか？

過去レスぐらい嫁
何度も言わせるな

>>463
っ>>50,308

俺の口座に1億円振り込まれるとかそういう不具合ないの？

>>464
そんなことか
くだらん

>>466
×過去レス＝>>50,308
○過去レス⊃>>50,308

>>465
会社の口座とかに数年に一度数千万が間違って入ってくることがあるな。
すぐ引き落とし処理されるけど。ｗ

>>466
オープン系の適当システムと一緒にしちゃいかんｗ
現場が思いつきで変更できるような代物じゃないと思うぞ

実態がどうであれ、仕様通りなら話はおわり
最後に作っただろなんて言えるわけがない

仕様どおり
プログラマは何も悪くない

仕様通りって書いてあるのに震えながらPGに責任なしりつけようとする
糞SE大杉ｗ

>>467
だから何？
意味わからん
推奨する過去レスがそれか？

>>472
だから「過去レスぐらい嫁」。
お前の>>463と同様の書き込みは、
既に何人もしている。
今更>>463を書き込んで、何が言いたいんだかイミフ。
再度言う、「過去レスぐらい嫁」。

みずほ「ダメな銀行だな」

>>474
10年後は三菱東京UFJみずほ銀行になってると思うよ＾＾

http://aspeakiyoshi.269g.net/

>>475
そうなったら。タンス預金に切り替えるわ

SEじゃないから実情はよく知らんけど。
某銀行勘定系を担当するシステム開発会社は
『銀行勘定は巨大すぎて一から作り直せるものではない』みたいなことを言ってたような言ってなかったような。

銀行SE仕事は昔やったことがあるが地獄だったなあ。
やらかして契約解除になったが最後の日のすがすがしさときたら
ホント、うれしさを隠す気にもならんかったわwww。

>>478
多分言ってると思うよ。
それで昔のコボルだのアセンブラのソースがそのまま動いてたりしてたから。
離れて三年になるがそう簡単に移行できそうじゃなかったし、
今もそういう状況が多いんじゃないかね。

>>475
りそなぁ

なんでちゃんとバグチェックしないの？
僕夏の８月３２日以降とか

これ、処理がABENDしたのかな？
気がついたタイミングとかきっかけが気になる。

>ところが処理の途中、1000件連続で「データなし」と判定する事象が発生した。

同じＳＥとして、銀行ほどじゃないが請求系扱っている身として、ちょっとこれは同情するわ…
バッチ処理にいくらでも時間をかけてもいい、システムリソース使い放題なんて甘い現実はないしな

単にSEの仕様ミスなのか？

COBOLのプログラムのミスなのか？
セキュリティに問題のあるJavaの問題なのか？

>>485
そりゃあ>>1見る限りプログラムは「仕様通り」終わってんだから
どこからどう考えても仕様ミスだ。

>>486
　　　　 /: : : : : __: :/: : ::/: : :／/: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ　　　　＿＿＿
　　 　 /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::､　 ／　　　　 ヽ
　　　 /ヽヽ: ://: :!:,X~::|: /;,,;,/: :／　 ﾘ!: ::/ﾉ　 l｀ヽl !: : |: : : :l: :l: ﾘ /　そ　そ　お　＼
　　　/: : ヽヾ/: : l/::l |／|||llllヾ,､　　/ |: :/ , -==､　l＼:::|: : : :|i: |　/ 　 う　う　 前　　|
.　　 /: : : //ヾ ; :|!: ｲ､||ll|||||::||　　　 ﾉノ　 ｲ|||||||ヾ､ |: ::|!: : ｲ: ::|/　 　な　思　が
　　 /: : ://: : :ヽｿ::ヽl |{ i||ll”ﾝ　　　 ´　　　i| l|||l”l　｀|: /|: : /’!/l 　 　 ん　う
　∠: : : ~: : : : : : : :丶ゝ-―-　　　　　 , 　ｰ=z_ｿ　　 |/ ﾊﾒ;, :: ::|.　　　だ　ん
　　 i|::ﾊ: : : : : : : : : : : ､ﾍﾍﾍﾍ　　　　 ､　　ﾍﾍﾍﾍﾍ /: : : : : ＼,|.　　　ろ　な
　　 |!l　|: : : : : : : : :､: ::＼　　　　､-―-,　　　　　　/ : : :丶;,,;,:ミヽ　　 う　 ら
　　　　　丶: :ﾊ､lヽ: :ヽ: : ::＼__　　｀~　”　　　　　 /: : ﾄ; lヽ）　　　ゝ
　　　　　　 ﾚ　｀|　｀､l｀､＞=ﾆ´　　　　　　　 ,　　_´ : :}　｀　　　／
　　　　　　　　 ,,､r”^~´””””t-｀r､ _　　-､　´ヽノ　＼ﾉ　　　／　　　　お ・
　　　　　　　,;’~　　_r? ､__　　　　　~f､_>’､_　　　　　　　　 |　　で　　前 ・
　　　　　　f~　　,;”　　　　　~”t___　　　　ﾐ､ ^’t　 　 　 　 　|　　は　　ん ・
　　　　　 ,”　　,~　　　　　　　　　ヾ~’-､__　ﾐ_ξ丶　　　　　|　　な　　中 ・
　　　　　;’　　,ｲ　.. 　　　　　　　　　ヽ_　　 ヾ､0ヽ丶　　　　l　　　　　　　　　/
　　　　 （　;”:: |:　:: ..　　　　　　　　　 .｀,　　 ヾ　丶 !　　　　＼＿＿＿＿／
　　　　　;;;; :: 入:: :: :: 　 　　　l｀ｰ-､　　 ）l　　 ヾ　丶
　　　　　”~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　 ヾ　丶

昔、UFJ銀行ってのがテレビCMバンバン流しててな。。そのキャッチフレーズが

「UFJ銀行は中国に進出する企業を応援します♪」

だったんよｗなんて言うか無責任きわまる銀行だったよな・・。

ミスした奴の説明や言い訳を、100%鵜呑みにしちゃう方がどうかしてるって事
まさか、○○方さんの言ってる事を、そのまま信じちゃってるわけ？
今回の件の場合、仕様と言いつつ、誰一人「仕様書に書いてある」とは言ってないとこがポイント

公表内容自体の真偽が問われているSTAP細胞と同列にするのは暴論だろ
トラブル自体は起きているんだからそこで嘘をつく必要はないわけで
そこを疑い出したらキリがない

1000件連続でデータなしがあって終了させる仕様だとしてもアラート上げろよ
アラートの内容精査してから途中から再実行させる仕様なら納得するが
そこで止めてそのままスルーするのはおかしい

>>479
唯の無能じゃんｗ
何やらかしたんだか知らんがさ

>>490
仕様≠仕様書

似たような案件に携わった事がある

蔵：ウチの処理で流石にxx件連続とかありえんやろ、そこまで連続したら不自然やし不具合疑うから
xx件連続したら確認できるようストップかけるように作っておいて

俺：まぁタスク止めずに確認できるよう作る事もできますけど、そうおっしゃるようでしたら
そのようにいたします

納品後
蔵：おい、てめえのとこのシステム〜件連続したら勝手に処理終わるじゃねーか！！！

>>473
ますますわからん
もう話しかけないでくれ

>>491
「1000件データ無し」を番兵にする仕様なんだからワーニングあげちゃ駄目だろうが。
日次や月次にバッチ処理の正常終了でお前は一々ワーニングあげるのか？

しかし、今回の障害はどうやったらガードできたのかねぇ。
ちゃんとEnd Of File／End Of Dataを送信・取得しない元々の仕様がおかしいのは確かなのだけど、
そうしていないって事は連携先のシステムか処理が真っ当なデータ終了の状態を
送ってこない、送ってこれない事情があったって事だろ。

根本的には銀行がデータ送信側だか作成側のシステムの改修費用けちって
今回送金失敗しちゃったシステム側で小手先の対処行わせたのが元凶だと
しか思えないんだけどねぇ。

まあ銀行側としたら難癖つけてSI部門の子会社とSE会社に責任おっかぶせて
自分たちの責任である事すら自覚しないで逃げちゃうんだろうけど、金融庁
とかがいつまでもそういうのを許している限り（銀行自身に責任取らせて
当事者意識持たせない限り）この手の障害は何回でも繰り返すんだろうね。

どう考えても現場（SI子会社、SE会社）で回避出来る問題ではなく、
銀行自身の判断して出費を決断しないと回避できない問題だからねぇ。

>>496
>「1000件データ無し」を番兵にする仕様なんだからワーニングあげちゃ駄目だろうが。
>日次や月次にバッチ処理の正常終了でお前は一々ワーニングあげるのか？

駄目な理由がわからない
俺ならワーニングあげる仕様を勧めるな
クリティカルメッセージじゃなくてワーニングだからな
正常終了でもワーニングあげるバッチなんてやまほどあるが？

レビュワーが悪い

処理対象件数と処理済み件数とマッチングしないのに正常終了とは納得いかない

自分たちへの信頼が想定外な状況なんだってことに気付いてほしいな。

だーからABENDどころかエラーすら吐いてないっつの！
完全に正常終了で処理終了！
おかげで現場から指摘あるまで全く気づきませんでしたとさ！

てへｗ

>>495
過去レスすら読まず、
>>1だけ読んで思いついた感想を、
条件反射で書き込むなよ

どうしてもPGのせいにしたい奴がいるようだが
銀行系のシステムなんて、アホみたいにガッチガチのウォーターフォールモデルなんだから
PGが仕込んだバグが仕様になりました、なんてのはまず有り得ない。

誰が仕込んだっていう話ならSEしかおらんのよ。

>>503
それを言い出したら、
「1000件データ無し」が番兵となって正常終了
なんて事が仕様書に記述される方が
もっと有り得ないだろ

>>504
よっぽど小規模システムしか携わったことがないようだな。
大規模銀行案件では細設計レベルでそこまで普通に記載されているよ。

設計書さえあれば製造できるところまで落とし込まれている。
そんなレベルの詳細設計を見た事も聞いたこともないという
低レベルなSEに話しても信じないだろうがね。

ある日東京上空で、EMP爆弾が爆発して、それにより生じた強烈な電磁パルスで、
半導体製品や通信回線は全滅。もちろんコンピュータも。大量のデーターも
消えて、。。。。そのあとどうやって復旧する？
莫大な復興ビジネスチャンスはあるけれども。

>>506
東京、千葉、大阪、沖縄にバックアップセンターあるから

>>506
災対サイトの知識もないのかよ
んなヤツがこんなスレでとやかく言うな