【COBOLから】バッチ処理【Javaまで】

>>112
悩んでるならSpringBatchとか見てみな、ヒントにはなると思うよ

SpringBatch見たところ、別プロセスにせず別スレッドとしているようですね。。

オンラインバッチ作るときは、直接Shellコールではなく。
ＪＯＢテーブル実行依頼テーブルのようなものを、監視するデーモンを用意して
各ＪＯＢは別スレッドとして動かした方がいいのかな

Javaだけで完結してるならスレッドでやればいいと思うが、
バッチ処理はJNIとかも使う要件も出るものだから、
VMを保護するためにもプロセスで分けた方が安全だと思う。

VMを別にするとなると直接シェルキックですかね・

リカバリの一般的な方針は？

リアルタイムバッチか定期バッチかによって変わってくるとは思うけど、外部I/Oのポイントでのバックアップは必須じゃないかな

基本的に１バッチ処理で、１トランザクションとすれば
リカバリは簡単？

COBOL誕生50周年
http://iiyu.asablo.jp/blog/2010/05/25/5111701

RDB使うならバッチは基本的にストアドだろ

>>122
いや、分野や規模によるぞ。裏で定期バッチは意外に多い。
歴史が長いから、細かいテクニックも知られてるし。

ObjectWorks+ ってどうなんだ？

COBOLで書けばすべて数十年前に解決済みの問題を、
わざわざＪａｖａで引き起こしては解決、の作業に何の意味があるのか

COBOLでやってきたバッチ処理なんて、
・データ編集
・マッチング
・帳票出力
なんてなもんだと思うがデータ編集とマッチングは
mdbや市販のETLツールで置き換えられるし
帳票ツールもGUIで帳票作れるものに置き換えられるから
それらをバッチファイルで順番に実行されるように組めば
Jaba（っていうか、プログラム言語自体）なんか使う
必要ないんじゃないの？

その変なツール類が、エンハンス停止とかになるので
またCOBOLに戻ってくる訳ですよ。

バッチで帳票出力とか未だに需要あるの？
COBOL→javaが騒がれてる理由はメンテ要員の高齢化でしょ
若いのはCOBOL近づかないしどんどん人がいなくなっていく

官と商社と銀行がすべて無くなれば需要は減るかもな

官庁と銀行は未だに帳票がとっても大好き。
某証券会社など、取り引き明細をわざわざ横型の紙に表裏上下反対に印刷して見易いなぞと悦に入ってる始末。

帳票出力の需要聞いてるわけじゃないんだがな・・・
帳票はあるのは当たり前として「バッチで」必要とされてんのか？

伝統を軽視する奴は許さないよ

>>131
バッチ以外で帳票なんて必要？

帳票てＰＤＦでセキュリティロックして、サーバに保存が普通じゃないのか。

>>131
それはバッチ処理が不要と聞いているのか？
それとも、バッチ処理内で帳票作る必要はないと言ってるのか？
どちらにしても、一処理で何十万件ものデータを処理して帳票イメージを作り、印刷出来るなら、そんな不要になるだろう。
だけど、現状は一瞬で処理して印刷まで完了させるなんて出来ない。

>>133
バッチって、夜間バッチという意味？
画面で印刷指示かけたら、すぐに帳票が出て欲しくないの？

>>134
２、３枚の帳票なら、ユーザーサイドで印刷すればいいけど、何十枚、何百枚単位になってもユーザーに印刷させる気かい？

>>136
そのすぐできる帳票ってどこに出るの？
すぐほしいならユーザーサイドで印刷するよね。
どこかで印刷されるならすぐ印刷する必要はないよね。

バッチで帳票ってのは朝出社したら大量に帳票が印刷されてる感じ？

そんな感じ
印刷された場所と受け取る人が遠く離れてる場合は配布に時間かかるから
出社した時点ではまだ届いてなかったりするけど

配送系とかかな？やっと理解できたわ
帳票はデスクからプリンタの即時印刷ってイメージだったわ

>>137
もう理解できてるかもしれないけど、
ユーザーサイドで印刷するものは、見積書とか依頼書とか印刷枚数の少ない帳票。オフィスに据え置いたブリンタで印刷する。
印刷は、印刷枚数の多い帳票は、大量印刷用のプリンタ。

>>141
誤送した。
最後の行は、郵送用のDMなど、大量印刷が必要な帳票は大量印刷用の専用ブリンタで一括で印刷する。

>>126
まあ、個人のクソ店舗程度ならそれで充分かもなｗｗｗ
その理念で行くと、みずほレベルの損害では済まないだろｗｗｗ

