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

**デフォルトの名無しさん** · 2008/01/12(土) 16:38:37

最近は、Javaでもバッチ処理を書くんですなぁ

**デフォルトの名無しさん** · 2008/01/12(土) 16:42:52

http://hp.vector.co.jp/authors/VA015862/javabtch.html

**デフォルトの名無しさん** · 2008/01/12(土) 16:45:44

http://hp.vector.co.jp/authors/VA015862/javabtch.html

**デフォルトの名無しさん** · 2008/01/12(土) 22:09:05

batchがCでやるものだ

**デフォルトの名無しさん** · 2008/01/14(月) 12:10:39

あげ

**デフォルトの名無しさん** · 2008/01/14(月) 13:51:46

まん

支援

**デフォルトの名無しさん** · 2008/01/14(月) 14:54:50

Javaでバッチ処理なんてシステムを解ってないとしか言い様がない

**デフォルトの名無しさん** · 2008/01/14(月) 15:21:01

>>7
時代遅れのおっさんｗ
用なしｗｗｗ

**デフォルトの名無しさん** · 2008/01/14(月) 15:26:04

ちょっと観戦させてもらうよｗ

**デフォルトの名無しさん** · 2008/01/14(月) 19:46:00

Javaでもバッチ処理をしてみようというだけであって、
Javaでのバッチ処理なんて現実性がない。
実績もほとんどないだろ。
やっぱCOBOLだな。
実績ばっちり。

**デフォルトの名無しさん** · 2008/01/14(月) 19:53:30

http://www.atmarkit.co.jp/fjava/column/andoh/andoh37.html
これからの技術だと思うので、期待age

**デフォルトの名無しさん** · 2008/01/15(火) 01:10:13

結局バッチ処理は安定性・処理速度重視だろ？
JAVAじゃ無理だろ？

**デフォルトの名無しさん** · 2008/01/15(火) 01:47:49

Ｊａｖａは移植性高いし、ＪＣＬに取って変わらせてもいいんじゃないかな？
どうせ、ホストはＵＮＩＸにすれば、いいわけだし。
その程度のマイグレーションは出来るよねｗｗｗ
落ちコボラーには無理かｗ

**デフォルトの名無しさん** · 2008/01/15(火) 01:50:42

移植性はあるだろうが、安定性はどうなんだよ？
JAVAはメインフレームで走るCOBOLほど安定してんのか？

JAVAでバッチやるんなら大量データを処理するための処理とか
あるのかよ？

**デフォルトの名無しさん** · 2008/01/15(火) 01:51:58

なんだ、年齢がばれそうな汎用系のＳＥくずれかよｗ

**デフォルトの名無しさん** · 2008/01/15(火) 01:58:09

レガシーにしがみ付いてる業務系ＳＥにはスキルアップの途が既に閉ざされてる
ように聞こえてならない書き込みだなｗ

**デフォルトの名無しさん** · 2008/01/15(火) 02:03:05

JAVAで速くて安定しているバッチ処理は書けるのか？
そのための技術基盤があるのか？
それがなけりゃJAVAでバッチ処理なんてありえないだろ。

**デフォルトの名無しさん** · 2008/01/15(火) 02:11:12

分散処理の話してもしょうがなさそうだな、こりゃｗ
君が２０年以上経験してるとは思えんのでこれ以上話すまい。
では、お休みｗ

**デフォルトの名無しさん** · 2008/01/15(火) 02:15:42

なんだ、まともな反論も出来ない正月休みの中房かｗ

**デフォルトの名無しさん** · 2008/01/15(火) 02:35:58

まともな反論はできないだろう。
馬鹿につける薬はないとｗ

**デフォルトの名無しさん** · 2008/01/15(火) 22:42:21

Javaは遅いと思うけどOracle使ってんならSQL次第、というかデータベースのチューニング次第のような気ガス。

純粋にシーケンシャルファイルの読み込みならCOBOLのほうが早そうだけど
シーケンシャルに落としてソートしてキーマッチさせてローダーなんて
そろそろ絶滅してもいいんじゃねーかと思うな。

**デフォルトの名無しさん** · 2008/01/15(火) 23:19:44

すげぇ関係ないけど、Javaで可能だとしたら.NETでもやれるんだろうか？

**デフォルトの名無しさん** · 2008/01/16(水) 00:03:20

これだから、プログラマー連中はお荷物だといわれる。

**デフォルトの名無しさん** · 2008/01/16(水) 00:07:12

30年以上使い込んでるメインフレームごと落ちコボラーをインドにでも払い下げた
ほうが経営効率は1000倍はあがるな。

