【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ではなくなります。

**デフォルトの名無しさん** · 2008/02/16(土) 20:17:40

バッチ処理はＳＡＳが一番だ。費用対効果は無視ナ。

**デフォルトの名無しさん** · 2008/02/18(月) 02:21:23

ttp://pc11.2ch.net/test/read.cgi/tech/1195400163/65

**はりせん** · 2008/03/08(土) 08:35:43

多態性オブジェクトを何とか理解して、
「リストにぶら下げたオブジェクトにイベントを渡す」
がイメージできたときに（塚越さんの本は分かりやすい）、
オブジェクト指向でバッチやるとロジックがシンプルに
なるな、と気がつき、Delphiでやってみるとなかなかよさげ。
（というか、これをやるためにコンパイラを買ったようなもの。）
で、ＩＢＭがＪａｖａを熱心にやっているので、Ｊａｖａにアレンジして
ＩＢＭユーザー研究会の論文に出したわけです。
　IBMのユーザー研なので、本文ではDelphiと書けずObjectPascal。
「Ｉ社」と書いたのは、当時のINPRISE社（ボーランド）のことだけど、
読んだ人はIBMと勘違いしてくれるだろうと期待してのこと。

　ただし、ここで最高の副産物。Ｊａｖａのプラットフォームにこだわらない
という特性は、ＰＣで作ったものがＭａｃで走る、ということよりも、ＰＣで
やっていた業務がスケールアップしても、ＵＮＩＸなりメインフレームで
プログラムを走らせればよい、というアイデア。でも一般的にならなかった。
　同じようなことは、同時期にテンアートニの社長もどっかで書いていた。
（はっきり意識していたかはよく分からないけど。）

**デフォルトの名無しさん** · 2008/03/08(土) 16:00:04

Javaで帳票のバッジ処理するのは変なんですか？

**デフォルトの名無しさん** · 2008/03/08(土) 18:19:38

>>46
狂気の沙汰

**デフォルトの名無しさん** · 2008/03/08(土) 18:29:54

帳票のバッジ処理って具体的にどんな処理？

**デフォルトの名無しさん** · 2008/03/10(月) 20:57:28

http://www.atmarkit.co.jp/fjava/rensai4/javabatch01/javabatch01_1.html

**デフォルトの名無しさん** · 2008/04/17(木) 23:09:53

http://www.atmarkit.co.jp/fjava/rensai4/javabatch02/javabatch02_1.html

**デフォルトの名無しさん** · 2008/06/06(金) 23:17:37

トランザクションの量によりますよね。
業務アプリはサーバーサイドjavaが大半だからバッチも含めて
ALLjavaも可能だけど、チューニング労力を考えると現実的
では無いような気がします。
大規模案件やった時はどうしても処理量が多いものはPL/SQL
で構築していました。

**デフォルトの名無しさん** · 2008/06/09(月) 14:07:45

http://www.atmarkit.co.jp/fjava/rensai4/javabatch03/javabatch03_1.html

**デフォルトの名無しさん** · 2008/06/18(水) 19:40:41

>>48
ファイル読んで帳票出力するんだべ？
違うの？

**デフォルトの名無しさん** · 2008/07/15(火) 20:53:11

http://www.infoq.com/jp/news/2008/07/spring-batch

**デフォルトの名無しさん** · 2008/07/22(火) 21:18:24

TextSS

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

＞バッチのフレームワーク
千手とかJP1とか。
運用管理システムのアーキテクチャに合わせて設計するだろ。
運用から見ればCOBOLだろうがJAVAだろうが変わりないけど、
シェルスクリプト内でループ回すのだけはやめて欲しい。遅すぎる(TT)
大規模バッチで重要なのは朝までに処理が終わるかどうか。
COBOLでも遅いものは遅い。
先行後続関係がくもの巣になってるほど終わらなくなるし、性能改善も難しい。

**デフォルトの名無しさん** · 2008/09/12(金) 11:03:42

【IT】「COBOLは現役バリバリ」、東京海上日動がシステム全面再構築でCOBOLを選んだワケ　開発者向けセミナー「XDev2008」 [08/09/08]
http://gimpo.2ch.net/test/read.cgi/bizplus/1220822531/

**デフォルトの名無しさん** · 2008/09/12(金) 21:37:00

バリバリ伝説

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

これは恋のおまもりｶｷｺです｡このｶｷｺを3ヵ所以上の
所に貼り付けると｡｡｡
いままでずっと
片思いだった人と
両思いになれちゃったり☆彼氏･彼女が
できちゃったり☆
と､他にもいい事がたぁ～っくさんおこります!!
私の姉がこれを
冗談でやってみたところ･･･
その3日後好きな人に告られました!!
これを信じるか
信じないかは
あなたしだいですよっっ☆
みなさんも
良い恋愛を･･･!!

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

>>57
「COBOLは現役バリバリ」　この言葉から加齢臭がする。

全面再構築でシステム構成のシンプル化を目指してるはずなのに、なんでJava+COBOLなんだよ。

でCOBOLがシンプルで習得スピードの速さに繋がり人材育成にも有効と言いながら。
なんで若手はJavaでベテランはCOBOLで開発してるんだよ。

どうせ取締役の私情でCOBOL使うことになったんだろ。無駄に作業をふやしてんじゃねえよ。

**デフォルトの名無しさん** · 2008/10/13(月) 19:02:08

>トランザクションの量によりますよね。
>業務アプリはサーバーサイドjavaが大半だからバッチも含めて
>ALLjavaも可能だけど、チューニング労力を考えると現実的
>では無いような気がします。

と、>>51氏が申しております。

**デフォルトの名無しさん** · 2008/12/24(水) 02:11:26