>>131
大量の帳票出力とかになると、大型の高速プリンターでないと無理だろｗｗｗ
何百万件以上もある客先の案内を朝までに打ち出さないといけない時にどうするよｗｗｗ

大型の魅力はマダマダあるんだよ、アンタのクライアントみたいにショボイ企業レベルの考え方では
処理しきれないのｗｗｗ

>>140
ショボイな、何の会社だよｗｗｗ
システム規模の違いで、いや、顧客規模の違いで必要とされているからこそ
コンパクトにできないんだよ、データ件数っていう処理に大きく関わる部分を意外と
ないがしろにしてマシンの処理能力を過剰評価してるから、みずほみたいなシステム要員に
馬鹿が多いんだよ、まあ、ゆとりも障害の要因だよなｗｗｗ

なんか元気なのが沸いてきたな

躁期にだけ動くバッチ処理って役に立たないよな

立たないよね

　　　　 ,,,,.,.,,,,
　　　　ﾐ・д・ﾐ
.　　　　""""

ruby2.0がかなりすごいらしい

バッチって具体的にはどういう処理よ
夜間に大量のCSVファイル加工してデータベースに書き込んだりする？

それだったらメインのシステムと同じ言語使ったりしてもよくね？

メインのシステム自体がCOBOLだろｗ

保守age

そろそろ時代が追い付くか
jBatchと、あとは分散を上手くやればなんとかなる・・・のか？

>>144
何百万件も明朝までに印刷しろとか無計画にもほどあがある。
どこのボンクラ企業だよ。
1週間以上前から言えよハゲ。

>>155
企業によっては月に一度くらいはそのページ数出力して打つとこもあるからな

ここに書いてる人らの置かれた状況（システム化領域）の差をごちゃ混ぜにしてるのをよく分かった。
帳票リアルタイム出力かバッチ出力か、で環境の差を知る。
出す紙の量に従ってシステム組むしかないだろ。

うちにはカード会社や電話会社からの利用明細が毎月届くけど
ああゆうのはバッチ出力して封入封函機で処理しないと
どうしようもないよね。
まあ電子化も進めてるんだろうけどNET使えないジジババがいる限り
なくせないだろうし。

>>158
NTTから引き落としにしないと請求書の発行には金を取るという脅迫文が来た。

>>155
ゴシック体ならいいの？

>>159
ドコモなんて口座振替でも請求書発行には金を取るって言ってんだぜ？ｗ

ずいぶん昔、リモート印刷システムの開発に関わったことがある
一般にはメインフレームには高速ページプリンタをチャネル接続するけど、
このプリンタをUNIXワークステーションに接続して
メインフレームからオンライン印刷するシステム

こうした大量の帳票を印刷するシステムでは、印刷の高速化や部品の耐久性が
重要になるけど、最も難しいのは帳票の重複や欠落を限りなくゼロにする設計だった
印刷処理はプリンタというメカが相手だから用紙切れや紙づまり(ジャム)が起こりうるけど、
エラーを適切に検出/回復し、たとえ何百万件であっても重複や欠落の無い出力が求められる

こうした要求を満たすために、高速プリンタは数１０ページ分のバッファを持ち、
用紙トレイ/印刷ドラム/排紙トレイの様々な箇所にはジャム検出センサが配置されている
またコンピュータとのインターフェイスにも印刷が完了したページ番号を伝える機能が必要
同様にプリンタドライバや印刷ミドルウェアにも対応した変更が必要になる(汎用品では対応できない)
更にここまでしてなお印刷エラーは完全に排除できないから、
エラーの回復手順にどこまで目視確認(=人の介入)が必要か運用基準を設計しなければならない

こうして考えると、PCの印刷システムは少量多種なオフィス向け帳票印刷に適していても、
安全な大量印刷を求められる帳票印刷のニーズには不完全であることが理解できる
結果として、印刷システムを既に技術が確立しているメインフレームから
UNIX/PCへ移行するのは、大きな壁が存在していると言わざるをえない

>>162
何だってそうだよねえ。
少量多種を即時に出すのと大量同種を一度に出すのとは、根本思想が違ってる。
印刷だけの話じゃない。
寮生１０人の賄い飯を毎日作るおばちゃんと毎度異なる団体客千人への夕食を毎日作る板前さんとでは
ノウハウも技術も根本的に違う。
どっちが優劣でもない。

もう当たり前過ぎるレベルのスレだよな。
それを一緒くたにに話してる輩が不憫。