**デフォルトの名無しさん** · 2008/01/16(水) 00:15:11

>22
可能だろう。
Win系でバッチとか客に殺されるかもしれんがなｗ

**デフォルトの名無しさん** · 2008/01/16(水) 10:04:23

電気代と、古参のSEPGを経営面から見て継続使用が可能なら、
レガシーのまんまで良いのかもな。

中小規模で新規の基幹業務システムを構築する場合は、
予算と、要求仕様にもよるが、最近じゃあサーバーで実現できそうな
話だな。

**デフォルトの名無しさん** · 2008/01/16(水) 23:28:12

バッチはCでやるものだ

**デフォルトの名無しさん** · 2008/01/17(木) 01:31:19

http://itpro.nikkeibp.co.jp/free/NC/NEWS/20020628/2/

**デフォルトの名無しさん** · 2008/01/17(木) 01:45:10

COBOLで過去に作られた業務プログラムが企業にとって資産ねぇ？
地球温暖化の要因のひとつだろｗ

**デフォルトの名無しさん** · 2008/01/20(日) 20:10:24

SOAとbatchは似ている

**デフォルトの名無しさん** · 2008/01/21(月) 19:31:45

バッチのフレームワーク・・・
バッチ処理でstrutsのように使いまわせる処理ってあるか？

**デフォルトの名無しさん** · 2008/01/25(金) 17:07:19

>>31
まあ、各会社が必要に応じて作ってんな
バッチなんて、個人で率先してフレームワークを作ろうって対象じゃないしw

データ量が中規模までだったら、COBOLなんて絶滅して構わん
大規模で遅いのが問題なんだよ

俺はCOBOL嫌いだから、Cで作るべきだと思うけど、Cはこぼらーにも
JAVAや.Net派にも不人気なんだよな～
Cが一番速度と柔軟性を兼ね備えていると思うのに・・・

**デフォルトの名無しさん** · 2008/01/29(火) 21:50:51

コボルはそのまんま東

**デフォルトの名無しさん** · 2008/02/02(土) 01:25:15

http://itpro.nikkeibp.co.jp/article/NEWS/20080129/292387/

**デフォルトの名無しさん** · 2008/02/02(土) 22:19:45

>>32
各会社で作りこむ必要が無いバッチの処理って何だろう？
フレームワークということはバッチ処理の定型的な処理が
あるってことなんだろうけど。

**デフォルトの名無しさん** · 2008/02/03(日) 09:44:08

>>32
Cでバッチ処理書いてパフォーマンスあがる？
ファイルIOとデシマル計算がメインの金融系バッチだと
COBOLのほうが安定したパフォーマンスたたき出せると思うなあ。
あいだにSQL挟んだらそれこそC関係ないし。

ソートはCのほうが早そうだけど

**デフォルトの名無しさん** · 2008/02/03(日) 12:17:06

>>36
何件レコードのソート考えて書いてる？
ソートロジックかいたＣだから早いってか？

さらし上げ

**デフォルトの名無しさん** · 2008/02/03(日) 17:34:48

???
なにが言いたいのかよくわからん???

**デフォルトの名無しさん** · 2008/02/03(日) 18:11:45

クリティカルなバッチ処理ならCOBOLだと思うけど、
ちょっとした処理ならJavaでもCでもなんでもいいと思う。

ただフレームワークという発想は面白い。
springbatchに期待。

**デフォルトの名無しさん** · 2008/02/12(火) 01:23:14

Antとかでも簡単なバッチ処理出来そうなんだが
実績はないのか

**デフォルトの名無しさん** · 2008/02/12(火) 05:58:42

CSVからソース取ってきて、コンパイルして、Jarに固めて、デプロイ
という流れはバッチ処理と言えなくは無い。

**デフォルトの名無しさん** · 2008/02/16(土) 10:28:38

みなさんのお知恵をお借りしたいです。m(__ __)m
cobol + ORACLE10gです

下記のような事が可能と言われたのですが、
検証した結果無理でした。
再度、試みますが物理的に可能なんでしょうか？

手順①
INSERT
(COBOLE) PIC 9(09) COMP-3 ⇒ (ORACLE) CHAR 5
※この場合 ORACLE上では正しく表現されない事はOKとします。

手順②次に(上記の手順後)
(ORACLE) CHAR 5 ⇒ (COBOLE) PIC 9(09) COMP-3
この場合、INSERT時のCOBOLで入力した値が
正しく表現されると言われたのですが・・・
本当でしょうか？

検証した時には、
手順①
111111111 ⇒ 11111
手順②
11111 ⇒ 000012345

このように　再取得した値が000012345となり
当初の111111111ではなくなります。