【.cmd】バッチファイルスクリプト %4 【.bat】
http://pc11.2ch.net/test/read.cgi/tech/1229955189/

**デフォルトの名無しさん** · 2009/01/22(木) 12:32:07

こぼるの良さを知らない若造が！！
こぼるはオヤジ達が似合う！！
こぼる最高！！！！！！！！！！！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

**デフォルトの名無しさん** · 2009/02/21(土) 02:29:53

map 系の処理が簡単に書けない COBOL も Java も糞じゃねぇの？
今時、クロージャがなくても許される言語って Fortran だけだよね
# Fortran は並列化構文があるので許さざるを得ない

**デフォルトの名無しさん** · 2009/02/26(木) 00:40:14

なんかみんな憐れ
痛々しい

**デフォルトの名無しさん** · 2009/02/27(金) 16:26:42

>>64　COBOLはしょうがないだろFortranと同じ世代だが元々の役割ちがうしFortranの並列化構文だってコンパイラーにその後付加されたのだろ

**デフォルトの名無しさん** · 2009/04/13(月) 20:32:36

計算はCOBOL、計算結果のメール送信にはjavaとか・・・

**デフォルトの名無しさん** · 2009/04/15(水) 23:18:02

そうか

**にゃあ** · 2009/05/04(月) 03:25:02

いまだ！69ｹﾞｯﾄォォｫｫ!!!　ｵﾏﾝｺﾍﾞﾛﾍﾞﾛﾅﾒﾀﾞーﾁﾝﾁﾝﾅﾒﾃー
￣￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣　　　　(´´
　　　　　　　　　　 ∧∧　　　　　　　(´⌒(´
　　　　　　　　　↑⊂（ﾟーﾟ*）≡≡≡(´⌒;;;≡≡≡
　　　　　　　⊆⊂´￣ ⊂ソ　(´⌒(´⌒;;
　　　　　　　　　　￣￣￣　　　ｽﾞｻﾞｰｰｰｰｰｯ

**デフォルトの名無しさん** · 2009/05/22(金) 21:45:07

EASY PULSについて聞きたいことがあるんだが、スレがない・・・
ここで質問してもいいのかな？

**デフォルトの名無しさん** · 2009/05/23(土) 09:01:06

富士通汎用機のツールか？とりあえず書いてみることよ。

**デフォルトの名無しさん** · 2009/05/23(土) 09:10:18

>>42 すごい亀だけど解決したんじゃろか？
Cobol質問スレねーの？

**デフォルトの名無しさん** · 2009/05/23(土) 09:38:59

以下の出力の違いを知りたいんだ。。。

例えば、SAMで頭4桁がX'123F'のデータがあるとして、
それをレポートに出力。

FILEA
A-DATA 1 2 P

W-DATA W 3 N

JOB
W-DATA = A-DATA
PRINT

と書いたとき、W-DATAの中身が012になっちゃうんだけど、
そーゆー仕様なの？
W-DATAを4桁にすると中身は0123。

ちなみに、データの頭が、'123C'や'123D'の時はちゃんと123になる。

EASY TRIVは平気なんだけど、PLUSは絶対値は勝手に埋められるのかな？

**デフォルトの名無しさん** · 2009/05/23(土) 11:18:26

今、実機で確認出来ませんが仕様と思われます。
以下のように推測します。
【原因】
B-DATAに出力を期待するデータは3桁であるのに、途中経路であるA-DATAを2桁で定義している。
状況により結果がことなるのはEASYのデータ切り捨て仕様に起因する(切り捨てが行われるタイミング)

【対処法】
A-DATAを3桁で定義する。

**デフォルトの名無しさん** · 2009/05/23(土) 11:30:34

>>74
だってパックだよ？
普通に出力したら化けるから、わざわざNタイプに移してから出力してるんだけど。。

**デフォルトの名無しさん** · 2009/05/23(土) 12:20:54

桁数あってないのが原因だと思うんだが。

**デフォルトの名無しさん** · 2009/05/23(土) 12:27:26

もしかしてパックだから3桁の半分の2桁にしたってオチ？文字数指定だから3のままでいいんだが、まさかそういうことじゃないだろうな

**デフォルトの名無しさん** · 2009/05/23(土) 12:43:05

そうじゃないだろ？

データとしては、

．．
13
2F

って入ってるだろ？
これを例えばA、2桁で定義したら、「．．」、P、2桁で定義したら「123F」
P、3桁なら隣の関係ないエリアまでかかるじゃねーか

**デフォルトの名無しさん** · 2009/05/23(土) 13:42:18

パックはそんなデータの持ち方しないはず。
ともかく3桁で定義して一度実行をすすめるわ。

**デフォルトの名無しさん** · 2009/05/23(土) 13:45:39

普通に開いたら．．でしか見れないだろ？
HEXモードにしたら>>78みたいに表示されるよな？
実際の値は開かないと分からない。
符号がなく絶対値だと勝手に桁埋めされるのかね・・・

**デフォルトの名無しさん** · 2009/05/29(金) 21:36:03

ワークベンチ(Eqlipse？)の日本語COBOL？使ってるんだが、
これってカラム位置とか揃えないといけないのか？
ＰＧ作ったら、イコールや符号、→の位置全部揃えろとか言われたから、
面倒だが、上から下まで全部揃えた。

次作った時は、最初から揃えた訳だが、今度はイコールや符号の位置がおかしいとか言い出して
俺の見てる前で半角スペースとDELキーで上から下までチマチマと位置をズラし始めた。
挙句の果てにここは１行空けるべきだとか言出だす。
他の人のソース見たら、普通に揃ってないわけだが…

さらには、ＥＡＳＹで作った検証ツールもＩＦなどを考慮して
イコールと符号の位置を揃えろとか言ってくるんだが
これはマジなわけ？